Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5974 Aalto University
Category: Experimental G. Karagiannis
ISSN: 2070-1721 University of Twente/Ericsson
A. McDonald
Roke
October 2010
Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5974 Aalto University
Category: Experimental G. Karagiannis
ISSN: 2070-1721 University of Twente/Ericsson
A. McDonald
Roke
October 2010
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
用于服务质量信令的NSIS信令层协议（NSLP）
Abstract
摘要
This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules.
本规范描述了用于互联网中信令服务质量（QoS）预留的NSIS信令层协议（NSLP）。它符合NSIS中制定的框架和要求。与通用Internet信令传输（GIST）一起，它提供了类似于RSVP的功能，并对其进行了扩展。QoS NSLP独立于底层QoS规范或体系结构，并支持不同的预订模型。它通过消除对多播流的支持而得到简化。本规范解释了总体协议方法，描述了所做的设计决策，并提供了示例。它指定对象、消息格式和处理规则。
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/rfc5974.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5974.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overall Approach . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 9
3.1.2. QoS Models and QoS Specifications . . . . . . . . . . 10
3.1.3. Policy Control . . . . . . . . . . . . . . . . . . . . 12
3.2. Design Background . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Soft States . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Sender and Receiver Initiation . . . . . . . . . . . . 13
3.2.3. Protection against Message Re-ordering and
Duplication . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. Explicit Confirmations . . . . . . . . . . . . . . . . 14
3.2.5. Reduced Refreshes . . . . . . . . . . . . . . . . . . 14
3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15
3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16
3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 16
3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.11. Support for Request Priorities . . . . . . . . . . . . 18
3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19
3.2.13. Preemption . . . . . . . . . . . . . . . . . . . . . . 24
3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24
3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25
3.3.2. Support for Peer Change Identification . . . . . . . . 25
3.3.3. Support for Stateless Operation . . . . . . . . . . . 26
3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26
3.3.5. Knowledge of Intermediate QoS-NSLP-Unaware Nodes . . . 26
4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 26
4.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 27
4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overall Approach . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 9
3.1.2. QoS Models and QoS Specifications . . . . . . . . . . 10
3.1.3. Policy Control . . . . . . . . . . . . . . . . . . . . 12
3.2. Design Background . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Soft States . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Sender and Receiver Initiation . . . . . . . . . . . . 13
3.2.3. Protection against Message Re-ordering and
Duplication . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. Explicit Confirmations . . . . . . . . . . . . . . . . 14
3.2.5. Reduced Refreshes . . . . . . . . . . . . . . . . . . 14
3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15
3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16
3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 16
3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.11. Support for Request Priorities . . . . . . . . . . . . 18
3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19
3.2.13. Preemption . . . . . . . . . . . . . . . . . . . . . . 24
3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24
3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25
3.3.2. Support for Peer Change Identification . . . . . . . . 25
3.3.3. Support for Stateless Operation . . . . . . . . . . . 26
3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26
3.3.5. Knowledge of Intermediate QoS-NSLP-Unaware Nodes . . . 26
4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 26
4.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 27
4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 28
4.3. Basic Receiver-Initiated Reservation . . . . . . . . . . . 29
4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31
4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 33
4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 34
4.7. Reduced-State or Stateless Interior Nodes . . . . . . . . 38
4.7.1. Sender-Initiated Reservation . . . . . . . . . . . . . 38
4.7.2. Receiver-Initiated Reservation . . . . . . . . . . . . 40
4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41
5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 42
5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 42
5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 42
5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 44
5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 47
5.2. General Processing Rules . . . . . . . . . . . . . . . . . 60
5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 61
5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 62
5.2.3. Standard Message Processing Rules . . . . . . . . . . 62
5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 62
5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 63
5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 65
5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 65
5.3.2. Request Identification Information (RII) . . . . . . . 66
5.3.3. BOUND-SESSION-ID . . . . . . . . . . . . . . . . . . . 67
5.3.4. REFRESH-PERIOD . . . . . . . . . . . . . . . . . . . . 67
5.3.5. INFO-SPEC . . . . . . . . . . . . . . . . . . . . . . 68
5.3.6. SESSION-ID-LIST . . . . . . . . . . . . . . . . . . . 70
5.3.7. RSN-LIST . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 72
5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 72
5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 77
5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 78
5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 79
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 81
6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81
6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 82
6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 82
6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 83
6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 83
7. Security Considerations . . . . . . . . . . . . . . . . . . . 83
7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 85
7.2. Authorization Model Examples . . . . . . . . . . . . . . . 87
7.2.1. Authorization for the Two-Party Approach . . . . . . . 87
7.2.2. Token-Based Three-Party Approach . . . . . . . . . . . 88
7.2.3. Generic Three-Party Approach . . . . . . . . . . . . . 90
7.3. Computing the Authorization Decision . . . . . . . . . . . 90
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
4.3. Basic Receiver-Initiated Reservation . . . . . . . . . . . 29
4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31
4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 33
4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 34
4.7. Reduced-State or Stateless Interior Nodes . . . . . . . . 38
4.7.1. Sender-Initiated Reservation . . . . . . . . . . . . . 38
4.7.2. Receiver-Initiated Reservation . . . . . . . . . . . . 40
4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41
5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 42
5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 42
5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 42
5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 44
5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 47
5.2. General Processing Rules . . . . . . . . . . . . . . . . . 60
5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 61
5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 62
5.2.3. Standard Message Processing Rules . . . . . . . . . . 62
5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 62
5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 63
5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 65
5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 65
5.3.2. Request Identification Information (RII) . . . . . . . 66
5.3.3. BOUND-SESSION-ID . . . . . . . . . . . . . . . . . . . 67
5.3.4. REFRESH-PERIOD . . . . . . . . . . . . . . . . . . . . 67
5.3.5. INFO-SPEC . . . . . . . . . . . . . . . . . . . . . . 68
5.3.6. SESSION-ID-LIST . . . . . . . . . . . . . . . . . . . 70
5.3.7. RSN-LIST . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 72
5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 72
5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 77
5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 78
5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 79
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 81
6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81
6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 82
6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 82
6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 83
6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 83
7. Security Considerations . . . . . . . . . . . . . . . . . . . 83
7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 85
7.2. Authorization Model Examples . . . . . . . . . . . . . . . 87
7.2.1. Authorization for the Two-Party Approach . . . . . . . 87
7.2.2. Token-Based Three-Party Approach . . . . . . . . . . . 88
7.2.3. Generic Three-Party Approach . . . . . . . . . . . . . 90
7.3. Computing the Authorization Decision . . . . . . . . . . . 90
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
10.2. Informative References . . . . . . . . . . . . . . . . . . 91
Appendix A. Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 94
A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 94
A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 96
A.3. Configuration Interface . . . . . . . . . . . . . . . . . 99
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . 100
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
10.2. Informative References . . . . . . . . . . . . . . . . . . 91
Appendix A. Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 94
A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 94
A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 96
A.3. Configuration Interface . . . . . . . . . . . . . . . . . 99
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . 100
This document defines a Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP), henceforth referred to as the "QoS NSLP". This protocol establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of signaling protocols, whose structure is outlined in the NSIS framework [RFC4080]. The abstract NTLP has been developed into a concrete protocol, GIST (General Internet Signaling Transport) [RFC5971]. The QoS NSLP relies on GIST to carry out many aspects of signaling message delivery.
本文档定义了服务质量（QoS）NSIS信令层协议（NSLP），此后称为“QoS NSLP”。该协议建立并维护数据流路径上节点的状态，以便为该数据流提供一些转发资源。其旨在满足RFC 3726[RFC3726]的QoS相关要求。此QoS NSLP是更大的信令协议套件的一部分，其结构在NSIS框架[RFC4080]中概述。抽象的NTLP已经发展成为一个具体的协议GIST（通用互联网信令传输）[RFC5971]。QoS NSLP依靠GIST执行信令消息传递的许多方面。
The design of the QoS NSLP is conceptually similar to RSVP [RFC2205] and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726], in particular, support of sender- or receiver-initiated reservations, as well as a type of bidirectional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.
QoS NSLP的设计在概念上类似于RSVP[RFC2205]，并且使用软状态对等刷新消息作为主要状态管理机制（即，状态安装/刷新在成对相邻NSLP节点之间执行，而不是沿着完整信令路径以端到端方式执行）。QoS NSLP扩展了保留机制集，以满足RFC 3726[RFC3726]的要求，特别是，支持发送方或接收方发起的保留，以及一种双向保留和支持任意节点之间的保留，例如，边到边、端到访问等，目前不支持IP多播。
A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). This document describes the signaling protocol, whilst [RFC5975] describes the RMF-related information carried in the QSPEC (QoS Specification) object in QoS NSLP messages. This is similar to the decoupling between RSVP and the IntServ architecture [RFC1633]. The QSPEC carries information on resources available, resources required, traffic descriptions, and other information required by the RMF.
在信令协议的操作和资源管理功能（RMF）的操作所需的信息之间进行了区分。本文档描述了信令协议，[RFC5975]描述了QoS NSLP消息中QSPEC（QoS规范）对象中携带的RMF相关信息。这类似于RSVP和IntServ体系结构之间的解耦[RFC1633]。QSPEC包含可用资源、所需资源、交通描述以及RMF所需的其他信息。
This document is structured as follows. The overall protocol design is outlined in Section 3.1. The operation and use of the QoS NSLP is described in more detail in the rest of Section 3. Section 4 then clarifies the protocol by means of a number of examples. These sections should be read by people interested in the overall protocol capabilities. The functional specification in Section 5 contains more detailed object and message formats and processing rules and should be the basis for implementers. The subsequent sections describe IANA allocation issues and security considerations.
本文件的结构如下。第3.1节概述了整个协议设计。QoS NSLP的操作和使用在第3节的其余部分中有更详细的描述。然后，第4节通过一些示例对协议进行了澄清。这些章节应由对整体协议功能感兴趣的人阅读。第5节中的功能规范包含更详细的对象和消息格式以及处理规则，应该是实现者的基础。后续章节将介绍IANA分配问题和安全注意事项。
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]中所述进行解释。
The terminology defined by GIST [RFC5971] applies to this document.
GIST[RFC5971]定义的术语适用于本文件。
In addition, the following terms are used:
此外，还使用了以下术语：
QNE: an NSIS Entity (NE), which supports the QoS NSLP.
QNE：支持QoS NSLP的NSIS实体（NE）。
QNI: the first node in the sequence of QNEs that issues a reservation request for a session.
QNI：QNE序列中为会话发出保留请求的第一个节点。
QNR: the last node in the sequence of QNEs that receives a reservation request for a session.
QNR：QNE序列中接收会话保留请求的最后一个节点。
P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY scope flag set.
P-QNE:Proxy QNE，一个节点集，用于回复设置了代理作用域标志的消息。
Session: A session defines an association between a QNI and QNR related to a data flow. Intermediate QNEs on the path, the QNI, and the QNR use the same identifier to refer to the state stored for the association. The same QNI and QNR may have more than one session active at any one time.
会话：会话定义与数据流相关的QNI和QNR之间的关联。路径上的中间QNE、QNI和QNR使用相同的标识符来引用为关联存储的状态。同一QNI和QNR在任何时候都可能有多个会话处于活动状态。
Session Identification (SESSION-ID, SID): This is a cryptographically random and (probabilistically) globally unique identifier of the application-layer session that is associated with a certain flow. Often, there will only be one data flow for a given session, but in mobility/multihoming scenarios, there may be more than one, and they may be differently routed [RFC4080].
会话标识（Session-ID，SID）：这是与特定流关联的应用层会话的加密随机且（可能）全局唯一的标识符。通常，给定会话只有一个数据流，但在移动性/多宿场景中，可能有多个数据流，并且它们的路由可能不同[RFC4080]。
Source or message source: The one of two adjacent NSLP peers that is sending a signaling message (maybe the upstream or the downstream peer). Note that this is not necessarily the QNI.
源或消息源：发送信令消息的两个相邻NSLP对等方之一（可能是上游或下游对等方）。请注意，这不一定是QNI。
QoS NSLP operation state: State used/kept by the QoS NSLP processing to handle messaging aspects.
QoS NSLP操作状态：QoS NSLP处理用于处理消息传递方面的状态。
QoS reservation state: State used/kept by the Resource Management Function to describe reserved resources for a session.
QoS保留状态：资源管理功能使用/保持的状态，用于描述会话的保留资源。
Flow ID: This is essentially the Message Routing Information (MRI) in GIST for path-coupled signaling.
流ID：这本质上是GIST中路径耦合信令的消息路由信息（MRI）。
Figure 1 shows the components that have a role in a QoS NSLP signaling session. The flow sender and receiver would in most cases be part of the QNI and QNR nodes. Yet, these may be separate nodes, too.
图1显示了在QoS NSLP信令会话中扮演角色的组件。在大多数情况下，流发送方和接收方都是QNI和QNR节点的一部分。然而，这些也可能是独立的节点。
QoS NSLP nodes
IP address (QoS-unaware NSIS nodes are IP address
= Flow not shown) = Flow
Source | | | Destination
Address | | | Address
V V V
+--------+ Data +------+ +------+ +------+ +--------+
| Flow |-------|------|------|------|-------|------|---->| Flow |
| Sender | Flow | | | | | | |Receiver|
+--------+ | QNI | | QNE | | QNR | +--------+
| | | | | |
+------+ +------+ +------+
=====================>
<=====================
Signaling
Flow
QoS NSLP nodes
IP address (QoS-unaware NSIS nodes are IP address
= Flow not shown) = Flow
Source | | | Destination
Address | | | Address
V V V
+--------+ Data +------+ +------+ +------+ +--------+
| Flow |-------|------|------|------|-------|------|---->| Flow |
| Sender | Flow | | | | | | |Receiver|
+--------+ | QNI | | QNE | | QNR | +--------+
| | | | | |
+------+ +------+ +------+
=====================>
<=====================
Signaling
Flow
Figure 1: Components of the QoS NSLP Architecture
图1:QoS NSLP体系结构的组件
A glossary of terms and abbreviations used in this document can be found in Appendix B.
本文件中使用的术语表和缩略语见附录B。
This section presents a logical model for the operation of the QoS NSLP and associated provisioning mechanisms within a single node. The model is shown in Figure 2.
本节介绍QoS NSLP操作的逻辑模型以及单个节点内的相关供应机制。模型如图2所示。
+-----------------+
| Local |
| Applications or |
|Management (e.g.,|
| for aggregates) |
+-----------------+
^
V
V
+----------+ +----------+ +---------+
| QoS NSLP | | Resource | | Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+ +----------+ +---------+
. ^ | * ^
| V . * ^
+----------+ * ^
| NTLP | * ^
|Processing| * V
+----------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.==>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
+-----------------+
| Local |
| Applications or |
|Management (e.g.,|
| for aggregates) |
+-----------------+
^
V
V
+----------+ +----------+ +---------+
| QoS NSLP | | Resource | | Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+ +----------+ +---------+
. ^ | * ^
| V . * ^
+----------+ * ^
| NTLP | * ^
|Processing| * V
+----------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.==>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
Figure 2: QoS NSLP in a Node
图2：节点中的QoS NSLP
This diagram shows an example implementation scenario where QoS conditioning is performed on the output interface. However, this does not limit the possible implementations. For example, in some cases, traffic conditioning may be performed on the incoming interface, or it may be split over the input and output interfaces.
此图显示了在输出接口上执行QoS调节的示例实现场景。然而，这并不限制可能的实现。例如，在某些情况下，流量调节可以在传入接口上执行，也可以在输入和输出接口上进行拆分。
Also, the interactions with the Policy Control component may be more complex, involving interaction with the Resource Management Function, and the AAA infrastructure.
此外，与策略控制组件的交互可能更复杂，涉及与资源管理功能和AAA基础设施的交互。
From the perspective of a single node, the request for QoS may result from a local application request or from processing an incoming QoS NSLP message. The request from a local application includes not only user applications but also network management and the policy control module. For example, a request could come from multimedia applications, initiate a tunnel to handle an aggregate, interwork with some other reservation protocol (such as RSVP), and contain an explicit teardown triggered by a AAA policy control module. In this sense, the model does not distinguish between hosts and routers.
从单个节点的角度来看，QoS请求可能来自本地应用程序请求或来自处理传入的QoS NSLP消息。来自本地应用程序的请求不仅包括用户应用程序，还包括网络管理和策略控制模块。例如，请求可能来自多媒体应用程序，启动隧道以处理聚合，与其他一些保留协议（如RSVP）互通，并包含由AAA策略控制模块触发的显式拆卸。从这个意义上讲，该模型不区分主机和路由器。
Incoming messages are captured during input packet processing and handled by GIST. Only messages related to QoS are passed to the QoS NSLP. GIST may also generate triggers to the QoS NSLP (e.g., indications that a route change has occurred). The QoS request is handled by the RMF, which coordinates the activities required to grant and configure the resource. It also handles policy-specific aspects of QoS signaling.
传入消息在输入数据包处理期间被捕获，并由GIST处理。仅将与QoS相关的消息传递给QoS NSLP。GIST还可以生成QoS NSLP的触发器（例如，发生路由改变的指示）。QoS请求由RMF处理，RMF协调授予和配置资源所需的活动。它还处理QoS信令的特定于策略的方面。
The grant processing involves two local decision modules, 'policy control' and 'admission control'. Policy control determines whether the user is authorized to make the reservation. Admission control determines whether the network of the node has sufficient available resources to supply the requested QoS. If both checks succeed, parameters are set in the packet classifier and in the link-layer interface (e.g., in the packet scheduler) to obtain the desired QoS. Error notifications are passed back to the request originator. The Resource Management Function may also manipulate the forwarding tables at this stage to select (or at least pin) a route; this must be done before interface-dependent actions are carried out (including sending outgoing messages over any new route), and is in any case invisible to the operation of the protocol.
授权处理涉及两个本地决策模块，“策略控制”和“许可控制”。策略控制确定用户是否有权进行预订。接纳控制确定节点的网络是否具有足够的可用资源来提供所请求的QoS。如果两个检查都成功，则在包分类器和链路层接口（例如，在包调度器中）中设置参数以获得所需的QoS。错误通知会传回请求发起人。资源管理功能还可在此阶段操纵转发表以选择（或至少pin）路由；这必须在执行依赖接口的操作（包括通过任何新路由发送传出消息）之前完成，并且在任何情况下协议的操作都不可见。
Policy control is expected to make use of the authentication infrastructure or the authentication protocols external to the node itself. Some discussion can be found in a separate document on authorization issues [qos-auth]. More generally, the processing of policy and Resource Management Functions may be outsourced to an external node, leaving only 'stubs' co-located with the NSLP node; this is not visible to the protocol operation. A more detailed discussion of authentication and authorization can be found in Section 3.1.3.
策略控制应使用身份验证基础设施或节点本身外部的身份验证协议。关于授权问题[qos auth]，可以在单独的文档中找到一些讨论。更一般地说，策略和资源管理功能的处理可能外包给外部节点，只留下与NSLP节点位于同一位置的“存根”；这对协议操作不可见。有关认证和授权的更详细讨论，请参见第3.1.3节。
Admission control, packet scheduling, and any part of policy control beyond simple authorization have to be implemented using specific definitions for types and levels of QoS. A key assumption is made that the QoS NSLP is independent of the QoS parameters (e.g., IntServ service elements). These are captured in a QoS model and interpreted only by the resource management and associated functions, and are opaque to the QoS NSLP itself. QoS models are discussed further in Section 3.1.2.
必须使用QoS类型和级别的特定定义来实现准入控制、数据包调度和简单授权之外的任何策略控制。主要假设QoS NSLP独立于QoS参数（例如，IntServ服务元素）。这些都是在QoS模型中捕获的，仅由资源管理和相关功能进行解释，并且对QoS NSLP本身是不透明的。第3.1.2节将进一步讨论QoS模型。
The final stage of processing for a resource request is to indicate to the QoS NSLP protocol processing that the required resources have been configured. The QoS NSLP may generate an acknowledgment message in one direction, and may forward the resource request in the other. Message routing is carried out by the GIST module. Note that while Figure 2 shows a unidirectional data flow, the signaling messages can pass in both directions through the node, depending on the particular message and orientation of the reservation.
资源请求处理的最后阶段是向QoS NSLP协议处理指示已配置所需资源。QoS NSLP可以在一个方向上生成确认消息，并且可以在另一个方向上转发资源请求。消息路由由GIST模块执行。注意，尽管图2显示了单向数据流，但信令消息可以在两个方向上通过节点，这取决于特定消息和保留的方向。
The QoS NSLP uses four message types:
QoS NSLP使用四种消息类型：
RESERVE: The RESERVE message is the only message that manipulates QoS NSLP reservation state. It is used to create, refresh, modify, and remove such state. The result of a RESERVE message is the same whether a message is received once or many times.
RESERVE：RESERVE消息是唯一操纵QoS NSLP保留状态的消息。它用于创建、刷新、修改和删除此类状态。无论消息接收一次还是多次，保留消息的结果都是相同的。
QUERY: A QUERY message is used to request information about the data path without making a reservation. This functionality can be used to make reservations or to support certain QoS models. The information obtained from a QUERY may be used in the admission control process of a QNE (e.g., in case of measurement-based admission control). Note that a QUERY does not change existing reservation state.
查询：查询消息用于请求有关数据路径的信息，而无需进行保留。此功能可用于预订或支持某些QoS模型。从查询获得的信息可用于QNE的接纳控制过程（例如，在基于测量的接纳控制的情况下）。请注意，查询不会更改现有保留状态。
RESPONSE: The RESPONSE message is used to provide information about the result of a previous QoS NSLP message. This includes explicit confirmation of the state manipulation signaled in the RESERVE message, and the response to a QUERY message or an error code if the QNE or QNR is unable to provide the requested information or if the response is negative. The RESPONSE message does not cause any reservation state to be installed or modified.
响应：响应消息用于提供有关先前QoS NSLP消息结果的信息。这包括明确确认保留消息中发出的状态操纵信号，以及在QNE或QNR无法提供请求的信息或响应为否定时对查询消息或错误代码的响应。响应消息不会导致安装或修改任何保留状态。
NOTIFY: NOTIFY messages are used to convey information to a QNE. They differ from RESPONSE messages in that they are sent asynchronously and need not refer to any particular state or previously received message. The information conveyed by a NOTIFY
通知：通知消息用于向QNE传递信息。它们与响应消息的不同之处在于，它们是异步发送的，不需要引用任何特定状态或以前收到的消息。通知所传达的信息
message is typically related to error conditions. Examples would be notification to an upstream peer about state being torn down or notification when a reservation has been preempted.
消息通常与错误条件有关。例如，向上游对等方发出关于状态被删除的通知，或者在保留被抢占时发出通知。
QoS NSLP messages are sent peer-to-peer. This means that a QNE considers its adjacent upstream or downstream peer to be the source of each message.
QoS NSLP消息以对等方式发送。这意味着QNE将其相邻的上游或下游对等方视为每条消息的源。
Each protocol message has a common header which indicates the message type and contains various flag bits. Message formats are defined in Section 5.1.2. Message processing rules are defined in Section 5.4.
每个协议消息都有一个公共标头，该标头指示消息类型并包含各种标志位。第5.1.2节定义了消息格式。第5.4节定义了消息处理规则。
QoS NSLP messages contain three types of objects:
QoS NSLP消息包含三种类型的对象：
1. Control Information: Control information objects carry general information for the QoS NSLP processing, such as sequence numbers or whether a response is required.
1. 控制信息：控制信息对象包含QoS NSLP处理的一般信息，例如序列号或是否需要响应。
2. QoS specifications (QSPECs): QSPEC objects describe the actual resources that are required and depend on the QoS model being used. Besides any resource description, they may also contain other control information used by the RMF's processing.
2. QoS规范（QSPEC）：QSPEC对象描述所需的实际资源，并取决于所使用的QoS模型。除了任何资源描述之外，它们还可能包含RMF处理所使用的其他控制信息。
3. Policy objects: Policy objects contain data used to authorize the reservation of resources.
3. 策略对象：策略对象包含用于授权资源保留的数据。
Object formats are defined in Section 5.1.3. Object processing rules are defined in Section 5.3.
第5.1.3节定义了对象格式。第5.3节定义了对象处理规则。
The QoS NSLP provides flexibility over the exact patterns of signaling messages that are exchanged. The decoupling of QoS NSLP and QSPEC allows the QoS NSLP to be ignorant about the ways in which traffic, resources, etc., are described, and it can treat the QSPEC as an opaque object. Various QoS models can be designed, and these do not affect the specification of the QoS NSLP protocol. Only the RMF specific to a given QoS model will need to interpret the QSPEC. The Resource Management Function (RMF) reserves resources for each flow.
QoS NSLP为交换的信令消息的确切模式提供了灵活性。QoS NSLP和QSPEC的解耦允许QoS NSLP不知道流量、资源等的描述方式，并且可以将QSPEC视为不透明对象。可以设计各种QoS模型，这些模型不影响QoS NSLP协议的规范。只有特定于给定QoS模型的RMF才需要解释QSPEC。资源管理功能（RMF）为每个流保留资源。
The QSPEC fulfills a similar purpose to the TSpec, RSpec, and AdSpec objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted by the Resource Management Function and the Policy Control Function for the purposes of traffic and policy control (including admission control and configuration of the packet classifier and scheduler).
QSPEC实现了与RSVP一起使用并在RFC 2205[RFC2205]和RFC 2210[RFC2210]中规定的TSpec、RSpec和AdSpec对象类似的目的。在每个QNE处，QSPEC的内容由资源管理功能和策略控制功能解释，以用于业务和策略控制（包括接纳控制和分组分类器和调度器的配置）。
The QoS NSLP does not mandate any particular behavior for the RMF, instead providing interoperability at the signaling-protocol level whilst leaving the validation of RMF behavior to contracts external to the protocol itself. The RMF may make use of various elements from the QoS NSLP message, not only the QSPEC object.
QoS NSLP不要求RMF具有任何特定行为，而是在信令协议级别提供互操作性，同时将RMF行为的验证留给协议本身外部的契约。RMF可以使用来自QoS NSLP消息的各种元素，而不仅仅是QSPEC对象。
Still, this specification assumes that resource sharing is possible between flows with the same SESSION-ID that originate from the same QNI or between flows with a different SESSION-ID that are related through the BOUND-SESSION-ID object. For flows with the same SESSION-ID, resource sharing is only applicable when the existing reservation is not just replaced (which is indicated by the REPLACE flag in the common header). We assume that the QoS model supports resource sharing between flows. A QoS Model may elect to implement a more general behavior of supporting relative operations on existing reservations, such as ADDING or SUBTRACTING a certain amount of resources from the current reservation. A QoS Model may also elect to allow resource sharing more generally, e.g., between all flows with the same Differentiated Service Code Point (DSCP).
尽管如此，本规范假设源于同一QNI的具有相同会话ID的流之间或通过绑定会话ID对象相关的具有不同会话ID的流之间可以共享资源。对于具有相同SESSION-ID的流，资源共享仅在不只是替换现有保留时适用（由公共头中的REPLACE标志指示）。我们假设QoS模型支持流之间的资源共享。QoS模型可以选择实现更一般的行为，支持对现有保留的相对操作，例如从当前保留中添加或减去一定数量的资源。QoS模型还可以选择更一般地允许资源共享，例如，在具有相同区分服务码点（DSCP）的所有流之间。
The QSPEC carries a collection of objects that can describe QoS specifications in a number of different ways. A generic template is defined in [RFC5975] and contains object formats for generally useful elements of the QoS description, which is designed to ensure interoperability when using the basic set of objects. A QSPEC describing the resources requested will usually contain objects that need to be understood by all implementations, and it can also be enhanced with additional objects specific to a QoS model to provide a more exact definition to the RMF, which may be better able to use its specific resource management mechanisms (which may, e.g., be link specific) as a result.
QSPEC包含一组对象，这些对象可以以多种不同的方式描述QoS规范。[RFC5975]中定义了一个通用模板，该模板包含QoS描述中常用元素的对象格式，用于确保使用基本对象集时的互操作性。描述所请求资源的QSPEC通常包含所有实现都需要理解的对象，并且还可以使用特定于QoS模型的附加对象来增强它，以便为RMF提供更精确的定义，RMF可能更好地使用其特定的资源管理机制（例如，可能是特定于链路的）因此。
A QoS Model defines the behavior of the RMF, including inputs and outputs, and how QSPEC information is used to describe resources available, resources required, traffic descriptions, and control information required by the RMF. A QoS Model also describes the minimum set of parameters QNEs should use in the QSPEC when signaling about this QoS Model.
QoS模型定义RMF的行为，包括输入和输出，以及如何使用QSPEC信息来描述RMF所需的可用资源、所需资源、流量描述和控制信息。QoS模型还描述了QNE在发送有关此QoS模型的信号时应在QSPEC中使用的最小参数集。
QoS Models may be local (private to one network), implementation/ vendor specific, or global (implementable by different networks and vendors). All QSPECs should follow the design of the QSPEC template.
QoS模型可以是本地（一个网络专用）、实现/特定于供应商或全局（可由不同的网络和供应商实现）。所有QSPEC应遵循QSPEC模板的设计。
The definition of a QoS model may also have implications on how local behavior should be implemented in the areas where the QoS NSLP gives freedom to implementers. For example, it may be useful to identify recommended behavior for how a forwarded RESERVE message relates to a received one, or for when additional signaling sessions should be
QoS模型的定义还可能对QoS NSLP为实现者提供自由的区域如何实现本地行为产生影响。例如，对于转发的保留消息如何与接收到的保留消息相关，或者对于何时应该进行额外的信令会话，识别推荐的行为可能是有用的
started based on existing sessions, such as required for aggregate reservations. In some cases, suggestions may be made on whether state that may optionally be retained should be held in particular scenarios. A QoS model may specify reservation preemption, e.g., an incoming resource request may cause removal of an earlier established reservation.
基于现有会话启动，例如聚合预订所需的会话。在某些情况下，可以就在特定情况下是否应保留可选择保留的状态提出建议。QoS模型可以指定预约抢占，例如，传入的资源请求可以导致移除先前建立的预约。
Getting access to network resources, e.g., network access in general or access to QoS, typically involves some kind of policy control. One example of this is authorization of the resource requester. Policy control for QoS NSLP resource reservation signaling is conceptually organized as illustrated below in Figure 3.
获取对网络资源的访问，例如，一般的网络访问或对QoS的访问，通常涉及某种策略控制。这方面的一个例子是资源请求者的授权。QoS NSLP资源预留信令的策略控制在概念上组织如下图3所示。
+-------------+
| Policy |
| Decision |
| Point (PDP) |
+------+------+
|
/-\-----+-----/\
//// \\\\
|| ||
| Policy transport |
|| ||
\\\\ ////
\-------+------/
|
+-------------+ QoS signaling +------+------+
| Entity |<==============>| QNE = Policy|<=========>
| requesting | Data Flow | Enforcement |
| resource |----------------|-Point (PEP)-|---------->
+-------------+ +-------------+
+-------------+
| Policy |
| Decision |
| Point (PDP) |
+------+------+
|
/-\-----+-----/\
//// \\\\
|| ||
| Policy transport |
|| ||
\\\\ ////
\-------+------/
|
+-------------+ QoS signaling +------+------+
| Entity |<==============>| QNE = Policy|<=========>
| requesting | Data Flow | Enforcement |
| resource |----------------|-Point (PEP)-|---------->
+-------------+ +-------------+
Figure 3: Policy Control with the QoS NSLP Signaling
图3：QoS NSLP信令的策略控制
From the QoS NSLP point of view, the policy control model is essentially a two-party model between neighboring QNEs. The actual policy decision may depend on the involvement of a third entity (the Policy Decision Point, PDP), but this happens outside of the QoS NSLP protocol by means of existing policy infrastructure (Common Open Policy Service (COPS), Diameter, etc.). The policy control model for the entire end-to-end chain of QNEs is therefore one of transitivity, where each of the QNEs exchanges policy information with its QoS NSLP policy peer.
从QoS NSLP的角度来看，策略控制模型本质上是相邻QNE之间的双方模型。实际的策略决策可能取决于第三实体（策略决策点，PDP）的参与，但这是在QoS NSLP协议之外通过现有的策略基础设施（公共开放策略服务（COPS）、Diameter等）实现的。因此，整个QNE端到端链的策略控制模型是可传递的，其中每个QNE与其QoS NSLP策略对等方交换策略信息。
The authorization of a resource request often depends on the identity of the entity making the request. Authentication may be required. The GIST channel security mechanisms provide one way of authenticating the QoS NSLP peer that sent the request, and so may be used in making the authorization decision.
资源请求的授权通常取决于发出请求的实体的身份。可能需要身份验证。GIST信道安全机制提供了一种验证发送请求的QoS NSLP对等方的方法，因此可用于做出授权决策。
Additional information might also be provided in order to assist in making the authorization decision. This might include alternative methods of authenticating the request.
还可以提供其他信息，以协助作出授权决定。这可能包括验证请求的替代方法。
The QoS NSLP does not currently contain objects to carry authorization information. At the time of writing, there exists a separate individual work [NSIS-AUTH] that defines this functionality for the QoS NSLP and the NAT and firewall (NATFW) NSLP.
QoS NSLP当前不包含携带授权信息的对象。在撰写本文时，存在一个单独的工作[NSIS-AUTH]，它为QoS NSLP和NAT和防火墙（NATFW）NSLP定义了此功能。
It is generally assumed that policy enforcement is likely to concentrate on border nodes between administrative domains. This may mean that nodes within the domain are "Policy-Ignorant Nodes" that perform no per-request authentication or authorization, relying on the border nodes to perform the enforcement. In such cases, the policy management between ingress and egress edge of a domain relies on the internal chain of trust between the nodes in the domain. If this is not acceptable, a separate signaling session can be set up between the ingress and egress edge nodes in order to exchange policy information.
通常认为策略实施可能集中在管理域之间的边界节点上。这可能意味着域中的节点是“策略无关节点”，不执行每请求身份验证或授权，依赖边界节点执行强制。在这种情况下，域的入口和出口边缘之间的策略管理依赖于域中节点之间的内部信任链。如果这是不可接受的，则可以在入口和出口边缘节点之间建立单独的信令会话，以便交换策略信息。
This section presents some of the key functionality behind the specification of the QoS NSLP.
本节介绍QoS NSLP规范背后的一些关键功能。
The NSIS protocol suite takes a soft-state approach to state management. This means that reservation state in QNEs must be periodically refreshed. The frequency with which state installation is refreshed is expressed in the REFRESH-PERIOD object. This object contains a value in milliseconds indicating how long the state that is signaled for remains valid. Maintaining the reservation beyond this lifetime can be done by sending a RESERVE message periodically.
NSIS协议套件采用软状态方法进行状态管理。这意味着QNE中的保留状态必须定期刷新。状态安装刷新的频率在REFRESH-PERIOD对象中表示。此对象包含一个以毫秒为单位的值，该值指示为其发送信号的状态保持有效的时间。通过定期发送保留消息，可以在该生命周期之后维护保留。
The QoS NSLP supports both sender-initiated and receiver-initiated reservations. For a sender-initiated reservation, RESERVE messages travel in the same direction as the data flow that is being signaled for (the QNI is at the side of the source of the data flow). For a
QoS NSLP支持发送方发起和接收方发起的保留。对于发送方发起的保留，保留消息的传输方向与发送信号的数据流相同（QNI位于数据流源的一侧）。暂时
receiver-initiated reservation, RESERVE messages travel in the opposite direction (the QNI is at the side of the receiver of the data flow).
接收方发起的保留，保留消息以相反的方向传播（QNI位于数据流接收方的一侧）。
Note: these definitions follow the definitions in Section 3.3.1 of RFC 4080 [RFC4080]. The main issue is about which node is in charge of requesting and maintaining the resource reservation. In a receiver-initiated reservation, even though the sender sends the initial QUERY, the receiver is still in charge of making the actual resource request and maintaining the reservation.
注：这些定义遵循RFC 4080[RFC4080]第3.3.1节中的定义。主要问题是哪个节点负责请求和维护资源预留。在接收方发起的保留中，即使发送方发送初始查询，接收方仍负责发出实际的资源请求并维护保留。
RESERVE messages affect the installed reservation state. Unlike NOTIFY, QUERY, and RESPONSE messages, the order in which RESERVE messages are received influences the eventual reservation state that will be stored at a QNE; that is, the most recent RESERVE message replaces the current reservation. Therefore, in order to protect against RESERVE message re-ordering or duplication, the QoS NSLP uses a Reservation Sequence Number (RSN). The RSN has local significance only, i.e., between a QNE and its downstream peers.
保留消息会影响已安装的保留状态。与通知、查询和响应消息不同，接收保留消息的顺序影响将存储在QNE中的最终保留状态；也就是说，最新的保留消息将替换当前的保留。因此，为了防止保留消息重新排序或复制，QoS NSLP使用保留序列号（RSN）。RSN仅具有局部意义，即在QNE与其下游对等方之间。
A QNE may require a confirmation that the end-to-end reservation is in place, or a reply to a query along the path. For such requests, it must be able to keep track of which request each response refers to. This is supported by including a Request Identification Information (RII) object in a QoS NSLP message.
QNE可能需要确认端到端保留已到位，或对路径上的查询作出答复。对于此类请求，它必须能够跟踪每个响应所指的请求。这是通过在QoS NSLP消息中包含请求标识信息（RII）对象来支持的。
For scalability, the QoS NSLP supports an abbreviated form of refresh RESERVE message. In this case, the refresh RESERVE references the reservation using the RSN and the SESSION-ID, and does not include the full reservation specification (including QSPEC). By default, state refresh should be performed with reduced refreshes in order to save bytes during transmission. Stateless QNEs will require full refresh since they do not store the whole reservation information.
对于可伸缩性，QoS NSLP支持一种简化形式的刷新保留消息。在这种情况下，刷新保留使用RSN和SESSION-ID引用保留，并且不包括完整的保留规范（包括QSPEC）。默认情况下，状态刷新应在减少刷新的情况下执行，以便在传输期间保存字节。无状态QNE将需要完全刷新，因为它们不存储整个预订信息。
If the stateful QNE does not support reduced refreshes, or there is a mismatch between the local and received RSN, the stateful QNE must reply with a RESPONSE carrying an INFO-SPEC indicating the error. Furthermore, the QNE must stop sending reduced refreshes to this peer if the error indicates that support for this feature is lacking.
如果有状态QNE不支持减少刷新，或者本地RSN与接收到的RSN不匹配，则有状态QNE必须使用带有指示错误的信息规范的响应进行回复。此外，如果错误表明缺少对该功能的支持，QNE必须停止向该对等方发送减少的刷新。
For limiting the number of individual messages, the QoS NSLP supports summary refresh and summary tear messages. When sending a refreshing RESERVE for a certain (primary) session, a QNE may include a SESSION-ID-LIST object where the QNE indicates (secondary) sessions that are also refreshed. An RSN-LIST object must also be added. The SESSION-IDs and RSNs are stacked in the objects such that the index in both stacks refer to the same reservation state, i.e., the SESSION-ID and RSN at index i in both objects refers to the same session. If the receiving stateful QNE notices unknown SESSION-IDs or a mismatch with RSNs for a session, it will reply back to the upstream stateful QNE with an error.
为了限制单个消息的数量，QoS NSLP支持摘要刷新和摘要删除消息。当发送某个（主）会话的刷新保留时，QNE可以包括会话ID列表对象，其中QNE指示也被刷新的（辅助）会话。还必须添加RSN-LIST对象。会话ID和RSN被堆叠在对象中，使得两个堆栈中的索引引用相同的保留状态，即，两个对象中索引i处的会话ID和RSN引用相同的会话。如果接收有状态QNE注意到未知会话ID或与会话的RSN不匹配，它将返回到上游有状态QNE，并返回一个错误。
In order to tear down several sessions at once, a QNE may include SESSION-ID-LIST and RSN-LIST objects in a tearing reserve. The downstream stateful QNE must then also tear down the other sessions indicated. The downstream stateful QNE must silently ignore any unknown SESSION-IDs.
为了一次中断多个会话，QNE可以在中断保留中包括会话ID-LIST和RSN-LIST对象。然后，下游有状态QNE还必须中断指示的其他会话。下游有状态QNE必须静默忽略任何未知会话ID。
GIST provides a SII-Handle for every downstream session. The SII-Handle identifies a peer and should be the same for all sessions whose downstream peer is the same. The QoS NSLP uses this information to decide whether summary refresh messages can be sent or when a summary tear is possible.
GIST为每个下游会话提供一个SII句柄。SII句柄标识一个对等方，对于其下游对等方相同的所有会话，该句柄应相同。QoS NSLP使用此信息来决定是否可以发送摘要刷新消息或何时可以进行摘要删除。
A QNE may use local policy when deciding whether to propagate a message or not. For example, the local policy can define/configure that a QNE is, for a particular session, a QNI and/or a QNR. The QoS NSLP also includes an explicit mechanism to restrict message propagation by means of a scoping mechanism.
QNE在决定是否传播消息时可以使用本地策略。例如，本地策略可以定义/配置QNE对于特定会话是QNI和/或QNR。QoS NSLP还包括通过作用域机制限制消息传播的显式机制。
For a RESERVE or a QUERY message, two scoping flags limit the part of the path on which state is installed on the downstream nodes that can respond. When the SCOPING flag is set to zero, it indicates that the scope is "whole path" (default). When set to one, the scope is "single hop". When the PROXY scope flag is set, the path is terminated at a pre-defined Proxy QNE (P-QNE). This is similar to the Localized RSVP [lrsvp].
对于保留消息或查询消息，两个作用域标志限制了路径中可响应的下游节点上安装状态的部分。当作用域标志设置为零时，表示作用域为“完整路径”（默认）。当设置为1时，范围为“单跳”。设置代理作用域标志时，路径在预定义的代理QNE（P-QNE）处终止。这类似于本地化的RSVP[lrsvp]。
The propagation of a RESPONSE message is limited by the RII object, which ensures that it is not forwarded back along the path further than the node that requested the RESPONSE.
响应消息的传播受到RII对象的限制，该对象确保响应消息不会沿着路径转发回请求响应的节点。
Session binding is defined as the enforcement of a relation between different QoS NSLP sessions (i.e., signaling flows with different SESSION-IDs (SIDs) as defined in GIST [RFC5971]).
会话绑定定义为不同QoS NSLP会话（即，具有GIST[RFC5971]中定义的不同会话ID（SID）的信令流）之间的关系的实施。
Session binding indicates a unidirectional dependency relation between two or more sessions by including a BOUND-SESSION-ID object. A session with SID_A (the binding session) can express its unidirectional dependency relation to another session with SID_B (the bound session) by including a BOUND-SESSION-ID object containing SID_B in its messages.
会话绑定通过包含绑定的Session-ID对象指示两个或多个会话之间的单向依赖关系。具有SID_A（绑定会话）的会话可以通过在其消息中包含包含SID_B的绑定会话ID对象来表示其与另一个具有SID_B（绑定会话）的会话的单向依赖关系。
The concept of session binding is used to indicate the unidirectional dependency relation between the end-to-end session and the aggregate session in case of aggregate reservations. In case of bidirectional reservations, it is used to express the unidirectional dependency relation between the sessions used for forward and reverse reservation. Typically, the dependency relation indicated by session binding is purely informative in nature and does not automatically trigger any implicit action in a QNE. A QNE may use the dependency relation information for local resource optimization or to explicitly tear down reservations that are no longer useful. However, by using an explicit binding code (see Section 5.1.3.4), it is possible to formalize this dependency relation, meaning that if the bound session (e.g., session with SID_B) is terminated, the binding session (e.g., the session with SID_A) must be terminated also.
会话绑定的概念用于表示在聚合保留的情况下，端到端会话和聚合会话之间的单向依赖关系。在双向预约的情况下，用于表示用于正向预约和反向预约的会话之间的单向依赖关系。通常，会话绑定所指示的依赖关系本质上是纯信息性的，不会自动触发QNE中的任何隐式操作。QNE可以使用依赖关系信息进行本地资源优化或明确删除不再有用的保留。但是，通过使用显式绑定代码（见第5.1.3.4节），可以将此依赖关系形式化，这意味着如果绑定会话（例如，具有SID_B的会话）终止，则绑定会话（例如，具有SID_A的会话）也必须终止。
A message may include more than one BOUND-SESSION-ID object. This may happen, e.g., in certain aggregation and bidirectional reservation scenarios, where an end-to-end session has a unidirectional dependency relation with an aggregate session and at the same time it has a unidirectional dependency relation with another session used for the reverse path.
消息可能包含多个绑定会话ID对象。这可能发生，例如，在某些聚合和双向保留场景中，端到端会话与聚合会话具有单向依赖关系，同时它与用于反向路径的另一会话具有单向依赖关系。
QoS NSLP supports binding of messages in order to allow for expressing dependencies between different messages. The message binding can indicate either a unidirectional or bidirectional dependency relation between two messages by including the MSG-ID object in one message ("binding message") and the BOUND-MSG-ID object in the other message ("bound message"). The unidirectional dependency means that only RESERVE messages are bound to each other whereas a bidirectional dependency means that there is also a dependency for the related RESPONSE messages. The message binding can be used to speed up signaling by starting two signaling exchanges simultaneously that are synchronized later by using message IDs.
QoS NSLP支持消息绑定，以便表示不同消息之间的依赖关系。消息绑定可以通过在一条消息（“绑定消息”）中包含MSG-ID对象和在另一条消息（“绑定消息”）中包含BOUND-MSG-ID对象来指示两条消息之间的单向或双向依赖关系。单向依赖性意味着只有保留消息彼此绑定，而双向依赖性意味着相关响应消息也存在依赖性。消息绑定可用于通过同时启动两个信令交换来加速信令，这两个信令交换稍后通过使用消息ID进行同步。
This can be used as an optimization technique, for example, in scenarios where aggregate reservations are used. Section 4.6 provides more details.
这可以用作优化技术，例如，在使用聚合预订的场景中。第4.6节提供了更多细节。
The QoS NSLP supports layered reservations. Layered reservations may occur when certain parts of the network (domains) implement one or more local QoS models or when they locally apply specific transport characteristics (e.g., GIST unreliable transfer mode instead of reliable transfer mode). They may also occur when several per-flow reservations are locally combined into an aggregate reservation.
QoS NSLP支持分层保留。当网络（域）的某些部分实现一个或多个本地QoS模型时，或者当它们在本地应用特定传输特性（例如，不可靠传输模式而不是可靠传输模式）时，可能发生分层保留。当多个每流保留在本地合并为一个聚合保留时，也可能发生这种情况。
A domain may have local policies regarding QoS model implementation, i.e., it may map incoming traffic to its own locally defined QoS models. The QSPEC allows this functionality, and the operation is transparent to the QoS NSLP. The use of local QoS models within a domain is performed in the RMF.
域可以具有关于QoS模型实现的本地策略，即，它可以将传入流量映射到其自己的本地定义的QoS模型。QSPEC允许此功能，并且操作对QoS NSLP是透明的。域内本地QoS模型的使用在RMF中执行。
The way signaling messages are handled is mainly determined by the parameters that are sent over the GIST-NSLP API and by the domain internal configuration. A domain may have a policy to implement local transport behavior. It may, for instance, elect to use an unreliable transport locally in the domain while still keeping end-to-end reliability intact.
处理信令消息的方式主要取决于通过GIST-NSLP API发送的参数和域内部配置。域可能具有实现本地传输行为的策略。例如，它可以选择在域中本地使用不可靠的传输，同时仍然保持端到端的可靠性不变。
The QoS NSLP supports this situation by allowing two sessions to be set up for the same reservation. The local session has the desired local transport properties and is interpreted in internal QNEs. This solution poses two requirements: the end-to-end session must be able to bypass intermediate nodes, and the egress QNE needs to bind both sessions together. Bypassing intermediate nodes is achieved with GIST. The local session and the end-to-end session are bound at the egress QNE by means of the BOUND-SESSION-ID object.
QoS NSLP通过允许为同一预约设置两个会话来支持这种情况。本地会话具有所需的本地传输属性，并在内部QNE中进行解释。该解决方案提出了两个要求：端到端会话必须能够绕过中间节点，出口QNE需要将两个会话绑定在一起。通过GIST可以绕过中间节点。本地会话和端到端会话通过绑定会话ID对象在出口QNE处绑定。
In some cases, it is desirable to create reservations for an aggregate, rather than on a per-flow basis, in order to reduce the amount of reservation state needed as well as the processing load for signaling messages. Note that the QoS NSLP does not specify how reservations need to be combined in an aggregate or how end-to-end properties need to be computed, but only provides signaling support for aggregate reservations.
在某些情况下，为了减少所需的保留状态量以及信令消息的处理负载，希望为聚合而不是基于每个流创建保留。请注意，QoS NSLP没有指定需要如何在聚合中组合保留，或者需要如何计算端到端属性，但只提供聚合保留的信令支持。
The essential difference with the layering approaches described in Sections 3.2.10.1 and 3.2.10.2 is that the aggregate reservation needs a MRI that describes all traffic carried in the aggregate (e.g., a DSCP in case of IntServ over Diffserv). The need for a different MRI mandates the use of two different sessions, as described in Section 3.2.10.2 and in the RSVP aggregation solution in RFC 3175 [RFC3175].
与第3.2.10.1节和第3.2.10.2节中描述的分层方法的本质区别在于，聚合预订需要一个描述聚合中承载的所有流量的MRI（例如，在IntServ优于Diffserv的情况下为DSCP）。如第3.2.10.2节和RFC 3175[RFC3175]中的RSVP聚合解决方案所述，不同MRI的需要要求使用两个不同的会话。
Edge QNEs of the aggregation domain that want to maintain some end-to-end properties may establish a peering relation by sending the end-to-end message transparently over the domain (using the intermediate node bypass capability described above). Updating the end-to-end properties in this message may require some knowledge of the aggregated session (e.g., for updating delay values). For this purpose, the end-to-end session contains a BOUND-SESSION-ID carrying the SESSION-ID of the aggregate session.
希望维护某些端到端属性的聚合域的边缘QNE可以通过在域上透明地发送端到端消息（使用上述中间节点旁路功能）来建立对等关系。更新此消息中的端到端属性可能需要一些聚合会话的知识（例如，用于更新延迟值）。为此，端到端会话包含一个绑定会话ID，其中包含聚合会话的会话ID。
This specification acknowledges the fact that in some situations, some messages or reservations may be more important than others, and therefore it foresees mechanisms to give these messages or reservations priority.
本规范承认，在某些情况下，某些消息或保留可能比其他消息或保留更重要，因此它预见了赋予这些消息或保留优先级的机制。
Priority of certain signaling messages over others may be required in mobile scenarios when a message loss during call setup is less harmful than during handover. This situation only occurs when GIST or QoS NSLP processing is the congested part or scarce resource.
当呼叫建立过程中的消息丢失比切换过程中的消息丢失危害小时，移动场景中可能需要某些信令消息优先于其他信令消息。只有当GIST或QoS NSLP处理是拥塞部分或稀缺资源时，才会出现这种情况。
Priority of certain reservations over others may be required when QoS resources are oversubscribed. In that case, existing reservations may be preempted in order to make room for new higher-priority reservations. A typical approach to deal with priority and preemption is through the specification of a setup priority and holding priority for each reservation. The Resource Management Function at each QNE then keeps track of the resource consumption at each priority level. Reservations are established when resources, at their setup priority level, are still available. They may cause preemption of reservations with a lower holding priority than their setup priority.
当QoS资源被超额订阅时，可能需要某些预订优先于其他预订。在这种情况下，现有的预订可能会被抢占，以便为新的更高优先级的预订腾出空间。处理优先级和抢占的典型方法是通过为每个保留指定设置优先级和保持优先级。然后，每个QNE的资源管理功能跟踪每个优先级的资源消耗。当具有设置优先级的资源仍然可用时，将建立预订。它们可能会导致保留优先权低于其设置优先权。
Support of reservation priority is a QSPEC parameter and therefore outside the scope of this specification. The GIST specification provides a mechanism to support a number of levels of message priority that can be requested over the NSLP-GIST API.
保留优先级的支持是QSPEC参数，因此不在本规范的范围内。GIST规范提供了一种机制来支持可通过NSLP-GIST API请求的多个级别的消息优先级。
The QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, create a QoS reservation on the new path, and optionally tear down reservations on the old path.
QoS NSLP需要适应数据路径中的路由更改。这假定能够检测重路由事件，在新路径上创建QoS保留，并可以选择删除旧路径上的保留。
From an NSLP perspective, rerouting detection can be performed in two ways. It can either come through NetworkNotification from GIST, or from information seen at the NSLP. In the latter case, the QoS NSLP node is able to detect changes in its QoS NSLP peers by keeping track of a Source Identification Information (SII) handle that provides information similar in nature to the RSVP_HOP object described in RFC 2205 [RFC2205]. When a RESERVE message with an existing SESSION-ID and a different SII is received, the QNE knows its upstream or downstream peer has changed, for sender-oriented and receiver-oriented reservations, respectively.
从NSLP的角度来看，可以通过两种方式执行重路由检测。它可以来自GIST的网络通知，也可以来自NSLP上看到的信息。在后一种情况下，QoS NSLP节点能够通过跟踪提供与RFC 2205[RFC2205]中描述的RSVP_-HOP对象性质类似的信息的源标识信息（SII）句柄来检测其QoS NSLP对等中的变化。当接收到具有现有会话ID和不同SII的保留消息时，QNE知道其上游或下游对等方已分别针对面向发送方和面向接收方的保留进行了更改。
Reservation on the new path happens when a RESERVE message arrives at the QNE beyond the point where the old and new paths diverge. If the QoS NSLP suspects that a reroute has occurred, then a full RESERVE message (including the QSPEC) would be sent. A refreshing RESERVE (with no QSPEC) will be identified as an error by a QNE on the new path, which does not have the reservation installed (i.e., it was not on the old path) or which previously had a different previous-hop QNE. It will send back an error message that results in a full RESERVE message being sent. Rapid recovery at the NSLP layer therefore requires short refresh periods. Detection before the next RESERVE message arrives is only possible at the IP layer or through monitoring of GIST peering relations (e.g., by monitoring the Time to Live (TTL), i.e., the number of GIST hops between NSLP peers, or observing the changes in the outgoing interface towards GIST peer). These mechanisms can provide implementation-specific optimizations and are outside the scope of this specification.
当保留消息到达QNE时，新路径上的保留发生在旧路径和新路径分开的点之外。如果QoS NSLP怀疑发生了重新路由，则将发送完整保留消息（包括QSPEC）。刷新保留（没有QSPEC）将被新路径上的QNE识别为错误，该路径没有安装保留（即，它不在旧路径上）或以前有不同的前一跳QNE。它将发回一条错误消息，导致发送完全保留消息。因此，NSLP层的快速恢复需要较短的刷新周期。只有在IP层或通过监测GIST对等关系（例如，通过监测生存时间（TTL），即NSLP对等点之间GIST跳跃的数量，或观察传出接口对GIST对等点的变化），才能在下一个保留消息到达之前进行检测。这些机制可以提供特定于实现的优化，不在本规范的范围之内。
When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by sending a new RESERVE message. If the next QNE is in fact unchanged, then this will be used to refresh/update the existing reservation. Otherwise, it will lead to the reservation being installed on the new path.
当QoS NSLP知道路由更改时，它需要在新路径上设置保留。这是通过发送新的保留消息来完成的。如果下一个QNE事实上没有改变，那么这将用于刷新/更新现有保留。否则，将导致保留安装在新路径上。
Note that the operation for a receiver-initiated reservation session differs a bit from the above description. If the routing changes in the middle of the path, at some point (i.e., the divergence point) the QNE that notices that its downstream path has changed (indicated by a NetworkNotification from GIST), and it must send a QUERY with the R-flag downstream. The QUERY will be processed as above, and at some point hits a QNE for which the path downstream towards the QNI
注意，接收器发起的保留会话的操作与上述描述稍有不同。如果路由在路径中间改变，在某个点（即发散点），注意到其下游路径的QNE已经改变（由GIST的NETWORK通知通知），并且它必须向下游发送带有R-标志的查询。查询将如上所述进行处理，并在某个点到达一个QNE，该QNE的下游路径指向QNI
remains (i.e., the convergence point). This node must then send a full RESERVE upstream to set up the reservation state along the new path. It should not send the QUERY further downstream, since this would have no real use. Similarly, when the QNE that sent the QUERY receives the RESERVE, it should not send the RESERVE further upstream.
保持不变（即，收敛点）。然后，该节点必须向上游发送完全保留，以沿新路径设置保留状态。它不应该将查询发送到更远的下游，因为这样做没有实际用途。类似地，当发送查询的QNE接收到保留时，它不应该将保留发送到更远的上游。
After the reservation on the new path is set up, the branching node may want to tear down the reservation on the old path (sooner than would result from normal soft-state timeout). This functionality is supported by keeping track of the old SII-Handle provided over the GIST API. This handle can be used by the QoS NSLP to route messages explicitly to the next node.
在新路径上设置保留后，分支节点可能希望取消旧路径上的保留（比正常软状态超时所导致的时间要早）。通过跟踪GIST API上提供的旧SII句柄来支持此功能。QoS NSLP可以使用此句柄将消息显式路由到下一个节点。
If the old path is downstream, the QNE can send a tearing RESERVE using the old SII-Handle. If the old path is upstream, the QNE can send a NOTIFY with the code for "Route Change". This is forwarded upstream until it hits a QNE that can issue a tearing RESERVE downstream. A separate document discusses in detail the effect of mobility on the QoS NSLP signaling [NSIS-MOB].
如果旧路径在下游，QNE可以使用旧SII句柄发送撕裂保留。如果旧路径在上游，QNE可以发送带有“路由更改”代码的通知。这被转发到上游，直到它到达可以向下游发出撕裂保留的QNE。另一份文件详细讨论了移动性对QoS NSLP信令[NSIS-MOB]的影响。
A QNI or a branch node may wish to keep the reservation on the old branch. For instance, this could be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. For this purpose, a REPLACE flag is provided in the QoS NSLP common header, which, when not set, indicates that the reservation on the old branch should be kept.
QNI或分支节点可能希望保留旧分支上的保留。例如，当移动节点经历了移动事件并且希望保留对其旧连接点的保留以防其移动回到那里时，可能会出现这种情况。为此，QoS NSLP公共头中提供了一个替换标志，如果未设置该标志，则表示应保留旧分支上的保留。
Note that keeping old reservations affects the resources available to other nodes. Thus, the operator of the access network must make the final decision on whether this behavior is allowed. Also, the QNEs in the access network may add this flag even if the mobile node has not used the flag initially.
请注意，保留旧保留会影响其他节点可用的资源。因此，接入网络的运营商必须最终决定是否允许这种行为。此外，即使移动节点最初没有使用该标志，接入网络中的qne也可以添加该标志。
The latency in detecting that a new downstream peer exists or that truncation has happened depends on GIST. The default QUERY message transmission interval is 30 seconds. More details on how NSLPs are able to affect the discovery of new peers or rerouting can be found in the GIST specification.
检测新的下游对等点存在或截断发生的延迟取决于GIST。默认查询消息传输间隔为30秒。有关NSLP如何影响新对等点发现或重路由的更多详细信息，请参见GIST规范。
The design of the QoS NSLP allows reservations to be installed at a subset of the nodes along a path. In particular, usage scenarios include cases where the data flow endpoints do not support the QoS NSLP.
QoS NSLP的设计允许在路径上的节点子集上安装预订。特别是，使用场景包括数据流端点不支持QoS NSLP的情况。
In the case where the data flow receiver does not support the QoS NSLP, some particular considerations must be given to node discovery and rerouting at the end of the signaling path.
在数据流接收器不支持QoS NSLP的情况下，必须对信令路径末端的节点发现和重新路由给予一些特殊考虑。
There are three cases for the last node on the signaling path:
信令路径上的最后一个节点有三种情况：
1) the last node is the data receiver,
1) 最后一个节点是数据接收器，
2) the last node is a configured proxy for the data receiver, or
2) 最后一个节点是为数据接收器配置的代理，或
3) the last node is not the data receiver and is not explicitly configured to act as a signaling proxy on behalf of the data receiver.
3) 最后一个节点不是数据接收器，并且未明确配置为代表数据接收器充当信令代理。
Cases (1) and (2) can be handled by the QoS NSLP itself during the initial path setup, since the QNE knows that it should terminate the signaling. Case (3) requires some assistance from GIST, which provides messages across the API to indicate that no further GIST nodes that support QoS NSLP are present downstream, and that probing of the downstream route change needs to continue once the reservation is installed to detect any changes in this situation.
情况（1）和（2）可以在初始路径设置期间由QoS NSLP本身处理，因为QNE知道它应该终止信令。案例（3）需要GIST的一些帮助，GIST通过API提供消息，指示下游不存在支持QoS NSLP的GIST节点，并且一旦安装了预留，需要继续探测下游路由更改，以检测这种情况下的任何更改。
Two particular scenarios need to be considered in this third case. In the first, referred to as "Path Extension", rerouting occurs such that an additional QNE is inserted into the signaling path between the old last node and the data receiver, as shown in Figure 4.
在第三种情况下，需要考虑两种特殊情况。在被称为“路径扩展”的第一种情况下，发生重路由，使得在旧的最后一个节点和数据接收器之间的信令路径中插入额外的QNE，如图4所示。
/-------\ Initial route
/ v
/-\
/--|B|--\ +-+
/ \-/ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ +-+ / |x| = QoS NSLP unaware
\--|C|--/ \-/
+-+
\ ^
\-------/ Updated route
/-------\ Initial route
/ v
/-\
/--|B|--\ +-+
/ \-/ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ +-+ / |x| = QoS NSLP unaware
\--|C|--/ \-/
+-+
\ ^
\-------/ Updated route
Figure 4: Path Extension
图4：路径扩展
When rerouting occurs, the data path changes from A-B-D to A-C-D. Initially the signaling path ends at A. Despite initially being the last node, node A needs to continue to attempt to send messages downstream to probe for path changes, unless it has been explicitly
当发生重新路由时，数据路径从A-B-D更改为A-C-D。最初，信令路径终止于A。尽管最初是最后一个节点，但节点A需要继续尝试向下游发送消息以探测路径更改，除非已明确指定
configured as a signaling proxy for the data flow receiver. This is required so that the signaling path change is detected, and C will become the new last QNE.
配置为数据流接收器的信令代理。这是必需的，以便检测到信令路径变化，并且C将成为新的最后一个QNE。
In a second case, referred to as "Path Truncation", rerouting occurs such that the QNE that was the last node on the signaling path is no longer on the data path. This is shown in Figure 5.
在第二种情况下，称为“路径截断”，发生重新路由，使得作为信令路径上最后一个节点的QNE不再位于数据路径上。这如图5所示。
/-------\ Initial route
/ v
+-+
/--|B|--\ +-+
/ +-+ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ /-\ / |x| = QoS NSLP unaware
\--|C|--/ \-/
\-/
\ ^
\-------/ Updated route
/-------\ Initial route
/ v
+-+
/--|B|--\ +-+
/ +-+ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ /-\ / |x| = QoS NSLP unaware
\--|C|--/ \-/
\-/
\ ^
\-------/ Updated route
Figure 5: Path Truncation
图5：路径截断
When rerouting occurs, the data path again changes from A-B-D to A-C-D. The signaling path initially ends at B, but this node is not on the new path. In this case, the normal GIST path change detection procedures at A will detect the path change and notify the QoS NSLP. GIST will also notify the signaling application that no downstream GIST nodes supporting the QoS NSLP are present. Node A will take over as the last node on the signaling path.
当发生重新路由时，数据路径再次从A-B-D更改为A-C-D。信令路径最初结束于B，但该节点不在新路径上。在这种情况下，A处的正常GIST路径改变检测过程将检测路径改变并通知QoS NSLP。GIST还将通知信令应用程序不存在支持QoS NSLP的下游GIST节点。节点A将作为信令路径上的最后一个节点接管。
The QoS NSLP is notified by GIST (with the NetworkNotification primitive) when GIST believes that a rerouting event may have occurred. In some cases, events that are detected as possible route changes will turn out not to be. The QoS NSLP will not always be able to detect this, even after receiving messages from the 'new' peer.
当GIST认为可能发生了重路由事件时，由GIST（使用NetworkNotification原语）通知QoS NSLP。在某些情况下，被检测为可能的路线更改的事件将被证明不是。QoS NSLP并不总是能够检测到这一点，即使在从“新”对等方接收消息之后也是如此。
As part of the RecvMessage API primitive, GIST provides an SII-Handle that can be used by the NSLP to direct a signaling message to a particular peer. The current SII-Handle will change if the signaling peer changes. However, it is not guaranteed to remain the same after a rerouting event where the peer does not change. Therefore, the QoS NSLP mechanism for reservation maintenance after a route change
作为RecvMessage API原语的一部分，GIST提供了一个SII句柄，NSLP可以使用该句柄将信令消息定向到特定的对等方。如果信令对等更改，当前SII句柄将更改。但是，不能保证在对等方未更改的重路由事件后保持不变。因此，QoS NSLP机制用于路由更改后的保留维护
includes robustness mechanisms to avoid accidentally tearing down a reservation in situations where the peer QNE has remained the same after a 'route change' notification from GIST.
包括健壮性机制，以避免在GIST发出“路由更改”通知后对等QNE保持不变的情况下意外删除保留。
A simple example that illustrates the problem is shown in Figure 6 below.
下面的图6显示了一个简单的例子，说明了这个问题。
(1) +-+
/-----\ |x| = QoS NSLP aware
+-+ /-\ (3) +-+ +-+
----|A| |B|-----|C|----
+-+ \-/ +-+ /-\
\-----/ |x| = QoS NSLP unaware
(2) \-/
(1) +-+
/-----\ |x| = QoS NSLP aware
+-+ /-\ (3) +-+ +-+
----|A| |B|-----|C|----
+-+ \-/ +-+ /-\
\-----/ |x| = QoS NSLP unaware
(2) \-/
Figure 6: Spurious Reroute Alerting
图6：虚假重路由警报
In this example, the initial route A-B-C uses links (1) and (3). After link (1) fails, the path is rerouted using links (2) and (3). The set of QNEs along the path is unchanged (it is A-C in both cases, since B does not support the QoS NSLP).
在此示例中，初始路由A-B-C使用链路（1）和（3）。链路（1）失败后，使用链路（2）和（3）重新路由路径。路径上的QNE集保持不变（这两种情况下都是A-C，因为B不支持QoS NSLP）。
When the outgoing interface at A has changes, GIST may signal across its API to the NSLP with a NetworkNotification. The QoS NSLP at A will then attempt to repair the path by installing the reservation on the path (2),(3). In this case, however, the old and new paths are the same.
当A处的传出接口发生更改时，GIST可能会通过其API向NSLP发送网络通知。然后，A处的QoS NSLP将尝试通过在路径（2）、（3）上安装保留来修复路径。但是，在这种情况下，旧路径和新路径是相同的。
To install the new reservation, A will send a RESERVE message, which GIST will transport to C (discovering the new next peer as appropriate). The RESERVE also requests a RESPONSE from the QNR. When this RESERVE message is received through the RecvMessage API call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged from its previous communications from A.
要安装新的保留，A将发送一条保留消息，GIST将该消息传输到C（根据需要发现新的下一个对等方）。保留区还请求QNR作出响应。当通过RecvMessage API调用从C处的QoS NSLP处的GIST接收到此保留消息时，SII句柄将与其以前从A处的通信保持不变。
A RESPONSE message will be sent by the QNR, and be forwarded from C to A. This confirms that the reservation was installed on the new path. The SII-Handle passed with the RecvMessage call from GIST to the QoS NSLP will be different to that seen previously, since the interface being used on A has changed.
QNR将发送一条响应消息，并将其从C转发到A。这将确认保留已安装在新路径上。从GIST到QoS NSLP的RecVMMessage调用传递的SII句柄将与前面看到的不同，因为在上使用的接口已更改。
At this point, A can attempt to tear down the reservation on the old path. The RESERVE message with the TEAR flag set is sent down the old path by using the GIST explicit routing mechanism and specifying the SII-Handle relating to the 'old' peer QNE.
此时，A可以尝试在旧路径上删除保留。通过使用GIST显式路由机制并指定与“旧”对等QNE相关的SII句柄，设置了撕裂标志的保留消息沿着旧路径发送。
If RSNs were being incremented for each of these RESERVE and RESERVE-with-TEAR messages, the reservation would be torn down at C and any QNEs further along the path. To avoid this, the RSN is used in a special way. The RESERVE down the new path is sent with the new current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down the old path is sent with an RSN set to the new current RSN minus 1. This is the peer from which it was receiving RESERVE messages (see for more details).
如果这些保留和带有撕裂消息的保留中的每一个都增加了RSN，那么保留将在C和路径上更远的任何QNE处被拆除。为了避免这种情况，以一种特殊的方式使用RSN。新路径下的保留发送时，新的当前RSN设置为旧RSN加2。删除旧路径的保留发送时，RSN设置为新的当前RSN减去1。这是它从中接收保留消息的对等方（有关更多详细信息，请参阅）。
The QoS NSLP provides building blocks to implement preemption. This specification does not define how preemption should work, but only provides signaling mechanisms that can be used by QoS models. For example, an INFO-SPEC object can be added to messages to indicate that the signaled session was preempted. A BOUND-SESSION-ID object can carry the Session ID of the flow that caused the preemption of the signaled session. How these are used by QoS models is out of scope of the QoS NSLP specification.
QoS NSLP提供了实现抢占的构建块。该规范没有定义抢占应该如何工作，但只提供了QoS模型可以使用的信令机制。例如，可以将INFO-SPEC对象添加到消息中，以指示已抢占已发信号的会话。绑定会话ID对象可以携带导致信号会话抢占的流的会话ID。QoS模型如何使用这些不在QoS NSLP规范的范围之内。
The QoS NSLP uses GIST for delivery of all its messages. Messages are passed from the NSLP to GIST via an API (defined in Appendix B of [RFC5971]), which also specifies additional information, including an identifier for the signaling application (e.g., 'QoS NSLP'), session identifier, MRI, and an indication of the intended direction (towards data sender or receiver). On reception, GIST provides the same information to the QoS NSLP. In addition to the NSLP message data itself, other meta-data (e.g., session identifier and MRI) can be transferred across this interface.
QoS NSLP使用GIST传递其所有消息。消息通过API（在[RFC5971]的附录B中定义）从NSLP传递到GIST，该API还指定了附加信息，包括信令应用的标识符（例如，“QoS NSLP”）、会话标识符、MRI以及预期方向的指示（朝向数据发送方或接收方）。在接收时，GIST向QoS NSLP提供相同的信息。除了NSLP消息数据本身之外，其他元数据（如会话标识符和MRI）也可以通过该接口传输。
The QoS NSLP keeps message and reservation state per session. A session is identified by a Session Identifier (SESSION-ID). The SESSION-ID is the primary index for stored NSLP state and needs to be constant and unique (with a sufficiently high probability) along a path through the network. The QoS NSLP picks a value for Session-ID.
QoS NSLP保留每个会话的消息和保留状态。会话由会话标识符（session-ID）标识。SESSION-ID是存储的NSLP状态的主要索引，需要在网络路径上保持恒定和唯一（具有足够高的概率）。QoS NSLP为Session-ID选择一个值。
This value is subsequently used by GIST and the QoS NSLP to refer to this session.
GIST和QoS NSLP随后使用该值来引用该会话。
Currently, the QoS NSLP specification considers mainly the path-coupled MRM. However, extensions may specify how other types of MRMs may be applied in combination with the QoS NSLP.
目前，QoS NSLP规范主要考虑路径耦合的MRM。然而，扩展可以指定如何结合QoS NSLP应用其他类型的MRM。
When GIST passes the QoS NSLP data to the NSLP for processing, it must also indicate the value of the 'D' (Direction) flag for that message in the MRI.
当GIST将QoS NSLP数据传递给NSLP进行处理时，它还必须指示MRI中该消息的“D”（方向）标志的值。
The QoS NSLP does not provide any method of interacting with firewalls or Network Address Translators (NATs). It assumes that a basic NAT traversal service is provided by GIST.
QoS NSLP不提供任何与防火墙或网络地址转换器（NAT）交互的方法。它假定GIST提供基本的NAT穿越服务。
The QoS NSLP may want to restrict the handling of its messages to specific nodes. This functionality is needed to support layering (explained in Section 3.2.10), when only the edge QNEs of a domain process the message. This requires a mechanism at the GIST level (which can be invoked by the QoS NSLP) to bypass intermediate nodes between the edges of the domain.
QoS NSLP可能希望将其消息的处理限制到特定节点。当只有域的边缘QNE处理消息时，需要此功能来支持分层（在第3.2.10节中解释）。这需要GIST级别的机制（可由QoS NSLP调用）绕过域边缘之间的中间节点。
The intermediate nodes are bypassed using multiple levels of the router alert option. In that case, internal routers are configured to handle only certain levels of router alerts. This is accomplished by marking this message at the ingress, i.e., modifying the QoS NSLP default NSLPID value to an NSLPID predefined value (see Section 6.6). The egress stops this marking process by reassigning the QoS NSLP default NSLPID value to the original RESERVE message. The exact operation of modifying the NSLPID must be specified in the relevant QoS model specification.
使用多级路由器警报选项绕过中间节点。在这种情况下，内部路由器配置为仅处理特定级别的路由器警报。这是通过在入口标记此消息来实现的，即将QoS NSLP默认NSLPID值修改为NSLPID预定义值（参见第6.6节）。出口通过将QoS NSLP default NSLPID值重新分配给原始保留消息来停止此标记过程。修改NSLPID的确切操作必须在相关QoS模型规范中指定。
There are several circumstances where it is necessary for a QNE to identify the adjacent QNE peer, which is the source of a signaling application message. For example, it may be to apply the policy that "state can only be modified by messages from the node that created it" or it might be that keeping track of peer identity is used as a (fallback) mechanism for rerouting detection at the NSLP layer.
在几种情况下，QNE必须识别相邻的QNE对等方，该对等方是信令应用消息的源。例如，可以应用“状态只能由创建它的节点的消息修改”的策略，也可以将跟踪对等身份用作在NSLP层重新路由检测的（回退）机制。
This functionality is implemented in the GIST service interface with SII-handle. As shown in the above example, we assume the SII-handling will support both its own SII and its peer's SII.
此功能通过SII句柄在GIST服务接口中实现。如上面的示例所示，我们假设SII处理将同时支持其自身的SII和对等的SII。
Keeping track of the SII of a certain reservation also provides a means for the QoS NSLP to detect route changes. When a QNE receives a RESERVE referring to existing state but with a different SII, it knows that its upstream peer has changed. It can then use the old SII to initiate a teardown along the old section of the path. This functionality is supported in the GIST service interface when the peer's SII (which is stored on message reception) is passed to GIST upon message transmission.
跟踪特定保留的SII也为QoS NSLP检测路由更改提供了一种方法。当QNE接收到一个参考现有状态但具有不同SII的保留时，它知道其上游对等方已经改变。然后，它可以使用旧的SII沿路径的旧部分启动拆卸。当对等方的SII（存储在消息接收时）在消息传输时传递给GIST时，GIST服务接口支持此功能。
Stateless or reduced-state QoS NSLP operation makes the most sense when some nodes are able to operate in a stateless way at the GIST level as well. Such nodes should not worry about keeping reverse state, message fragmentation and reassembly (at GIST), congestion control, or security associations. A stateless or reduced-state QNE will be able to inform the underlying GIST of this situation. GIST service interface supports this functionality with the Retain-State attribute in the MessageReceived primitive.
当一些节点能够在GIST级别以无状态方式操作时，无状态或简化状态QoS NSLP操作最有意义。这样的节点不应该担心保持反向状态、消息碎片和重组（按要点）、拥塞控制或安全关联。无状态或简化状态QNE将能够告知这种情况的基本要点。GIST服务接口通过MessageReceived原语中的Retain State属性支持此功能。
The QoS NSLP will generate messages with a range of performance requirements for GIST. These requirements may result from a prioritization at the QoS NSLP (Section 3.2.11) or from the responsiveness expected by certain applications supported by the QoS NSLP. GIST service interface supports this with the 'priority' transfer attribute.
QoS NSLP将为GIST生成具有一系列性能要求的消息。这些要求可能源于QoS NSLP（第3.2.11节）的优先级划分或QoS NSLP支持的某些应用程序预期的响应性。GIST服务接口支持“优先级”传输属性。
In some cases, it is useful to know that there are routers along the path where QoS cannot be provided. The GIST service interface supports this by keeping track of IP-TTL and Original-TTL in the RecvMessage primitive. A difference between the two indicates the number of QoS-NSLP-unaware nodes. In this case, the QNE that detects this difference should set the "B" (BREAK) flag. If a QNE receives a QUERY or RESERVE message with the BREAK flag set, and then generates a QUERY, RESERVE, or RESPONSE message, it can set the BREAK flag in those messages. There are however, situations where the egress QNE in a local domain may have some other means to provide QoS [RFC5975]. For example, in a local domain that is aware of RMD-QOSM [RFC5977] (or a similar QoS Model) and that uses either NTLP stateless nodes or NSIS-unaware nodes, the end-to-end RESERVE or QUERY message bypasses these NTLP stateless or NSIS-unaware nodes. However, the reservation within the local domain can be signaled by the RMD-QOSM (or a similar QoS Model). In such situations, the "B" (BREAK) flag in the end-to-end RESERVE or QUERY message should not be set by the edges of the local domain.
在某些情况下，知道路径上存在无法提供QoS的路由器是很有用的。GIST服务接口通过跟踪RecVMMessage原语中的IP-TTL和原始TTL来支持这一点。两者之间的差异表示QoS NSLP不知道节点的数量。在这种情况下，检测到此差异的QNE应设置“B”（中断）标志。如果QNE接收到设置了中断标志的查询或保留消息，然后生成查询、保留或响应消息，则可以在这些消息中设置中断标志。然而，存在这样的情况，本地域中的出口QNE可以具有一些其他方式来提供QoS[RFC5975]。例如，在知道RMD-QOSM[RFC5977]（或类似QoS模型）并且使用NTLP无状态节点或NSIS无意识节点的本地域中，端到端保留或查询消息绕过这些NTLP无状态或NSIS无意识节点。然而，本地域内的保留可以由RMD-QOSM（或类似的QoS模型）发出信号。在这种情况下，端到端保留或查询消息中的“B”（中断）标志不应由本地域的边缘设置。
The QoS NSLP can be used in a number of ways. The examples here give an indication of some of the basic processing. However, they are not exhaustive and do not attempt to cover the details of the protocol processing.
QoS NSLP可以以多种方式使用。这里的示例说明了一些基本处理。但是，它们并非详尽无遗，也不试图涵盖协议处理的细节。
QNI QNE QNE QNR
| | | |
| RESERVE | | |
+--------->| | |
| | RESERVE | |
| +--------->| |
| | | RESERVE |
| | +--------->|
| | | |
| | | RESPONSE |
| | |<---------+
| | RESPONSE | |
| |<---------+ |
| RESPONSE | | |
|<---------+ | |
| | | |
| | | |
QNI QNE QNE QNR
| | | |
| RESERVE | | |
+--------->| | |
| | RESERVE | |
| +--------->| |
| | | RESERVE |
| | +--------->|
| | | |
| | | RESPONSE |
| | |<---------+
| | RESPONSE | |
| |<---------+ |
| RESPONSE | | |
|<---------+ | |
| | | |
| | | |
Figure 7: Basic Sender-Initiated Reservation
图7：基本发送者发起的预订
To make a new reservation, the QNI constructs a RESERVE message containing a QSPEC object, from its chosen QoS model, that describes the required QoS parameters.
为了进行新的预订，QNI根据其选择的QoS模型构造一个包含QSPEC对象的预订消息，该消息描述了所需的QoS参数。
The RESERVE message is passed to GIST, which transports it to the next QNE. There, it is delivered to the QoS NSLP processing, which examines the message. Policy control and admission control decisions are made. The exact processing also takes into account the QoS model being used. The node performs appropriate actions (e.g., installing the reservation) based on the QSPEC object in the message.
保留消息被传递给GIST，GIST将其传输到下一个QNE。在那里，它被传递到QoS NSLP处理，后者检查消息。进行策略控制和接纳控制决策。精确处理还考虑了所使用的QoS模型。节点根据消息中的QSPEC对象执行适当的操作（例如，安装保留）。
The QoS NSLP then generates a new RESERVE message (usually based on the one received). This is passed to GIST, which forwards it to the next QNE.
QoS NSLP然后生成新的保留消息（通常基于接收到的消息）。这将传递给GIST，GIST将其转发给下一个QNE。
The same processing is performed at further QNEs along the path, up to the QNR. The determination that a node is the QNR may be made directly (e.g., that node is the destination for the data flow), or using GIST functionality to determine that there are no more QNEs between this node and the data flow destination.
在沿着路径到QNR的其他qne处执行相同的处理。可以直接确定节点是QNR（例如，该节点是数据流的目的地），或者使用GIST功能确定该节点和数据流目的地之间没有更多的qne。
Any node may include a request for a RESPONSE in its RESERVE messages. It does so by including a Request Identification Information (RII) object in the RESERVE message. If the message already includes an RII, an interested QNE must not add a new RII object or replace the old RII object. Instead, it needs to remember
任何节点都可以在其保留消息中包含响应请求。它通过在保留消息中包含请求标识信息（RII）对象来实现。如果消息已经包含RII，感兴趣的QNE不得添加新的RII对象或替换旧的RII对象。相反，它需要记住
the RII value so that it can match a RESPONSE message belonging to the RESERVE. When it receives the RESPONSE, it forwards the RESPONSE upstream towards the RII originating node.
RII值，以便它可以匹配属于保留区的响应消息。当它接收到响应时，它将响应向上游转发到RII发起节点。
In this example, the RESPONSE message is forwarded peer-to-peer along the reverse of the path that the RESERVE message took (using GIST path state), and so is seen by all the QNEs on this segment of the path. It is only forwarded as far as the node that requested the RESPONSE originally.
在此示例中，响应消息沿保留消息所采用的路径的相反方向（使用GIST路径状态）以对等方式转发，因此该路径段上的所有QNE都可以看到。它只转发到最初请求响应的节点。
The reservation can subsequently be refreshed by sending further RESERVE messages containing the complete reservation information, as for the initial reservation. The reservation can also be modified in the same way, by changing the QSPEC data to indicate a different set of resources to reserve.
随后可以通过发送包含完整预约信息的进一步预约消息来刷新预约，就像初始预约一样。也可以通过同样的方式修改保留，方法是更改QSPEC数据以指示要保留的不同资源集。
The overhead required to perform refreshes can be reduced, in a similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a RESPONSE message has been received indicating the successful installation of a reservation, subsequent refreshing RESERVE messages can simply refer to the existing reservation, rather than including the complete reservation specification.
执行刷新所需的开销可以减少，方法与RFC 2961[RFC2961]中建议的RSVP类似。一旦接收到指示成功安装保留的响应消息，后续刷新保留消息可以简单地引用现有保留，而不包括完整的保留规范。
QUERY messages can be used to gather information from QNEs along the path. For example, they can be used to find out what resources are available before a reservation is made.
查询消息可用于沿路径从QNE收集信息。例如，在预订之前，可以使用它们找出可用的资源。
In order to perform a query along a path, the QNE constructs a QUERY message. This message includes a QSPEC containing the actual query to be performed at QNEs along the path. It also contains an RII object used to match the response back to the query, and an indicator of the query scope (next node, whole path, proxy). The QUERY message is passed to GIST to forward it along the path.
为了沿着路径执行查询，QNE构造查询消息。此消息包括一个QSPEC，其中包含沿路径在QNE上执行的实际查询。它还包含一个用于将响应匹配回查询的RII对象，以及查询范围的指示符（下一个节点、整个路径、代理）。查询消息被传递给GIST，以便沿着路径转发它。
A QNE receiving a QUERY message should inspect it and create a new message based on it, with the query objects modified as required. For example, the query may request information on whether a flow can be admitted, and so a node processing the query might record the available bandwidth. The new message is then passed to GIST for further forwarding (unless it knows it is the QNR or is the limit for the scope in the QUERY).
接收查询消息的QNE应检查该消息并基于该消息创建新消息，并根据需要修改查询对象。例如，查询可以请求关于是否可以接纳流的信息，因此处理查询的节点可以记录可用带宽。然后将新消息传递给GIST以进一步转发（除非它知道它是QNR或是查询中作用域的限制）。
At the QNR, a RESPONSE message must be generated if the QUERY message includes an RII object. Various objects from the received QUERY message have to be copied into the RESPONSE message. It is then passed to GIST to be forwarded peer-to-peer back along the path.
在QNR，如果查询消息包含RII对象，则必须生成响应消息。必须将收到的查询消息中的各种对象复制到响应消息中。然后将其传递给GIST，以便沿路径进行对等转发。
Each QNE receiving the RESPONSE message should inspect the RII object to see if it 'belongs' to it (i.e., it was the one that originally created it). If it does not, then it simply passes the message back to GIST to be forwarded upstream.
每个接收到响应消息的QNE都应该检查RII对象，看看它是否“属于”它（即，它是最初创建它的那个）。如果没有，那么它只是将消息传递回GIST，以便向上游转发。
If there was an error in processing a RESERVE, instead of an RII, the RESPONSE may carry an RSN. Thus, a QNE must also be prepared to look for an RSN object if no RII was present, and act based on the error code set in the INFO-SPEC of the RESPONSE.
如果在处理保留（而不是RII）时出错，则响应可能携带RSN。因此，如果不存在RII，QNE还必须准备查找RSN对象，并根据响应信息规范中设置的错误代码采取行动。
As described in the NSIS framework [RFC4080], in some signaling applications, a node at one end of the data flow takes responsibility for requesting special treatment -- such as a resource reservation -- from the network. Both ends then agree whether sender- or receiver-initiated reservation is to be done. In case of a receiver-initiated reservation, both ends agree whether a "One Pass With Advertising" (OPWA) [opwa95] model is being used. This negotiation can be accomplished using mechanisms that are outside the scope of NSIS.
如NSIS框架[RFC4080]中所述，在一些信令应用中，数据流一端的节点负责从网络请求特殊处理（如资源保留）。然后，双方同意是否进行发送方或接收方发起的预订。在接收方发起预订的情况下，双方同意是否使用“广告一通”（OPWA）[opwa95]模式。这种协商可以使用NSIS范围之外的机制来完成。
To make a receiver-initiated reservation, the QNR constructs a QUERY message, which MUST contain a QSPEC object from its chosen QoS model (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This QUERY message does not need to trigger a RESPONSE message and therefore, the QNI must not include the RII object (Section 5.4.2) in the QUERY message. The QUERY message may be used to gather information along the path, which is carried by the QSPEC object. An example of such information is the "One Pass With Advertising" (OPWA) model [opwa95]. This QUERY message causes GIST reverse-path state to be installed.
To make a receiver-initiated reservation, the QNR constructs a QUERY message, which MUST contain a QSPEC object from its chosen QoS model (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This QUERY message does not need to trigger a RESPONSE message and therefore, the QNI must not include the RII object (Section 5.4.2) in the QUERY message. The QUERY message may be used to gather information along the path, which is carried by the QSPEC object. An example of such information is the "One Pass With Advertising" (OPWA) model [opwa95]. This QUERY message causes GIST reverse-path state to be installed.translate error, please retry
QNR QNE QNE QNI
sender receiver
| | | |
| QUERY | | |
+--------->| | |
| | QUERY | |
| +--------->| |
| | | QUERY |
| | +--------->|
| | | |
| | | RESERVE |
| | |<---------+
| | RESERVE | |
| |<---------+ |
| RESERVE | | |
|<---------+ | |
| | | |
| RESPONSE | | |
+--------->| | |
| | RESPONSE | |
| +--------->| |
| | | RESPONSE |
| | +--------->|
| | | |
QNR QNE QNE QNI
sender receiver
| | | |
| QUERY | | |
+--------->| | |
| | QUERY | |
| +--------->| |
| | | QUERY |
| | +--------->|
| | | |
| | | RESERVE |
| | |<---------+
| | RESERVE | |
| |<---------+ |
| RESERVE | | |
|<---------+ | |
| | | |
| RESPONSE | | |
+--------->| | |
| | RESPONSE | |
| +--------->| |
| | | RESPONSE |
| | +--------->|
| | | |
Figure 8: Basic Receiver-Initiated Reservation
图8：基本接收方发起的预订
The QUERY message is transported by GIST to the next downstream QoS NSLP node. There, it is delivered to the QoS NSLP processing, which examines the message. The exact processing also takes into account the QoS model being used and may include gathering information on path characteristics that may be used to predict the end-to-end QoS.
查询消息通过GIST传输到下一个下游QoS NSLP节点。在那里，它被传递到QoS NSLP处理，后者检查消息。精确处理还考虑到所使用的QoS模型，并且可以包括收集关于可用于预测端到端QoS的路径特征的信息。
The QNE generates a new QUERY message (usually based on the one received). This is passed to GIST, which forwards it to the next QNE. The same processing is performed at further QNEs along the path, up to the flow receiver. The receiver detects that this QUERY message carries the RESERVE-INIT flag and by using the information contained in the received QUERY message, such as the QSPEC, constructs a RESERVE message.
QNE生成新的查询消息（通常基于接收到的查询消息）。这将传递给GIST，GIST将其转发给下一个QNE。在沿着路径的进一步QNE处执行相同的处理，直至流接收器。接收方检测到该查询消息携带RESERVE-INIT标志，并通过使用接收到的查询消息中包含的信息（如QSPEC）构造一条RESERVE消息。
The RESERVE is forwarded peer-to-peer along the reverse of the path that the QUERY message took (using GIST reverse-path state). Similar to the sender-initiated approach, any node may include an RII in its RESERVE messages. The RESPONSE is sent back to confirm that the resources are set up. The reservation can subsequently be refreshed with RESERVE messages in the upstream direction.
保留将沿着查询消息所采用的路径的反向（使用GIST反向路径状态）进行对等转发。与发送方发起的方法类似，任何节点都可以在其保留消息中包括RII。返回响应以确认资源已设置。随后可使用上游方向的保留消息刷新保留。
The term "bidirectional reservation" refers to two different cases that are supported by this specification:
术语“双向保留”指本规范支持的两种不同情况：
o Binding two sender-initiated reservations together, e.g., one sender-initiated reservation from QNE A to QNE B and another one from QNE B to QNE A (Figure 9).
o 将两个发送者发起的保留绑定在一起，例如，一个发送者发起从QNE A到QNE B的保留，另一个发送者发起从QNE B到QNE A的保留（图9）。
o Binding a sender-initiated and a receiver-initiated reservation together, e.g., a sender-initiated reservation from QNE A towards QNE B, and a receiver-initiated reservation from QNE A towards QNE B for the data flow in the opposite direction (from QNE B to QNE A). This case is particularly useful when one end of the communication has all required information to set up both sessions (Figure 10).
o 将发送方发起的保留和接收方发起的保留绑定在一起，例如，发送方发起的从QNE a到QNE B的保留，以及接收方发起的从QNE a到QNE B的针对相反方向（从QNE B到QNE a）数据流的保留。当通信的一端拥有设置两个会话所需的所有信息时，这种情况尤其有用（图10）。
Both ends have to agree on which bidirectional reservation type they need to use. This negotiation can be accomplished using mechanisms that are outside the scope of NSIS.
双方必须就需要使用哪种双向预订类型达成一致。这种协商可以使用NSIS范围之外的机制来完成。
The scenario with two sender-initiated reservations is shown in Figure 9. Note that RESERVE messages for both directions may visit different QNEs along the path because of asymmetric routing. Both directions of the flows are bound by inserting the BOUND-SESSION-ID object at the QNI and QNR. RESPONSE messages are optional and not shown in the picture for simplicity.
图9显示了具有两个发送者发起的预订的场景。请注意，由于非对称路由，双向保留消息可能会访问路径上的不同QNE。通过在QNI和QNR处插入bound-SESSION-ID对象来绑定流的两个方向。响应消息是可选的，为了简单起见，不在图片中显示。
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | |RESERVE-2 |
| RESERVE-2 |<---------+QNI
QNR|<--------------------+ |
| | | |
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | |RESERVE-2 |
| RESERVE-2 |<---------+QNI
QNR|<--------------------+ |
| | | |
Figure 9: Bidirectional Reservation for Sender+Sender Scenario
图9：发送方+发送方场景的双向预订
The scenario with a sender-initiated and a receiver-initiated reservation is shown in Figure 10. In this case, QNI A sends out two RESERVE messages, one for the sender-initiated and one for the receiver-initiated reservation. Note that the sequence of the two RESERVE messages may be interleaved.
图10显示了发送方发起和接收方发起保留的场景。在这种情况下，QNI A发送两条保留消息，一条用于发送方发起的保留，另一条用于接收方发起的保留。注意，两个保留消息的序列可以交错。
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | | QUERY-2 |
| | QUERY-2 |<---------+QNR
QNI|<--------------------+ |
| | | |
|RESERVE-2 | | |
QNI+--------->|RESERVE-2 | |
| +-------------------->|QNR
| | | |
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | | QUERY-2 |
| | QUERY-2 |<---------+QNR
QNI|<--------------------+ |
| | | |
|RESERVE-2 | | |
QNI+--------->|RESERVE-2 | |
| +-------------------->|QNR
| | | |
Figure 10: Bidirectional Reservation for Sender+Receiver Scenario
图10：发送方+接收方场景的双向预订
In order to reduce signaling and per-flow state in the network, the reservations for a number of flows may be aggregated.
为了减少网络中的信令和每流状态，可以聚合多个流的预留。
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | +=========>| RESERVE' | |
| | | +=========>| RESERVE |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | +=========>| RESERVE' | |
| | | +=========>| RESERVE |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
Figure 11: Sender-Initiated Reservation with Aggregation
图11：发送方发起的带有聚合的预订
An end-to-end per-flow reservation is initiated with the messages shown in Figure 11 as "RESERVE".
端到端的每流保留由图11中显示为“RESERVE”的消息启动。
At the aggregator, a reservation for the aggregated flow is initiated (shown in Figure 11 as "RESERVE'"). This may use the same QoS model as the end-to-end reservation but has an MRI identifying the aggregated flow (e.g., tunnel) instead of for the individual flows.
在聚合器上，启动对聚合流的保留（如图11所示为“保留”）。这可以使用与端到端预留相同的QoS模型，但是具有识别聚合流（例如隧道）而不是单个流的MRI。
This document does not specify how the QSPEC of the aggregate session can be derived from the QSPECs of the end-to-end sessions.
本文档未指定如何从端到端会话的QSPEC派生聚合会话的QSPEC。
The messages used for the signaling of the individual reservation need to be marked such that the intermediate routers will not inspect them. In the QoS NSLP, the following marking policy is applied; see also RFC 3175.
需要标记用于单个保留的信令的消息，以便中间路由器不会检查它们。在QoS NSLP中，应用以下标记策略：；另见RFC 3175。
All routers use essentially the same algorithm for which messages they process, i.e., all messages at aggregation level 0. However, messages have their aggregation level incremented on entry to an aggregation region and decremented on exit. In this technique, the interior routers are not required to do any rewriting of the RAO values. However, the aggregating/deaggregating routers must distinguish the interfaces and associated aggregation levels. These routers also perform message rewriting at these boundaries.
所有路由器使用基本相同的算法处理消息，即聚合级别为0的所有消息。但是，消息的聚合级别在进入聚合区域时增加，在退出时减少。在这种技术中，内部路由器不需要对RAO值进行任何重写。但是，聚合/反聚合路由器必须区分接口和相关聚合级别。这些路由器也在这些边界上执行消息重写。
In particular, the Aggregator performs the marking by modifying the QoS NSLP default NSLPID value to an NSLPID predefined value; see Section 6.6. A RAO value is then uniquely derivable from each predefined NSLPID. However, the RAO does not have to have a one-to-one relation to a specific NSLPID.
具体地，聚合器通过将QoS NSLP默认NSLPID值修改为NSLPID预定义值来执行标记；见第6.6节。然后，RAO值可从每个预定义的NSLPID唯一派生。但是，RAO不必与特定NSLPID有一对一的关系。
Aggregator Deaggregator
聚合器-解聚器
+---+ +---+ +---+ +---+
|QNI|-----|QNE|-----|QNE|-----|QNR| aggregate
+---+ +---+ +---+ +---+ reservation
+---+ +---+ +---+ +---+
|QNI|-----|QNE|-----|QNE|-----|QNR| aggregate
+---+ +---+ +---+ +---+ reservation
+---+ +---+ ..... ..... +---+ +---+
|QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end
+---+ +---+ ..... ..... +---+ +---+ reservation
+---+ +---+ ..... ..... +---+ +---+
|QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end
+---+ +---+ ..... ..... +---+ +---+ reservation
Figure 12: Reservation Aggregation
图12：预订汇总
The deaggregator acts as the QNR for the aggregate reservation. Session binding information carried in the RESERVE message enables the deaggregator to associate the end-to-end and aggregate reservations with one another (using the BOUND-SESSION-ID).
解聚集器充当聚集保留的QNR。RESERVE消息中携带的会话绑定信息使deaggregator能够将端到端和聚合保留相互关联（使用bind-Session-ID）。
The key difference between this example and the one shown in Section 4.7.1 is that the flow identifier for the aggregate is expected to be different to that for the end-to-end reservation. The aggregate reservation can be updated independently of the per-flow end-to-end reservations.
该示例与第4.7.1节所示示例之间的关键区别在于，聚合的流标识符预计与端到端预留的流标识符不同。聚合保留可以独立于每个流的端到端保留进行更新。
Section 4.5 sketches the interaction of an aggregated end-to-end flow and an aggregate. For this scenario, and probably others, it is useful to have a method for synchronizing the exchanges of signaling messages of different sessions. This can be used to speed up signaling, because some message exchanges can be started simultaneously and can be processed in parallel until further processing of a message from one particular session depends on
第4.5节概述了聚合端到端流和聚合的相互作用。对于这个场景，或者其他场景，有一种方法来同步不同会话的信令消息的交换是有用的。这可以用来加速信令，因为一些消息交换可以同时启动，并且可以并行处理，直到来自一个特定会话的消息的进一步处理取决于
another message from a different session. For instance, Figure 11 shows a case where inclusion of a new reservation requires that the capacity of the encompassing aggregate be increased first. So the RESERVE (bound message) for the individual flow arriving at the deaggregator should wait until the RESERVE' (binding message) for the aggregate arrived successfully (otherwise, the individual flow cannot be included in the existing aggregate and cannot be admitted). Another alternative would be to increase the aggregate first and then to reserve resources for a set of aggregated individual flows. In this case, the binding and synchronization between the (RESERVE and RESERVE') messages are not needed.
来自不同会话的另一条消息。例如，图11显示了一种情况，其中包含一个新的保留要求首先增加包含的聚合的容量。因此，到达解聚集器的单个流的RESERVE（绑定消息）应该等待聚合的RESERVE（绑定消息）成功到达（否则，单个流不能包含在现有聚合中，也不能被接纳）。另一种选择是先增加聚合，然后为一组聚合的单个流保留资源。在这种情况下，不需要（RESERVE和RESERVE'）消息之间的绑定和同步。
A message binding may be used (depending an the aggregators policy) as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a 128-bit MSG-ID (same rules apply as for generating a SESSION-ID) and includes it as BOUND-MSG-ID object into the bound signaling message (RESERVE (1) in Figure 13) that should wait for the arrival of a related binding signaling message (RESERVE' (3) in Figure 13) that carries the associated MSG-ID object. The BOUND-SESSION-ID should also be set accordingly. Only one MSG-ID or BOUND-MSG-ID object per message is allowed. If the dependency relation between the two messages is bidirectional, then the Message_Binding_Type flag is SET (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In most cases, an RII object must be included in order to get a corresponding RESPONSE back.
可以使用如下消息绑定（取决于聚合器策略）：QNE（图14中的聚合器QNI）随机生成128位MSG-ID（与生成会话ID的规则相同），并将其作为绑定的MSG-ID对象包含到绑定的信令消息中（图13中的保留（1））它应该等待相关绑定信令消息（图13中的RESERVE“（3））的到来，该消息携带相关的MSG-ID对象。还应相应地设置绑定会话ID。每条消息只允许一个MSG-ID或绑定的MSG-ID对象。如果两条消息之间的依赖关系是双向的，则设置消息绑定类型标志（值为1）。否则，将取消设置消息绑定类型标志。在大多数情况下，必须包含一个RII对象才能得到相应的响应。
Depending on the arrival sequence of the bound signaling message (RESERVE (1) in Figure 13) and the "triggering" binding signaling message (RESERVE' (3) in Figure 13), different situations can be identified:
根据绑定信令消息（图13中的RESERVE（1）和图13中的“触发”绑定信令消息（RESERVE）（3）的到达顺序，可以识别不同的情况：
o The bound signaling (RESERVE (1)) arrives first. The receiving QNE enqueues (probably after some pre-processing) the signaling (RESERVE (1)) message for the corresponding session. It also starts a MsgIDWait timer in order to discard the message in case the related "triggering" message (RESERVE' in Figure 13) does not arrive. The timeout period for this time SHOULD be set to the default retransmission timeout period (QOSNSLP_REQUEST_RETRY). In case a retransmitted RESERVE message arrives before the timeout, it will simply override the waiting message (i.e., the latter is discarded, and the new message is now waiting with the MsgIDWait timer being reset).
o 绑定信令（RESERVE（1））首先到达。接收QNE排队（可能在一些预处理之后）相应会话的信令（保留（1））消息。它还启动MsgIDWait计时器，以便在相关“触发”消息（图13中的RESERVE）未到达时丢弃该消息。此时间的超时时间应设置为默认的重新传输超时时间（QOSNSLP_请求_重试）。如果重新传输的保留消息在超时之前到达，它将简单地覆盖等待消息（即，后者被丢弃，新消息现在正在等待，MsgIDWait计时器被重置）。
At the same time, the "triggering" message including a MSG-ID object, carrying the same value as the BOUND-MSG-ID object is sent by the same initiating QNE (QNI' in Figure 13). The intermediate QNE' sees the MSG-ID object, but can determine that it is not the endpoint for the session (QNR') and therefore simply forwards the message after
同时，包含MSG-ID对象的“触发”消息与绑定的MSG-ID对象具有相同的值，由相同的发起QNE发送（图13中的QNI）。中间QNE'看到MSG-ID对象，但可以确定它不是会话（QNR）的端点，因此只需在之后转发消息
normal processing. The receiving QNE (QNR') as endpoint for the aggregate session (i.e., deaggregator) interprets the MSG-ID object and looks for a corresponding waiting message with a BOUND-MSG-ID of the same value whose waiting condition is satisfied now. Depending on successful processing of the RESERVE' (3), processing of the waiting RESERVE will be resumed, and the MsgIDWait timer will be stopped as soon as the related RESERVE' arrived.
正常处理。接收QNE（QNR'）作为聚合会话的端点（即，解聚合器）解释MSG-ID对象，并查找具有相同值的绑定MSG-ID且其等待条件现在已满足的相应等待消息。根据成功处理保留“（3）的情况，等待保留的处理将恢复，并且在相关保留“到达”后，MsgIDWait计时器将立即停止。
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | | (1) | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | | (2) | | |
| | +=========>| RESERVE' | |
| | | | (3) | |
| | | +=========>| RESERVE |
| | | | | (4) |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | | (1) | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | | (2) | | |
| | +=========>| RESERVE' | |
| | | | (3) | |
| | | +=========>| RESERVE |
| | | | | (4) |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
(1): RESERVE: SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A
(2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x
(4): RESERVE: SESSION-ID=F (MSG-ID object was removed)
(1): RESERVE: SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A
(2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x
(4): RESERVE: SESSION-ID=F (MSG-ID object was removed)
Figure 13: Example for Using Message Binding
图13：使用消息绑定的示例
Several further cases have to be considered in this context:
在这方面还需要考虑其他几个案例：
o "Triggering message" (3) arrives before waiting (bound) message (1): In this case, the processing of the triggering message depends on the value of the Message_Binding_Type flag. If Message_Binding_Type is UNSET (value is 0), then the triggering message can be processed normally, but the MSG-ID and the result (success or failure) should be saved for the waiting message. Thus, the RESPONSE' can be sent by the QNR' immediately. If the waiting message (1) finally arrives at the QNR', it can be detected that the waiting condition was already satisfied because the triggering message already arrived earlier. If Message_Binding_Type is SET (value is 1), then the triggering message interprets the MSG-ID object and looks for the corresponding waiting message with a BOUND-MSG-ID of the same value, which in this case has not yet arrived. It then starts a MsgIDWait timer in order to discard the message in case the related message (RESERVE (1) in Figure 14) does not arrive. Depending on successful processing of the RESERVE (1), processing of the waiting RESERVE' will be resumed, the MsgIDWait timer will be stopped as soon as the related RESERVE arrives and the RESPONSE' can be sent by the QNR' towards the QNI'.
o “触发消息”（3）在等待（绑定）消息（1）之前到达：在这种情况下，触发消息的处理取决于消息绑定类型标志的值。如果消息绑定类型未设置（值为0），则触发消息可以正常处理，但应为等待的消息保存MSG-ID和结果（成功或失败）。因此，响应“可由QNR立即发送”。如果等待消息（1）最终到达QNR’，则可以检测到等待条件已经满足，因为触发消息已经提前到达。如果设置了Message_Binding_Type（值为1），则触发消息将解释MSG-ID对象，并查找具有相同值的bind-MSG-ID的对应等待消息，在本例中，该值尚未到达。然后启动MsgIDWait计时器，以便在相关消息（图14中的RESERVE（1））未到达时丢弃该消息。根据保留（1）的成功处理，等待保留的处理将恢复，相关保留到达后，MsgIDWait计时器将停止，响应“可由QNR向QNI发送”。
o The "triggering message" (3) does not arrive at all: this may be due to message loss (which will cause a retransmission by the QNI' if the RII object is included) or due to a reservation failure at an intermediate node (QNE' in the example). The MsgIDWait timeout will then simply discard the waiting message at QNR'. In this case, the QNR' MAY send a RESPONSE message towards the QNI informing it that the synchronization of the two messages has failed.
o “触发消息”（3）根本没有到达：这可能是由于消息丢失（如果包含RII对象，这将导致QNI'重新传输）或由于中间节点（示例中的QNE'处的保留失败）。然后，MsgIDWait超时将在QNR'处丢弃等待消息。在这种情况下，QNR’可向QNI发送响应消息，通知其两条消息的同步已失败。
o Retransmissions should use the same MSG-ID because usually only one of the two related messages is retransmitted. As mentioned above: retransmissions will only occur if the RII object is set in the RESERVE. If a retransmitted message with a MSG-ID arrives while a bound message with the same MSG-ID is still waiting, the retransmitted message will replace the bound message.
o 重新传输应使用相同的MSG-ID，因为通常只会重新传输两条相关消息中的一条。如上所述：只有在保留中设置RII对象时才会发生重传。如果具有MSG-ID的重传消息到达，而具有相同MSG-ID的绑定消息仍在等待，则重传消息将替换绑定消息。
For a receiving node, there are conceptually two lists indexed by message IDs. One list contains the IDs and results of triggering messages (those carrying a MSG-ID object), the other list contains the IDs and message contents of the bound waiting messages (those who carried a BOUND-MSG-ID). The former list is used when a triggering message arrives before the bound message. The latter list is used when a bound message arrives before a triggering message.
对于接收节点，从概念上讲，有两个由消息ID索引的列表。一个列表包含触发消息的ID和结果（携带MSG-ID对象的消息），另一个列表包含绑定等待消息的ID和消息内容（携带绑定MSG-ID的消息）。当触发消息在绑定消息之前到达时，使用前一个列表。当绑定消息在触发消息之前到达时，使用后一个列表。
This example uses a different QoS model within a domain, in conjunction with GIST and NSLP functionality that allows the interior nodes to avoid storing GIST and QoS NSLP state. As a result, the interior nodes only store the QSPEC-related reservation state or even no state at all. This allows the QoS model to use a form of "reduced-state" operation, where reservation states with a coarser granularity (e.g., per-class) are used, or a "stateless" operation where no QoS NSLP state is needed (or created). This is useful, e.g., for measurement-based admission control schemes.
此示例在域中使用不同的QoS模型，并结合GIST和NSLP功能，允许内部节点避免存储GIST和QoS NSLP状态。因此，内部节点仅存储QSPEC相关的保留状态，甚至根本不存储任何状态。这允许QoS模型使用一种形式的“简化状态”操作，其中使用具有较粗粒度（例如，每个类）的保留状态，或者使用一种不需要（或创建）QoS NSLP状态的“无状态”操作。这是有用的，例如，对于基于测量的接纳控制方案。
The key difference between this example and the use of different QoS models in Section 4.5 is the transport characteristics for the reservation, i.e., GIST can be used in a different way for the edge-to-edge and hop-by-hop sessions. The reduced-state reservation can be updated independently of the per-flow end-to-end reservations.
本示例与第4.5节中使用不同QoS模型的关键区别在于保留的传输特性，即GIST可以以不同的方式用于边到边和逐跳会话。简化状态保留可以独立于每流端到端保留进行更新。
The QNI initiates a RESERVE message (see Figure 14). At the QNEs on the edges of the stateless or reduced-state region, the processing is different and the nodes support two QoS models. At the ingress, the original RESERVE message is forwarded but ignored by the stateless or reduced-state nodes. This is accomplished by marking this message at the ingress, i.e., modifying the QoS NSLP default NSLPID value to an NSLPID predefined value (see Section 4.6). The egress must reassign the QoS NSLP default NSLPID value to the original end-to-end RESERVE message. An example of such operation is given in [RFC5977].
QNI启动一条保留消息（参见图14）。在无状态或简化状态区域边缘的QNE上，处理是不同的，节点支持两种QoS模型。在入口，原始保留消息被转发，但被无状态或简化状态节点忽略。这是通过在入口标记此消息来实现的，即将QoS NSLP默认NSLPID值修改为NSLPID预定义值（参见第4.6节）。出口必须将QoS NSLP默认NSLPID值重新分配给原始端到端保留消息。[RFC5977]中给出了此类操作的示例。
The egress node is the next QoS-NSLP hop for the end-to-end RESERVE message. Reliable GIST transfer mode can be used between the ingress and egress without requiring GIST state in the interior. At the egress node, the RESERVE message is then forwarded normally.
出口节点是端到端保留消息的下一个QoS NSLP跳。在入口和出口之间可以使用可靠的GIST传输模式，而不需要内部GIST状态。在出口节点，保留消息随后被正常转发。
At the ingress, a second RESERVE' message is also built (Figure 14). This makes use of a QoS model suitable for a reduced-state or stateless form of operation (such as the RMD per-hop reservation). Since the original RESERVE and the RESERVE' messages are addressed identically, the RESERVE' message also arrives at the same egress QNE that was also traversed by the RESERVE message. Message binding is used to synchronize the messages.
在入口，还构建了第二条RESERVE消息（图14）。这使得QoS模型适用于简化状态或无状态的操作形式（例如RMD每跳保留）。由于原始RESERVE和RESERVE消息的地址相同，RESERVE消息也到达RESERVE消息也经过的同一出口QNE。消息绑定用于同步消息。
When processed by interior (stateless) nodes, the QoS NSLP processing exercises its options to not keep state wherever possible, so that no per-flow QoS NSLP state is stored. Some state, e.g., per class, for the QSPEC-related data may be held at these interior nodes. The QoS NSLP also requests that GIST use different transport characteristics
当由内部（无状态）节点处理时，QoS NSLP处理将执行其选项，尽可能不保持状态，以便不存储每流QoS NSLP状态。QSPEC相关数据的某些状态（例如，每类）可能保存在这些内部节点上。QoS NSLP还要求GIST使用不同的传输特性
(e.g., sending of messages in unreliable GIST transfer mode). It also requests the local GIST processing not to retain messaging association state or reverse message routing state.
（例如，以不可靠的GIST传输模式发送消息）。它还请求本地GIST处理不保留消息关联状态或反向消息路由状态。
Nodes, such as those in the interior of the stateless or reduced-state domain, that do not retain reservation state cannot send back RESPONSE messages (and so cannot use the refresh reduction extension).
不保留保留保留状态的节点（如无状态或简化状态域内部的节点）无法发回响应消息（因此无法使用刷新简化扩展）。
At the egress node, the RESERVE' message is interpreted in conjunction with the reservation state from the end-to-end RESERVE message (using information carried in the message to correlate the signaling flows). The RESERVE message is only forwarded further if the processing of the RESERVE' message was successful at all nodes in the local domain; otherwise, the end-to-end reservation is regarded as having failed to be installed. This can be realized by using the message binding functionality described in Section 4.6 to synchronize the arrival of the bound signaling message (end-to-end RESERVE) and the binding signaling message (local RESERVE').
在出口节点，结合来自端到端保留消息的保留状态来解释保留消息（使用消息中携带的信息来关联信令流）。仅当在本地域中的所有节点上成功处理保留消息时，才进一步转发保留消息；否则，端到端保留被视为无法安装。这可以通过使用第4.6节中描述的消息绑定功能来实现，以同步绑定信令消息（端到端保留）和绑定信令消息（本地保留）的到达。
QNE QNE QNE QNE
ingress interior interior egress
GIST stateful GIST stateless GIST stateless GIST stateful
| A B |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' |
|<---------------------------------------------+
| | | | RESERVE
| | | +-------->
| | | | RESPONSE
| | | |<--------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
QNE QNE QNE QNE
ingress interior interior egress
GIST stateful GIST stateless GIST stateless GIST stateful
| A B |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' |
|<---------------------------------------------+
| | | | RESERVE
| | | +-------->
| | | | RESPONSE
| | | |<--------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 14: Sender-Initiated Reservation with Reduced-State Interior Nodes
图14：减少状态内部节点的发送方发起的保留
Resource management errors in the example above are reflected in the QSPEC and QoS model processing. For example, if the RESERVE' fails at QNE A, it cannot send an error message back to the ingress QNE. Thus, the RESERVE' is forwarded along the intended path, but the QSPEC includes information for subsequent QNEs telling them an error happened upstream. It is up to the QoS model to determine what to do. Eventually, the RESERVE' will reach the egress QNE, and again, the QoS model then determines the response.
上述示例中的资源管理错误反映在QSPEC和QoS模型处理中。例如，如果保留“在QNE A失败，它将无法向入口QNE发送错误消息。因此，RESERVE“沿着预定路径转发，但是QSPEC包括后续qne的信息，告诉它们上游发生了错误。由QoS模型决定要做什么。最终，保留将到达出口QNE，并且再次，QoS模型随后确定响应。
Since NSLP neighbor relationships are not maintained in the reduced-state region, only sender-initiated signaling can be supported within the reduced-state region. If a receiver-initiated reservation over a stateless or reduced-state domain is required, this can be implemented as shown in Figure 15.
由于在简化状态区域中不维护NSLP邻居关系，因此在简化状态区域中只能支持发送方发起的信令。如果需要对无状态域或简化状态域进行接收方发起的保留，则可以如图15所示实现。
QNE QNE QNE
ingress interior egress
GIST stateful GIST stateless GIST stateful
| | |
QUERY | | |
-------->| QUERY | |
+------------------------------>|
| | | QUERY
| | +-------->
| | | RESERVE
| | |<--------
| | RESERVE |
|<------------------------------+
| RESERVE' | RESERVE' |
|-------------->|-------------->|
| | RESPONSE' |
|<------------------------------+
RESERVE | | |
<--------| | |
QNE QNE QNE
ingress interior egress
GIST stateful GIST stateless GIST stateful
| | |
QUERY | | |
-------->| QUERY | |
+------------------------------>|
| | | QUERY
| | +-------->
| | | RESERVE
| | |<--------
| | RESERVE |
|<------------------------------+
| RESERVE' | RESERVE' |
|-------------->|-------------->|
| | RESPONSE' |
|<------------------------------+
RESERVE | | |
<--------| | |
Figure 15: Receiver-Initiated Reservation with Reduced-State Interior Nodes
图15：具有减少状态内部节点的接收器发起的保留
The RESERVE message that is received by the egress QNE of the stateless domain is sent transparently to the ingress QNE (known as the source of the QUERY message). When the RESERVE message reaches the ingress, the ingress QNE needs to send a sender-initiated RESERVE' over the stateless domain. The ingress QNE needs to wait for a RESPONSE'. If the RESPONSE' notifies that the reservation was accomplished successfully, then the ingress QNE sends a RESERVE message further upstream.
由无状态域的出口QNE接收的保留消息被透明地发送到入口QNE（称为查询消息的源）。当保留消息到达入口时，入口QNE需要通过无状态域发送发送方发起的保留。入口QNE需要等待响应'。如果响应“通知保留已成功完成，则入口QNE将向更远的上游发送保留消息。
Besides the sender- and receiver-initiated reservations, the QoS NSLP includes a functionality we refer to as Proxy Mode. Here a QNE is set by administrator assignment to work as a proxy QNE (P-QNE) for a certain region, e.g., for an administrative domain. A node initiating the signaling may set the PROXY scope flag to indicate that the signaling is meant to be confined within the area controlled by the proxy, e.g., the local access network.
除了发送方和接收方发起的保留之外，QoS NSLP还包括我们称为代理模式的功能。此处，管理员分配将QNE设置为作为特定区域（例如，管理域）的代理QNE（P-QNE）。发起信令的节点可以设置代理作用域标志，以指示信令将被限制在由代理控制的区域内，例如，本地接入网络。
The Proxy Mode has two uses. First, it allows the QoS NSLP signaling to be confined to a pre-defined section of the path. Second, it allows a node to make reservations for an incoming data flow.
代理模式有两种用途。首先，它允许QoS NSLP信令被限制在路径的预定义部分。其次，它允许节点为传入的数据流进行保留。
For outgoing data flows and sender-initiated reservations, the end host is the QNI, and sends a RESERVE with the PROXY scope flag set. The P-QNE is the QNR; it will receive the RESERVE, notice the PROXY scope flag is set and reply with a RESPONSE (if requested). This operation is the same as illustrated in Figure 7. The receiver-oriented reservation for outgoing flows works the same way as in Figure 8, except that the P-QNE is the QNI.
对于传出数据流和发送方发起的保留，最终主机是QNI，并发送设置了代理作用域标志的保留。P-QNE是QNR；它将接收保留，注意设置了代理作用域标志，并用响应（如果请求）进行回复。此操作与图7所示的操作相同。除了P-QNE是QNI之外，面向接收方的传出流保留的工作方式与图8中相同。
For incoming data flows, the end host is the QNI, and it sends a RESERVE towards the data sender with the PROXY scope flag set. Here the end host sets the MRI so that it indicates the end host as the receiver of the data, and sets the D-flag.
对于传入的数据流，终端主机是QNI，它向数据发送方发送保留，并设置代理作用域标志。此处，终端主机设置MRI，以便将终端主机指示为数据接收器，并设置D标志。
GIST is able to send messages towards the data sender if there is existing message routing state or it is able to use the Upstream Q-mode Encapsulation. In some cases, GIST will be unable to determine the appropriate next hop for the message, and so will indicate a failure to deliver it (by sending an error message). This may occur, for example, if GIST attempts to determine an upstream next hop and there are multiple possible inbound routes that could be used.
GIST能够向数据发送方发送消息，前提是存在消息路由状态，或者GIST能够使用上游Q模式封装。在某些情况下，GIST将无法确定消息的适当下一跳，因此将指示传递失败（通过发送错误消息）。例如，如果GIST试图确定上游下一跳，并且有多个可能的入站路由可供使用，则可能会发生这种情况。
Bidirectional reservations can be used, as discussed in Section 4.4. The P-QNE will be the QNR or QNI for reservations.
如第4.4节所述，可以使用双向预订。对于预订，P-QNE将是QNR或QNI。
If the PROXY scope flag is set in an incoming QoS NSLP message, the QNE must set the same flag in all QoS NSLP messages it sends that are related to this session.
如果在传入的QoS NSLP消息中设置了代理作用域标志，则QNE必须在其发送的与此会话相关的所有QoS NSLP消息中设置相同的标志。
A QoS NSLP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The common header and other objects are encapsulated together in a GIST NSLP-Data object. The following subsections define the formats of the common header and each of the QoS NSLP message types. In the message formats, the common header is denoted as COMMON-HEADER.
QoS NSLP消息由一个公共头和一个正文组成，正文由数量可变、长度可变、类型化的“对象”组成。公共标头和其他对象封装在一个GIST NSLP数据对象中。以下小节定义了公共标头的格式和每个QoS NSLP消息类型。在消息格式中，公共标头表示为公共标头。
For each QoS NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 [RFC5234]. The ABNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation SHOULD create messages with the objects in the order shown here, but MUST accept the objects in any order.
对于每种QoS NSLP消息类型，都有一组允许选择对象类型的规则。这些规则是使用RFC 5234[RFC5234]中指定的扩充巴科斯诺尔表（ABNF）指定的。ABNF表示消息中对象的顺序。然而，在许多（但不是所有）情况下，对象顺序在逻辑上没有区别。实现应该按照此处显示的顺序使用对象创建消息，但必须以任何顺序接受对象。
All GIST NSLP-Data objects for the QoS NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header).
QoS NSLP的所有GIST NSLP数据对象必须包含此公共头作为对象的前32位（这与GIST公共头不同）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Message Flags | Generic Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Message Flags | Generic Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the common header are as follows:
公共标题中的字段如下所示：
Msg Type: 8 bits
消息类型：8位
1 = RESERVE
1 = RESERVE
2 = QUERY
2 = QUERY
3 = RESPONSE
3 = RESPONSE
4 = NOTIFY
4 = NOTIFY
Message-specific flags: 8 bits
消息特定标志：8位
These flags are defined as part of the specification of individual messages, and, thus, are different with each message type.
这些标志被定义为单个消息规范的一部分，因此，每种消息类型都不同。
Generic flags: 16 bits
通用标志：16位
Generic flags have the same meaning for all message types. There exist currently four generic flags: the (next hop) Scoping flag (S), the Proxy scope flag (P), the Acknowledgement Requested flag (A), and the Break flag (B).
通用标志对于所有消息类型都具有相同的含义。目前存在四个通用标志：（下一跳）作用域标志（S）、代理作用域标志（P）、确认请求标志（A）和中断标志（B）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B|A|P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B|A|P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCOPING (S) - when set, indicates that the message is scoped and should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path").
作用域-设置后，表示消息的作用域已确定，不应沿整个路径传播，而应仅传播到下一个QNE（scope=“next hop”）。默认情况下，不设置此标志（默认范围=“整个路径”）。
PROXY (P) - when set, indicates that the message is scoped, and should not travel down the entire path but only as far as the P-QNE. By default, this flag is not set.
代理（P）-设置时，表示消息的作用域已确定，不应沿整个路径传播，而应仅传播到P-QNE。默认情况下，不设置此标志。
ACK-REQ (A) - when set, indicates that the message should be acknowledged by the receiving peer. The flag is only used between stateful peers, and only used with RESERVE and QUERY messages. Currently, the flag is only used with refresh messages. By default, the flag is not set.
ACK-REQ（A）-设置时，表示接收对等方应确认消息。该标志仅在有状态对等方之间使用，并且仅用于保留和查询消息。目前，该标志仅用于刷新消息。默认情况下，不设置该标志。
BREAK (B) - when set, indicates that there are routers along the path where QoS cannot be provided.
中断（B）-设置时，表示路径上存在无法提供QoS的路由器。
The set of appropriate flags depends on the particular message being processed. Any bit not defined as a flag for a particular message MUST be set to zero on sending and MUST be ignored on receiving.
适当标志的设置取决于正在处理的特定消息。任何未定义为特定消息标志的位在发送时必须设置为零，在接收时必须忽略。
The ACK-REQ flag is useful when a QNE wants to make sure the messages received by the downstream QNE are truly processed by the QoS NSLP, not just delivered by GIST. This is useful for faster dead peer detection on the NSLP layer. This liveliness test can only be used with refresh RESERVE messages. The ACK-REQ flag must not be set for RESERVE messages that already include an RII object, since a confirmation has already been requested from the QNR. Reliable transmission of messages between two QoS NSLP peers should be handled by GIST, not the NSLP by itself.
当QNE希望确保下游QNE接收的消息由QoS NSLP真正处理时，ACK-REQ标志非常有用，而不仅仅是由GIST传递。这对于NSLP层上更快的死点检测非常有用。此活力测试只能用于刷新保留消息。不得为已包含RII对象的保留消息设置ACK-REQ标志，因为已从QNR请求确认。两个QoS NSLP对等方之间的消息可靠传输应由GIST处理，而不是由NSLP本身处理。
The format of a RESERVE message is as follows:
保留信息的格式如下所示：
RESERVE = COMMON-HEADER
RSN [ RII ] [ REFRESH-PERIOD ] [ *BOUND-SESSION-ID ]
[ SESSION-ID-LIST [ RSN-LIST ] ]
[ MSG-ID / BOUND-MSG-ID ] [ INFO-SPEC ]
[ [ PACKET-CLASSIFIER ] QSPEC ]
RESERVE = COMMON-HEADER
RSN [ RII ] [ REFRESH-PERIOD ] [ *BOUND-SESSION-ID ]
[ SESSION-ID-LIST [ RSN-LIST ] ]
[ MSG-ID / BOUND-MSG-ID ] [ INFO-SPEC ]
[ [ PACKET-CLASSIFIER ] QSPEC ]
The RSN is the only mandatory object and MUST always be present in all cases. A QSPEC MUST be included in the initial RESERVE sent towards the QNR. A PACKET-CLASSIFIER MAY be provided. If the PACKET-CLASSIFIER is not provided, then the full set of information provided in the GIST MRI for the session should be used for packet classification purposes.
RSN是唯一的强制对象，在任何情况下都必须始终存在。QSPEC必须包含在发送给QNR的初始储备中。可以提供分组分类器。如果未提供分组分类器，则GIST MRI中为会话提供的全套信息应用于分组分类目的。
Subsequent RESERVE messages meant as reduced refreshes, where no QSPEC is provided, MUST NOT include a PACKET-CLASSIFIER either.
如果未提供QSPEC，则表示为减少刷新的后续保留消息也不得包括分组分类器。
There are no requirements on transmission order, although the above order is recommended.
虽然建议使用上述顺序，但对变速箱顺序没有要求。
Two message-specific flags are defined for use in the common header with the RESERVE message. These are:
定义了两个特定于消息的标志，用于保留消息的公共头中。这些是：
+-+-+-+-+-+-+-+-+
|Reserved |T|R|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Reserved |T|R|
+-+-+-+-+-+-+-+-+
TEAR (T) - when set, indicates that reservation state and QoS NSLP operation state should be torn down. The former is indicated to the RMF. Depending on the QoS model, the tear message may include a QSPEC to further specify state removal, e.g., for an aggregation, the QSPEC may specify the amount of resources to be removed from the aggregate.
撕裂（T）-设置时，表示应拆除保留状态和QoS NSLP操作状态。前者向RMF指示。取决于QoS模型，撕裂消息可以包括QSPEC以进一步指定状态移除，例如，对于聚合，QSPEC可以指定要从聚合移除的资源量。
REPLACE (R) - when set, the flag has two uses. First, it indicates that a RESERVE with different MRI (but same SID) replaces an existing one, so the old one MAY be torn down immediately. This is the default situation. This flag may be unset to indicate a desire from an upstream node to keep an existing reservation on an old branch in place. Second, this flag is also used to indicate whether the reserved resources on the old branch should be torn down or not when a data path change happens. In this case, the MRI is the same and only the route path changes.
替换（R）-设置后，该标志有两种用途。首先，它表明一个具有不同MRI（但相同SID）的保留区替换了一个现有的保留区，因此旧的保留区可能会立即被拆除。这是默认情况。该标志可被取消设置以指示来自上游节点的保持旧分支上的现有保留的愿望。其次，此标志还用于指示在发生数据路径更改时是否应拆除旧分支上的保留资源。在这种情况下，MRI是相同的，只有路径改变。
If the REFRESH-PERIOD is not present, a default value of 30 seconds is assumed.
如果刷新周期不存在，则假定默认值为30秒。
If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s).
如果此消息的会话绑定到另一个会话，则保留消息必须在绑定会话ID对象中包含该另一个会话的会话ID。在聚合隧道的情况下，聚合会话可能不包括绑定会话ID中其绑定会话的会话ID。
The negotiation of whether to perform sender- or receiver-initiated signaling is done outside the QoS NSLP. Yet, in theory, it is possible that a "reservation collision" may occur if the sender believes that a sender-initiated reservation should be performed for a flow, whilst the other end believes that it should be starting a receiver-initiated reservation. If different session identifiers are used, then this error condition is transparent to the QoS NSLP, though it may result in an error from the RMF. Otherwise, the removal of the duplicate reservation is left to the QNIs/QNRs for the two sessions.
是否执行发送方或接收方发起的信令的协商在QoS NSLP之外完成。然而，理论上，如果发送方认为应该对流执行发送方发起的保留，而另一端认为应该启动接收方发起的保留，则可能发生“保留冲突”。如果使用不同的会话标识符，则此错误条件对QoS NSLP是透明的，尽管它可能会导致来自RMF的错误。否则，删除两个会话的重复保留将留给QNIs/QNRs。
If a reservation is already installed and a RESERVE message is received with the same session identifier from the other direction (i.e., going upstream where the reservation was installed by a downstream RESERVE message, or vice versa), then an error indicating "RESERVE received from wrong direction" MUST be sent in a RESPONSE message to the signaling message source for this second RESERVE.
如果已安装保留，并且从另一个方向接收到具有相同会话标识符的保留消息（即，从下游保留消息安装保留的位置向上游移动，反之亦然），则会出现一个错误，指示“从错误方向接收保留”必须以响应消息的形式发送到此第二个保留的信令消息源。
A refresh right along the path can be forced by requesting a RESPONSE from the far end (i.e., by including an RII object in the RESERVE message). Without this, a refresh RESERVE would not trigger RESERVE messages to be sent further along the path, as each hop has its own refresh timer.
通过从远端请求响应（即，通过在保留消息中包含RII对象），可以强制沿路径进行刷新。否则，刷新保留将不会触发沿路径发送的保留消息，因为每个跃点都有自己的刷新计时器。
A QNE may ask for confirmation of a tear operation by including an RII object. QoS NSLP retransmissions SHOULD be disabled. A QNE sending a tearing RESERVE with an RII included MAY ask GIST to use reliable transport. When the QNE sends out a tearing RESERVE, it MUST NOT send refresh messages anymore.
QNE可以通过包含RII对象来请求撕裂操作的确认。应禁用QoS NSLP重传。QNE发送包含RII的撕裂储备可能要求GIST使用可靠传输。当QNE发出撕裂保留时，它不能再发送刷新消息。
If the routing path changed due to mobility and the mobile node's IP address changed, and it sent a Mobile IP binding update, the resulting refresh is a new RESERVE. This RESERVE includes a new MRI and will be propagated end-to-end; there is no need to force end-to-end forwarding by including an RII.
如果路由路径由于移动性而改变，并且移动节点的IP地址改变，并且它发送了移动IP绑定更新，则产生的刷新是一个新的保留。该储备包括一个新的MRI，并将端到端传播；没有必要通过包含RII来强制端到端转发。
Note: It is possible for a host to use this mechanism to constantly force the QNEs on the path to send refreshing RESERVE messages. It may, therefore, be appropriate for QNEs to perform rate-limiting on the refresh messages that they send.
注意：主机可以使用此机制不断强制路径上的QNE发送刷新保留消息。因此，QNE可能适合对其发送的刷新消息执行速率限制。
The format of a QUERY message is as follows:
查询消息的格式如下所示：
QUERY = COMMON-HEADER [ RII ] [ *BOUND-SESSION-ID ] [ PACKET-CLASSIFIER ] [ INFO-SPEC ] QSPEC [ QSPEC ]
QUERY=COMMON-HEADER[RII][*BOUND-SESSION-ID][PACKET-CLASSIFIER][INFO-SPEC]QSPEC[QSPEC]
QUERY messages MUST always include a QSPEC. QUERY messages MAY include a PACKET-CLASSIFIER when the message is used to trigger a receiver-initiated reservation. If a PACKET-CLASSIFIER is not included then the full GIST MRI should be used for packet classification purposes in the subsequent RESERVE. A QUERY message MAY contain a second QSPEC object.
查询消息必须始终包含QSPEC。当查询消息用于触发接收器发起的保留时，查询消息可以包括分组分类器。如果未包括分组分类器，则应在后续保留中使用完整的GIST MRI进行分组分类。查询消息可能包含第二个QSPEC对象。
A QUERY message for requesting information about network resources MUST contain an RII object to match an incoming RESPONSE to the QUERY.
用于请求有关网络资源的信息的查询消息必须包含一个RII对象，以匹配查询的传入响应。
The QSPEC object describes what is being queried for and may contain objects that gather information along the data path. There are no requirements on transmission order, although the above order is recommended.
QSPEC对象描述查询的内容，可能包含沿数据路径收集信息的对象。虽然建议使用上述顺序，但对变速箱顺序没有要求。
One message-specific flag is defined for use in the common header with the QUERY message. It is:
定义了一个特定于消息的标志，用于查询消息的公共头中。它是：
+-+-+-+-+-+-+-+-+
|Reserved |R|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Reserved |R|
+-+-+-+-+-+-+-+-+
RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger for the recipient to make a resource reservation by sending a RESERVE.
RESERVE-INIT（R）-设置此选项时，查询意味着收件人通过发送保留来触发资源保留。
If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s).
如果此消息的会话绑定到另一个会话，则保留消息必须在绑定会话ID对象中包含该另一个会话的会话ID。在聚合隧道的情况下，聚合会话可能不包括绑定会话ID中其绑定会话的会话ID。
The format of a RESPONSE message is as follows:
响应消息的格式如下所示：
RESPONSE = COMMON-HEADER [ RII / RSN ] INFO-SPEC [SESSION-ID-LIST [ RSN-LIST ] ] [ QSPEC ]
响应=COMMON-HEADER[RII/RSN]INFO-SPEC[SESSION-ID-LIST[RSN-LIST]][QSPEC]
A RESPONSE message MUST contain an INFO-SPEC object that indicates the success of a reservation installation or an error condition. Depending on the value of the INFO-SPEC, the RESPONSE MAY also contain a QSPEC object. The value of an RII or an RSN object was provided by some previous QNE. There are no requirements on transmission order, although the above order is recommended.
响应消息必须包含一个INFO-SPEC对象，该对象指示保留安装成功或出现错误情况。根据INFO-SPEC的值，响应还可能包含QSPEC对象。RII或RSN对象的值由以前的某个QNE提供。虽然建议使用上述顺序，但对变速箱顺序没有要求。
No message-specific flags are defined for use in the common header with the RESPONSE message.
没有为响应消息的公共标头中使用定义消息特定的标志。
The format of a NOTIFY message is as follows:
通知消息的格式如下所示：
NOTIFY = COMMON-HEADER INFO-SPEC [ QSPEC ]
NOTIFY=通用标题信息规范[QSPEC]
A NOTIFY message MUST contain an INFO-SPEC object indicating the reason for the notification. Depending on the INFO-SPEC value, it MAY contain a QSPEC object providing additional information.
通知消息必须包含指示通知原因的INFO-SPEC对象。根据INFO-SPEC值，它可能包含提供附加信息的QSPEC对象。
No message-specific flags are defined for use with the NOTIFY message.
未定义用于NOTIFY消息的消息特定标志。
The QoS NSLP uses a Type-Length-Value (TLV) object format similar to that used by GIST. Every object consists of one or more 32-bit words with a one-word header. For convenience, the standard object header is shown here:
QoS NSLP使用与GIST使用的类型长度值（TLV）对象格式类似的对象格式。每个对象都由一个或多个32位字组成，并带有一个字头。为方便起见，标准对象标题如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value for the Type field comes from the shared NSLP object type space; the various objects are presented in subsequent sections. The Length field is given in units of 32-bit words and measures the length of the Value component of the TLV object (i.e., it does not include the standard header).
类型字段的值来自共享NSLP对象类型空间；随后的章节将介绍各种对象。长度字段以32位字为单位给出，并测量TLV对象的值组件的长度（即，它不包括标准标头）。
The bits marked 'A' and 'B' are flags used to signal the desired treatment for objects whose treatment has not been defined in the protocol specification (i.e., whose Type field is unknown at the receiver). The following four categories of object have been identified, and are described here.
标记为“A”和“B”的位是用于向协议规范中未定义其处理的对象（即，其类型字段在接收器处未知）发送所需处理信号的标志。已经确定了以下四类对象，并在此处进行了描述。
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back.
AB=00（“必需”）：如果对象不被理解，则必须拒绝包含该对象的整个消息，并返回错误消息。
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual.
AB=01（“忽略”）：如果对象不被理解，则必须将其删除，并像往常一样处理消息的其余部分。
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
AB=10（“转发”）：如果对象不被理解，则必须将其作为消息处理的结果保留在转发的任何消息中，而不是存储在本地。
AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored QoS NSLP signaling application operational state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message that is generated locally. The contents of this object does not need to be interpreted, and should only be stored as bytes on the QNE.
AB=11（“刷新”）：如果不理解该对象，则应将其合并到此流/会话的本地存储QoS NSLP信令应用程序操作状态中，在任何结果消息中转发，并在本地生成的任何刷新或修复消息中使用。此对象的内容不需要解释，只应作为字节存储在QNE上。
The remaining bits marked 'r' are reserved. These SHALL be set to 0 and SHALL be ignored on reception. The extensibility flags AB are similar to those used in the GIST specification. All objects defined in this specification MUST be understood by all QNEs; thus, they MUST have the AB-bits set to "00". A QoS NSLP implementation must recognize objects of the following types: RII, RSN, REFRESH-PERIOD, BOUND-SESSION-ID, INFO-SPEC, and QSPEC.
标记为“r”的其余位保留。这些应设置为0，并在接收时忽略。扩展性标志AB与GIST规范中使用的标志类似。所有QNE必须理解本规范中定义的所有对象；因此，它们必须将AB位设置为“00”。QoS NSLP实现必须识别以下类型的对象：RII、RSN、刷新周期、绑定会话ID、INFO-SPEC和QSPEC。
The object header is followed by the Value field, which varies for different objects. The format of the Value field for currently defined objects is specified below.
对象标题后面是值字段，该字段因不同对象而异。下面指定了当前定义对象的值字段格式。
The object diagrams here use '//' to indicate a variable-sized field.
此处的对象关系图使用“/”表示大小可变的字段。
Type: 0x001
类型：0x001
Length: Fixed - 1 32-bit word
长度：固定-1个32位字
Value: An identifier that MUST be (probabilistically) unique within the context of a SESSION-ID and SHOULD be different every time a RESPONSE is desired. Used by a QNE to match back a RESPONSE to a request in a RESERVE or QUERY message.
值：在会话ID的上下文中必须（可能）唯一的标识符，并且每次需要响应时都应该不同。QNE用于将响应与保留或查询消息中的请求进行匹配。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identification Information (RII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identification Information (RII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x002
类型：0x002
Length: Fixed - 2 32-bit words
长度：固定-2个32位字
Value: An incrementing sequence number that indicates the order in which state-modifying actions are performed by a QNE, and an epoch identifier to allow the identification of peer restarts. The RSN has local significance only, i.e., between a QNE and its downstream stateful peers. The RSN is not reset when the downstream peer changes.
值：一个递增序列号，指示QNE执行状态修改操作的顺序，以及一个允许识别对等重启的历元标识符。RSN仅具有局部意义，即在QNE与其下游有状态对等方之间。当下游对等方发生变化时，RSN不会重置。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number (RSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number (RSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x003
类型：0x003
Length: Fixed - 1 32-bit word
长度：固定-1个32位字
Value: The refresh timeout period R used to generate this message; in milliseconds.
值：用于生成此消息的刷新超时时间R；以毫秒为单位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Period (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Period (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x004
类型：0x004
Length: Fixed - 5 32-bit words
长度：固定-5个32位字
Value: contains an 8-bit Binding_Code that indicates the nature of the binding. The rest specifies the SESSION-ID (as specified in GIST [RFC5971]) of the session that MUST be bound to the session associated with the message carrying this object.
值：包含指示绑定性质的8位绑定\u代码。其余部分指定会话的会话ID（如GIST[RFC5971]中所述），该会话必须绑定到与承载该对象的消息相关联的会话。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Binding Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Binding Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Currently defined Binding Codes are:
当前定义的绑定代码为：
o 0x01 - Tunnel and end-to-end sessions
o 0x01-隧道和端到端会话
o 0x02 - Bidirectional sessions
o 0x02-双向会话
o 0x03 - Aggregate sessions
o 0x03-聚合会话
o 0x04 - Dependent sessions (binding session is alive only if the other session is also alive)
o 0x04-依赖会话（仅当另一个会话也处于活动状态时，绑定会话才处于活动状态）
o 0x05 - Indicated session caused preemption
o 0x05-指示的会话导致抢占
More binding codes may be defined based on the above five atomic binding actions. Note a message may include more than one BOUND-SESSION-ID object. This may be needed in case one needs to define more specifically the reason for binding, or if the session depends
可以基于上述五个原子绑定操作定义更多绑定代码。注意：消息可能包含多个绑定会话ID对象。如果需要更具体地定义绑定的原因，或者会话依赖于
on more than one other session (with possibly different reasons). Note that a session with, e.g., SID_A (the binding session), can express its unidirectional dependency relation to another session with, e.g., SID_B (the bound session), by including a BOUND-SESSION-ID object containing SID_B in its messages.
在多个其他会话上（可能有不同的原因）。请注意，具有（例如）SID_a（绑定会话）的会话可以通过在其消息中包含包含SID_B的绑定会话ID对象来表示其与另一个具有（例如）SID_B（绑定会话）的会话的单向依赖关系。
Type: 0x005
类型：0x005
Length: Variable
长度：可变
Value: Contains variable-length MRM-specific data
值：包含可变长度MRM特定数据
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Method-specific classifier data (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Method-specific classifier data (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At this stage, the QoS NSLP only uses the path-coupled routing MRM. The method-specific classifier data is four bytes long and consists of a set of flags:
在此阶段，QoS NSLP仅使用路径耦合路由MRM。特定于方法的分类器数据有四个字节长，由一组标志组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Y|P|T|F|S|A|B| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Y|P|T|F|S|A|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
旗为：
X - Source Address and Prefix
X-源地址和前缀
Y - Destination Address and Prefix
Y-目的地址和前缀
P - Protocol
P-协议
T - Diffserv Code Point
T-Diffserv码点
F - Flow Label
F流标签
S - SPI
S-SPI
A - Source Port
A-源端口
B - Destination Port
B-目的港
The flags indicate which fields from the MRI MUST be used by the packet classifier. This allows a subset of the information in the MRI to be used for identifying the set of packets that are part of the reservation. Flags MUST only be set if the data is present in the MRI (i.e., where there is a corresponding flag in the GIST MRI, the flag can only be set if the corresponding GIST MRI flag is set). It should be noted that some flags in the PACKET-CLASSIFIER (X and Y) relate to data that is always present in the MRI, but are optional to use for QoS NSLP packet classification. The appropriate set of flags set may depend, to some extent, on the QoS model being used.
这些标志指示数据包分类器必须使用MRI中的哪些字段。这允许MRI中的信息子集用于识别作为保留的一部分的分组集。仅当数据存在于MRI中时才必须设置标志（即，如果GIST MRI中有相应标志，则仅当设置了相应的GIST MRI标志时才能设置标志）。应当注意，分组分类器（X和Y）中的一些标志与始终存在于MRI中的数据相关，但是对于QoS NSLP分组分类是可选的。在某种程度上，合适的标志集可能取决于所使用的QoS模型。
As mentioned earlier in this section, the QoS NSLP is currently only defined for use with the Path-Coupled Message Routing Method (MRM) in GIST. Future work may extend the QoS NSLP to additional routing mechanisms. Such MRMs must include sufficient information in the MRI to allow the subset of packets for which QoS is to be provided to be identified. When QoS NSLP is extended to support a new MRM, appropriate method-specific classifier data for the PACKET-CLASSIFIER object MUST be defined.
如本节前面所述，QoS NSLP目前仅定义为与GIST中的路径耦合消息路由方法（MRM）一起使用。未来的工作可能会将QoS NSLP扩展到其他路由机制。此类MRM必须在MRI中包含足够的信息，以允许识别为其提供QoS的数据包子集。当QoS NSLP被扩展以支持新的MRM时，必须为包分类器对象定义适当的方法特定分类器数据。
Type: 0x006
类型：0x006
Length: Variable
长度：可变
Value: Contains 8 reserved bits, an 8-bit error code, a 4-bit error class, a 4-bit error source identifier type, and an 8-bit error source identifier length (in 32-bit words), an error source identifier, and optionally variable-length error-specific information.
值：包含8个保留位、8位错误代码、4位错误类、4位错误源标识符类型、8位错误源标识符长度（32位字）、错误源标识符以及可选的可变长度错误特定信息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code |E-Class|ESI Typ| ESI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Source Identifier //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional error-specific information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code |E-Class|ESI Typ| ESI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Source Identifier //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional error-specific information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class Field:
类别字段：
The four E-Class bits of the object indicate the error severity class. The currently defined error classes are:
对象的四个E类位表示错误严重性级别。当前定义的错误类别包括：
o 1 - Informational
o 1-信息性
o 2 - Success
o 2-成功
o 3 - Protocol Error
o 3-协议错误
o 4 - Transient Failure
o 4-瞬态故障
o 5 - Permanent Failure
o 5-永久性故障
o 6 - QoS Model Error
o 6-QoS模型错误
Error field:
错误字段：
Within each error severity class, a number of Error Code values are defined.
在每个错误严重性类别中，定义了许多错误代码值。
o Informational:
o 信息性：
* 0x01 - Unknown BOUND-SESSION-ID: the message refers to an unknown SESSION-ID in its BOUND-SESSION-ID object.
* 0x01-未知绑定会话ID：消息引用其绑定会话ID对象中的未知会话ID。
* 0x02 - Route Change: possible route change occurred on downstream path.
* 0x02-路由更改：下游路径上可能发生路由更改。
* 0x03 - Reduced refreshes not supported; full QSPEC required.
* 0x03-不支持减少刷新次数；需要完整的QSPEC。
* 0x04 - Congestion situation: Possible congestion situation occurred on downstream path.
* 0x04-拥塞情况：下游路径上可能出现拥塞情况。
* 0x05 - Unknown SESSION-ID in SESSION-ID-LIST.
* 0x05-会话ID列表中的会话ID未知。
* 0x06 - Mismatching RSN in RSN-LIST.
* 0x06-RSN-LIST中的RSN不匹配。
o Success:
o 成功：
* 0x01 - Reservation successful
* 0x01-预订成功
* 0x02 - Teardown successful
* 0x02-拆卸成功
* 0x03 - Acknowledgement
* 0x03-确认
* 0x04 - Refresh successful
* 0x04-刷新成功
o Protocol Error:
o 协议错误：
* 0x01 - Illegal message type: the type given in the Message Type field of the common header is unknown.
* 0x01-非法消息类型：公用标头的消息类型字段中给定的类型未知。
* 0x02 - Wrong message length: the length given for the message does not match the length of the message data.
* 0x02-错误的消息长度：为消息指定的长度与消息数据的长度不匹配。
* 0x03 - Bad flags value: an undefined flag or combination of flags was set in the generic flags.
* 0x03-错误标志值：在通用标志中设置了未定义的标志或标志组合。
* 0x04 - Bad flags value: an undefined flag or combination of flags was set in the message-specific flags.
* 0x04-错误标志值：在消息特定标志中设置了未定义的标志或标志组合。
* 0x05 - Mandatory object missing: an object required in a message of this type was missing.
* 0x05-缺少强制对象：缺少此类型消息中所需的对象。
* 0x06 - Illegal object present: an object was present that must not be used in a message of this type.
* 0x06-存在非法对象：存在的对象不能用于此类型的消息中。
* 0x07 - Unknown object present: an object of an unknown type was present in the message.
* 0x07-存在未知对象：消息中存在未知类型的对象。
* 0x08 - Wrong object length: the length given for the object did not match the length of the object data present.
* 0x08-对象长度错误：为对象指定的长度与当前对象数据的长度不匹配。
* 0x09 - RESERVE received from wrong direction.
* 0x09-从错误方向接收到保留。
* 0x0a - Unknown object field value: a field in an object had an unknown value.
* 0x0a-未知对象字段值：对象中的字段具有未知值。
* 0x0b - Duplicate object present.
* 0x0b-存在重复的对象。
* 0x0c - Malformed QSPEC.
* 0x0c-格式不正确的QSPEC。
* 0x0d - Unknown MRI.
* 0x0d-未知MRI。
* 0x0e - Erroneous value in the TLV object's value field.
* 0x0e-TLV对象的值字段中的值错误。
* 0x0f - Incompatible QSPEC.
* 0x0f-不兼容的QSPEC。
o Transient Failure:
o 瞬时故障：
* 0x01 - No GIST reverse-path forwarding state
* 0x01-无GIST反向路径转发状态
* 0x02 - No path state for RESERVE, when doing a receiver-oriented reservation
* 0x02-执行面向接收器的保留时，保留没有路径状态
* 0x03 - RII conflict
* 0x03-RII冲突
* 0x04 - Full QSPEC required
* 0x04-需要完整的QSPEC
* 0x05 - Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE
* 0x05-端到端保留和域内保留之间的同步不匹配
* 0x06 - Reservation preempted
* 0x06-预订被抢占
* 0x07 - Reservation failure
* 0x07-预订失败
* 0x08 - Path truncated - Next peer dead
* 0x08 - Path truncated - Next peer dead
o Permanent Failure:
o 永久性故障：
* 0x01 - Internal or system error
* 0x01-内部或系统错误
* 0x02 - Authorization failure
* 0x02-授权失败
o QoS Model Error:
o QoS模型错误：
This error class can be used by QoS models to add error codes specific to the QoS model being used. All these errors and events are created outside the QoS NSLP itself. The error codes in this class are defined in QoS model specifications. Note that this error class may also include codes that are not purely errors, but rather some non-fatal information.
QoS模型可以使用此错误类来添加特定于所使用QoS模型的错误代码。所有这些错误和事件都是在QoS NSLP本身之外创建的。此类错误代码在QoS模型规范中定义。请注意，此错误类还可能包括并非纯粹错误的代码，而是一些非致命信息。
Error Source Identifier (ESI)
错误源标识符（ESI）
The Error Source Identifier is for diagnostic purposes and its inclusion is OPTIONAL. It is suggested that implementations use this for the IP address, host name, or other identifier of the QNE generating the INFO-SPEC to aid diagnostic activities. A QNE SHOULD NOT be used in any purpose other than error logging or being presented to the user as part of any diagnostic information. A QNE SHOULD NOT attempt to send a message to that address.
错误源标识符用于诊断目的，其包含是可选的。建议实现将其用于生成信息规范的QNE的IP地址、主机名或其他标识符，以帮助诊断活动。QNE不得用于错误记录或作为任何诊断信息的一部分呈现给用户之外的任何目的。QNE不应尝试向该地址发送消息。
If no Error Source Identifier is included, the Error Source Identifier Type field must be zero.
如果未包含错误源标识符，则错误源标识符类型字段必须为零。
Currently three Error Source Identifiers have been defined: IPv4, IPv6, and FQDN.
目前已定义了三个错误源标识符：IPv4、IPv6和FQDN。
Error Source Identifier: IPv4
错误源标识符：IPv4
Error Source Identifier Type: 0x1
错误源标识符类型：0x1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Source Identifier: IPv6
错误源标识符：IPv6
Error Source Identifier Type: 0x2
错误源标识符类型：0x2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 128-bit IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 128-bit IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Source Identifier: FQDN in UTF-8
错误源标识符：UTF-8中的FQDN
Error Source Identifier Type: 0x3
错误源标识符类型：0x3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// FQDN //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// FQDN //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the length of the FQDN is not a multiple of 32-bits, the field is padded with zero octets to the next 32-bit boundary.
如果FQDN的长度不是32位的倍数，则该字段用零个八位字节填充到下一个32位边界。
If a QNE encounters protocol errors, it MAY include additional information, mainly for diagnostic purposes. Additional information MAY be included if the type of an object is erroneous, or a field has an erroneous value.
如果QNE遇到协议错误，它可能包括附加信息，主要用于诊断目的。如果对象的类型错误，或者字段的值错误，则可以包括附加信息。
If the type of an object is erroneous, the following optional error-specific information may be included at the end of the INFO-SPEC.
如果对象类型错误，则信息规范末尾可能包含以下可选错误特定信息。
Object Type Info:
对象类型信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object provides information about the type of object that caused the error.
此对象提供有关导致错误的对象类型的信息。
If a field in an object had an incorrect value, the following Optional error-specific information may be added at the end of the INFO-SPEC.
如果对象中的字段值不正确，则可以在INFO-SPEC末尾添加以下可选错误特定信息。
Object Value Info:
对象值信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Real Object Length: Since the length in the original TLV header may be inaccurate, this field provides the actual length of the object (including the TLV Header) included in the error message.
真实对象长度：由于原始TLV标头中的长度可能不准确，因此此字段提供错误消息中包含的对象（包括TLV标头）的实际长度。
Offset: Indicates which part of the erroneous object is included. When this field is set to "0", the complete object is included. If Offset is bigger than "0", the erroneous object from offset (calculated from the beginning of the object) to the end of the object is included.
偏移：指示包含错误对象的哪一部分。当此字段设置为“0”时，将包含完整的对象。如果偏移量大于“0”，则包括从偏移量（从对象开始计算）到对象结束的错误对象。
Object: The invalid TLV object (including the TLV Header).
对象：无效的TLV对象（包括TLV标头）。
This object carries information about a TLV object that was found to be invalid in the original message. An error message may contain more than one Object Value Info object.
此对象包含有关原始消息中发现无效的TLV对象的信息。错误消息可能包含多个对象值信息对象。
Type: 0x007
类型：0x007
Length: Variable
长度：可变
Value: A list of 128-bit SESSION-IDs used in summary refresh and summary tear messages. All SESSION-IDs are concatenated together.
值：在摘要刷新和摘要删除消息中使用的128位会话ID的列表。所有会话ID都连接在一起。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID n +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID n +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x008
类型：0x008
Length: Variable
长度：可变
Value: A list of 32-bit Reservation Sequence Number (RSN) values. All RSN are concatenated together.
值：32位保留序列号（RSN）值的列表。所有RSN都连接在一起。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number 1 (RSN1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number n (RSNn) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number 1 (RSN1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number n (RSNn) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 0x009
类型：0x009
Length: Fixed - 5 32-bit words
长度：固定-5个32位字
Value: contains a 1-bit Message_Binding_Type (D) that indicates the dependency relation of a message binding. The rest specifies a 128-bit randomly generated value that "uniquely" identifies this particular message.
值：包含指示消息绑定的依赖关系的1位消息绑定类型（D）。其余部分指定一个128位随机生成的值，该值“唯一”标识此特定消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Binding Codes are:
消息绑定代码为：
* 0 - Unidirectional binding dependency
* 0-单向绑定依赖项
* 1 - Bidirectional binding dependency
* 1-双向绑定依赖项
Type: 0x00A
类型：0x00A
Length: Fixed - 5 32-bit words
长度：固定-5个32位字
Value: contains a 1-bit Message_Binding_Type (D) that indicates the dependency relation of a message binding. The rest specifies a 128-bit randomly generated value that refers to a Message ID in another message.
值：包含指示消息绑定的依赖关系的1位消息绑定类型（D）。其余部分指定一个128位随机生成的值，该值引用另一条消息中的消息ID。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bound Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bound Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Binding Codes are:
消息绑定代码为：
* 0 - Unidirectional binding dependency
* 0-单向绑定依赖项
* 1 - Bidirectional binding dependency
* 1-双向绑定依赖项
Type: 0x00B
类型：0x00B
Length: Variable
长度：可变
Value: Variable-length QSPEC (QoS specification) information, which is dependent on the QoS model.
值：可变长度QSPEC（QoS规范）信息，取决于QoS模型。
The contents and encoding rules for this object are specified in other documents. See [RFC5975].
此对象的内容和编码规则在其他文档中指定。参见[RFC5975]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// QSPEC Data //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// QSPEC Data //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section provides the general processing rules used by QoS-NSLP. The triggers communicated between RM/QOSM and QoS-NSLP functionalities are given in Appendices Appendix A.1, Appendix A.2, and Appendix A.3.
本节提供QoS NSLP使用的一般处理规则。附录A.1、附录A.2和附录A.3中给出了RM/QOSM和QoS NSLP功能之间通信的触发器。
The processing of a message and its component objects involves manipulating the QoS NSLP and reservation state of a QNE.
消息及其组件对象的处理涉及操作QoS NSLP和QNE的保留状态。
For each flow, a QNE stores (RMF-related) reservation state that depends on:
对于每个流，QNE存储（RMF相关）保留状态，该状态取决于：
o the QoS model / QSPEC used,
o 使用的QoS模型/QSPEC，
o the QoS NSLP operation state, which includes non-persistent state (e.g., the API parameters while a QNE is processing a message), and
o QoS NSLP操作状态，包括非持久状态（例如，QNE处理消息时的API参数），以及
o the persistent state, which is kept as long as the session is active.
o 持续状态，只要会话处于活动状态，就会保持该状态。
The persistent QoS NSLP state is conceptually organized in a table with the following structure. The primary key (index) for the table is the SESSION-ID:
持久QoS NSLP状态在概念上组织在具有以下结构的表中。表的主键（索引）是SESSION-ID：
SESSION-ID A 128-bit identifier.
会话ID是一个128位的标识符。
The state information for a given key includes:
给定密钥的状态信息包括：
Flow ID Based on GIST MRI. Several entries are possible in case of mobility events.
基于GIST MRI的流量ID。在发生移动事件的情况下，可能会出现多个条目。
SII-Handle for each upstream and downstream peer The SII-Handle is a local identifier generated by GIST and passed over the API. It is a handle that allows to refer to a particular GIST next hop. See SII-Handle in [RFC5971] for more information.
每个上游和下游对等方的SII句柄SII句柄是GIST生成并通过API传递的本地标识符。它是一个允许下一跳引用特定要点的句柄。有关更多信息，请参阅[RFC5971]中的SII句柄。
RSN from the upstream peer The RSN is a 32-bit counter.
来自上游对等方的RSN RSN是一个32位计数器。
The latest local RSN A 32-bit counter.
最新的本地RSN是一个32位计数器。
List of RII for outstanding responses with processing information. The RII is a 32-bit number.
具有处理信息的未完成响应的RII列表。RII是一个32位数字。
State lifetime The state lifetime indicates how long the state that is being signaled for remains valid.
状态生存期状态生存期指示发出信号的状态保持有效的时间。
List of bound sessions A list of BOUND-SESSION-ID 128-bit identifiers for each session bound to this state.
绑定会话列表绑定到此状态的每个会话的绑定会话ID 128位标识符列表。
Scope of the signaling If the Proxy scope is used, a flag is needed to identify all signaling of this session as being scoped.
信令的作用域如果使用代理作用域，则需要一个标志来标识此会话的所有信令的作用域。
Adding the state requirements of all these items gives an upper bound on the state to be kept by a QNE. The need to keep state depends on the desired functionality at the NSLP layer.
添加所有这些项目的状态要求会给出QNE保持状态的上限。保持状态的需要取决于NSLP层所需的功能。
QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP does not have the concept of a message being sent directly to the end of the path. Instead, messages are received by a QNE, which may then send another message (which may be identical to the received message or contain some subset of objects from it) to continue in the same direction (i.e., towards the QNI or QNR) as the message received.
QoS NSLP消息沿路径以对等方式发送。QoS NSLP没有将消息直接发送到路径末端的概念。相反，消息由QNE接收，然后QNE可以发送另一个消息（可能与接收到的消息相同，或者包含来自它的一些对象子集）以在与接收到的消息相同的方向（即，朝向QNI或QNR）上继续。
The decision on whether to generate a message to forward may be affected by the value of the SCOPING or PROXY flags, or by the presence of an RII object.
是否生成要转发的消息的决定可能受作用域或代理标志的值或RII对象的存在的影响。
If a mandatory object is missing from a message then the receiving QNE MUST NOT propagate the message any further. It MUST construct a RESPONSE message indicating the error condition and send it back to the peer QNE that sent the message.
如果消息中缺少强制对象，则接收QNE不得进一步传播该消息。它必须构造一条指示错误条件的响应消息，并将其发送回发送该消息的对等QNE。
If a message contains an object of an unrecognised type, then the behavior depends on the AB extensibility flags.
如果消息包含无法识别类型的对象，则行为取决于AB扩展性标志。
If the Proxy scope flag was set in an incoming QoS NSLP message, the QNE must set the same flag in all QoS NSLP messages it sends that are related to this session.
如果在传入的QoS NSLP消息中设置了代理作用域标志，则QNE必须在其发送的与此会话相关的所有QoS NSLP消息中设置相同的标志。
Retransmissions may happen end-to-end (e.g., between QNI and QNR using an RII object) or peer-to-peer (between two adjacent QNEs). When a QNE transmits a RESERVE with an RII object set, it waits for a RESPONSE from the responding QNE. QoS NSLP messages for which a response is requested by including an RII object, but that fail to elicit a response are retransmitted. Similarly, a QNE may include the ACK-REQ flag to request confirmation of a refresh message
重传可以端到端（例如，使用RII对象的QNI和QNR之间）或对等（两个相邻QNE之间）发生。当QNE传输带有RII对象集的保留时，它等待来自响应QNE的响应。通过包含RII对象请求响应但未能引发响应的QoS NSLP消息将被重新传输。类似地，QNE可以包括ACK-REQ标志以请求对刷新消息的确认
reception from its immediate peer. The retransmitted message should be exactly the same as the original message, e.g., the RSN is not modified with each retransmission.
来自直接同伴的接收。重新传输的消息应与原始消息完全相同，例如，RSN不会随着每次重新传输而修改。
The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). QoS NSLP messages SHOULD be retransmitted until either a RESPONSE (which might be an error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after the initial transmission. In the latter case, a failure SHOULD be indicated to the signaling application. The default values for the above-mentioned timers are:
初始重传发生在QOSNP请求重试等待期之后。必须以指数增长的等待间隔（每次等待时间加倍）进行重新传输。QoS NSLP消息应重新传输，直到获得响应（可能是错误）为止，或者直到首次传输后QOSNSLP_RETRY_MAX秒为止。在后一种情况下，应向信令应用程序指示故障。上述计时器的默认值为：
QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial retransmit of the message
QOSNSLP_请求_重试：消息初始重新传输前的2秒等待间隔
QOSNSLP_RETRY_MAX: 30 seconds Period to retry sending the message before giving up
QOSNSLP_RETRY_最长：在放弃之前重试发送消息的时间为30秒
Retransmissions SHOULD be disabled for tear messages.
应禁用撕裂消息的重新传输。
As discussed in Section 3.2.12, some care needs to be taken to handle cases where the last node on the path may change.
如第3.2.12节所述，在处理路径上最后一个节点可能发生变化的情况时，需要特别小心。
A node that is the last node on the path, but not the data receiver (or an explicitly configured proxy for it), MUST continue to attempt to send messages downstream to probe for path changes. This must be done in order to handle the "Path Extension" case described in Section 5.2.5.1.
作为路径上最后一个节点的节点，但不是数据接收器（或为其显式配置的代理），必须继续尝试向下游发送消息以探测路径更改。为了处理第5.2.5.1节所述的“路径扩展”情况，必须这样做。
A node on the path, that was not previously the last node, MUST take over as the last node on the signaling path if GIST path change detection identifies that there are no further downstream nodes on the path. This must be done in order to handle the "Path Truncation" case described in Section 5.2.5.1.
如果GIST路径更改检测发现路径上没有其他下游节点，则路径上以前不是最后一个节点的节点必须作为信令路径上的最后一个节点接管。为了处理第5.2.5.1节中所述的“路径截断”情况，必须这样做。
In order to handle the spurious route change problem described in Section 3.2.12.2, the RSN must be used in a particular way when maintaining the reservation after a route change is believed to have occurred.
为了处理第3.2.12.2节中所述的虚假路线变更问题，当认为发生路线变更后，在维持预订时，必须以特定方式使用RSN。
We assume that the current RSN (RSN[current]) is initially RSN0.
我们假设当前RSN（RSN[current]）最初为RSN0。
When a route change is believed to have occurred, the QNE SHOULD send a RESERVE message, including the full QSPEC. This must contain an RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII to request a response from the QNR. An SII-Handle MUST NOT be specified when passing this message over the API to GIST, so that the message is correctly routed to the new peer QNE.
当认为发生了路由更改时，QNE应发送保留消息，包括完整的QSPEC。这必须包含一个RSN，其RSN[current]=RSN0+2。它应该包括请求QNR响应的RII。通过API将此消息传递给GIST时，不得指定SII句柄，以便将消息正确路由到新的对等QNE。
When the QNE receives the RESPONSE message that relates to the RESERVE message sent down the new path, it SHOULD send a RESERVE message with the TEAR flag sent down the old path. To do so, it MUST request GIST to use its explicit routing mechanism, and the QoS NSLP MUST supply an SII-Handle relating to the old peer QNE. When sending this RESERVE message, it MUST contain an RSN that is RSN[current] - 1. (RSN[current] remains unchanged.)
当QNE接收到与沿新路径发送的保留消息相关的响应消息时，它应该发送一条保留消息，并沿旧路径发送撕裂标志。为此，它必须请求GIST使用其显式路由机制，并且QoS NSLP必须提供与旧对等QNE相关的SII句柄。发送此保留消息时，它必须包含RSN[current]-1的RSN。（RSN[当前]保持不变。）
If the RESPONSE received after sending the RESERVE down the new path contains the code "Refresh successful" in the INFO-SPEC, then the QNE MAY elect not to send the tearing RESERVE, since this indicates that the path is unchanged.
如果在沿新路径发送保留后收到的响应包含INFO-SPEC中的代码“Refresh successful”，则QNE可能选择不发送撕裂保留，因为这表明路径未更改。
GIST may notify the QoS NSLP that a possible upstream route change has occurred over the GIST API. On receiving such a notification, the QoS NSLP SHOULD send a NOTIFY message with Informational code 0x02 for signaling sessions associated with the identified MRI. If this is sent, it MUST be sent to the old peer using the GIST explicit routing mechanism through the use of the SII-Handle.
GIST可通知QoS NSLP，可能的上游路由改变已通过GIST API发生。在接收到此类通知时，QoS NSLP应发送一条通知消息，其信息代码为0x02，用于与所识别的MRI相关联的信令会话。如果发送此消息，则必须使用GIST显式路由机制通过使用SII句柄将其发送给旧对等方。
On receiving such a NOTIFY message, the QoS NSLP SHOULD use the InvalidateRoutingState API call to inform GIST that routing state may be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. The NOTIFY message should be propagated back to the QNI or QNR.
在收到此类通知消息时，QoS NSLP应使用InvalidateRoutingState API调用通知GIST路由状态可能已过期。QoS NSLP应向上游发送通知消息。通知消息应传播回QNI或QNR。
In some circumstances, a route change may occur, but the path then falls back to the original route.
在某些情况下，可能会发生路由更改，但路径会返回到原始路由。
After a route change the routers on the old path will continue to refresh the reservation until soft state times out or an explicit TEAR is received.
路由更改后，旧路径上的路由器将继续刷新保留，直到软状态超时或收到明确的撕裂。
After detecting an upstream route change, a QNE SHOULD consider the new upstream peer as current and not fall back to the old upstream peer unless:
在检测到上游路由变化之后，QNE应考虑新的上游节点作为电流，而不返回到旧的上游对等节点，除非：
o it stops receiving refreshes from the old upstream peer for at least the soft-state timeout period and then starts receiving messages from the old upstream peer again, or
o 它至少在软状态超时期间停止接收来自旧上游对等方的刷新，然后再次开始接收来自旧上游对等方的消息，或者
o it stops receiving refreshes from the new upstream peer for at least the soft-state timeout period.
o 它至少在软状态超时期间停止接收来自新上游对等方的刷新。
GIST routing state keeps track of the latest upstream peer it has seen, and so may spuriously indicate route changes occur when the old upstream peer refreshes its routing state until the state at that node is explicitly torn down or times out.
GIST路由状态跟踪它所看到的最新上游对等点，因此当旧的上游对等点刷新其路由状态时，可能会错误地指示发生路由更改，直到该节点上的状态被明确删除或超时。
This section presents processing rules for individual QoS NSLP objects.
本节介绍各个QoS NSLP对象的处理规则。
A QNE's own RSN is a sequence number which applies to a particular signaling session (i.e., with a particular SESSION-ID). It MUST be incremented for each new RESERVE message where the reservation for the session changes. The RSN is manipulated using the serial number arithmetic rules from [RFC1982], which also defines wrapping rules and the meaning of 'equals', 'less than', and 'greater than' for comparing sequence numbers in a circular sequence space.
QNE自己的RSN是应用于特定信令会话（即，具有特定会话ID）的序列号。对于会话保留发生更改的每个新保留消息，它必须递增。RSN使用[RFC1982]中的序列号算术规则进行操作，该规则还定义了包装规则和“等于”、“小于”和“大于”的含义，用于比较循环序列空间中的序列号。
The RSN starts at zero. It is stored as part of the per-session state, and it carries on incrementing (i.e., it is not reset to zero) when a downstream peer change occurs. (Note that Section 5.2.5.2 provides some particular rules for use when a downstream peer changes.)
RSN从零开始。它作为每会话状态的一部分存储，当下游对等更改发生时，它将继续递增（即，不会重置为零）。（请注意，第5.2.5.2节提供了一些特定规则，供下游对等方更改时使用。）
The RSN object also contains an Epoch Identifier, which provides a method for determining when a peer has restarted (e.g., due to node reboot or software restart). The exact method for providing this value is implementation defined. Options include storing a serial number that is incremented on each restart, picking a random value on each restart, or using the restart time.
RSN对象还包含一个历元标识符，它提供了一种确定对等机何时重新启动（例如，由于节点重新启动或软件重新启动）的方法。提供此值的确切方法由实现定义。选项包括存储在每次重新启动时递增的序列号、在每次重新启动时拾取随机值或使用重新启动时间。
On receiving a RESERVE message a QNE examines the Epoch Identifier to determine if the peer sending the message has restarted. If the Epoch Identifier is different to that stored for the reservation then the RESERVE message MUST be treated as an updated reservation (even if the RSN is less than the current stored value), and the stored RSN and Epoch Identifier MUST be updated to the new values.
在接收到保留消息时，QNE检查历元标识符以确定发送消息的对等方是否已重新启动。如果历元标识符不同于为保留存储的标识符，则必须将保留消息视为更新的保留（即使RSN小于当前存储的值），并且必须将存储的RSN和历元标识符更新为新值。
When receiving a RESERVE message, a QNE uses the RSN given in the message to determine whether the state being requested is different to that already stored. If the RSN is equal to that stored for the current reservation, the current state MUST be refreshed. If the RSN is greater than the current stored value, the current reservation MUST be modified appropriately as specified in the QSPEC (provided that admission control and policy control succeed), and the stored RSN value updated to that for the new reservation. If the RSN is greater than the current stored value and the RESERVE was a reduced refresh, the QNE SHOULD send upstream a transient error message "Full QSPEC required". If the RSN is less than the current value, then it indicates an out-of-order message, and the RESERVE message MUST be discarded.
当接收到保留消息时，QNE使用消息中给出的RSN来确定所请求的状态是否与已存储的状态不同。如果RSN等于为当前保留存储的RSN，则必须刷新当前状态。如果RSN大于当前存储值，则必须按照QSPEC中的规定适当修改当前保留（前提是准入控制和策略控制成功），并将存储的RSN值更新为新保留的值。如果RSN大于当前存储值，且保留是减少的刷新，则QNE应向上游发送一条瞬态错误消息“需要完整QSPEC”。如果RSN小于当前值，则表示出现故障消息，必须丢弃保留消息。
If the QNE does not store per-session state (and so does not keep any previous RSN values), then it MAY ignore the value of the RSN. It MUST also copy the same RSN into the RESERVE message (if any) that it sends as a consequence of receiving this one.
如果QNE不存储每个会话状态（因此不保留任何以前的RSN值），那么它可能会忽略RSN的值。它还必须将相同的RSN复制到作为接收此RSN的结果而发送的保留消息（如果有）中。
A QNE sending QUERY or RESERVE messages may require a response to be sent. It does so by including a Request Identification Information (RII) object. When creating an RII object, the QNE MUST select the value for the RII such that it is probabilistically unique within the given session. A RII object is typically set by the QNI.
QNE发送查询或保留消息可能需要发送响应。它通过包含请求标识信息（RII）对象来实现。当创建RII对象时，QNE必须为RII选择值，以便它在给定会话中可能是唯一的。RII对象通常由QNI设置。
A number of choices are available when implementing this. Possibilities might include using a random value, or a node identifier together with a counter. If the value collides with one selected by another QNE for a different QUERY, then RESPONSE messages may be incorrectly terminated, and may not be passed back to the node that requested them.
在实现此功能时，有许多选择。可能包括使用随机值，或将节点标识符与计数器一起使用。如果该值与另一个QNE为不同查询选择的值冲突，则响应消息可能会被错误终止，并且可能不会传回请求它们的节点。
The node that created the RII object MUST remember the value used in the RII in order to match back any RESPONSE it will receive. The node SHOULD use a timer to identify situations where it has taken too long to receive the expected RESPONSE. If the timer expires without receiving a RESPONSE, the node MAY perform a retransmission as discussed in Section 5.2.4. In this case, the QNE MUST NOT generate any RESPONSE or NOTIFY message to notify this error.
创建RII对象的节点必须记住RII中使用的值，以便匹配它将收到的任何响应。节点应该使用计时器来识别需要很长时间才能收到预期响应的情况。如果计时器到期而未收到响应，则节点可执行第5.2.4节中讨论的重传。在这种情况下，QNE不得生成任何响应或通知消息来通知此错误。
If an intermediate QNE wants to receive a response for an outgoing message, but the message already included an RII when it arrived, the QNE MUST NOT add a new RII object nor replace the old RII object, but MUST simply remember this RII in order to match a later RESPONSE message. When it receives the RESPONSE, it forwards the RESPONSE upstream towards the RII originating node. Note that only the node
如果中间QNE希望接收传出消息的响应，但消息到达时已包含RII，则QNE不得添加新的RII对象或替换旧的RII对象，但必须记住此RII以匹配稍后的响应消息。当它接收到响应时，它将响应向上游转发到RII发起节点。请注意，只有节点
that originally created the RII can set up a retransmission timer. Thus, if an intermediate QNE decides to use the RII already contained in the message, it MUST NOT set up a retransmission timer, but rely on the retransmission timer set up by the QNE that inserted the RII.
最初创建的RII可以设置重传计时器。因此，如果中间QNE决定使用已经包含在消息中的RII，则它不能设置重传计时器，而是依赖于插入RII的QNE设置的重传计时器。
When receiving a message containing an RII object the node MUST send a RESPONSE if
当接收到包含RII对象的消息时，节点必须在以下情况下发送响应：
o The SCOPING flag is set ('next hop' scope),
o 设置范围标志（“下一跳”范围），
o The PROXY scope flag is set and the QNE is the P-QNE, or
o 设置代理作用域标志，且QNE为P-QNE，或
o This QNE is the last one on the path for the given session.
o 此QNE是给定会话路径上的最后一个QNE。
and the QNE keeps per-session state for the given session.
并且QNE保持给定会话的每个会话状态。
In the rare event that the QNE wants to request a response for a message that already included an RII, and this RII value conflicts with an existing RII value on the QNE, the node should interrupt the processing the message, send an error message upstream to indicate an RII collision, and request a retry with a new RII value.
在QNE希望请求对已包含RII的消息的响应，并且该RII值与QNE上的现有RII值冲突的罕见事件中，节点应中断消息处理，向上游发送错误消息以指示RII冲突，并请求使用新RII值重试。
As shown in the examples in Section 4, the QoS NSLP can relate multiple sessions together. It does this by including the SESSION-ID from one session in a BOUND-SESSION-ID object in messages in another session.
如第4节中的示例所示，QoS NSLP可以将多个会话关联在一起。它通过将一个会话中的SESSION-ID包含在另一个会话的消息中的绑定SESSION-ID对象中来实现。
When receiving a message with a BOUND-SESSION-ID object, a QNE MUST copy the BOUND-SESSION-ID object into all messages it sends for the same session. A QNE that stores per-session state MUST store the value of the BOUND-SESSION-ID.
当接收带有绑定会话ID对象的消息时，QNE必须将绑定会话ID对象复制到它为同一会话发送的所有消息中。存储每个会话状态的QNE必须存储绑定会话ID的值。
The BOUND-SESSION-ID is only indicative in nature. However, a QNE implementation may use BOUND-SESSION-ID information to optimize resource allocation, e.g., for bidirectional reservations. When receiving a teardown message (e.g., a RESERVE message with teardown semantics) for an aggregate reservation, the QNE may use this information to initiate a teardown for end-to-end sessions bound to the aggregate. A QoS NSLP implementation MUST be ready to process more than one BOUND-SESSION-ID object within a single message.
绑定会话ID只是指示性的。然而，QNE实现可以使用绑定会话ID信息来优化资源分配，例如，用于双向预约。当接收到用于聚合保留的拆卸消息（例如，具有拆卸语义的保留消息）时，QNE可以使用该信息来启动绑定到聚合的端到端会话的拆卸。QoS NSLP实现必须准备好在单个消息中处理多个绑定会话ID对象。
Refresh timer management values are carried by the REFRESH-PERIOD object, which has local significance only. At the expiration of a "refresh timeout" period, each QNE independently examines its state
刷新计时器管理值由刷新周期对象携带，该对象仅具有局部意义。在“刷新超时”期限到期时，每个QNE独立检查其状态
and sends a refreshing RESERVE message to the next QNE peer where it is absorbed. This peer-to-peer refreshing (as opposed to the QNI initiating a refresh that travels all the way to the QNR) allows QNEs to choose refresh intervals as appropriate for their environment. For example, it is conceivable that refreshing intervals in the backbone, where reservations are relatively stable, are much larger than in an access network. The "refresh timeout" is calculated within the QNE and is not part of the protocol; however, it must be chosen to be compatible with the reservation lifetime as expressed by the REFRESH-PERIOD and with an assessment of the reliability of message delivery.
并将刷新保留消息发送到下一个吸收该消息的QNE对等方。这种点对点刷新（与QNI发起一个一直到QNR的刷新相反）允许QNE根据其环境选择适当的刷新间隔。例如，可以想象，保留相对稳定的主干中的刷新间隔比接入网络中的要大得多。“刷新超时”是在QNE内计算的，不是协议的一部分；但是，必须选择与刷新周期表示的保留生存期兼容，并对消息传递的可靠性进行评估。
The details of timer management and timer changes (slew handling and so on) are identical to the ones specified in Section 3.7 of RFC 2205 [RFC2205].
定时器管理和定时器更改（回转处理等）的细节与RFC 2205[RFC2205]第3.7节中规定的相同。
There are two time parameters relevant to each QoS NSLP state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RESERVE message may contain a REFRESH-PERIOD object specifying the R value that was used to generate this (refresh) message. This R value is then used to determine the value for L when the state is received and stored. The values for R and L may vary from peer to peer.
有两个时间参数与节点中的每个QoS NSLP状态相关：邻居节点为该状态生成连续刷新之间的刷新周期R和本地状态的生存期L。每个保留消息可能包含一个刷新周期对象，指定用于生成该（刷新）消息的R值。然后，当接收并存储状态时，该R值用于确定L的值。R和L的值可能因点而异。
The INFO-SPEC object is carried by the RESPONSE and NOTIFY messages, and it is used to report a successful, an unsuccessful, or an error situation. In case of an error situation, the error messages SHOULD be generated even if no RII object is included in the RESERVE or in the QUERY messages. Note that when the TEAR flag is set in the RESERVE message an error situation SHOULD NOT trigger the generation of a RESPONSE message.
INFO-SPEC对象由响应和通知消息携带，用于报告成功、失败或错误情况。如果出现错误情况，即使保留区或查询消息中未包含RII对象，也应生成错误消息。请注意，在保留消息中设置撕裂标志时，错误情况不应触发响应消息的生成。
Six classes of INFO-SPEC objects are identified and specified in Section 5.1.3.6. The message processing rules for each class are defined below.
第5.1.3.6节确定并规定了六类INFO-SPEC对象。下面定义了每个类的消息处理规则。
A RESPONSE message MUST carry INFO-SPEC objects towards the QNI. The RESPONSE message MUST be forwarded unconditionally up to the QNI. The actions that SHOULD be undertaken by the QNI that receives the INFO-SPEC object are specified by the local policy of the QoS model supported by this QNE. The default action is that the QNI that receives the INFO-SPEC object SHOULD NOT trigger any other QoS NSLP procedure.
响应消息必须携带面向QNI的INFO-SPEC对象。响应消息必须无条件转发至QNI。接收INFO-SPEC对象的QNI应执行的操作由该QNE支持的QoS模型的本地策略指定。默认操作是接收INFO-SPEC对象的QNI不应触发任何其他QoS NSLP过程。
The Informational INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when an Informational error class is caught. The Informational INFO-SPEC object MUST be carried by a RESPONSE or a NOTIFY message.
当捕捉到信息性错误类时，信息性INFO-SPEC类必须由有状态QoS NSLP QNE生成。信息性INFO-SPEC对象必须由响应或通知消息携带。
In case of a unidirectional reservation, the Success INFO-SPEC class MUST be generated by a stateful QoS NSLP QNR when a RESERVE message is received and the reservation state installation or refresh succeeded. In case of a bidirectional reservation, the INFO-SPEC object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE message is received and the reservation state installation or refresh succeeded. The Success INFO-SPEC object MUST be carried by a RESPONSE or a NOTIFY message.
在单向保留的情况下，当接收到保留消息且保留状态安装或刷新成功时，成功信息规范类必须由有状态QoS NSLP QNR生成。在双向保留的情况下，当接收到保留消息且保留状态安装或刷新成功时，有状态QoS NSLP QNE应生成INFO-SPEC对象。成功信息规范对象必须由响应或通知消息携带。
In case of a unidirectional reservation, the Protocol Error INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and a protocol error is caught. In case of a bidirectional reservation, the Protocol Error INFO-SPEC class SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and a protocol error is caught. A RESPONSE message MUST carry this object, which MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered the generation of this INFO-SPEC object. The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed, and the RESERVE or QUERY message SHOULD be forwarded downstream.
在单向保留的情况下，当QNE接收到保留或查询消息并且捕获到协议错误时，有状态QoS NSLP QNE必须生成协议错误信息规范类。在双向保留的情况下，当QNE接收到保留或查询消息并捕获到协议错误时，有状态QoS NSLP QNE应生成协议错误信息规范类。响应消息必须携带此对象，该对象必须无条件地转发到生成保留或查询消息（触发生成此INFO-SPEC对象）的上游QNE。检测到此类错误的无状态QoS NSLP QNE的默认操作是不应处理任何QoS NSLP对象，并且应将保留或查询消息转发到下游。
In case of a unidirectional reservation, the Transient Failure INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and one Transient failure error code is caught, or when an event happens that causes a transient error. In case of a bidirectional reservation, the Transient Failure INFO-SPEC class SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and one Transient failure error code is caught.
在单向保留的情况下，当QNE接收到保留或查询消息并捕获一个瞬时故障错误代码时，或当发生导致瞬时错误的事件时，瞬时故障信息规范类必须由有状态QoS NSLP QNE生成。在双向保留的情况下，当QNE接收到保留或查询消息并且捕获到一个瞬时故障错误代码时，瞬时故障信息规范类应由有状态QoS NSLP QNE生成。
A RESPONSE message MUST carry this object, which MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered the generation of this INFO-SPEC object. The transient RMF-related error MAY also be carried by a NOTIFY message. The default action is that the QNE that receives this INFO-SPEC object SHOULD re-trigger the retransmission of the RESERVE or QUERY message that triggered the generation of the INFO-SPEC object. The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message SHOULD be forwarded downstream.
响应消息必须携带此对象，该对象必须无条件地转发到生成保留或查询消息（触发生成此INFO-SPEC对象）的上游QNE。瞬时RMF相关错误也可能由NOTIFY消息携带。默认操作是，接收此INFO-SPEC对象的QNE应重新触发触发生成INFO-SPEC对象的保留或查询消息的重新传输。检测到此类错误的无状态QoS NSLP QNE的默认操作是不应处理任何QoS NSLP对象，并且应将保留或查询消息转发到下游。
In case of a unidirectional reservation, the Permanent Failure INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by a QNE and an internal or system error occurred, or authorization failed. In case of a bidirectional reservation, the Permanent Failure INFO-SPEC class SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by a QNE and an internal or system error occurred, or authorization failed. A RESPONSE message MUST carry this object, which MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered this protocol error. The internal, system, or permanent RMF-related errors MAY also be carried by a NOTIFY message. The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message SHOULD be forwarded downstream.
在单向保留的情况下，当QNE收到保留或查询消息且发生内部或系统错误或授权失败时，有状态QoS NSLP QNE必须生成永久故障信息规范类。在双向保留的情况下，当QNE收到保留或查询消息且发生内部或系统错误或授权失败时，有状态QoS NSLP QNE应生成永久故障信息规范类。响应消息必须携带此对象，该对象必须无条件转发到生成触发此协议错误的保留或查询消息的上游QNE。与RMF相关的内部、系统或永久性错误也可以通过NOTIFY消息携带。检测到此类错误的无状态QoS NSLP QNE的默认操作是不应处理任何QoS NSLP对象，并且应将保留或查询消息转发到下游。
The QoS-specific error class may be used when errors outside the QoS NSLP itself occur that are related to the particular QoS model being used. The processing rules of these errors are not specified in this document.
当发生与所使用的特定QoS模型相关的QoS NSLP自身之外的错误时，可以使用QoS特定错误类。本文档中未指定这些错误的处理规则。
A SESSION-ID-LIST is carried in RESERVE messages. It is used in two cases, to refresh or to tear down the indicated sessions. A SESSION-ID-LIST carries information about sessions that should be refreshed or torn down, in addition to the main (primary) session indicated in the RESERVE.
保留消息中包含会话ID列表。它用于两种情况，刷新或中断指定的会话。SESSION-ID-LIST除了保留中指示的主（主）会话外，还包含有关应该刷新或删除的会话的信息。
If the primary SESSION-ID is not understood, the SESSION-ID-LIST object MUST NOT be processed.
如果未理解主会话ID，则不得处理会话ID列表对象。
When a stateful QNE goes through the SESSION-ID-LIST, if it finds one or more unknown SESSION-ID values, it SHOULD construct an informational RESPONSE message back to the upstream stateful QNE with the error code for unknown SESSION-ID in SESSION-ID-LIST, and include all unknown SESSION-IDs in a SESSION-ID-LIST.
当一个有状态QNE通过SESSION-ID-LIST时，如果它发现一个或多个未知SESSION-ID值，它应该构造一条信息性响应消息，返回到上游有状态QNE，并在SESSION-ID-LIST中包含未知SESSION-ID的错误代码，并在SESSION-ID-LIST中包含所有未知SESSION-ID。
If the RESERVE is a tear, for each session in the SESSION-ID-LIST, the stateful QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST also be interpreted in order to distinguish whether the tear down is valid, or whether it is referring to an old state, and, thus, should be silently discarded.
如果保留是撕裂，对于session-ID-LIST中的每个会话，有状态的QNE必须通知RMF不再需要保留。还必须对RSN值进行解释，以区分拆除是否有效，或是否引用旧状态，因此，应默默放弃。
If the RESERVE is a refresh, the stateful QNE MUST also process the RSN-LIST object as detailed in the next section.
如果保留是刷新，则有状态QNE还必须处理RSN-LIST对象，详见下一节。
If the RESERVE is a tear, for each session in the SESSION-ID-LIST, the QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST be interpreted.
如果保留是撕裂，对于会话ID列表中的每个会话，QNE必须通知RMF不再需要保留。必须解释RSN值。
Note that a stateless QNE cannot support summary or single reduced refreshes, and always needs full single refreshes.
请注意，无状态QNE不支持摘要刷新或单个精简刷新，并且始终需要完整的单个刷新。
An RSN-LIST MUST be carried in RESERVE messages when a QNE wants to perform a refresh or teardown of several sessions with a single NSLP message. The RSN-LIST object MUST be populated with RSN values of the same sessions and in the same order as indicated in the SESSION-ID-LIST. Thus, entries in both objects at position X refer to the same session.
当QNE希望使用单个NSLP消息刷新或拆除多个会话时，必须在保留消息中携带RSN-LIST。RSN-LIST对象必须使用相同会话的RSN值填充，填充顺序与会话ID-LIST中指示的顺序相同。因此，位置X处两个对象中的条目都引用同一会话。
If the primary session and RSN reference in the RESERVE were not understood, the stateful QNE MUST NOT process the RSN-LIST. Instead, an error RESPONSE SHOULD be sent back to the upstream stateful QNE.
如果未理解保留区中的主会话和RSN引用，则有状态QNE不得处理RSN-LIST。相反，应该将错误响应发送回上游有状态QNE。
On receiving an RSN-LIST object, the stateful QNE should check whether the number of items in the SESSION-ID-LIST and RSN-LIST objects match. If there is a mismatch, the stateful QNE SHOULD send back a protocol error indicating a bad value in the object.
在接收到RSN-LIST对象时，有状态QNE应检查SESSION-ID-LIST和RSN-LIST对象中的项目数是否匹配。如果存在不匹配，则有状态QNE应发回协议错误，指示对象中存在错误值。
While matching the RSN-LIST values to the SESSION-ID-LIST values, if one or more RSN values in the RSN-LIST are not in synch with the local values, the stateful QNE SHOULD construct an informational RESPONSE message with an error code for RSN mismatch in the RSN-LIST. The stateful QNE MUST include the erroneous SESSION-ID and RSN values in SESSION-ID-LIST and RSN-LIST objects in the RESPONSE.
将RSN-LIST值与会话ID-LIST值匹配时，如果RSN-LIST中的一个或多个RSN值与本地值不同步，则有状态QNE应构造一条信息性响应消息，其中包含RSN-LIST中RSN不匹配的错误代码。有状态QNE必须在响应中的SESSION-ID-LIST和RSN-LIST对象中包含错误的SESSION-ID和RSN值。
If no errors were found in processing the RSN-LIST, the stateful QNE refreshes the reservation states of all sessions -- the primary single session indicated in the refresh, and all sessions in the SESSION-ID-LIST.
如果在处理RSN-LIST时未发现错误，则有状态QNE将刷新所有会话的保留状态——刷新中指示的主要单个会话以及会话ID-LIST中的所有会话。
For each successfully processed session in the RESERVE, the stateful QNE performs a refresh of the reservation state. Thus, even if some sessions were not in synch, the remaining sessions in the SESSION-ID-LIST and RSN-LIST are refreshed.
对于保留中每个成功处理的会话，有状态QNE都会刷新保留状态。因此，即使某些会话不同步，SESSION-ID-LIST和RSN-LIST中的其余会话也会刷新。
The contents of the QSPEC depend on the QoS model being used. A template for QSPEC objects can be found in [RFC5975].
QSPEC的内容取决于所使用的QoS模型。QSPEC对象的模板可在[RFC5975]中找到。
Upon reception, the complete QSPEC is passed to the Resource Management Function (RMF), along with other information from the message necessary for the RMF processing. A QNE may also receive an INFO-SPEC that includes a partial or full QSPEC. This will also be passed to the RMF.
接收后，完整的QSPEC连同RMF处理所需的消息中的其他信息一起传递给资源管理功能（RMF）。QNE还可以接收包含部分或全部QSPEC的信息规范。这也将传递给RMF。
This section provides rules for message processing. Not all possible error situations are considered. A general rule for dealing with erroneous messages is that a node should evaluate the situation before deciding how to react. There are two ways to react to erroneous messages:
本节提供消息处理的规则。并非所有可能的错误情况都被考虑在内。处理错误消息的一般规则是，节点应在决定如何反应之前评估情况。有两种方法可以对错误消息作出反应：
a) Silently drop the message, or
a) 悄悄地删除消息，或者
b) Drop the message, and reply with an error code to the sender.
b) 删除邮件，并向发件人回复错误代码。
The default behavior, in order to protect the QNE from a possible denial-of-service attack, is to silently drop the message. However, if the QNE is able to authenticate the sender, e.g., through GIST, the QNE may send a proper error message back to the neighbor QNE in order to let it know that there is an inconsistency in the states of adjacent QNEs.
为了保护QNE免受可能的拒绝服务攻击，默认行为是静默地丢弃消息。然而，如果QNE能够例如通过GIST认证发送方，则QNE可以向邻居QNE发送正确的错误消息，以便让其知道相邻QNE的状态中存在不一致。
The RESERVE message is used to manipulate QoS reservation state in QNEs. A RESERVE message may create, refresh, modify, or remove such state. A QNE sending a RESERVE MAY require a response to be sent by including a Request Identification Information (RII) object; see Section 5.3.2.
RESERVE消息用于操作QNE中的QoS保留状态。保留消息可以创建、刷新、修改或删除此类状态。发送保留的QNE可能要求通过包括请求标识信息（RII）对象来发送响应；见第5.3.2节。
RESERVE messages MUST only be sent towards the QNR. A QNE that receives a RESERVE message checks the message format. In case of malformed messages, the QNE MAY send a RESPONSE message with the appropriate INFO-SPEC.
保留消息只能发送到QNR。接收保留消息的QNE检查消息格式。如果消息格式不正确，QNE可能会发送带有适当信息规范的响应消息。
Before performing any state-changing actions, a QNE MUST determine whether the request is authorized. The way to do this check depends on the authorization model being used.
在执行任何状态更改操作之前，QNE必须确定请求是否已授权。执行此检查的方式取决于所使用的授权模型。
When the RESERVE is authorized, a QNE checks the COMMON-HEADER flags. If the TEAR flag is set, the message is a tearing RESERVE that indicates complete QoS NSLP state removal (as opposed to a reservation of zero resources). On receiving such a RESERVE message,
当保留被授权时，QNE检查公共标头标志。如果设置了撕裂标志，则消息是一个撕裂保留，表示完全删除QoS NSLP状态（与零资源保留相反）。在收到这种保留信息时，
the QNE MUST inform the RMF that the reservation is no longer required. The RSN value MUST be processed. After this, there are two modes of operation:
QNE必须通知RMF不再需要预订。必须处理RSN值。在此之后，有两种操作模式：
1. If the tearing RESERVE did not include an RII, i.e., the QNI did not want a confirmation, the QNE SHOULD remove the QoS NSLP state. It MAY signal to GIST (over the API) that reverse-path state for this reservation is no longer required. Any errors in processing the tearing RESERVE SHOULD NOT be sent back towards the QNI since the upstream QNEs will already have removed their session states; thus, they are unable to do anything to the error.
1. 如果撕裂保留不包括RII，即QNI不需要确认，则QNE应移除QoS NSLP状态。它可能会（通过API）向GIST发出信号，表示不再需要此保留的反向路径状态。处理撕裂保留时的任何错误都不应发送回QNI，因为上游QNE将已经删除其会话状态；因此，他们无法对错误采取任何措施。
2. If an RII was included, the stateful QNE SHOULD still keep the NSLP operational state until a RESPONSE for the tear going towards the QNI is received. This operational state SHOULD be kept for one refresh interval, after which the NSLP operational state for the session is removed. Depending on the QoS model, the tear message MAY include a QSPEC to further specify state removal. If the QoS model requires a QSPEC, and none is provided, the QNE SHOULD reply with an error message and SHOULD NOT remove the reservation.
2. 如果包含RII，则有状态QNE仍应保持NSLP运行状态，直到收到朝向QNI的撕裂响应。此操作状态应保持一个刷新间隔，然后删除会话的NSLP操作状态。根据QoS模型，撕裂消息可以包括QSPEC以进一步指定状态移除。如果QoS模型需要QSPEC，但未提供任何QSPEC，则QNE应回复错误消息，并且不应删除保留。
If the tearing RESERVE includes a QSPEC, but none is required by the QoS model, the QNE MAY silently discard the QSPEC and proceed as if it did not exist in the message. In general, a QoS NSLP implementation should carefully consider when an error message should be sent, and when not. If the tearing RESERVE did not include an RII, then the upstream QNE has removed the RMF and NSLP states, and it will not be able to do anything to the error. If an RII was included, the upstream QNE may still have the NSLP operational state, but no RMF state.
如果撕裂保留包括QSPEC，但是QoS模型不需要QSPEC，则QNE可以默默地丢弃QSPEC并继续，就好像它在消息中不存在一样。一般来说，QoS NSLP实现应该仔细考虑何时发送错误消息，何时不发送错误消息。如果撕裂储备不包括RII，则上游QNE已移除RMF和NSLP状态，并且它将无法对错误进行任何处理。如果包括RII，则上游QNE可能仍然具有NSLP运行状态，但没有RMF状态。
If a QNE receives a tearing RESERVE for a session for which it still has the operational state, but the RMF state was removed, the QNE SHOULD accept the message and forward it downstream as if all is well.
如果QNE接收到一个会话的撕裂保留，而该会话仍处于可操作状态，但RMF状态已被删除，则QNE应接受该消息并将其转发到下游，就像一切正常一样。
If the tearing RESERVE includes a SESSION-ID-LIST, the stateful QNE MUST process the object as described earlier in this document, and for each identified session, indicate to the RMF that the reservation is no longer required.
如果保留包括SESSION-ID-LIST，则有状态QNE必须按照本文档前面所述处理对象，并且对于每个已识别的会话，向RMF指示不再需要保留。
If a QNE receives a refreshing RESERVE for a session for which it still has the operational state, but the RMF state was removed, the QNE MUST silently drop the message and not forward it downstream.
如果QNE接收到会话的刷新保留，但该会话的状态仍为操作状态，但RMF状态已被删除，则QNE必须以静默方式删除该消息，而不是将其转发到下游。
As discussed in Section 5.2.5.2, to avoid incorrect removal of state after a rerouting event, a node receiving a RESERVE message that has the TEAR flag set and that does not come from the current peer QNE (identified by its SII) MUST be ignored and MUST NOT be forwarded.
如第5.2.5.2节所述，为了避免在重路由事件后错误地删除状态，必须忽略接收保留消息的节点，该保留消息设置了撕裂标志，并且该保留消息不是来自当前对等QNE（由其SII标识），并且不得转发。
If the QNE has reservations that are bound and dependent to this session (they contain the SESSION-ID of this session in their BOUND-SESSION-ID object and use Binding Code 0x04), it MUST send a NOTIFY message for each of the reservations with an appropriate INFO-SPEC. If the QNE has reservations that are bound, but that they are not dependent to this session (the Binding Code in the BOUND-SESSION-ID object has one of the values: 0x01, 0x02, or 0x03), it MAY send a NOTIFY message for each of the reservations with an appropriate INFO-SPEC. The QNE MAY elect to send RESERVE messages with the TEAR flag set for these reservations.
如果QNE具有绑定并依赖于此会话的保留（它们在其绑定会话ID对象中包含此会话的会话ID，并使用绑定代码0x04），则必须为每个保留发送一条通知消息，其中包含相应的信息规范。如果QNE具有绑定的保留，但是，如果它们不依赖于此会话（BOUND-session-ID对象中的绑定代码具有以下值之一：0x01、0x02或0x03），则它可以使用适当的信息规范为每个保留发送通知消息。QNE可以选择使用为这些保留设置的撕裂标志发送保留消息。
The default behavior of a QNE that receives a RESERVE with a SESSION-ID for which it already has state installed but with a different flow ID is to replace the existing reservation (and to tear down the reservation on the old branch if the RESERVE is received with a different SII).
QNE接收具有已安装状态但具有不同流ID的会话ID保留的默认行为是替换现有保留（如果使用不同的SII接收保留，则在旧分支上删除保留）。
In some cases, this may not be the desired behavior, so the QNI or a QNE MAY set the REPLACE flag in the common header to zero to indicate that the new session does not replace the existing one.
在某些情况下，这可能不是期望的行为，因此QNI或QNE可能会将公共头中的替换标志设置为零，以指示新会话不会替换现有会话。
A QNE that receives a RESERVE with the REPLACE flag set to zero but with the same SII will indicate REPLACE=0 to the RMF (where it will be used for the resource handling). Furthermore, if the QNE maintains a QoS NSLP state, then it will also add the new flow ID in the QoS NSLP state. If the SII is different, this means that the QNE is a merge point. In that case, in addition to the operations specified above, the value REPLACE=0 is also indicating that a tearing RESERVE SHOULD NOT be sent on the old branch.
接收REPLACE标志设置为零但SII相同的保留的QNE将向RMF指示REPLACE=0（在RMF中，它将用于资源处理）。此外，如果QNE保持QoS NSLP状态，那么它还将在QoS NSLP状态中添加新的流ID。如果SII不同，这意味着QNE是一个合并点。在这种情况下，除了上面指定的操作外，值REPLACE=0还指示不应在旧分支上发送撕裂保留。
When a QNE receives a RESERVE message with an unknown SESSION-ID and this message contains no QSPEC because it was meant as a refresh, then the node MUST send a RESPONSE message with an INFO-SPEC that indicates a missing QSPEC to the upstream peer ("Full QSPEC required"). The upstream peer SHOULD send a complete RESERVE (i.e., one containing a QSPEC) on the new path (new SII).
当QNE接收到具有未知会话ID的保留消息且该消息不包含QSPEC（因为它是用于刷新的）时，节点必须向上游对等方发送一条带有指示缺少QSPEC的INFO-SPEC的响应消息（“需要完整QSPEC”）。上游对等方应在新路径（新SII）上发送完整的保留（即，包含QSPEC的保留）。
At a QNE, resource handling is performed by the RMF. For sessions with the REPLACE flag set to zero, we assume that the QoS model includes directions to deal with resource sharing. This may include adding the reservations or taking the maximum of the two or more complex mathematical operations.
在QNE，资源处理由RMF执行。对于REPLACE标志设置为零的会话，我们假设QoS模型包括处理资源共享的方向。这可能包括添加保留或最多进行两个或更多复杂的数学运算。
This resource-handling mechanism in the QoS model is also applicable to sessions that have different SESSION-IDs but that are related through the BOUND-SESSION-ID object. Session replacement is not an issue here, but the QoS model may specify whether or not to let the sessions that are bound together share resources on common links.
QoS模型中的资源处理机制也适用于具有不同会话ID但通过绑定会话ID对象相关的会话。会话替换在这里不是问题，但是QoS模型可以指定是否让绑定在一起的会话共享公共链路上的资源。
Finally, it is possible that a RESERVE is received with no QSPEC at all. This is the case of a reduced refresh. In this case, rather than sending a refreshing RESERVE with the full QSPEC, only the SESSION-ID and the RSN are sent to refresh the reservation. Note that this mechanism just reduces the message size (and probably eases processing). One RESERVE per session is still needed. Such a reduced refresh may further include a SESSION-ID-LIST and RSN-LIST, which indicate further sessions to be refreshed along the primary session. The processing of these objects was described earlier in this document.
最后，可能接收到的储备根本没有QSPEC。这是减少刷新的情况。在这种情况下，只发送SESSION-ID和RSN来刷新保留，而不是发送带有完整QSPEC的刷新保留。注意，这种机制只是减少了消息的大小（并且可能简化了处理）。每个会话仍然需要一个保留。这种减少的刷新可进一步包括会话ID-LIST和RSN-LIST，其指示沿主会话刷新的进一步会话。这些对象的处理在本文档前面进行了描述。
If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC contained in the message (if the QSPEC is missing, the QNE SHOULD indicate this error by replying with a RESPONSE containing the corresponding INFO-SPEC "Full QSPEC required"). It MUST update the lifetime of the reservation. If the REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation state if the SII that is passed by GIST over the API is different than the SII that was stored for this reservation. The QNE MAY elect to keep sending refreshing RESERVE messages.
如果设置了替换标志，QNE应根据消息中包含的QSPEC更新保留状态（如果QSPEC缺失，QNE应通过回复包含相应信息规范“需要完整QSPEC”的响应来指示此错误）。它必须更新保留的生存期。如果未设置替换标志，则如果GIST通过API传递的SII与为此保留存储的SII不同，则QNE不应删除旧保留状态。QNE可以选择继续发送刷新保留消息。
If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag set, then the BREAK flag of newly generated messages (e.g., RESERVE or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag not set, then the IP-TTL and Original-TTL values in the GIST RecvMessage primitive MUST be monitored. If they differ, it is RECOMMENDED to set the BREAK flag in newly generated messages (e.g., RESERVE or RESPONSE). In situations where a QNE or a domain is able to provide QoS using other means (see Section 3.3.5), the BREAK flag SHOULD NOT be set.
如果有状态QoS NSLP QNE接收到设置了中断标志的保留消息，则必须设置新生成消息的中断标志（例如，保留或响应）。当有状态QoS NSLP QNE接收到未设置中断标志的保留消息时，必须监视GIST RecVMMessage原语中的IP-TTL和原始TTL值。如果它们不同，建议在新生成的消息（例如保留或响应）中设置中断标志。在QNE或域能够使用其他方式提供QoS的情况下（见第3.3.5节），不应设置中断标志。
If the RESERVE message included an RII, and any of the following are true, the QNE MUST send a RESPONSE message:
如果保留消息包含RII，且以下任何一项为真，则QNE必须发送响应消息：
o If the QNE is configured, for a particular session, to be a QNR,
o 如果针对特定会话将QNE配置为QNR，
o the SCOPING flag is set,
o 设置范围标志，
o the Proxy scope flag is set and the QNE is a P-QNE, or
o 设置代理作用域标志，且QNE为P-QNE，或
o the QNE is the last QNE on the path to the destination.
o QNE是到达目的地的路径上的最后一个QNE。
When a QNE receives a RESERVE message, its processing may involve sending out another RESERVE message.
当QNE接收到保留消息时，其处理可能涉及发送另一个保留消息。
If a QNE has received a RESPONSE mandating the use of full refreshes from its downstream peer for a session, the QNE MUST continue to use full refresh messages.
如果QNE接收到一个响应，要求其下游对等方对会话使用完全刷新，则QNE必须继续使用完全刷新消息。
If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s).
如果此消息的会话绑定到另一个会话，则保留消息必须在绑定会话ID对象中包含该另一个会话的会话ID。在聚合隧道的情况下，聚合会话可能不包括绑定会话ID中其绑定会话的会话ID。
In case of receiver-initiated reservations, the RESERVE message must follow the same path that has been followed by the QUERY message. Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the message upstream, i.e., by setting GIST "D" flag; see GIST [RFC5971].
对于接收方发起的保留，保留消息必须遵循与查询消息相同的路径。因此，通过QoS NSLP/GIST API，通知GIST向上游传递消息，即，通过设置GIST“D”标志；参见要点[RFC5971]。
The QNE MUST create a new RESERVE and send it to its next peer, when:
在以下情况下，QNE必须创建新的保留并将其发送给下一个对等方：
- A new resource setup was done,
- 完成了新的资源设置，
- A new resource setup was not done, but the QOSM still defines that a RESERVE must be propagated,
- 未完成新的资源设置，但QOSM仍定义必须传播保留，
- The RESERVE is a refresh and includes a new MRI, or
- 保留是一个刷新，包括一个新的MRI，或
- If the RESERVE-INIT flag is included in an arrived QUERY.
- 如果到达的查询中包含RESERVE-INIT标志。
If the QNE sent out a refresh RESERVE with the ACK-REQ flag set, and did not receive a RESPONSE from its immediate stateful peer within the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a NOTIFY to its immediate upstream stateful peer and indicate "Path truncated - Next peer dead" in the INFO-SPEC. The ACK-REQ flag SHOULD NOT be added to a RESERVE that already include an RII object, since a confirmation from the QNR has already been requested.
如果QNE发送了设置了ACK-REQ标志的刷新保留，并且在QOSNP_RETRY_MAX的重传周期内没有从其直接有状态对等方收到响应，则QNE应向其直接上游有状态对等方发送通知，并指示“路径截断-下一个对等方死亡”在INFO-SPEC中，ACK-REQ标志不应添加到已包含RII对象的保留中，因为已请求QNR的确认。
Finally, if a received RESERVE requested acknowledgement through the ACK-REQ flag in the COMMON HEADER flags and the processing of the message was successful, the stateful QNE SHOULD send back a RESPONSE with an INFO-SPEC carrying the acknowledgement success code. The QNE MAY include the ACK-REQ flag in the next refresh message it will send for the session. The use of the ACK-REQ-flag for diagnostic purposes is a policy issue. An acknowledged refresh message can be used to probe the end-to-end path in order to check that it is still intact.
最后，如果接收到的保留请求通过公共报头标志中的ACK-REQ标志确认，并且消息处理成功，则有状态QNE应发送回带有带有确认成功代码的INFO-SPEC的响应。QNE可在其将为会话发送的下一个刷新消息中包括ACK-REQ标志。出于诊断目的使用ACK REQ标志是一个策略问题。确认的刷新消息可用于探测端到端路径，以检查其是否仍然完好。
A QUERY message is used to request information about the data path without making a reservation. This functionality can be used to 'probe' the network for path characteristics or for support of certain QoS models, or to initiate a receiver-initiated reservation.
查询消息用于请求有关数据路径的信息，而无需进行保留。此功能可用于“探测”网络的路径特征或支持某些QoS模型，或启动接收器发起的预留。
A QNE sending a QUERY indicates a request for a response by including a Request Identification Information (RII) object; see Section 5.3.2. A request to initiate a receiver-initiated reservation is done through the RESERVE-INIT flag; see Section 5.1.2.2.
发送查询的QNE通过包括请求标识信息（RII）对象来指示对响应的请求；见第5.3.2节。通过RESERVE-INIT标志发起接收方发起的预留的请求；见第5.1.2.2节。
When a QNE receives a QUERY message the QSPEC is passed to the RMF for processing. The RMF may return a modified QSPEC that is used in any QUERY or RESPONSE message sent out as a result of the QUERY processing.
当QNE接收到查询消息时，QSPEC被传递给RMF进行处理。RMF可以返回修改后的QSPEC，该QSPEC用于作为查询处理结果发送的任何查询或响应消息中。
When processing a QUERY message, a QNE checks whether the RESERVE-INIT flag is set. If the flag is set, the QUERY is used to install reverse-path state. In this case, if the QNE is not the QNI, it creates a new QUERY message to send downstream. The QSPEC MUST be passed to the RMF where it may be modified by the QoS-model-specific QUERY processing. If the QNE is the QNI, the QNE creates a RESERVE message, which contains a QSPEC received from the RMF and which may be based on the received QSPEC. If this node was not expecting to perform a receiver-initiated reservation, then an error MUST be sent back along the path.
在处理查询消息时，QNE检查是否设置了RESERVE-INIT标志。如果设置了该标志，则查询用于安装反向路径状态。在这种情况下，如果QNE不是QNI，它将创建一个新的查询消息发送到下游。QSPEC必须传递给RMF，在RMF中可以通过QoS模型特定的查询处理对其进行修改。如果QNE是QNI，则QNE创建保留消息，该消息包含从RMF接收的QSPEC，并且可能基于接收的QSPEC。如果此节点不希望执行接收器启动的保留，则必须沿路径发回错误。
The QNE MUST generate a RESPONSE message and pass it back along the reverse of the path used by the QUERY if:
如果出现以下情况，QNE必须生成响应消息并沿查询使用的路径的相反方向将其传递回：
o an RII object is present,
o 存在一个RII对象，
o the QNE is the QNR,
o QNE是QNR，
o the SCOPING flag is set, or
o 已设置范围标志，或
o the PROXY scope flag is set, and the QNE is a P-QNE.
o 设置代理作用域标志，并且QNE是P-QNE。
If an RII object is present, and if the QNE is the QNR, the SCOPING flag is set or the PROXY scope flag is set and the QNE is a P-QNE, the QNE MUST generate a RESPONSE message and pass it back along the reverse of the path used by the QUERY.
如果存在RII对象，并且如果QNE是QNR，则设置了作用域标志或代理作用域标志，并且QNE是P-QNE，则QNE必须生成响应消息，并沿查询使用的路径的相反方向将其传回。
In other cases, the QNE MUST generate a QUERY message that is then forwarded further along the path using the same MRI, Session ID, and Direction as provided when the QUERY was received over the GIST API.
在其他情况下，QNE必须生成查询消息，然后使用与通过GIST API接收查询时提供的相同MRI、会话ID和方向沿路径进一步转发。
The QSPEC to be used is that provided by the RMF as described previously. When generating a QUERY to send out to pass the query further along the path, the QNE MUST copy the RII object (if present) unchanged into the new QUERY message. A QNE that is also interested in the response to the query keeps track of the RII to identify the RESPONSE when it passes through it.
所使用的QSPEC由RMF提供，如前所述。当生成要发送的查询以沿路径进一步传递查询时，QNE必须将RII对象（如果存在）复制到新的查询消息中，保持不变。对查询响应感兴趣的QNE会跟踪RII，以在响应通过时识别响应。
Note that QUERY messages with the RESERVE-INIT flag set MUST be answered by the QNR. This feature may be used, e.g., following handovers, to set up new path state in GIST and to request that the other party to send a RESERVE back on this new GIST path.
请注意，设置了RESERVE-INIT标志的查询消息必须由QNR应答。例如，在切换之后，可使用此功能在GIST中设置新路径状态，并请求另一方在该新GIST路径上发送保留。
If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT flag and BREAK flag set, then the BREAK flag of newly generated messages (e.g., QUERY, RESERVE, or RESPONSE) MUST be set. When a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT flag set and BREAK flag not set, then the IP-TTL and Original-TTL values in GIST RecvMessage primitive MUST be monitored. If they differ, it is RECOMMENDED to set the BREAK flag in newly generated messages (e.g., QUERY, RESERVE, or RESPONSE). In situations where a QNE or a domain is able to provide QoS using other means (see Section 3.3.5), the BREAK flag SHOULD NOT be set.
如果有状态QoS NSLP QNE接收到设置了REFERE-INIT标志和BREAK标志的查询消息，则必须设置新生成消息的BREAK标志（例如，查询、保留或响应）。当有状态QoS NSLP QNE接收到设置了REFERE-INIT标志且未设置BREAK标志的查询消息时，必须监视GIST RecvMessage原语中的IP-TTL和原始TTL值。如果它们不同，建议在新生成的消息（例如查询、保留或响应）中设置中断标志。在QNE或域能够使用其他方式提供QoS的情况下（见第3.3.5节），不应设置中断标志。
Finally, if a received QUERY requested acknowledgement through the ACK-REQ flag in the COMMON HEADER flags and the processing of the message was successful, the stateful QNE SHOULD send back a RESPONSE with an INFO-SPEC carrying the acknowledgement success code.
最后，如果收到的查询通过公共报头标志中的ACK-REQ标志请求确认，并且消息处理成功，则有状态QNE应发送回带有确认成功代码的INFO-SPEC的响应。
The RESPONSE message is used to provide information about the result of a previous QoS NSLP message, e.g., confirmation of a reservation or information resulting from a QUERY. The RESPONSE message does not cause any state to be installed, but may cause state(s) to be modified, e.g., if the RESPONSE contains information about an error.
响应消息用于提供关于先前QoS NSLP消息的结果的信息，例如，预约确认或查询产生的信息。响应消息不会导致安装任何状态，但可能会导致修改状态，例如，如果响应包含有关错误的信息。
A RESPONSE message MUST be sent when the QNR processes a RESERVE or QUERY message containing an RII object or if the QNE receives a scoped RESERVE or a scoped QUERY. In this case, the RESPONSE message MUST contain the RII object copied from the RESERVE or the QUERY. Also, if there is an error in processing a received RESERVE, a RESPONSE is sent indicating the nature of the error. In this case, the RII and RSN, if available, MUST be included in the RESPONSE.
当QNR处理包含RII对象的保留或查询消息时，或者如果QNE接收范围保留或范围查询，则必须发送响应消息。在这种情况下，响应消息必须包含从保留或查询复制的RII对象。此外，如果在处理收到的保留时出错，则会发送一个响应，指示错误的性质。在这种情况下，RII和RSN（如果可用）必须包含在响应中。
On receipt of a RESPONSE message containing an RII object, the stateful QoS NSLP QNE MUST attempt to match it to the outstanding response requests for that signaling session. If the match succeeds, then the RESPONSE MUST NOT be forwarded further along the path if it
在接收到包含RII对象的响应消息时，有状态QoS NSLP QNE必须尝试将其与该信令会话的未完成响应请求相匹配。如果匹配成功，则响应不能沿路径进一步转发（如果匹配成功）
contains an Informational or Success INFO-SPEC class. If the QNE did not insert this RII itself, it must forward the RESPONSE to the next peer. Thus, for RESPONSEs indicating success, forwarding should only stop if the QNE inserted the RII by itself. If the RESPONSE carries an INFO-SPEC indicating an error, forwarding SHOULD continue upstream towards the QNI by using RSNs as described in the next paragraph.
包含信息类或成功信息规范类。如果QNE本身没有插入此RII，则必须将响应转发给下一个对等方。因此，对于表示成功的响应，只有当QNE自己插入RII时，才应该停止转发。如果响应包含指示错误的信息规范，则应使用下一段中描述的RSN继续向QNI上游转发。
On receipt of a RESPONSE message containing an RSN object, a stateful QoS NSLP QNE MUST compare the RSN to that of the appropriate signaling session. If the match succeeds, then the INFO-SPEC MUST be processed. If the INFO-SPEC object is used to send error notifications then the node MUST use the stored upstream peer RSN value, associated with the same session, and forward the RESPONSE message further along the path towards the QNI.
在接收到包含RSN对象的响应消息时，有状态QoS NSLP QNE必须将RSN与相应信令会话的RSN进行比较。如果匹配成功，则必须处理INFO-SPEC。如果INFO-SPEC对象用于发送错误通知，则节点必须使用存储的上游对等RSN值（与同一会话关联），并沿路径向QNI进一步转发响应消息。
If the INFO-SPEC is not used to notify error situations (see above), then if the RESPONSE message carries an RSN, the message MUST NOT be forwarded further along the path.
如果INFO-SPEC未用于通知错误情况（见上文），则如果响应消息带有RSN，则消息不得沿路径进一步转发。
If there is no match for RSN, the message SHOULD be silently dropped.
如果没有与RSN匹配的消息，则应以静默方式删除该消息。
On receipt of a RESPONSE message containing neither an RII nor an RSN object, the RESPONSE MUST NOT be forwarded further along the path.
在收到既不包含RII也不包含RSN对象的响应消息时，不得沿路径进一步转发响应。
In the typical case, RESPONSE messages do not change the states installed in intermediate QNEs. However, depending on the QoS model, there may be situations where states are affected, e.g.,
在典型情况下，响应消息不会更改中间QNE中安装的状态。但是，根据QoS模型，可能存在状态受到影响的情况，例如：。，
- if the RESPONSE includes an INFO-SPEC describing an error situation resulting in reservations to be removed, or
- 如果响应包含描述导致删除保留的错误情况的信息规范，或
- the QoS model allows a QSPEC to define [min,max] limits on the resources requested, and downstream QNEs gave less resources than their upstream nodes, which means that the upstream nodes may release a part of the resource reservation.
- QoS模型允许QSPEC对请求的资源定义[min，max]限制，下游QNE提供的资源少于其上游节点，这意味着上游节点可以释放部分资源预留。
If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK flag set, then the BREAK flag of newly generated message (e.g., RESPONSE) MUST be set.
如果有状态QoS NSLP QNE接收到设置了中断标志的响应消息，则必须设置新生成消息的中断标志（例如，响应）。
NOTIFY messages are used to convey information to a QNE asynchronously. NOTIFY messages do not cause any state to be installed. The decision to remove state depends on the QoS model. The exact operation depends on the QoS model. A NOTIFY message does
通知消息用于异步地将信息传递给QNE。通知消息不会导致安装任何状态。删除状态的决定取决于QoS模型。具体操作取决于QoS模型。通知消息不起作用
not directly cause other messages to be sent. NOTIFY messages are sent asynchronously, rather than in response to other messages. They may be sent in either direction (upstream or downstream).
不会直接导致发送其他消息。通知消息是异步发送的，而不是响应其他消息。它们可以向任一方向发送（上游或下游）。
A special case of synchronous NOTIFY is when the upstream QNE is asked to use reduced refresh by setting the appropriate flag in the RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY and a proper INFO-SPEC code indicating whether the QNE agrees to use reduced refresh between the upstream QNE.
同步通知的一种特殊情况是，通过在保留中设置适当的标志，要求上游QNE使用减少的刷新。接收到这种保留的QNE必须回复NOTIFY和适当的INFO-SPEC代码，指示QNE是否同意在上游QNE之间使用减少的刷新。
The Transient error code 0x07 "Reservation preempted" is sent to the QNI whose resources were preempted. The NOTIFY message carries information to the QNI that one QNE no longer has a reservation for the session. It is up to the QNI to decide what to do based on the QoS model being used. The QNI would normally tear down the preempted reservation by sending a RESERVE with the TEAR flag set using the SII of the preempted reservation. However, the QNI can follow other procedures as specified in its QoS Model. More discussion on preemption can be found in the QSPEC Template [RFC5975] and the individual QoS Model specifications.
暂时错误代码0x07“Reservation preempted”被发送到资源被抢占的QNI。NOTIFY消息将一个QNE不再保留会话的信息传送给QNI。由QNI根据所使用的QoS模型决定要做什么。QNI通常会通过使用抢占预订的SII发送一个设置了撕裂标志的预订来撕毁抢占预订。但是，QNI可以遵循其QoS模型中指定的其他过程。在QSPEC模板[RFC5975]和各个QoS模型规范中可以找到关于抢占的更多讨论。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QoS NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].
根据BCP 26、RFC 5226[RFC5226]，本节为互联网分配号码管理局（IANA）提供了关于QoS NSLP相关值注册的指南。
Per QoS NSLP, IANA has created a number of new registries:
根据QoS NSLP，IANA创建了许多新的注册表：
- QoS NSLP Message Types - QoS NSLP Binding Codes - QoS NSLP Error Classes - Informational Error Codes - Success Error Codes - Protocol Error Codes - Transient Failure Codes - Permanent Failure Codes - QoS NSLP Error Source Identifiers
- QoS NSLP消息类型-QoS NSLP绑定代码-QoS NSLP错误类-信息性错误代码-成功错误代码-协议错误代码-瞬时故障代码-永久故障代码-QoS NSLP错误源标识符
IANA has also registered new values in a number of registries:
IANA还在多个注册中心注册了新值：
- NSLP Object Types - NSLP Identifiers (under GIST Parameters) - Router Alert Option Values (IPv4 and IPv6)
- NSLP对象类型-NSLP标识符（在GIST参数下）-路由器警报选项值（IPv4和IPv6）
The QoS NSLP Message Type is an 8-bit value. This specification defines four QoS NSLP message types, which form the initial contents of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03), and NOTIFY (0x04).
QoS NSLP消息类型为8位值。此规范定义了四种QoS NSLP消息类型，它们构成此注册表的初始内容：保留（0x01）、查询（0x02）、响应（0x03）和通知（0x04）。
The value 0 is reserved. Values 240 to 255 are for Experimental/ Private Use. The registration procedure is IETF Review.
值0是保留的。值240至255供实验/私人使用。注册程序为IETF审查。
When a new message type is defined, any message flags used with it must also be defined.
定义新消息类型时，还必须定义与之一起使用的任何消息标志。
A new registry has been created for NSLP Message Objects. This is a 12-bit field (giving values from 0 to 4095). This registry is shared between a number of NSLPs.
已为NSLP消息对象创建了一个新注册表。这是一个12位字段（给出0到4095之间的值）。此注册表由多个NSLP共享。
Registration procedures are as follows:
登记程序如下：
0: Reserved
0:保留
1-1023: IETF Review
1-1023：IETF审查
1024-1999: Specification Required
1024-1999：需要规格
Allocation policies are as follows:
分配政策如下：
2000-2047: Private/Experimental Use
2000-2047：私人/实验用途
2048-4095: Reserved
2048-4095：保留
When a new object is defined, the extensibility bits (A/B) must also be defined.
定义新对象时，还必须定义扩展性位（a/B）。
This document defines eleven new NSLP message objects. These are described in Section 5.1.3: RII (0x001), RSN (0x002), REFRESH-PERIOD (0x003), BOUND-SESSION-ID (0x004), PACKET-CLASSIFIER (0x005), INFO-SPEC (0x006), SESSION-ID-LIST (0x007), RSN-LIST (0x008), MSG-ID (0x009), BOUND-MSG-ID (0x00A), and QSPEC (0x00B).
本文档定义了11个新的NSLP消息对象。这些在第5.1.3节中描述：RII（0x001）、RSN（0x002）、刷新周期（0x003）、绑定会话ID（0x004）、数据包分类器（0x005）、信息规范（0x006）、会话ID列表（0x007）、RSN列表（0x008）、消息ID（0x009）、绑定会话ID（0x00A）和QSPEC（0x00B）。
Additional values are to be assigned from the IETF Review section of the NSLP Message Objects registry.
附加值将从NSLP消息对象注册表的IETF审查部分分配。
A new registry has been created for the 8-bit Binding Codes used in the BOUND-SESSION-ID object. The initial values for this registry are listed in Section 5.1.3.4.
已为绑定会话ID对象中使用的8位绑定代码创建了一个新注册表。第5.1.3.4节列出了该注册表的初始值。
The registration procedure is IETF Review. Value 0 is reserved. Values 128 to 159 are for Experimental/Private Use. Other values are Reserved.
注册程序为IETF审查。保留值0。值128至159供实验/私人使用。其他值保留。
In addition, Error Classes and Error Codes for the INFO-SPEC object are defined. These are described in Section 5.1.3.6.
此外，还定义了INFO-SPEC对象的错误类和错误代码。第5.1.3.6节对此进行了描述。
The Error Class is 4 bits in length. The initial values are:
错误类的长度为4位。初始值为：
0: Reserved
0:保留
1: Informational
1：信息性
2: Success
2:成功
3: Protocol Error
3：协议错误
4: Transient Failure
4：瞬时故障
5: Permanent Failure
5：永久性故障
6: QoS Model Error
6:QoS模型错误
7: Signaling session failure (described in [RFC5973])
7：信令会话失败（如[RFC5973]所述）
8-15: Reserved
8-15：保留
Additional values are to be assigned based on IETF Review.
应根据IETF审查分配附加值。
The Error Code is 8 bits in length. Each Error Code is assigned within a particular Error Class. This requires the creation of a registry for Error Codes in each Error Class. The Error Code 0 in each class is Reserved.
错误代码的长度为8位。每个错误代码都分配在特定的错误类中。这需要为每个错误类中的错误代码创建注册表。保留每个类中的错误代码0。
Policies for the error code registries are as follows:
错误代码注册表的策略如下所示：
0-63: IETF Review
0-63：IETF审查
64-127: Specification Required
64-127：需要规格
128-191: Experimental/Private Use
128-191：实验/私人使用
192-255: Reserved
192-255：保留
The initial assignments for the Error Code registries are given in Section 5.1.3.6. Experimental and Reserved values are relevant to all Error classes.
第5.1.3.6节给出了错误代码注册表的初始分配。实验值和保留值与所有错误类别相关。
Section 5.1.3.6 defines Error Source Identifiers, the type of which is identified by a 4-bit value.
第5.1.3.6节定义了错误源标识符，其类型由4位值标识。
The value 0 is reserved.
值0是保留的。
Values 1-3 are given in Section 5.1.3.6.
第5.1.3.6节给出了值1-3。
Values 14 and 15 are for Experimental/Private Use.
值14和15供实验/私人使用。
The registration procedure is Specification Required.
注册程序是必需的。
This specification defines an NSLP for use with GIST. Furthermore, it specifies that a number of NSLPID values are used for the support of bypassing intermediary nodes. Consequently, new identifiers must be assigned for them from the GIST NSLP identifier registry. As required by the QoS NSLP, 32 NSLPID values have been assigned, corresponding to QoS NSLP Aggregation Levels 0 to 31.
本规范定义了与GIST一起使用的NSLP。此外，它还指定了许多NSLPID值用于支持绕过中间节点。因此，必须从GIST NSLP标识符注册表为其分配新的标识符。根据QoS NSLP的要求，分配了32个NSLPID值，对应于QoS NSLP聚合级别0到31。
The GIST specification also requires that NSLPIDs be associated with specific Router Alert Option (RAO) values (although multiple NSLPIDs may be associated with the same value). For the purposes of the QoS NSLP, each of its NSLPID values should be associated with a different RAO value. A block of 32 new IPv4 RAO values and a block of 32 new IPv6 RAO values have been assigned, corresponding to QoS NSLP Aggregation Levels 0 to 31.
GIST规范还要求NSLPID与特定的路由器警报选项（RAO）值相关联（尽管多个NSLPID可能与相同的值相关联）。出于QoS NSLP的目的，其每个NSLPID值都应与不同的RAO值相关联。已分配32个新IPv4 RAO值的块和32个新IPv6 RAO值的块，对应于QoS NSLP聚合级别0到31。
The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats. For the signaling problem as a whole, these threats have been outlined in NSIS threats [RFC4081]; the NSIS framework [RFC4080] assigns a subset of the responsibility to GIST, and the remaining threats need to be addressed by NSLPs. The main issues to be handled can be summarized as:
QoS NSLP的安全要求是保护信令交换，以针对已识别的安全威胁建立QoS保留。对于整个信令问题，NSIS威胁[RFC4081]中概述了这些威胁；NSIS框架[RFC4080]将部分责任分配给GIST，其余威胁需要由NSLP解决。需要处理的主要问题可概括为：
Authorization:
授权：
The QoS NSLP must assure that the network is protected against theft-of-service by offering mechanisms to authorize the QoS reservation requester. A user requesting a QoS reservation might want proper resource accounting and protection against spoofing and other security vulnerabilities that lead to denial of service and financial loss. In many cases, authorization is based on the authenticated identity. The authorization solution must provide guarantees that replay attacks are either not possible or limited to a certain extent. Authorization can also be based on traits that enable the user to remain anonymous. Support for user identity confidentiality can be accomplished.
QoS NSLP必须通过提供授权QoS保留请求者的机制来确保网络免受服务盗窃的保护。请求QoS保留的用户可能需要适当的资源核算和保护，以防止欺骗和其他导致拒绝服务和财务损失的安全漏洞。在许多情况下，授权基于经过身份验证的身份。授权解决方案必须保证重播攻击不可能发生或在一定程度上受到限制。授权也可以基于允许用户保持匿名的特征。可以实现对用户身份保密性的支持。
Message Protection:
消息保护：
Signaling message content should be protected against modification, replay, injection, and eavesdropping while in transit. Authorization information, such as authorization tokens, needs protection. This type of protection at the NSLP layer is necessary to protect messages between NSLP nodes.
在传输过程中，应对信令消息内容进行保护，防止修改、重播、注入和窃听。授权信息（如授权令牌）需要保护。NSLP层的这种类型的保护对于保护NSLP节点之间的消息是必要的。
Rate Limitation:
费率限制：
QNEs should perform rate-limiting on the refresh messages that they send. An attacker could send erroneous messages on purpose, forcing the QNE to constantly reply with an error message. Authentication mechanisms would help in figuring out if error situations should be reported to the sender, or silently ignored. If the sender is authenticated, the QNE should reply promptly.
QNE应该对其发送的刷新消息执行速率限制。攻击者可能故意发送错误消息，迫使QNE不断回复错误消息。身份验证机制将有助于确定错误情况是应该报告给发送方，还是应该默默地忽略。如果发送方经过身份验证，QNE应立即回复。
Prevention of Denial-of-Service Attacks:
防止拒绝服务攻击：
GIST and QoS NSLP nodes have finite resources (state storage, processing power, bandwidth). The protocol mechanisms in this document try to minimize exhaustion attacks against these resources when performing authentication and authorization for QoS resources.
GIST和QoS NSLP节点具有有限的资源（状态存储、处理能力、带宽）。本文档中的协议机制试图在对QoS资源执行身份验证和授权时最大限度地减少对这些资源的耗尽攻击。
To some extent, the QoS NSLP relies on the security mechanisms provided by GIST, which by itself relies on existing authentication and key exchange protocols. Some signaling messages cannot be protected by GIST and hence should be used with care by the QoS NSLP. An API must ensure that the QoS NSLP implementation is aware of the underlying security mechanisms and must be able to indicate which degree of security is provided between two GIST peers. If a level of security protection for QoS NSLP messages that is required goes beyond the security offered by GIST or underlying security
在某种程度上，QoS NSLP依赖于GIST提供的安全机制，GIST本身依赖于现有的身份验证和密钥交换协议。一些信令消息不能受GIST保护，因此QoS NSLP应谨慎使用。API必须确保QoS NSLP实现了解底层安全机制，并且必须能够指示两个GIST对等方之间提供的安全程度。如果所需的QoS NSLP消息的安全保护级别超出了GIST或底层安全性提供的安全性
mechanisms, additional security mechanisms described in this document must be used. Due to the different usage environments and scenarios where NSIS is used, it is very difficult to make general statements without reducing its flexibility.
必须使用本文档中描述的其他安全机制。由于使用NSIS的使用环境和场景不同，很难在不降低其灵活性的情况下做出一般性陈述。
This specification is based on a model that requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path. The model is simple to deploy, was used in previous QoS authorization environments (such as RSVP), and seems to provide sufficiently strong security properties. We refer to this model as the New Jersey Turnpike.
该规范基于一个模型，该模型要求相邻NSLP节点之间的信任，以沿QoS信令路径建立信任链。该模型易于部署，在以前的QoS授权环境（如RSVP）中使用过，并且似乎提供了足够强的安全属性。我们称这种型号为新泽西收费公路。
On the New Jersey Turnpike, motorists pick up a ticket at a toll booth when entering the highway. At the highway exit, the ticket is presented and payment is made at the toll booth for the distance driven. For QoS signaling in the Internet, this procedure is roughly similar. In most cases, the data sender is charged for transmitted data traffic where charging is provided only between neighboring entities.
在新泽西州收费公路上，驾车者进入高速公路时在收费亭领取车票。在高速公路出口，出示车票，并在收费亭支付行驶距离。对于Internet中的QoS信令，此过程大致相似。在大多数情况下，仅在相邻实体之间提供收费的情况下，数据发送方对传输的数据流量收费。
+------------------+ +------------------+ +------------------+
| Network | | Network | | Network |
| X | | Y | | Z |
| | | | | |
| -----------> -----------> |
| | | | | |
| | | | | |
+--------^---------+ +------------------+ +-------+----------+
| .
| .
| v
+--+---+ Data Data +--+---+
| Node | ==============================> | Node |
| A | Sender Receiver | B |
+------+ +------+
+------------------+ +------------------+ +------------------+
| Network | | Network | | Network |
| X | | Y | | Z |
| | | | | |
| -----------> -----------> |
| | | | | |
| | | | | |
+--------^---------+ +------------------+ +-------+----------+
| .
| .
| v
+--+---+ Data Data +--+---+
| Node | ==============================> | Node |
| A | Sender Receiver | B |
+------+ +------+
Legend:
图例：
----> Peering relationship that allows neighboring
networks/entities to charge each other for the
QoS reservation and data traffic
----> Peering relationship that allows neighboring
networks/entities to charge each other for the
QoS reservation and data traffic
====> Data flow
====> Data flow
.... Communication to the end host
.... Communication to the end host
Figure 16: New Jersey Turnpike Model
图16：新泽西收费公路模型
The model shown in Figure 16 uses peer-to-peer relationships between different administrative domains as a basis for accounting and charging. As mentioned above, based on the peering relationship, a chain-of-trust is established. There are several issues that come to mind when considering this type of model:
图16所示的模型使用不同管理域之间的对等关系作为记帐和收费的基础。如上所述，基于对等关系，建立信任链。考虑此类模型时，会想到几个问题：
o The model allows authorization on a request basis or on a per-session basis. Authorization mechanisms are elaborated in Section 7.2. The duration for which the QoS authorization is valid needs to be controlled. Combining the interval with the soft-state interval is possible. Notifications from the networks also seem to be a viable approach.
o 该模型允许基于请求或基于每个会话的授权。第7.2节详细阐述了授权机制。需要控制QoS授权有效的持续时间。将间隔与软状态间隔相结合是可能的。来自网络的通知似乎也是一种可行的方法。
o The price for a QoS reservation needs to be determined somehow and communicated to the charged entity and to the network where the charged entity is attached. Protocols providing "Advice of Charge" functionality are out of scope.
o QoS保留的价格需要以某种方式确定，并传达给收费实体和连接收费实体的网络。提供“收费建议”功能的协议超出范围。
o This architecture is simple enough to allow a scalable solution (ignoring reverse charging, multicast issues, and price distribution).
o 该体系结构非常简单，可以提供可扩展的解决方案（忽略反向收费、多播问题和价格分布）。
Charging the data sender as performed in the model simplifies security handling by demanding only peer-to-peer security protection. Node A would perform authentication and key establishment. The established security association (together with the session key) would allow the user to protect QoS signaling messages. The identity used during the authentication and key establishment phase would be used by Network X (see Figure 16) to perform the so-called policy-based admission control procedure. In our context, this user identifier would be used to establish the necessary infrastructure to provide authorization and charging. Signaling messages later exchanged between the different networks are then also subject to authentication and authorization. However, the authenticated entity is thereby the neighboring network and not the end host.
按照模型中的执行方式向数据发送方收费，只需要点对点安全保护，从而简化了安全处理。节点A将执行身份验证和密钥建立。建立的安全关联（连同会话密钥）将允许用户保护QoS信令消息。网络X（见图16）将使用身份验证和密钥建立阶段使用的身份来执行所谓的基于策略的准入控制过程。在我们的上下文中，该用户标识符将用于建立必要的基础设施，以提供授权和收费。随后在不同网络之间交换的信令消息也要经过认证和授权。然而，认证实体因此是相邻网络而不是终端主机。
The New Jersey Turnpike model is attractive because of its simplicity. S. Shenker, et al. [shenker] discuss various accounting implications and introduced the edge pricing model. The edge pricing model shows similarity to the model described in this section, with the exception that mobility and the security implications are not addressed.
新泽西收费公路模型因其简单而吸引人。S.Shenker等人[Shenker]讨论了各种会计含义，并介绍了edge定价模型。边缘定价模型与本节中描述的模型相似，但移动和安全影响未得到解决。
Various authorization models can be used in conjunction with the QoS NSLP.
各种授权模型可以与QoS NSLP结合使用。
The two-party approach (Figure 17) is conceptually the simplest authorization model.
两党方法（图17）在概念上是最简单的授权模型。
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
Figure 17: Two-Party Approach
图17：两党办法
In this example, the authorization decision only involves the two entities, or makes use of previous authorization using an out-of-band mechanism to avoid the need for active participation of an external entity during the NSIS protocol execution.
在此示例中，授权决策仅涉及两个实体，或利用先前使用带外机制的授权来避免在NSIS协议执行期间需要外部实体的积极参与。
This type of model may be applicable, e.g., between two neighboring networks (inter-domain signaling) where a long-term contract (or other out-of-band mechanisms) exists to manage charging and provides sufficient information to authorize individual requests.
这种类型的模型可能适用，例如，在两个相邻网络（域间信令）之间，其中存在管理计费的长期合同（或其他带外机制），并提供足够的信息来授权单个请求。
An alternative approach makes use of tokens, such as those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the Open Settlement Protocol [osp]. Authorization tokens are used to associate two different signaling protocols runs (e.g., SIP and NSIS) and their authorization decision with each other. The latter is a form of assertion or trait. As an example, with the authorization token mechanism, some form of authorization is provided by the SIP proxy, which acts as the resource-authorizing entity in Figure 18. If the request is authorized, then the SIP signaling returns an authorization token that can be included in the QoS signaling protocol messages to refer to the previous authorization decision. The tokens themselves may take a number of different forms, some of which may require the entity performing the QoS reservation to query the external state.
另一种方法是使用令牌，如RFC 3520[RFC3520]和RFC 3521[RFC3521]中描述的令牌或用作开放式结算协议[osp]的一部分的令牌。授权令牌用于将两个不同的信令协议运行（例如，SIP和NSI）及其授权决策相互关联。后者是断言或特征的一种形式。例如，使用授权令牌机制，SIP代理提供某种形式的授权，它充当图18中的资源授权实体。如果请求被授权，则SIP信令返回可包括在QoS信令协议消息中的授权令牌，以参考先前的授权决策。令牌本身可以采取许多不同的形式，其中一些可能要求执行QoS保留的实体查询外部状态。
Authorization
Token Request +--------------+
+-------------->| Entity C | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation |
+-------------+ +--------------+
Authorization
Token Request +--------------+
+-------------->| Entity C | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 18: Token-Based Three-Party Approach
图18：基于令牌的三方方法
For the digital money type of systems (e.g., OSP tokens), the token represents a limited amount of credit. So, new tokens must be sent with later refresh messages once the credit is exhausted.
对于数字货币类型的系统（例如，OSP代币），代币表示有限的信用额度。因此，一旦信用耗尽，新的令牌必须与稍后的刷新消息一起发送。
Another method is for the node performing the QoS reservation to delegate the authorization decision to a third party, as illustrated in Figure 19. The authorization decision may be performed on a per-request basis, periodically, or on a per-session basis.
另一种方法是执行QoS保留的节点将授权决策委托给第三方，如图19所示。可以基于每个请求、周期性地或基于每个会话执行授权决策。
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
QoS | | QoS
authz| |authz
req.| | res.
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
QoS | | QoS
authz| |authz
req.| | res.
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 19: Three-Party Approach
图19：三方方法
Whenever an authorization decision has to be made there is the question about which information serves as an input to the authorizing entity. The following information items have been mentioned in the past for computing the authorization decision (in addition to the authenticated identity):
无论何时必须做出授权决策，都存在一个问题，即哪些信息可作为授权实体的输入。过去曾提到以下信息项用于计算授权决策（除了经过身份验证的身份外）：
Price
价格
QoS objects
QoS对象
Policy rules
政策规则
Policy rules take into consideration attributes like time of day, subscription to certain services, membership, etc., when computing an authorization decision.
在计算授权决策时，策略规则会考虑诸如时间、对某些服务的订阅、成员资格等属性。
The policies used to make the authorization are outside the scope of this document and are implementation/deployment specific.
用于进行授权的策略不在本文档的范围内，并且是特定于实施/部署的。
The authors would like to thank Eleanor Hepworth, Ruediger Geib, Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, Martijn Swanink, and Ruud Klaver for their useful comments. Roland, especially, has done deep reviews of the document, making sure the protocol is well defined. Bob Braden provided helpful comments and guidance which were gratefully received.
作者要感谢埃莉诺·赫普沃斯、鲁迪格·盖布、罗兰·布莱斯、内梅特·克里斯坦、马库斯·奥特、玛伊·祖马罗·杰扬、玛蒂恩·斯瓦宁克和路德·克拉弗的有用评论。尤其是罗兰，对该文件进行了深入的审查，以确保该协议得到了很好的定义。Bob Braden提供了有益的意见和指导，受到了感谢。
This document combines work from three individual documents. The following authors from these documents also contributed to this document: Robert Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson), and Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, Roland Bless has contributed considerable amounts of text all along the writing of this specification.
本文档结合了三个单独文档中的工作。这些文件中的以下作者也对本文件做出了贡献：罗伯特·汉考克（西门子/罗克庄园研究院）、汉内斯·茨霍芬尼（Hannes Tschofenig）和科妮莉亚·卡普勒（西门子股份公司）、拉尔斯·韦斯特伯格（Lars Westberg）和阿提拉·巴德（爱立信）、马尔滕·布切利（但丁）和埃里克·瓦格曼（阿尔卡特）。此外，罗兰·布莱斯（Roland Bless）在本规范的编写过程中贡献了大量的文本。
Sven Van den Bosch was the initial editor of earlier draft versions of this document. Since version 06 of the document, Jukka Manner has taken the editorship. Yacine El Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning Schulzrinne suggested the use of the reason field in the BOUND-SESSION-ID.
Sven Van den Bosch是本文件早期草稿的初始编辑。自该文件第06版起，朱卡·韦德担任编辑。Yacine El-Mghazli（阿尔卡特）提供了关于AAA的文本。Charles Shen和Henning Schulzrinne建议在绑定会话ID中使用原因字段。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[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月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]Ash，G.，Bader，A.，Kappler，C.，和D.Oran，“服务质量NSIS信令层协议（NSLP）的QSPEC模板”，RFC 59752010年10月。
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, Ed., "Authorization for NSIS Signaling Layer Protocols", Work in Progress, May 2010.
[NSIS-AUTH]Way，J.，Stiemerling，M.，Tschofenig，H.，和R.Bless，Ed.，“NSIS信令层协议的授权”，正在进行的工作，2010年5月。
[NSIS-MOB] Sanda, T., Fu, X., Jeong, S., Manner, J., and H. Tschofenig, "NSIS Protocols operation in Mobile Environments", Work in Progress, May 2010.
[NSIS-MOB]Sanda，T.，Fu，X.，Jeong，S.，Way，J.，和H.Tschofenig，“移动环境中的NSIS协议操作”，正在进行的工作，2010年5月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]Hamer，L-N.，Gage，B.，Kosinski，B.，和H.Shieh，“会话授权策略元素”，RFC 3520，2003年4月。
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521]Hamer，L-N.，Gage，B.，和H.Shieh，“通过媒体授权建立会话的框架”，RFC 35212003年4月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]Brunner，M.，“信令协议的要求”，RFC 3726，2004年4月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，RFC 59732010年10月。
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C., Tschofenig, H., 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.，Tschofenig，H.，和T.Phelan，“RMD-QOSM：区分服务中资源管理的NSIS服务质量模型”，RFC 5977，2010年10月。
[lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management for Multimedia Applications in Wireless Access Networks", IASTED IMSA, Technical Specification 101 321, p. 193-200, August 2004.
[lrsvp]Way，J.和K.Raatikainen，“无线接入网络中多媒体应用的本地化QoS管理”，IASTED IMSA，技术规范101 321，第页。2004年8月193日至200日。
[opwa95] Breslau, L., "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.
[opwa95]Breslau，L.，“保留地建立中的两个问题”，Proc。ACM SIGCOMM'95，马萨诸塞州剑桥，1995年8月。
[osp] ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage exchange", Technical Specification 101 321, version 4.1.1.
[osp]ETSI，“网络上的电信和互联网协议协调（TIPHON）；域间定价、授权和使用交换的开放结算协议（osp）”，技术规范101 321，版本4.1.1。
[qos-auth] Tschofenig, H., "QoS NSLP Authorization Issues", Work in Progress, June 2003.
[qos认证]Tschofenig，H.，“qos NSLP授权问题”，正在进行的工作，2003年6月。
[shenker] Shenker, S., et al., "Pricing in computer networks: Reshaping the research agenda", Proc. of TPRC 1995, 1995.
[shenker]shenker，S.等人，“计算机网络中的定价：重塑研究议程”，Proc。1995年，1995年。
This appendix is purely informational and provides an abstract API between the QoS NSLP and the RMF. It should not be taken as a strict rule for implementors, but rather it helps clarify the interface between the NSLP and RMF.
本附录仅供参考，提供了QoS NSLP和RMF之间的抽象API。它不应被视为实现者的严格规则，而是有助于澄清NSLP和RMF之间的接口。
The QoS-NSLP triggers the RMF/QOSM functionality by using the sendrmf() primitive:
QoS NSLP通过使用sendrmf（）原语触发RMF/QOSM功能：
int sendrmf(sid, nslp_req_type, qspec, authorization_info, NSLP_objects, filter, features_in, GIST_API_triggers, incoming_interface, outgoing_interface)
int sendrmf（sid、nslp需求类型、qspec、授权信息、nslp对象、过滤器、功能输入、GIST API触发器、输入接口、输出接口）
o sid: SESSION-ID - The NSIS session identifier
o sid:SESSION-ID-NSIS会话标识符
o nslp_req_type: indicates type of request:
o nslp_请求类型：表示请求类型：
* RESERVE
* 储备
* QUERY
* 查询
* RESPONSE
* 回答
* NOTIFY
* 通知
o qspec: the QSPEC object, if present
o qspec：qspec对象（如果存在）
o authorization_info: the AUTH_SESSION object, if present
o 授权信息：授权会话对象（如果存在）
o NSLP_objects: data structure that contains a list with received QoS-NSLP objects. This list can be used by, e.g., local applications, network management, or policy control modules:
o NSLP_对象：包含具有接收到的QoS NSLP对象的列表的数据结构。此列表可由本地应用程序、网络管理或策略控制模块使用：
* RII
* 里伊
* RSN
* RSN
* BOUND-SESSION-ID list
* 绑定会话ID列表
* REFRESH-PERIOD
* 刷新周期
* SESSION-ID-LIST
* 会话ID列表
* RSN-LIST
* RSN-LIST
* INFO-SPEC
* 信息规格
* MSG-ID
* MSG-ID
* BOUND-MSG-ID
* 绑定-MSG-ID
o filter: the information for packet filtering, based on the MRI and the PACKET-CLASSIFIER object.
o 过滤器：基于MRI和数据包分类器对象的数据包过滤信息。
o features_in: it represents the flags included in the common header of the received QOS-NSLP message, but also additional triggers:
o 功能：它表示接收到的QOS-NSLP消息的公共头中包含的标志，但也表示其他触发器：
* BREAK
* 打破
* REQUEST REDUCED REFRESHES
* 要求减少刷新次数
* RESERVE-INIT
* RESERVE-INIT
* TEAR
* 撕裂
* REPLACE
* 代替
* ACK-REQ
* 确认请求
* PROXY
* 代理
* SCOPING
* 范围界定
* synchronization_required: this attribute is set (see Sections Section 4.6 and Section 4.7.1, for example) when the QoS-NSLP functionality supported by a QNE Egress receives a non-tearing RESERVE message that includes a MSG-ID or a BOUND-MSG-ID object, and the BINDING_CODE value of the BOUND-SESSION-ID object is equal to one of the following values:
* 需要同步：当QNE出口支持的QoS NSLP功能接收到包含MSG-ID或BOUND-MSG-ID对象的非撕裂保留消息时，设置此属性（例如，请参见第4.6节和第4.7.1节），绑定会话ID对象的绑定代码值等于以下值之一：
+ Tunnel and end-to-end sessions
+ 隧道和端到端会话
+ Aggregate sessions
+ 聚合会话
* GIST_API_triggers: it represents the attributes that are provided by GIST to QoS-NSLP via the GIST API:
* GIST_API_触发器：它表示GIST通过GIST API向QoS NSLP提供的属性：
+ NSLPID
+ NSLPID
+ Routing-State-Check
+ 路由状态检查
+ SII-Handle
+ SII手柄
+ Transfer-Attributes
+ 转移属性
+ GIST-Hop-Count
+ 跳数
+ IP-TTL
+ IP-TTL
+ IP-Distance
+ IP距离
o incoming_interface: the ID of the incoming interface. Used only when the QNE reserves resources on incoming interface. Default is 0 (no reservations on incoming interface)
o 传入接口：传入接口的ID。仅当QNE在传入接口上保留资源时使用。默认值为0（传入接口无保留）
o outgoing_interface: the ID of the outgoing interface. Used only when the QNE reserves resources on outgoing interface. Default is 0 (no reservations on outgoing interface)
o 传出接口：传出接口的ID。仅当QNE在传出接口上保留资源时使用。默认值为0（传出接口无保留）
The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and "config()" primitives to perform either all or a subset of the features listed below.
RMF使用“recvrmf（）”和“config（）”原语触发QoS NSLP功能，以执行下面列出的所有或部分功能。
The recvrmf() primitive represents either a response to a request that has been sent via the API by the QoS-NSLP or an asynchronous notification. Note that when the RMF/QOSM receives a request via the API from the QoS-NSLP function, one or more "recvrmf()" response primitives can be sent via the API towards QoS-NSLP. In this way, the QOS-NSLP can generate one or more QoS-NSLP messages that can be used, for example, in the situation that the arrival of one end-to-end RESERVE triggers the generation of two (or more) RESERVE messages: an end-to-end RESERVE message and one (or more) intra-domain (local) RESERVE message.
recvrmf（）原语表示对QoS NSLP通过API发送的请求的响应或异步通知。注意，当RMF/QOSM通过API从QoS NSLP函数接收到请求时，可以通过API向QoS NSLP发送一个或多个“recvrmf（）”响应原语。这样，QOS-NSLP可以生成一个或多个QOS NSLP消息，例如，在一个端到端保留的到达触发两个（或多个）保留消息的生成的情况下，可以使用这些消息：端到端保留消息和一个（或多个）域内（本地）保留消息。
The config() primitive is used to configure certain features, such as QNE type, stateful or stateless operation, or bypassing of end-to-end messages.
config（）原语用于配置某些功能，例如QNE类型、有状态或无状态操作，或绕过端到端消息。
Note that the selection of the subset of triggers is controlled by the QoS Model.
请注意，触发器子集的选择由QoS模型控制。
int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status, NSLP_objects, filter, features_out, GIST_API_triggers incoming_interface, outgoing_interface)
int recvrmf（sid、nslp响应类型、qspec、授权信息、状态、nslp对象、过滤器、功能输出、GIST API触发器传入接口、传出接口）
o sid: SESSION-ID - The NSIS session identifier
o sid:SESSION-ID-NSIS会话标识符
o nslp_resp_type: indicates type of response:
o nslp_响应类型：表示响应类型：
* RESERVE
* 储备
* QUERY
* 查询
* RESPONSE
* 回答
* NOTIFY
* 通知
o qspec: the QSPEC object, if present
o qspec：qspec对象（如果存在）
o authorization_info: the AUTHO_SESSION object, if present
o 授权信息：授权会话对象（如果存在）
o status: boolean that notifies the status of the reservation and can be used by QOS-NSLP to include in the INFO-SPEC object:
o 状态：通知保留状态的布尔值，可由QOS-NSLP用于包含在INFO-SPEC对象中：
* RESERVATION_SUCCESSFUL
* 预订成功
* TEAR_DOWN_SUCCESSFUL
* 拆毁成功
* NO RESOURCES
* 没有资源
* RESERVATION_FAILURE
* 预约失败
* RESERVATION_PREEMPTED: reservation was preempted
* 预订被抢占：预订被抢占
* AUTHORIZATION_FAILED: authorizing the request failed
* 授权失败：授权请求失败
* MALFORMED_QSPEC: request failed due to malformed qspec
* 格式错误的_QSPEC：由于格式错误的QSPEC，请求失败
* SYNCHRONIZATION_FAILED: Mismatch synchronization between an end-to-end RESERVE and an intra-domain RESERVE (see Sections Section 4.6 and Section 4.7.1)
* 同步失败：端到端保留和域内保留之间的同步不匹配（请参阅第4.6节和第4.7.1节）
* CONGESTION_SITUATION: Possible congestion situation occurred on downstream path
* 拥堵情况：下游路径可能出现拥堵情况
* QoS Model Error
* QoS模型错误
o NSLP_objects: data structure that contains a list with QoS-NSLP objects that can be used by QoS-NSLP when the QNE is a QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress:
o NSLP_对象：当QNE是QNI、QNR、QNI_入口、QNR_入口、QNI_出口或QNR_出口时，包含QoS NSLP对象列表的数据结构：
* RII
* 里伊
* RSN
* RSN
* BOUND-SESSION-ID list
* 绑定会话ID列表
* REFRESH-PERIOD
* 刷新周期
* SESSION-ID-LIST
* 会话ID列表
* RSN-LIST
* RSN-LIST
* MSG-ID
* MSG-ID
* BOUND-MSG-ID
* 绑定-MSG-ID
o filter: it represents the MRM-related PACKET CLASSIFIER
o 过滤器：它表示与MRM相关的数据包分类器
o features_out: it represents (among others) the flags that can be used by the QOS-NSLP for newly generated QoS-NSLP messages:
o 功能：它表示（除其他外）QOS-NSLP可用于新生成的QOS NSLP消息的标志：
* BREAK
* 打破
* REQUEST REDUCED REFRESHES
* 要求减少刷新次数
* RESERVE-INIT
* RESERVE-INIT
* TEAR
* 撕裂
* REPLACE
* 代替
* ACK-REQ
* 确认请求
* PROXY
* 代理
* SCOPING
* 范围界定
* BYPASSING - when the outgoing message should be bypassed, then it includes the required bypassing level. Otherwise, it is empty. It can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress. It can be unset only by QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress.
* 旁路-当传出消息应被旁路时，它包括所需的旁路级别。否则，它是空的。只能通过QNI_入口、QNR_入口、QNI_出口或QNR_出口进行设置。只能通过QNI_入口、QNR_入口、QNI_出口或QNR_出口取消设置。
* BINDING () - when BINDING is required, then it includes a BOUND-SESSION-ID list. Otherwise, it is empty. It can only be requested by the following QNE types: QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress.
* BINDING（）-当需要绑定时，它包括一个绑定会话ID列表。否则，它是空的。只能由以下QNE类型请求：QNI、QNR、QNI_入口、QNR_入口、QNI_出口或QNR_出口。
* NEW_SID - it requests to generate a new session with a new SESSION-ID. If the QoS-NSLP generates a new SESSION-ID, then the QoS-NSLP has to return the value of this new SESSION-ID to the RMF/QOSM. It can be requested by a QNI, QNR, QNI_Ingress, QNI_Egress, QNR_Ingress, or QNR_Egress.
* NEW_SID—它请求使用新会话ID生成新会话。如果QoS NSLP生成新会话ID，则QoS NSLP必须将此新会话ID的值返回给RMF/QOSM。它可以由QNI、QNR、QNI_入口、QNI_出口、QNR_入口或QNR_出口请求。
* NEW_RSN - it requests to generate a new RSN. If the QoS-NSLP generates a new RSN, then the QoS-NSLP has to return the value of this new RSN to the RMF/QOSM.
* NEW_RSN-它请求生成一个新的RSN。如果QoS NSLP生成新的RSN，则QoS NSLP必须将该新RSN的值返回给RMF/QOSM。
* NEW_RII - it requests to generate a new RII. If the QoS-NSLP generates a new RII, then the QoS-NSLP has to return the value of this new RII to the RMF/QOSM.
* NEW_RII-它请求生成新的RII。如果QoS NSLP生成新的RII，则QoS NSLP必须将该新RII的值返回给RMF/QOSM。
o GIST_API_triggers: it represents the attributes that are provided to GIST via QoS-NSLP via the GIST API:
o GIST_API_触发器：它表示通过GIST API通过QoS NSLP提供给GIST的属性：
* NSLPID
* NSLPID
* SII-Handle
* SII手柄
* Transfer-Attributes
* 转移属性
* GIST-Hop-Count
* 跳数
* IP-TTL
* IP-TTL
* ROUTING-STATE-CHECK (if set, it requires that GIST create a routing state)
* ROUTING-STATE-CHECK（如果已设置，则需要创建路由状态）
o incoming_interface: the ID of the incoming interface. Used only when the QNE reserves resources on the incoming interface. Default is 0 (no reservations on the incoming interface).
o 传入接口：传入接口的ID。仅当QNE在传入接口上保留资源时使用。默认值为0（传入接口上没有保留）。
o outgoing_interface: the ID of the outgoing interface. Used only when the QNE reserves resources on the outgoing interface. Default is 0 (no reservations on the outgoing interface).
o 传出接口：传出接口的ID。仅当QNE在传出接口上保留资源时使用。默认值为0（传出接口上没有保留）。
The config() function is meant for configuring per-session settings, from the RMF towards the NSLP.
config（）函数用于配置从RMF到NSLP的每会话设置。
int config(sid, qne_type, state_type, bypassing_type)
int配置（sid、qne类型、状态类型、旁路类型）
o sid: SESSION-ID - The NSIS session identifier
o sid:SESSION-ID-NSIS会话标识符
o qne_type: it defines the type of a QNE
o qne_类型：定义qne的类型
* QNI
* QNI
* QNI_Ingress: the QNE is a QNI and an Ingress QNE
* QNI_入口：QNE是一个QNI和一个入口QNE
* QNE: the QNE is not a QNI or QNR
* QNE：QNE不是QNI或QNR
* QNE_Interior: the QNE is an Interior QNE, but it is not a QNI or QNR
* QNE_内部：QNE是内部QNE，但不是QNI或QNR
* QNI_Egress: the QNE is a QNI and an Egress QNE
* QNI_出口：QNE是QNI和出口QNE
* QNR
* QNR
* QNR_Ingress: the QNE is a QNR and an Ingress QNE
* QNR_入口：QNE是QNR和入口QNE
* QNR_Egress: the QNE is a QNR and an Egress QNE
* QNR_出口：QNE是QNR和出口QNE
o state_type: it defines if the QNE keeps QoS-NSLP operational states
o state_type：定义QNE是否保持QoS NSLP操作状态
* STATEFUL
* 有状态
* STATELESS
* 无国籍
o bypassing_type: it defines if a QNE bypasses end-to-end messages or not
o 旁路类型：定义QNE是否绕过端到端消息
AAA: Authentication, Authorization, and Accounting
AAA：身份验证、授权和记帐
EAP: Extensible Authentication Protocol
可扩展认证协议
MRI: Message Routing Information (see [RFC5971])
MRI：消息路由信息（请参阅[RFC5971]）
NAT: Network Address Translator
网络地址转换器
NSLP: NSIS Signaling Layer Protocol (see [RFC4080])
NSLP:NSIS信令层协议（参见[RFC4080]）
NTLP: NSIS Transport Layer Protocol (see [RFC4080])
NTLP:NSIS传输层协议（参见[RFC4080]）
OPWA: One Pass With Advertising
OPWA：广告一通
OSP: Open Settlement Protocol
开放式结算协议
PIN: Policy-Ignorant Node
PIN：策略节点
QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)
QNE：支持QoS NSLP的NSIS实体（NE）（参见第2节）
QNI: the first node in the sequence of QNEs that issues a reservation request for a session (see Section 22)
QNI：QNE序列中发出会话保留请求的第一个节点（参见第22节）
QNR: the last node in the sequence of QNEs that receives a reservation request for a session (see Section 22)
QNR：QNE序列中接收会话预约请求的最后一个节点（参见第22节）
QSPEC: Quality-of-Service Specification
QSPEC：服务质量规范
RII: Request Identification Information
请求识别信息
RMD: Resource Management for Diffserv
RMD：区分服务的资源管理
RMF: Resource Management Function
资源管理功能
RSN: Reservation Sequence Number
RSN：预订序列号
RSVP: Resource Reservation Protocol (see [RFC2205])
资源预留协议（参见[RFC2205]）
SII: Source Identification Information
来源识别信息
SIP: Session Initiation Protocol
会话启动协议
SLA: Service Level Agreement
SLA：服务级别协议
Authors' Addresses
作者地址
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
阿尔托大学通信与网络系（Comnet）邮政信箱13000 FIN-00076阿尔托芬兰
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Georgios Karagiannis University of Twente/Ericsson P.O. Box 217 Enschede 7500 AE The Netherlands
乔治斯·卡拉吉安尼斯屯特大学/爱立信邮政信箱217恩斯赫德7500 AE荷兰
EMail: karagian@cs.utwente.nl
EMail: karagian@cs.utwente.nl
Andrew McDonald Roke Manor Research Ltd Old Salisbury Lane Romsey, Hampshire S051 0ZN United Kingdom
安德鲁·麦克唐纳·罗克庄园研究有限公司英国汉普郡老索尔兹伯里巷罗姆西S051 0ZN
EMail: andrew.mcdonald@roke.co.uk
EMail: andrew.mcdonald@roke.co.uk