[要約] RFC 5974は、品質サービスシグナリングのためのNSISシグナリングレイヤープロトコル（NSLP）に関するものです。このRFCの目的は、ネットワーク内での品質サービスのシグナリングを可能にするためのプロトコルを提供することです。
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で開発されたフレームワークと要件に従っています。一般的なインターネットシグナリングトランスポート（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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
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 NSLP」と呼ばれるサービス品質（QOS）NSISシグナリングレイヤープロトコル（NSLP）を定義します。このプロトコルは、そのフローの転送リソースを提供する目的で、データフローのパスに沿ってノードで状態を確立および維持します。RFC 3726 [RFC3726]のQoS関連要件を満たすことを目的としています。このQoS NSLPは、NSISフレームワーク[RFC4080]で構造が概説されているシグナリングプロトコルの大規模なスイートの一部です。要約NTLPは、具体的なプロトコルであるGIST（一般的なインターネットシグナル伝達輸送）[RFC5971]に開発されています。QOS NSLPは、Signalingメッセージ伝達の多くの側面を実行するために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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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：セッションの予約要求を発行するQNESのシーケンスの最初のノード。
QNR: the last node in the sequence of QNEs that receives a reservation request for a session.
QNR：セッションの予約要求を受信するQNESのシーケンスの最後のノード。
P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY scope flag set.
P-QNE：プロキシ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の関連性を定義します。パス、QNI、およびQNR上の中間QNESを使用して、同じ識別子を使用して、協会に保存されている状態を参照します。同じ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）：これは、特定のフローに関連付けられているアプリケーション層セッションの（確率的）グローバルに一意の識別子である暗号化的にランダムであり、（確率的に）グローバルに一意の識別子です。多くの場合、特定のセッションには1つのデータフローしかありませんが、モビリティ/マルチホームのシナリオでは、複数のデータが存在する可能性があり、それらは異なるルーティングが異なる場合があります[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.
ソースまたはメッセージソース：信号メッセージを送信している2つの隣接するNSLPピアの1つ（上流または下流のピア）。これは必ずしも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
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
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によって処理されます。また、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.
助成金処理には、2つのローカル決定モジュール、「ポリシーコントロール」と「入場管理」が含まれます。ポリシー管理は、ユーザーが予約を行う権限を与えられているかどうかを決定します。入場制御により、ノードのネットワークが要求されたQoSを提供するのに十分な利用可能なリソースを持っているかどうかを決定します。両方のチェックが成功した場合、パラメーターはパケット分類器とリンク層インターフェイス（パケットスケジューラなど）に設定され、目的のQosを取得します。エラー通知は、リクエストオリジネーターに渡されます。リソース管理機能は、この段階で転送テーブルを操作して、ルートを選択（または少なくともピン留めする）こともできます。これは、インターフェイス依存のアクションが実行される前に実行する必要があります（新しいルートで発信メッセージの送信を含む）。
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.
QOのタイプとレベルの特定の定義を使用して、入場制御、パケットスケジューリング、および単純な承認を超えたポリシー管理の一部を実装する必要があります。QoS NSLPはQoSパラメーター（例：IntServサービス要素）に依存しないという重要な仮定がなされています。これらはQoSモデルでキャプチャされ、リソース管理と関連する機能によってのみ解釈され、QoS NSLP自体に不透明です。QoSモデルについては、セクション3.1.2でさらに説明します。
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は、4つのメッセージタイプを使用します。
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.
予約：予備のメッセージは、QoS NSLP予約状態を操作する唯一のメッセージです。そのような状態を作成、更新、変更、および削除するために使用されます。予備のメッセージの結果は、メッセージが1回または何度も受信されているかどうかと同じです。
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 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.
通知：通知メッセージは、情報をQNEに伝えるために使用されます。それらは、非同期に送信され、特定の状態または以前に受信したメッセージを参照する必要がないという点で、応答メッセージとは異なります。通知メッセージによって伝えられる情報は、通常、エラー条件に関連しています。例は、予約が先制されたときに、州が取り壊されているか、通知があるという上流のピアに通知することです。
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メッセージには、3種類のオブジェクトが含まれています。
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は、QSPECオブジェクトだけでなく、QoS NSLPメッセージからさまざまな要素を使用する場合があります。
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でのフロー間、またはBoundSession-IDオブジェクトを介して関連する異なるセッションIDのフロー間でリソース共有が可能であると想定しています。同じセッションIDのフローの場合、リソース共有は、既存の予約が交換されていない場合にのみ適用されます（これは共通ヘッダーの交換フラグで示されます）。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モデルに固有の追加のオブジェクトで強化することもできます。結果として、その特定のリソース管理メカニズム（リンク固有の場合があります）。
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の動作、および利用可能なリソース、必要なリソース、トラフィックの説明、RMFが必要とする制御情報を説明するためにQSPEC情報を使用する方法を定義します。QoSモデルは、このQoSモデルについてシグナルを合わせてQNESがQSESで使用するパラメーターの最小セットセットについても説明します。
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モデルは、ローカル（プライベート1つのネットワーク）、実装/ベンダー固有、またはグローバル（異なるネットワークとベンダーが実装可能）にすることができます。すべての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 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モデルの定義は、QoS NSLPが実装者に自由を与える領域でローカルな行動をどのように実装すべきかにも影響を与える可能性があります。たとえば、転送された予約メッセージが受信したメッセージにどのように関連するか、または集約予約に必要な既存のセッションに基づいて追加のシグナルセッションを開始する必要がある場合に、推奨される動作を特定することが役立つ場合があります。場合によっては、オプションで保持される可能性のある状態を特定のシナリオで保持する必要があるかどうかについて提案が行われる場合があります。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)-|---------->
+-------------+ +-------------+
Figure 3: Policy Control with the QoS NSLP Signaling
図3：QoSNSLPシグナル伝達によるポリシー制御
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間の2つのパーティモデルです。実際の政策決定は、第三のエンティティ（ポリシー決定ポイント、PDP）の関与に依存する可能性がありますが、これは既存のポリシーインフラストラクチャ（Common Open Policy Service（COPS）、直径などによってQoS NSLPプロトコルの外で発生します。）。したがって、QNESのエンドツーエンドチェーン全体のポリシー管理モデルは、QSNEのそれぞれがQOS NSLPポリシーピアとポリシー情報を交換する推移性の1つです。
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.
リソース要求の承認は、多くの場合、要求を行うエンティティのIDに依存します。認証が必要になる場合があります。GISTチャネルセキュリティメカニズムは、リクエストを送信したQoS NSLPピアを認証する1つの方法を提供するため、承認決定を下す際に使用される場合があります。
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には現在、認証情報を掲載するオブジェクトは含まれていません。執筆時点では、QoS NSLPおよびNATおよびファイアウォール（NATFW）NSLPのこの機能を定義する個別の作業[NSIS-Auth]が存在します。
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プロトコルスイートは、州の管理に対するソフトステートアプローチを採用しています。これは、QNESの予約状態を定期的に更新する必要があることを意味します。状態のインストールが更新される周波数は、リフレッシュ期間オブジェクトで表されます。このオブジェクトには、値が有効なままであることを示す時間を示すミリ秒単位で値が含まれています。この生涯を超えて予約を維持することは、定期的に予備のメッセージを送信することで行うことができます。
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 receiver-initiated reservation, RESERVE messages travel in the opposite direction (the QNI is at the side of the receiver of the data flow).
QoS NSLPは、送信者が開始した予約と受信機が開始する両方の予約をサポートしています。送信者が開始した予約の場合、予備のメッセージは、合図されているデータフローと同じ方向に移動します（QNIはデータフローのソースの側にあります）。受信機が開始する予約の場合、予備のメッセージは反対方向に移動します（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.
予約メッセージは、設置された予約状態に影響します。Notify、Query、およびResponseメッセージとは異なり、予定メッセージを受信する順序は、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とセッションIDを使用して予約を参照し、完全な予約仕様（QSPECを含む）は含まれていません。デフォルトでは、送信中にバイトを節約するために、Reded Refrehesで状態の更新を実行する必要があります。ステートレスQNESは、予約情報全体を保存しないため、完全な更新が必要です。
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の間に不一致がある場合、ステートフル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には、QNEが（セカンダリ）セッションが更新されるセッションを示すセッションIDリストオブジェクトを含めることができます。RSNリストオブジェクトも追加する必要があります。セッションIDとRSNは、両方のスタックのインデックスが同じ予約状態、つまり両方のオブジェクトのインデックスIのセッションIDとRSNが同じセッションを参照するようにオブジェクトに積み重ねられています。受信しているステートフルQNEが、セッションの不明なセッションIDまたはミスマッチに通知する場合、エラーで上流のステートフル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リストとRSNリストオブジェクトが含まれる場合があります。下流のステートフル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].
予約またはクエリメッセージの場合、2つのスコーピングフラグは、応答できる下流ノードに状態がインストールされているパスの部分を制限します。スコーピングフラグがゼロに設定されている場合、スコープが「パス全体」（デフォルト）であることを示します。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（SIDS）によるシグナル伝達フロー）。
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.
セッションバインディングは、バウンドセッションIDオブジェクトを含めることにより、2つ以上のセッション間の単方向依存関係の関係を示します。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は、異なるメッセージ間で依存関係を表現できるように、メッセージのバインディングをサポートしています。メッセージバインディングは、1つのメッセージ（「バインディングメッセージ」）にMSG-IDオブジェクトを含めることにより、2つのメッセージ間の単方向または双方向依存関係のいずれかを示します。単方向の依存性は、予約メッセージのみが互いに結合されることを意味しますが、双方向依存関係は、関連する応答メッセージに依存関係もあることを意味します。メッセージバインディングは、メッセージIDを使用して後で同期される2つのシグナル交換を同時に開始することにより、シグナリングをスピードアップするために使用できます。
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は、層状の予約をサポートしています。ネットワークの特定の部分（ドメイン）が1つ以上のローカル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は、同じ予約のために2つのセッションを設定できるようにすることにより、この状況をサポートしています。ローカルセッションには、目的のローカル輸送プロパティがあり、内部QNESで解釈されます。このソリューションは、2つの要件を提起します。エンドツーエンドセッションは中間ノードをバイパスできる必要があり、出力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が必要であることです（たとえば、Diffservを超えるIntservの場合のDSCP）。別のMRIの必要性は、セクション3.2.10.2で説明されているように、RFC 3175 [RFC3175]のRSVP集計ソリューションで説明されているように、2つの異なるセッションの使用を義務付けています。
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.
エンドツーエンドのプロパティを維持したい集約ドメインのエッジQNESは、ドメイン上にエンドツーエンドメッセージを透過的に送信することにより、ピアリング関係を確立する場合があります（上記の中間ノードバイパス機能を使用）。このメッセージのエンドツーエンドのプロパティを更新するには、集計されたセッションの知識が必要になる場合があります（遅延値を更新する場合）。この目的のために、エンドツーエンドのセッションには、集約セッションのセッション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の観点から、再ルーティング検出は2つの方法で実行できます。GISTからのNetwork -Notificationを通じて、または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 Peerへの発信インターフェイス）。これらのメカニズムは、実装固有の最適化を提供することができ、この仕様の範囲外です。
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 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（GISTからのネットワーク解釈によって示されます）、およびR-でクエリを送信する必要があります。下流のフラグ。クエリは上記のように処理され、ある時点でQNIに向かって下流のパスが残るQNE（つまり、収束点）にヒットします。このノードは、上流のフルリザーブを送信して、新しいパスに沿って予約状態を設定する必要があります。これは実際に使用されないため、さらに下流にクエリを送信する必要はありません。同様に、クエリを送信した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.
古い予約を維持すると、他のノードが利用できるリソースに影響することに注意してください。したがって、アクセスネットワークのオペレーターは、この動作が許可されているかどうかを最終決定する必要があります。また、アクセスネットワーク内のQNESは、モバイルノードが最初にフラグを使用していない場合でも、このフラグを追加する場合があります。
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.
新しい下流のピアが存在するか、切り捨てが起こったことを検出する際の遅延は、要点に依存します。デフォルトのクエリメッセージ送信間隔は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:
信号パスには最後のノードには3つのケースがあります。
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.
QNEはシグナリングを終了することを知っているため、最初のパスセットアップ中にQOS NSLP自体によってケース（1）および（2）が処理できます。ケース（3）では、APIを介してメッセージを提供するメッセージを提供するGISTの支援が必要です。これは、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.
この3番目のケースでは、2つの特定のシナリオを考慮する必要があります。「パス拡張」と呼ばれる最初のものでは、図4に示すように、追加のQNEが古い最後のノードとデータ受信機の間の信号パスに挿入されるように再ルーティングが発生します。
/-------\ 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 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.
再ルーティングが発生すると、データパスはA-B-DからA-C-Dに変わります。最初はAで終了します。最初は最後のノードであるにもかかわらず、ノードAは、データフロー受信機のシグナリングプロキシとして明示的に構成されていない限り、パス変更のためにプローブの下流にメッセージを送信しようとし続ける必要があります。これは、シグナリングパスの変更が検出され、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.
「パストランケーション」と呼ばれる2番目のケースでは、再編成が発生し、信号パスの最後のノードであったQNEがデータパス上にないようになります。これを図5に示します。
/-------\ 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.
QoS NSLPは、GISTが再ルーティングイベントが発生した可能性があると考えている場合、GIST（ネットワーク解釈プリミティブを使用）によって通知されます。場合によっては、可能なルートの変更として検出されたイベントは、そうでないことが判明します。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 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.
Recvmessage API Primitiveの一部として、GISTはNSLPが使用して特定のピアにシグナリングメッセージを向けることができるSIIハンドルを提供します。シグナリングピアが変更された場合、現在のSIIハンドルは変更されます。ただし、ピアが変更されないルーティングイベントの後、同じままであることは保証されていません。したがって、ルートの変更後の予約メンテナンスのためのQOS NSLPメカニズムには、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) \-/
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）を使用して再ルーティングされます。パスに沿ったQNESのセットは変更されていません（BはQOS NSLPをサポートしていないため、どちらの場合もA-Cです）。
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にNSLPに合わせてNETWORK -NOTIFICATIONを使用して信号を送信する場合があります。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からの応答を要求します。CのQoS NSLPでのGISTからのRecVMessage API呼び出しを通じてこの予備メッセージが受信されると、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へのRecVMessageコールで合格したSIIハンドルは、Aで使用されているインターフェイスが変更されたため、以前に見たものとは異なります。
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.
この時点で、缶は古い道の予約を取り壊そうとします。Tear Flagセットを使用した予備のメッセージは、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およびパスに沿ってさらにQNESで取り壊されます。これを回避するために、RSNは特別な方法で使用されます。新しいパスを下る保護区は、古いRSNプラス2に新しい電流RSNセットを使用して送信されます。古いパスの張られた保護区は、新しい電流RSNマイナス1にRSNセットを使用して送信されます。これはからのピアです。予備のメッセージを受信していました（詳細については、詳細を参照）。
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モデルで使用できるシグナル伝達メカニズムのみを提供します。たとえば、情報スペックオブジェクトをメッセージに追加して、信号セッションが先制されたことを示すことができます。Boundsession-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に渡されます。これは、シグナリングアプリケーションの識別子（「QOS NSLP」、セッション識別子、MRI、、およびセッション識別子、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は、セッションごとにメッセージと予約状態を保持します。セッションは、セッション識別子（セッションID）によって識別されます。Session-IDは、NSLP状態の保存の主要なインデックスであり、ネットワークを通るパスに沿って一定かつ一意である（十分に高い確率を持つ）必要があります。QOS NSLPは、セッション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）との対話方法を提供しません。基本的なNATトラバーサルサービスがGISTによって提供されると想定しています。
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デフォルト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.
ステートレスまたは縮小状態のQoS NSLP操作は、いくつかのノードがGISTレベルでもステートレスの方法で動作できる場合に最も理にかなっています。このようなノードは、逆の状態、メッセージの断片化と再組み立て（GISTで）、混雑制御、またはセキュリティ関連を維持することを心配する必要はありません。ステートレスまたは縮小状態のQNEは、この状況の根底にある要点を知らせることができます。GISTサービスインターフェイスは、Messagereceived Primitiveの保持状態属性とこの機能をサポートします。
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サービスインターフェイスは、Recvmessage PrimitiveでIP-TTLとOriginal-TTLを追跡することにより、これをサポートします。2つの違いは、QOS-NSLP-Unawareノードの数を示します。この場合、この違いを検出するQNEは、「B」（破損）フラグを設定する必要があります。QNEがブレークフラグセットでクエリまたは予約メッセージを受信し、クエリ、予約、または応答メッセージを生成すると、それらのメッセージにブレークフラグを設定できます。ただし、ローカルドメインの出口QNEにQOSを提供する他の手段がある可能性がある状況があります[RFC5975]。たとえば、RMD-QOSM [RFC5977]（または同様のQOSモデル）を認識しているローカルドメインで、NTLPのステートレスノードまたはNSIS-Unawareノードのいずれかを使用します。ステートレスまたはNSIS-Unawareノード。ただし、ローカルドメイン内の予約は、RMD-QOSM（または同様のQoSモデル）によってシグナルを行うことができます。このような状況では、エンドツーエンドの予備またはクエリメッセージの「B」（BREAK）フラグをローカルドメインのエッジによって設定しないでください。
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 | | |
|<---------+ | |
| | | |
| | | |
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パラメーターを説明する選択したQoSモデルから、QSPECオブジェクトを含む予備メッセージを構築します。
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に渡され、次の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に渡され、次の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.
同じ処理は、パスに沿ったQNESで、QNRまで実行されます。ノードが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 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が含まれている場合、興味のあるQNEは新しいRIIオブジェクトを追加したり、古いRIIオブジェクトを交換したりしてはなりません。代わりに、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.
クエリメッセージを使用して、パスに沿ってQNESから情報を収集できます。たとえば、予約が行われる前に利用可能なリソースを見つけるために使用できます。
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はクエリメッセージを作成します。このメッセージには、パスに沿ってQNESで実行される実際のクエリを含むQSPECが含まれます。また、応答をクエリに一致させるために使用される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を運ぶ場合があります。したがって、QNEは、RIIが存在しない場合は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]で説明されているように、一部のシグナリングアプリケーションでは、データフローの一端にあるノードは、ネットワークからリソース予約などの特別な処理を要求する責任を負います。その後、両端は、送信者または受信機が開始する予約を行うかどうかに同意します。受信者が開始した予約の場合、両端は「広告で1つのパス」（OPWA）[OPWA95]モデルが使用されているかどうかに同意します。この交渉は、NSIの範囲外のメカニズムを使用して達成できます。
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.
レシーバーが開始した予約を作成するには、QNRはクエリメッセージを作成します。クエリメッセージは、選択したQoSモデルからQSPECオブジェクトを含める必要があります（図8を参照）。クエリには、リザーブInitフラグが設定されている必要があります。このクエリメッセージでは、応答メッセージをトリガーする必要はないため、QNIはクエリメッセージにRIIオブジェクト（セクション5.4.2）を含めてはなりません。クエリメッセージは、QSPECオブジェクトによって運ばれるパスに沿って情報を収集するために使用できます。そのような情報の例は、「広告付きの1つのパス」（OPWA）モデル[OPWA95]です。このクエリメッセージにより、GISTリバースパス状態がインストールされます。
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に渡され、次のQNEに転送されます。同じ処理が、流れのレシーバーまで、パスに沿ったQNESで実行されます。受信者は、このクエリメッセージが予備のINITフラグを伝達し、QSPECなどの受信クエリメッセージに含まれる情報を使用することにより、予備メッセージを作成することを検出します。
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:
「双方向予約」という用語は、この仕様でサポートされている2つの異なるケースを指します。
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 2つの送信者が開始した予約を結合します。たとえば、1つの送信者がQNE AからQNE Bまで、もう1つは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 Aへのレシーバー開始予約は、QNEからのデータフローについて（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.
両端は、どの双方向予約タイプを使用する必要があるかに同意する必要があります。この交渉は、NSIの範囲外のメカニズムを使用して達成できます。
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.
2つの送信者が開始した予約を備えたシナリオを図9に示します。両方向の予備メッセージは、非対称ルーティングのためにパスに沿って異なるQNEにアクセスする可能性があることに注意してください。フローの両方の方向は、QNIとQNRにバウンドセッションIDオブジェクトを挿入することに拘束されます。応答メッセージはオプションであり、簡単にするために写真には表示されません。
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は、送信者が開始した2つの予約メッセージを送信します。2つの予備メッセージのシーケンスはインターリーブされる場合があることに注意してください。
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 | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
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に「予備」として示されているメッセージで、エンドツーエンドのフローごとの予約が開始されます。
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と1対1の関係を持つ必要はありません。
Aggregator Deaggregator
アグリゲーターDeaggregator
+---+ +---+ +---+ +---+
|QNI|-----|QNE|-----|QNE|-----|QNR| aggregate
+---+ +---+ +---+ +---+ 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).
Deaggregatorは、集計予約のQNRとして機能します。予備のメッセージに掲載されたセッションバインディング情報により、Deaggregatorはエンドツーエンドと総計を互いに関連付けることができます（Bound-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 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.
セクション4.5では、集約されたエンドツーエンドの流れと骨材の相互作用をスケッチします。このシナリオ、そしておそらく他のシナリオでは、さまざまなセッションのシグナリングメッセージの交換を同期する方法があると便利です。一部のメッセージ交換は同時に開始でき、ある特定のセッションからのメッセージのさらなる処理が異なるセッションからの別のメッセージに依存するまで、一部のメッセージ交換を同時に開始でき、並行して処理できるため、これを使用できます。たとえば、図11は、新しい予約を含めるには、包括的な凝集体の容量を最初に増やす必要がある場合を示しています。したがって、Deaggregatorに到着する個々のフローの予備（バウンドメッセージ）は、総計の保護区（バインディングメッセージ）が正常に到着するまで待つ必要があります（そうでない場合、個々のフローは既存の骨材に含まれず、認められません）。もう1つの選択肢は、最初に骨材を増やし、次に集約された個々のフローのセットのリソースを予約することです。この場合、（予備と予備の）メッセージ間の結合と同期は必要ありません。
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オブジェクトは、関連するMSG-IDを運ぶ関連するバインディングシグナルメッセージ（（3））の到着を待つはずです。物体。BoundSession-IDもそれに応じて設定する必要があります。メッセージごとに1つのMSG-IDまたはBound-MSG-IDオブジェクトのみが許可されます。2つのメッセージ間の依存関係が双方向である場合、message_binding_typeフラグが設定されます（値は1）。それ以外の場合、message_binding_typeフラグは設定されていません。ほとんどの場合、対応する応答を取得するには、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の予約（1））と「トリガー」バインディングシグナリングメッセージ（図13の予約 '（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 バウンドシグナル伝達（予備（1））が最初に到着します。受信QNEエンキュー（おそらくいくつかの前処理後）対応するセッションのシグナリング（予備（1））メッセージ。また、関連する「トリガー」メッセージ（図13の予約 '）が到着しない場合にメッセージを破棄するために、MSGIDWAITタイマーを起動します。この時間のタイムアウト期間は、デフォルトの再送信タイムアウト期間（QOSNSLP_REQUEST_RETRY）に設定する必要があります。タイムアウトの前に再送信された予備のメッセージが届く場合、待機中のメッセージをオーバーライドするだけです（つまり、後者が破棄され、新しいメッセージが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 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.
同時に、MSG-IDオブジェクトを含む「トリガー」メッセージ、Bound-MSG-IDオブジェクトと同じ値を運ぶメッセージは、同じ開始QNEによって送信されます（図13のQNI '）。中間QNE 'はMSG-IDオブジェクトを表示しますが、セッション（QNR'）のエンドポイントではないことを判断することができ、したがって通常の処理後にメッセージを単純に転送します。集約セッションのエンドポイントとして受信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 | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
(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）：この場合、トリガーメッセージの処理はメッセージ_binding_typeフラグの値に依存します。message_binding_typeがunset（value is 0）の場合、トリガーメッセージは正常に処理できますが、MSG-IDと結果（成功または失敗）を待機メッセージの場合は保存する必要があります。したがって、応答はQNRによってすぐに送信できます。待機中のメッセージ（1）が最終的にQNRに到着した場合、トリガーメッセージがすでに以前に到着したため、待機条件がすでに満たされていることが検出できます。message_binding_typeが設定されている場合（値は1）、トリガーメッセージはMSG-IDオブジェクトを解釈し、同じ値のバウンドMSG-IDで対応する待機メッセージを探します。この場合はまだ到着していません。次に、関連するメッセージ（図14の予約（1））が到着しない場合にメッセージを破棄するために、MSGIDWAITタイマーを起動します。保護区の処理の成功（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に向けて応答メッセージを送信して、2つのメッセージの同期が失敗したことを通知する場合があります。
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 通常、2つの関連するメッセージのうち1つだけが再送信されるため、再送信は同じ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によってインデックス付けされた概念的に2つのリストがあります。1つのリストには、メッセージをトリガーするIDと結果（MSG-IDオブジェクトを運ぶもの）が含まれています。もう1つのリストには、バインドされた待機メッセージのIDSとメッセージ内容（Bound-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.
この例では、GISTおよびNSLP機能と組み合わせて、ドメイン内の異なるQOSモデルを使用して、インテリアノードが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を参照）。ステートレスまたは縮小状態領域の端にあるQNESでは、処理が異なり、ノードは2つの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ホップです。内部の要点状態を必要とせずに、侵入と出口の間で信頼できる要点転送モードを使用できます。出力ノードでは、予備のメッセージが正常に転送されます。
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.
イングレスでは、2番目の予備のメッセージも構築されています（図14）。これにより、QOSモデルが縮小された操作またはステートレスの動作形式（RMDごとの予約など）に適しています。元の保護区と保護区のメッセージは同じように対処されているため、予備のメッセージは、予備のメッセージによっても横断された同じ出力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 (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.
内部（ステートレス）ノードで処理されると、QoS NSLP処理は、可能な限り状態を維持しないようにオプションを行使します。QSPEC関連のデータについては、クラスごとに、これらの内部ノードに保持される場合があります。QoS NSLPは、GISTが異なる輸送特性を使用することも要求しています（たとえば、信頼できない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| | | |
<--------| | | |
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に送り返すことはできません。したがって、保護区は意図したパスに沿って転送されますが、QSPECにはその後のQNESの情報が含まれており、エラーが上流で発生しました。何をすべきかを決定するのは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 | | |
<--------| | |
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は応答を待つ必要があります」。応答が予約が正常に達成されたことを通知した場合、Ingress 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）として、たとえば管理ドメインのプロキシ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.
プロキシモードには2つの用途があります。まず、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-Flagを設定します。
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は、既存のメッセージルーティング状態がある場合、またはアップストリーム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-DATAオブジェクトにまとめられています。次のサブセクションでは、共通ヘッダーの形式と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]で指定された拡張されたバックNAURフォーム（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-DATAオブジェクトは、オブジェクトの最初の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the common header are as follows:
共通ヘッダーのフィールドは次のとおりです。
Msg Type: 8 bits
MSGタイプ：8ビット
1 = RESERVE
2 = QUERY
3 = RESPONSE
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).
一般的なフラグは、すべてのメッセージタイプに対して同じ意味を持っています。現在、4つの一般的なフラグが存在します。（次のホップ）スコーピングフラグ、プロキシスコープフラグ（P）、承認要求フラグ（a）、およびブレークフラグ（b）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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").
スコープ（S） - 設定すると、メッセージがスコープされており、パス全体を下に移動しないでください。デフォルトでは、このフラグは設定されていません（デフォルトのscope = "全体のパス"）。
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.
Proxy（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.
break（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.
ACK-REQフラグは、QNEが下流のQNEによって受信されたメッセージが、GISTだけではなくQOS NSLPによって本当に処理されることを確認したい場合に役立ちます。これは、NSLPレイヤーでの死んだピア検出が速くなるのに役立ちます。このLivelinessテストは、リフレッシュリザーブメッセージでのみ使用できます。ACK-REQフラグは、QNRから確認が既に要求されているため、すでにRIIオブジェクトを含む予備メッセージに設定してはなりません。2つのQoS NSLPピア間のメッセージの信頼できる送信は、NSLPだけでなく、GISTで処理する必要があります。
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 ]
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:
リザーブメッセージを使用して、共通ヘッダーで使用するために、2つのメッセージ固有のフラグが定義されています。これらは：
+-+-+-+-+-+-+-+-+
|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） - 設定すると、フラグには2つの用途があります。まず、異なる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をBoundsession-IDオブジェクトに含める必要があります。集約されたトンネルの状況では、集約されたセッションには、Boundsession-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からエラーが発生する可能性があります。それ以外の場合は、2つのセッションの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.
予約が既にインストールされており、他の方向から同じセッション識別子を使用して予約メッセージが受信された場合（つまり、予約が下流の予備メッセージによってインストールされた上流にある、またはその逆）、「から受け取った予備」を示すエラーがあります。間違った方向」は、この2番目の予備の信号メッセージソースへの応答メッセージで送信する必要があります。
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再送信は無効にする必要があります。RIIが含まれている涙液を送るQNEは、信頼できる輸送を使用するように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.
注：ホストがこのメカニズムを使用して、QNESをパス上のQNESに絶えず強制して、リフレッシュリザーブメッセージを送信することができます。したがって、QNESが送信する更新メッセージでレート制限を実行するのが適切かもしれません。
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を後続の予備のパケット分類目的に使用する必要があります。クエリメッセージには、2番目の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:
1つのメッセージ固有のフラグは、クエリメッセージを使用して共通ヘッダーで使用するために定義されています。そうです：
+-+-+-+-+-+-+-+-+
|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.
リザーブ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をBoundsession-IDオブジェクトに含める必要があります。集約されたトンネルの状況では、集約されたセッションには、Boundsession-IDのバインドセッションのセッションIDが含まれない場合があります。
The format of a RESPONSE message is as follows:
応答メッセージの形式は次のとおりです。
RESPONSE = COMMON-HEADER [ RII / RSN ] INFO-SPEC [SESSION-ID-LIST [ RSN-LIST ] ] [ QSPEC ]
Response = 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.
応答メッセージには、予約のインストールまたはエラー条件の成功を示す情報スペックオブジェクトを含める必要があります。情報スペックの値に応じて、応答には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 = Common-Header Info-Spec [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.
通知メッセージには、通知の理由を示す情報スペックオブジェクトを含める必要があります。情報仕様の値に応じて、追加情報を提供する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）オブジェクト形式を使用します。すべてのオブジェクトは、1ワードのヘッダーを備えた1つ以上の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
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」とマークされたビットは、プロトコル仕様で処理が定義されていないオブジェクトの目的の処理を信号するために使用されるフラグです（つまり、そのタイプフィールドは受信機では不明です）。次の4つのカテゴリのオブジェクトが特定されており、ここで説明されています。
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（ "Ingrore"）：オブジェクトが理解されていない場合は、削除し、メッセージの残りを通常どおり処理する必要があります。
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（ "Forward"）：オブジェクトが理解されていない場合、メッセージ処理の結果として転送されたメッセージで変更されずに保持する必要がありますが、ローカルに保存されません。
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（ "REFRESH"）：オブジェクトが理解されていない場合、このフロー/セッションのためにローカルに保存された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に設定され、レセプションでは無視されます。Extensibilityフラグは、GIST仕様で使用されるものと似ています。この仕様で定義されているすべてのオブジェクトは、すべてのQNEによって理解する必要があります。したがって、ABビットを「00」に設定する必要があります。QoS NSLP実装は、RII、RSN、REFREFPERIOD、BoundSession-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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットBinding_Codeが含まれています。残りは、このオブジェクトを運ぶメッセージに関連付けられたセッションにバインドする必要があるセッションのセッションID（GIST [RFC5971]で指定[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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
上記の5つの原子結合アクションに基づいて、より多くの結合コードを定義できます。注メッセージには、複数のバウンドセッションIDオブジェクトが含まれる場合があります。これは、より具体的にバインドの理由をより具体的に定義する必要がある場合、またはセッションが他の複数のセッションに依存している場合（おそらく異なる理由がある場合）、これが必要になる場合があります。たとえば、SID_A（バインディングセッション）とのセッションでは、メッセージにSID_Bを含むBoundSession-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) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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のみを使用します。メソッド固有の分類器データは4バイトの長さで、フラグのセットで構成されています。
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 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.
B-宛先ポートフラグは、Packet分類器がMRIから使用する必要がある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を追加のルーティングメカニズムに拡張する可能性があります。このようなMRMSには、QoSが識別されるパケットのサブセットを許可するために、MRIに十分な情報を含める必要があります。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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class Field:
クラスフィールド：
The four E-Class bits of the object indicate the error severity class. The currently defined error classes are: o 1 - Informational
オブジェクトの4つのEクラスビットは、エラーの重大度クラスを示しています。現在定義されているエラークラスは次のとおりです。O1-情報
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-サポートされていないReded Refreshes;完全なQSPECが必要です。
* 0x04 - Congestion situation: Possible congestion situation occurred on downstream path.
* 0x04-うっ血状況：下流の経路でうっ血状況の可能性が発生しました。
* 0x05 - Unknown SESSION-ID in SESSION-ID-LIST.
* 0x05-SESSION-IDリストの不明なセッションID。
* 0x06 - Mismatching RSN in RSN-LIST.
* 0x06- RSNリストの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
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.
現在、3つのエラーソース識別子が定義されています：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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
オブジェクト内のフィールドに誤った値がある場合、情報スペックの最後に次のオプションのエラー固有の情報が追加される場合があります。
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットmessage_binding_type（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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットmessage_binding_type（d）が含まれています。残りは、別のメッセージのメッセージIDを参照する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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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.
値：QoSモデルに依存する変数長QSPEC（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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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が使用する一般的な処理ルールを提供します。RM/QOSMとQOS-NSLP機能の間に通信されたトリガーは、付録Appedix A.1、付録A.2、および付録A.3に記載されています。
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操作状態。
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状態は、次の構造を持つテーブルに概念的に編成されています。テーブルの主キー（インデックス）はセッションIDです。
SESSION-ID A 128-bit identifier.
SESSION-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を通過するローカル識別子です。特定のGist Next Hopを参照できるハンドルです。詳細については、[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 A 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によって受信されます。これは、別のメッセージ（受信したメッセージと同一であるか、そこからオブジェクトのサブセットが含まれている可能性がある）を送信して、同じ方向（つまり、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 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.
再送信は、エンドツーエンド（たとえば、RIIオブジェクトを使用してQNIとQNRの間）またはピアツーピア（2つの隣接するQNESの間）に発生する場合があります。QNEがRIIオブジェクトセットを使用してリザーブを送信すると、応答するQNEからの応答を待ちます。RIIオブジェクトを含めることによって応答が要求されるが、応答を引き出すことができないQOS NSLPメッセージは再送信されます。同様に、QNEにはACK-REQフラグが含まれて、すぐにピアからの更新メッセージの受信の確認を要求する場合があります。再送信されたメッセージは、元のメッセージとまったく同じでなければなりません。たとえば、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:
最初の再送信は、QOSNSLP_REQUEST_RETRY待機期間後に発生します。交換は、待機間隔を指数関数的に増加させる（毎回待機を2倍にする）ことで行う必要があります。QoS NSLPメッセージは、応答（エラーである可能性がある）が取得されるまで、または初期送信後QOSNSLP_RETRY_MAXのいずれかになるまで再送信する必要があります。後者の場合、障害はシグナリングアプリケーションに示される必要があります。上記のタイマーのデフォルト値は次のとおりです。
QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial retransmit of the message
qosnslp_request_retry：メッセージの最初の再送信の2秒待機間隔
QOSNSLP_RETRY_MAX: 30 seconds Period to retry sending the message before giving up
qosnslp_retry_max：あきらめる前にメッセージを送信するための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 [電流]）が最初は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 [current] = rsn0であるRSNが含まれている必要があります。このメッセージを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 [current]である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.
リザーブを送信した後に受け取った応答が新しいパスに情報スペックに「リフレッシュ成功」コードが含まれている場合、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は、特定されたMRIに関連付けられたシグナリングセッションについて、情報コード0x02を使用して通知メッセージを送信する必要があります。これが送信される場合は、SIIハンドルを使用してGIST明示的なルーティングメカニズムを使用して、古いピアに送信する必要があります。
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は、上流の通知メッセージを送信する必要があります。Notifyメッセージは、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: 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
上流のルートの変更を検出した後、QNEは新しいアップストリームピアを電流と見なし、以下の場合を除き、古い上流のピアに戻ることはありません。古い上流のピアから再びメッセージを受信するか、
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ルーティング状態は、見た最新の上流のピアを追跡しているため、古い上流のピアがそのノードの状態が明示的に取り壊されるか、タイムアウトするまでルーティング状態を再reseしたときにルートの変更が発生することを示唆している可能性があります。
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が現在の保存値よりも少ない場合でも）値。
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をコピーする必要があります。
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 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.
中間QNEが発信メッセージの応答を受信したいが、メッセージに到着時にRIIが既に含まれている場合、QNEは新しいRIIオブジェクトを追加したり、古いRIIオブジェクトを置き換えたりする必要はありませんが、このRIIを単に覚えておく必要があります。後の応答メッセージに一致します。応答を受信すると、応答が上流の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は、指定されたセッションのパス上の最後のものです。
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は複数のセッションを一緒に関連付けることができます。これは、別のセッションのメッセージにBoundsession-IDオブジェクトにあるセッションからセッション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.
Boundsession-IDオブジェクトを使用してメッセージを受信する場合、QNEは、同じセッションに対して送信されるすべてのメッセージにBoundSession-IDオブジェクトをコピーする必要があります。セッションごとの状態を保存するQNEは、BoundSession-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.
Boundsession-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 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.
リフレッシュタイマー管理値は、局所的な重要性のみを持つREPHRES-FERIODオブジェクトによって運ばれます。「リフレッシュタイムアウト」期間の満了時に、各QNEは独立して状態を調べ、吸収される次のQNEピアにリフレッシュリザーブメッセージを送信します。このピアツーピアのリフレッシュ（QNIがQNRまで移動するリフレッシュを開始するのではなく）により、QNESは環境に適したリフレッシュ間隔を選択できます。たとえば、予約が比較的安定しているバックボーンのさわやかな間隔は、アクセスネットワークよりもはるかに大きいと考えられます。「更新タイムアウト」は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状態に関連する2つの時間パラメーターがあります。近隣ノードによる状態の連続したリフレッシュの生成の間の更新期間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.
6つのクラスの情報スペックオブジェクトが識別され、セクション5.1.3.6で指定されています。各クラスのメッセージ処理ルールを以下に定義します。
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に向かって情報スペックオブジェクトを運ぶ必要があります。応答メッセージは、QNIまで無条件に転送する必要があります。情報スペックオブジェクトを受信するQNIが実施すべきアクションは、このQNEによってサポートされるQOSモデルのローカルポリシーによって指定されます。デフォルトのアクションは、情報スペックオブジェクトを受信する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.
情報情報スペッククラスは、情報エラークラスがキャッチされたときに、ステートフルQOS NSLP QNEによって生成される必要があります。情報情報スペックオブジェクトは、応答または通知メッセージによって運ばれる必要があります。
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によって情報スペックオブジェクトを生成する必要があります。Success 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によって受信され、プロトコルエラーがキャッチされた場合、Protocol Error Info-Specクラスは、ステートフルQoS NSLP QNEによって生成される必要があります。双方向の予約の場合、予備またはクエリメッセージがQNEによって受信され、プロトコルエラーがキャッチされた場合、Protocol Error Info-Specクラスは、ステートフルQoS NSLP QNEによって生成される必要があります。応答メッセージは、このオブジェクトを運ぶ必要があります。このオブジェクトは、この情報スペックオブジェクトの生成をトリガーする予備またはクエリメッセージを生成する上流の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によって受信され、1つの過渡障害エラーコードがキャッチされた場合、またはイベントが発生する場合に、一時的な障害情報スペッククラスをステートフルQOS NSLP QNEによって生成する必要があります。過渡エラー。双方向の予約の場合、予備またはクエリメッセージがQNEによって受信され、1つの過渡障害エラーコードがキャッチされた場合、一時的な障害情報スペッククラスは、ステートフル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.
応答メッセージは、このオブジェクトを運ぶ必要があります。このオブジェクトは、この情報スペックオブジェクトの生成をトリガーする予備またはクエリメッセージを生成する上流のQNEに無条件に転送する必要があります。一時的なRMF関連エラーは、通知メッセージによっても実行される場合があります。デフォルトのアクションは、この情報スペックオブジェクトを受信するQNEが、情報スペックオブジェクトの生成をトリガーした予備またはクエリメッセージの再送信を再トリガーする必要があることです。このようなエラーを検出するステートレス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リストは、予備のメッセージで携帯されています。2つのケースで使用され、指定されたセッションをリフレッシュしたり、取り壊したりするために使用されます。セッションIDリストには、保護区に示されているメイン（プライマリ）セッションに加えて、リフレッシュまたは取り壊す必要のあるセッションに関する情報が含まれています。
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がセッションIDリストを通過する場合、1つ以上の不明なセッションID値を見つけた場合、セッション中の不明なセッションIDのエラーコードを使用して、アップストリームステートフルなQNEに情報応答メッセージを戻す必要があります。id-list、およびすべての未知のセッションIDをセッション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.
保護区が裂傷である場合、セッションIDリストの各セッションで、ステートフル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リストオブジェクトも処理する必要があります。
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リストは予備のメッセージに携帯する必要があります。RSNリストオブジェクトには、同じセッションのRSN値を入力し、セッションIDリストに示されているのと同じ順序で入力する必要があります。したがって、位置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リストを処理してはなりません。代わりに、エラー応答を上流のステートフルな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リストオブジェクトを受信すると、Stateful QNEは、セッションIDリストとRSNリストオブジェクトのアイテムの数が一致するかどうかを確認する必要があります。不一致がある場合、ステートフル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リスト値をセッション-IDリスト値に一致させる間、RSNリストの1つ以上のRSN値がローカル値と同期していない場合、ステートフルQNEはエラーコードを使用して情報応答メッセージを作成する必要があります。RSNリストのRSNミスマッチ。ステートフルQNEには、セッションIDリストに誤ったセッションIDとRSN値を、応答に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リストの処理にエラーが見つからなかった場合、ステートフルQNEはすべてのセッションの予約状態を再表示します - リフレッシュに示された主要な単一セッション、およびセッションIDリストのすべてのセッション。
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は予約状態の更新を実行します。したがって、一部のセッションが同期していなくても、セッションIDリストとRSNリストの残りのセッションは更新されます。
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:
このセクションでは、メッセージ処理のルールを提供します。すべての可能なエラー状況が考慮されるわけではありません。誤ったメッセージを処理するための一般的なルールは、ノードが反応する方法を決定する前に状況を評価する必要があるということです。誤ったメッセージに反応する方法は2つあります。
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.
予備のメッセージは、QNESの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, 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は共通ヘッダーフラグをチェックします。涙フラグが設定されている場合、メッセージは完全なQoS NSLP状態の除去を示す裂け目の予備です（ゼロリソースの予約とは対照的に）。このような予備のメッセージを受信すると、QNEはRMFに予約が不要になったことを通知する必要があります。RSN値を処理する必要があります。この後、2つの操作モードがあります。
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上）。上流のQNESがすでにセッション状態を削除しているため、裂傷保護区の処理のエラーをQNIに送り返さないでください。したがって、彼らはエラーに対して何もすることができません。
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は、QNIに向かう涙の応答が受信されるまで、NSLPの動作状態を維持する必要があります。この運用状態は、1つの更新間隔のために保持する必要があります。その後、セッションのNSLP動作状態が削除されます。QoSモデルに応じて、ティアメッセージには、状態除去をさらに指定するQSPECが含まれる場合があります。QOSモデルにQSPECが必要であり、NONTが提供されていない場合、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モデルでは必要ない場合、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.
Tearing ReserveにセッションIDリストが含まれている場合、ステートフル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にバインドされ、このセッションに依存している予約がある場合（BoundSession-IDオブジェクトにこのセッションのセッションIDが含まれ、バインディングコード0x04を使用します）。適切な情報スペック。QNEにバインドされた予約がありますが、このセッションに依存していない場合（BoundSession-IDオブジェクトのバインディングコードには、0x01、0x02、または0x03の値の1つがあります）、通知メッセージが送信される場合があります適切な情報スペックを使用した各予約について。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).
既に状態がインストールされているが、異なるフローIDが既存の予約を置き換える（そして予備を受け取った場合、古い支店の予約を取り壊すことを既にインストールしているセッションIDで予備を受け取るQNEのデフォルト動作別の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.
交換フラグがゼロに設定されているが同じSIIを備えたリザーブを受け取るQNEは、RMF（リソース処理に使用される）に置き換え= 0を示します。さらに、QNEがQOS NSLP状態を維持している場合、QoS NSLP状態に新しいフローIDも追加されます。SIIが異なる場合、これはQNEがマージポイントであることを意味します。その場合、上記で指定された操作に加えて、値の置換= 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が含まれていない場合、ノードは上流のピアに欠落しているQSPECを示す情報スペックを含む応答メッセージを送信する必要があります（「完全な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によってリソース処理が実行されます。置換フラグをゼロに設定したセッションの場合、QoSモデルにはリソース共有に対処するための指示が含まれていると想定しています。これには、予約を追加するか、2つ以上の複雑な数学操作を最大限に活用することが含まれます。
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なしで保護区を受け取る可能性があります。これは、更新された減少の場合です。この場合、完全なQSPECでさわやかなリザーブを送信するのではなく、セッションIDとRSNのみが予約を更新するために送信されます。このメカニズムはメッセージサイズを削減するだけであることに注意してください（おそらく処理を緩和します）。セッションごとに1つの予備が必要です。このような更新の削減には、セッションIDリストとRSNリストがさらに含まれる場合があります。これには、プライマリセッションに沿って更新されることがさらにセッションが表示されます。これらのオブジェクトの処理については、このドキュメントで前述しました。
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が必要な応答で応答することにより、このエラーを示す必要があります"）。予約の寿命を更新する必要があります。交換フラグが設定されていない場合、API上でGISTで渡される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がBreak Flagが設定されていない予備のメッセージを受信する場合、GIST Recvmessageプリミティブの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をBoundsession-IDオブジェクトに含める必要があります。集約されたトンネルの状況では、集約されたセッションには、Boundsession-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」フラグを設定します。GIST [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.
- リザーブ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フラグセットでリフレッシュリザーブを送信し、QOSNSLP_RETRY_MAXの再送信期間内に即時のステートフルピアから応答を受け取らなかった場合、QNEはすぐに上流のステートリーピアに通知を送信し、「パスを示す」切り捨てられた - 次のピア・デッド」QNRからの確認が既に要求されているため、ACK-REQフラグはすでにRIIオブジェクトを含む予備に追加されるべきではありません。
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は、確認成功コードを運ぶ情報スペックで応答を送り返す必要があります。QNEには、セッションに送信される次の更新メッセージにACK-REQフラグを含めることができます。診断目的でACK-REQ-FLAGを使用することは、政策の問題です。確認された更新メッセージを使用して、エンドツーエンドのパスをプローブして、まだ無傷であることを確認できます。
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を参照してください。レシーバーが開始した予約を開始するためのリクエストは、予備の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を返す場合があります。
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はリザーブInitフラグが設定されているかどうかを確認します。フラグが設定されている場合、クエリはリバースパス状態のインストールに使用されます。この場合、QNEがQNIでない場合、下流を送信する新しいクエリメッセージが作成されます。QSPECをRMFに渡す必要があり、そこでQoS-Model固有のクエリ処理によって変更される場合があります。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を通過したときに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.
リザーブ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が予備のINITフラグとブレークフラグセットを使用してクエリメッセージを受信した場合、新しく生成されたメッセージのブレークフラグ（例：クエリ、リザーブ、または応答）を設定する必要があります。ステートフルなQOS NSLP QNEが予備INITフラグセットとBreak Flagが設定されていないクエリメッセージを受信する場合、GIST RecvmessageプリミティブのIP-TTLとORIGINAL 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は、確認成功コードを運ぶ情報スペックで応答を送信する必要があります。
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 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.
RIIオブジェクトを含む応答メッセージを受け取ったとき、ステートフルQOS NSLP QNEは、そのシグナリングセッションの未解決の応答要求にそれを一致させようとする必要があります。試合が成功した場合、情報や成功情報のスペッククラスが含まれている場合、応答をパスに沿ってさらに転送してはなりません。QNEがこのRII自体を挿入しなかった場合、次のピアに応答を転送する必要があります。したがって、成功を示す回答の場合、QNEがRIIを単独で挿入した場合にのみ転送が停止する必要があります。応答にエラーを示す情報スペックがある場合、次の段落で説明されているようにRSNSを使用して、転送を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を適切なシグナリングセッションのそれと比較する必要があります。一致が成功した場合、情報スペックを処理する必要があります。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.
情報スペックがエラーの状況を通知するために使用されない場合（上記を参照）、応答メッセージに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.,
典型的な場合、応答メッセージは中間QNESにインストールされている状態を変更しません。ただし、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]制限を定義でき、下流のQNESは上流ノードよりも少ないリソースを提供します。つまり、上流ノードはリソース予約の一部をリリースする可能性があります。
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 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).
通知メッセージは、情報を非同期にQNEに伝えるために使用されます。通知メッセージでは、状態がインストールされません。状態を削除する決定は、QoSモデルによって異なります。正確な操作はQoSモデルに依存します。通知メッセージでは、他のメッセージが直接送信されません。通知メッセージは、他のメッセージに応じてではなく、非同期に送信されます。どちらの方向（上流または下流）に送られる場合があります。
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は、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「予約済み」は、リソースが先制されたQNIに送信されます。Notifyメッセージは、1つのQNEにセッションの予約がなくなっていないという情報をQNIに伝えます。使用されているQoSモデルに基づいて何をすべきかを決定するのはQNI次第です。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]に従って、QOS NSLPに関連する値の登録に関するインターネット割り当て番号局（IANA）にガイダンスを提供します。
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メッセージタイプ-QOSNSLPバインディングコード - 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ビット値です。この仕様では、このレジストリの初期内容を形成する4つの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-list（0x007）、rsn-list（0x008）、msg-id（0x009）、bound-msg-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.
BoundSession-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.
さらに、情報スペックオブジェクトのエラークラスとエラーコードが定義されています。これらはセクション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 128-191: Experimental/Private Use
64-127：必要な仕様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.
値1-3は、セクション5.1.3.6に記載されています。
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で要求されているように、QoS NSLP集約レベル0〜31に対応する32のNSLPID値が割り当てられています。
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: Authorization:
QoS NSLPのセキュリティ要件は、特定されたセキュリティの脅威に対するQoS留保を確立するためのシグナリング交換を保護することです。シグナル伝達の問題全体として、これらの脅威はNSISの脅威[RFC4081]で概説されています。NSISフレームワーク[RFC4080]は、GISTに対する責任のサブセットを割り当て、NSLPSによって残りの脅威に対処する必要があります。処理される主な問題は、次のように要約できます。
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予約を要求するユーザーは、サービスの拒否と財政的損失につながるスプーフィングやその他のセキュリティの脆弱性に対する適切なリソースの会計と保護を必要とする場合があります。多くの場合、許可は認証されたアイデンティティに基づいています。承認ソリューションは、リプレイ攻撃が不可能またはある程度に限定されていないことを保証する必要があります。許可は、ユーザーが匿名を維持できるようにする特性に基づいている場合もあります。ユーザーIDのサポートの機密性を達成することができます。
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.
QNESは、送信する更新メッセージでレート制限を実行する必要があります。攻撃者は意図的に誤ったメッセージを送信し、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 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.
QoS NSLPは、ある程度、GISTによって提供されるセキュリティメカニズムに依存しており、それ自体が既存の認証と主要な交換プロトコルに依存しています。一部のシグナルメッセージはGISTによって保護できないため、QOS NSLPが注意して使用する必要があります。APIは、QoS NSLP実装が基礎となるセキュリティメカニズムを認識していることを確認する必要があり、2つのGISTピア間でどの程度のセキュリティが提供されているかを示すことができなければなりません。必要なQOS NSLPメッセージのセキュリティ保護レベルが、GISTまたは基礎となるセキュリティメカニズムによって提供されるセキュリティを超えている場合、このドキュメントで説明されている追加のセキュリティメカニズムを使用する必要があります。NSIが使用されるさまざまな使用環境とシナリオにより、柔軟性を低下させることなく一般的な声明を発表することは非常に困難です。
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.
この仕様は、QOSシグナリングパスに沿ってトラストのチェーンを確立するために、隣接するNSLPノード間の信頼を必要とするモデルに基づいています。このモデルは展開が簡単で、以前の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.
ニュージャージーのターンパイクでは、運転手は高速道路に入るときに料金所でチケットを受け取ります。高速道路の出口では、チケットが提示され、距離駆動型の料金所で支払いが行われます。インターネットでのQoSシグナリングの場合、この手順はほぼ類似しています。ほとんどの場合、データ送信者は、近隣のエンティティ間で充電が提供される場合に送信されたデータトラフィックに対して請求されます。
+------------------+ +------------------+ +------------------+
| 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
====> Data flow
.... 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信号メッセージを保護できます。認証段階と主要な確立フェーズで使用されるIDは、ネットワーク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]さまざまな会計上の意味合いについて話し合い、エッジ価格設定モデルを導入しました。エッジ価格モデルは、モビリティとセキュリティへの影響に対処されていないことを除いて、このセクションで説明したモデルとの類似性を示しています。
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.
2パーティのアプローチ（図17）は、概念的に最も単純な承認モデルです。
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
Figure 17: Two-Party Approach
図17：2パーティのアプローチ
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.
この例では、承認決定には2つのエンティティのみが関与するか、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.
このタイプのモデルは、たとえば、充電を管理するために長期契約（またはその他の帯域外メカニズム）が存在する2つの隣接ネットワーク（ドメイン間シグナリング）の間に適用される場合があり、個々のリクエストを承認するのに十分な情報を提供します。
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]に記載されているトークンなど、オープン決済プロトコル[OSOP]の一部として使用されます。承認トークンは、2つの異なるシグナル伝達プロトコルの実行（SIPやNSIなど）とその承認決定を互いに関連付けるために使用されます。後者は、アサーションまたは特性の一形態です。例として、承認トークンメカニズムを使用して、図18のリソース承認エンティティとして機能するSIPプロキシによって何らかの形の認可が提供されます。リクエストが承認されている場合、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 |
+-------------+ +--------------+
Figure 18: Token-Based Three-Party Approach
図18：トークンベースの3パーティのアプローチ
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 |
+-------------+ +--------------+
Figure 19: Three-Party Approach
図19：3パーティのアプローチ
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):
許可決定を下す必要があるときはいつでも、どの情報が認可エンティティへの入力として機能するかについての問題があります。以下の情報項目は、認証決定の決定を計算するために過去に言及されています（認証されたIDに加えて）：
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.
著者は、エレノア・ヘプワース、ルーデガー・ガイブ、ローランド・ブレッシー、ネメス・クリスティアン、マルクス・オット、マイ・ズーマロ・ダジョーン、マルティン・スワニンク、ルード・クラバーの有用なコメントに感謝したいと思います。特に、ローランドはドキュメントの深いレビューを行っており、プロトコルが明確に定義されていることを確認しています。ボブ・ブレーデンは、感謝して受け取られた有益なコメントとガイダンスを提供しました。
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.
このドキュメントでは、3つの個別のドキュメントからの作業を組み合わせています。これらの文書の以下の著者は、この文書にも貢献しました：ロバート・ハンコック（シーメンス/ローク・マナー研究）、ハンヌ・ツェーフェニグとコーネリア・カプラー（シーメンスAG）、ラース・ウェストバーグとアッティラ・バーダー（エリクソン）、およびマルテン・ブエチ（ダンテ）とエリック・ウェーエグマン（アルカテル）。さらに、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以来、Jukka Matherは編集を行いました。Yacine El Mghazli（Alcatel）はAAAにテキストを貢献しました。チャールズ・シェンとヘニング・シュルツリンヌは、境界線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、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975] Ash、G.、Bader、A.、Kappler、C。、およびD. Oran、「サービス品質NSISシグナリング層プロトコル（NSLP）のQSPECテンプレート」、RFC 5975、2010年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] Mater、J.、Stiemerling、M.、Tschofenig、H。、およびR. Bless、ed。、「NSIS Signaling Layer Protocolsの認可」、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.、Mather、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、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年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 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、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 Refrend Overhead Recotion Extensions」、RFC 2961、2001年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 3521、2003年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 4080、2005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig、H。およびD. Kroeselberg、「シグナリングの次のステップ（NSIS）のセキュリティの脅威」、RFC 4081、2005年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] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（NSLP）」、RFC 5973、2010年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サービス品質モデルDiffserv "、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] Mather、J。およびK. Raatikainen、「ワイヤレスアクセスネットワークのマルチメディアアプリケーション向けのローカライズされたQoS管理」、Iasted IMSA、Technical Specification 101 321、p。193-200、2004年8月。
[opwa95] Breslau, L., "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.
[OPWA95] Breslau、L。、「予約施設における2つの問題」、Proc。ACM SIGCOMM '95、ケンブリッジMA、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-auth] 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.、et al。、「コンピューターネットワークの価格設定：研究アジェンダの再構築」、Proc。TPRC 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_req_type、qspec、authorization_info、nslp_objects、filter、feature_in、gist_api_triggers、incoming_interface、outovering_interface）
o sid: SESSION-ID - The NSIS session identifier
o SID：SESSION -ID -NSISセッション識別子
o nslp_req_type: indicates type of request:
o nslp_req_type：リクエストのタイプを示します。
* RESERVE
* 予約
* QUERY
* クエリ
* RESPONSE
* 応答
* NOTIFY
* 通知します
o qspec: the QSPEC object, if present
o QSPEC：存在する場合はQSPECオブジェクト
o authorization_info: the AUTH_SESSION object, if present
o authorization_info：auth_sessionオブジェクト（存在する場合）
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_objects：受信したqos-nslpオブジェクトを含むリストを含むデータ構造。このリストは、地元のアプリケーション、ネットワーク管理、またはポリシー制御モジュールなどで使用できます。
* RII
* rii
* RSN
* RSN
* BOUND-SESSION-ID list
* BoundSession-IDリスト
* REFRESH-PERIOD
* リフレッシュ期間
* SESSION-ID-LIST
* SESSION-IDリスト
* RSN-LIST
* RSNリスト
* INFO-SPEC
* 情報スペック
* MSG-ID
* msg-id
* BOUND-MSG-ID
* Bound-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 feature_in：受信したqos-nslpメッセージの共通ヘッダーに含まれるフラグを表しますが、追加のトリガー：
* BREAK
* 壊す
* REQUEST REDUCED REFRESHES
*
* RESERVE-INIT
* リザーブイン
* TEAR
* 破れ目
* REPLACE
* 交換
* ACK-REQ
* 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:
* synchronization_required：この属性は設定されています（たとえば、セクション4.6およびセクション4.7.1を参照）qsne egressでサポートされているqos-nslp機能が、msg-idまたはbound-msg-を含む非引換リザーブメッセージを受信した場合です。IDオブジェクト、およびBoundSession-IDオブジェクトのBinding_Code値は、次の値のいずれかに等しくなります。
+ 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_TRIGGERS：GIST APIを介してQOS-NSLPにGISTによって提供される属性を表します。
+ NSLPID
+ nslpid
+ Routing-State-Check
+ ルーティングステートチェック
+ SII-Handle
+ SIIハンドル
+ Transfer-Attributes
+ 転送属性
+ GIST-Hop-Count
+ Gist-Hop-Count
+ IP-TTL
+ ip-ttl
+ IP-Distance
+ IP-Distance
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 incoming_interface：着信インターフェイスの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 Outving_interface：発信インターフェイスの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がQOS-NSLP関数からAPIを介して要求を受信した場合、1つ以上の「recvrmf（）」応答プリミティブをAPIを介してQoS-NSLPに送信できることに注意してください。このように、QOS-NSLPは、たとえば、1つのエンドツーエンドリザーブの到着が2つの（またはそれ以上の）予備メッセージの生成をトリガーするという状況で、1つ以上の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_resp_type、qspec、authorization_info、status、nslp_objects、filter、feature_out、gist_api_triggers incoming_interface、outovering_interface）
o sid: SESSION-ID - The NSIS session identifier o nslp_resp_type: indicates type of response:
o SID：SESSION -ID -NSISセッション識別子O NSLP_RESP_TYPE：応答のタイプを示します。
* RESERVE
* 予約
* QUERY
* クエリ
* RESPONSE
* 応答
* NOTIFY
* 通知します
o qspec: the QSPEC object, if present
o QSPEC：存在する場合はQSPECオブジェクト
o authorization_info: the AUTHO_SESSION object, if present
o authorization_info：autho_sessionオブジェクト（存在する場合）
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が情報スペックオブジェクトに含めるために使用できるブール値：
* RESERVATION_SUCCESSFUL
* RESERANTION_SUCCESSFUL
* TEAR_DOWN_SUCCESSFUL
* Teal_down_successful
* NO RESOURCES
* リソースはありません
* RESERVATION_FAILURE
* RESERANTION_FAILURE
* RESERVATION_PREEMPTED: reservation was preempted
* Reservation_Preempted：予約が先制されました
* AUTHORIZATION_FAILED: authorizing the request failed
* authorization_failed：リクエストの承認は失敗しました
* MALFORMED_QSPEC: request failed due to malformed qspec
* MALFORMED_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)
* Synchronization_failed：エンドツーエンドの予備とドメイン内保護区との間の不一致の同期（セクション4.6およびセクション4.7.1を参照）
* CONGESTION_SITUATION: Possible congestion situation occurred on downstream path
* 混雑_Situation：下流のパスで渋滞の可能性が発生しました
* 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_objects：qsniがqni、qnr、qni_ingress、qnr_ingress、qni_egress、またはqnr_egressである場合、qos-nslpが使用できるqos-nslpオブジェクトを含むリストを含むデータ構造：
* RII
* rii
* RSN
* RSN
* BOUND-SESSION-ID list
* BoundSession-IDリスト
* REFRESH-PERIOD
* リフレッシュ期間
* SESSION-ID-LIST
* SESSION-IDリスト
* RSN-LIST
* RSNリスト
* MSG-ID
* msg-id
* BOUND-MSG-ID
* Bound-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 feature_out：（とりわけ）新しく生成されたqos-nslpメッセージにqos-nslpが使用できるフラグを表します。
* BREAK
* 壊す
* REQUEST REDUCED REFRESHES
* 削減されたリフレッシュを要求します
* RESERVE-INIT
* リザーブイン
* TEAR
* 破れ目
* REPLACE
* 交換
* ACK-REQ
* 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_ingress、qnr_ingress、qni_egress、またはqnr_egressによってのみ設定できます。qni_ingress、qnr_ingress、qni_egress、またはqnr_egressによってのみ設定できます。
* 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（） - バインディングが必要な場合、BoundSession-IDリストが含まれます。それ以外の場合は、空です。次のQNEタイプでのみ要求できます：qni、qnr、qni_ingress、qnr_ingress、qni_egress、またはqnr_egress。
* 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_INGRESS、QNI_EGRESS、QNR_INGRESS、またはQNR_EGRESSによって要求できます。
* 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_TRIGGERS：GIST APIを介してQOS-NSLPを介してGISTに提供される属性を表します。
* NSLPID
* nslpid
* SII-Handle
* SIIハンドル
* Transfer-Attributes
* 転送属性
* GIST-Hop-Count
* Gist-Hop-Count
* IP-TTL
* ip-ttl
* ROUTING-STATE-CHECK (if set, it requires that GIST create a routing state)
* ルーティングステートチェック（設定されている場合、GISTがルーティング状態を作成する必要があります）
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 incoming_interface：着信インターフェイスの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 Outving_interface：発信インターフェイスの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 config（sid、qne_type、state_type、bypassing_type）
o sid: SESSION-ID - The NSIS session identifier o qne_type: it defines the type of a QNE
o SID：SESSION -ID -NSISセッション識別子O QNE_TYPE：QNEのタイプを定義します
* QNI
* Qni
* QNI_Ingress: the QNE is a QNI and an Ingress QNE
* qni_ingress：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ですが、QNHとQNEではありません
* QNI_Egress: the QNE is a QNI and an Egress QNE
* qni_egress：qneはqniと出口qneです
* QNR
* QNR
* QNR_Ingress: the QNE is a QNR and an Ingress QNE
* QNR_INGRESS：QNEはQNRと侵入QNEです
* QNR_Egress: the QNE is a QNR and an Egress QNE
* QNR_EGRESS：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 bypassing_type：qneがエンドツーエンドのメッセージをバイパスするかどうかを定義します
AAA: Authentication, Authorization, and Accounting
AAA：認証、承認、および会計
EAP: Extensible Authentication Protocol
EAP：拡張可能な認証プロトコル
MRI: Message Routing Information (see [RFC5971])
MRI：メッセージルーティング情報（[RFC5971]を参照）
NAT: Network Address Translator
NAT：ネットワークアドレス翻訳者
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
OSP：オープン決済プロトコル
PIN: Policy-Ignorant Node QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)
PIN：ポリシーイノラントノード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：セッションの予約要求を発行するQNESのシーケンスの最初のノード（セクション22を参照）
QNR: the last node in the sequence of QNEs that receives a reservation request for a session (see Section 22)
QNR：セッションの予約リクエストを受信するQNESのシーケンスの最後のノード（セクション22を参照）
QSPEC: Quality-of-Service Specification
QSPEC：サービス品質仕様
RII: Request Identification Information
RII：識別情報を要求します
RMD: Resource Management for Diffserv
RMD：diffservのリソース管理
RMF: Resource Management Function
RMF：リソース管理機能
RSN: Reservation Sequence Number
RSN：予約シーケンス番号
RSVP: Resource Reservation Protocol (see [RFC2205])
RSVP：リソース予約プロトコル（[RFC2205]を参照）
SII: Source Identification Information
SII：ソース識別情報
SIP: Session Initiation Protocol
SIP：セッション開始プロトコル
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
Jukka Mather Aalto University of Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland
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
Georgios Karagiannis Of Twente/Ericsson P.O.Box 217 Enschede 7500 AEオランダ
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