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
サービス品質（QoS）シグナリングのための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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5974.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5974で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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（Quality of Service）を以下 "QoSのNSLP" と呼ばれるNSISシグナリング層プロトコル（NSLP）を定義しています。このプロトコルは、確立し、そのフローのためにいくつかの転送リソースを提供する目的のためのデータフローのパスに沿ったノードの状態を維持します。 RFC 3726 [RFC3726]のQoS関連の要件を満たすことを目的としています。このQoS NSLPは構造NSISフレームワーク[RFC4080]に概説されているシグナリングプロトコルの大きなスイートの一部です。抽象NTLPは具体的なプロトコル、GIST（一般のインターネットシグナリング交通）[RFC5971]に開発されました。 QoSのNSLPは、メッセージ配信のシグナリングの多くの側面を実行するためにGISTに依存しています。
The design of the QoS NSLP is conceptually similar to RSVP [RFC2205] and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726], in particular, support of sender- or receiver-initiated reservations, as well as a type of bidirectional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.
QoS NSLPの設計は、[RFC2205] RSVPに概念的に類似しており、一次状態管理機構としてソフトステートピア・ツー・ピア・リフレッシュ・メッセージを使用して（すなわち、状態のインストール/更新は、隣接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：NSISエンティティ（NE）、QoSのNSLPをサポートしています。
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、PROXYスコープのフラグを設定してメッセージに返信するように設定されたノード。
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間の関連付けを定義します。中間経路上QNEs、QNI、及びQNRはアソシエーションのために保存された状態を指すために同じ識別子を使用します。同じQNIとQNRは、一度にアクティブに複数のセッションを持つことができます。
Session Identification (SESSION-ID, SID): This is a cryptographically random and (probabilistically) globally unique identifier of the application-layer session that is associated with a certain flow. Often, there will only be one data flow for a given session, but in mobility/multihoming scenarios, there may be more than one, and they may be differently routed [RFC4080].
セッションの識別（セッション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.
ソースまたはメッセージソース：シグナリングメッセージ（おそらく上流または下流ピア）に送信された隣接する二つの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.
アドミッション制御、パケットスケジューリング、および簡単な承認を超えポリシー制御のいずれかの部分がタイプとQoSのレベルのための具体的な定義を使用して実装する必要があります。重要な仮定は、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.
RESERVE：RESERVEメッセージは、QoS NSLPの予約状態を操作するだけのメッセージです。作成更新し、変更、およびこのような状態を削除するために使用されます。 RESERVEメッセージの結果、メッセージが一回または多数回受信されているかどうかと同じです。
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.
QUERY：QUERYメッセージは、予約を行うことなく、データ経路に関する情報を要求するために使用されます。この機能は、予約をするために、または特定のQoSモデルをサポートするために使用することができます。クエリから得られた情報は、QNEのアドミッション制御プロセス（例えば、測定ベースのアドミッション制御の場合）に使用することができます。 QUERYは、既存の予約状態を変更しないことに注意してください。
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は、要求された情報を提供することができない場合、または応答が否定的である場合、これは、明示的なRESERVEメッセージでシグナリング状態操作の確認、およびクエリメッセージに対する応答、またはエラーコードを含みます。応答メッセージは、任意の予約状態がインストールまたは変更されることはありません。
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.
NOTIFY：NOTIFYメッセージがQNEに情報を伝えるために使用されています。彼らは非同期で送信され、任意の特定の状態または以前に受信したメッセージを参照していない必要があるという点で、応答メッセージとは異なります。 NOTIFYメッセージによって伝えられる情報は、典型的には、エラー状態に関連しています。予約がプリエンプトされたときの実施例は、解体された状態についての上流のピアに通知または通知であろう。
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仕様（QSPECs）：QSPECオブジェクトが必要と使用されているQoSモデルに依存している実際のリソースを記述する。任意のリソース記述に加えて、それらはまた、RMFの処理で使用される他の制御情報を含んでいてもよいです。
3. Policy objects: Policy objects contain data used to authorize the reservation of resources.
3.ポリシーオブジェクト：ポリシーオブジェクトリソースの予約を許可するために使用されるデータが含まれています。
Object formats are defined in Section 5.1.3. Object processing rules are defined in Section 5.3.
オブジェクトフォーマットは、5.1.3項で定義されています。オブジェクトの処理ルールは、セクション5.3で定義されています。
The QoS NSLP provides flexibility over the exact patterns of signaling messages that are exchanged. The decoupling of QoS NSLP and QSPEC allows the QoS NSLP to be ignorant about the ways in which traffic, resources, etc., are described, and it can treat the QSPEC as an opaque object. Various QoS models can be designed, and these do not affect the specification of the QoS NSLP protocol. Only the RMF specific to a given QoS model will need to interpret the QSPEC. The Resource Management Function (RMF) reserves resources for each flow.
QoSのNSLPが交換されているシグナリングメッセージの正確なパターン上の柔軟性を提供します。 QoSのNSLPとQSPECのデカップリングは、QoS NSLPは、トラフィックが、その他のリソースは、記述された方法についての無知にすることができます、そしてそれは、不透明なオブジェクトとしてQSPECを扱うことができます。様々なQoSのモデルが設計することができ、そしてこれらは、QoS NSLPプロトコルの仕様には影響を与えません。のみ与えられたQoSモデルにRMFの特定はQSPECを解釈する必要があります。リソース管理機能（RMF）は、各フローのためのリソースを予約します。
The QSPEC fulfills a similar purpose to the TSpec, RSpec, and AdSpec objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC 2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted by the Resource Management Function and the Policy Control Function for the purposes of traffic and policy control (including admission control and configuration of the packet classifier and scheduler).
QSPECは、RSVPとRFC 2205で指定された[RFC2205]及びRFC 2210 [RFC2210]で使用TSpecの、RSpecの、およびADSPECオブジェクトと同様の目的を果たします。各QNEで、QSPECの内容は、（パケット分類器とスケジューラのアドミッション制御および構成を含む）トラフィックおよびポリシー制御のためにリソース管理機能とポリシー制御機能によって解釈されます。
The QoS NSLP does not mandate any particular behavior for the RMF, instead providing interoperability at the signaling-protocol level whilst leaving the validation of RMF behavior to contracts external to the protocol itself. The RMF may make use of various elements from the QoS NSLP message, not only the QSPEC object.
QoSのNSLPではなく、プロトコル自体に外部の契約にRMFの挙動の検証を残しながら、シグナリング・プロトコルレベルでの相互運用性を提供し、RMFのための特定の動作を強制しません。 RMFは、QoS NSLPメッセージから様々な要素だけでなく、QSPECオブジェクトを利用することができます。
Still, this specification assumes that resource sharing is possible between flows with the same SESSION-ID that originate from the same QNI or between flows with a different SESSION-ID that are related through the BOUND-SESSION-ID object. For flows with the same SESSION-ID, resource sharing is only applicable when the existing reservation is not just replaced (which is indicated by the REPLACE flag in the common header). We assume that the QoS model supports resource sharing between flows. A QoS Model may elect to implement a more general behavior of supporting relative operations on existing reservations, such as ADDING or SUBTRACTING a certain amount of resources from the current reservation. A QoS Model may also elect to allow resource sharing more generally, e.g., between all flows with the same Differentiated Service Code Point (DSCP).
依然として、本明細書では、リソースの共有は同じQNI起源同じセッションIDを持つ又はBOUND-SESSION-IDオブジェクトを介して関連している異なったセッションIDとフローとの間の流れの間に可能であることを前提としています。同じセッションIDとフローに対して、リソース共有は、（共通ヘッダにREPLACEフラグで示される）は、既存の予約だけ交換されていない場合にのみ適用可能です。私たちは、QoSモデルは、フロー間のリソース共有をサポートしていることを前提としています。 QoSのモデルは、現在の予約のリソースの一定量を加算または減算などの既存の予約、上の相対動作をサポートする、より一般的な動作を実装することを選択することができます。 QoSのモデルは、すべてが同じ差別化サービスコードポイント（DSCP）で流れる間、より一般的には例えば、リソースの共有を可能にするように選択することができます。
The QSPEC carries a collection of objects that can describe QoS specifications in a number of different ways. A generic template is defined in [RFC5975] and contains object formats for generally useful elements of the QoS description, which is designed to ensure interoperability when using the basic set of objects. A QSPEC describing the resources requested will usually contain objects that need to be understood by all implementations, and it can also be enhanced with additional objects specific to a QoS model to provide a more exact definition to the RMF, which may be better able to use its specific resource management mechanisms (which may, e.g., be link specific) as a result.
QSPECは、いくつかの異なる方法でQoS仕様を記述できるオブジェクトのコレクションを運びます。汎用テンプレートは、[RFC5975]で定義されたオブジェクトの基本的なセットを使用する場合の相互運用性を保証するために設計されたQoS記述の一般的に有用な要素、対象フォーマットを含んでいます。 QSPECは通常、すべての実装によって理解する必要のあるオブジェクトが含まれています要求されたリソースを記述し、また、使用する方ができるかもしれRMFへのより正確な定義を、提供するために、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の動作を定義し、どのようにQSPEC情報は、利用可能なリソースを記述するために使用され、必要なリソース、トラフィックの説明、およびRMFが必要とする情報を制御します。 QoSのモデルも、このQoSモデルについては、シグナリング時にQNEsがQSPECに使用すべきパラメータの最小セットを記述する。
QoS Models may be local (private to one network), implementation/ vendor specific, or global (implementable by different networks and vendors). All QSPECs should follow the design of the QSPEC template.
QoSのモデルは、（一つのネットワークにプライベート）、実装/ベンダ固有、またはグローバル（異なるネットワークやベンダーによって実装可能）局所的であってもよいです。すべてのQSPECsは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が実装に自由を与える領域に実装する方法ローカル行動に影響する可能性があり。例えば、転送RESERVEメッセージが受信された1つ、又は追加のシグナリングセッションは、集約の予約のために必要に応じて、既存のセッションに基づいて開始されるべきときのためにどのように関連するかの推奨行動を識別するのに有用であり得ます。いくつかのケースでは、提案は、必要に応じて保持することができる状態は、特定のシナリオに保持されるべきかどうかで行われてもよいです。 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へのアクセスでは、例えば、ネットワークアクセスへのアクセスを取得、一般的にポリシー制御のいくつかの種類を必要とします。この一例は、リソース要求者の承認です。図3に、以下に示すようなQoS NSLPリソース予約シグナリングのためのポリシー制御は、概念的に編成されます。
+-------------+
| Policy |
| Decision |
| Point (PDP) |
+------+------+
|
/-\-----+-----/\
//// \\\\
|| ||
| Policy transport |
|| ||
\\\\ ////
\-------+------/
|
+-------------+ QoS signaling +------+------+
| Entity |<==============>| QNE = Policy|<=========>
| requesting | Data Flow | Enforcement |
| resource |----------------|-Point (PEP)-|---------->
+-------------+ +-------------+
Figure 3: Policy Control with the QoS NSLP Signaling
図3：ポリシー制御のQoS NSLPシグナリングと
From the QoS NSLP point of view, the policy control model is essentially a two-party model between neighboring QNEs. The actual policy decision may depend on the involvement of a third entity (the Policy Decision Point, PDP), but this happens outside of the QoS NSLP protocol by means of existing policy infrastructure (Common Open Policy Service (COPS), Diameter, etc.). The policy control model for the entire end-to-end chain of QNEs is therefore one of transitivity, where each of the QNEs exchanges policy information with its QoS NSLP policy peer.
ビューのQoSのNSLPの観点から、ポリシー制御モデルは、基本的に、隣接QNEs間の二者モデルです。実際の政策決定は、第3のエンティティ（ポリシー決定ポイント、PDP）の関与に依存してもよいが、これは既存のポリシーインフラストラクチャ（一般的なオープンポリシーサービス（COPS）、直径などによってQoSのNSLPプロトコルの外で起こります）。 QNEsの全体エンド・ツー・エンドの鎖のポリシー制御モデルは、のQoS NSLPポリシーピアとQNEs交換ポリシー情報の場合それぞれ、従って推移の一つです。
The authorization of a resource request often depends on the identity of the entity making the request. Authentication may be required. The GIST channel security mechanisms provide one way of authenticating the QoS NSLP peer that sent the request, and so may be used in making the authorization decision.
リソース要求の承認は、多くの場合、要求を行うエンティティのアイデンティティに依存します。認証が必要な場合があります。 GISTチャネルセキュリティメカニズムは、要求を送信したQoS NSLPピアを認証する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での予約状態を定期的にリフレッシュしなければならないことを意味しています。状態のインストールが更新される頻度は、リフレッシュ周期オブジェクトで表現されます。このオブジェクトはの合図をしている状態が有効なままどのくらいを示す値をミリ秒単位で含まれています。この存続期間を超えて予約を維持することは、定期的にRESERVEメッセージを送信することにより行うことができます。
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は、送信者が開始すると受信が開始した予約の両方をサポートしています。送信者によって開始予約のために、RESERVEメッセージは、（QNIデータフローのソース側にある）の合図されているデータの流れと同じ方向に移動します。受信機が開始した予約のために、RESERVEメッセージは反対方向に移動する（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.
RESERVEメッセージは、インストールされた予約状態に影響を与えます。 QUERY、応答メッセージ、RESERVEメッセージは影響をQNEで保存される最終的な予約状態を受信された順序、NOTIFYは異なり;つまり、最新のRESERVEメッセージは、現在の予約を置き換えます。したがって、RESERVEメッセージの再順序付けや複製から保護するために、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は、リフレッシュRESERVEメッセージの省略形をサポートしています。この場合、リフレッシュRESERVEはRSNとセッションIDを使用して、予約を参照し、（QSPEC含む）完全予約指定を含んでいません。デフォルトでは、状態の更新は、送信中のバイトを節約するために減少したリフレッシュを実行する必要があります。彼らは全体の予約情報を格納しないため、ステートレス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は、エラーを示すINFO-SPECを担持するRESPONSEで応答しなければなりません。さらに、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は、要約リフレッシュと要約涙のメッセージをサポートしています。特定の（プライマリ）セッションのリフレッシュRESERVEを送信するとき、QNEはQNEもリフレッシュされる（二次）セッションを示すセッションIDリストオブジェクトを含むことができます。 RSN-LISTオブジェクトも追加する必要があります。セッションIDととれたRSNが同じセッションを指す両方のスタックのインデックスは両方のオブジェクトのインデックスiにおける同一の予約状態、すなわち、セッションID及びRSNを参照するように、オブジェクトに積層されています。受信ステートフルQNEが不明SESSION-IDやセッションのとれたRSNとの不一致に気付いた場合、それはエラーで上流ステートフルQNEに返信します。
In order to tear down several sessions at once, a QNE may include SESSION-ID-LIST and RSN-LIST objects in a tearing reserve. The downstream stateful QNE must then also tear down the other sessions indicated. The downstream stateful QNE must silently ignore any unknown SESSION-IDs.
一度に複数のセッションを切断するために、QNEは、引裂リザーブにセッションID-LISTおよびRSN-LISTオブジェクトを含むことができます。下流ステートフルQNEはその後も示された他のセッションを切断しなければなりません。下流ステートフルQNEは静かに未知SESSION-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].
RESERVEまたはQUERYメッセージの二スコープフラグは状態が応答することができ、下流のノードにインストールされている経路の一部を制限します。スコープフラグがゼロに設定されている場合は、範囲は「全経路」（デフォルト）であることを示しています。 1に設定すると、範囲は「単一ホップ」です。 PROXY範囲フラグが設定されている場合、パスは、事前に定義されたプロキシ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.
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で定義されるように、異なるセッションのID（SID）を[RFC5971]を有する、すなわち、シグナリングフロー）として定義される結合します。
Session binding indicates a unidirectional dependency relation between two or more sessions by including a BOUND-SESSION-ID object. A session with SID_A (the binding session) can express its unidirectional dependency relation to another session with SID_B (the bound session) by including a BOUND-SESSION-ID object containing SID_B in its messages.
セッション結合は、結合-SESSION-IDのオブジェクトを含むことにより、2つの以上のセッションの間に一方向の依存関係を示しています。 SID_A（結合セッション）とのセッションは、そのメッセージにBOUND-SESSION-IDのオブジェクトを含むSID_Bを含めることによって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.
メッセージは、複数のBOUND-SESSION-IDのオブジェクトを含むことができます。これは、エンドツーエンドのセッション集約セッションとの一方向の依存関係を有すると同時に、それは逆の経路に使用される他のセッションとの一方向の依存関係を有し、特定の凝集および双方向予約のシナリオにおいて、例えば、起こり得ます。
QoS NSLP supports binding of messages in order to allow for expressing dependencies between different messages. The message binding can indicate either a unidirectional or bidirectional dependency relation between two messages by including the MSG-ID object in one message ("binding message") and the BOUND-MSG-ID object in the other message ("bound message"). The unidirectional dependency means that only RESERVE messages are bound to each other whereas a bidirectional dependency means that there is also a dependency for the related RESPONSE messages. The message binding can be used to speed up signaling by starting two signaling exchanges simultaneously that are synchronized later by using message IDs.
QoSのNSLPは異なるメッセージ間の依存関係を表現できるようにするために、メッセージの結合をサポートしています。バインディングメッセージは、一つのメッセージ（「バインディングメッセージ」）および他のメッセージ（「バウンドメッセージ」）で結合した-MSG-IDのオブジェクトにMSG-IDのオブジェクトを含めることによって二つのメッセージの間で単方向または双方向の依存関係のいずれかを示すことができます。一方向依存双方向依存性はまた、関連する応答メッセージの依存関係があることを意味し、一方のみRESERVEメッセージは互いに結合していることを意味します。バインディングメッセージは、メッセージ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モデルを実装する場合に発生やよい彼らは局所的に、特定の輸送特性を適用する場合（例えば、GIST信頼できない転送モードの代わりに信頼できる転送モード）。いくつかのフロー毎の予約がローカル集計予約に結合されるときにも起こり得ます。
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に解釈されます。エンドツーエンドのセッションが中間ノードをバイパスすることができなければならない、と出口QNEは一緒に、両方のセッションをバインドする必要があります。この溶液は、二つの要件を課します。中間ノードをバイパスするGISTを用いて達成されます。ローカルセッションとのエンドツーエンドセッションが結合-SESSION-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に記載の階層化アプローチと本質的な差は、集合予約（Diffservの上のIntServの場合には、例えば、DSCP）総計で運ばれるすべてのトラフィックを記述するMRIを必要とすることです。セクション3.2.10.2およびRFC 3175でRSVP集約溶液に[RFC3175]に記載されているように、異なるMRIの必要性は、二つの異なるセッションの使用を義務付け。
Edge QNEs of the aggregation domain that want to maintain some end-to-end properties may establish a peering relation by sending the end-to-end message transparently over the domain (using the intermediate node bypass capability described above). Updating the end-to-end properties in this message may require some knowledge of the aggregated session (e.g., for updating delay values). For this purpose, the end-to-end session contains a BOUND-SESSION-ID carrying the SESSION-ID of the aggregate session.
（上記中間ノードバイパス機能を使用して）ドメイン上に透過的エンドツーエンドのメッセージを送信することによって、ピアリング関係を確立することができるいくつかのエンド・ツー・エンドの特性を維持する凝集ドメインのエッジQNEs。このメッセージ内のエンドツーエンドのプロパティを更新する（例えば、遅延値を更新するための）集約セッションのいくつかの知識を必要とし得ます。この目的のために、エンドツーエンドのセッションは、集約セッションのセッション-IDを運ぶBOUND-SESSION-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からNetworkNotification通ってくる、またはNSLPで見られた情報からすることができます。後者の場合には、QoSのNSLPノードは、RFC 2205に記載さRSVP_HOPオブジェクト[RFC2205]と本質的に同様の情報を提供するソース識別情報（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.
RESERVEメッセージは、古いものと新しいパスが分岐点を越えてQNEに到着したときに新しいパスの予約が起こります。 QoSのNSLPは、リルートが発生したことを疑う場合は、（QSPECを含む）をフルRESERVEメッセージが送信されます。 （なしQSPEC付き）さわやかRESERVEは予約がインストールされていない新しいパス上のQNE、によりエラーとして識別されます（つまり、それは古いパスではなかった）、または以前に別の以前のホップQNEを持っていました。これは、完全なRESERVEメッセージが送信され、その結果、エラーメッセージを返送します。 NSLP層での急速な回復は、したがって、短いリフレッシュ期間を必要とします。次のRESERVEメッセージが到着する前に検出がIP層で、または例えば、すなわち（TTL）を、生存時間を監視することにより、GISTピアリング関係（の監視を通じてのみ可能である、GISTの数はNSLPピア間のホップ、またはの変化を観察しますGISTピアに向かって発信インターフェイス）。これらのメカニズムは、実装固有の最適化を提供し、この仕様の範囲外であることができます。
When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by sending a new RESERVE message. If the next QNE is in fact unchanged, then this will be used to refresh/update the existing reservation. Otherwise, it will lead to the reservation being installed on the new path.
QoSのNSLPは、ルート変更を認識している場合は、新しいパスに予約を設定する必要があります。これは、新しいRESERVEメッセージを送信することにより行われます。次の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.
受信器で開始予約セッションの動作は上記の説明から少し異なることに留意されたいです。もしある時点でパスの途中でルーティングの変更（すなわち、分岐点）その下流経路は（GISTからNetworkNotificationで示す）変更された、そしてそれはR-でクエリを送信しなければならないことに気付くQNEフラグ下流。クエリは、上記のように処理し、ある時点で下流QNIままである（すなわち、収束点）に向かってパスのQNEに衝突します。このノードは、新しいパスに沿って予約状態を設定するために、上流フルRESERVEを送信する必要があります。これが本当の使用を持っていないだろうので、それは、さらに下流QUERYを送るべきではありません。クエリを送信QNEがRESERVEを受信した場合同様に、それはさらに上流RESERVEを送るべきではありません。
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-ハンドルを使用して引き裂きRESERVEを送信することができます。古いパスが上流にある場合、QNEは「ルート変更」のコードでNOTIFYを送信することができます。それが下流の引き裂きRESERVEを発行することができます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またはブランチノードは、古い枝に予約を維持することを望むかもしれません。例えば、これは、モバイルノードがモビリティイベントを経験し、それが戻って移動した場合にはその古い接続ポイントに予約を維持することを希望している場合である可能性があります。この目的のために、REPLACEフラグがセットされていないと、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.
新しい下流のピアが存在するか、または切り捨てが発生したことを検出する際の待ち時間は、GISTに依存します。デフォルトのQUERYメッセージの送信間隔は30秒です。 NSLPsが新しいピアまたは再ルーティングの発見に影響を与えることができます方法についての詳細は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.
ケース（1）とQNEは、それがシグナル伝達を終了すべきことを知っているので、（2）、最初のパス設定時のQoS NSLP自体によって処理することができます。ケース（3）のQoS NSLPをサポートさらなるGISTノードが下流に存在しない、および下流の経路変更のプロービングする予約は、任意を検出するために設置されると継続する必要があることを示すために、GISTからいくつかの援助を必要とするAPIを横切ってメッセージを提供しますこのような状況の変化。
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.
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.
再ルーティングが発生すると、データパスは-C-Dに-B-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.
第二の場合には、「パス切り捨て」と呼ばれる、再ルーティングは、シグナリング経路の最後のノードであった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.
再ルーティングが発生すると、データパスは再度-C-Dに-B-Dから変化します。シグナル伝達経路は、最初にBで終了するが、このノードは、新しいパス上にはありません。この場合、Aにおける通常GIST経路変化検出手順は、経路変更を検出し、QoS NSLPを通知します。 GISTものQoS NSLPをサポートなし下流GISTノードが存在しないシグナリングアプリケーションに通知します。ノードAは、シグナリングパス上の最後のノードとして引き継ぎます。
The QoS NSLP is notified by GIST (with the NetworkNotification primitive) when GIST believes that a rerouting event may have occurred. In some cases, events that are detected as possible route changes will turn out not to be. The QoS NSLP will not always be able to detect this, even after receiving messages from the 'new' peer.
GISTは、再ルーティングイベントが発生した可能性があると考えていたときのQoS NSLPは（プリミティブNetworkNotification付き）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プリミティブ、GISTの一部として特定のピアにシグナリングメッセージを指示するためにNSLPによって使用することができるSIIハンドルを提供します。シグナリング・ピア・変更された場合、現在のSII-ハンドルが変更されます。しかし、ピアは変更されません再ルーティングイベントの後に同じままに保証するものではありません。このため、経路変更後の予約メンテナンスのためのQoS NSLP機構は、ピアQNEはGISTから「ルート変更」の通知後に同じままである状況で予約を切断誤っ回避する堅牢性メカニズムを含みます。
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をサポートしていないので、それは、両方の場合において-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はNetworkNotificationとNSLPに、そのAPIを横切ってシグナリングすることができます。 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（必要に応じて新たな次のピアを発見）に輸送するRESERVEメッセージを送信します。 RESERVEもQNRからの応答を要求します。このRESERVEメッセージが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.
RESPONSEメッセージはQNRにより送信され、この予約は、新しいパスにインストールされたことを確認A.にCから転送されます。 SIIは、ハンドルAで使用されているインタフェースが変更されているので、GISTからのQoS NSLPにRecvMessageコールは、以前に見られたものとは異なるであろうと渡されます。
At this point, A can attempt to tear down the reservation on the old path. The RESERVE message with the TEAR flag set is sent down the old path by using the GIST explicit routing mechanism and specifying the SII-Handle relating to the 'old' peer QNE.
この時点で、Aは、古いパスの予約を取り壊すことを試みることができます。 TEARフラグが設定されたRESERVEメッセージは、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これらRESERVEとRESERVE-WITH-TEARメッセージのそれぞれについてインクリメントされていた場合、予約はCで解体し、経路に沿ってさらに任意QNEsされるであろう。これを避けるために、RSNは特別な方法で使用されています。新しいパスダウンRESERVEが古いRSNプラス2への新たな現在のRSNセットで送信されRESERVE-と-TEAR古いパスダウンが新しい現在のRSNこのマイナス1に設定RSNに送られからピアでありますそれはRESERVEメッセージを受信している（詳細はを参照）。
The QoS NSLP provides building blocks to implement preemption. This specification does not define how preemption should work, but only provides signaling mechanisms that can be used by QoS models. For example, an INFO-SPEC object can be added to messages to indicate that the signaled session was preempted. A BOUND-SESSION-ID object can carry the Session ID of the flow that caused the preemption of the signaled session. How these are used by QoS models is out of scope of the QoS NSLP specification.
QoSのNSLPは、プリエンプションを実装するためのビルディングブロックを提供します。この仕様は、プリエンプションがどのように動作するかを定義しますが、唯一のQoSモデルで使用可能なシグナル伝達機構を提供しません。例えば、INFO-SPECオブジェクトがシグナリングセッションがプリエンプトされたことを示すために、メッセージに追加することができます。 BOUND-SESSION-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を使用しています。メッセージは、シグナリングアプリケーション（例えば、「のQoS NSLP」）、セッション識別子、MRIのための識別子を含む、付加的な情報を特定する、（[RFC5971]の付録Bで定義された）APIを介して、GISTにNSLPから渡され、そして意図した方向の指示（データ送信側または受信側に向かって）。レセプションでは、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）によって識別されます。セッション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を検討します。ただし、拡張子はのMRMの他のタイプは、QoS NSLPと組み合わせて適用することができる方法を指定することもできます。
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は、処理のためにNSLPにQoS 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は、特定のノードへのメッセージの処理を制限することができます。この機能は、積層サポートするために必要とされる（セクション3.2.10で説明する）、場合ドメインプロセスメッセージの唯一のエッジQNEs。これは、ドメインのエッジ間の中間ノードをバイパスする（のQoS NSLPによって呼び出すことができる）GISTレベルのメカニズムを必要とします。
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.
中間ノードは、ルータ警戒オプションの複数のレベルを使用してバイパスされます。その場合、内部ルータは、ルータアラートのみ特定のレベルを処理するように構成されています。これは、すなわち、入口でこのメッセージをマーキングNSLPID所定の値へのQoS NSLPデフォルトNSLPID値を変更することによって達成される（セクション6.6参照）。出力は、元のRESERVEメッセージに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で参照RESERVEを受信すると、その上流ピアが変更されたことを知ります。これは、パスの古い部分に沿ってティアダウンを開始するために、古いSIIを使用することができます。 （メッセージの受信に格納されている）ピアのSIIは、メッセージ送信時GISTに渡されたとき、この機能は、GISTサービス・インターフェースでサポートされています。
Stateless or reduced-state QoS NSLP operation makes the most sense when some nodes are able to operate in a stateless way at the GIST level as well. Such nodes should not worry about keeping reverse state, message fragmentation and reassembly (at GIST), congestion control, or security associations. A stateless or reduced-state QNE will be able to inform the underlying GIST of this situation. GIST service interface supports this functionality with the Retain-State attribute in the MessageReceived primitive.
いくつかのノードは、同様GISTレベルでステートレスな方法で動作することができる場合にステートレスまたは低減状態のQoS NSLP操作は、最も理にかなっています。そのようなノードは、逆の状態、（GISTで）メッセージの断片化と再アセンブリ、輻輳制御、またはセキュリティアソシエーションを維持する心配するべきではありません。ステートレスまたは低減状態QNEは、このような状況の根本的なGISTを知らせることができるようになります。 GISTのサービス・インターフェースは、MessageReceivedプリミティブで保持-State属性でこの機能をサポートしています。
The QoS NSLP will generate messages with a range of performance requirements for GIST. These requirements may result from a prioritization at the QoS NSLP (Section 3.2.11) or from the responsiveness expected by certain applications supported by the QoS NSLP. GIST service interface supports this with the 'priority' transfer attribute.
QoSのNSLPはGISTの性能要件の範囲でメッセージを生成します。これらの要件は、QoS NSLP（セクション3.2.11）での優先順位からまたはQoS NSLPによってサポートされる特定のアプリケーションによって期待される応答に起因し得ます。 GISTのサービス・インターフェースは、「優先順位」の転送属性でこれをサポートしています。
In some cases, it is useful to know that there are routers along the path where QoS cannot be provided. The GIST service interface supports this by keeping track of IP-TTL and Original-TTL in the RecvMessage primitive. A difference between the two indicates the number of QoS-NSLP-unaware nodes. In this case, the QNE that detects this difference should set the "B" (BREAK) flag. If a QNE receives a QUERY or RESERVE message with the BREAK flag set, and then generates a QUERY, RESERVE, or RESPONSE message, it can set the BREAK flag in those messages. There are however, situations where the egress QNE in a local domain may have some other means to provide QoS [RFC5975]. For example, in a local domain that is aware of RMD-QOSM [RFC5977] (or a similar QoS Model) and that uses either NTLP stateless nodes or NSIS-unaware nodes, the end-to-end RESERVE or QUERY message bypasses these NTLP stateless or NSIS-unaware nodes. However, the reservation within the local domain can be signaled by the RMD-QOSM (or a similar QoS Model). In such situations, the "B" (BREAK) flag in the end-to-end RESERVE or QUERY message should not be set by the edges of the local domain.
いくつかのケースでは、QoSを提供することができないパスに沿ったルータがあることを知っておくと便利です。 GISTのサービス・インターフェースは、プリミティブRecvMessageにIP-TTLとオリジナル-TTLを追跡することによって、これをサポートしています。両者の違いは、QoS-NSLP非対応ノードの数を示しています。この場合には、この差を検出QNEは「B」（BREAK）フラグを設定しなければなりません。 QNEはBREAKフラグを設定してクエリまたはRESERVEメッセージを受信し、QUERY、RESERVE、または応答メッセージを生成した場合、そのメッセージにBREAKフラグを設定することができます。ローカルドメイン内の出口QNEがQoS [RFC5975]を提供するために、いくつかの他の手段を有していても良い状況では、しかし、があります。例えば、RMD-QOSM [RFC5977]（または同様のQoSモデル）を認識しており、それはNTLPステートレスノードまたはNSIS非対応ノードのいずれかを使用するローカルドメインで、エンド・ツー・エンドのRESERVEまたはクエリメッセージは、これらのNTLPを迂回しますステートレスまたはNSIS非対応ノード。しかし、ローカルドメイン内の予約は、RMD-QOSM（または同様のQoSモデル）によってシグナリングすることができます。そのような状況では、エンドツーエンドRESERVEまたはクエリメッセージ中の「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オブジェクトを含むRESERVEメッセージを構築します。
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.
RESERVEメッセージは次のQNEに搬送GISTに渡されます。そこでは、それがメッセージを調べた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は、次に（通常は受信した1つに基づいて）新しいRESERVEメッセージを生成します。これは、次のQNEに転送GISTに渡されます。
The same processing is performed at further QNEs along the path, up to the QNR. The determination that a node is the QNR may be made directly (e.g., that node is the destination for the data flow), or using GIST functionality to determine that there are no more QNEs between this node and the data flow destination.
同様の処理がQNRまで、パスに沿ってさらにQNEsで行われます。ノードがQNRであることを決意（例えば、そのノードは、データフローの送信先である）直接行うか、またはこのノードとデータフロー先との間に複数QNEsが存在しないことを決定するために、GIST機能を使用することができます。
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.
任意のノードは、そのRESERVEメッセージで応答のための要求を含むことができます。これは、RESERVEメッセージ内の要求識別情報（RII）オブジェクトを含むことによってそうします。メッセージがすでにRIIが含まれている場合は、興味のあるQNEは新しいRIIオブジェクトを追加したり、古いRIIオブジェクトを交換してはなりません。代わりに、それはRESERVEに属する応答メッセージを一致させることができるように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.
この例では、応答メッセージはRESERVEメッセージは（GIST路状態を使用して）取った経路の逆方向に沿ってピア・ツー・ピア転送され、従って経路のこのセグメント上のすべてのQNEsによって見られます。これは、元々の応答を要求されたノード限り転送されます。
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.
予約は、その後、最初の予約のためとして、完全な予約情報を含む更なる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のために提案されたものと同様に、低減することができます。応答メッセージは、予約の正常なインストールを示す受信された後、後続のリフレッシュRESERVEメッセージは、単にむしろ完全予約指定を含むよりも、既存の予約を参照することができます。
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.
QUERYメッセージは、パスに沿っ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はQUERYメッセージを構築します。このメッセージは、経路に沿ってQNEsで実行される実際のクエリを含むQSPECを含みます。また、バッククエリに応答して、クエリスコープ（次のノード、パス全体、プロキシ）の指標を一致させるために使用RIIオブジェクトを含みます。 QUERYメッセージは、パスに沿って、それを転送するために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).
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.
QUERYメッセージはRIIオブジェクトが含まれている場合QNRで、応答メッセージが生成されなければなりません。受信したクエリメッセージから様々なオブジェクトは、応答メッセージにコピーされなければなりません。次いで、これをバック経路に沿って、ピア・ツー・ピアを転送する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.
RESERVEの処理でエラーの代わりに、RIIがあった場合、応答はRSNを有していてもよいです。したがって、QNEはまた全くRIIが存在しない場合にRSNオブジェクトを探すために調製し、応答のINFO-SPECに設定されたエラーコードに基づいて行動しなければなりません。
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]に記載されているように、いくつかのシグナリングアプリケーションでは、データフローの一端のノードは、特別な処理を要求するための責任を負います。両端はその後、センダまたはレシーバが開始した予約が行われるかどうかを同意するものとします。受信機が開始した予約の場合には、両端が一致[opwa95「広告をワンパス」（OPWA）かどうかのモデルが使用されています。このネゴシエーションはNSISの範囲外にあるメカニズムを使用して達成することができます。
To make a receiver-initiated reservation, the QNR constructs a QUERY message, which MUST contain a QSPEC object from its chosen QoS model (see Figure 8). The QUERY must have the RESERVE-INIT flag set. This QUERY message does not need to trigger a RESPONSE message and therefore, the QNI must not include the RII object (Section 5.4.2) in the QUERY message. The QUERY message may be used to gather information along the path, which is carried by the QSPEC object. An example of such information is the "One Pass With Advertising" (OPWA) model [opwa95]. This QUERY message causes GIST reverse-path state to be installed.
受信機が開始し、予約をし、QNRは、その選択されたQoSモデル（図8参照）からQSPECオブジェクトを含まなければなりませんQUERYメッセージを構築します。 QUERYはRESERVE-INITフラグを設定する必要があります。このQUERYメッセージは、応答メッセージをトリガーするため、QNIがQUERYメッセージにRIIオブジェクト（5.4.2）が含まれてはならない必要はありません。 QUERYメッセージはQSPECオブジェクトによって運ばれる経路に沿って情報を収集するために使用することができます。そのような情報の例は、「広告をワンパス」（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.
QUERYメッセージは次のダウンストリームQoS NSLPノードにGISTによって輸送されます。そこでは、それがメッセージを調べた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は、（通常、受信した1つに基づいて）新しいクエリメッセージを生成します。これは、次のQNEに転送GISTに渡されます。同様の処理は、フロー受信機までの経路に沿ってさらにQNEsで行われます。受信機は、このクエリメッセージがRESERVE-INITフラグを担持し、そのようなQSPECとして受信したクエリメッセージに含まれる情報を用いて、RESERVEメッセージを構築することを検出します。
The RESERVE is forwarded peer-to-peer along the reverse of the path that the QUERY message took (using GIST reverse-path state). Similar to the sender-initiated approach, any node may include an RII in its RESERVE messages. The RESPONSE is sent back to confirm that the resources are set up. The reservation can subsequently be refreshed with RESERVE messages in the upstream direction.
RESERVEは、クエリメッセージが（GISTリバースパスの状態を使用して）取った経路の逆方向に沿ってピアツーピア転送されます。送信者が開始したアプローチと同様、任意のノードは、そのRESERVEメッセージにRIIを含むことができます。応答は、リソースが設定されていることを確認するために戻って送信されます。予約は、その後、上流方向にRESERVEメッセージでリフレッシュすることができます。
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).
2つの送信者が開始した予約を結合、O、例えば、1つの送信者によって開始QNE BとQNE A（図9）にQNE Bから別のものへQNE Aからの予約。
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).
逆方向のデータフローの送信者が開始したと受信機が開始した予約一緒に、例えば、QNE Bに向かってQNE Aから送信者によって開始予約、及びQNE Bに向かってQNE Aから受信器で開始予約バインディングO（からQNE AにQNE B）。通信の一端は両方のセッション（図10）を設定するために必要なすべての情報を有する場合この場合は、特に有用です。
Both ends have to agree on which bidirectional reservation type they need to use. This negotiation can be accomplished using mechanisms that are outside the scope of NSIS.
両端は、彼らが使用する必要がある双方向予約タイプに同意する必要があります。このネゴシエーションはNSISの範囲外にあるメカニズムを使用して達成することができます。
The scenario with two sender-initiated reservations is shown in Figure 9. Note that RESERVE messages for both directions may visit different QNEs along the path because of asymmetric routing. Both directions of the flows are bound by inserting the BOUND-SESSION-ID object at the QNI and QNR. RESPONSE messages are optional and not shown in the picture for simplicity.
2送信者によって開始予約とのシナリオは、図中両方向のためのRESERVEメッセージが原因で非対称ルーティングの経路に沿って異なるQNEsを訪問するかもしれない9注示されています。流れの両方向にQNIとQNRで結合-SESSION-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は、二つのRESERVEメッセージは、送信者が開始したと受信機が開始した予約のための1つのための1つを送出します。 2つのRESERVEメッセージのシーケンスをインターリーブすることができることに注意してください。
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.
アグリゲータで、集約フローのための予約が開始される（「RESERVE '」として図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は、エンドツーエンドのセッションのQSPECsから得ることができる方法を指定しません。
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.
具体的には、アグリゲータはNSLPID所定値へのQoS NSLPデフォルトNSLPID値を変更することによってマーキングを行います。 6.6節を参照してください。 RAO値が一意に予め定義されたNSLPIDから導出次にです。ただし、RAOは、特定のNSLPIDへの1対1の関係を持っている必要はありません。
Aggregator 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).
デアグリゲータは、集合予約のためのQNRとして機能します。 RESERVEメッセージで運ばれたセッションバインディング情報は、エンドツーエンド及び（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は、新規予約の包含は最初に増加することが集計包含する容量ことを必要とする場合を示しています。だから、デアグリゲータに到着し、個々のフローのためのRESERVE（バインドメッセージ）は、集約のためにRESERVE」（結合メッセージ）まで待たなければならない（そうでない場合は、個々のフローは、既存の集計に含めることができないと認めすることはできません）が正常に到着しました。別の代替は、凝集個々のフローの集合のためのリソースを予約するために、第1、次いで凝集を増加させるであろう。この場合、結合および（RESERVEとRESERVE '）との間の同期メッセージが必要とされません。
A message binding may be used (depending an the aggregators policy) as follows: a QNE (aggregator QNI' in Figure 14) generates randomly a 128-bit MSG-ID (same rules apply as for generating a SESSION-ID) and includes it as BOUND-MSG-ID object into the bound signaling message (RESERVE (1) in Figure 13) that should wait for the arrival of a related binding signaling message (RESERVE' (3) in Figure 13) that carries the associated MSG-ID object. The BOUND-SESSION-ID should also be set accordingly. Only one MSG-ID or BOUND-MSG-ID object per message is allowed. If the dependency relation between the two messages is bidirectional, then the Message_Binding_Type flag is SET (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In most cases, an RII object must be included in order to get a corresponding RESPONSE back.
次のようにメッセージが（アグリゲータポリシーによって）使用することができる結合（図14の「アグリゲータQNI）QNEは、（同じルールがセッションIDを生成するように適用する）ランダム128ビットMSG-IDを生成し、それを含みます関連MSG-IDを運ぶ関連するバインディングシグナリングメッセージ（図13のRESERVE」（3））の到着を待つ必要があり、結合したシグナリングメッセージ（図13のRESERVE（1））にバインド-MSG-IDオブジェクトとしてオブジェクト。 BOUND-SESSION-IDもそれに応じて設定されるべきです。メッセージごとに1つのMSG-IDまたは結合-MSG-IDのオブジェクトが許可されています。二つのメッセージ間の依存関係が双方向である場合、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:
結合されたシグナリングメッセージの到着順に応じて（RESERVEは、（1）図13）および「トリガ」バインディングシグナリングメッセージ（RESERVE」（3）図13）には、様々な状況を識別することができます。
o The bound signaling (RESERVE (1)) arrives first. The receiving QNE enqueues (probably after some pre-processing) the signaling (RESERVE (1)) message for the corresponding session. It also starts a MsgIDWait timer in order to discard the message in case the related "triggering" message (RESERVE' in Figure 13) does not arrive. The timeout period for this time SHOULD be set to the default retransmission timeout period (QOSNSLP_REQUEST_RETRY). In case a retransmitted RESERVE message arrives before the timeout, it will simply override the waiting message (i.e., the latter is discarded, and the new message is now waiting with the MsgIDWait timer being reset).
結合したシグナルO（RESERVE（1））最初に到着します。 （おそらく、いくつかの前処理の後に）受信QNEエンキュー対応するセッションのためのシグナリング（RESERVE（1））メッセージ。また、到着しない場合に関連する「トリガ」メッセージ（図13のリザーブ」）メッセージを破棄するためにMsgIDWaitタイマをスタートさせます。この時間のタイムアウト期間は、デフォルトの再送タイムアウト時間（QOSNSLP_REQUEST_RETRY）に設定する必要があります。再送RESERVEメッセージがタイムアウトする前に到着する場合、それは単に（すなわち、後者は廃棄され、新しいメッセージが現在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.
同時に、BOUND-MSG-IDのオブジェクトが同一の発信側QNE（図13においてQNI」）によって送信されるものと同じ値を運ぶ、MSG-IDのオブジェクトを含むメッセージを「トリガー」。中間QNEは「MSG-IDのオブジェクトを見て、それはセッション（QNRのエンドポイントではないと判断することができる」）、従って、単に通常の処理後にメッセージを転送します。集約セッション（即ち、デアグリゲーター）のエンドポイントとして受信QNE（QNR '）はMSG-IDのオブジェクトを解釈して、待機状態今満足する同じ値のBOUND-MSG-IDと対応する待機メッセージを探し。 RESERVEの成功処理に応じて、「（3）、待機RESERVEの処理が再開され、MsgIDWaitタイマーはすぐに関連RESERVEのように停止されます」到着しました。
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | | (1) | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | | (2) | | |
| | +=========>| RESERVE' | |
| | | | (3) | |
| | | +=========>| RESERVE |
| | | | | (4) |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |
(1): RESERVE: SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A (2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x (4): RESERVE: SESSION-ID=F (MSG-ID object was removed)
（1）：RESERVE：SESSION-ID = F、結合-MSG-ID = X、結合-SESSION-ID = A（2）+（3）：RESERVE '：SESSION-ID = A、MSG-ID = X（ 4）：RESERVE：SESSION-ID = F（MSG-IDのオブジェクトが削除されました）
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）：この場合、トリガメッセージの処理はMessage_Binding_Typeフラグの値に依存します。 Message_Binding_Typeが設定されていない場合（値は0）、その後、トリガメッセージを正常に処理することができるが、MSG-ID及び結果（成功または失敗）が待機メッセージのために保存されるべきです。したがって、応答が即座に「QNRで送信することができます」。待機メッセージが（1）最終的には「QNRに到着した場合、トリガーメッセージは、すでに以前に到着しているため待機状態が既に満たされたことを検出することができます。 Message_Binding_Typeは（値は1）に設定されている場合、トリガメッセージはMSG-IDのオブジェクトを解釈し、この場合には、まだ到着していない同じ値のBOUND-MSG-IDと対応する待機メッセージを探し。次に、関連するメッセージ（図14のRESERVE（1））が到着しない場合にメッセージを廃棄するためにMsgIDWaitタイマをスタートさせます。 「QNIに向けた」QNRで送ることができRESERVE（1）、待機しているRESERVEの処理が成功の処理に応じて、「関連RESERVEが到着し、応答は次のように再開されます、MsgIDWaitタイマーはすぐに停止します」。
o The "triggering message" (3) does not arrive at all: this may be due to message loss (which will cause a retransmission by the QNI' if the RII object is included) or due to a reservation failure at an intermediate node (QNE' in the example). The MsgIDWait timeout will then simply discard the waiting message at QNR'. In this case, the QNR' MAY send a RESPONSE message towards the QNI informing it that the synchronization of the two messages has failed.
「トリガメッセージ」O（3）全く到着しない：これは、中間ノードに起因予約の失敗に（RIIオブジェクトが含まれていれば「QNIにより再送が発生します）メッセージ損失または起因し得ます（例のQNE」）。 MsgIDWaitタイムアウトは、単に「QNRで待機中のメッセージを破棄します。この場合、QNRは」二つのメッセージの同期が失敗したことを知らせるQNIに対する応答メッセージを送るかもしれません。
o Retransmissions should use the same MSG-ID because usually only one of the two related messages is retransmitted. As mentioned above: retransmissions will only occur if the RII object is set in the RESERVE. If a retransmitted message with a MSG-ID arrives while a bound message with the same MSG-ID is still waiting, the retransmitted message will replace the bound message.
通常は2つのだけ、関連するメッセージのいずれかが再送信されるので、O再送は、同じMSG-IDを使用する必要があります。上述したように：RIIオブジェクトはRESERVEに設定されている場合、再送信にのみ発生します。同じMSG-IDを持つバウンドメッセージはまだ待っている間にMSG-IDと再送されたメッセージが到着した場合、再送されたメッセージは、バインドされたメッセージを交換します。
For a receiving node, there are conceptually two lists indexed by message IDs. One list contains the IDs and results of triggering messages (those carrying a MSG-ID object), the other list contains the IDs and message contents of the bound waiting messages (those who carried a BOUND-MSG-ID). The former list is used when a triggering message arrives before the bound message. The latter list is used when a bound message arrives before a triggering message.
受信ノードは、メッセージIDによってインデックスさ二つのリストは、概念的にあります。一つのリストには、IDとトリガメッセージ（MSG-IDのオブジェクトを有するもの）の結果が含まれ、他のリストは、IDとバウンド待ちのメッセージ（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と内部ノードが格納GISTおよびQoS NSLP状態を回避することを可能にするNSLP機能に関連して、ドメイン内の異なるQoSモデルを使用します。その結果、内部ノードだけで全て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はRESERVEメッセージ（図14参照）を開始します。ステートレスまたは低減状態領域のエッジ上QNEsで、処理が異なり、ノードは2つのQoSモデルをサポートします。入口で、元のRESERVEメッセージが転送されるが、ステートレスまたは低減状態ノードによって無視します。これは、すなわち、入口でこのメッセージをマーキングNSLPID所定の値へのQoS NSLPデフォルトNSLPID値を変更することによって達成される（セクション4.6参照）。出力は、元のエンド・ツー・エンドのRESERVEメッセージに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.
出口ノードは、エンドツーエンドRESERVEメッセージのための次のQoS-NSLPホップです。信頼性GIST転送モードは、内部にGIST状態を必要とすることなく、入力と出力との間で使用することができます。出口ノードにおいて、RESERVEメッセージは、その後、正常に転送されます。
At the ingress, a second RESERVE' message is also built (Figure 14). This makes use of a QoS model suitable for a reduced-state or stateless form of operation (such as the RMD per-hop reservation). Since the original RESERVE and the RESERVE' messages are addressed identically, the RESERVE' message also arrives at the same egress QNE that was also traversed by the RESERVE message. Message binding is used to synchronize the messages.
入口で、第二RESERVE」メッセージはまた、（図14）が内蔵されています。これは、低減状態又は（例えばRMDホップごとの予約のような）動作のステートレス形態に適したQoSモデルを利用します。オリジナルRESERVEとRESERVE「メッセージが同じアドレス指定される、RESERVE」以来メッセージはまた、RESERVEメッセージによって横断されたのと同じ出口QNEに到達します。結合メッセージは、メッセージを同期するために使用されます。
When processed by interior (stateless) nodes, the QoS NSLP processing exercises its options to not keep state wherever possible, so that no per-flow QoS NSLP state is stored. Some state, e.g., per class, for the QSPEC-related data may be held at these interior nodes. The QoS NSLP also requests that GIST use different transport characteristics (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処理が可能な限り何のフローごとの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').
出口ノードにおいて、RESERVE」メッセージ（シグナリングフローを相関させるメッセージで運ばれた情報を使用して）、エンドツーエンドのRESERVEメッセージから予約状態と関連して解釈されます。 RESERVE」メッセージの処理は、ローカルドメイン内のすべてのノードで成功した場合RESERVEメッセージは、さらに転送されます。そうでない場合は、エンドツーエンドの予約をインストールするために失敗したとみなされます。これは、結合したシグナリングメッセージ（エンド・ツー・エンドRESERVE）と結合シグナリングメッセージ（ローカル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モデル処理に反映されます。 RESERVE「はQNE Aで障害が発生した場合、それは戻って入口QNEにエラーメッセージを送信することはできません。このように、RESERVEは」意図したパスに沿って転送されますが、QSPECは、エラーが起こった上流それらを言って、その後のQNEsための情報が含まれています。それは何をすべきかを決定するためのQoSモデルまでです。結局、RESERVEは」出口の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によって受信されるRESERVEメッセージは、（QUERYメッセージの送信元として知られている）入口QNEに透過的に送信されます。 RESERVEメッセージが入力に到達すると、入口QNEはステートレスドメイン上で、送信者が開始したRESERVE」を送信する必要があります。入口QNEは、応答」を待つ必要があります。応答は」予約が正常に達成されたことを通知した場合は、入口QNEは、さらに上流RESERVEメッセージを送信します。
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）として動作するように管理者が割り当てにより設定されています。シグナリングを開始ノードは、シグナリングがプロキシ、例えば、ローカル・アクセス・ネットワークによって制御されるエリア内に限定されることを意図されていることを示すために、PROXYスコープのフラグを設定することができます。
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であり、プロキシスコープのフラグが設定されたRESERVEを送信します。 P-QNEはQNRあります。それは、RESERVEを受信PROXYスコープのフラグがセットされて気づき、（要求された場合）RESPONSEで応答します。発信フローの受信指向予約がP-QNEがQNIであることを除いて、図8の場合と同じように動作し、図7に示すように、この動作は同じです。
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であり、PROXYスコープのフラグを設定してデータ送信側に向けてRESERVEを送信します。それは、データの受信側としてエンドホストを示し、Dフラグをセットするようにここでエンドホストは、MRIを設定します。
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.
PROXYスコープフラグが入ってくるのQoS NSLPメッセージに設定されている場合は、QNEは、このセッションに関連して、送信するすべてのQoS NSLPメッセージで同じフラグを設定する必要があります。
A QoS NSLP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The common header and other objects are encapsulated together in a GIST NSLP-Data object. The following subsections define the formats of the common header and each of the QoS NSLP message types. In the message formats, the common header is denoted as COMMON-HEADER.
QoS NSLPメッセージが可変長の可変数からなる本体続い共通ヘッダから成り、「オブジェクト」を入力しました。共通ヘッダ及び他の目的は、GIST NSLP-データオブジェクトに一緒にカプセル化されます。以下のサブセクションでは、共通ヘッダのフォーマットとQoS NSLPメッセージタイプのそれぞれを定義します。メッセージの形式で、共通ヘッダは、共通ヘッダとして示されます。
For each QoS NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 [RFC5234]. The ABNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation SHOULD create messages with the objects in the order shown here, but MUST accept the objects in any order.
各QoS NSLPメッセージタイプのために、オブジェクトタイプの許容選択するための規則のセットがあります。これらのルールは、RFC 5234 [RFC5234]で指定された拡張バッカス・ナウアフォーム（ABNF）を使用して指定されます。 ABNFは、メッセージ内のオブジェクトの順序を暗示します。しかし、多くの（すべてではない）の場合には、オブジェクトの順序は、論理的違いはありません。実装は、ここに示す順序でオブジェクトとのメッセージを作成する必要がありますが、どのような順序でオブジェクトを受け入れなければなりません。
All GIST NSLP-Data objects for the QoS NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header).
QoS NSLPのための全てのGIST NSLP・データ・オブジェクト（これはGIST共通ヘッダと同じではない）オブジェクトの最初の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Message Flags | Generic Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the common header are as follows:
次のように共通ヘッダ内のフィールドは以下のとおりです。
Msg Type: 8 bits
メッセージの種類：8ビット
1 = RESERVE
1 = RESERVE
2 = QUERY
2 = QUERY
3 = RESPONSE
3 = RESPONSE
4 = NOTIFY
4 = NOTIFY
Message-specific flags: 8 bits
メッセージ固有フラグ：8ビット
These flags are defined as part of the specification of individual messages, and, thus, are different with each message type.
これらのフラグは、このように、各メッセージタイプと異なり、個々のメッセージの仕様の一部として定義され、。
Generic flags: 16 bits
一般的なフラグ：16ビット
Generic flags have the same meaning for all message types. There exist currently four generic flags: the (next hop) Scoping flag (S), the Proxy scope flag (P), the Acknowledgement Requested flag (A), and the Break flag (B).
一般的なフラグは、すべてのメッセージタイプのために同じ意味を持ちます。 （次のホップ）スコープフラグ（S）、プロキシ範囲フラグ（P）、肯定応答要求フラグ（A）、およびブレークフラグ（B）：現在4つの汎用フラグが存在します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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） - 設定した場合、メッセージがスコープされ、全体の道を移動するべきではないが、ことを示しているのみ限り次QNE（範囲=「ネクストホップ」）など。デフォルトでは、このフラグは、（デフォルトのスコープ=「パス全体を」）に設定されていません。
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） - セットは、メッセージが受信ピアによって確認されるべきであることを示しています。フラグは、ステートフルピア間で使用される、唯一RESERVEとQUERYメッセージで使用されます。現在、フラグは、リフレッシュメッセージで使用されています。デフォルトでは、フラグが設定されていません。
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層に速く死んだピア検出に有用です。この活気テストは唯一のリフレッシュRESERVEメッセージで使用することができます。確認がすでにQNRから要求されたので、ACK-REQフラグは、すでにRIIオブジェクトが含まれるRESERVEメッセージ用に設定してはいけません。 2つのQoS NSLPピア間のメッセージの信頼性の高い伝送は、それ自体ではないNSLP、GISTによって処理されなければなりません。
The format of a RESERVE message is as follows:
次のようにRESERVEメッセージのフォーマットは次のとおりです。
RESERVE = COMMON-HEADER RSN [ RII ] [ REFRESH-PERIOD ] [ *BOUND-SESSION-ID ] [ SESSION-ID-LIST [ RSN-LIST ] ] [ MSG-ID / BOUND-MSG-ID ] [ INFO-SPEC ] [ [ PACKET-CLASSIFIER ] QSPEC ]
RESERVE = COMMON-HEADER RSN [RII] [リフレッシュ周期] [* BOUND-SESSION-ID] [セッションID-LIST [RSN-LIST] [MSG-ID / BOUND-MSG-ID] [INFO-SPEC] [パケット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に向けて送信された初期RESERVEに含めなければなりません。パケット分類器は設けられていてもよいです。パケット分類器は提供されていない場合、そのセッションのためにGIST MRIで提供される情報のフルセットは、パケット分類の目的のために使用すべきです。
Subsequent RESERVE messages meant as reduced refreshes, where no QSPEC is provided, MUST NOT include a PACKET-CLASSIFIER either.
その後のRESERVEメッセージは何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つのメッセージ固有フラグはRESERVEメッセージで共通ヘッダで使用するために定義されています。これらは：
+-+-+-+-+-+-+-+-+
|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.
TEAR（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）REPLACE - 設定した場合、フラグは2つの用途を有しています。まず、それは別のMRI（同じSID）とRESERVEは、既存のものを置き換えることを示しているので、古いものはすぐに取り壊されるかもしれません。これはデフォルトの状況です。このフラグは、所定の位置に古い枝に既存の予約を維持するための上流ノードからの願望を示すために、設定を解除することがあります。第二に、このフラグは、データパスの変更が発生したときに、古いブランチの予約リソースが取り壊されるべきか否かを示すために使用されます。この場合、MRIは、同じだけのルートパスの変更です。
If the REFRESH-PERIOD is not present, a default value of 30 seconds is assumed.
REFRESH-期間が存在しない場合、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).
このメッセージのセッションが別のセッションにバインドされている場合、RESERVEメッセージはBOUND-SESSION-IDのオブジェクトに他のセッションのセッションIDを含まなければなりません。集約されたトンネルのような状況では、集約セッションはBOUND-SESSION-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外で行われます。しかし、理論的には、送信者がもう一方の端は、それが受信機が開始した予約を開始すべきであると考えている一方で、送信者が開始した予約が、流れのために行われるべきであると考えている場合は、「予約の衝突が」発生する可能性があります。別のセッション識別子を使用している場合、それはRMFからエラーになるかもしれませんが、このエラー状態は、QoSのNSLPに対して透過的です。それ以外の場合は、重複予約の除去は、二つのセッションのための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.
予約が既にインストールされ、RESERVEメッセージは、他の方向から同一のセッション識別子を用いて受信された場合（すなわち、予約下流RESERVEメッセージ、またはその逆によってインストールされた場所の上流に行く）、次いでRESERVEから受信」を示すエラー間違った方向」とは、この第二のRESERVEためのシグナリング・メッセージ・ソースに対する応答メッセージで送信されなければなりません。
A refresh right along the path can be forced by requesting a RESPONSE from the far end (i.e., by including an RII object in the RESERVE message). Without this, a refresh RESERVE would not trigger RESERVE messages to be sent further along the path, as each hop has its own refresh timer.
右の経路に沿ってリフレッシュが遠端（すなわち、RESERVEメッセージ中RIIオブジェクトを含むことによる）からの応答を要求することによって強制することができます。各ホップは独自のリフレッシュタイマを持っているとしてこれがないと、リフレッシュRESERVEは、パスに沿ってさらに送信されるRESERVEメッセージをトリガしないでしょう。
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の再送信を無効にする必要があります。信頼性の高いトランスポートを使用するようにGISTを求めることができる含まRIIと引き裂きRESERVEを送信するQNE。 QNEは引き裂きRESERVEを送信すると、それはもうリフレッシュメッセージを送ってはいけません。
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バインディング更新を送信した場合、結果のリフレッシュが新しいRESERVEです。このRESERVEは新しい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.
注意：ホストは常に爽やかRESERVEメッセージを送信するために、パス上のQNEsを強制的にこのメカニズムを使用することが可能です。 QNEsは、彼らが送るリフレッシュメッセージにレート制限を実行することは、それゆえ、適切な場合があります。
The format of a QUERY message is as follows:
次のようにQUERYメッセージの形式は次のとおりです。
QUERY = COMMON-HEADER [ RII ] [ *BOUND-SESSION-ID ] [ PACKET-CLASSIFIER ] [ INFO-SPEC ] QSPEC [ QSPEC ]
QUERY = COMMON-HEADER [RII] [* BOUND-SESSION-ID] [パケット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.
QUERYメッセージは常にQSPECを含まなければなりません。メッセージは、受信機によって開始予約をトリガするために使用される場合QUERYメッセージは、パケット分類器を含むかもしれません。パケット分類器は、次に含まれていない場合は、完全なGIST MRIは、その後のRESERVEでのパケット分類の目的のために使用する必要があります。 QUERYメッセージは、第QSPECオブジェクトを含むかもしれません。
A QUERY message for requesting information about network resources MUST contain an RII object to match an incoming RESPONSE to the QUERY.
ネットワーク・リソースに関する情報を要求する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:
一つのメッセージ固有フラグはQUERYメッセージで共通ヘッダで使用するために定義されています。これは、次のとおりです。
+-+-+-+-+-+-+-+-+
|Reserved |R|
+-+-+-+-+-+-+-+-+
RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger for the recipient to make a resource reservation by sending a RESERVE.
RESERVE-INIT（R） - これが設定されている場合、クエリは、RESERVEを送信することによって、リソース予約をし、受信者のためのトリガとして意図されています。
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).
このメッセージのセッションが別のセッションにバインドされている場合、RESERVEメッセージはBOUND-SESSION-IDのオブジェクトに他のセッションのセッションIDを含まなければなりません。集約されたトンネルのような状況では、集約セッションはBOUND-SESSION-ID（複数可）でのバインドセッションのセッションIDを含まなくてもよいです。
The format of a RESPONSE message is as follows:
次のようにRESPONSEメッセージの形式は次のとおりです。
RESPONSE = COMMON-HEADER [ RII / RSN ] INFO-SPEC [SESSION-ID-LIST [ RSN-LIST ] ] [ QSPEC ]
RESPONSE = COMMON-HEADER [RII / RSN] INFO-SPEC [セッションID-LIST [RSN-LIST] [QSPEC]
A RESPONSE message MUST contain an INFO-SPEC object that indicates the success of a reservation installation or an error condition. Depending on the value of the INFO-SPEC, the RESPONSE MAY also contain a QSPEC object. The value of an RII or an RSN object was provided by some previous QNE. There are no requirements on transmission order, although the above order is recommended.
応答メッセージは、予約のインストールやエラー状態の成功を示すINFO-SPECオブジェクトを含まなければなりません。 INFO-SPECの値に応じて、応答もQSPECオブジェクトを含むかもしれません。 RIIまたはRSNオブジェクトの値は、いくつかの以前のQNEによって提供されました。上記の順序が推奨されますが、何の要件は、送信順序ではありません。
No message-specific flags are defined for use in the common header with the RESPONSE message.
いいえメッセージ固有フラグは、応答メッセージを共通ヘッダで使用するために定義されていません。
The format of a NOTIFY message is as follows:
次のようにNOTIFYメッセージの形式は次のとおりです。
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.
NOTIFYメッセージは、通知の理由を示すINFO-SPECオブジェクトを含まなければなりません。 INFO-SPECの値に応じて、追加情報を提供するQSPECオブジェクトを含むかもしれません。
No message-specific flags are defined for use with the NOTIFY message.
いいえメッセージ固有のフラグは、NOTIFYメッセージで使用するために定義されていません。
The QoS NSLP uses a Type-Length-Value (TLV) object format similar to that used by GIST. Every object consists of one or more 32-bit words with a one-word header. For convenience, the standard object header is shown here:
QoS NSLPはGISTによって使用されるものと同様なType-Length-Value（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).
Typeフィールドの値が共有NSLPオブジェクト型空間から来ます。さまざまなオブジェクトは、次のセクションで提示されています。 Lengthフィールドは、32ビットのワード単位で与えられ、TLVオブジェクト（すなわち、それは標準ヘッダを含まない）の値コンポーネントの長さを測定します。
The bits marked 'A' and 'B' are flags used to signal the desired treatment for objects whose treatment has not been defined in the protocol specification (i.e., whose Type field is unknown at the receiver). The following four categories of object have been identified, and are described here.
ビットは「A」および「B」その治療プロトコル仕様で定義されていないオブジェクトの所望の処置を知らせるために使用されるフラグをマークし（すなわち、そのタイプフィールド、受信機に知られていません）。オブジェクトの以下の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（「無視」）：オブジェクトが理解されていない場合、それは削除され、通常どおり処理されたメッセージの残りなければなりません。
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
AB = 10（「フォワード」）：オブジェクトが理解されていない場合は、メッセージ処理の結果として転送されたメッセージで不変保持するが、ローカルに格納されないことを意味します。
AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored QoS NSLP signaling application operational state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message that is generated locally. The contents of this object does not need to be interpreted, and should only be stored as bytes on the QNE.
AB = 11（「更新」）：オブジェクトが理解されていない場合は、任意の結果のメッセージで転送、このフロー/セッションのためのアプリケーションの動作状態を知らせるローカルに格納されたQoS NSLPに組み込まれ、また、任意のリフレッシュまたは修復に使用されるべきですローカルで生成されたメッセージ。このオブジェクトの内容を解釈する必要はない、とだけQNE上のバイトとして格納されるべきです。
The remaining bits marked 'r' are reserved. These SHALL be set to 0 and SHALL be ignored on reception. The extensibility flags AB are similar to those used in the GIST specification. All objects defined in this specification MUST be understood by all QNEs; thus, they MUST have the AB-bits set to "00". A QoS NSLP implementation must recognize objects of the following types: RII, RSN, REFRESH-PERIOD, BOUND-SESSION-ID, INFO-SPEC, and QSPEC.
「R」マーク残りのビットは予約されています。これらは、0に設定されなければならないし、受信時に無視されなければなりません。拡張フラグABはGISTの明細書中で使用されるものと同様です。本明細書で定義されたすべてのオブジェクトは、すべてのQNEsによって理解されなければなりません。このように、彼らは「00」に設定AB-ビットを持たなければなりません。 RII、RSN、REFRESH期間、BOUND-SESSION-ID、INFO-SPEC、およびQSPEC：QoSのNSLPの実装は、次の種類のオブジェクトを認識しなければなりません。
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.
オブジェクトヘッダは、異なる目的のために変化する値フィールドが続きます。現在定義されたオブジェクトのValueフィールドのフォーマットは以下に規定されます。
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のコンテキスト内（確率）一意である必要があり、応答が望まれるたびに異なるべき識別子。 RESERVEまたはQUERYメッセージ内の要求に対する応答を返すと一致する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
タイプ：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]で指定されるように）指定します。
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
0x02のO - 双方向セッション
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つの原子結合アクションに基づいて定義されてもよいです。複数BOUND-SESSION-IDのオブジェクトを含むことができるメッセージを注意してください。これは、1つは、より特異的に結合するための理由を定義する必要がある、またはセッションが（おそらく異なる理由で）複数の他のセッションに依存する場合場合に必要とされてもよいです。セッションで、例えば、SID_A（結合セッション）が、そのメッセージにBOUND-SESSION-IDのオブジェクトを含むSID_Bを含むことによって、と別のセッション、例えば、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
- 送信元ポート
B - Destination Port
B - 宛先ポート
The flags indicate which fields from the MRI MUST be used by the packet classifier. This allows a subset of the information in the MRI to be used for identifying the set of packets that are part of the reservation. Flags MUST only be set if the data is present in the MRI (i.e., where there is a corresponding flag in the GIST MRI, the flag can only be set if the corresponding GIST MRI flag is set). It should be noted that some flags in the PACKET-CLASSIFIER (X and Y) relate to data that is always present in the MRI, but are optional to use for QoS NSLP packet classification. The appropriate set of flags set may depend, to some extent, on the QoS model being used.
フラグは、MRIからのフィールドはパケット分類器によって使用されなければならないかを示します。これは、MRIにおける情報のサブセットが予約の一部であるパケットのセットを識別するために使用されることを可能にします。フラグは、（GIST MRIに対応するフラグがある場合、すなわち、フラグのみ対応GIST MRIフラグが設定されている場合に設定することができる）データがMRI中に存在する場合に設定しなければなりません。パケットCLASSIFIER（X及びY）におけるいくつかのフラグは常にMRIに存在するデータに関連する、しかしのQoS NSLPパケットの分類に使用するオプションであることに留意すべきです。設定されたフラグの適切なセットが使用されているQoSモデルに、ある程度、依存し得ます。
As mentioned earlier in this section, the QoS NSLP is currently only defined for use with the Path-Coupled Message Routing Method (MRM) in GIST. Future work may extend the QoS NSLP to additional routing mechanisms. Such MRMs must include sufficient information in the MRI to allow the subset of packets for which QoS is to be provided to be identified. When QoS NSLP is extended to support a new MRM, appropriate method-specific classifier data for the PACKET-CLASSIFIER object MUST be defined.
この項で前述したように、のQoS NSLPは、現在のみGISTにおけるパス結合メッセージルーティング法（MRM）で使用するために定義されています。今後の作業は、追加のルーティングメカニズムへのQoS NSLPを延長することができます。そのようなのMRMは、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クラス・ビットは、エラーの重大度クラスを示します。現在定義されたエラーのクラスがあります。o 1 - 情報
o 2 - Success
O 2 - 成功
o 3 - Protocol Error
O 3 - プロトコルエラー
o 4 - Transient Failure
O 4 - 一時的な障害
o 5 - Permanent Failure
O 5 - 永続的なエラー
o 6 - QoS Model Error
O 6 - QoSのモデル誤差
Error field:
エラーフィールド：
Within each error severity class, a number of Error Code values are defined.
各エラーの重大度クラス内では、エラーコードの値の数が定義されています。
o Informational:
情報O：
* 0x01 - Unknown BOUND-SESSION-ID: the message refers to an unknown SESSION-ID in its BOUND-SESSION-ID object.
* 0x01の - 不明BOUND-SESSION-ID：メッセージは、そのBOUND-SESSION-IDのオブジェクトで不明SESSION-IDを指します。
* 0x02 - Route Change: possible route change occurred on downstream path.
* 0×02 - ルート変更：可能なルート変更が下流パスで発生しました。
* 0x03 - Reduced refreshes not supported; full QSPEC required.
* 0x03の - サポートされていません削減リフレッシュ。フルQSPECが必要。
* 0x04 - Congestion situation: Possible congestion situation occurred on downstream path.
* 0x04を - 輻輳状況：可能混雑状況は、ダウンストリームパス上で発生しました。
* 0x05 - Unknown SESSION-ID in SESSION-ID-LIST.
* 0x05の - SESSION-ID-LISTで不明SESSION-ID。
* 0x06 - Mismatching RSN in RSN-LIST.
* 0x06で - 不整合RSNにおけるRSN-LIST。
o Success:
成功O：
* 0x01 - Reservation successful
* 0x01の - 成功予約
* 0x02 - Teardown successful
* 0×02 - ティアダウンに成功
* 0x03 - Acknowledgement
* 0×03 - 謝辞
* 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.
* 0×01 - 不正なメッセージタイプ：共通ヘッダのメッセージタイプフィールドで指定されたタイプが不明です。
* 0x02 - Wrong message length: the length given for the message does not match the length of the message data.
* 0×02 - 間違ったメッセージの長さ：メッセージに指定された長さは、メッセージデータの長さと一致していません。
* 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.
* 0×04 - バートフラグ値：フラグの未定義のフラグまたは組合せは、メッセージ固有のフラグにセットしました。
* 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の - RESERVEが間違った方向から受信しました。
* 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オブジェクトのvalueフィールドの誤った値。
* 0x0f - Incompatible QSPEC.
* 0x0Fの - 互換性のないQSPEC。
o Transient Failure:
一時的な障害○：
* 0x01 - No GIST reverse-path forwarding state
* 0x01の - いいえ、GISTは逆ないパスフォワーディングステート
* 0x02 - No path state for RESERVE, when doing a receiver-oriented reservation
* 0×02 - RESERVEなしパスの状態、受信機指向の予約をするとき
* 0x03 - RII conflict
* 0x03の - RII紛争
* 0x04 - Full QSPEC required
* 0x04を - フルQSPECが必要
* 0x05 - Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE
* 0x05の - エンドツーエンドRESERVE間のミスマッチの同期や、ドメイン内RESERVE
* 0x06 - Reservation preempted
* 0x06で - 予約先取り
* 0x07 - Reservation failure
* 0x07に - 予約失敗
* 0x08 - Path truncated - Next peer dead
* 0x08に - 切り捨てパス - 死ん次ピア
o Permanent Failure:
永続的なエラーO：
* 0x01 - Internal or system error
* 0×01 - 内部またはシステム・エラー
* 0x02 - Authorization failure
* 0×02 - 認証に失敗
o QoS Model Error:
QoSのモデル誤差O：
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.
エラーソース識別子は、診断目的のためであり、その包含は任意です。実装は、IPアドレス、ホスト名、または診断の活動を支援するためにINFO-SPECを生成するQNEの他の識別子のためにこれを使用することを示唆しています。 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
エラーソース識別子：FQDNでのUTF-8
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.
オブジェクトの種類が誤っている場合、次のオプションのエラー固有の情報は、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.
オブジェクト内のフィールドが不正な値を持っていた場合、以下のオプションのエラー固有の情報は、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ビットのSESSION-IDのリスト。すべてのSESSION-IDが一緒に連結されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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.
値：可変長QSPEC（QOS仕様）情報、QoSモデルに依存しています。
The contents and encoding rules for this object are specified in other documents. See [RFC5975].
このオブジェクトの内容と符号化規則は、他の文書で指定されています。 [RFC5975]を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// QSPEC Data //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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機能との間で通信トリガは付録付録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,
QoSモデルO / 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動作状態、非永続的な状態（例えば、APIパラメータQNEがメッセージを処理している間）、及び
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 A 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ネクストホップを参照することを可能にするハンドルです。詳細については、[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.
バインドされたセッションのリストこの状態にバインドされた各セッションについてBOUND-SESSION-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は、パスの末尾に直接送信されるメッセージの概念がありません。代わりに、メッセージは次のように（QNI又はQNRに向かって、すなわち、）同じ方向に継続する（受信したメッセージと同一であるか、またはそれからオブジェクトのサブセットを含んでいてもよい）は、別のメッセージを送信することができるQNEによって受信されますメッセージを受信しました。
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間）、またはピアツーピア（二つの隣接する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待機期間後に発生します。再送は、指数関数的に増加する待機間隔（待機たび倍加）を用いて行わなければなりません。 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含め、RESERVEメッセージを送るべきです。これは、QNRからの応答を要求するRIIを含むべきであるRSN [現在]はRSN = RSN0 + 2を含まなければなりません。 GISTにAPIを介してこのメッセージを渡すときに、メッセージが正しく新しいピアQNEにルーティングされるように、SII-ハンドルは、指定することはできません。
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が新しい道を送っRESERVEメッセージに関連する応答メッセージを受信すると、古い道を送っTEARフラグでRESERVEメッセージを送るべきです。そのためには、その明示的なルーティングメカニズムを使用するGISTを要求しなければなりません、およびQoS NSLPは、古いピアQNEに関するSII-ハンドルを供給しなければなりません。このRESERVEメッセージを送信する場合、それはRSN [現在]であるRSNを含まなければなりません - 1（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.
新しいパスへのRESERVEを送信した後に受信したレスポンスコードが含まれている場合はINFO-SPECで「成功した更新」、そしてQNEが、これはパスが変更されていないことを示しているので、引き裂きRESERVEを送信しないことを選択するかもしれません。
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は、可能な上流のルート変更は、GISTのAPIを介して発生したことのQoS NSLPを通知することができます。そのような通知を受信すると、QoS NSLPは、識別されたMRIに関連付けられたセッションをシグナリングするための情報コードが0x02でNOTIFYメッセージを送信するべきです。これが送信される場合は、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.
このようNOTIFYメッセージを受信すると、QoS NSLPは状態をルーティングすることは古くなっている可能性がありGISTを知らせるためにInvalidateRoutingState API呼び出しを使用すべきです。 QoSのNSLPは、NOTIFYメッセージを上流に送るべきです。 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.
ルートの後、ソフト状態がタイムアウトまたは明示的なTEARが受信されるまで予約をリフレッシュしていきます古いパス上のルータを変更します。
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が開始さ再び昔の上流のピアからのメッセージの受信、または
o it stops receiving refreshes from the new upstream peer for at least the soft-state timeout period.
Oは、少なくともソフトステートタイムアウト期間のための新しい上流のピアからリフレッシュの受信を停止します。
GIST routing state keeps track of the latest upstream peer it has seen, and so may spuriously indicate route changes occur when the old upstream peer refreshes its routing state until the state at that node is explicitly torn down or times out.
状態をルーティングGISTは、上流、それは見ているピア、およびので、誤ってそのノードの状態が明示的にまたは回取り壊されるまで、古い上流のピアがそのルーティング状態を更新したときにルート変更が生じ示すことがあり、最新の追跡します。
This section presents processing rules for individual QoS NSLP objects.
このセクションでは、個々のQoS NSLP・オブジェクトの処理ルールを提示します。
A QNE's own RSN is a sequence number which applies to a particular signaling session (i.e., with a particular SESSION-ID). It MUST be incremented for each new RESERVE message where the reservation for the session changes. The RSN is manipulated using the serial number arithmetic rules from [RFC1982], which also defines wrapping rules and the meaning of 'equals', 'less than', and 'greater than' for comparing sequence numbers in a circular sequence space.
QNE自身のRSN（すなわち、特定のセッションIDを有する）特定のシグナリングセッションに適用されるシーケンス番号です。これは、セッションの変更のための予約それぞれの新しいRESERVEメッセージのために増加しなければなりません。 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は0から始まります。下流ピア変化が発生した場合には（すなわち、それはゼロにリセットされていない）セッションごとの状態の一部として記憶され、それが増分に担持されています。 （セクション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.
RESERVEメッセージを受信するQNEは、メッセージを送信するピアが再起動したかどうかを決定するためにエポック識別子を検査します。エポック識別子は、次にRESERVEメッセージが更新された予約（RSNが現在格納されている値よりも小さい場合であっても）として扱われなければならない予約のために格納されているとは異なる場合、および保存されたRSNとエポック識別子が新たに更新されなければなりません値。
When receiving a RESERVE message, a QNE uses the RSN given in the message to determine whether the state being requested is different to that already stored. If the RSN is equal to that stored for the current reservation, the current state MUST be refreshed. If the RSN is greater than the current stored value, the current reservation MUST be modified appropriately as specified in the QSPEC (provided that admission control and policy control succeed), and the stored RSN value updated to that for the new reservation. If the RSN is greater than the current stored value and the RESERVE was a reduced refresh, the QNE SHOULD send upstream a transient error message "Full QSPEC required". If the RSN is less than the current value, then it indicates an out-of-order message, and the RESERVE message MUST be discarded.
RESERVEメッセージを受信すると、QNEは、要求された状態が既に記憶されているものと異なっているかどうかを決定するためにメッセージに与えられたRSNを使用します。 RSNが現在の予約のために格納されているに等しい場合、現在の状態がリフレッシュされなければなりません。 RSNが現在格納されている値よりも大きい場合、現在の予約は、（アドミッション制御およびポリシー制御が成功している場合）QSPECで指定されるように適切に変更し、新たな予約のためのものに更新記憶されたRSNの値でなければなりません。 RSNが現在格納されている値よりも大きいとRESERVEを低減リフレッシュた場合、QNEは、一時的なエラー・メッセージ「が必要です全QSPECを」上流送るべきです。 RSNが現在の値よりも小さい場合、それはアウトオブオーダーメッセージを示し、RESERVEメッセージは破棄されなければなりません。
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の値を無視するかもしれません。また、それはこの1つを受けた結果として送信する（もしあれば）RESERVEメッセージに同じ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.
QUERYまたはRESERVEメッセージを送信する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.
これを実装するときに選択肢の数が用意されています。可能性はカウンタとともにランダム値、またはノード識別子を使用することを含むかもしれません。値が異なるQUERYのための別の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 PROXY範囲フラグが設定され、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、およびQNE上の既存RII値でこの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は一緒に複数のセッションを関連付けることができます。それは別のセッション内のメッセージにBOUND-SESSION-IDのオブジェクト内の1つのセッションからSESSION-IDを含めることによってこれを行います。
When receiving a message with a BOUND-SESSION-ID object, a QNE MUST copy the BOUND-SESSION-ID object into all messages it sends for the same session. A QNE that stores per-session state MUST store the value of the BOUND-SESSION-ID.
BOUND-SESSION-IDのオブジェクトとのメッセージを受信すると、QNEは、同じセッションのために送信するすべてのメッセージにBOUND-SESSION-IDのオブジェクトをコピーする必要があります。店舗ごとのセッション状態がBOUND-SESSION-IDの値を格納する必要がありQNE。
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.
BOUND-SESSION-IDは、自然の中で唯一の指標です。しかし、QNEの実装では、双方向予約のために、例えば、資源配分を最適化するためにBOUND-SESSION-ID情報を使用することができます。集約の予約のためのティアダウンメッセージ（例えば、ティアダウンセマンティクスで予約メッセージ）を受信した場合、QNEは、集約に結合し、エンドツーエンドセッションのティアダウンを開始するためにこの情報を使用することができます。 QoS NSLP実装は、単一のメッセージ内の複数のBOUND-SESSION-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.
リフレッシュタイマ管理値は、ローカルな意味を持っているだけREFRESH周期オブジェクトによって運ばれます。 「リフレッシュタイムアウト」期間の満了時に、各QNEは、独立して、その状態を調べ、それが吸収され、次のQNEピアにリフレッシュRESERVEメッセージを送信します。このピア・ツー・ピアリフレッシュが（QNRにすべての道を移動するリフレッシュを開始QNIではなく）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のセクション3.7 [RFC 2205]で指定されたものと同じです。
There are two time parameters relevant to each QoS NSLP state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RESERVE message may contain a REFRESH-PERIOD object specifying the R value that was used to generate this (refresh) message. This R value is then used to determine the value for L when the state is received and stored. The values for R and L may vary from peer to peer.
二つの時間ノードにおける各QoS NSLP状態に関連するパラメータがあり：隣接ノードによる状態のための連続したリフレッシュの発生との間のリフレッシュ期間R、及びローカル状態の寿命L.がそれぞれRESERVEメッセージは、特定REFRESH周期オブジェクトを含んでいてもよいですこの（リフレッシュ）メッセージを生成するために使用された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オブジェクトがRESERVEまたはQUERYメッセージに含まれていない場合でも、エラー状態の場合に、エラーメッセージが生成されるべきです。 TEARフラグがRESERVEメッセージに設定されている場合、エラー状況が応答メッセージの生成をトリガしないように注意してください。
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.
INFO-SPECオブジェクトの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の方INFO-SPECオブジェクトを運ばなければなりません。応答メッセージがQNIまで無条件に転送する必要があります。 INFO-SPECオブジェクトを受け取りQNIによって行われるべきアクションは、このQNEでサポートされるQoSモデルのローカルポリシーで指定されています。デフォルトのアクションは、INFO-SPECオブジェクトを受け取りQNIが、他のQoS NSLP手順をトリガはならないことです。
The Informational INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when an Informational error class is caught. The Informational INFO-SPEC object MUST be carried by a RESPONSE or a NOTIFY message.
情報のエラークラスがキャッチされたときに情報INFO-SPECクラスは、ステートフルなQoS NSLPのQNEによって生成されなければなりません。情報INFO-SPECオブジェクトは、応答またはNOTIFYメッセージによって運ばれなければなりません。
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.
RESERVEメッセージを受信し、予約状態のインストールや更新が成功した場合に一方向の予約の場合には、成功INFO-SPECクラスは、ステートフルなQoS NSLP QNRによって生成されなければなりません。 RESERVEメッセージを受信し、予約状態のインストールや更新が成功した場合、双方向予約の場合には、INFO-SPECオブジェクトは、ステートフルなQoS NSLP QNEによって生成されるべきです。成功INFO-SPECオブジェクトは、応答またはNOTIFYメッセージによって運ばれなければなりません。
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.
RESERVEまたはQUERYメッセージがQNEによって受信され、プロトコルエラーが捕捉されたときに一方向予約の場合に、プロトコルエラーINFO-SPECクラスは、ステートフルなQoS NSLP QNEによって生成されなければなりません。 RESERVEまたはQUERYメッセージがQNEによって受信され、プロトコルエラーが捕捉されたときに、双方向予約の場合に、プロトコルエラーINFO-SPECクラスは、ステートフルなQoS NSLP QNEによって生成されるべきです。応答メッセージは、このINFO-SPECオブジェクトの生成をトリガRESERVEまたはQUERYメッセージを生成し、上流QNE向かって無条件に転送する必要があり、このオブジェクトを運ばなければなりません。このようなエラーを検出するステートレスなQoS NSLPのQNEのデフォルトアクションは、QoS NSLPオブジェクトのどれが処理されるべきではない、とRESERVEまたはQUERYメッセージを下流に転送されるべきであることです。
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.
RESERVEまたはQUERYメッセージがQNEによって受信され、1つの一時的な障害エラーコードがキャッチ、またはイベントがその原因が発生したときにされたときに一方向予約の場合には、一時的な障害INFO-SPECクラスは、ステートフルなQoS NSLP QNEによって生成されなければなりません一時的なエラー。 RESERVEまたはQUERYメッセージがQNEによって受信され、1つの一時的な障害エラーコードが捕捉されたときに、双方向予約の場合には、一時的な障害INFO-SPECクラスは、ステートフルなQoS NSLP QNEによって生成されるべきです。
A RESPONSE message MUST carry this object, which MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered the generation of this INFO-SPEC object. The transient RMF-related error MAY also be carried by a NOTIFY message. The default action is that the QNE that receives this INFO-SPEC object SHOULD re-trigger the retransmission of the RESERVE or QUERY message that triggered the generation of the INFO-SPEC object. The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message SHOULD be forwarded downstream.
応答メッセージは、このINFO-SPECオブジェクトの生成をトリガRESERVEまたはQUERYメッセージを生成し、上流QNE向かって無条件に転送する必要があり、このオブジェクトを運ばなければなりません。過渡RMF-関連のエラーは、NOTIFYメッセージによって行うことができます。デフォルトのアクションは、このINFO-SPECオブジェクトを受信QNE再トリガーすることRESERVEまたはINFO-SPECオブジェクトの生成をトリガQUERYメッセージの再送信です。このようなエラーを検出するステートレスなQoS NSLPのQNEのデフォルトアクションは、QoS NSLPオブジェクトのどれが処理されるべきではないとRESERVEまたはQUERYメッセージを下流に転送されるべきことです。
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.
RESERVEまたはQUERYメッセージがQNEによって受信され、内部またはシステムエラーが発生し、または認証が失敗した場合、単方向予約の場合には、永続的なエラーINFO-SPECクラスは、ステートフルなQoS NSLPのQNEによって生成されなければなりません。 RESERVEまたはQUERYメッセージがQNEによって受信され、内部またはシステムエラーが発生し、または認証が失敗した場合、双方向予約の場合には、永続的なエラーINFO-SPECクラスは、ステートフルなQoS NSLPのQNEによって生成されるべきです。応答メッセージは、このプロトコルエラーを引き起こしRESERVEまたはクエリメッセージを生成し、上流QNE向かって無条件に転送する必要があり、このオブジェクトを運ばなければなりません。内部、システム、または永久RMF関連のエラーもNOTIFYメッセージによって実施することができます。このようなエラーを検出するステートレスなQoS NSLPのQNEのデフォルトアクションは、QoS NSLPオブジェクトのどれが処理されるべきではないとRESERVEまたはQUERYメッセージを下流に転送されるべきことです。
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 NSLP自体外部エラーは、使用される特定のQoSモデルに関連していることが発生した場合の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.
SESSION-ID-LISTはRESERVEメッセージで運ばれます。リフレッシュしたり、指示セッションを取り壊すために、2つのケースで使用されています。セッションID-LISTは、リフレッシュまたはRESERVEに示される主（プライマリ）セッションに加えて、解体されるべきセッションに関する情報を搬送します。
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.
それは、1つ以上の未知のセッションID値を見つけた場合、ステートフルQNEは、セッションID-LISTを通過するとき、それはセッション - 未知SESSION-IDに対するエラーコードで上流ステートフルQNEに戻す情報応答メッセージを構築すべきですID-LIST、およびSESSION-ID-LIST内のすべての未知SESSION-IDが含まれています。
If the RESERVE is a tear, for each session in the SESSION-ID-LIST, the stateful QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST also be interpreted in order to distinguish whether the tear down is valid, or whether it is referring to an old state, and, thus, should be silently discarded.
RESERVEは涙がある場合は、SESSION-ID-LISTの各セッションのために、ステートフルQNEは予約がもはや必要とされていることをRMFを知らせてはなりません。 RSN値も涙ダウンが有効であるかどうかを区別するために解釈されなければならない、またはそれが古い状態に言及され、そして、このように、静かに捨てられるべきかどうか。
If the RESERVE is a refresh, the stateful QNE MUST also process the RSN-LIST object as detailed in the next section.
RESERVEがリフレッシュされた場合は、次の節で詳述されるように、ステートフルQNEはまた、RSN-LISTオブジェクトを処理しなければなりません。
If the RESERVE is a tear, for each session in the SESSION-ID-LIST, the QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST be interpreted.
RESERVEは涙がある場合は、SESSION-ID-LISTの各セッションのために、QNEは予約がもはや必要とされていることをRMFを知らせてはなりません。 RSN値は解釈されなければなりません。
Note that a stateless QNE cannot support summary or single reduced refreshes, and always needs full single refreshes.
ステートレスQNEは、要約または単一減少リフレッシュをサポートできないことに注意してください、と常に完全な単一リフレッシュを必要とします。
An RSN-LIST MUST be carried in RESERVE messages when a QNE wants to perform a refresh or teardown of several sessions with a single NSLP message. The RSN-LIST object MUST be populated with RSN values of the same sessions and in the same order as indicated in the SESSION-ID-LIST. Thus, entries in both objects at position X refer to the same session.
QNEは、単一のNSLPメッセージを持ついくつかのセッションのリフレッシュやティアダウンを実行したい場合RSN-LISTはRESERVEメッセージで運ばなければなりません。 RSNリストオブジェクトは、同じセッションのRSN値とし、セッションID-LISTに示すように同じ順序で読み込まなければなりません。したがって、位置Xにおける両方のオブジェクトのエントリが同じセッションを指します。
If the primary session and RSN reference in the RESERVE were not understood, the stateful QNE MUST NOT process the RSN-LIST. Instead, an error RESPONSE SHOULD be sent back to the upstream stateful QNE.
RESERVEの主なセッションとRSN参照が理解されなかった場合は、ステートフルQNEはRSN-LISTを処理してはいけません。代わりに、エラー応答が上流ステートフルQNEに戻って送ってください。
On receiving an RSN-LIST object, the stateful QNE should check whether the number of items in the SESSION-ID-LIST and RSN-LIST objects match. If there is a mismatch, the stateful QNE SHOULD send back a protocol error indicating a bad value in the object.
RSN-LISTオブジェクトを受信すると、ステートフルQNEは、セッションID-LISTおよび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.
セッションID-LIST値にRSN-LIST値に一致しながら、RSN-LIST内の1つまたは複数のRSN値がローカル値と同期していない場合、ステートフルQNEでのエラーコードを示す通知応答メッセージを構築すべきですRSN-LISTでRSNのミスマッチ。ステートフルQNEは、応答して、セッションID-LISTおよびRSN-LISTオブジェクトにおける誤SESSION-ID及びRSNの値を含まなければなりません。
If no errors were found in processing the RSN-LIST, the stateful QNE refreshes the reservation states of all sessions -- the primary single session indicated in the refresh, and all sessions in the SESSION-ID-LIST.
リフレッシュに示されている主なシングルセッション、およびSESSION-ID-LIST内のすべてのセッション - エラーがRSN-LISTを処理中に発見されなかった場合は、ステートフルQNEは、すべてのセッションの予約状態を更新します。
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.
RESERVEの各正常に処理されたセッションのために、ステートフルQNEは、予約状態のリフレッシュを行います。このように、いくつかのセッションが同期していなかった場合でも、SESSION-ID-LISTおよびRSN-LISTの残りのセッションが更新されます。
The contents of the QSPEC depend on the QoS model being used. A template for QSPEC objects can be found in [RFC5975].
QSPECの内容が使用されているQoSモデルによって異なります。 QSPECオブジェクトのテンプレートは、[RFC5975]に見出すことができます。
Upon reception, the complete QSPEC is passed to the Resource Management Function (RMF), along with other information from the message necessary for the RMF processing. A QNE may also receive an INFO-SPEC that includes a partial or full QSPEC. This will also be passed to the RMF.
受信すると、完全QSPECはRMF処理に必要なメッセージからの他の情報と共に、リソース管理機能（RMF）に渡されます。 QNEはまた、部分的または完全なQSPECを含むINFO-SPECを受信することができます。また、これは、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は、それが隣接QNEsの状態に矛盾があることを知ってもらうために、バック近隣QNEに適切なエラーメッセージを送信することができます。
The RESERVE message is used to manipulate QoS reservation state in QNEs. A RESERVE message may create, refresh, modify, or remove such state. A QNE sending a RESERVE MAY require a response to be sent by including a Request Identification Information (RII) object; see Section 5.3.2.
RESERVEメッセージはQNEsにQoS予約状態を操作するために使用されます。 RESERVEメッセージを作成、更新、変更、またはそのような状態を除去することができます。 RESERVEを送信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.
RESERVEメッセージはQNRに向けて送らなければなりません。 RESERVEメッセージを受信したQNEは、メッセージ形式を確認します。不正な形式のメッセージの場合には、QNEは、適切なINFO-SPEC応答メッセージを送信することができます。
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:
RESERVEが許可されると、QNEはCOMMON-HEADERフラグをチェックします。 TEARフラグが設定されている場合、メッセージは、（ゼロリソースの予約とは対照的に）完全なQoS NSLP状態の除去を示す引裂RESERVEあります。このようRESERVEメッセージを受信すると、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.引き裂きRESERVEはRIIが含まれていなかった場合、すなわち、QNIはQNEは、QoS NSLP状態を削除する必要があり、確認をしたくありませんでした。これは、この予約のためにそのリバースパスの状態がもはや必要とされる（APIを介して）GISTに合図するかもしれません。引き裂きRESERVEを処理中にエラーは、すでに彼らのセッション状態を削除しているだろう上流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.
RIIが含まれていた場合は2、ステートフルQNEはまだQNIが受信された方に行く涙の応答までNSLP動作状態を維持する必要があります。この動作状態は、セッションのためのNSLP動作状態が除去された後、1つのリフレッシュ間隔、のために保たれるべきです。 QoSモデルによっては、涙のメッセージは、さらに状態の除去を指定するQSPECを含むかもしれません。 QoSモデルはQSPECを必要とし、何も提供されていない場合、QNEは、エラーメッセージで応答すべきであり、予約を削除しないでください。
If the tearing RESERVE includes a QSPEC, but none is required by the QoS model, the QNE MAY silently discard the QSPEC and proceed as if it did not exist in the message. In general, a QoS NSLP implementation should carefully consider when an error message should be sent, and when not. If the tearing RESERVE did not include an RII, then the upstream QNE has removed the RMF and NSLP states, and it will not be able to do anything to the error. If an RII was included, the upstream QNE may still have the NSLP operational state, but no RMF state.
引き裂きRESERVEはQSPECが含まれていますが、なにもQoSモデルによって必要とされていない場合、QNEは黙っQSPECを破棄し、それがメッセージ内に存在しなかったかのように進めることができます。一般的には、QoSのNSLPの実装は慎重にエラーメッセージが送信され、ないときはしなければならない時に検討すべきです。引き裂きRESERVEは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状態が除去されたため、セッションの引き裂きRESERVEを受信した場合、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.
引き裂きRESERVEは、セッションID-LISTを含む場合は、この文書で先に説明したように、ステートフルQNEは、オブジェクトを処理しなければならない、と識別された各セッションのために、予約がもはや必要とされていることをRMFに示しません。
If a QNE receives a refreshing RESERVE for a session for which it still has the operational state, but the RMF state was removed, the QNE MUST silently drop the message and not forward it downstream.
QNEが、それはまだ動作状態を持っているセッションのさわやかRESERVEを受け取りますが、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で論じたように、再ルーティングイベント後の状態の誤削除を避けるために、TEARフラグセットを有しており、それが（そのSIIによって識別される）現在のピアQNEから来ないRESERVEメッセージを受信したノードは無視されなければなりませんそして転送されてはなりません。
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がバインドされ、このセッションに依存している予約を持っている場合は（彼らはBOUND-SESSION-IDのオブジェクトでこのセッションのセッションIDが含まれているとコード0x04のバインディングを使用）、それが持つ予約ごとにNOTIFYメッセージを送らなければなりません適切なINFO-SPEC。 QNEがバインドされている予約を持っていますが、彼らはこのセッションに依存しないことをした場合（BOUND-SESSION-IDにバインディングコードをオブジェクトが値のいずれかを持っていますが0x01、0x02の、または0x03の）、それはNOTIFYメッセージを送信することができます適切なINFO-SPECでの予約のそれぞれについて。 QNEは、これらの予約のために設定されTEARフラグでRESERVEメッセージを送信するために選ぶことができます。
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).
RESERVEを受信した場合、それはすでに状態がインストールされているためSESSION-IDとが異なるフローIDとRESERVEを受け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.
ゼロに設定REPLACEフラグと同じSIIは（それがリソースの処理に使用される）RMFに= 0をREPLACE示すことになるで予約を受け付けるQNE。 QNEは、QoS NSLP状態を維持している場合さらに、それはまたのQoS NSLP状態で新しいフローIDを追加します。 SIIが異なる場合、これはQNEは合流点であることを意味しています。その場合には、上記指定された操作に加えて、値= 0も引き裂きRESERVE古い分岐上で送信すべきでないことを示しているREPLACE。
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とRESERVEメッセージを受信し、このメッセージは、それがリフレッシュように意図されたので、何QSPECが含まれていない場合、ノードは、上流のピアに欠けQSPECを（示しINFO-SPEC応答メッセージを送らなければなりません） "フルQSPECが必要"。上流のピアは、新しいパス（新しいSII）に完全RESERVE（QSPECを含む、すなわち、1）を送信すべきです。
At a QNE, resource handling is performed by the RMF. For sessions with the REPLACE flag set to zero, we assume that the QoS model includes directions to deal with resource sharing. This may include adding the reservations or taking the maximum of the two or more complex mathematical operations.
QNEでは、資源の取り扱いはRMFによって行われます。ゼロに設定REPLACEフラグを持つセッションでは、我々は、QoSモデルは、リソースの共有に対処するための指示が含まれていることを前提としています。これは、予約を追加または二つ以上の複雑な数学的演算の最大値をとる含むことができます。
This resource-handling mechanism in the QoS model is also applicable to sessions that have different SESSION-IDs but that are related through the BOUND-SESSION-ID object. Session replacement is not an issue here, but the QoS model may specify whether or not to let the sessions that are bound together share resources on common links.
QoSモデルでこのリソース処理のメカニズムもBOUND-SESSION-IDのオブジェクトを介して関連している異なるSESSION-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.
最後に、RESERVEはまったくQSPECで受信することも可能です。これは、減少リフレッシュの場合です。この場合、むしろフルQSPECとさわやかRESERVEを送信するよりも、唯一SESSION-IDおよびRSNは、予約をリフレッシュするために送信されます。このメカニズムは、単にメッセージのサイズを減少させ（そしておそらく処理が容易になります）ことに注意してください。セッションごとにRESERVEがまだ必要とされています。さらに、さらにセッションを示すセッションID-LISTおよびRSN-LISTを含むことができるそのような減少リフレッシュがプライマリセッションに沿ってリフレッシュします。これらのオブジェクトの処理は、この資料で先に説明しました。
If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC contained in the message (if the QSPEC is missing, the QNE SHOULD indicate this error by replying with a RESPONSE containing the corresponding INFO-SPEC "Full QSPEC required"). It MUST update the lifetime of the reservation. If the REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation state if the SII that is passed by GIST over the API is different than the SII that was stored for this reservation. The QNE MAY elect to keep sending refreshing RESERVE messages.
REPLACEフラグが設定されている場合、QNEはQSPECがない場合、QNEは、対応するINFO-SPECを含むRESPONSEで応答することにより、このエラーを示すべきである（メッセージに含まQSPECに係る予約状態を更新する必要が「フルQSPECが必要「）。これは、予約の有効期間を更新する必要があります。 REPLACEフラグが設定されていない場合は、APIを介しGISTで渡されるSIIは、この予約のために保存したSIIと異なる場合、QNEは古い予約状態を削除しないでください。 QNEはさわやかRESERVEメッセージを送り続けることを選ぶことができます。
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はBREAKフラグが設定されたRESERVEメッセージを受信した場合、その後、新たに生成されたメッセージ（例えば、RESERVEまたはRESPONSE）のBREAKフラグを設定しなければなりません。ステートフルなQoS NSLP QNEが設定されていないBREAKフラグをRESERVEメッセージを受信すると、次にIP-TTLおよびGIST RecvMessageにおけるオリジナル-TTL値プリミティブを監視しなければなりません。それらが異なる場合には、新たに生成されたメッセージ（例えば、RESERVEまたはRESPONSE）でBREAKフラグを設定することが推奨されます。 QNEまたはドメインは、他の手段（セクション3.3.5を参照）を使用してQoSを提供することができる状況では、BREAKフラグを設定しないでください。
If the RESERVE message included an RII, and any of the following are true, the QNE MUST send a RESPONSE message:
RESERVEメッセージは、RIIを含めて、次のいずれかに該当する場合、QNEは、応答メッセージを送らなければなりません。
o If the QNE is configured, for a particular session, to be a QNR,
QNEが設定されている場合は、O、特定のセッションのために、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はRESERVEメッセージを受信した場合、その処理は、別のRESERVEメッセージを送信することを含むことができます。
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).
このメッセージのセッションが別のセッションにバインドされている場合、RESERVEメッセージはBOUND-SESSION-IDのオブジェクトに他のセッションのセッションIDを含まなければなりません。集約されたトンネルのような状況では、集約セッションはBOUND-SESSION-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].
受信機が開始した予約の場合には、RESERVEメッセージは、クエリメッセージに続くされた同じパスに従わなければなりません。したがって、GISTは、GIST、「D」フラグを設定することによって、すなわち、上流のメッセージを渡すと、QoS NSLP / GISTのAPIの上に、通知されます。 GIST [RFC5971]を参照してください。
The QNE MUST create a new RESERVE and send it to its next peer, when:
QNEは新しいRESERVEを作成し、その次のピアにそれを送らなければなりません。
- 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はまだRESERVEが伝播しなければならないことを規定し、
- The RESERVE is a refresh and includes a new MRI, or
- RESERVEは、リフレッシュされ、新しいMRIを含み、または
- If the RESERVE-INIT flag is included in an arrived QUERY.
- RESERVE-INITフラグが到着したクエリに含まれている場合。
If the QNE sent out a refresh RESERVE with the ACK-REQ flag set, and did not receive a RESPONSE from its immediate stateful peer within the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a NOTIFY to its immediate upstream stateful peer and indicate "Path truncated - Next peer dead" in the INFO-SPEC. The ACK-REQ flag SHOULD NOT be added to a RESERVE that already include an RII object, since a confirmation from the QNR has already been requested.
QNEはACK-REQフラグが設定されたリフレッシュRESERVEを送って、QOSNSLP_RETRY_MAXの再送期間内にその直接のステートフルピアから応答を受信しなかった場合、QNEは、そのすぐ上流のステートフルピアにNOTIFY送るべきであると「パスを示しています切り捨て - INFO-SPECの次のピア死にました」。 QNRから確認が既に要求されているので、ACK-REQフラグは、既にRIIオブジェクトを含むRESERVEに追加しないでください。
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.
受信RESERVEは、共通ヘッダフラグにACK-REQフラグを介して確認応答を要求し、メッセージの処理が成功した場合、最終的に、ステートフルQNEは、INFO-SPEC肯定応答成功コードを運ぶと共に応答を送り返すべきです。 QNEは、それがセッションのために送信されます、次のリフレッシュメッセージでのACK-REQフラグを含むかもしれません。診断目的のためにACK-REQフラグの使用は、ポリシーの問題です。認めリフレッシュメッセージは、それが無傷のままであることを確認するために、エンド・ツー・エンドのパスをプローブするために使用することができます。
A QUERY message is used to request information about the data path without making a reservation. This functionality can be used to 'probe' the network for path characteristics or for support of certain QoS models, or to initiate a receiver-initiated reservation.
QUERYメッセージは、予約を行うことなく、データ経路に関する情報を要求するために使用されます。この機能は、パス特性のために、または特定のQoSモデルをサポートするためのネットワーク「プローブ」を使用することができ、または受信機が開始予約を開始します。
A QNE sending a QUERY indicates a request for a response by including a Request Identification Information (RII) object; see Section 5.3.2. A request to initiate a receiver-initiated reservation is done through the RESERVE-INIT flag; see Section 5.1.2.2.
クエリを送信QNEは、要求識別情報（RII）オブジェクトを含むことによって、応答するための要求を示します。 5.3.2項を参照してください。受信機が開始した予約を開始する要求がRESERVE-INITフラグを介して行われます。セクション5.1.2.2を参照してください。
When a QNE receives a QUERY message the QSPEC is passed to the RMF for processing. The RMF may return a modified QSPEC that is used in any QUERY or RESPONSE message sent out as a result of the QUERY processing.
QNEがクエリメッセージを受信した場合QSPECは、処理のためにRMFに渡されます。 RMFは、クエリ処理の結果として送出される任意のクエリや応答メッセージで使用されている修飾QSPECを返すことができます。
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.
QUERYメッセージを処理するとき、QNEチェックはRESERVE-INITフラグが設定されているかどうか。フラグが設定されている場合、クエリは逆の経路状態をインストールするために使用されます。 QNEがQNIでない場合は、この場合には、それが下流に送信するための新しいQUERYメッセージを作成します。 QSPECは、それは、QoSモデル固有クエリ処理によって修正されてもよいRMFに渡さなければなりません。 QNEがQNIであれば、QNEはQSPECが受信QSPECに基づくことができるRMFから受信含まRESERVEメッセージを作成します。このノードは、受信器で開始予約を実行するために期待していなかった場合、エラーが経路に沿って送り返されなければなりません。
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,
QNEは、QNRであるO
o the SCOPING flag is set, or
スコーピングフラグが設定されている、O、又は
o the PROXY scope flag is set, and the QNE is a P-QNE.
O PROXY範囲フラグが設定され、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は、応答メッセージを生成し、逆方向に沿って戻ってそれを渡す必要がありますQUERYで使用されるパスの。
In other cases, the QNE MUST generate a QUERY message that is then forwarded further along the path using the same MRI, Session ID, and Direction as provided when the QUERY was received over the GIST API.
他の場合において、QNEは、クエリがGISTのAPIを介して受信したときに提供されるように、同じMRI、セッションID、および方向を使用して、経路に沿ってさらに転送されるクエリメッセージを生成しなければなりません。
The QSPEC to be used is that provided by the RMF as described previously. When generating a QUERY to send out to pass the query further along the path, the QNE MUST copy the RII object (if present) unchanged into the new QUERY message. A QNE that is also interested in the response to the query keeps track of the RII to identify the RESPONSE when it passes through it.
使用するQSPECは、前述のようにRMFにより提供されることです。経路に沿ってさらにクエリを渡すために送出するためのクエリを生成するとき、QNEは新しいクエリメッセージに不変RIIオブジェクト（存在する場合）をコピーする必要があります。また、クエリに対する応答に興味があるQNEはそれを通過するときの応答を識別するために、RIIを追跡します。
Note that QUERY messages with the RESERVE-INIT flag set MUST be answered by the QNR. This feature may be used, e.g., following handovers, to set up new path state in GIST and to request that the other party to send a RESERVE back on this new GIST path.
QNRで答えなければならないRESERVE-INITフラグが設定されているQUERYメッセージに注意してください。この機能は、例えば、ハンドオーバ以下、GISTに新しいパスの状態を設定すると、他の当事者は、この新しいGISTパスに戻ってRESERVEを送信することを要求するために、使用することができます。
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はRESERVE-INITフラグとBREAKフラグが設定されたQUERYメッセージを受信した場合、その後、新たに生成されたメッセージのBREAKフラグが（例えば、QUERY、RESERVE、または応答）を設定しなければなりません。ステートフルなQoS NSLP QNEが設定されていないRESERVE-INITフラグセットとBREAKフラグをQUERYメッセージを受信すると、次にIP-TTLおよびGIST RecvMessageにおけるオリジナル-TTL値がプリミティブを監視しなければなりません。それらが異なる場合は、新しく生成されたメッセージ（例えば、QUERY、RESERVE、またはRESPONSE）でBREAKフラグを設定することが推奨されます。 QNEまたはドメインは、他の手段（セクション3.3.5を参照）を使用してQoSを提供することができる状況では、BREAKフラグを設定しないでください。
Finally, if a received QUERY requested acknowledgement through the ACK-REQ flag in the COMMON HEADER flags and the processing of the message was successful, the stateful QNE SHOULD send back a RESPONSE with an INFO-SPEC carrying the acknowledgement success code.
最後に、受信したクエリは、共通ヘッダフラグにACK-REQフラグを介して確認応答を要求し、メッセージの処理が成功した場合は、ステートフルQNEは、INFO-SPEC肯定応答成功コードを運ぶと共に応答を送り返すべきです。
The RESPONSE message is used to provide information about the result of a previous QoS NSLP message, e.g., confirmation of a reservation or information resulting from a QUERY. The RESPONSE message does not cause any state to be installed, but may cause state(s) to be modified, e.g., if the RESPONSE contains information about an error.
RESPONSEメッセージが以前のQoS NSLPメッセージの結果に関する情報を提供するために使用され、例えば、QUERY起因予約や情報の確認。応答メッセージは、任意の状態がインストールされませんが、レスポンスがエラーに関する情報が含まれている場合に状態（単数または複数）は、例えば、改変させることができます。
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はQNEがスコープRESERVEまたはスコープクエリを受信した場合RIIオブジェクトを含むか、RESERVEまたはクエリメッセージを処理するときに応答メッセージが送信されなければなりません。この場合、応答メッセージはRESERVEまたはクエリからコピーされた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は、そのシグナリングセッションのための優れた応答要求にそれを照合しなければなりません。マッチが成功した場合、情報や成功INFO-SPECクラスが含まれている場合、レスポンスは、パスに沿ってさらに転送されてはなりません。 QNEはこのRII自体を挿入しなかった場合、それは次のピアへの応答を転送する必要があります。 QNEは、単独でRIIを挿入した場合従って、成功を示す応答するため、転送のみ停止する必要があります。応答がエラーを示すINFO-SPECを搬送する場合、転送は、次の段落で説明したようにとれたRSNを用いて、上流QNIに向かって継続する必要があります。
On receipt of a RESPONSE message containing an RSN object, a stateful QoS NSLP QNE MUST compare the RSN to that of the appropriate signaling session. If the match succeeds, then the INFO-SPEC MUST be processed. If the INFO-SPEC object is used to send error notifications then the node MUST use the stored upstream peer RSN value, associated with the same session, and forward the RESPONSE message further along the path towards the QNI.
RSNオブジェクトを含む応答メッセージを受信すると、ステートフルなQoS NSLP QNEは、適切なシグナリングセッションのものにRSNを比較しなければなりません。マッチが成功した場合、INFO-SPECを処理しなければなりません。 INFO-SPECオブジェクトはエラー通知を送信するために使用される場合、ノードは、同じセッションに関連付けられた格納された上流のピアRSN値を使用する必要があり、そしてQNI向かって経路に沿って、さらに応答メッセージを転送します。
If the INFO-SPEC is not used to notify error situations (see above), then if the RESPONSE message carries an RSN, the message MUST NOT be forwarded further along the path.
INFO-SPEC（上記参照）エラー状況を通知するために使用されていない場合、応答メッセージがRSNを運ぶ場合、次いで、メッセージは、パスに沿ってさらに転送されてはいけません。
If there is no match for RSN, the message SHOULD be silently dropped.
RSNのために一致しない場合、メッセージは静かに落とされるべきです。
On receipt of a RESPONSE message containing neither an RII nor an RSN object, the RESPONSE MUST NOT be forwarded further along the path.
RIIもRSNオブジェクトもを含む応答メッセージを受信すると、応答は、経路に沿ってさらに転送されてはいけません。
In the typical case, RESPONSE messages do not change the states installed in intermediate QNEs. However, depending on the QoS model, there may be situations where states are affected, e.g.,
典型的なケースでは、応答メッセージは、中間QNEsにインストール状態を変更しないでください。しかし、QoSモデルに応じて、例えば、状態が影響を受けている状況があり得ます、
- if the RESPONSE includes an INFO-SPEC describing an error situation resulting in reservations to be removed, or
- 応答は、予約を生じるエラー状況を説明INFO-SPECを含む除去する場合、または
- 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を定義することができ[分、最大]要求されたリソースの制限、及び下流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はBREAKフラグが設定された応答メッセージを受信した場合、その後、新たに生成されたメッセージ（例えば、応答）のBREAKフラグを設定しなければなりません。
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).
NOTIFYメッセージは非同期QNEに情報を伝えるために使用されています。 NOTIFYメッセージは、いずれかの状態がインストールされることはありません。状態を除去するための決定は、QoSモデルに依存します。正確な操作は、QoSモデルに依存します。 NOTIFYメッセージは、直接、他のメッセージを送信することはありません。 NOTIFYメッセージではなく、他のメッセージに応答するよりも、非同期的に送信されます。彼らは、（上流または下流）のいずれかの方向に送信されてもよいです。
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はRESERVEに適切なフラグを設定することにより、減少リフレッシュを使用するように要求されたときに通知同期の特別な場合です。そのようなRESERVEを受信QNEはNOTIFYとQNE上流QNEの間に減少リフレッシュを使用することに同意するかどうかを示す適切なINFO-SPECコードを返信しなければなりません。
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を用いTEARフラグのセットで予約を送信することによってプリエンプト予約を取り壊すことになります。しかし、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メッセージタイプ - のQoS NSLPバインディングコード - のQoS NSLPエラークラス - 情報エラーコード - 成功のエラーコード - プロトコルエラーコード - 過渡障害コード - 永久障害コード - のQoS NSLPエラーソース識別子
IANA has also registered new values in a number of registries:
IANAはまた、レジストリの数に新しい値を登録しています：
- NSLP Object Types - NSLP Identifiers (under GIST Parameters) - Router Alert Option Values (IPv4 and IPv6)
- NSLPオブジェクトタイプ - （GISTパラメータ下）NSLP識別子 - ルータアラートオプション値（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メッセージタイプを定義：RESERVE（0×01）、QUERY（0×02）、応答（0×03）、及び（0×04）NOTIFY。
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メッセージオブジェクトのために作成されています。これは、（0から4095までの値を与える）12ビットのフィールドです。このレジストリはNSLPsの数の間で共有されています。
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メッセージオブジェクトを定義します。 RII（0x001）、RSN（0x002）、リフレッシュ期間（0x003）、結合-SESSION-ID（0x004）、パケットCLASSIFIER（0x005）、INFO-SPEC（0x006）、セッション：これらは、セクション5.1.3に記載されています。 -ID-LIST（0x007）、RSN-LIST（0x008と）、MSG-ID（0x009）、結合-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.
新しいレジストリは、結合-SESSION-IDのオブジェクトに使用される8ビットの結合コードのために作成されています。このレジストリの初期値は、セクション5.1.3.4に記載されています。
The registration procedure is IETF Review. Value 0 is reserved. Values 128 to 159 are for Experimental/Private Use. Other values are Reserved.
登録手続きは、IETFレビューです。値0は予約されています。値128 159に実験的/私的使用のためです。その他の値は予約されています。
In addition, Error Classes and Error Codes for the INFO-SPEC object are defined. These are described in Section 5.1.3.6.
また、INFO-SPECオブジェクトのエラー・クラスとエラーコードが定義されています。これらは、セクション5.1.3.6で説明されています。
The Error Class is 4 bits in length. The initial values are:
エラークラスは、長さが4ビットです。初期値は次のとおりです。
0: Reserved
0：予約済み
1: Informational
1：情報
2: Success
2：成功
3: Protocol Error
3：プロトコルエラー
4: Transient Failure
4：一時的な障害
5: Permanent Failure
5：永続的なエラー
6: QoS Model Error
6：QoSのモデル誤差
7: Signaling session failure (described in [RFC5973])
7：（[RFC5973]に記載されている）セッションの失敗をシグナリング
8-15: Reserved
8-15：予約済み
Additional values are to be assigned based on IETF Review.
追加の値はIETFレビューに基づいて割り当てられます。
The Error Code is 8 bits in length. Each Error Code is assigned within a particular Error Class. This requires the creation of a registry for Error Codes in each Error Class. The Error Code 0 in each class is Reserved.
エラーコードは、長さが8ビットです。各エラーコードは、特定のエラークラスの中に割り当てられます。これは、各エラークラスのエラーコードのためのレジストリを作成する必要があります。各クラスのエラーコード0は予約されています。
Policies for the error code registries are as follows:
次のようにエラーコードレジストリの方針は以下のとおりです。
0-63: IETF Review
0-63：IETFレビュー
64-127: Specification Required
64-127：仕様が必要
128-191: Experimental/Private Use
128から191：実験/私用
192-255: Reserved
192から255：予約済み
The initial assignments for the Error Code registries are given in Section 5.1.3.6. Experimental and Reserved values are relevant to all Error classes.
エラーコードレジストリの初期割り当ては、セクション5.1.3.6に示されています。実験と予約値は、すべてのエラー・クラスに関連しています。
Section 5.1.3.6 defines Error Source Identifiers, the type of which is identified by a 4-bit value.
セクション5.1.3.6エラーソース識別子、4ビットの値によって識別されたタイプを定義します。
The value 0 is reserved.
値0は予約されています。
Values 1-3 are given in Section 5.1.3.6.
値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によって要求されるように、32のNSLPID値は、QoS NSLP集約レベル0〜31に対応し、割り当てられています。
The GIST specification also requires that NSLPIDs be associated with specific Router Alert Option (RAO) values (although multiple NSLPIDs may be associated with the same value). For the purposes of the QoS NSLP, each of its NSLPID values should be associated with a different RAO value. A block of 32 new IPv4 RAO values and a block of 32 new IPv6 RAO values have been assigned, corresponding to QoS NSLP Aggregation Levels 0 to 31.
GISTの仕様もNSLPIDsが特定のルータ警告オプション（RAO）の値（複数NSLPIDsが同じ値に関連付けてもよい）に関連付けられることを要求します。 QoS NSLPの目的のために、そのNSLPID値の各々は、異なるRAO値に関連付けられるべきです。 32の新規のIPv4 RAO値のブロックと32の新規のIPv6 RAO値のブロックは、QoS NSLP集約レベル0〜31に対応し、割り当てられています。
The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats. For the signaling problem as a whole, these threats have been outlined in NSIS threats [RFC4081]; the NSIS framework [RFC4080] assigns a subset of the responsibility to GIST, and the remaining threats need to be addressed by NSLPs. The main issues to be handled can be summarized as:
QoSのNSLPのためのセキュリティ要件は、識別されたセキュリティの脅威に対するQoS予約を確立するためのシグナリング交換を保護することです。全体として、シグナリング問題のために、これらの脅威はNSISの脅威[RFC4081]に概説されています。 NSISフレームワーク[RFC4080]はGISTに対して責任の一部を割り当て、残りの脅威がNSLPsによって対処する必要があります。処理される主な問題点は、次のように要約することができます。
Authorization:
認証：
The QoS NSLP must assure that the network is protected against theft-of-service by offering mechanisms to authorize the QoS reservation requester. A user requesting a QoS reservation might want proper resource accounting and protection against spoofing and other security vulnerabilities that lead to denial of service and financial loss. In many cases, authorization is based on the authenticated identity. The authorization solution must provide guarantees that replay attacks are either not possible or limited to a certain extent. Authorization can also be based on traits that enable the user to remain anonymous. Support for user identity confidentiality can be accomplished.
QoSのNSLPは、ネットワークがQoS予約要求者を認証する仕組みを提供することで、サービスの窃盗から保護されていることを保証しなければなりません。 QoS予約を要求しているユーザーには、サービスおよび金融損失の否定につながる適切なリソースアカウンティングやなりすましなどのセキュリティの脆弱性に対する保護をお勧めします。多くの場合、認可は認証された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や基本的なセキュリティ・メカニズムによって提供されるセキュリティを超えた場合は、このドキュメントで説明する追加のセキュリティ・メカニズムを使用する必要があります。原因NSISが使用されているさまざまな使用環境やシナリオには、その柔軟性を低下させることなく、一般的な文を作ることは非常に困難です。
This specification is based on a model that requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path. The model is simple to deploy, was used in previous QoS authorization environments (such as RSVP), and seems to provide sufficiently strong security properties. We refer to this model as the New Jersey Turnpike.
この仕様は、シグナリングパスのQoSに沿ってチェーンの信頼を確立するために、隣接NSLPノード間の信頼関係を必要とするモデルに基づいています。モデルは導入が簡単である（例えば、RSVPなど）前回のQoS認証環境で使用され、十分に強力なセキュリティ特性を提供するように思われました。私たちは、ニュージャージー・ターンパイクのように、このモデルを参照してください。
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シグナリングを保護することができるようになります。認証及び鍵確立フェーズの間に使用される同一ネットワークXによって使用される、いわゆるポリシーベースのアドミッション制御手順を実行する（図16参照）。私たちの文脈では、このユーザ識別子は、認可と充電を提供するために必要なインフラを確立するために使用されるだろう。シグナリングメッセージは、後にも、認証と承認の対象となり、異なるネットワーク間で交換しました。ただし、認証されたエンティティは、それによって、隣接ネットワークとしないエンドホストです。
The New Jersey Turnpike model is attractive because of its simplicity. S. Shenker, et al. [shenker] discuss various accounting implications and introduced the edge pricing model. The edge pricing model shows similarity to the model described in this section, with the exception that mobility and the security implications are not addressed.
ニュージャージーターンパイクモデルは、そのシンプルさの魅力です。 S. Shenker、ら。 [shenker]様々な会計上の影響を議論し、エッジ・プライシング・モデルを導入しました。エッジ・プライシング・モデルは、モビリティおよびセキュリティ上の影響が対処されていないことを除いて、このセクションで説明したモデルに類似性を示します。
Various authorization models can be used in conjunction with the QoS NSLP.
様々な認証モデルは、QoS NSLPと組み合わせて使用することができます。
The two-party approach (Figure 17) is conceptually the simplest authorization model.
二大政党のアプローチ（図17）は、概念的に最も単純な承認モデルです。
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
Figure 17: Two-Party Approach
図17：二大政党のアプローチ
In this example, the authorization decision only involves the two entities, or makes use of previous authorization using an out-of-band mechanism to avoid the need for active participation of an external entity during the NSIS protocol execution.
この例では、許可の決定は、唯一の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.
このタイプのモデルは、長期契約（またはその他のアウトオブバンドメカニズムは）充電管理するために存在し、個々の要求を許可するのに十分な情報を提供する二つの隣接ネットワーク（ドメイン間シグナリング）との間に、例えば、適用可能です。
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.
別のアプローチは、オープン決済プロトコル[OSP]の一部として、RFC 3520 [RFC3520]及びRFC 3521 [RFC3521]に記載され又は使用されるようなトークンを利用します。許可トークンは、二つの異なったシグナリングプロトコルの実行（例えば、SIPおよびNSIS）と互いの許可決定を関連付けるために使用されます。後者は、アサーションまたは形質の形態です。一例として、許可トークン機構と、許可のいくつかのフォームを要求が許可されている場合は図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：トークンベースの三者のアプローチ
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.
別の方法は、許可決定は、要求ごとに、定期的に、またはセッションごとに実行されてもよい。図19に示すように、第三者に許可決定を委任するQoS予約を行うノードのためのものです。
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
QoS | | QoS
authz| |authz
req.| | res.
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 19: Three-Party Approach
図19：三者のアプローチ
Whenever an authorization decision has to be made there is the question about which information serves as an input to the authorizing entity. The following information items have been mentioned in the past for computing the authorization decision (in addition to the authenticated identity):
許可の決定がなされなければならたびの情報は、認可実体への入力として役立つかについての疑問があります。以下の情報項目は、（認証された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.
作者は彼らの役に立つコメントをエレノア・ヘップワース、Ruediger Geib、ローランド祝福、ネメスKrisztian、マーカス・オット、MAYI Zoumaro-Djayoon、マルタインSwanink、とルードKlaverに感謝したいと思います。ローランドは、特に、プロトコルが十分に定義されていることを確認すること、文書の深いレビューを行っています。ボブブレーデンは感謝して受信された有益なコメントやガイダンスを提供しました。
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つの個別の文書から作業を兼ね備えています。ロバート・ハンコック（シーメンス/ Rokeマナーリサーチ）、ハンネスTschofenigとコルネリアKappler（シーメンスAG）、ラースWestbergとアッティラベイダー（エリクソン）、およびマールテンBuechli（ダンテ）とエリック・Waegeman：これらの文書から次の著者はまた、この文書に貢献しました（アルカテル）。また、ローランドは、すべてこの仕様書の執筆に沿ったテキストのかなりの量を貢献してきた祝福します。
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.
スヴェン・ヴァン・デン・ボッシュは、このドキュメントの以前のドラフトバージョンの最初の編集者でした。ドキュメントのバージョン06以来、ユッカマナーが監修してきました。 YacineエルMghazli（アルカテル）は、AAAのテキストを寄付しました。チャールズ・シェンとヘニングSchulzrinneとはBOUND-SESSION-IDでのreasonフィールドの使用を示唆しました。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、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]アッシュ、G.、ベイダー、A.、Kappler、C.、およびD.オラン、 "サービス品質NSISシグナリング層プロトコルのためのQSPECテンプレート（NSLP）"、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]マナー、J.は、Stiemerling、M.、Tschofenig、H.、およびR.は、ブレス編、 "NSISシグナリング層プロトコルの許可"、進歩、2010年5月ワーク。
[NSIS-MOB] Sanda, T., Fu, X., Jeong, S., Manner, J., and H. Tschofenig, "NSIS Protocols operation in Mobile Environments", Work in Progress, May 2010.
[NSIS-MOB]三田、T.、フー、X.、チョン、S.、マナー、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]ブレーデン、B.、クラーク、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、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]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "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]ハマー、L-N。、ゲージ、B.、コジンスキー、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]ハマー、L-N。、RFC 3521、2003年4月、ゲージ、B.、およびH. Shieh、 "メディア認証とセッションのセットアップのためのフレームワーク"。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、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]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（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]クロッカー、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.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（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]ベイダー、A.、Westberg、L.、Karagiannis、G.、Kappler、C.、Tschofenig、H.、およびT.フェラン、「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]マナー、J.及びK. Raatikainen、 "無線アクセスネットワークにおけるマルチメディアアプリケーションのローカライズされたQoS管理"、IASTED IMSA、技術仕様101 321、P。 193-200、2004年8月。
[opwa95] Breslau, L., "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.
[opwa95]ブレスラウ、L.、 "予約の確立で二つの問題"、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.、ら、 "コンピュータネットワークにおける価格：研究課題を再成形"。、PROCを。 TPRC 1995、1995。
Appendix A. Abstract NSLP-RMF API
付録A.抽象NSLP-RMFのAPI
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の間のインタフェースを明確にするのに役立ちます。
A.1. Triggers from QOS-NSLP towards RMF
A.1。 RMFに向けてQOS-NSLPからのトリガー
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、フィルタ、features_in、GIST_API_triggers、incoming_interface、outgoing_interface）
o sid: SESSION-ID - The NSIS session identifier
O SID：SESSION-ID - NSISセッション識別子
o nslp_req_type: indicates type of request:
nslp_req_type O：要求のタイプを示します。
* RESERVE
* RESERVE
* QUERY
* QUERY
* RESPONSE
*応答
* NOTIFY
* NOTIFY
o qspec: the QSPEC object, if present
O qspec：QSPECオブジェクト、存在する場合
o authorization_info: the AUTH_SESSION object, if present
authorization_info O：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
＊ りい
* RSN
* RSN
* BOUND-SESSION-ID list
* BOUND-SESSION-IDのリスト
* REFRESH-PERIOD
* REFRESH期間
* SESSION-ID-LIST
* SESSION-ID-LIST
* RSN-LIST
* RSN-LIST
* INFO-SPEC
* 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:
features_in O：それが受信したQoS-NSLPメッセージだけでなく、追加のトリガの共通ヘッダに含まれるフラグを表します。
* BREAK
* BREAK
* REQUEST REDUCED REFRESHES
* REQUEST REDUCED更新します
* RESERVE-INIT
* RESERVE-INIT
* TEAR
* TEAR
* REPLACE
* REPLACE
* ACK-REQ
* ACK-REQ
* PROXY
* PROXY
* SCOPING
* 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：この属性は、QNE退出によってサポートされるQoS-NSLP機能はMSG-IDまたは結合-MSGを含む非引裂RESERVEメッセージを受信した場合（例えば、セクションセクション4.6およびセクション4.7.1を参照）が設定されています-IDオブジェクト、およびBOUND-SESSION-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
+アラビア語 - ハンドル
+ Transfer-Attributes
+転送アトリビュート
+ GIST-Hop-Count
+ GISTホップ・カウント
+ IP-TTL
+ IP-TTL
+ IP-Distance
+ IP-距離
o incoming_interface: the ID of the incoming interface. Used only when the QNE reserves resources on incoming interface. Default is 0 (no reservations on incoming interface)
入出力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)
outgoing_interface O：発信インターフェイスのID。使用時にのみQNE埋蔵資源発信インターフェイス上。デフォルトは0（発信インターフェイスには予約）ではありません
A.2. Triggers from RMF/QOSM towards QOS-NSLP
A.2。 QOS-NSLPに向けてRMF / QOSMからのトリガー
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（）」と「設定（）」プリミティブを使用して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（）」応答プリミティブは、QoS-NSLP向かっAPIを介して送信することができます。このように、QOS-NSLPは、一エンド・ツー・エンドRESERVEの到着が2つ（またはそれ以上）RESERVEメッセージの生成をトリガする状況で、例えば、使用することができる1つ以上のQoS-NSLPメッセージを生成することができます：エンドツーエンドのRESERVEメッセージと1つ（または複数）ドメイン内（ローカル）RESERVEメッセージ。
The config() primitive is used to configure certain features, such as QNE type, stateful or stateless operation, or bypassing of end-to-end messages.
設定（）プリミティブは、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、ステータス、NSLP_objects、フィルタ、features_out、GIST_API_triggersのincoming_interface、outgoing_interface）
o sid: SESSION-ID - The NSIS session identifier o nslp_resp_type: indicates type of response:
O SID：セッションID - NSISセッション識別子入出力nslp_resp_typeは：応答のタイプを示します。
* RESERVE
* RESERVE
* QUERY
* QUERY
* RESPONSE
*応答
* NOTIFY
* NOTIFY
o qspec: the QSPEC object, if present
O qspec：QSPECオブジェクト、存在する場合
o authorization_info: the AUTHO_SESSION object, if present
authorization_info O：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状態：ブール予約の状況を通知し、INFO-SPECオブジェクトに含めるQOS-NSLPで使用することができます。
* RESERVATION_SUCCESSFUL
* RESERVATION_SUCCESSFUL
* TEAR_DOWN_SUCCESSFUL
* TEAR_DOWN_SUCCESSFUL
* NO RESOURCES
* NOリソース
* RESERVATION_FAILURE
* RESERVATION_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：エンドツーエンドRESERVEの間の不一致同期およびドメイン内RESERVE（セクションセクション4.6およびセクション4.7.1を参照のこと）
* CONGESTION_SITUATION: Possible congestion situation occurred on downstream path
* CONGESTION_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：QNEはQNI、QNR、QNI_Ingress、QNR_Ingress、QNI_Egress、又はQNR_Egressある場合のQoS-NSLPで使用することができるのQoS-NSLPオブジェクトのリストを含むデータ構造。
* RII
＊ りい
* RSN
* RSN
* BOUND-SESSION-ID list
* BOUND-SESSION-IDのリスト
* REFRESH-PERIOD
* REFRESH期間
* SESSION-ID-LIST
* SESSION-ID-LIST
* RSN-LIST
* RSN-LIST
* 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 features_out：それは（とりわけ）新たに生成されたQoS-NSLPメッセージのQoS-NSLPで使用することができるフラグを表します。
* BREAK
* BREAK
* REQUEST REDUCED REFRESHES
* REQUEST REDUCED更新します
* RESERVE-INIT
* RESERVE-INIT
* TEAR
* TEAR
* REPLACE
* REPLACE
* ACK-REQ
* ACK-REQ
* PROXY
* PROXY
* SCOPING
* 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 - バインディングが要求される場合、それはBOUND-SESSION-IDのリストを含みます。それ以外の場合は空です。 QNI、QNR、QNI_Ingress、QNR_Ingress、QNI_Egress、またはQNR_Egress：それだけで、次のQNEの種類によって要求することができます。
* 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は - それは新しいSESSION-IDを使用して新しいセッションを生成するために要求します。 QoSの-NSLPが新しいSESSION-IDを生成した場合、QoSの-NSLPは、RMF / QOSMにこの新しいSESSION-IDの値を返すことがあります。それは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は、RMF / QOSMにこの新しいRSNの値を返すことがあります。
* 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は、RMF / QOSMにこの新しいRIIの値を返すことがあります。
o GIST_API_triggers: it represents the attributes that are provided to GIST via QoS-NSLP via the GIST API:
GIST_API_triggers O：それはGISTのAPI経由でのQoS-NSLP経由GISTに提供される属性を表します。
* NSLPID
* NSLPID
* SII-Handle
*アラビア語 - ハンドル
* Transfer-Attributes
*転送-属性
* GIST-Hop-Count
* GISTホップ・カウント
* IP-TTL
* IP-TTL
* ROUTING-STATE-CHECK (if set, it requires that GIST create a routing state)
* ROUTING-STATE-CHECK（設定されている場合、それは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).
入出力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).
outgoing_interface O：発信インターフェイスのID。使用時にのみQNE埋蔵資源発信インターフェイス上。デフォルトは0（発信インターフェイスには予約）ではありません。
A.3. Configuration Interface
A.3。構成インターフェイス
The config() function is meant for configuring per-session settings, from the RMF towards the NSLP.
設定（）関数は、NSLPに向けたRMFから、セッションごとの設定を行うためのものです。
int config(sid, qne_type, state_type, bypassing_type)
int型の設定（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：セッションID - NSISセッション識別子qne_type O：それは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_Interior：QNEはインテリアQNEであるが、それはQNIかQNRではありません
* 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
state_typeはO：QNEは、QoS-NSLP動作状態を維持している場合、それは定義されて
* STATEFUL
*ステートフル
* STATELESS
* STATELESS
o bypassing_type: it defines if a QNE bypasses end-to-end messages or not
bypassing_type O：QNEは、エンドツーエンドのメッセージをバイパスしないかどうかを定義します
Appendix B. Glossary
付録B.用語集
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
PIN：ポリシー無知なノード
QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)
QNE：NSISエンティティ（NE）、QoSのNSLPをサポートしています（第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
コミュニケーションのアアルト大学学部およびネットワーキング（Comnet）私書箱からユッカマナー13000 FIN-00076アアルトフィンランド箱
Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/
電話：+358 9 470 22481 Eメール：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
トウェンテのゲオルギオスカラGiannis大学/エリクソン私書箱ボックス217、7500 AEエンスヘーデ、ネザーランズ
EMail: karagian@cs.utwente.nl
メールアドレス：karagian@cs.utwente.nl
Andrew McDonald Roke Manor Research Ltd Old Salisbury Lane Romsey, Hampshire S051 0ZN United Kingdom
アンドリュー・マクドナルドRokeマナーリサーチリミテッドオールド・ソールズベリーレーンロムジー、ハンプシャーS051 0ZNイギリス
EMail: andrew.mcdonald@roke.co.uk
メールアドレス：andrew.mcdonald@roke.co.uk