[要約] RFC 5975は、NSISシグナリングレイヤープロトコル（NSLP）のためのQSPECテンプレートに関するものです。このRFCの目的は、QoS要件を定義し、NSISプロトコルを使用してこれらの要件を伝達するためのテンプレートを提供することです。
Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 5975 AT&T
Category: Experimental A. Bader, Ed.
ISSN: 2070-1721 Ericsson
C. Kappler, Ed.
ck technology concepts
D. Oran, Ed.
Cisco Systems, Inc.
October 2010
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
サービス品質NSISシグナリングレイヤープロトコルのQSPECテンプレート（NSLP）
Abstract
概要
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.
サービス品質（QOS）NSISシグナリングレイヤープロトコル（NSLP）は、QoS予約を信号するために使用され、IntServやDiffServなどの特定のQoSモデル（QOSM）とは無関係です。むしろ、QoSMに固有のすべての情報は、別のオブジェクトであるQSPECにカプセル化されています。このドキュメントでは、多くのQSPECパラメーターを含むQSPECのテンプレートを定義しています。QSPECパラメーターは、いくつかのQoSMで再利用される共通言語を提供し、それによりQoS NSLPの拡張性と相互運用性を確保することを目指しています。基本プロトコルはQOSMに依存していますが、QSPECオブジェクトに携帯できるパラメーターは、特定のモデルと密接に結合される可能性があります。NSISシグナル伝達を開始するノードは、イニシエーターQSPECを追加します。これは、下流ノードによって解釈されなければならないQSPECパラメーターが予約に失敗することを示し、それによりNSISイニシエーターの意図が信号パスに沿って保存されることを保証します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5975.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5975で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................6
2. Terminology .....................................................6
3. QSPEC Framework .................................................7
3.1. QoS Models .................................................7
3.2. QSPEC Objects ..............................................9
3.3. QSPEC Parameters ..........................................11
3.3.1. Traffic Model Parameter ............................12
3.3.2. Constraints Parameters .............................14
3.3.3. Traffic-Handling Directives ........................16
3.3.4. Traffic Classifiers ................................17
3.4. Example of QSPEC Processing ...............................17
4. QSPEC Processing and Procedures ................................20
4.1. Local QSPEC Definition and Processing .....................20
4.2. Reservation Success/Failure, QSPEC Error Codes,
and INFO-SPEC Notification ................................23
4.2.1. Reservation Failure and Error E Flag ...............24
4.2.2. QSPEC Parameter Not Supported N Flag ...............25
4.2.3. INFO-SPEC Coding of Reservation Outcome ............25
4.2.4. QNE Generation of a RESPONSE Message ...............26
4.2.5. Special Case of Local QSPEC ........................27
4.3. QSPEC Procedures ..........................................27
4.3.1. Two-Way Transactions ...............................28
4.3.2. Three-Way Transactions .............................30
4.3.3. Resource Queries ...................................32
4.3.4. Bidirectional Reservations .........................33
4.3.5. Preemption .........................................33
4.4. QSPEC Extensibility .......................................33
5. QSPEC Functional Specification .................................33
5.1. General QSPEC Formats .....................................33
5.1.1. Common Header Format ...............................34
5.1.2. QSPEC Object Header Format .........................36
5.2. QSPEC Parameter Coding ....................................37
5.2.1. <TMOD-1> Parameter .................................37
5.2.2. <TMOD-2> Parameter .................................38
5.2.3. <Path Latency> Parameter ...........................39
5.2.4. <Path Jitter> Parameter ............................40
5.2.5. <Path PLR> Parameter ...............................41
5.2.6. <Path PER> Parameter ...............................42
5.2.7. <Slack Term> Parameter .............................43
5.2.8. <Preemption Priority> and <Defending Priority>
Parameters .........................................43
5.2.9. <Admission Priority> Parameter .....................44
5.2.10. <RPH Priority> Parameter ..........................45
5.2.11. <Excess Treatment> Parameter ......................46
5.2.12. <PHB Class> Parameter .............................48
5.2.13. <DSTE Class Type> Parameter .......................49
5.2.14. <Y.1541 QoS Class> Parameter ......................50
6. Security Considerations ........................................51
7. IANA Considerations ............................................51
8. Acknowledgements ...............................................55
9. Contributors ...................................................55
10. Normative References ..........................................57
11. Informative References ........................................59
Appendix A. Mapping of QoS Desired, QoS Available, and QoS
Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62
Appendix B. Example of TMOD Parameter Encoding ....................62
The QoS NSIS signaling layer protocol (NSLP) [RFC5974] is used to signal QoS reservations for a data flow, provide forwarding resources (QoS) for that flow, and establish and maintain state at nodes along the path of the flow. The design of QoS NSLP is conceptually similar to the decoupling between RSVP [RFC2205] and the IntServ architecture [RFC2210], where a distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). [RFC5974] describes the signaling protocol, while this document describes the RMF-related information carried in the QSPEC (QoS Specification) object carried in QoS NSLP messages.
QOS NSISシグナリングレイヤープロトコル（NSLP）[RFC5974]は、データフローのQOS予約を信号に合わせ、そのフローの転送リソース（QOS）を提供し、フローの経路に沿ったノードで状態を確立および維持するために使用されます。QoS NSLPの設計は、RSVP [RFC2205]とIntServアーキテクチャ[RFC2210]の間のデカップリングと概念的に類似しています。ここでは、シグナル伝達プロトコルの動作とリソース管理機能の動作に必要な情報との区別が行われます（RMF）。[RFC5974]はシグナル伝達プロトコルを説明し、このドキュメントでは、QoS NSLPメッセージに掲載されたQSPEC（QOS仕様）オブジェクトに掲載されたRMF関連情報を説明しています。
[RFC5974] defines four QoS NSLP messages -- RESERVE, QUERY, RESPONSE, and NOTIFY -- each of which may carry the QSPEC object, while this document describes a template for the QSPEC object. The QSPEC object carries information on traffic descriptions, resources required, resources available, and other information required by the RMF. Therefore, the QSPEC template described in this document is closely tied to QoS NSLP, and the reader should be familiar with [RFC5974] to fully understand this document.
[RFC5974] 4つのQoS NSLPメッセージ（予約、クエリ、応答、および通知）を定義し、それぞれがQSPECオブジェクトを運ぶことができますが、このドキュメントはQSPECオブジェクトのテンプレートを説明しています。QSPECオブジェクトは、RMFが必要とするトラフィックの説明、必要なリソース、利用可能なリソース、およびその他の情報に関する情報を搭載しています。したがって、このドキュメントで説明されているQSPECテンプレートはQOS NSLPに密接に関連しており、読者は[RFC5974]に精通して、このドキュメントを完全に理解する必要があります。
A QoS-enabled domain supports a particular QoS model (QOSM), which is a method to achieve QoS for a traffic flow. A QOSM incorporates QoS provisioning methods and a QoS architecture, and defines the behavior of the RMF that reserves resources for each flow, including inputs and outputs. The QoS NSLP protocol is able to signal QoS reservations for different QOSMs, wherein all information specific to a QOSM is encapsulated in the QSPEC object, and only the RMF specific to a given QOSM will need to interpret the QSPEC. Examples of QOSMs are IntServ, Diffserv admission control, and those specified in [CL-QOSM], [RFC5976], and [RFC5977].
QOS対応ドメインは、トラフィックフローのQOSを達成する方法である特定のQOSモデル（QOSM）をサポートします。QOSMには、QoSプロビジョニング方法とQoSアーキテクチャが組み込まれ、入力や出力を含む各フローのリソースを留保するRMFの動作を定義します。QOS NSLPプロトコルは、QoSMに固有のすべての情報がQSPECオブジェクトにカプセル化されているさまざまなQOSMのQOS予約を信号することができ、特定のQoSMに固有のRMFのみがQSPECを解釈する必要があります。QOSMの例は、IntServ、DiffServ Asmention Control、および[CL-QOSM]、[RFC5976]、および[RFC5977]で指定されているものです。
QSPEC parameters include, for example:
QSPECパラメーターには、たとえば：
o a mandatory traffic model (TMOD) parameter, o constraints parameters such as path latency and path jitter, o traffic handling directives such as excess treatment, and o traffic classifiers such as PHB class.
o 必須のトラフィックモデル（TMOD）パラメーター、oパスレイテンシやパスジッターなどの制約パラメーター、o過剰処理などのトラフィック処理指令、およびPHBクラスなどのトラフィック分類器。
While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models.
基本プロトコルはQOSMに依存していますが、QSPECオブジェクトに携帯できるパラメーターは、特定のモデルと密接に結合される可能性があります。
QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec objects specified in RSVP and may contain, respectively, a description of QoS Desired, QoS Reserved, and QoS Available. Going beyond RSVP functionality, the QSPEC also allows indicating a range of acceptable QoS by defining a QSPEC object denoting minimum QoS. Usage of these QSPEC objects is not bound to particular message types, thus allowing for flexibility. A QSPEC object collecting information about available resources may travel in any QoS NSLP message, for example, a QUERY message or a RESERVE message, as defined in [RFC5974]. The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP and is only interpreted by the RMF.
QSPECオブジェクトは、RSVPで指定されたTSPEC、RSPEC、およびADSPECオブジェクトに大まかに対応し、それぞれ使用可能なQOS、QOS予約、およびQOSの説明がそれぞれ含まれている場合があります。RSVP機能を超えて、QSPECは、最小QoSを示すQSPECオブジェクトを定義することにより、許容可能なQOSの範囲を示すこともできます。これらのQSPECオブジェクトの使用は、特定のメッセージタイプにバインドされていないため、柔軟性が可能になります。利用可能なリソースに関する情報を収集するQSPECオブジェクトは、[RFC5974]で定義されているように、クエリメッセージやリザーブメッセージなど、QOS NSLPメッセージなどに移動できます。QSPECはQOS NSLPメッセージで移動しますが、QOS NSLPに不透明であり、RMFによってのみ解釈されます。
Interoperability between QoS NSIS entities (QNEs) in different domains is enhanced by the definition of a common set of QSPEC parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an Initiator QSPEC object containing parameters describing the desired QoS, normally based on the QOSM it supports. QSPEC parameters flagged by the QNI must be interpreted by all QNEs in the path, else the reservation fails. In contrast, QSPEC parameters not flagged by the QNI may be skipped if not understood. Additional QSPEC parameters can be defined by informational specification documents, and thereby ensure the extensibility and flexibility of QoS NSLP.
異なるドメインのQoS NSISエンティティ（QNES）間の相互運用性は、QSPECパラメーターの共通セットの定義によって強化されます。QoS NSLPシグナル伝達を開始するQoS NSISイニシエーター（QNI）は、通常はサポートするQoSMに基づいて、目的のQoSを記述するパラメーターを含むイニシエーターQSPECオブジェクトを追加します。QNIによってフラグが付けられたQSPECパラメーターは、パス内のすべてのQNEによって解釈される必要があります。そうしないと、予約が失敗します。対照的に、QNIによってフラグが付けられていないQSPECパラメーターは、理解されていない場合はスキップされる場合があります。追加のQSPECパラメーターは、情報仕様ドキュメントで定義でき、QoSNSLPの拡張性と柔軟性を確保できます。
A Local QSPEC can be defined in a local domain with the Initiator QSPEC encapsulated, where the Local QSPEC must be functionally consistent with the Initiator QSPEC in terms of defined source traffic and other constraints. That is, a domain-specific local QSPEC can be defined and processed in a local domain, which could, for example, enable simpler processing by QNEs within the local domain.
ローカルQSPECは、イニシエーターQSPECがカプセル化されたローカルドメインで定義できます。ここでは、定義されたソーストラフィックおよびその他の制約の観点から、ローカルQSPECがイニシエーターQSPECと機能的に一致する必要があります。つまり、ドメイン固有のローカルQSPECをローカルドメインで定義および処理できます。これにより、たとえば、ローカルドメイン内のQNESによるよりシンプルな処理が可能になります。
In Section 3.4, an example of QSPEC processing is provided.
セクション3.4では、QSPEC処理の例が提供されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Initiator QSPEC: The Initiator QSPEC is included in a QoS NSLP message by the QNI/QNR. It travels end-to-end to the QNR/QNI and is never removed.
イニシエーターQSPEC：イニシエーターQSPECは、QNI/QNRによるQOS NSLPメッセージに含まれています。QNR/QNIにエンドツーエンドを移動し、削除されることはありません。
Local QSPEC: A Local QSPEC is used in a local domain and is domain specific. It encapsulates the Initiator QSPEC and is removed at the egress of the local domain.
ローカルQSPEC：ローカルQSPECはローカルドメインで使用され、ドメイン固有です。イニシエーターQSPECをカプセル化し、ローカルドメインの出口で削除されます。
Minimum QoS: QSPEC object that, together with a description of QoS Desired or QoS Available, allows the QNI to specify a QoS range, i.e., an upper and lower bound. If the QoS Desired cannot be reserved, QNEs are going to decrease the reservation until the minimum QoS is hit. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value.
最小QoS：QSSPECオブジェクトは、利用可能なQOSまたはQOSの説明とともに、QNIがQoS範囲、つまり上限と下限を指定できるようにします。希望のQoSを予約できない場合、QNESは最小QOSがヒットするまで予約を減らします。「最小」という用語は一般的に使用されることに注意してください。損失率やレイテンシなどの一部のパラメーターでは、指定されているものが最大許容値であるためです。
QNE: QoS NSIS Entity, a node supporting QoS NSLP.
QNE：QOS NSISエンティティ、QOS NSLPをサポートするノード。
QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling.
QNI：QOS NSIS Initiator、QOS NSLPシグナル伝達を開始するノード。
QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling.
QNR：QOS NSISレシーバー、QOS NSLPシグナリングを終了するノード。
QoS Available: QSPEC object containing parameters describing the available resources. They are used to collect information along a reservation path.
利用可能なQoS：利用可能なリソースを説明するパラメーターを含むQSPECオブジェクト。それらは、予約パスに沿って情報を収集するために使用されます。
QoS Desired: QSPEC object containing parameters describing the desired QoS for which the sender requests reservation.
QOSが目的：送信者が予約を要求する目的のQOを記述するパラメーターを含むQSPECオブジェクト。
QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF.
QoSモデル（QOSM）：トラフィックフローのQoSを達成する方法、たとえばIntServ制御負荷。QOSMがQOSMがサポートできることとRMFによってリソースの管理方法を実装するQNEが実装するQSPEC QOS制約とトラフィック処理指令のサブセットを指定します。
QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters.
予約済み：予約されたリソースと関連するQoSパラメーターを記述するパラメーターを含むQSPECオブジェクト。
QSPEC: the object of QoS NSLP that contains all QoS-specific information.
QSPEC：すべてのQoS固有の情報を含むQoS NSLPのオブジェクト。
QSPEC parameter: Any parameter appearing in a QSPEC; for example, traffic model (TMOD), path latency, and excess treatment parameters.
QSPECパラメーター：QSPECに表示されるパラメーター。たとえば、トラフィックモデル（TMOD）、パスレイテンシ、過剰な治療パラメーター。
QSPEC Object: Main building blocks containing a QSPEC parameter set that is the input or output of an RMF operation.
QSPECオブジェクト：RMF操作の入力または出力であるQSPECパラメーターセットを含むメインビルディングブロック。
QSPEC Type: Identifies a particular QOSM used in the QSPEC
QSPECタイプ：QSPECで使用されている特定のQOSMを識別します
Resource Management Function (RMF): Functions that are related to resource management and processing of QSPEC parameters.
リソース管理機能（RMF）：QSPECパラメーターのリソース管理と処理に関連する関数。
The overall framework for the QoS NSLP is that [RFC5974] defines QoS signaling and semantics, the QSPEC template defines the container and semantics for QoS parameters and objects, and informational specifications define QoS methods and procedures for using QoS signaling and QSPEC parameters/objects within specific QoS deployments. QoS NSLP is a generic QoS signaling protocol that can signal for many QOSMs.
QoS NSLPの全体的なフレームワークは、[RFC5974]がQOSシグナル伝達とセマンティクスを定義し、QSPECテンプレートはQOSパラメーターとオブジェクトのコンテナとセマンティクスを定義し、QOSシグナルおよびQSPECパラメーター/オブジェクトを使用するためのQOSメソッドと手順を定義し、情報仕様を定義することです。特定のQoS展開。QoS NSLPは、多くのQoSMをシグナルとする一般的なQoSシグナル伝達プロトコルです。
A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load [CL-QOSM], Resource Management with Diffserv [RFC5977], and QoS signaling for Y.1541 QoS classes [RFC5976]. A QOSM specifies a set of QSPEC parameters that describe the QoS desired and how resources will be managed by the RMF. The RMF implements functions that are related to resource management and processes the QSPEC parameters.
QoSMは、トラフィックフローのQoSを達成する方法です。たとえば、IntServ制御負荷[CL-QOSM]、DiffServ [RFC5977]を使用したリソース管理、およびY.1541 QOSクラス[RFC5976]のQOSシグナル伝達。QOSMは、QOSが望むQOSとRMFによってリソースの管理方法を説明するQSPECパラメーターのセットを指定します。RMFは、リソース管理に関連する関数を実装し、QSPECパラメーターを処理します。
QOSMs affect the operation of the RMF in NSIS-capable nodes and the information carried in QSPEC objects. Under some circumstances (e.g., aggregation), they may cause a separate NSLP session to be instantiated by having the RMF as a QNI. QOSM specifications may define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state and messaging processing rules, as defined in Section 5.2 of [RFC5974]. New QoS NSLP message processing rules can only be defined in extensions to QoS NSLP. If a QOSM specification defines triggers that deviate from existing QoS NSLP processing rules, the fallback for QNEs not supporting that QOSM are the QoS NSLP state transition/message processing rules.
QoSMは、NSIS対応ノードでのRMFの動作とQSPECオブジェクトで搭載されている情報に影響します。状況によっては（たとえば、集約）、RMFをQNIとして持つことにより、個別のNSLPセッションがインスタンス化される場合があります。QOSM仕様は、[RFC5974]のセクション5.2で定義されているように、QoS NSLPが基礎となるQoS NSLPシグナリング状態およびメッセージング処理ルール内でセマンティクスを実行するRMFトリガーを定義する場合があります。新しいQoS NSLPメッセージ処理ルールは、QoS NSLPの拡張でのみ定義できます。QOSM仕様が既存のQoS NSLP処理ルールから逸脱するトリガーを定義する場合、QSEがQOSMがQoS NSLP状態の遷移/メッセージ処理ルールであることをサポートしていないフォールバック。
The QOSM specification includes how the requested QoS resources will be described and how they will be managed by the RMF. For this purpose, the QOSM specification defines a set of QSPEC parameters it uses to describe the desired QoS and resource control in the RMF, and it may define additional QSPEC parameters.
QOSM仕様には、要求されたQoSリソースの説明方法と、RMFがどのように管理するかが含まれます。この目的のために、QOSM仕様は、RMFの目的のQoSとリソース制御を記述するために使用する一連のQSPECパラメーターを定義し、追加のQSPECパラメーターを定義する場合があります。
When a QoS NSLP message travels through different domains, it may encounter different QOSMs. Since QOSMs use different QSPEC parameters for describing resources, the QSPEC parameters included by the QNI may not be understood in other domains. The QNI therefore can flag those QSPEC parameters it considers vital with the M flag. QSPEC parameters with the M flag set must be interpreted by the downstream QNEs, or the reservation fails. QSPEC parameters without the M flag set should be interpreted by the downstream QNEs, but may be ignored if not understood.
QoS NSLPメッセージが異なるドメインを通過すると、異なるQoSMに遭遇する可能性があります。QoSMはリソースを記述するために異なるQSPECパラメーターを使用するため、QNIに含まれるQSPECパラメーターは他のドメインでは理解されない場合があります。したがって、QNIは、Mフラグで重要であると考えるQSPECパラメーターにフラグを立てることができます。Mフラグセットを使用したQSPECパラメーターは、下流のQNESによって解釈する必要があります。または、予約が失敗する必要があります。MフラグセットのないQSPECパラメーターは、下流QNESによって解釈される必要がありますが、理解されていない場合は無視される場合があります。
A QOSM specification SHOULD include the following:
QOSM仕様には、次のものを含める必要があります。
- role of QNEs, e.g., location, frequency, statefulness, etc. - QSPEC definition including QSPEC parameters - QSPEC procedures applicable to this QOSM - QNE processing rules describing how QSPEC information is treated and interpreted in the RMF, e.g., admission control, scheduling, policy control, QoS parameter accumulation (e.g., delay) - at least one bit-level QSPEC example - QSPEC parameter behavior for new QSPEC parameters that the QOSM specification defines - a definition of what happens in case of preemption if the default QNI behavior (teardown preempted reservation) is not followed (see Section 4.3.5)
- QNEの役割、例えば、場所、頻度、状態など。 -QSPECパラメーターを含むQSPEC定義-QSPEC手順このQOSMに適用される - QSPEC情報の処理ルールQSPEC情報がRMFで処理および解釈される方法、例えば、入学制御、スケジューリング、ポリシー制御、QoSパラメーター蓄積（遅延など） - 少なくとも1つのビットレベルQSPEC例-QOSM仕様が定義する新しいQSPECパラメーターのQSPECパラメーター動作 - デフォルトのQNI動作の場合の先制の場合に起こることの定義予約された予約）には従わない（セクション4.3.5を参照）
A QOSM specification MAY include the following:
QOSM仕様には、次のものが含まれます。
- definitions of additional QOSM-specific error codes, as discussed in Section 4.2.3 - the QoS-NSLP options a QOSM wants to use, when several options are available for a QOSM (e.g., Local QSPEC to either a) hide the Initiator QSPEC within a local domain message, or b) encapsulate the Initiator QSPEC).
- セクション4.2.3-QOS-NSLPオプションで説明した追加のQOSM固有のエラーコードの定義QOSMが使用したいQOS-NSLPオプション。ローカルドメインメッセージ、またはb）イニシエーターQSPECをカプセル化します）。
QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the QSPEC. This includes traffic description parameters, constraint parameters, and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the QSPEC parameters specified in this document. Note that signaling functionality is only defined by the QoS NSLP document [RFC5974] and not by this document or by QOSM specification documents.
QOSMは無料で、IANA登録およびレビュールールを条件として、QSPECがサポートする種類のパラメーターを追加することによりQSPECを拡張します。これには、トラフィックの説明パラメーター、制約パラメーター、トラフィック処理指令が含まれます。ただし、QoSMは、このドキュメントで指定されているQSPECパラメーターを再解釈または再定義することは許可されていません。シグナリング機能は、QoS NSLPドキュメント[RFC5974]によってのみ定義され、このドキュメントまたはQOSM仕様ドキュメントによっては定義されていることに注意してください。
The QSPEC is the object of QoS NSLP containing QSPEC objects and parameters. QSPEC objects are the main building blocks of the QSPEC parameter set that is input or output of an RMF operation. QSPEC parameters are the parameters appearing in a QSPEC, which must include the traffic model parameter (TMOD), and may optionally include constraints (e.g., path latency), traffic handling directives (e.g., excess treatment), and traffic classifiers (e.g., PHB class). The RMF implements functions that are related to resource management and processes the QSPEC parameters.
QSPECは、QSPECオブジェクトとパラメーターを含むQOS NSLPのオブジェクトです。QSPECオブジェクトは、RMF操作の入力または出力であるQSPECパラメーターセットのメインビルディングブロックです。QSPECパラメーターは、トラフィックモデルパラメーター（TMOD）を含む必要があるQSPECに表示されるパラメーターであり、オプションで制約（パスレイテンシなど）、トラフィックハンドリングディレクティブ（過剰治療）、トラフィック分類子（例：PHBBクラス）。RMFは、リソース管理に関連する関数を実装し、QSPECパラメーターを処理します。
The QSPEC consists of a QSPEC version number and QSPEC objects. IANA assigns a new QSPEC version number when the current version is deprecated or deleted (as required by a specification). Note that a new QSPEC version number is not needed when new QSPEC parameters are specified. Later QSPEC versions MUST be backward compatible with earlier QSPEC versions. That is, a version n+1 device must support QSPEC version n (or earlier). On the other hand, if a QSPEC version n (or earlier) device receives an NSLP message specifying QSPEC version n+1, then the version n device responds with an 'Incompatible QSPEC' error code (0x0f) response, as discussed in Section 4.2.3, allowing the QNE that sent the NSLP message to retry with a lower QSPEC version.
QSPECは、QSPECバージョン番号とQSPECオブジェクトで構成されています。IANAは、現在のバージョンが非推奨または削除されている場合（仕様で要求されている場合）、新しいQSPECバージョン番号を割り当てます。新しいQSPECパラメーターが指定されている場合、新しいQSPECバージョン番号は必要ないことに注意してください。後のQSPECバージョンは、以前のQSPECバージョンと後方互換性がなければなりません。つまり、バージョンn 1デバイスはQSPECバージョンN（または以前）をサポートする必要があります。一方、QSPECバージョンN（または以前）デバイスがQSPECバージョンn 1を指定するNSLPメッセージを受信すると、バージョンnデバイスはセクション4.2で説明したように、「互換性のないQSPEC」エラーコード（0x0F）応答で応答します。3、NSLPメッセージを送信したQNEが低いQSPECバージョンで再試行できるようにします。
This document provides a template for the QSPEC in order to promote interoperability between QOSMs. Figure 1 illustrates how the QSPEC is composed of up to 4 QSPEC objects, namely QoS Desired, QoS Available, QoS Reserved, and Minimum QoS. Each of these QSPEC objects consists of a number of QSPEC parameters. A given QSPEC may contain only a subset of the QSPEC objects, e.g., QoS Desired. The QSPEC objects QoS Desired, QoS Available, QoS Reserved and Minimum QoS MUST all be supported by QNEs and MAY appear in any QSPEC object carried in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY). See [RFC5974] for descriptions of the QoS NSLP RESERVE, QUERY, RESPONSE, and NOTIFY messages.
このドキュメントは、QoSM間の相互運用性を促進するためのQSPECのテンプレートを提供します。図1は、QSPECが最大4つのQSPECオブジェクト、つまりQOSが望むQOS、QOS利用可能、QOS予約、および最小QOで構成されている方法を示しています。これらの各QSPECオブジェクトは、多くのQSPECパラメーターで構成されています。与えられたQSPECには、QSPECオブジェクトのサブセットのみが含まれている場合があります。たとえば、QoSが必要です。QSPECオブジェクトQOSが必要、QOSが利用可能、QOS予約、および最小QOSはすべてQNESによってサポートされ、QOS NSLPメッセージ（予約、クエリ、応答、通知）に携帯されるQSPECオブジェクトに表示される場合があります。QoS NSLP予備、クエリ、応答、および通知メッセージの説明については、[RFC5974]を参照してください。
+---------------------------------------+
| QSPEC Objects |
+---------------------------------------+
\________________ ______________________/
V
+----------+----------+---------+-------+
|QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
+----------+----------+---------+-------+
\____ ____/\___ _____/\___ ____/\__ ___/
V V V V
+-------------+... +-------------+...
|QSPEC Para. 1| |QSPEC Para. n|
+-------------+... +-------------+...
Figure 1: Structure of the QSPEC
図1：QSPECの構造
Use of the 4 QSPEC objects (QoS Desired, QoS Available, QoS Reserved, and Minimum QoS) is described in Section 4.3 for 3 message sequences and 7 object combinations.
4つのQSPECオブジェクト（QOSが目的のQOS、QOS利用可能、QOS予約、および最小QO）の使用は、3つのメッセージシーケンスと7つのオブジェクトの組み合わせのセクション4.3で説明されています。
The QoS Desired Object describe the resources the QNI desires to reserve, and hence this is a read-only QSPEC object in that the QSPEC parameters carried in the object may not be overwritten. QoS Desired is always included in a RESERVE message and sometimes included in the QUERY message (see Section 4.3 for details).
QOSの望ましいオブジェクトは、QNIが予約したいリソースを記述しているため、オブジェクトに携帯されるQSPECパラメーターが上書きされない可能性があるという点で、これは読み取り専用のQSPECオブジェクトです。希望のQoSは常に予約メッセージに含まれており、クエリメッセージに含まれることもあります（詳細についてはセクション4.3を参照）。
As described in Section 4.3, the QoS Available object may travel in a RESERVE message, RESPONSE Message, or QUERY message and may collect information on the resources currently available on the path. In this case, QoS Available is a read-write object, which means the QSPEC parameters contained in QoS Available may be updated, but they cannot be deleted. As such, each QNE MUST inspect all parameters of this QSPEC object, and if resources available to this QNE are less than what a particular parameter says currently, the QNE MUST adapt this parameter accordingly. Hence, when the message arrives at the recipient of the message, <QoS Available> reflects the bottleneck of the resources currently available on a path. It can be used in a QUERY message, for example, to collect the available resources along a data path.
セクション4.3で説明されているように、QOS利用可能なオブジェクトは予備のメッセージ、応答メッセージ、またはクエリメッセージで移動し、現在利用可能なリソースに関する情報を収集することができます。この場合、利用可能なQoSは読み取りワイトオブジェクトです。つまり、利用可能なQOSに含まれるQSPECパラメーターが更新される可能性がありますが、削除することはできません。そのため、各QNEはこのQSPECオブジェクトのすべてのパラメーターを検査する必要があり、このQNEが利用できるリソースが特定のパラメーターが現在述べているものよりも少ない場合、QNEはこのパラメーターをそれに応じて適応させる必要があります。したがって、メッセージがメッセージの受信者に到着すると、<Qos利用可能>は、パスで現在利用可能なリソースのボトルネックを反映しています。たとえば、データパスに沿って利用可能なリソースを収集するために、クエリメッセージで使用できます。
When QoS Available travels in a RESPONSE message, it in fact just transports the result of a previous measurement performed by a RESERVE or QUERY message back to the initiator. Therefore, in this case, QoS Available is read-only. In one other instance described in Section 4.3.2 (Case 3), QoS Available is sent by the QNI in a RESERVE message as a read-only QSPEC object (see Section 4.3.2 for details).
利用可能なQoSが応答メッセージで移動すると、実際には、予備またはクエリメッセージによって実行された以前の測定の結果をイニシエーターに戻します。したがって、この場合、利用可能なQosは読み取り専用です。セクション4.3.2（ケース3）で説明されているもう1つの例では、利用可能なQoSは、QNIによってリザーブメッセージで読み取り専用QSPECオブジェクトとして送信されます（詳細についてはセクション4.3.2を参照）。
The QoS Reserved object reflects the resources that are being reserved. It is a read-only object and is always included in a RESPONSE message if QoS Desired is included in the RESERVE message (see Section 4.3 for details).
QoS予約オブジェクトは、予約されているリソースを反映しています。これは読み取り専用オブジェクトであり、QoSが必要なQoSが予備メッセージに含まれている場合、常に応答メッセージに含まれます（詳細についてはセクション4.3を参照）。
Minimum QoS does not have an equivalent in RSVP. It allows the QNI to define a range of acceptable QoS levels by including both the desired QoS value and the minimum acceptable QoS in the same message. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value. It is a read-only object, and may be included in a RESERVE message, RESPONSE message, or QUERY message (see Section 4.3 for details). The desired QoS is included with a QoS Desired and/or a QoS Available QSPEC object seeded to the desired QoS value. The minimum acceptable QoS value MAY be coded in the Minimum QoS QSPEC object. As the message travels towards the QNR, QoS Available is updated by QNEs on the path. If its value drops below the value of Minimum QoS, the reservation fails and is aborted. When this method is employed, the QNR signals back to the QNI the value of QoS Available attained in the end, because the reservation may need to be adapted accordingly (see Section 4.3 for details).
最小QoSはRSVPに相当するものではありません。これにより、QNIは、目的のQoS値と同じメッセージに最小許容可能なQOの両方を含めることにより、許容可能なQOSレベルの範囲を定義できます。「最小」という用語は一般的に使用されることに注意してください。損失率やレイテンシなどの一部のパラメーターでは、指定されているものが最大許容値であるためです。これは読み取り専用のオブジェクトであり、予約メッセージ、応答メッセージ、またはクエリメッセージに含まれる場合があります（詳細についてはセクション4.3を参照）。目的のQoSは、目的のQOS値にシードされたQOSの目的のQOSおよび/または利用可能なQSPECオブジェクトに含まれています。最小許容可能なQoS値は、最小QoS QSPECオブジェクトでコーディングできます。メッセージがQNRに向かって移動すると、利用可能なQOSがパス上のQNESによって更新されます。その値が最小QoSの値を下回ると、予約が失敗し、中止されます。この方法を採用すると、QNRはQNIに戻り、最終的に利用可能なQoSの値を獲得します。
Note that the relationship of QSPEC objects to RSVP objects is covered in Appendix A.
QSPECオブジェクトとRSVPオブジェクトの関係は、付録Aで説明していることに注意してください。
QSPEC parameters provide a common language for building QSPEC objects. This document defines a number of QSPEC parameters; additional parameters may be defined in separate QOSM specification documents. For example, QSPEC parameters are defined in [RFC5976] and [RFC5977].
QSPECパラメーターは、QSPECオブジェクトを構築するための共通言語を提供します。このドキュメントでは、多くのQSPECパラメーターを定義しています。追加のパラメーターは、個別のQOSM仕様ドキュメントで定義できます。たとえば、QSPECパラメーターは[RFC5976]および[RFC5977]で定義されています。
One QSPEC parameter, <TMOD>, is special. It provides a description of the traffic for which resources are reserved. This parameter must be included by the QNI, and it must be interpreted by all QNEs. All other QSPEC parameters are populated by a QNI if they are applicable to the underlying QoS desired. For these QSPEC parameters, the QNI sets the M flag if they must be interpreted by downstream QNEs. If QNEs cannot interpret the parameter, the reservation fails. QSPEC parameters populated by a QNI without the M flag set should be interpreted by downstream QNEs, but may be ignored if not understood.
1つのQSPECパラメーター<tmod>は特別です。リソースが予約されているトラフィックの説明を提供します。このパラメーターはQNIに含める必要があり、すべてのQNEによって解釈する必要があります。他のすべてのQSPECパラメーターには、QNIが希望するQOSに適用できる場合、QNIが入力されます。これらのQSPECパラメーターでは、QNIが下流QNESによって解釈する必要がある場合、Mフラグを設定します。QNESがパラメーターを解釈できない場合、予約は失敗します。MフラグセットのないQNIが入力するQSPECパラメーターは、ダウンストリームQNESによって解釈される必要がありますが、理解されていない場合は無視される場合があります。
In this document, the term 'interpret' means, in relation to RMF processing of QSPEC parameters, that the RMF processes the QSPEC parameter according to the commonly accepted normative procedures specified by references given for each QSPEC parameter. Note that a QNE need only interpret a QSPEC parameter if it is populated in the QSPEC object by the QNI; if not populated in the QSPEC, the QNE does not interpret it of course.
このドキュメントでは、「解釈」という用語は、QSPECパラメーターのRMF処理に関連して、RMFが各QSPECパラメーターに与えられた参照で指定された一般的に受け入れられる規範手順に従ってQSPECパラメーターを処理することを意味します。QNEは、QSPECパラメーターがQNIによってQSPECオブジェクトに入力されている場合にのみ解釈する必要があることに注意してください。QSPECに存在しない場合、QNEはもちろんそれを解釈しません。
Note that when an ingress QNE in a local domain defines a Local QSPEC and encapsulates the Initiator QSPEC, the QNEs in the interior local domain need only process the Local QSPEC and can ignore the Initiator (encapsulated) QSPEC. However, edge QNEs in the local domain indeed must interpret the QSPEC parameters populated in the Initiator QSPEC with the M flag set and should interpret QSPEC parameters populated in the Initiator QSPEC without the M flag set.
ローカルドメインの侵入QNEがローカルQSPECを定義し、イニシエーターQSPECをカプセル化する場合、内部ローカルドメインのQNESはローカルQSPECのみを処理する必要があり、イニシエーター（カプセル化）QSPECを無視できることに注意してください。ただし、ローカルドメインのEdge QNESは、Mフラグセットを使用してイニシエーターQSPECに存在するQSPECパラメーターを実際に解釈する必要があり、MフラグセットなしでイニシエーターQSPECに入力されたQSPECパラメーターを解釈する必要があります。
As described in the previous section, QoS parameters may be overwritten depending on which QSPEC object and which message they appear in.
前のセクションで説明したように、QSPECオブジェクトとそれらが表示されるメッセージに応じて、QoSパラメーターが上書きされる場合があります。
The <Traffic Model> (TMOD) parameter is mandatory for the QNI to include in the Initiator QSPEC and mandatory for downstream QNEs to interpret. The traffic description specified by the TMOD parameter is a container consisting of 5 sub-parameters [RFC2212]:
<トラフィックモデル>（TMOD）パラメーターは、QNIがイニシエーターQSPECに含めることが必須であり、下流QNESが解釈するために必須です。TMODパラメーターで指定されたトラフィックの説明は、5サブパラメータ[RFC2212]で構成されるコンテナです。
o rate (r) specified in octets per second o bucket size (b) specified in octets o peak rate (p) specified in octets per second o minimum policed unit (m) specified in octets o maximum packet size (MPS) specified in octets
o オクテットで指定されたレート（r）oバケツサイズ（b）オクテットで指定oピークレート（p）秒単位で指定されたo最小ポリシーユニット（m）オクテットで指定o最大パケットサイズ（MP）で指定されたオクテットで指定
The TMOD parameter takes the form of a token bucket of rate (r) and bucket size (b), plus a peak rate (p), minimum policed unit (m), and maximum packet size (MPS).
TMODパラメーターは、レートのトークンバケット（R）とバケットサイズ（B）の形式、さらにピークレート（P）、最小ポリシーユニット（M）、および最大パケットサイズ（MPS）の形をとっています。
Both b and r MUST be positive. The rate, r, is measured in octets of IP packets per second, and can range from 1 octet per second to as large as 40 teraoctets per second. The bucket depth, b, is also measured in octets and can range from 1 octet to 250 gigaoctets. The peak rate, p, is measured in octets of IP packets per second and has the same range and suggested representation as the bucket rate.
BとRの両方が正でなければなりません。レートrは、1秒あたりのIPパケットのオクテットで測定され、1秒あたり1オクテットから1秒あたり40テラクテットまでの範囲です。バケットの深さBはオクテットで測定され、1オクテットから250ギガクセットの範囲です。ピーク速度Pは、1秒あたりのIPパケットのオクテットで測定され、同じ範囲を持ち、バケットレートとして表現を示唆しています。
The peak rate is the maximum rate at which the source and any reshaping (defined below) may inject bursts of traffic into the network. More precisely, it is a requirement that for all time periods the amount of data sent cannot exceed MPS+pT, where MPS is the maximum packet size and T is the length of the time period. Furthermore, p MUST be greater than or equal to the token bucket rate, r. If the peak rate is unknown or unspecified, then p MUST be set to infinity.
ピークレートは、ソースと再形成（以下に定義）がネットワークにトラフィックのバーストを注入する可能性がある最大レートです。より正確には、すべての期間に送信されるデータの量がMPS PTを超えることはできないことが要件です。ここで、MPSは最大パケットサイズであり、Tは期間の長さです。さらに、Pはトークンバケットレート以上でなければなりませんr。ピークレートが不明または不明確である場合、pは無限に設定する必要があります。
The minimum policed unit, m, is an integer measured in octets. All IP packets less than size m will be counted, when policed and tested for conformance to the TMOD, as being of size m.
最小ポリシーユニットMは、オクテットで測定された整数です。サイズmであるとして、TMODへの適合について警察され、テストされた場合、サイズMよりも少ないすべてのIPパケットがカウントされます。
The maximum packet size, MPS, is the biggest packet that will conform to the traffic specification; it is also measured in octets. The flow MUST be rejected if the requested maximum packet size is larger than the MTU of the link. Both m and MPS MUST be positive, and m MUST be less than or equal to MPS.
最大パケットサイズのMPSは、トラフィック仕様に準拠する最大のパケットです。オクテットでも測定されます。要求された最大パケットサイズがリンクのMTUよりも大きい場合、フローを拒否する必要があります。MとMPの両方が肯定的でなければならず、MはMPS以下でなければなりません。
Policing compares arriving traffic against the TMOD parameters at the edge of the network. Traffic is policed to ensure it conforms to the token bucket. Reshaping attempts to restore the (possibly distorted) traffic's shape to conform to the TMOD parameters, and traffic that is in violation of the TMOD is discovered because the reshaping fails and the reshaping buffer overflows.
ポリシングは、ネットワークの端にあるTMODパラメーターに対してトラフィックの到着を比較します。トラフィックは、トークンバケットに適合するように警察されています。再形成する試みは、（おそらく歪んだ）トラフィックの形状を復元してTMODパラメーターに準拠し、TMODに違反しているトラフィックが再形成が故障し、バッファーの再フローが再フローするために発見されます。
The token bucket and peak rate parameters require that traffic MUST obey the rule that over all time periods, the amount of data sent cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token bucket parameters, MPS is the maximum packet size, and T is the length of the time period (note that when p is infinite, this reduces to the standard token bucket requirement). For the purposes of this accounting, links MUST count packets that are smaller than the minimum policing unit as being of size m. Packets that arrive at an element and cause a violation of the MPS + min[pT, rT+b-MPS] bound are considered non-conformant.
トークンバケットとピークレートのパラメーターは、トラフィックがすべての期間にわたって、送信されるデータの量がMPS Min [PT、RT B-MPS]を超えることはできないというルールに従わなければならないことが必要です。ここで、RとBはトークンバケットパラメーターであり、MPはMPSです最大パケットサイズ、およびtは期間の長さです（Pが無限である場合、これは標準のトークンバケット要件に減少することに注意してください）。この会計の目的のために、リンクは最小ポリシングユニットよりも小さいパケットをサイズmのものとしてカウントする必要があります。要素に到達し、MPS Min [PT、RT B-MPS]の違反を引き起こすパケットは、不適合と見なされます。
All 5 of the sub-parameters MUST be included in the TMOD parameter. The TMOD parameter can be set to describe the traffic source. If, for example, TMOD is set to specify bandwidth only, then set r = peak rate = p, b = large, and m = large. As another example, if TMOD is set for TCP traffic, then set r = average rate, b = large, and p = large.
サブパラメーターの5つすべてをTMODパラメーターに含める必要があります。TMODパラメーターは、トラフィックソースを記述するように設定できます。たとえば、TMODが帯域幅のみを指定するように設定されている場合、r =ピーク速度= p、b =大、およびm =大規模に設定します。別の例として、TMODがTCPトラフィックに設定されている場合、r =平均レート、b =大きく、p = vargeを設定します。
When the 5 TMOD sub-parameters are included in QoS Available, they provide information, for example, about the TMOD resources available along the path followed by a data flow. The value of TMOD at a QNE is an estimate of the TMOD resources the QNE has available for packets following the path up to the next QNE, including its outgoing link, if this link exists. Furthermore, the QNI MUST account for the resources of the ingress link, if this link exists. Computation of the value of this parameter SHOULD take into account all information available to the QNE about the path, taking into consideration administrative and policy controls, as well as physical resources.
5つのTMODサブパラメーターが利用可能なQoSに含まれている場合、たとえば、パスに沿って利用可能なTMODリソースとデータフローが続く情報を提供します。QNEでのTMODの値は、このリンクが存在する場合、発信リンクを含む次のQNEまでのパスに続いてQNEが利用できるTMODリソースの推定値です。さらに、このリンクが存在する場合、QNIは、入り口リンクのリソースを考慮する必要があります。このパラメーターの値の計算は、管理およびポリシーの管理、および物理リソースを考慮して、パスに関するQNEが利用できるすべての情報を考慮に入れる必要があります。
The output composed value is the minimum of the QNE's value and the input composed value for r, b, p, and MPS, and the maximum of the QNE's value and the input composed value for m. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal TMOD resources along the path from QNI to QNR.
出力構成値は、QNEの値の最小値とR、B、P、およびMPSの入力成分値、およびQNEの値の最大値とMの入力構成値です。この数量は、構成されたエンドツーエンドの場合、QNIからQNRへのパスに沿った最小のTMODリソースのQNR（または応答メッセージのQNI）に通知します。
Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>, where the second parameter (<TMOD-2>) is specified as could be needed to support some Diffserv applications. For example, it is typically assumed that Diffserv Expedited Forwarding (EF) traffic is shaped at the ingress by a single rate token bucket. Therefore, a single TMOD parameter is sufficient to signal Diffserv EF traffic. However, for Diffserv Assured Forwarding (AF) traffic, two sets of token bucket parameters are needed -- one for the average traffic and one for the burst traffic. [RFC2697] defines a Single Rate Three Color Marker (srTCM), which meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it does not exceed the CBS; yellow if it does exceed the CBS, but not the EBS; and red otherwise. [RFC2697] defines specific procedures using two token buckets that run at the same rate. Therefore, 2 TMOD parameters are sufficient to distinguish among 3 levels of drop precedence. An example is also described in the Appendix to [RFC2597].
2つのTMODパラメーターは、セクション5、<TMOD-1>および<TMOD-2>で定義されています。ここで、いくつかのDiffServアプリケーションをサポートするために必要な2番目のパラメーター（<TMOD-2>）が指定されています。たとえば、通常、Diffserv Expedited Forwarding（EF）トラフィックは、単一のレートトークンバケットによって侵入で形成されると想定されています。したがって、単一のTMODパラメーターでは、DiffServ EFトラフィックを信号するのに十分です。ただし、DiffServ Assured Forwarding（AF）トラフィックの場合、2セットのトークンバケットパラメーターが必要です。1つは平均トラフィック用、もう1つはバーストトラフィック用です。[RFC2697]は、トラフィックストリームを計算し、3つのトラフィックパラメーター、コミットされた情報レート（CIR）、コミットされたバーストサイズ（CBS）、および超過バーストサイズ（EBS）に従ってパケットをマークする単一レート3色マーカー（SRTCM）を定義します。、緑、黄色、または赤のいずれかであること。CBSを超えない場合、パケットは緑色にマークされています。CBSを超えている場合は黄色ですが、EBSではなく。それ以外の場合は赤。[RFC2697]は、同じ速度で実行される2つのトークンバケットを使用して特定の手順を定義します。したがって、3レベルのドロップ優先順位を区別するには、2つのTMODパラメーターで十分です。例については、[RFC2597]の付録にも説明されています。
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC parameters describing the desired path latency, path jitter, packet loss ratio, and path packet error ratio, respectively. Since these parameters are cumulative, an individual QNE cannot decide whether the desired path latency, etc., is available, and hence they cannot decide whether a reservation fails. Rather, when these parameters are included in <Desired QoS>, the QNI SHOULD also include corresponding parameters in a QoS Available QSPEC object in order to facilitate collecting this information.
<Path Latency>、<Path Jitter>、<Path Plr>、および<Path PAR>は、それぞれ目的のパスレイテンシ、パスジッター、パケット損失比、パスパケットエラー比を記述するQSPECパラメーターです。これらのパラメーターは累積的であるため、個々のQNEは目的のパスレイテンシなどが利用可能かどうかを決定できないため、予約が失敗するかどうかを決定できません。むしろ、これらのパラメーターが<希望のQoS>に含まれている場合、QNIには、この情報の収集を容易にするために、利用可能なQSPECオブジェクトに対応するパラメーターも含める必要があります。
The <Path Latency> parameter accumulates the latency of the packet forwarding process associated with each QNE, where the latency is defined to be the mean packet delay, measured in microseconds, added by each QNE. This delay results from the combination of link propagation delay, packet processing, and queuing. Each QNE MUST add the propagation delay of its outgoing link, if this link exists.
<Path Latency>パラメーターは、各QNEに関連付けられたパケット転送プロセスの遅延を蓄積します。ここで、各QNEで追加されたマイクロ秒で測定された平均パケット遅延と定義されます。この遅延は、リンク伝播遅延、パケット処理、キューイングの組み合わせから生じます。このリンクが存在する場合、各QNEは、発信リンクの伝播遅延を追加する必要があります。
Furthermore, the QNI SHOULD add the propagation delay of the ingress link, if this link exists. The composition rule for the <Path Latency> parameter is summation with a clamp of (2^32) - 1 on the maximum value. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet delay along the path from QNI to QNR. The purpose of this parameter is to provide a minimum path latency for use with services that provide estimates or bounds on additional path delay [RFC2212].
さらに、QNIは、このリンクが存在する場合、侵入リンクの伝播遅延を追加する必要があります。<パスレイテンシ>パラメーターの構成ルールは、最大値に（2^32）-1のクランプを含む合計です。この数量は、構成されたエンドツーエンドの場合、QNIからQNRへのパスに沿った最小限のパケット遅延のQNR（または応答メッセージのQNI）に通知します。このパラメーターの目的は、追加のパス遅延[RFC2212]で推定または境界を提供するサービスで使用するための最小パスレイテンシを提供することです。
The <Path Jitter> parameter accumulates the jitter of the packet forwarding process associated with each QNE, where the jitter is defined to be the nominal jitter, measured in microseconds, added by each QNE. IP packet jitter, or delay variation, is defined in [RFC3393], Section 3.4 (Type-P-One-way-ipdv), and where the [RFC3393] selection function includes the packet with minimum delay such that the distribution is equivalent to 2-point delay variation in [Y.1540]. The suggested evaluation interval is 1 minute. This jitter results from packet-processing limitations, and includes any variable queuing delay that may be present. Each QNE MUST add the jitter of its outgoing link, if this link exists. Furthermore, the QNI SHOULD add the jitter of the ingress link, if this link exists. The composition method for the <Path Jitter> parameter is the combination of several statistics describing the delay variation distribution with a clamp on the maximum value (note that the methods of accumulation and estimation of nominal QNE jitter are specified in clause 8 of [Y.1541]). This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the nominal packet jitter along the path from QNI to QNR. The purpose of this parameter is to provide a nominal path jitter for use with services that provide estimates or bounds on additional path delay [RFC2212].
<Path Jitter>パラメーターは、各QNEに関連付けられたパケット転送プロセスのジッターを蓄積します。ここで、ジッターは各QNEによって追加されたマイクロ秒で測定された名目ジッターであると定義されます。IPパケットジッター、または遅延バリエーションは[RFC3393]、セクション3.4（タイプ-P-One-Way-IPDV）で定義されています。[RFC3393]選択関数には、分布が同等であるように最小遅延のパケットが含まれています。[Y.1540]の2点遅延変動。推奨される評価間隔は1分です。このジッターは、パケット処理の制限から生じ、存在する可能性のある可変キューイング遅延が含まれます。このリンクが存在する場合は、各QNEが発信リンクのジッターを追加する必要があります。さらに、QNIは、このリンクが存在する場合、イングレスリンクのジッターを追加する必要があります。<Path Jitter>パラメーターの構成方法は、最大値のクランプを使用した遅延変動分布を記述するいくつかの統計の組み合わせです（蓄積と推定の方法と推定の方法は、[Yの節8で指定されていることに注意してください。1541]）。この数量は、構成されたエンドツーエンドの場合、QNIからQNRへのパスに沿った公称パケットジッターのQNR（または応答メッセージのQNI）に通知します。このパラメーターの目的は、追加のパス遅延[RFC2212]で推定または境界を提供するサービスで使用するための公称パスジッターを提供することです。
The <Path PLR> parameter is the unit-less ratio of total lost IP packets to total transmitted IP packets. <Path PLR> accumulates the packet loss ratio (PLR) of the packet-forwarding process associated with each QNE, where the PLR is defined to be the PLR added by each QNE. Each QNE MUST add the PLR of its outgoing link, if this link exists. Furthermore, the QNI MUST add the PLR of the ingress link, if this link exists. The composition rule for the <Path PLR> parameter is summation with a clamp on the maximum value. (This assumes sufficiently low PLR values such that summation error is not significant; however, a more accurate composition function is specified in clause 8 of [Y.1541].) This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet PLR along the path from QNI to QNR.
<PATH PLR>パラメーターは、総送信IPパケットに対する総失われたIPパケットの単位のない比率です。<PATH PLR>は、各QNEに関連付けられたパケットフォワードプロセスのパケット損失比（PLR）を蓄積します。ここで、PLRは各QNEによって追加されたPLRと定義されます。このリンクが存在する場合、各QNEは、発信リンクのPLRを追加する必要があります。さらに、QNIは、このリンクが存在する場合、侵入リンクのPLRを追加する必要があります。<Path PLR>パラメーターの構成ルールは、最大値のクランプを備えた合計です。（これは、合計誤差が有意ではないように十分に低いPLR値を想定しています。ただし、[Y.1541]の条項8でより正確な組成関数が指定されています。）この量は、エンドツーエンドの場合、QNR（QNIからQNRへのパスに沿った最小パケットPLRの応答メッセージのQNI）。
Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total errored IP packet outcomes to the total of successful IP packet transfer outcomes plus errored IP packet outcomes in a population of interest, with a resolution of at least 10^-9. If lesser resolution is available in a value, the unused digits MUST be set to zero. Note that the number of errored packets observed is directly related to the confidence in the result. The <Path PER> parameter accumulates the packet error ratio (PER) of the packet forwarding process associated with each QNE, where the PER is defined to be the PER added by each QNE. Each QNE MUST add the PER of its outgoing link, if this link exists. Furthermore, the QNI SHOULD add the PER of the ingress link, if this link exists. The composition rule for the <Path PER> parameter is summation with a clamp on the maximum value. (This assumes sufficiently low PER values such that summation error is not significant; however, a more accurate composition function is specified in clause 8 of [Y.1541].) This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet PER along the path from QNI to QNR.
パケットエラー比[Y.1540、Y.1541]は、IPパケット転送の成功成果の合計と、少なくとも少なくとも解像度の解像度で、IPパケット転送の成功とエラーのあるIPパケットアウトカムとの合計との合計との単位のない比率です。10^-9。より少ない解像度が値で使用可能な場合、未使用の数字をゼロに設定する必要があります。観察されたエラーパケットの数は、結果の信頼性に直接関係していることに注意してください。<Path Per>パラメーターは、各QNEに関連付けられたパケット転送プロセスのパケットエラー比（PER）を蓄積します。ここで、Perは各QNEによって追加されたPERと定義されます。このリンクが存在する場合、各QNEは、発信リンクのごとを追加する必要があります。さらに、QNIは、このリンクが存在する場合、侵入リンクごとを追加する必要があります。<Path Per>パラメーターの構成ルールは、最大値にクランプが付いた合計です。（これは、合計誤差が有意ではないように値ごとに十分に低いと想定しています。ただし、[Y.1541]の条項8でより正確な組成関数が指定されています。）この量は、エンドツーエンドの場合、QNRを通知します（QNIからQNRへのパスに沿った最小パケットの応答メッセージのqni）。
The slack term parameter is the difference between desired delay and delay obtained by using bandwidth reservation, and it is used to reduce the resource reservation for a flow [RFC2212].
Slack用語パラメーターは、帯域幅予約を使用して得られる遅延と遅延の差であり、フローのリソース予約を減らすために使用されます[RFC2212]。
An application MAY like to reserve resources for packets and also specify a specific traffic-handling behavior, such as <Excess Treatment>. In addition, as discussed in Section 3.1, an application MAY like to define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state / messaging processing rules, as defined in Section 5.2 of [RFC5974]. Note, however, that new QoS NSLP message processing rules can only be defined in extensions to the QoS NSLP. As with constraints parameters and other QSPEC parameters, Traffic Handling Directives parameters may be defined in QOSM specifications in order to provide support for QOSM-specific resource management functions. Such QOSM-specific parameters are already defined, for example, in [RFC5976], [RFC5977], and [CL-QOSM]. Generally, a Traffic Handling Directives parameters is expected to be set by the QNI in <QoS Desired>, and to not be included in <QoS Available>. If such a parameter is included in <QoS Available>, QNEs may change their value.
アプリケーションは、パケットのリソースを予約し、<超過治療>などの特定の交通処理動作を指定することもできます。さらに、セクション3.1で説明したように、アプリケーションは、[RFC5974]のセクション5.2で定義されているように、QoS NSLPが基礎となるQoS NSLPシグナリング状態 /メッセージ処理ルール内でセマンティクスを実行するRMFトリガーを定義することを好む場合があります。ただし、新しいQOS NSLPメッセージ処理ルールは、QoS NSLPの拡張でのみ定義できることに注意してください。制約パラメーターやその他のQSPECパラメーターと同様に、QOSM固有のリソース管理機能をサポートするために、トラフィックハンドリングディレクティブパラメーターをQOSM仕様で定義することができます。このようなQoSM固有のパラメーターは、たとえば[RFC5976]、[RFC5977]、および[Cl-QOSM]で既に定義されています。一般に、トラフィックハンドリングディレクティブパラメーターは、<QOS希望>のQNIによって設定され、<QOS利用可能>に含まれないと予想されます。このようなパラメーターが<QOSavailable>に含まれている場合、qnesは値を変更する可能性があります。
The <Preemption Priority> parameter is the priority of the new flow compared with the <Defending Priority> of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The <Defending Priority> parameter is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equal to the defending priority. <Admission Priority> and <RPH Priority> provide an essential way to differentiate flows for emergency services, Emergency Telecommunications Service (ETS), E911, etc., and assign them a higher admission priority than normal priority flows and best-effort priority flows.
<Preemption Priority>パラメーターは、以前に認められたフローの<防御優先度>と比較して、新しいフローの優先度です。フローが認められると、先制の優先順位は無関係になります。<防御優先度>パラメーターは、新しいフローの先制優先度と比較するために使用されます。特定のフローの場合、その先制優先度は常に防御の優先順位以下でなければなりません。<入場優先度>および<RPH Priority>緊急サービス、緊急時電子通信サービス（ETS）、E911などのフローを区別するための不可欠な方法を提供し、通常の優先度のフローと最良の優先度フローよりも高い入場優先度を割り当てます。
The <Excess Treatment> parameter describes how the QNE will process out-of-profile traffic. Excess traffic MAY be dropped, shaped, and/or re-marked.
<超過治療>パラメーターは、QNEがプロファイル外のトラフィックをどのように処理するかを説明します。余分なトラフィックは、落下、形状、および/または再マークされる場合があります。
An application MAY like to reserve resources for packets with a particular Diffserv per-hop behavior (PHB) [RFC2475]. Note that PHB class is normally set by a downstream QNE to tell the QNI how to mark traffic to ensure the treatment that is designated by admission control; however, setting of the parameter by the QNI is not precluded. An application MAY like to reserve resources for packets with a particular QoS class, e.g., Y.1541 QoS class [Y.1541] or Diffserv-aware MPLS traffic engineering (DSTE) class type [RFC3564, RFC4124]. These parameters are useful in various QOSMs, e.g., [RFC5976], [RFC5977], and other QOSMs yet to be defined (e.g., DSTE-QOSM). This is intended to provide guidelines to QOSMs on how to encode these parameters; use of the PHB class parameter is illustrated in the example in the following section.
アプリケーションは、特定のDiffserv Per Hopの動作（PHB）[RFC2475]を使用して、パケット用のリソースを予約することを好む場合があります。PHBクラスは通常、下流のQNEによって設定されて、QNIにトラフィックをマークする方法を伝えて、入場制御によって指定された治療を確保する方法を伝えることに注意してください。ただし、QNIによるパラメーターの設定は排除されていません。アプリケーションは、特定のQoSクラス、例えばY.1541 QOSクラス[Y.1541]またはDiffserv-Aware MPLSトラフィックエンジニアリング（DSTE）クラスタイプ[RFC3564、RFC4124]を備えたパケット用のリソースを予約することができます。これらのパラメーターは、たとえば[RFC5976]、[RFC5977]、およびまだ定義されていない他のQoSM（例：DSTE-QOSM）で役立ちます。これは、これらのパラメーターをエンコードする方法に関するQOSMSにガイドラインを提供することを目的としています。PHBクラスパラメーターの使用については、次のセクションの例に示します。
This section illustrates the operation and use of the QSPEC within the NSLP. The example configuration in shown in Figure 2.
このセクションでは、NSLP内のQSPECの操作と使用について説明します。図2に示す例の構成の例。
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | XG | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/
Figure 2: Example Configuration of QoS-NSLP/QSPEC Operation
図2：QOS-NSLP/QSPEC操作の例の例
In this configuration, a laptop computer and a handheld wireless device are the endpoints for some application that has QoS requirements. Assume initially that the two endpoints are stationary during the application session, later we consider mobile endpoints.
この構成では、ラップトップコンピューターとハンドヘルドワイヤレスデバイスが、QoS要件を持つアプリケーションのエンドポイントです。最初は、2つのエンドポイントがアプリケーションセッション中に静止していると仮定し、後でモバイルエンドポイントを検討します。
For this session, the laptop computer is connected to a home network that has no QoS support. The home network is connected to a CableLabs-type cable access network with dynamic QoS (DQOS) support, such as specified in the [DQOS] for cable access networks. That network is connected to a Diffserv core network that uses the Resource Management in Diffserv QoS Model [RFC5977]. On the other side of the Diffserv core is a wireless access network built on generation "X" technology with QoS support as defined by generation "X". And finally, the handheld endpoint is connected to the wireless access network.
このセッションでは、ラップトップコンピューターはQoSサポートのないホームネットワークに接続されています。ホームネットワークは、ケーブルアクセスネットワークの[DQOS]で指定されているような動的QoS（DQOS）サポートを備えたCableLabsタイプのケーブルアクセスネットワークに接続されています。そのネットワークは、DiffServ QoSモデル[RFC5977]でリソース管理を使用するDiffServコアネットワークに接続されています。DiffServ Coreの反対側には、Generation "x"で定義されているQoSサポートを備えたGeneration "x"テクノロジーに構築されたワイヤレスアクセスネットワークがあります。そして最後に、ハンドヘルドエンドポイントはワイヤレスアクセスネットワークに接続されています。
We assume that the laptop is the QNI, and the handheld device is the QNR. The QNI will signal an Initiator QSPEC object to achieve the QoS desired on the path.
ラップトップはQNIであり、ハンドヘルドデバイスはQNRであると仮定します。QNIは、パスで望ましいQOSを実現するために、イニシエーターQSPECオブジェクトを信号します。
The QNI sets QoS Desired, QoS Available, and possibly Minimum QoS QSPEC objects in the Initiator QSPEC, and initializes QoS Available to QoS Desired. Each QNE on the path reads and interprets those parameters in the Initiator QSPEC and checks to see if QoS Available resources can be reserved. If not, the QNE reduces the respective parameter values in QoS Available and reserves these values. The minimum parameter values are given in Minimum QoS, if populated; they are zero if Minimum QoS is not included. If one or more parameters in QoS Available fails to satisfy the corresponding minimum values in Minimum QoS, the QNE generates a RESPONSE message to the QNI and the reservation is aborted. Otherwise, the QNR generates a RESPONSE to the QNI with the QoS Available for the reservation. If a QNE cannot reserve QoS Desired resources, the reservation fails.
QNIは、Initiator QSPECのQOS、利用可能なQOS、およびおそらく最小QOS QSPECオブジェクトを設定し、QOSが使用できるQOSを初期化します。パス上の各QNEは、イニシエーターQSPECのこれらのパラメーターを読み取り、解釈し、QOS利用可能なリソースを予約できるかどうかを確認します。そうでない場合、QNEは利用可能なQOSのそれぞれのパラメーター値を削減し、これらの値を予約します。最小パラメーター値は、人口がかかった場合、最小QOで与えられます。最小QoSが含まれていない場合、それらはゼロです。利用可能なQoSの1つ以上のパラメーターが最小QoSの対応する最小値を満たしていない場合、QNEはQNIへの応答メッセージを生成し、予約は中止されます。それ以外の場合、QNRはQNIへの応答を生成し、予約に使用できるQOSを使用します。QNEがQOSの希望リソースを予約できない場合、予約は失敗します。
The QNI populates QSPEC parameters to ensure correct treatment of its traffic in domains down the path. Let us assume the QNI wants to achieve QoS guarantees similar to IntServ Controlled Load service, and also is interested in what path latency it can achieve. Additionally, to ensure correct treatment further down the path, the QNI includes <PHB Class> in <QoS Desired>. The QNI therefore includes in the QSPEC
QNIは、QSPECパラメーターに入力して、パスのドメインでのトラフィックの正しい処理を確保します。QNIは、IntServ制御ロードサービスと同様のQoS保証を達成したいと考えています。また、達成できるパスレイテンシにも関心があります。さらに、パスのさらに正しい治療を確保するために、QNIには<QOS希望>の<PHBクラス>が含まれます。したがって、QNIにはQSPECに含まれます
QoS Desired = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
Since <Path Latency> and <PHB Class> are not vital parameters from the QNI's perspective, it does not raise their M flags.
<Path Latency>および<PHBクラス>はQNIの観点からの重要なパラメーターではないため、Mフラグを上げません。
There are three possibilities when a RESERVE message is received at a QNE at a domain border; they are described in the example:
ドメイン境界のQNEで予備のメッセージが受信される場合、3つの可能性があります。それらは例で説明されています：
- the QNE just leaves the QSPEC as is.
- QNEは、QSPECをそのまま残します。
- the QNE can add a Local QSPEC and encapsulate the Initiator QSPEC (see discussion in Section 4.1; this is new in QoS NSLP -- RSVP does not do this).
- QNEはローカルQSPECを追加して、イニシエーターQSPECをカプセル化できます（セクション4.1の説明を参照してください。これはQOS NSLPで新しいです-RSVPはこれを行いません）。
- the QNE can 'hide' the initiator RESERVE message so that only the edge QNE processes the initiator RESERVE message, which then bypasses intermediate nodes between the edges of the domain and issues its own local RESERVE message (see Section 3.3.1 of [RFC5974]). For this new local RESERVE message, the QNE acts as the QNI, and the QSPEC in the domain is an Initiator QSPEC. A similar procedure is also used by RSVP in making aggregate reservations, in which case there is not a new intra-domain (aggregate) RESERVE for each newly arriving inter-domain (per-flow) RESERVE, but the aggregate reservation is updated by the border QNE (or QNI) as need be. This is also how RMD works [RFC5977].
- QNEは、イニシエーターリザーブメッセージを「非表示」できるため、エッジQNEのみがイニシエーターリザーブメッセージを処理し、ドメインのエッジ間の中間ノードをバイパスし、独自のローカルリザーブメッセージを発行します（[RFC5974]のセクション3.3.1を参照してください。）。この新しいローカルリザーブメッセージの場合、QNEはQNIとして機能し、ドメイン内のQSPECはイニシエーターQSPECです。同様の手順は、RSVPが総予約を行う際にも使用されます。この場合、新しく到着する各ドメイン（流量あたり）保護区ごとに新しいドメイン（総計）予備がありませんが、総予約は総予約が更新されます。必要に応じて境界qne（またはqni）。これは、RMDの仕組みでもあります[RFC5977]。
For example, at the RMD domain, a local RESERVE with its own RMD Initiator QSPEC corresponding to the RMD-QOSM is generated based on the original Initiator QSPEC according to the procedures described in Section 4.5 of [RFC5974] and in [RFC5977]. The ingress QNE to the RMD domain maps the TMOD parameters contained in the original Initiator QSPEC to the equivalent TMOD parameter representing only the peak bandwidth in the Local QSPEC. The local RMD QSPEC for example also needs <PHB Class>, which in this case was provided by the QNI.
たとえば、RMDドメインでは、RMD-QOSMに対応する独自のRMDイニシエーターQSPECを備えたローカルリザーブは、[RFC5974]のセクション4.5および[RFC5977]で説明されている手順に従って、元のイニシエーターQSPECに基づいて生成されます。RMDドメインへのIngress QNEは、元のイニシエーターQSPECに含まれるTMODパラメーターをマップし、ローカルQSPECのピーク帯域幅のみを表す同等のTMODパラメーターにマップします。たとえば、ローカルRMD QSPECには<PHBクラス>も必要です。この場合、QNIによって提供されました。
Furthermore, if the node can, at the egress to the RMD domain, it updates QoS Available on behalf of the entire RMD domain. If it cannot (since the M flag is not set for <Path Latency>), it raises the parameter-specific, Not Supported N flag, warning the QNR that the final latency value in QoS Available is imprecise.
さらに、ノードがRMDドメインへの出口で、RMDドメイン全体に代わって利用可能なQOを更新できる場合。できない場合（Mフラグが<パスレイテンシ>に設定されていないため）、パラメーター固有のサポートされていないnフラグを上げ、QNRに利用可能なQoSの最終的なレイテンシ値が不正確であることを警告します。
In the XG domain, the Initiator QSPEC is translated into a local QSPEC using a similar procedure as described above. The Local QSPEC becomes the current QSPEC used within the XG domain, and the Initiator QSPEC is encapsulated. This saves the QNEs within the XG domain the trouble of re-translating the Initiator QSPEC, and simplifies processing in the local domain. At the egress edge of the XG domain, the translated Local QSPEC is removed, and the Initiator QSPEC returns to the number one position.
XGドメインでは、イニシエーターQSPECは、上記のように同様の手順を使用してローカルQSPECに変換されます。ローカルQSPECは、XGドメイン内で使用される現在のQSPECになり、イニシエーターQSPECがカプセル化されています。これにより、XGドメイン内のQNESがイニシエーターQSPECを再翻訳する問題を節約し、ローカルドメインでの処理を簡素化します。XGドメインの出口エッジでは、翻訳されたローカルQSPECが削除され、イニシエーターQSPECはナンバーワンの位置に戻ります。
If the reservation was successful, eventually the RESERVE request arrives at the QNR (otherwise, the QNE at which the reservation failed aborts the RESERVE and sends an error RESPONSE back to the QNI). If the RII was included in the QoS NSLP message, the QNR generates a positive RESPONSE with QSPEC objects QoS Reserved and QoS Available. The parameters appearing in QoS Reserved are the same as in QoS Desired, with values copied from QoS Available. Hence, the QNR includes the following QSPEC objects in the RESPONSE:
予約が成功した場合、最終的にリザーブリクエストはQNRに到着します（そうでなければ、予約が失敗したQNEが予備を中止し、QNIにエラー応答を送り返します）。RIIがQOS NSLPメッセージに含まれている場合、QNRはQSPECオブジェクトQOSを予約し、QOSを使用して肯定的な応答を生成します。予約されているQOSに表示されるパラメーターは、QOSが希望するQOSと同じであり、QOSからコピーされた値が利用可能です。したがって、QNRには、応答に次のQSPECオブジェクトが含まれています。
QoS Reserved = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
If the handheld device on the right of Figure 2 is mobile, and moves through different XG wireless networks, then the QoS might change on the path since different XG wireless networks might support different QOSMs. As a result, QoS NSLP/QSPEC processing will have to renegotiate the QoS Available on the path. From a QSPEC perspective, this is like a new reservation on the new section of the path and is basically the same as any other rerouting event -- to the QNEs on the new path, it looks like a new reservation. That is, in this mobile scenario, the new segment may support a different QOSM than the old segment, and the QNI would now signal a new reservation explicitly (or implicitly with the next refreshing RESERVE message) to account for the different QOSM in the XG wireless domain. Further details on rerouting are specified in [RFC5974].
図2の右側のハンドヘルドデバイスがモバイルであり、異なるXGワイヤレスネットワークを移動する場合、異なるXGワイヤレスネットワークが異なるQoSMをサポートする可能性があるため、QoSがパス上で変化する可能性があります。その結果、QoS NSLP/QSPEC処理は、パスで利用可能なQOを再交渉する必要があります。QSPECの観点から、これはパスの新しいセクションの新しい予約のようなものであり、基本的に他の再ルーティングイベントと同じです - 新しいパスのQNESまで、それは新しい予約のように見えます。つまり、このモバイルシナリオでは、新しいセグメントは古いセグメントとは異なるQoSMをサポートする可能性があり、QNIはXGの異なるQOSMを説明するために明示的に（または次のリフレッシュリザーブメッセージと暗黙的に）新しい予約を示します。ワイヤレスドメイン。再ルーティングの詳細については、[RFC5974]で指定されています。
For bit-level examples of QSPECs, see the documents specifying QOSMs: [CL-QOSM], [RFC5976], and [RFC5977].
QSPECのビットレベルの例については、QoSMを指定するドキュメントを参照してください：[Cl-QOSM]、[RFC5976]、および[RFC5977]。
Three flags are used in QSPEC processing, the M flag, E flag, and N flag, which are explained in this section. The QNI sets the M flag for each QSPEC parameter it populates that MUST be interpreted by downstream QNEs. If a QNE does not support the parameter, it sets the N flag and fails the reservation. If the QNE supports the parameter but cannot meet the resources requested by the parameter, it sets the E flag and fails the reservation.
このセクションで説明されているQSPEC処理、Mフラグ、Eフラグ、およびNフラグで3つのフラグが使用されています。QNIは、下流QNESによって解釈する必要がある各QSPECパラメーターのMフラグを設定します。QNEがパラメーターをサポートしていない場合、Nフラグを設定し、予約に失敗します。QNEがパラメーターをサポートしているが、パラメーターによって要求されたリソースを満たすことができない場合、Eフラグを設定し、予約に失敗します。
If the M flag is not set, the downstream QNE SHOULD interpret the parameter. If the QNE does not support the parameter, it sets the N flag and forwards the reservation. If the QNE supports the parameter but cannot meet the resources requested by the parameter, it sets the E flag and fails the reservation.
Mフラグが設定されていない場合、下流のQNEはパラメーターを解釈する必要があります。QNEがパラメーターをサポートしていない場合、Nフラグを設定し、予約を転送します。QNEがパラメーターをサポートしているが、パラメーターによって要求されたリソースを満たすことができない場合、Eフラグを設定し、予約に失敗します。
A QNE at the edge of a local domain may either a) translate the Initiator QSPEC into a Local QSPEC and encapsulate the Initiator QSPEC in the RESERVE message, or b) 'hide' the Initiator QSPEC through the local domain and reserve resources by generating a new RESERVE message through the local domain containing the Local QSPEC. In either case, the Initiator QSPEC parameters are interpreted at the local domain edges.
ローカルドメインの端にあるQNEは、a）イニシエーターQSPECをローカルQSPECに変換し、予備メッセージのイニシエーターQSPECをカプセル化するか、b）ローカルドメインを介してイニシエーターQSPECを「非表示」し、リソースを生成してリソースを「非表示」します。ローカルQSPECを含むローカルドメインを介した新しい予備メッセージ。どちらの場合でも、イニシエーターQSPECパラメーターはローカルドメインのエッジで解釈されます。
A Local QSPEC may allow a simpler control plane in a local domain. The edge nodes in the local domain must interpret the Initiator QSPEC parameters. They can either initiate a parallel session with Local QSPEC or define a Local QSPEC and encapsulate the Initiator QSPEC, as illustrated in Figure 3. The Initiator/Local QSPEC bit identifies whether the QSPEC is an Initiator QSPEC or a Local QSPEC. The QSPEC Type indicates, for example, that the initiator of the local QSPEC uses to a certain QOSM, e.g., CL-QSPEC Type. It may be useful for the QNI to signal a QSPEC Type based on some QOSM (which will necessarily entail populating certain QOSM-related parameters) so that a downstream QNE can chose amongst various QOSM-related processes it might have. That is, the QNI populates the QSPEC Type, e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to 'Initiator'. A local QNE can decide, for whatever reasons, to insert a Local QSPEC Type, e.g., RMD-QSPEC Type, and set the local QSPEC Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 'Local' (and encapsulate the Initiator QSPEC in the RESERVE or whatever NSLP message).
ローカルQSPECは、ローカルドメイン内のよりシンプルな制御プレーンを可能にする場合があります。ローカルドメインのエッジノードは、イニシエーターQSPECパラメーターを解釈する必要があります。図3に示すように、ローカルQSPECとの並列セッションを開始するか、ローカルQSPECを定義し、イニシエーターQSPECをカプセル化することができます。イニシエーター/ローカルQSPECビットは、QSPECがイニシエーターQSPECかローカルQSPECであるかを識別します。QSPECタイプは、たとえば、ローカルQSPECのイニシエーターが特定のQoSM（たとえばCL-QSPECタイプ）に使用することを示しています。QNIがQOSMに基づいてQSPECタイプを信号にしている場合（特定のQOSM関連のパラメーターに依存することを必然的に伴う）、ダウンストリームQNEがQOSM関連のさまざまなプロセスから選択できるようにすることが役立つ場合があります。つまり、QNIはQSPECタイプ、たとえばCL-QSPECタイプに入力し、イニシエーター/ローカルQSPECビットを「イニシエーター」に設定します。ローカルQNEは、何らかの理由でローカルQSPECタイプ、例えばRMD-QSPECタイプを挿入し、ローカルQSPECタイプ= RMD-QSPECを設定し、イニシエーター/ローカルQSPECビットを「ローカル」に設定することを決定できます（そして、予備のイニシエーターQSPECまたはNSLPメッセージ）。
+--------------------------------+\
| QSPEC Type, QSPEC Procedure | \
+--------------------------------+ / Common QSPEC Header
| Init./Local QSPEC bit=Local |/
+================================+\
| Local-QSPEC Parameter 1 | \
+--------------------------------+ \
| .... | Local-QSPEC Parameters
+--------------------------------+ /
| Local-QSPEC Parameter n | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC Type, QSPEC Procedure| |
| +----------------------------+ |
| | Init./Local QSPEC bit=Init.| |
| +============================+ |
| | | | Encapsulated Initiator QSPEC
| | .... | |
| +----------------------------+ |
+--------------------------------+
Figure 3: Defining a Local QSPEC
図3：ローカルQSPECの定義
Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. Thus, the type of the QSPEC may change within a local domain. Hence:
ここでは、QOS-NSLPは1つのQSPECをRMFまで見て渡すだけです。したがって、QSPECのタイプはローカルドメイン内で変化する場合があります。したがって：
o the QNI signals its QoS requirements with the Initiator QSPEC,
o QNIは、イニシエーターQSPECを使用してQoS要件を信号します。
o the ingress edge QNE in the local domain translates the Initiator QSPEC parameters to equivalent parameters in the local QSPEC,
o ローカルドメインのIngress Edge QNEは、イニシエーターQSPECパラメーターをローカルQSPECの等価パラメーターに変換します。
o the QNEs in the local domain only interpret the Local QSPEC parameters, and
o ローカルドメインのQNESは、ローカルQSPECパラメーターのみを解釈し、
o the egress QNE in the local domain processes the Local QSPEC and also interprets the QSPEC parameters in the Initiator QSPEC.
o ローカルドメインの出力QNEは、ローカルQSPECを処理し、イニシエーターQSPECのQSPECパラメーターを解釈します。
The Local QSPEC MUST be consistent with the Initiator QSPEC. That is, it MUST NOT specify a lower level of resources than specified by the Initiator QSPEC. For example, in RMD the TMOD parameters contained in the original Initiator QSPEC are mapped to the equivalent TMOD parameter representing only the peak bandwidth in the Local QSPEC.
ローカルQSPECは、イニシエーターQSPECと一致する必要があります。つまり、イニシエーターQSPECで指定されているよりも低いレベルのリソースを指定してはなりません。たとえば、RMDでは、元のイニシエーターQSPECに含まれるTMODパラメーターは、ローカルQSPECのピーク帯域幅のみを表す同等のTMODパラメーターにマッピングされます。
Note that it is possible to use both a) hiding a QSPEC through a local domain by initiating a new RESERVE at the domain edge, and b) defining a Local QSPEC and encapsulating the Initiator QSPEC, as defined above. However, it is not expected that both the hiding and encapsulating functions would be used at the same time for the same flow.
a）ドメインエッジで新しいリザーブを開始することにより、ローカルドメインを介してQSPECを隠すこと、およびb）ローカルQSPECを定義し、上記のようにイニシエーターQSPECをカプセル化することができることに注意してください。ただし、同じフローに対して、非表示関数とカプセル化機能の両方が同時に使用されることは予想されません。
The support of Local QSPECs is illustrated in Figure 4 for a single flow to show where the Initiator and Local QSPECs are used. The QNI initiates an end-to-end, inter-domain QoS NSLP RESERVE message containing the Initiator QSPEC for the Y.1541 QOSM. As illustrated in Figure 4, the RESERVE message crosses multiple domains supporting different QOSMs. In this illustration, the Initiator QSPEC arrives in a QoS NSLP RESERVE message at the ingress node of the local-QOSM domain. At the ingress edge node of the local-QOSM domain, the end-to-end, inter-domain QoS-NSLP message triggers the generation of a Local QSPEC, and the Initiator QSPEC is encapsulated within the messages signaled through the local domain. The local QSPEC is used for QoS processing in the local-QOSM domain, and the Initiator QSPEC is used for QoS processing outside the local domain.
ローカルQSPECのサポートを図4に示します。単一のフローについては、イニシエーターとローカルQSPECが使用される場所を示します。QNIは、Y.1541 QOSMのイニシエーターQSPECを含むエンドツーエンドのドメイン間QOS NSLPリザーブメッセージを開始します。図4に示すように、リザーブメッセージは異なるQoSMをサポートする複数のドメインを越えます。この図では、イニシエーターQSPECは、ローカルQOSMドメインのイングレスノードにQOS NSLPリザーブメッセージに到着します。ローカルQOSMドメインのイングレスエッジノードでは、エンドツーエンドのドメイン間QOS-NSLPメッセージがローカルQSPECの生成をトリガーし、イニシエーターQSPECはローカルドメインを介して通知されたメッセージ内にカプセル化されます。ローカルQSPECは、ローカルQOSMドメインでのQOS処理に使用され、イニシエーターQSPECはローカルドメイン外のQOS処理に使用されます。
In this example, the QNI sets <QoS Desired>, <Minimum QoS>, and <QoS Available> objects to include objectives for the <Path Latency>, <Path Jitter>, and <Path PER> parameters. The QNE / local domain sets the cumulative parameters, e.g., <Path Latency>, that can be achieved in the <QoS Available> object (but not less than specified in <Minimum QoS>). If the <QoS Available> fails to satisfy one or more of the <Minimum QoS> objectives, the QNE / local domain notifies the QNI and the reservation is aborted. If any QNE cannot meet the requirements designated by the Initiator QSPEC to support a QSPEC parameter with the M bit set to zero, the QNE sets the N flag for that parameter to one. Otherwise, the QNR notifies the QNI of the <QoS Available> for the reservation.
この例では、QNIは<qos desired>、<motim qos>、および<qos available>オブジェクトを設定して、<path latency>、<path jitter>、および<path path>パラメーターの目的を含めるように設定します。QNE / Localドメインは、<QOS利用可能>オブジェクトで実現できる累積パラメーター（<Path Latency>）を設定します（ただし、<最小QoS>で指定されていません）。<QOS利用可能>が1つ以上の<最小QoS>目的を満たさない場合、QNE /ローカルドメインはQNIに通知し、予約は中止されます。QNEは、Mビットがゼロに設定されたQSPECパラメーターをサポートするためにイニシエーターQSPECによって指定された要件を満たすことができない場合、QNEはそのパラメーターのNフラグを1に設定します。それ以外の場合、QNRは、予約のために<QOS利用可能>のQNIに通知します。
|------| |------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Y.1541| |local | |local | |local | |local | |Y.1541|
| QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM |
|------| |------| |-------| |-------| |------| |------|
-----------------------------------------------------------------
|------| |------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|------| |------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End)
Figure 4: Example of Initiator and Local Domain QOSM Operation
図4：イニシエーターとローカルドメインQOSM操作の例
A reservation may not be successful for several reasons:
いくつかの理由で予約が成功しない場合があります。
- a reservation may fail because the desired resources are not available. This is a reservation failure condition.
- 目的のリソースが利用できないため、予約が失敗する可能性があります。これは予約障害条件です。
- a reservation may fail because the QSPEC is erroneous or because of a QNE fault. This is an error condition.
- QSPECが誤っているか、QNE障害のために予約が失敗する可能性があります。これはエラー条件です。
A reservation may be successful even though some parameters could not be interpreted or updated properly:
いくつかのパラメーターを適切に解釈または更新することができなかったとしても、予約は成功する可能性があります。
- a QSPEC parameter cannot be interpreted because it is an unknown QSPEC parameter type. This is a QSPEC parameter not supported condition. However, the reservation does not fail. The QNI can still decide whether to keep or tear down the reservation depending on the procedures specified by the QNI's QOSM.
- QSPECパラメーターは、不明なQSPECパラメータータイプであるため解釈できません。これは、サポートされていない条件ではないQSPECパラメーターです。ただし、予約は失敗しません。QNIは、QNIのQoSMによって指定された手順に応じて、予約を維持するか削減するかを決定できます。
The following sections provide details on the handling of unsuccessful reservations and reservations where some parameters could not be met, as follows:
次のセクションでは、次のように、いくつかのパラメーターを満たすことができなかった留保と予約の処理に関する詳細を示します。
- details on flags used inside the QSPEC to convey information on success or failure of individual parameters. The formats and semantics of all flags are given in Section 5.
- 個々のパラメーターの成功または失敗に関する情報を伝えるためにQSPEC内で使用されるフラグの詳細。すべてのフラグの形式とセマンティクスは、セクション5に記載されています。
- the content of the INFO-SPEC [RFC5974], which carries a code indicating the outcome of reservations.
- 情報スペック[RFC5974]のコンテンツは、予約の結果を示すコードを搭載しています。
- the generation of a RESPONSE message to the QNI containing both QSPEC and INFO-SPEC objects.
- QSPECと情報スペックオブジェクトの両方を含むQNIへの応答メッセージの生成。
Note that when there are routers along the path between the QNI and QNR where QoS cannot be provided, then the QoS-NSLP generic flag BREAK (B) is set. The BREAK flag is discussed in Section 3.3.5 of [RFC5974].
QOSが提供できないQNIとQNRの間のパスに沿ってルーターがある場合、QOS-NSLPジェネリックフラグブレイク（b）が設定されていることに注意してください。ブレークフラグについては、[RFC5974]のセクション3.3.5で説明します。
The QSPEC parameters each have a 'reservation failure error E flag' to indicate which (if any) parameters could not be satisfied. When a resource cannot be satisfied for a particular parameter, the QNE detecting the problem raises the E flag in this parameter. Note that the TMOD parameter and all QSPEC parameters with the M flag set MUST be examined by the RMF, and all QSPEC parameters with the M flag not set SHOULD be examined by the RMF, and the E flag set to indicate whether the parameter could or could not be satisfied. Additionally, the E flag in the corresponding QSPEC object MUST be raised when a resource cannot be satisfied for this parameter. If the reservation failure problem cannot be located at the parameter level, only the E flag in the QSPEC object is raised.
QSPECパラメーターには、それぞれ「予約障害エラーEフラグ」があり、（もしあれば）パラメーターが満たされなかったことを示します。特定のパラメーターに対してリソースを満たすことができない場合、問題を検出するQNEはこのパラメーターのEフラグを上げます。Mフラグセットを使用したTMODパラメーターとすべてのQSPECパラメーターはRMFで調べる必要があり、Mフラグが設定されていないすべてのQSPECパラメーターをRMFで調べ、パラメーターができるか、またはパラメーターが可能かを示すためにeフラグセットを調べる必要があることに注意してください。満足できませんでした。さらに、対応するQSPECオブジェクトのEフラグは、このパラメーターのリソースが満たされない場合に掲載する必要があります。予約障害の問題をパラメーターレベルに配置できない場合、QSPECオブジェクトのEフラグのみが上昇します。
When an RMF cannot interpret the QSPEC because the coding is erroneous, it raises corresponding reservation failure E flags in the QSPEC. Normally, all QSPEC parameters MUST be examined by the RMF, and the erroneous parameters appropriately flagged. In some cases, however, an error condition may occur and the E flag of the error-causing QSPEC parameter is raised (if possible), but the processing of further parameters may be aborted.
RMFがQSPECを解釈できない場合、コーディングが誤っているため、QSPECの対応する予約障害eフラグを上げます。通常、すべてのQSPECパラメーターはRMFによって調べられ、誤ったパラメーターが適切にフラグを立てられなければなりません。ただし、場合によっては、エラー条件が発生し、エラーを引き起こすQSPECパラメーターのEフラグが表示されますが（可能であれば）、さらなるパラメーターの処理が中止される場合があります。
Note that if the QSPEC and/or any QSPEC parameter is found to be erroneous, then any QSPEC parameters not satisfied are ignored and the E Flags in the QSPEC object MUST NOT be set for those parameters (unless they are erroneous).
QSPECおよび/またはQSPECパラメーターが誤っていることがわかった場合、満たされていないQSPECパラメーターは無視され、QSPECオブジェクトのEフラグをそれらのパラメーターに設定してはなりません（誤っている場合を除く）。
Whether E flags denote reservation failure or error can be determined by the corresponding error code in the INFO-SPEC in QoS NSLP, as discussed below.
以下で説明するように、eフラグが予約障害またはエラーを示すかどうかは、QoS NSLPの情報スペックの対応するエラーコードによって決定できます。
Each QSPEC parameter has an associated 'Not Supported N flag'. If the Not Supported N flag is set, then at least one QNE along the data transmission path between the QNI and QNR cannot interpret the specified QSPEC parameter. A QNE MUST set the Not Supported N flag if it cannot interpret the QSPEC parameter. If the M flag for the parameter is not set, the message should continue to be forwarded but with the N flag set, and the QNI has the option of tearing down the reservation.
各QSPECパラメーターには、関連する「サポートされていないnフラグ」があります。サポートされていないNフラグが設定されている場合、QNIとQNRの間のデータ送信パスに沿って少なくとも1つのQNEが指定されたQSPECパラメーターを解釈できません。QNEは、QSPECパラメーターを解釈できない場合、サポートされていないNフラグを設定する必要があります。パラメーターのMフラグが設定されていない場合、メッセージは引き続き転送されますが、nフラグが設定されており、QNIには予約を取り壊すオプションがあります。
If a QNE in the path does not support a QSPEC parameter, e.g., <Path Latency>, and sets the N flag, then downstream QNEs that support the parameter SHOULD still update the parameter, even if the N flag is set. However, the presence of the N flag will indicate that the cumulative value only provides a bound, and the QNI/QNR decides whether or not to accept the reservation with the N flag set.
パス内のQNEがQSPECパラメーター、たとえば<パスレイテンシ>、nフラグを設定していない場合、パラメーターをサポートする下流QNESは、nフラグが設定されていてもパラメーターを更新する必要があります。ただし、Nフラグの存在は、累積値がバインドされていることのみを示し、QNI/QNRはNフラグセットで予約を受け入れるかどうかを決定します。
As prescribed by [RFC5974], the RESPONSE message always contains the INFO-SPEC with an appropriate 'error' code. It usually also contains a QSPEC with QSPEC objects, as described in Section 4.3 ("QSPEC Procedures"). The RESPONSE message MAY omit the QSPEC in case of a successful reservation.
[RFC5974]で規定されているように、応答メッセージには常に、適切な「エラー」コードを備えた情報スペックが含まれます。また、セクション4.3（「QSPEC手順」）で説明されているように、QSPECオブジェクトを持つQSPECも含まれています。応答メッセージは、予約が成功した場合にQSPECを省略する場合があります。
The following guidelines are provided for setting the error codes in the INFO-SPEC, based on the codes provided in Section 5.1.3.6 of [RFC5974]:
[RFC5974]のセクション5.1.3.6で提供されているコードに基づいて、次のガイドラインが情報スペックにエラーコードを設定するために提供されています。
- NSLP error class 2 (Success) / 0x01 (Reservation Success): This code is set when all QSPEC parameters have been satisfied. In this case, no E Flag is set; however, one or more N flags may be set.
- NSLPエラークラス2（成功） / 0x01（予約成功）：このコードは、すべてのQSPECパラメーターが満たされたときに設定されます。この場合、Eフラグは設定されていません。ただし、1つ以上のNフラグを設定することができます。
- NSLP error class 4 (Transient Failure) / 0x07 (Reservation Failure): This code is set when at least one QSPEC parameter could not be satisfied, or when a QSPEC parameter with M flag set could not be interpreted. E flags are set for the parameters that could not be satisfied at each QNE up to the QNE issuing the RESPONSE message. The N flag is set for those parameters that could not be interpreted by at least one QNE. In this case, QNEs receiving the RESPONSE message MUST remove the corresponding reservation.
- NSLPエラークラス4（過渡障害） / 0x07（予約障害）：このコードは、少なくとも1つのQSPECパラメーターが満たされなかった場合、またはMフラグセットを持つQSPECパラメーターを解釈できなかった場合に設定されます。eフラグは、応答メッセージを発行するQNEまでの各QNEで満たすことができなかったパラメーターに設定されています。nフラグは、少なくとも1つのQNEで解釈できなかったパラメーターに設定されています。この場合、応答メッセージを受信するQNESは、対応する予約を削除する必要があります。
- NSLP error class 3 (Protocol Error) / 0x0c (Malformed QSPEC): Some QSPEC parameters had associated errors, E Flags are set for parameters that had errors, and the QNE where the error was found rejects the reservation.
- NSLPエラークラス3（プロトコルエラー） / 0x0C（不正なQSPEC）：一部のQSPECパラメーターには関連するエラーがあり、eフラグはエラーのパラメーターに設定され、エラーが見つかったQNEは予約を拒否します。
- NSLP error class 3 (Protocol Error) / 0x0f (Incompatible QSPEC): A higher version QSPEC is signaled and not supported by the QNE.
- NSLPエラークラス3（プロトコルエラー） / 0x0F（互換性のないQSPEC）：より高いバージョンQSPECが信号され、QNEでサポートされていません。
- NSLP error class 6 (QoS Model Error): QOSM error codes can be defined by QOSM specification documents. A registry is defined in Section 7, IANA Considerations.
- NSLPエラークラス6（QOSモデルエラー）：QOSMエラーコードは、QOSM仕様ドキュメントで定義できます。レジストリは、セクション7、IANAの考慮事項で定義されています。
- Successful Reservation Condition
- 予約条件の成功
When a RESERVE message arrives at a QNR and no E Flag is set, the reservation is successful. A RESPONSE message may be generated with INFO-SPEC code 'Reservation Success' as described above and in Section 4.3 ("QSPEC Procedures").
予備のメッセージがQNRに到着し、Eフラグが設定されていない場合、予約は成功します。応答メッセージは、上記のように情報スペックコード「予約の成功」とセクション4.3（「QSPEC手順」）で生成される場合があります。
- Reservation Failure Condition
- 予約障害条件
When a QNE detects that a reservation failure occurs for at least one parameter, the QNE sets the E Flags for the QSPEC parameters and QSPEC object that failed to be satisfied. According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines the reservation failed, it formulates a RESPONSE message that includes an INFO-SPEC with the 'reservation failure' error code and QSPEC object. The QSPEC in the RESPONSE message includes the failed QSPEC parameters marked with the E Flag to clearly identify them.
QNEが少なくとも1つのパラメーターで予約障害が発生することを検出すると、QNEはQSPECパラメーターと満たされなかったQSPECオブジェクトのEフラグを設定します。[RFC5974]によると、QNEの動作は、それがステートフルであるかどうかに依存します。ステートフルQNEが予約が失敗したと判断すると、「予約障害」エラーコードとQSPECオブジェクトを使用した情報スペックを含む応答メッセージを作成します。応答メッセージのQSPECには、eフラグがマークされた失敗したqspecパラメーターが含まれており、それらを明確に識別します。
The default action for a stateless QoS NSLP QNE that detects a reservation failure condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE then formulates the RESPONSE message as described above.
予約障害条件を検出するステートレスQOS NSLP QNEのデフォルトアクションは、各QSPECパラメーターに適切に設定されているEフラグを適切に設定して、予備のメッセージを次のステートフルQNEに転送し続ける必要があることです。次のステートフルQNEは、上記のように応答メッセージを定式化します。
- Malformed QSPEC Error Condition
- 奇形のQSPECエラー条件
When a stateful QNE detects that one or more QSPEC parameters are erroneous, the QNE sets the error code 'malformed QSPEC' in the INFO-SPEC. In this case, the QSPEC object with the E Flags appropriately set for the erroneous parameters is returned within the INFO-SPEC object. The QSPEC object can be truncated or fully included within the INFO-SPEC.
ステートフルQNEが1つ以上のQSPECパラメーターが誤っていることを検出すると、QNEは情報スペックでエラーコード「奇形QSPEC」を設定します。この場合、Eフラグを適切に設定したQSPECオブジェクトは、誤ったパラメーターに適切に設定されています。情報スペックオブジェクト内で返されます。QSPECオブジェクトは切り捨てられたり、情報スペック内に完全に含めることができます。
According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines a malformed QSPEC error condition, it formulates a RESPONSE message that includes an INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.
[RFC5974]によると、QNEの動作は、それがステートフルであるかどうかに依存します。ステートフルなQNEが奇形のQSPECエラー条件を決定すると、「奇形QSPEC」エラーコードとQSPECオブジェクトを使用した情報スペックを含む応答メッセージを定式化します。
The QSPEC in the RESPONSE message includes, if possible, only the erroneous QSPEC parameters and no others. The erroneous QSPEC parameter(s) are marked with the E Flag to clearly identify them. If QSPEC parameters are returned in the INFO-SPEC that are not marked with the E flag, then any values of these parameters are irrelevant and MUST be ignored by the QNI.
応答メッセージのQSPECには、可能であれば、誤ったQSPECパラメーターのみが含まれ、その他は含まれません。誤ったQSPECパラメーターには、それらを明確に識別するためのEフラグがマークされています。QSPECパラメーターがeフラグにマークされていない情報スペックで返される場合、これらのパラメーターの値は無関係であり、QNIによって無視する必要があります。
The default action for a stateless QoS NSLP QNE that detects a malformed QSPEC error condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE will then act as described in [RFC5974].
不正なQSPECエラー条件を検出するステートレスQOS NSLP QNEのデフォルトアクションは、各QSPECパラメーターに適切に設定されているEフラグを適切に設定して、次のステートフルQNEに予備メッセージを転送し続ける必要があることです。次のステートフルQNEは、[RFC5974]に記載されているとおりに機能します。
A 'malformed QSPEC' error code takes precedence over the 'reservation failure' error code, and therefore the case of reservation failure and QSPEC/RMF error conditions are disjoint, and the same E Flag can be used in both cases without ambiguity.
「不正なQSPEC」エラーコードは、「予約障害」エラーコードよりも優先されるため、予約障害とQSPEC/RMFエラー条件の場合はばらばらであり、どちらの場合も同じEフラグを使用できます。
When an unsuccessful reservation problem occurs inside a local domain where a Local QSPEC is used, only the topmost (local) QSPEC is affected (e.g., E flags are raised, etc.). The encapsulated Initiator QSPEC is untouched. However, when the message (RESPONSE in case of stateful QNEs; RESERVE in case of stateless QNEs) reaches the edge of the local domain, the Local QSPEC is removed. The edge QNE must update the Initiator QSPEC on behalf of the entire domain, reflecting the information received in the Local QSPEC. This update concerns both parameter values and flags. Note that some intelligence is needed in mapping the E flags, etc., from the local QSPEC to the Initiator QSPEC. For example, even if there is no direct match between the parameters in the local and Initiator QSPECs, E flags could still be raised in the latter.
予約の失敗がローカルQSPECが使用されるローカルドメイン内で発生すると、最上位（ローカル）QSPECのみが影響を受けます（たとえば、Eフラグが上昇します）。カプセル化されたイニシエーターQSPECは触れられていません。ただし、メッセージ（ステートレスQNESの場合の応答、ステートレスQNESの場合は予約）がローカルドメインの端に達すると、ローカルQSPECが削除されます。エッジQNEは、ローカルQSPECで受け取った情報を反映して、ドメイン全体に代わってイニシエーターQSPECを更新する必要があります。この更新は、パラメーター値とフラグの両方に関係しています。ローカルQSPECからイニシエーターQSPECまでのEフラグなどをマッピングする際には、ある程度のインテリジェンスが必要であることに注意してください。たとえば、ローカルとイニシエーターQSPECのパラメーター間に直接一致がない場合でも、後者ではEフラグを引き上げることができます。
While the QSPEC template aims to put minimal restrictions on usage of QSPEC objects, interoperability between QNEs and between QOSMs must be ensured. We therefore give below an exhaustive list of QSPEC object combinations for the message sequences described in QoS NSLP [RFC5974]. A specific QOSM may prescribe that only a subset of the procedures listed below may be used.
QSPECテンプレートは、QSPECオブジェクトの使用に関する最小限の制限を設定することを目的としていますが、QNESとQOSM間の相互運用性を確保する必要があります。したがって、QOS NSLP [RFC5974]で説明されているメッセージシーケンスのQSPECオブジェクトの組み合わせの徹底的なリストを以下に示します。特定のQoSMは、以下にリストされている手順のサブセットのみを使用できることを規定する場合があります。
Note that QoS NSLP does not mandate the usage of a RESPONSE message. A positive RESPONSE message will only be generated if the QNE includes an RII (Request Identification Information) in the RESERVE message, and a negative RESPONSE message is always generated in case of an error or failure. Some of the QSPEC procedures below, however, are only meaningful when a RESPONSE message is possible. The QNI SHOULD in these cases include an RII.
QoS NSLPは、応答メッセージの使用を義務付けていないことに注意してください。正の応答メッセージは、QNEに予備メッセージにRII（要求識別情報）が含まれている場合にのみ生成され、エラーまたは障害の場合に否定的な応答メッセージが常に生成されます。ただし、以下のQSPEC手順の一部は、応答メッセージが可能な場合にのみ意味があります。これらの場合、QNIにはRIIが含まれる必要があります。
Here, the QNI issues a RESERVE message, which may be replied to by a RESPONSE message. The following 3 cases for QSPEC object usage exist:
ここで、QNIはリザーブメッセージを発行します。これは、応答メッセージによって返信される場合があります。QSPECオブジェクトの使用に関する次の3つのケースが存在します。
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
0 | 0 | QoS Desired | QoS Reserved
| | |
0 | 1 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | |
0 | 2 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | Minimum QoS |
Table 1: Message Sequence 0: Two-Way Transactions Defining Object Combinations 0, 1, and 2
表1：メッセージシーケンス0：オブジェクトの組み合わせを定義する双方向トランザクション0、1、および2
Case 1:
ケース1：
If only QoS Desired is included in the RESERVE message, the implicit assumption is that exactly these resources must be reserved. If this is not possible, the reservation fails. The parameters in QoS Reserved are copied from the parameters in QoS Desired. If the reservation is successful, the RESPONSE message can be omitted in this case. If a RESPONSE message was requested by a QNE on the path, the QSPEC in the RESPONSE message can be omitted.
予備のメッセージに希望のQoSのみが含まれている場合、暗黙の仮定は、これらのリソースを正確に予約する必要があるということです。これが不可能な場合、予約は失敗します。予約されたQoSのパラメーターは、希望するQoSのパラメーターからコピーされます。予約が成功した場合、この場合は応答メッセージを省略できます。パス上のQNEによって応答メッセージが要求された場合、応答メッセージのQSPECは省略できます。
Case 2:
ケース2：
When QoS Available is included in the RESERVE message also, some parameters will appear only in QoS Available and not in QoS Desired. It is assumed that the value of these parameters is collected for informational purposes only (e.g., path latency).
利用可能なQoSが予備のメッセージにも含まれている場合、一部のパラメーターは、利用可能なQoSでのみ表示され、QOSが必要としません。これらのパラメーターの値は、情報目的のみで収集されていると想定されています（たとえば、パスレイテンシ）。
However, some parameters in QoS Available can be the same as in QoS Desired. For these parameters, the implicit message is that the QNI would be satisfied by a reservation with lower parameter values than specified in QoS Desired. For these parameters, the QNI seeds the parameter values in QoS Available to those in QoS Desired (except for cumulative parameters such as <Path Latency>).
ただし、利用可能なQoSの一部のパラメーターは、QOSが目的とするのと同じです。これらのパラメーターの場合、暗黙的なメッセージは、QSIが指定したQoSで指定されているよりも低いパラメーター値の予約によってQNIが満たされることです。これらのパラメーターの場合、QNIは、QOSのパラメーター値をQOSのパラメーター値にシードします（<Path Latency>などの累積パラメーターを除く）。
Each QNE interprets the parameters in QoS Available according to its current capabilities. Reservations in each QNE are hence based on current parameter values in QoS Available (and additionally those parameters that only appear in QoS Desired). The drawback of this approach is that, if the resulting resource reservation becomes gradually smaller towards the QNR, QNEs close to the QNI have an oversized reservation, possibly resulting in unnecessary costs for the user. Of course, in the RESPONSE the QNI learns what the actual reservation is (from the QoS RESERVED object) and can immediately issue a properly sized refreshing RESERVE. The advantage of the approach is that the reservation is performed in half-a-roundtrip time.
各QNEは、現在の機能に従って利用可能なQoSのパラメーターを解釈します。したがって、各QNEの予約は、利用可能なQOSの現在のパラメーター値（さらに、QOSのみに表示されるパラメーター）に基づいています。このアプローチの欠点は、結果のリソース予約がQNRに向かって徐々に小さくなると、QNIに近いQNESが特大の予約を持ち、おそらくユーザーに不必要なコストをもたらす可能性があることです。もちろん、応答では、QNIは実際の予約が（QoS予約オブジェクトから）何であるかを学び、すぐに適切にサイズのリフレッシュリザーブを発行できます。このアプローチの利点は、予約が半分のラウンドトリップ時間に実行されることです。
The QSPEC parameter IDs and values included in the QoS Reserved object in the RESPONSE message MUST be the same as those in the QoS Desired object in the RESERVE message. For those QSPEC parameters that were also included in the QoS Available object in the RESERVE message, their value is copied from the QoS Available object (in RESERVE) into the QoS Reserved object (in RESPONSE). For the other QSPEC parameters, the value is copied from the QoS Desired object (the reservation would fail if the corresponding QoS could not be reserved).
応答メッセージのQOS予約オブジェクトに含まれるQSPECパラメーターIDと値は、予備メッセージのQOS望ましいオブジェクトのものと同じでなければなりません。リザーブメッセージのQOS利用可能なオブジェクトにも含まれているQSPECパラメーターの場合、それらの値はQOS利用可能なオブジェクト（予備）からQOS予約オブジェクト（応答）にコピーされます。他のQSPECパラメーターの場合、値はQoS目的のオブジェクトからコピーされます（対応するQoSを予約できなかった場合、予約は失敗します）。
All parameters in the QoS Available object in the RESPONSE message are copied with their values from the QoS Available object in the RESERVE message (irrespective of whether they have also been copied into the QoS Desired object). Note that the parameters in the QoS Available object can be overwritten in the RESERVE message, whereas they cannot be overwritten in the RESPONSE message.
応答メッセージ内のQOS利用可能なオブジェクトのすべてのパラメーターは、予備メッセージのQOS利用可能なオブジェクトから値にコピーされます（QoS望ましいオブジェクトにコピーされたかどうかに関係なく）。QOS利用可能なオブジェクトのパラメーターは、リザーブメッセージに上書きすることができますが、応答メッセージで上書きすることはできません。
In this case, the QNI SHOULD request a RESPONSE message since it will otherwise not learn what QoS is available.
この場合、QSが利用可能なものを学習しないため、QNIは応答メッセージを要求する必要があります。
Case 3:
ケース3：
This case is handled as case 2, except that the reservation fails when QoS Available becomes less than Minimum QoS for one parameter. If a parameter appears in the QoS Available object but not in the Minimum QoS object, it is assumed that there is no minimum value for this parameter.
このケースはケース2として処理されます。ただし、1つのパラメーターのQoSが最小QoS未満になると予約が失敗することを除きます。QoS利用可能なオブジェクトにパラメーターが表示されますが、最小QoSオブジェクトに表示されない場合、このパラメーターに最小値がないと想定されます。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
トラフィック処理指令に関して、デフォルトのルールは、QNIによって予備メッセージに含まれているすべてのQSPECパラメーターも、QNRに到着したときに持っていた値でQNRの応答メッセージに含まれていることです。応答メッセージで移動する場合、すべてのトラフィック処理ディレクティブパラメーターは読み取り専用です。QOSM仕様は、独自のトラフィック処理ディレクティブパラメーターと処理ルールを定義できることに注意してください。
Here, the QNR issues a QUERY message that is replied to by the QNI with a RESERVE message if the reservation was successful. The QNR in turn sends a RESPONSE message to the QNI. The following 3 cases for QSPEC object usage exist:
ここで、QNRは、予約が成功した場合、予備のメッセージでQNIによって返信されるクエリメッセージを発行します。QNRは順番にQNIに応答メッセージを送信します。QSPECオブジェクトの使用に関する次の3つのケースが存在します。
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
Table 2: Message Sequence 1: Three-Way Transactions Defining Object Combinations 0, 1, and 2
表2：メッセージシーケンス1：オブジェクトの組み合わせを定義する3方向トランザクション0、1、および2
Cases 1 and 2:
ケース1および2：
The idea is that the sender (QNR in this scenario) needs to inform the receiver (QNI in this scenario) about the QoS it desires. To this end, the sender sends a QUERY message to the receiver including a QoS Desired QSPEC object. If the QoS is negotiable, it additionally includes a (possibly zero) Minimum QoS object, as in Case 2.
アイデアは、送信者（このシナリオのQNR）は、必要なQosについてレシーバー（このシナリオのQNI）に通知する必要があるということです。この目的のために、送信者はQOSが目的のQSPECオブジェクトを含むクエリメッセージを受信機に送信します。QoSが交渉可能な場合、ケース2のように（おそらくゼロ）最小QoSオブジェクトが追加されます。
The RESERVE message includes the QoS Available object if the sender signaled that QoS is negotiable (i.e., it included the Minimum QoS object). If the Minimum QoS object received from the sender is included in the QUERY message, the QNI also includes the Minimum QoS object in the RESERVE message.
予備のメッセージには、QOSが交渉可能であることを送信者が合図した場合（つまり、最小QoSオブジェクトが含まれている）場合、QoS利用可能なオブジェクトが含まれます。送信者から受信した最小QoSオブジェクトがクエリメッセージに含まれている場合、QNIには予備メッセージに最小QoSオブジェクトも含まれます。
For a successful reservation, the RESPONSE message in case 1 is optional (as is the QSPEC inside). In case 2, however, the RESPONSE message is necessary in order for the QNI to learn about the QoS available.
予約を成功させるために、ケース1の応答メッセージはオプションです（内部のQSPECと同様）。ただし、ケース2では、QNIが利用可能なQoSについて学習するために応答メッセージが必要です。
Case 3:
ケース3：
This is the 'RSVP-style' scenario. The sender (QNR in this scenario) issues a QUERY message with a QoS Desired object informing the receiver (QNI in this scenario) about the QoS it desires, as above. It also includes a QoS Available object to collect path properties. Note that here path properties are collected with the QUERY message, whereas in the previous case, 2 path properties were collected in the RESERVE message.
これは「RSVPスタイル」のシナリオです。送信者（このシナリオのQNR）は、上記のように、QOSが望むQOSについてレシーバー（QNI）に通知するQOS望ましいオブジェクトを使用してクエリメッセージを発行します。また、パスプロパティを収集するためのQOS利用可能なオブジェクトも含まれています。ここでは、パスプロパティがクエリメッセージで収集され、前のケースでは、予備のメッセージで2つのパスプロパティが収集されたことに注意してください。
Some parameters in the QoS Available object may be the same as in the QoS Desired object. For these parameters, the implicit message is that the sender would be satisfied by a reservation with lower parameter values than specified in QoS Desired.
QOS利用可能なオブジェクトの一部のパラメーターは、QoS望ましいオブジェクトと同じである場合があります。これらのパラメーターの場合、暗黙的なメッセージは、送信者が必要なQoSで指定されたよりも低いパラメーター値を持つ予約によって満たされるということです。
It is possible for the QoS Available object to contain parameters that do not appear in the QoS Desired object. It is assumed that the value of these parameters is collected for informational purposes only (e.g., path latency). Parameter values in the QoS Available object are seeded according to the sender's capabilities. Each QNE remaps or approximately interprets the parameter values according to its current capabilities.
QoS利用可能なオブジェクトが、QOS望ましいオブジェクトに表示されないパラメーターを含めることができます。これらのパラメーターの値は、情報目的のみで収集されていると想定されています（たとえば、パスレイテンシ）。QOS利用可能なオブジェクトのパラメーター値は、送信者の機能に従ってシードされます。各QNEは、現在の機能に応じてパラメーター値を再確認またはほぼ解釈します。
The receiver (QNI in this scenario) signals the QoS Desired object as follows: For those parameters that appear in both the QoS Available object and QoS Desired object in the QUERY message, it takes the (possibly remapped) QSPEC parameter values from the QoS Available object. For those parameters that only appear in the QoS Desired object, it adopts the parameter values from the QoS Desired object.
受信機（このシナリオのQNI）は、QOSが使用可能なオブジェクトとクエリメッセージにQOSが目的のオブジェクトの両方に表示されるパラメーターの場合、QoSが目的のオブジェクトを次のように信号します。物体。QoS目的のオブジェクトにのみ表示されるパラメーターの場合、QoS目的のオブジェクトからパラメーター値を採用します。
The parameters in the QoS Available QSPEC object in the RESERVE message are copied with their values from the QoS Available QSPEC object in the QUERY message. Note that the parameters in the QoS Available object can be overwritten in the QUERY message, whereas they cannot be overwritten in the RESERVE message.
QOS利用可能なQSPECオブジェクトのリザーブメッセージ内のパラメーターは、クエリメッセージ内のQOS利用可能なQSPECオブジェクトからの値にコピーされます。QOS利用可能なオブジェクトのパラメーターはクエリメッセージに上書きできるのに対し、予備メッセージで上書きすることはできません。
The advantage of this model compared to the sender-initiated reservation is that the situation of over-reservation in QNEs close to the QNI (as described above) does not occur. On the other hand, the QUERY message may find, for example, a particular bandwidth is not available. When the actual reservation is performed, however, the desired bandwidth may meanwhile have become free. That is, the 'RSVP style' may result in a smaller reservation than necessary.
送信者が開始した予約と比較したこのモデルの利点は、QNI（上記のように）に近いQNESの過剰保存の状況が発生しないことです。一方、クエリメッセージには、特定の帯域幅が利用できないことがわかります。ただし、実際の予約が実行されると、その間、望ましい帯域幅が自由になる可能性があります。つまり、「RSVPスタイル」は、必要以上に予約が少なくなる可能性があります。
The sender includes all QSPEC parameters it cares about in the QUERY message. Parameters that can be overwritten are updated by QNEs as the QUERY message travels towards the receiver. The receiver includes all QSPEC parameters arriving in the QUERY message also in the RESERVE message, with the value they had when arriving at the receiver. Again, QOSM-specific QSPEC parameters and procedures may be defined in QOSM specification documents.
送信者には、クエリメッセージで気にかけているすべてのQSPECパラメーターが含まれています。上書きできるパラメーターは、クエリメッセージが受信機に向かって移動するとQNESによって更新されます。受信機には、リザーブメッセージにもクエリメッセージに到着するすべてのQSPECパラメーターが含まれており、レシーバーに到着したときに持っていた値が含まれています。繰り返しますが、QOSM固有のQSPECパラメーターと手順は、QOSM仕様ドキュメントで定義される場合があります。
Also in this scenario, the QNI SHOULD request a RESPONSE message since it will otherwise not learn what QoS is available.
また、このシナリオでは、QSが利用可能なものを学習しないため、QNIは応答メッセージを要求する必要があります。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
トラフィック処理指令に関して、デフォルトのルールは、QNIによって予備メッセージに含まれているすべてのQSPECパラメーターも、QNRに到着したときに持っていた値でQNRの応答メッセージに含まれていることです。応答メッセージで移動する場合、すべてのトラフィック処理ディレクティブパラメーターは読み取り専用です。QOSM仕様は、独自のトラフィック処理ディレクティブパラメーターと処理ルールを定義できることに注意してください。
Here, the QNI issues a QUERY message in order to investigate what resources are currently available. The QNR replies with a RESPONSE message.
ここで、QNIは、現在利用可能なリソースを調査するためにクエリメッセージを発行します。QNRは応答メッセージで返信します。
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN QUERY MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
2 | 0 | QoS Available | QoS Available
Table 3: Message Sequence 2: Resource Queries Defining Object Combination 0
表3：メッセージシーケンス2：オブジェクトの組み合わせを定義するリソースクエリ0
Note that the QoS Available object when traveling in the QUERY message can be overwritten, whereas in the RESPONSE message it cannot be overwritten.
クエリメッセージ内で移動するときに利用可能なオブジェクトは上書きすることができますが、応答メッセージでは上書きすることはできません。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
トラフィック処理指令に関して、デフォルトのルールは、QNIによって予備メッセージに含まれているすべてのQSPECパラメーターも、QNRに到着したときに持っていた値でQNRの応答メッセージに含まれていることです。応答メッセージで移動する場合、すべてのトラフィック処理ディレクティブパラメーターは読み取り専用です。QOSM仕様は、独自のトラフィック処理ディレクティブパラメーターと処理ルールを定義できることに注意してください。
On a QSPEC level, bidirectional reservations are no different from unidirectional reservations, since QSPECs for different directions never travel in the same message.
QSPECレベルでは、異なる方向のQSPECは同じメッセージ内で移動しないため、双方向の予約は一方向の予約と変わりません。
A flow can be preempted by a QNE based on QNE policy, where a decision to preempt a flow may account for various factors such as, for example, the values of the QSPEC preemption priority and defending priority parameters as described in Section 5.2.8. In this case, the reservation state for this flow is torn down in the QNE, and the QNE sends a NOTIFY message to the QNI, as described in [RFC5974]. The NOTIFY message carries an INFO-SPEC with the error code as described in [RFC5974]. A QOSM specification document may specify whether a NOTIFY message also carries a QSPEC object. The QNI would normally tear down the preempted reservation by sending a RESERVE message with the TEAR flag set using the SII of the preempted reservation. However, the QNI can follow other procedures as specified in its QOSM specification document.
フローは、QNEポリシーに基づいてQNEによって先制することができます。たとえば、フローを先制する決定は、たとえば、セクション5.2.8で説明されているように、QSPECTIONの優先度や防御優先パラメーターの値などのさまざまな要因を説明する場合があります。この場合、このフローの予約状態はQNEで取り壊され、QNEは[RFC5974]で説明されているように、QNIに通知メッセージを送信します。Notifyメッセージは、[RFC5974]で説明されているように、エラーコードを使用して情報スペックを搭載しています。QOSM仕様ドキュメントは、通知メッセージにQSPECオブジェクトも搭載されているかどうかを指定する場合があります。QNIは通常、先制予約のSIIを使用して涙フラグセットで予備のメッセージを送信することにより、先制予約を取り壊します。ただし、QNIは、QOSM仕様ドキュメントで指定されている他の手順に従うことができます。
Additional QSPEC parameters MAY need to be defined in the future and are defined in separate informational documents. For example, QSPEC parameters are defined in [RFC5977] and [RFC5976].
追加のQSPECパラメーターは、将来定義する必要があり、個別の情報文書で定義されている場合があります。たとえば、QSPECパラメーターは[RFC5977]および[RFC5976]で定義されています。
Guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments for QSPEC objects and QSPEC parameters are given in Section 7, IANA Considerations.
QSPECオブジェクトとQSPECパラメーターの新しいCodePoint割り当てのリクエストを評価する際に従うべき技術基準に関するガイドラインは、セクション7、IANAの考慮事項に記載されています。
This section defines the encodings of the QSPEC parameters. We first give the general QSPEC formats and then the formats of the QSPEC objects and parameters.
このセクションでは、QSPECパラメーターのエンコーディングを定義します。まず、一般的なQSPEC形式、次にQSPECオブジェクトとパラメーターの形式を提供します。
Network octet order ('big-endian') for all 16- and 32-bit integers, as well as 32-bit floating point numbers, is as specified in [RFC4506], [IEEE754], and [NETWORK-OCTET-ORDER].
すべての16および32ビット整数のネットワークオクテットオーダー（「ビッグエンディアン」）、および32ビットの浮動小数点数は、[RFC4506]、[IEEE754]、および[ネットワークオクテットオーダー]で指定されています。。
The format of the QSPEC closely follows that used in GIST [RFC5971] and QoS NSLP [RFC5974]. Every object (and parameter) has the following general format:
QSPECの形式は、GIST [RFC5971]およびQOS NSLP [RFC5974]で使用されているものに密接に従います。すべてのオブジェクト（およびパラメーター）には、次の一般的な形式があります。
o The overall format is Type-Length-Value (in that order).
o 全体的な形式は、型-Length-Value（その順序で）です。
o Some parts of the type field are set aside for control flags.
o タイプフィールドの一部は、制御フラグのために確保されています。
o Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. The Object length excludes the header.
o 長さには32ビット単語の単位があり、値の長さを測定します。値がない場合、長さ= 0。オブジェクトの長さはヘッダーを除外します。
o Value is a whole number of 32-bit words. If there is any padding required, the length and location MUST be defined by the object-specific format information; objects that contain variable-length types may need to include additional length subfields to do so.
o 値は、32ビットの単語のすべてです。パディングが必要な場合は、長さと場所をオブジェクト固有の形式情報で定義する必要があります。可変長タイプを含むオブジェクトは、そのために追加の長さサブフィールドを含める必要がある場合があります。
o Any part of the object used for padding or defined as reserved ("r") MUST be set to 0 on transmission and MUST be ignored on reception.
o パディングに使用されるオブジェクトの一部または予約済み（ "r"）として定義されている部分は、送信時に0に設定する必要があり、受信で無視する必要があります。
o Empty QSPECs and empty QSPEC Objects MUST NOT be used.
o 空のQSPECと空のQSPECオブジェクトを使用しないでください。
o Duplicate objects, duplicate parameters, and/or multiple occurrences of a parameter MUST NOT be used.
o 重複したオブジェクト、複製パラメーター、および/またはパラメーターの複数の発生は使用しないでください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common QSPEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC Objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Common QSPEC Header is a fixed 4-octet object containing the QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see Section 4.3), and an Initiator/Local QSPEC bit:
一般的なQSPECヘッダーは、QSPECバージョン、QSPECタイプ、QSPEC手順の識別子（セクション4.3を参照）、およびイニシエーター/ローカルQSPECビットを含む固定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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r| QSPEC Proc. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers.: Identifies the QSPEC version number. QSPEC Version 0 is assigned by this specification in Section 7 (IANA Considerations).
Vers。：QSPECバージョン番号を識別します。QSPECバージョン0は、この仕様によってセクション7（IANAの考慮事項）に割り当てられています。
QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC Type corresponding to a particular QOSM. QSPEC Type 0 (default) is assigned by this specification in Section 7 (IANA Considerations).
QSPECタイプ：特定のタイプのQSPECを識別します。たとえば、特定のQOSMに対応するQSPECタイプ。QSPECタイプ0（デフォルト）は、この仕様によってセクション7（IANAの考慮事項）に割り当てられます。
QSPEC Proc.: Identifies the QSPEC procedure and is composed of two times 4 bits. The first field identifies the Message Sequence; the second field identifies the QSPEC Object Combination used for this particular message sequence:
QSPEC Proc。：QSPEC手順を識別し、2回4ビットで構成されています。最初のフィールドはメッセージシーケンスを識別します。2番目のフィールドは、この特定のメッセージシーケンスに使用されるQSPECオブジェクトの組み合わせを識別します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Mes.Sq |Obj.Cmb|
+-+-+-+-+-+-+-+-+
The Message Sequence field can attain the following values:
メッセージシーケンスフィールドは、次の値を達成できます。
0: Sender-Initiated Reservations 1: Receiver-Initiated Reservations 2: Resource Queries
0：送信者開始予約1：受信機が開始する予約2：リソースクエリ
The Object Combination field can take the values between 1 and 3 indicated in the tables in Section 4.3:
オブジェクトの組み合わせフィールドは、セクション4.3のテーブルに示されている1〜3の値を取得できます。
Message Sequence: 0 Object Combination: 0, 1, 2 Semantic: see Table 1 in Section 4.3.1
メッセージシーケンス：0オブジェクトの組み合わせ：0、1、2セマンティック：セクション4.3.1の表1を参照してください
Message Sequence: 1 Object Combination: 0, 1, 2 Semantic: see Table 2 in Section 4.3.2
メッセージシーケンス：1オブジェクトの組み合わせ：0、1、2セマンティック：セクション4.3.2の表2を参照してください
Message Sequence: 2 Object Combination: 0 Semantic: see Table 3 in Section 4.3.3
メッセージシーケンス：2オブジェクトの組み合わせ：0セマンティック：セクション4.3.3の表3を参照してください
I: Initiator/Local QSPEC bit identifies whether the QSPEC is an initiator QSPEC or a Local QSPEC, and is set to the following values:
I：イニシエーター/ローカルQSPECビットは、QSPECがイニシエーターQSPECかローカルQSPECであるかを識別し、次の値に設定されています。
0: Initiator QSPEC 1: Local QSPEC
0：イニシエーターQSPEC 1：ローカルQSPEC
Length: The total length of the QSPEC (in 32-bit words) excluding the common header
長さ：共通ヘッダーを除くQSPEC（32ビット語）の合計長さ
The QSPEC Objects field is a collection of QSPEC objects (QoS Desired, QoS Available, etc.), which share a common format and each contain several parameters.
QSPECオブジェクトフィールドは、QSPECオブジェクトのコレクション（QOSが目的のQOS、QOSが利用可能など）のコレクションであり、共通形式を共有し、それぞれにいくつかのパラメーターが含まれています。
QSPEC objects share a common header format:
QSPECオブジェクトは、共通のヘッダー形式を共有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E Flag: Set if an error occurs on object level
Eフラグ：オブジェクトレベルでエラーが発生した場合に設定
Object Type = 0: QoS Desired (parameters cannot be overwritten)
= 1: QoS Available (parameters may be overwritten; see
Section 3.2)
= 2: QoS Reserved (parameters cannot be overwritten)
= 3: Minimum QoS (parameters cannot be overwritten)
The r bits are reserved.
Rビットは予約されています。
Each QSPEC or QSPEC parameter within an object is encoded in the same way in TLV format using a similar parameter header:
オブジェクト内の各QSPECまたはQSPECパラメーターは、同様のパラメーターヘッダーを使用してTLV形式で同じ方法でエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag: When set, indicates the subsequent parameter MUST be interpreted. Otherwise, the parameter can be ignored if not understood.
Mフラグ：設定すると、後続のパラメーターを解釈する必要があることを示します。それ以外の場合、理解されていない場合は、パラメーターを無視できます。
E Flag: When set, indicates either a) a reservation failure where the QSPEC parameter is not met, or b) an error occurred when this parameter was being interpreted (see Section 4.2.1).
eフラグ：設定する場合、a）QSPECパラメーターが満たされない場合の予約障害、またはb）このパラメーターが解釈されているときにエラーが発生したことを示します（セクション4.2.1を参照）。
N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2).
nフラグ：サポートされていないQSPECパラメーターフラグ（セクション4.2.2を参照）。
Parameter ID: Assigned consecutively to each QSPEC parameter. Parameter IDs are assigned to each QSPEC parameter defined in this document in Sections 5.2 and 7 (IANA Considerations).
パラメーターID：各QSPECパラメーターに連続して割り当てられます。パラメーターIDは、このドキュメントで定義されている各QSPECパラメーターに、セクション5.2および7（IANAの考慮事項）に割り当てられます。
Parameters are usually coded individually, for example, the <Excess Treatment> parameter (Section 5.2.11). However, it is also possible to combine several sub-parameters into one parameter field, which is called 'container coding'. This coding is useful if either a) the sub-parameters always occur together (as for example the 5 sub-parameters that jointly make up the TMOD), or b) in order to make coding more efficient when the length of each sub-parameter value is much less than a 32-bit word (as for example described in [RFC5977]) and to avoid header overload. When a container is defined, the Parameter ID and the M, E, and N flags refer to the container. Examples of container parameters are <TMOD> (specified below) and the PHR (Per Hop Reservation) container parameter specified in [RFC5977].
パラメーターは通常、<過剰治療>パラメーター（セクション5.2.11）など、個別にコード化されます。ただし、複数のサブパラメーターを「コンテナコーディング」と呼ばれる1つのパラメーターフィールドに結合することもできます。このコーディングは、a）サブパラメーターが常に（たとえば、TMODを共同で構成する5つのサブパラメーターなど）、または各サブパラメーターの長さをより効率的にするために、またはb）のいずれかの場合に役立ちます。値は32ビット単語（[RFC5977]で説明されているように）をはるかに少なくし、ヘッダーの過負荷を避けるためです。コンテナが定義されると、パラメーターIDとM、E、およびNフラグがコンテナを参照します。コンテナパラメーターの例は、[RFC5977]で指定されている<tmod>（以下に指定）とphr（ホップ予約あたり）コンテナパラメーターです。
The references in the following sections point to the normative procedures for processing the QSPEC parameters and sub-parameters.
次のセクションの参照は、QSPECパラメーターとサブパラメーターを処理するための規範的手順を示しています。
The <TMOD-1> parameter consists of the <r>, <b>, <p>, <m>, and <MPS> sub-parameters [RFC2212], which all must be populated in the <TMOD-1> parameter. Note that a second TMOD QSPEC parameter <TMOD-2> is specified below in Section 5.2.2.
<tmod-1>パラメーターは、<r>、<b>、<p>、<m>、および<MPS>サブパラメーター[RFC2212]で構成されています。。2番目のTMOD QSPECパラメーター<TMOD-2>は、セクション5.2.2で以下に指定されていることに注意してください。
The coding for the <TMOD-1> parameter is as follows:
<tmod-1>パラメーターのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| 1 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <TMOD-1> parameters are represented by three floating point numbers in single-precision IEEE floating point format [IEEE754] followed by two 32-bit integers in network octet order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), the first unsigned integer is the minimum policed unit (m), and the second unsigned integer is the maximum packet size (MPS). The values of r and p are measured in octets per second; b, m, and MPS are measured in octets. When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255), and a sign bit and mantissa of all zeroes.
<tmod-1>パラメーターは、単一のrecision IEEEフローティングポイント形式[IEEE754]の3つのフローティングポイント番号で表され、その後、ネットワークオクテット順に2つの32ビット整数が付いています。最初のフローティングポイント値はレート（r）、2番目の浮動小数点値はバケットサイズ（b）、3番目のフローティングポイントはピークレート（p）、最初の符号なし整数は最小ポリシーユニット（m）です。2番目の署名の整数は、最大パケットサイズ（MPS）です。rとpの値は、1秒あたりのオクテットで測定されます。B、M、およびMPSはオクテットで測定されます。r、b、およびpの項がIEEEフローティングポイント値として表される場合、記号ビットはゼロでなければなりません（すべての値は非陰性でなければなりません）。127（つまり、0）未満の指数は禁止されています。162（つまり、正の35）を超える指数は、無限のピーク速度を指定することを除き、落胆しています。Infinityは、すべての指数（255）の指数（255）と、すべてのゼロのサインビットとMantissaで表されます。
A second QSPEC <TMOD-2> parameter is specified as could be needed, for example, to support some Diffserv applications.
たとえば、いくつかのdiffservアプリケーションをサポートするために、2番目のqspec <tmod-2>パラメーターが必要に応じて指定されています。
The coding for the <TMOD-2> parameter is as follows:
<tmod-2>パラメーターのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 2 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-2 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <TMOD-2> parameters are represented by three floating point numbers in single-precision IEEE floating point format [IEEE754] followed by two 32-bit integers in network octet order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), the first unsigned integer is the minimum policed unit (m), and the second unsigned integer is the maximum packet size (MPS). The values of r and p are measured in octets per second; b, m, and MPS are measured in octets. When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255), and a sign bit and mantissa of all zeroes.
<tmod-2>パラメーターは、単一のrecision IEEEフローティングポイント形式[IEEE754]の3つのフローティングポイント番号で表され、その後、ネットワークオクテット順に2つの32ビット整数が付いています。最初のフローティングポイント値はレート（r）、2番目の浮動小数点値はバケットサイズ（b）、3番目のフローティングポイントはピークレート（p）、最初の符号なし整数は最小ポリシーユニット（m）です。2番目の署名の整数は、最大パケットサイズ（MPS）です。rとpの値は、1秒あたりのオクテットで測定されます。B、M、およびMPSはオクテットで測定されます。r、b、およびpの項がIEEEフローティングポイント値として表される場合、記号ビットはゼロでなければなりません（すべての値は非陰性でなければなりません）。127（つまり、0）未満の指数は禁止されています。162（つまり、正の35）を超える指数は、無限のピーク速度を指定することを除き、落胆しています。Infinityは、すべての指数（255）の指数（255）と、すべてのゼロのサインビットとMantissaで表されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency [RFC2215] is a single 32-bit unsigned integer in network octet order. The intention of the Path Latency parameter is the same as the Minimal Path Latency parameter defined in Section 3.4 of [RFC2215]. The purpose of this parameter is to provide a baseline minimum path latency for use with services that provide estimates or bounds on additional path delay, such as in [RFC2212]. Together with the queuing delay bound offered by [RFC2212] and similar services, this parameter gives the application knowledge of both the minimum and maximum packet delivery delay.
パスレイテンシ[RFC2215]は、ネットワークオクテットの順序で単一の32ビットの符号なし整数です。パスレイテンシパラメーターの意図は、[RFC2215]のセクション3.4で定義されている最小パスレイテンシパラメーターと同じです。このパラメーターの目的は、[RFC2212]などの追加のパス遅延の推定値または境界を提供するサービスで使用するためのベースライン最小パスレイテンシを提供することです。[RFC2212]および同様のサービスによって提供されるキューイング遅延バウンドバウンドとともに、このパラメーターは、最小および最大パケット配信遅延の両方のアプリケーションの知識を提供します。
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2^32) - 1 on the maximum value. The latencies are
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
An individual QNE can add a latency value between 1 and 2^28
(somewhat over two minutes), and the total latency added across all
QNEs can range as high as (2^32)-2. If the sum of the different
elements delays exceeds (2^32)-2, the end-to-end cumulative delay
SHOULD be reported as indeterminate = (2^32)-1. A QNE that cannot
accurately predict the latency of packets it is processing MUST raise
the Not Supported N flag and either leave the value of Path Latency
as is, or add its best estimate of its lower bound. A raised not-
supported flag indicates the value of Path Latency is a lower bound
of the real Path Latency. The distinguished value (2^32)-1 is taken
to mean indeterminate latency because the composition function limits
the composed sum to this value; it indicates the range of the
composition calculation was exceeded.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Jitter is a set of four 32-bit unsigned integers in network octet order [RFC3393, Y.1540, Y.1541]. As noted in Section 3.3.2, the Path Jitter parameter is called "IP Delay Variation" in [RFC3393]. The Path Jitter parameter is the combination of four statistics describing the Jitter distribution with a clamp of (2^32) - 1 on the maximum of each value. The jitter STATs are reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can add jitter values between 1 and 2^28 (somewhat over two minutes), and the total jitter computed across all QNEs can range as high as (2^32)-2. If the combination of the different element values exceeds (2^32)-2, the end-to-end cumulative jitter SHOULD be reported as indeterminate. A QNE that cannot accurately predict the jitter of packets it is processing MUST raise the not-supported flag and either leave the value of Path Jitter as is, or add its best estimate of its STAT values. A raised not-supported flag indicates the value of Path Jitter is a lower bound of the real Path Jitter. The distinguished value (2^32)-1 is taken to mean indeterminate jitter. A QNE that cannot accurately predict the jitter of packets it is processing SHOULD set its local Path Jitter parameter to this value. Because the composition function limits the total to this value, receipt of this value at a network element or application indicates that the true Path Jitter is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
パスジッターは、ネットワークオクテット順[RFC3393、Y.1540、Y.1541]の4つの32ビットの非署名整数のセットです。セクション3.3.2で述べたように、パスジッターパラメーターは[RFC3393]の「IP遅延変動」と呼ばれます。Path Jitterパラメーターは、各値の最大値に（2^32）-1のクランプを使用したジッター分布を記述する4つの統計の組み合わせです。ジッターの統計は、1マイクロ秒単位で報告されます。解像度が1マイクロ秒未満のシステムは、未使用の数字をゼロに設定する必要があります。個々のQNEは、ジッター値を1〜2^28（やや2分以上）に追加でき、すべてのQNEで計算された合計ジッターは（2^32）-2の範囲になります。異なる要素値の組み合わせが（2^32）-2を超える場合、エンドツーエンドの累積ジッターは不確定であると報告する必要があります。処理しているパケットのジッターを正確に予測できないQNEは、サポートされていないフラグを上げて、そのままパスジッターの値を残すか、統計値の最良の推定値を追加する必要があります。上昇したサポートされていないフラグは、パスジッターの値が実際のパスジッターの下限であることを示しています。著名な値（2^32）-1は、不確定なジッターを意味すると見なされます。処理しているパケットのジッターを正確に予測できないQNEは、ローカルパスジッターパラメーターをこの値に設定するはずです。構成関数はこの値に合計を制限するため、ネットワーク要素またはアプリケーションでのこの値の受領は、真のパスジッターが不明であることを示します。これは、1つ以上のネットワーク要素が値を供給できなかったか、構成計算の範囲を超えたために発生する可能性があります。
NOTE: The Jitter composition function makes use of the <Path Latency> parameter. Composition functions for loss, latency, and jitter may be found in [Y.1541]. Development continues on methods to combine jitter values to estimate the value of the complete path, and additional statistics may be needed to support new methods (the methods are standardized in [RFC5481] and [COMPOSITION]).
注：Jitter構成関数は、<Path Latency>パラメーターを使用します。[Y.1541]には、損失、遅延、およびジッターの組成関数があります。ジッター値を組み合わせて完全なパスの値を推定する方法が開発されており、新しい方法をサポートするために追加の統計が必要になる場合があります（メソッドは[RFC5481]および[構成]で標準化されています）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PLR is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541]. As defined in [Y.1540], Path PLR is the ratio of total lost IP packets to total transmitted IP packets. An evaluation interval of 1 minute is suggested in [Y.1541], in which the number of losses observed is directly related to the confidence in the result. The composition rule for the <Path PLR> parameter is summation with a clamp of 10^-1 on the maximum value. The PLRs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero. An individual QNE adds its local PLR value (up to a maximum of 10^-2) to the total Path PLR value (up to a maximum of 10^-1) , where the acceptability of the total Path PLR value added across all QNEs is determined based on the QOSM being used. The maximum limit of 10^-2 on a QNE's local PLR value and the maximum limit (clamp value) of 10^-1 on the accumulated end-to-end Path PLR value are used to preserve the accuracy of the simple additive accumulation function specified and to avoid more complex accumulation functions. Furthermore, if these maximums are exceeded, then the path would likely not meet the QoS objectives. If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PLR SHOULD be reported as indeterminate. A QNE that cannot accurately predict the PLR of packets it is processing MUST raise the not-supported flag and either leave the value of Path PLR as is, or add its best estimate of its lower bound. A raised not-supported flag indicates the value of Path PLR is a lower bound of the real Path PLR. The distinguished value 10^-1 is taken to mean indeterminate PLR. A QNE that cannot accurately predict the PLR of packets it is processing SHOULD set its local path PLR parameter to this value. Because the composition function limits the composed sum to this value, receipt of this value at a network element or application indicates that the true path PLR is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
PATH PLRは、ネットワークオクテット順[Y.1541]の単一の32ビット単一精度IEEEフローティングポイント番号です。[Y.1540]で定義されているように、Path PLRは、総送信IPパケットに対する総失われたIPパケットの比率です。[Y.1541]では1分の評価間隔が示唆されており、観察された損失の数は結果の信頼に直接関連しています。<Path PLR>パラメーターの構成ルールは、最大値で10^-1のクランプを持つ合計です。PLRは10^-11の単位で報告されます。解像度が10^-11未満のシステムは、未使用の数字をゼロに設定する必要があります。個々のQNEは、ローカルPLR値（最大10^-2）を合計パスPLR値（最大10^-1）に追加します。ここでは、すべてのQNESで合計パスPLR値の受容性が追加されます。使用されているQoSMに基づいて決定されます。QNEのローカルPLR値の10^-2の最大制限と累積エンドツーエンドパス値の10^-1の最大制限（クランプ値）は、単純な添加剤蓄積関数の精度を維持するために使用されます指定され、より複雑な蓄積機能を回避するため。さらに、これらの最大値を超えた場合、パスはQoS目標を満たしていない可能性があります。異なる要素の値の合計が10^-1を超える場合、エンドツーエンドの累積PLRを不確定であると報告する必要があります。処理しているパケットのPLRを正確に予測できないQNEは、サポートされていないフラグを上げて、そのままパスPLRの値を残すか、下限の最良の推定値を追加する必要があります。上昇したサポートされていないフラグは、PATH PLRの値が実際のパスPLRの下限であることを示します。識別値10^-1は、不確定なplrを意味すると見なされます。処理しているパケットのPLRを正確に予測できないQNEは、ローカルパスPLRパラメーターをこの値に設定するはずです。構成関数は、構成された合計をこの値に制限するため、ネットワーク要素またはアプリケーションでのこの値の受領は、真のパスPLRが知られていないことを示します。これは、1つ以上のネットワーク要素が値を供給できなかったか、構成計算の範囲を超えたために発生する可能性があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PER is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541]. As defined in [Y.1540], Path PER is the ratio of total errored IP packets to the total of successful IP Packets plus errored IP packets, in which the number of errored packets observed is directly related to the confidence in the result. The composition rule for the <Path PER> parameter is summation with a clamp of 10^-1 on the maximum value. The PERs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero. An individual QNE adds its local PER value (up to a maximum of 10^-2) to the total Path PER value (up to a maximum of 10^-1) , where the acceptability of the total Path PER value added across all QNEs is determined based on the QOSM being used. The maximum limit of 10^-2 on a QNE's local PER value and the maximum limit (clamp value) of 10^-1 on the accumulated end-to-end Path PER value are used to preserve the accuracy of the simple additive accumulation function specified and to avoid more complex accumulation functions. Furthermore, if these maximums are exceeded, then the path would likely not meet the QoS objectives. If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PER SHOULD be reported as indeterminate. A QNE that cannot accurately predict the PER of packets it is processing MUST raise the Not Supported N flag and either leave the value of Path PER as is, or add its best estimate of its lower bound. A raised Not Supported N flag indicates the value of Path PER is a lower bound of the real Path PER. The distinguished value 10^-1 is taken to mean indeterminate PER. A QNE that cannot accurately predict the PER of packets it is processing SHOULD set its local path PER parameter to this value. Because the composition function limits the composed sum to this value, receipt of this value at a network element or application indicates that the true path PER is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
PATH PERは、ネットワークオクテット順[Y.1541]の単一の32ビット単一精度IEEEフローティングポイント番号です。[Y.1540]で定義されているように、パスPARは、成功したIPパケットとエラー化されたIPパケットの合計とエラーパケットの数が観測されたパケットの数と、結果の信頼性に直接関連しているため、誤ったIPパケットとエラーのあるIPパケットの比率です。<Path Per>パラメーターの構成ルールは、最大値で10^-1のクランプを持つ合計です。PERSは10^-11の単位で報告されています。解像度が10^-11未満のシステムは、未使用の数字をゼロに設定する必要があります。個々のQNEは、ローカルあたりの値（最大10^-2）を値ごとの合計パス（最大10^-1）に追加します。ここで、すべてのQNESに追加された値ごとの合計パスの受容性使用されているQoSMに基づいて決定されます。QNEのローカル値あたりの10^-2の最大制限と、累積エンドツーエンドパスごとに10^-1の最大制限（クランプ値）が使用され、単純な添加剤蓄積関数の精度を維持するために使用されます。指定され、より複雑な蓄積機能を回避するため。さらに、これらの最大値を超えた場合、パスはQoS目標を満たしていない可能性があります。異なる要素の値の合計が10^-1を超える場合、エンドツーエンドの累積PERは不確定であると報告する必要があります。処理されているパケットのごとを正確に予測できないQNEは、サポートされていないNフラグを上げて、パスの値をそのままにしておくか、下限の最良の推定値を追加する必要があります。支持されていないnフラグの上昇は、パスごとの値が実際のパスごとの下限であることを示します。識別された値10^-1は、あたりの不確定性を意味すると見なされます。処理されているパケットのごとを正確に予測できないQNEは、パラメーターごとにローカルパスをこの値に設定するはずです。構成関数は、構成された合計をこの値に制限するため、ネットワーク要素またはアプリケーションでのこの値の受領は、真のパスPerが知られていないことを示します。これは、1つ以上のネットワーク要素が値を供給できなかったか、構成計算の範囲を超えたために発生する可能性があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term (S) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Slack term S MUST be nonnegative and is measured in microseconds [RFC2212]. The Slack term, S, is represented as a 32-bit unsigned integer. Its value can range from 0 to (2^32)-1 microseconds.
Slack用語は非陰性でなければならず、マイクロ秒で測定されます[RFC2212]。Slack用語sは、32ビットの符号なし整数として表されます。その値は、0〜（2^32）-1マイクロ秒の範囲です。
The coding for the <Preemption Priority> and <Defending Priority> sub-parameters is as follows [RFC3181]:
<プリエンプション優先度>および<ディフェンディングプライリティ>サブパラメーターのコーディングは次のとおりです[RFC3181]：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority.
プリエンプションの優先順位：以前に認められたフローの防御優先度と比較した新しいフローの優先順位。より高い値は優先度が高いことを表します。
Defending Priority: Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.
防御の優先順位：フローが認められると、先制の優先順位は無関係になります。代わりに、その防御の優先順位は、新しいフローの先制優先度と比較するために使用されます。
As specified in [RFC3181], <Preemption Priority> and <Defending Priority> are 16-bit integer values, and both MUST be populated if the parameter is used.
[rfc3181]で指定されているように、<プリエンプション優先度>および<defending priority>は16ビット整数値であり、パラメーターを使用する場合は両方とも入力する必要があります。
The coding for the <Admission Priority> parameter is as follows:
<indation Priority>パラメーターのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.2171 Adm Pri.|Admis. Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two fields are provided for the <Admission Priority> parameter and are populated according to the following rules.
2つのフィールドが<Antisment Priority>パラメーターに提供され、次のルールに従って入力されます。
<Y.2171 Admission Priority> values are globally significant on an end-to-end basis. High priority flows, normal priority flows, and best-effort priority flows can have access to resources depending on their admission priority value, as described in [Y.2171], as follows:
<Y.2171入場の優先順位>値は、エンドツーエンドベースでグローバルに重要です。[Y.2171]に記載されているように、高い優先度フロー、通常の優先度フロー、および最良の優先度フローは、入場優先度の値に応じてリソースにアクセスできます。
<Y.2171 Admission Priority>:
<Y.2171入場の優先>：
0 - best-effort priority flow 1 - normal priority flow 2 - high priority flow
0-ベストエフォート優先フロー1-通常の優先フロー2-優先度の高いフロー
If the QNI signals <Y.2171 Admission Priority>, it populates both the <Y.2171 Admission Priority> and <Admission Priority> fields with the same value. Downstream QNEs MUST NOT change the value in the <Y.2171 Admission Priority> field so that end-to-end consistency is maintained and MUST treat the flow priority according to the value populated. A QNE in a local domain MAY reset a different value of <Admission Priority> in a Local QSPEC, but (as specified in Section 4.1) the Local QSPEC MUST be consistent with the Initiator QSPEC. That is, the local domain MUST specify an <Admission Priority> in the Local QSPEC that is functionally equivalent to the <Y.2171 Admission Priority> specified by the QNI in the Initiator QSPEC.
QNIが<Y.2171入場の優先度>を信号する場合、同じ値で<Y.2171入場優先度>と<入場優先度>フィールドの両方に入力されます。ダウンストリームQNESは、エンドツーエンドの一貫性が維持されるように、<Y.2171入場の優先度>フィールドの値を変更してはならないため、人口計算値に応じてフローの優先度を処理する必要があります。ローカルドメインのQNEは、ローカルQSPECで<入場優先度>の異なる値をリセットする場合がありますが、（セクション4.1で指定されているように）ローカルQSPECは、イニシエーターQSPECと一致する必要があります。つまり、ローカルドメインは、イニシエーターQSPECのQNIによって指定された<Y.2171入場優先度>に機能的に同等のローカルQSPECで<入場優先度>を指定する必要があります。
If the QNI signals admission priority according to [EMERGENCY-RSVP], it populates a locally significant value in the <Admission Priority> field and places all ones in the <Y.2171 Admission Priority> field. In this case, the functional significance of the <Admission Priority> value is specified by the local network administrator. Higher values indicate higher priority. Downstream QNEs and RSVP nodes MAY reset the <Admission Priority> value according to the local rules specified by the local network administrator, but MUST NOT reset the value of the <Y.2171 Admission Priority> field.
QNIが[Emergency-RSVP]に従って入場の優先順位を信号する場合、<入場優先度>フィールドの局所的に有意な値に浸透し、すべてのものを<Y.2171 Admision Priority>フィールドに配置します。この場合、<Antisment Priority>値の機能的意義は、ローカルネットワーク管理者によって指定されます。値が高いほど優先度が高いことを示します。ダウンストリームQNESおよびRSVPノードは、ローカルネットワーク管理者によって指定されたローカルルールに従って<入場優先度>値をリセットすることができますが、<Y.2171 Admision Priority>フィールドの値をリセットしてはなりません。
A reservation without an <Y.2171 Admission Priority> parameter MUST be treated as a reservation with an <Y.2171 Admission Priority> = 1.
<Y.2171入場の優先度のない予約>パラメーターは、<Y.2171入場優先度> = 1の予約として扱う必要があります。
The coding for the <RPH Priority> parameter is as follows:
<rph Priority>パラメーターのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC4412] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority", and if populated is applicable only to flows with high admission priority. A registry is created in [RFC4412] and extended in [EMERG-RSVP] for IANA to assign the RPH priority parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces and "Priority Numerical Values" are assigned to the RPH Priority.
[RFC4412]は、パラメーター「RPH Namespace」と「RPH Priority」を持つリソース優先ヘッダー（RPH）を定義します。レジストリは[RFC4412]に作成され、IANAがRPH優先パラメーターを割り当てるために[Emerg-RSVP]で拡張されます。拡張レジストリでは、「名前空間数値値」がIANAによってRPHネームスペースに割り当てられ、「優先数値値」がRPHの優先度に割り当てられます。
Note that the <Admission Priority> parameter MAY be used in combination with the <RPH Priority> parameter, which depends on the supported QOSM. Furthermore, if more than one RPH namespace is supported by a QOSM, then the QOSM MUST specify how the mapping between the priorities belonging to the different RPH namespaces are mapped to each other.
<Antisment Priority>パラメーターは、サポートされているQOSMに依存する<RPH Priority>パラメーターと組み合わせて使用できることに注意してください。さらに、複数のRPHネームスペースがQOSMによってサポートされている場合、QOSMは、異なるRPHネームスペースに属する優先順位間のマッピングが互いにマッピングされる方法を指定する必要があります。
Note also that additional work is needed to communicate these flow priority values to bearer-level network elements [VERTICAL-INTERFACE].
また、これらのフロー優先値をBearerレベルのネットワーク要素[垂直インターフェイス]に通知するには、追加の作業が必要であることに注意してください。
For the 4 priority parameters, the following cases are permissible (procedures specified in references):
4つの優先パラメーターの場合、次のケースが許容されます（参考文献で指定された手順）：
1 parameter: <Admission Priority> [Y.2171]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]
It is permissible to have <Admission Priority> without <RPH Priority>, but not permissible to have <RPH Priority> without <Admission Priority>. (Alternatively, <RPH Priority> is ignored in instances without <Admission Priority>.)
<rph priority>なしで<入場優先度>を持つことは許可されていますが、<indation Priority>なしで<rph Priority>を持つことは許されません。（または、<rph Priority>は、<入場優先度のない場合に無視されます>。）
Functionality similar to enhanced Multi-Level Precedence and Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) specifies use of <Admission Priority> corresponding to the 'queuing allowed' part of eMLPP, as well as <Preemption/Defending Priority> corresponding to the 'preemption capable' and 'may be preempted' parts of eMLPP.
強化されたマルチレベルの優先順位とプリエンプションサービス（EMLPP; [3GPP-1、3GPP-2]で定義されている）と同様の機能は、EMLPPの一部と<<Preemptionに対応する<入場優先度>の使用を指定します。/防御優先度> emlppの「先制能力」および「先制される」部分に対応しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Excess Treatment: Indicates how the QNE SHOULD process out-of-profile traffic, that is, traffic not covered by the <TMOD> parameter. The Excess Treatment Parameter is set by the QNI. Allowed values are as follows:
過剰な治療：QNEがプロファイル外のトラフィック、つまり<tmod>パラメーターでカバーされていないトラフィックをどのように処理するかを示します。過剰治療パラメーターはQNIによって設定されます。許可された値は次のとおりです。
0: drop 1: shape 2: re-mark 3: no metering or policing is permitted
0：ドロップ1：シェイプ2：再マーク3：メーターまたはポリシングは許可されていません
If no Excess Treatment Parameter is specified, the default is that there are no guarantees to excess traffic, i.e., a QNE can do whatever it finds suitable.
過剰な治療パラメーターが指定されていない場合、デフォルトは、過剰なトラフィックに保証がないことです。つまり、QNEは適切なものを何でも実行できます。
When excess treatment is set to 'drop', all marked traffic MUST be dropped by the QNE/RMF.
過剰な治療が「ドロップ」に設定されている場合、すべてのマークされたトラフィックはQNE/RMFによって落とさなければなりません。
When excess treatment is set to 'shape', it is expected that the QoS Desired object carries a TMOD parameter, and excess traffic is shaped to this TMOD. The bucket size in the TMOD parameter for excess traffic specifies the queuing behavior, and when the shaping causes unbounded queue growth at the shaper, any traffic in excess of the TMOD for excess traffic SHOULD be dropped. If excess treatment is set to 'shape' and no TMOD parameter is given, the E flag is set for the parameter and the reservation fails. If excess treatment is set to 'shape' and two TMOD parameters are specified, then the QOSM specification dictates how excess traffic should be shaped in that case.
過剰な処理が「形状」に設定されている場合、QoS望ましいオブジェクトにTMODパラメーターが搭載され、過剰なトラフィックがこのTMODに形作られることが予想されます。過剰なトラフィックのTMODパラメーターのバケットサイズは、キューイングの動作を指定し、シェーピングがシェーパーで固定されていないキューの成長を引き起こす場合、過剰なトラフィックのTMODを超えるトラフィックはすべて低下する必要があります。過剰な処理が「形状」に設定され、TMODパラメーターが与えられない場合、パラメーターに対してEフラグが設定され、予約が失敗します。過剰な処理が「形状」に設定され、2つのTMODパラメーターが指定されている場合、QOSM仕様はその場合、余分なトラフィックを形成する方法を決定します。
When excess treatment is set to 're-mark', the Excess Treatment Parameter MUST carry the re-mark value, and the re-mark values and procedures MUST be specified in the QOSM specification document. For example, packets may be re-marked to pertain to a particular QoS class (Diffserv Code Point (DSCP) value). In the latter case, re-marking relates to a Diffserv model where packets arrive marked as belonging to a certain QoS class / DSCP, and when they are identified as excess, they should then be re-marked to a different QoS Class (DSCP value) indicated in the 'Re-mark Value', as follows:
余分な治療が「再マーク」に設定されている場合、過剰な治療パラメーターは再マーク値を運ぶ必要があり、QOSM仕様ドキュメントで再マーク値と手順を指定する必要があります。たとえば、パケットは、特定のQoSクラス（DiffServ Code Point（DSCP）値）に関係するように再マイクされる場合があります。後者の場合、再マークは、パケットが特定のQoSクラス / DSCPに属しているとマークされているとマークされたDiffServモデルに関連し、それらが過剰であると識別されると、別のQoSクラス（DSCP値）に再マイクする必要があります）次のように、「再マーク値」に示されています。
Re-mark Value (6 bits): indicates DSCP value [RFC2474] to re-mark packets to when identified as excess
再マーク値（6ビット）：DSCP値[RFC2474]が過剰として識別された場合にパケットを再マークすることを示します
If 'no metering or policing is permitted' is signaled, the QNE should accept the Excess Treatment Parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, and should be used with caution.
「メーターまたはポリシングが許可されていない」が信号が表示されない場合、QNEは、過剰なトラフィックが問題を引き起こさないように、特別な注意を払って送信者によって設定された過剰な治療パラメーターを受け入れる必要があります。nullメーター[RFC3290]を要求するには、特に強力であり、注意して使用する必要があります。
A NULL metering application [RFC2997] would not include the traffic profile, and conceptually it should be possible to support this with the QSPEC. A QSPEC without a traffic profile is not excluded by the current specification. However, note that the traffic profile is important even in those cases when the excess treatment is not specified, e.g., in negotiating bandwidth for the best-effort aggregate. However, a "NULL Service QOSM" would need to be specified where the desired QNE Behavior and the corresponding QSPEC format are described.
ヌルメーターアプリケーション[RFC2997]にはトラフィックプロファイルが含まれておらず、概念的にはQSPECでこれをサポートできるはずです。トラフィックプロファイルのないQSPECは、現在の仕様によって除外されません。ただし、過剰な治療が指定されていない場合でもトラフィックプロファイルは重要であることに注意してください。ただし、目的のQNE動作と対応するQSPEC形式が記載されている場合、「Null Service QOSM」を指定する必要があります。
As an example behavior for a NULL metering, in the properly configured Diffserv router, the resources are shared between the aggregates by the scheduling disciplines. Thus, if the incoming rate increases, it will influence the state of a queue within that aggregate, while all the other aggregates will be provided sufficient bandwidth resources. NULL metering is useful for best-effort and signaling data, where there is no need to meter and police this data as it will be policed implicitly by the allocated bandwidth and, possibly, active queue management mechanism.
適切に構成されたDiffServルーターでは、ヌルメーターの動作の例として、リソースはスケジューリング分野によって集合体間で共有されます。したがって、着信レートが上昇すると、その集合体内のキューの状態に影響しますが、他のすべての集合体は十分な帯域幅リソースを提供されます。NULLメーターは、割り当てられた帯域幅、場合によってはアクティブキュー管理メカニズムによって暗黙的にポリシングされるため、このデータを計算および警察する必要のないベストエフォートおよびシグナリングデータに役立ちます。
The coding for the <PHB Class> parameter is as follows [RFC3140]:
<PHBクラス>パラメーターのコーディングは次のとおりです[RFC3140]：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB Field | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The above encoding is consistent with [RFC3140], and the following four figures show four possible formats based on the value of the PHB Field.
上記のエンコーディングは[RFC3140]と一致しており、次の4つの図は、PHBフィールドの値に基づいて4つの可能な形式を示しています。
Single PHB:
シングルPHB：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0|
+---+---+---+---+---+---+---+---+
Set of PHBs:
PHBのセット：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0|
+---+---+---+---+---+---+---+---+
PHBs not defined by standards action, i.e., experimental or local use PHBs as allowed by [RFC2474]. In this case, an arbitrary 12-bit PHB identification code, assigned by the IANA, is placed left-justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
標準訴訟では定義されていないPHB、つまり、[RFC2474]で許可されている実験的または局所使用PHB。この場合、IANAによって割り当てられた任意の12ビットPHB識別コードが、16ビットフィールドに左正直に配置されます。ビット15は1に設定されており、ビット14は単一のPHBではゼロまたはPHBのセットで1です。ビット12と13はゼロです。
Single non-standard PHB (experimental or local):
単一の非標準PHB（実験的またはローカル）：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 0 1|
+---+---+---+---+---+---+---+---+
Set of non-standard PHBs (experimental or local):
標準以外のPHB（実験またはローカル）のセット：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 1 1|
+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future.
BITS 12と13は、PHB識別コードの拡張またはその他の使用のために、将来のある時点で予約されています。
In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID.
どちらの場合も、単一のpHBIDを使用してPHBのセットを識別する場合（つまり、ビット14が1に設定されます）、PHBのセットはPHBスケジューリングクラスを構成する必要があります（つまり、セットからのPHBの使用はイントラを引き起こしてはなりません-microflowのトラフィックは、セットから異なるphbが同じマイクロフロー内のトラフィックに適用される場合に並べ替えます）。AF1X PHB [RFC2597]のセットは、PHBスケジューリングクラスの例です。PHBスケジューリングクラスを構成しないPHBのセットは、複数のPHBIDを使用することで識別できます。
The registries needed to use RFC 3140 already exist; see [DSCP-REGISTRY] and [PHBID-CODES-REGISTRY]. Hence, no new registry needs to be created for this purpose.
RFC 3140を使用するために必要なレジストリはすでに存在します。[dscp-registry]および[phbid-codes-registry]を参照してください。したがって、この目的のために新しいレジストリを作成する必要はありません。
A description of the semantic of the parameter values can be found in [RFC4124]. The coding for the <DSTE Class Type> parameter is as follows:
パラメーター値のセマンティックの説明は、[RFC4124]に記載されています。<DSTEクラスタイプ>パラメーターのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 13 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Cls. Type | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DSTE Class Type: Indicates the DSTE class type. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
DSTEクラスタイプ：DSTEクラスタイプを示します。現在許可されている値は0、1、2、3、4、5、6、および7です。
The coding for the <Y.1541 QoS Class> parameter [Y.1541] is as follows:
<Y.1541 QOSクラス>パラメーター[Y.1541]のコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
Y.1541 QOSクラス：Y.1541 QoSクラスを示します。現在許可されている値は0、1、2、3、4、5、6、および7です。
Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
クラス0：ジッターに敏感なリアルタイム、高度にインタラクティブなアプリケーション。平均遅延<= 100 ms、遅延変動<= 50 ms、および損失比<= 10^-3。アプリケーションの例には、VoIPとビデオ通信が含まれます。
Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
クラス1：ジッターに敏感なリアルタイムのインタラクティブなアプリケーション。平均遅延<= 400 ms、遅延変動<= 50 ms、および損失比<= 10^-3。アプリケーションの例には、VoIPとビデオ通信が含まれます。
Class 2: Highly interactive transaction data. Mean delay <= 100 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
クラス2：高度にインタラクティブなトランザクションデータ。平均遅延<= 100ミリ秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、シグナリングが含まれます。
Class 3: Interactive transaction data. Mean delay <= 400 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
クラス3：インタラクティブトランザクションデータ。平均遅延<= 400ミリ秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、シグナリングが含まれます。
Class 4: Low Loss Only applications. Mean delay <= 1 s, delay variation is unspecified, loss ratio <= 10^-3. Application examples include short transactions, bulk data, and video streaming.
クラス4：低損失のみのアプリケーション。平均遅延<= 1秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、短いトランザクション、バルクデータ、ビデオストリーミングが含まれます。
Class 5: Unspecified applications with unspecified mean delay, delay variation, and loss ratio. Application examples include traditional applications of default IP networks.
クラス5：不特定の平均遅延、遅延変動、および損失比を持つ不特定のアプリケーション。アプリケーションの例には、デフォルトのIPネットワークの従来のアプリケーションが含まれます。
Class 6: Applications that are highly sensitive to loss. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and Time-Division Multiplexing (TDM) circuit emulation.
クラス6：損失に非常に敏感なアプリケーション。平均遅延<= 100 ms、遅延変動<= 50 ms、および損失比<= 10^-5。アプリケーションの例には、テレビ輸送、大容量のTCP転送、および時間分割多重化（TDM）回路エミュレーションが含まれます。
Class 7: Applications that are highly sensitive to loss. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and TDM circuit emulation.
クラス7：損失に非常に敏感なアプリケーション。平均遅延<= 400 ms、遅延変動<= 50 ms、および損失比<= 10^-5。アプリケーションの例には、テレビ輸送、大容量のTCP転送、およびTDM回路エミュレーションが含まれます。
QSPEC security is directly tied to QoS NSLP security, and the QoS NSLP document [RFC5974] has a very detailed security discussion in Section 7. All the considerations detailed in Section 7 of [RFC5974] apply to QSPEC.
QSPECセキュリティはQOS NSLPセキュリティに直接結び付けられており、QoS NSLPドキュメント[RFC5974]はセクション7で非常に詳細なセキュリティディスカッションを行います。
The priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such attacks, for example:
優先パラメーターは、ユーザーが実際に必要とせずにフローの緊急の優先順位を請求できるため、盗難攻撃の可能性を高め、それにより、深刻な緊急呼び出しを効果的に防ぐことができます。そのような攻撃に対抗するためのいくつかのオプションが存在します。
- only some user groups (e.g., the police) are authorized to set the emergency priority bit
- 一部のユーザーグループ（例：警察）のみが緊急の優先ビットを設定する権限があります
- any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police)
- すべてのユーザーは、特定の宛先アドレス（例：警察）に緊急事態の優先ビットを採用することを許可されています
This section defines the registries and initial codepoint assignments for the QSPEC template, in accordance with BCP 26, RFC 5226 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints.
このセクションでは、BCP 26、RFC 5226 [RFC5226]に従って、QSPECテンプレートのレジストリと初期コードポイント割り当てを定義します。また、新しいコードポイントを割り当てる際にIANAが従うべき手続き要件を定義します。
This specification creates the following registries with the structures as defined below:
この仕様では、以下に定義するように、構造を含む次のレジストリを作成します。
Object Types (12 bits): The following values are allocated as specified in Section 5: 0: QoS Desired 1: QoS Available 2: QoS Reserved 3: Minimum QoS
オブジェクトタイプ（12ビット）：次の値は、セクション5：0で指定されているように割り当てられます：QoS希望1：QOS利用可能2：QOS予約3：最小QO
Further values are as follows: 4-63: Unassigned 64-67: Private/Experimental Use 68-4095: Reserved (Note: 'Reserved' just means 'do not give these out'.) The registration procedure is Specification Required.
さらなる値は次のとおりです。4-63：割り当てされていない64-67：プライベート/実験的使用68-4095：予約済み（「予約」は「これらを与えない」という意味です。）登録手順が必要です。
QSPEC Version (4 bits): The following value is allocated by this specification: 0: Version 0 QSPEC Further values are as follows: 1-15: Unassigned The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QSPEC versions.)
QSPECバージョン（4ビット）：次の値はこの仕様によって割り当てられます：0：バージョン0 QSPECさらなる値は次のとおりです。1-15：登録手順が必要です。（QSPECバージョンを減価償却、削除、または変更するには、仕様が必要です。）
QSPEC Type (5 bits): The following values are allocated by this specification: 0: Default 1: Y.1541-QOSM [RFC5976] 2: RMD-QOSM [RFC5977] Further values are as follows: 3-12: Unassigned 13-16: Local/Experimental Use 17-31: Reserved The registration procedure is Specification Required.
QSPECタイプ（5ビット）：次の値はこの仕様によって割り当てられます：0：デフォルト1：Y.1541-QOSM [RFC5976] 2：RMD-QOSM [RFC5977]さらなる値は次のとおりです。16：ローカル/実験的使用17-31：予約登録手順が必要です。
QSPEC Procedure (8 bits):
The QSPEC Procedure object consists of the Message Sequence parameter
(4 bits) and the Object Combination parameter (4 bits), as discussed
in Section 4.3. Message Sequences 0 (Two-Way Transactions), 1
(Three-Way Transactions), and 2 (Resource Queries) are explained in
Sections 4.3.1, 4.3.2, and 4.3.3, respectively. Tables 1, 2, and 3
in Section 4.3 assign the Object Combination Number to Message
Sequences 0, 1, and 2, respectively. The values assigned by this
specification for the Message Sequence parameter and the Object
Combination parameter are summarized here:
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS Available
Further values of the Message Sequence parameter (4 bits) are as follows: 3-15: Unassigned
メッセージシーケンスパラメーター（4ビット）のさらなる値は次のとおりです。3-15：未割り当て
Further values of the Object Combination parameter (4 bits) are as follows:
オブジェクトの組み合わせパラメーター（4ビット）のさらなる値は次のとおりです。
Message | Object
Sequence | Combination
---------------------------
0 | 3-15: Unassigned
1 | 3-15: Unassigned
2 | 1-15: Unassigned
3-15 | 0-15: Unassigned
The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QSPEC Procedures.)
登録手順が必要です。（QSPEC手順を減価償却、削除、または変更するには、仕様が必要です。）
QoS Model Error Code (8 bits): QoS Model Error Codes may be defined for NSLP error class 6 (QoS Model Error), as described in Section 6.4 of [RFC5974]. Values are as follows: 0-63: Unassigned 64-67: Private/Experimental Use 68-255: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QoS Model Error Codes.)
QoSモデルエラーコード（8ビット）：QoSモデルエラーコードは、[RFC5974]のセクション6.4で説明されているように、NSLPエラークラス6（QOSモデルエラー）に対して定義される場合があります。値は次のとおりです。0-63：未割り当て64-67：プライベート/実験的使用68-255：予約登録手順が必要です。（QoSモデルエラーコードを減価償却、削除、または変更するには、仕様が必要です。）
Parameter ID (12 bits): The following values are allocated by this specification: 1-14: assigned as specified in Section 5.2: 1: <TMOD-1> 2: <TMOD-2> 3: <Path Latency> 4: <Path Jitter> 5: <Path PLR> 6: <Path PER> 7: <Slack Term> 8: <Preemption Priority> and <Defending Priority> 9: <Admission Priority> 10: <RPH Priority> 11: <Excess Treatment> 12: <PHB Class> 13: <DSTE Class Type> 14: <Y.1541 QoS Class> Further values are as follows: 15-255: Unassigned 256-259: Private/Experimental Use 260-4095: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify Parameter IDs.)
パラメーターID（12ビット）：次の値はこの仕様によって割り当てられます：1-14：セクション5.2：1：<TMOD-1> 2：<TMOD-2> 3：<Path Latency> 4：<パスジッター> 5：<Path Plr> 6：<Path Per> 7：<Slack Term> 8：<Preemption Priority>および<Defending Priority> 9：<入場優先> 10：<RPH優先> 11：<超過治療>12：<PHBクラス> 13：<DSTEクラスタイプ> 14：<Y.1541 QOSクラス>さらなる値は次のとおりです。15-255：未割り当て256-259：プライベート/実験的使用260-4095：登録手順の予約仕様が必要です。（パラメーターIDを減価償却、削除、または変更するには、仕様が必要です。）
Y.2171 Admission Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 5.2.9: 0: best-effort priority flow 1: normal priority flow 2: high priority flow Further values are as follows: 3-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
Y.2171入学優先パラメーター（8ビット）：次の値はこの仕様によって割り当てられます：0-2：セクション5.2.9：0で指定されているように割り当てられます：最優秀エフォルト優先フロー1：通常の優先フロー2：高優先フローさらに値は次のとおりです。3-63：未割り当て64-255：予約登録手順が必要です。
RPH Namespace Parameter (16 bits): Note that [RFC4412] creates a registry for RPH Namespace and Priority values already (see Section 12.6 of [RFC4412]), and an extension to this registry is created in [EMERG-RSVP], which will also be used for the QSPEC RPH parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces, and
RPH名空間パラメーター（16ビット）：[RFC4412]はRPH名空間と優先度の値のレジストリをすでに作成していることに注意してください（[RFC4412]のセクション12.6を参照）、このレジストリの拡張は[Emerg-RSVP]で作成されます。QSPEC RPHパラメーターにも使用されます。拡張レジストリでは、「名前空間数値値」がIANAによってRPHネームスペースに割り当てられ、
"Priority Numerical Values" are assigned to the RPH Priority. There are no additional IANA requirements made by this specification for the RPH Namespace Parameter.
「優先度の数値値」は、RPHの優先度に割り当てられます。RPH名空間パラメーターのこの仕様によって作成された追加のIANA要件はありません。
Excess Treatment Parameter (8 bits): The following values are allocated by this specification: 0-3: assigned as specified in Section 5.2.11: 0: drop 1: shape 2: re-mark 3: no metering or policing is permitted Further values are as follows: 4-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
過剰処理パラメーター（8ビット）：次の値はこの仕様によって割り当てられます：0-3：セクション5.2.11：0で指定されているように割り当てられます。値は次のとおりです。4-63：未割り当て64-255：予約登録手順が必要です。
Y.1541 QoS Class Parameter (8 bits): The following values are allocated by this specification: 0-7: assigned as specified in Section 5.2.14: 0: Y.1541 QoS Class 0 1: Y.1541 QoS Class 1 2: Y.1541 QoS Class 2 3: Y.1541 QoS Class 3 4: Y.1541 QoS Class 4 5: Y.1541 QoS Class 5 6: Y.1541 QoS Class 6 7: Y.1541 QoS Class 7 Further values are as follows: 8-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
Y.1541 QoSクラスパラメーター（8ビット）：次の値はこの仕様によって割り当てられます：0-7：セクション5.2.14：0で指定されているように割り当てられます：Y.1541 QOSクラス0 1：Y.1541 QOSクラス1 2：Y.1541 QOSクラス2 3：Y.1541 QoSクラス3 4：Y.1541 QOSクラス4 5：Y.1541 QOSクラス5 6：Y.1541 QOSクラス6 7：Y.1541 QOSクラス7さらなる値は次のように：8-63：未割り当て64-255：予約された登録手順が必要です。
The authors would like to thank (in alphabetical order) David Black, Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and Sven van den Bosch for their very helpful suggestions.
著者は、（アルファベット順の順序で）デイビッド・ブラック、ケン・カールバーグ、アンナ・チャーニー、クリスチャン・ディックマン、エイドリアン・ファレル、ルーディガー・ガイブ、マティアス・フリードリッヒ、Xiaoming FU、ジャネット・ガン、ロバート・ハンコック、クリス・ラング、ジュッカ・マナー、マーティン・スティメーリングに感謝したいと思います。Nguyen、Tom Phelan、James Polk、Alexander Seyenko、John Rosenberg、Hannes Tschofenig、Sven Van Den Boschの非常に役立つ提案をしてくれました。
This document is the result of the NSIS Working Group effort. In addition to the authors/editors listed in Section 12, the following people contributed to the document: Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany Phone: +49 721 608 6413 EMail: bless@kit.edu URI: http://tm.kit.edu/~bless
このドキュメントは、NSISワーキンググループの努力の結果です。セクション12にリストされている著者/編集者に加えて、次の人々がこの文書に貢献しました。RolandBlessTelematics Institute、Karlsruhe Institute of Technology（Kit）Zirkel 2、Building 20.20 P.O.Box 6980 Karlsruhe 76049ドイツ電話：49 721 608 6413メール：bless@kit.edu Uri：http：//tm.kit.edu/~bless
Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: +1 973-236-6700 Fax: +1 973-236-7453 EMail: cdvorak@research.att.com
チャックdvorak AT＆Tルーム2A37 180パークアベニュー、ビルディング2フローハムパーク、ニュージャージー州07932電話：1 973-236-6700ファックス：1 973-236-7453メール：cdvorak@research.att.com
Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex FRANCE Phone: +33 1 69 63 41 87 EMail: yacine.el_mghazli@alcatel.fr
YACINE EL MGHAZLI ALCATEL ROUTE DE NOZAY 91460 MARCOSSIS CEDEX FRANCE電話：33 1 69 63 41 87電子メール：Yacine.el_mghazli@alcatel.fr
Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands EMail: g.karagiannis@ewi.utwente.nl
Georgios Karagiannis University of Twente P.O.Box 217 7500 AE Enschedeオランダのメール：g.karagiannis@ewi.utwente.nl
Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-1571 Fax: +1 732 368-1192 EMail: acmorton@att.com
アンドリュー・マクドナルド・シーメンス/ローク・マナー・リサーチ・ローク・マナー・リサーチ・リミテッド、ロムシー、ハンツSO51 0ZN UKメール：andrew.mcdonald@roke.co.uk al Morton AT＆TルームD3-3C06 200 S. Laurel Avenue Middletown、NJ 07748電話：-1571 FAX：1 732 368-1192メール：acmorton@att.com
Bernd Schloer University of Goettingen EMail: bschloer@cs.uni-goettingen.de
Bernd Schloer Goettingen University Email：bschloer@cs.uni-goettingen.de
Percy Tarapore AT&T Room D1-33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-4172 EMail: tarapore@.att.com
Percy Tarapore AT＆TルームD1-33 200 S.ローレルアベニューミドルタウン、ニュージャージー07748電話：1 732 420-4172メール：Tarapore@.att.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 Se-164 80 Stockholm、Sweden Email：lars.westberg@ericsson.com
[3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; enhanced Multi Level Precedence and Preemption service (eMLPP) - Stage 1 (Release 7).
[3GPP-1] 3GPP TS 22.067 V7.0.0（2006-03）技術仕様、第3世代パートナーシッププロジェクト。技術仕様グループサービスとシステムの側面。強化されたマルチレベルの優先順位とプリエンプションサービス（EMLPP） - ステージ1（リリース7）。
[3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 2 (Release 7).
[3GPP-2] 3GPP TS 23.067 V7.1.0（2006-03）技術仕様、第3世代パートナーシッププロジェクト。技術仕様グループコアネットワーク。強化されたマルチレベルの優先順位とプリエンプションサービス（EMLPP） - ステージ2（リリース7）。
[3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 3 (Release 6).
[3GPP-3] 3GPP TS 24.067 V6.0.0（2004-12）技術仕様、第3世代パートナーシッププロジェクト。技術仕様グループコアネットワーク。強化されたマルチレベルの優先順位とプリエンプションサービス（EMLPP） - ステージ3（リリース6）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215] Shenker、S。およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140] Black、D.、Brim、S.、Carpenter、B。、およびF. Le Faucheur、「Per Hopの動作識別コード」、RFC 3140、2001年6月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 3181、2001年10月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F.、ed。、「Diffserv-Aware MPLS Traffic Engineeringのサポートのためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinne、H。およびJ. Polk、「セッション開始プロトコル（SIP）の通信リソースの優先順位」、RFC 4412、2006年2月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506] Eisler、M.、ed。、「XDR：外部データ表現標準」、STD 67、RFC 4506、2006年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、RFC 5974、2010年10月。
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006.
[Y.1541] ITU-T推奨Y.1541、「IPベースのサービスのネットワークパフォーマンス目標」、2006年2月。
[Y.2171] ITU-T Recommendation Y.2171, "Admission Control Priority Levels in Next Generation Networks", September 2006.
[Y.2171] ITU-Tの推奨Y.2171、「次世代ネットワークの入場制御優先レベル」、2006年9月。
[COMPOSITION] Morton, A. and E. Stephan, "Spacial Composition of Metrics", Work in Progress, July 2010.
[構成] Morton、A。およびE. Stephan、「メトリックの空間構成」、2010年7月の作業。
[DQOS] CableLabs, "PacketCable Dynamic Quality of Service Specification", CableLabs Specification PKT-SP-DQOS-I12-050812, August 2005.
[DQOS] CableLabs、「Packetcable Dynamic Quality of Service Specification」、CableLabs仕様PKT-SP-DQOS-I12-050812、2005年8月。
[EMERG-RSVP] Le Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority", Work in Progress, March 2010.
[Emerg-RSVP] Le Faucheur、F.、Polk、J。、およびK. Carlberg、「リソース予約プロトコル（RSVP）入場優先事項の拡張」、2010年3月の進行中。
[G.711] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies", November 1988.
[G.711] ITU-Tの推奨G.711、「音声周波数のパルスコード変調（PCM）」、1988年11月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985.
[IEEE754]電気およびエレクトロニクスエンジニアの研究所、「バイナリフローティングポイント算術のIEEE標準」、ANSI/IEEE Standard 754-1985、1985年8月。
[CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.
[CL-QOSM] Kappler、C。、「NSISを使用したIntServ制御荷重サービスのシグナリングのQoSモデル」、2010年4月、進行中の作業。
[DSCP-REGISTRY] IANA, "Differentiated Services Field Codepoints", http://www.iana.org.
[DSCP-Registry] IANA、「Dishireated Services Field CodePoints」、http://www.iana.org。
[NETWORK-OCTET-ORDER] Wikipedia, "Endianness", http://en.wikipedia.org/wiki/Endianness.
[Network-octet-order] wikipedia、 "endianness"、http://en.wikipedia.org/wiki/endianness。
[PHBID-CODES-REGISTRY] IANA, "Per Hop Behavior Identification Codes", http://www.iana.org.
[phbid-codes-registry] iana、「ホップの動作識別コードごと」、http：//www.iana.org。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「ジェネリックルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「IPv4ネットワーク上の一般的なルーティングカプセル化」、RFC 1702、1994年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen、J。およびR. Guerin、「単一レート3色マーカー」、RFC 2697、1999年9月。
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[RFC2997] Bernet、Y.、Smith、A。、およびB. Davie、「ヌルサービスタイプの仕様」、RFC 2997、2000年11月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290] Bernet、Y.、Blake、S.、Grossman、D。、およびA. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリックのIPパケット遅延変動メトリック（IPPM）」、RFC 3393、2002年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件」、RFC 3564、2003年7月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
[RFC4301] Kent、S。およびK. Seo、「セキュリティアーキテクチャ
Internet Protocol", RFC 4301, December 2005.
インターネットプロトコル」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、A。およびB. Claise、「パケット遅延変動適用ステートメント」、RFC 5481、2009年3月。
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010.
[RFC5976] Ash、G.、Morton、A.、Dolly、M.、Tarapore、P.、Dvorak、C。、およびY. El Mghazli、 "Y.1541-QOSM：Y.1541 Quality-Qualks-for Networkのモデル - of-serviceクラス」、RFC 5976、2010年10月。
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C, and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv", RFC 5977, October 2010.
[RFC5977] Bader、A.、Westberg、L.、Karagiannis、G.、Kappler、C、およびT. Phelan、「RMD-QOSM：Diffservのリソース管理のためのNSISサービス品質モデル」、RFC 5977、2010年10月。
[VERTICAL-INTERFACE] Dolly, M., Tarapore, P., and S. Sayers, "Discussion on Associating of Control Signaling Messages with Media Priority Levels", T1S1.7 and PRQC, October 2004.
[Vertical-interface] Dolly、M.、Tarapore、P。、およびS. Sayers、「コントロールシグナリングメッセージのメディア優先レベルの関連付けに関する議論」、T1S1.7およびPRQC、2004年10月。
[Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", December 2002.
[Y.1540] ITU -Tの推奨Y.1540、「インターネットプロトコルデータ通信サービス - IPパケット転送および可用性パフォーマンスパラメーター」、2002年12月。
Appendix A. Mapping of QoS Desired, QoS Available, and QoS Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ
付録A. RSVP IntServのADSPEC、TSPEC、およびRSPECにNSIを希望のQOS、QOS、およびQOSのマッピング
The union of QoS Desired, QoS Available, and QoS Reserved can provide all functionality of the objects specified in RSVP IntServ; however, it is difficult to provide an exact mapping.
QoSの希望の統合、利用可能なQoS、およびQoS予約されたQoSは、RSVP IntServで指定されたオブジェクトのすべての機能を提供できます。ただし、正確なマッピングを提供することは困難です。
In RSVP, the Sender TSpec specifies the traffic an application is going to send (e.g., TMOD). The AdSpec can collect path characteristics (e.g., delay). Both are issued by the sender. The receiver sends the FlowSpec that includes a Receiver TSpec describing the resources reserved using the same parameters as the Sender TSpec, as well as an RSpec that provides additional IntServ QoS Model specific parameters, e.g., Rate and Slack.
RSVPでは、送信者TSPECは、アプリケーションが送信するトラフィック（TMODなど）を指定します。ADSPECは、パス特性（遅延など）を収集できます。どちらも送信者によって発行されます。受信者は、送信者TSPECと同じパラメーターを使用して予約されたリソースを記述するレシーバーTSPECを含むFlowsPecと、追加のIntServ QOSモデル固有のパラメーター（レートやスラックなど）を提供するRSPECを送信します。
The RSVP TSpec, AdSpec, and RSpec are tailored to the receiver-initiated signaling employed by RSVP and the IntServ QoS Model. For example, to the knowledge of the authors, it is not possible for the sender to specify a desired maximum delay except implicitly and mutably by seeding the AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in the receiver-issued RSVP RESERVE message. For this reason, our discussion at this point leads us to a slightly different mapping of necessary functionality to objects, which should result in more flexible signaling models.
RSVP TSPEC、ADSPEC、およびRSPECは、RSVPおよびIntServ QoSモデルで使用される受信機によって開始されたシグナル伝達に合わせて調整されています。たとえば、著者の知識には、それに応じてADSPECをシードすることにより、暗黙的かつ変異的に除き、送信者が目的の最大遅延を指定することはできません。同様に、RSPECは、受信者が発行したRSVPリザーブメッセージでのみ有意義に送信されます。このため、この時点での議論は、オブジェクトに必要な機能をわずかに異なるマッピングに導き、より柔軟なシグナル伝達モデルになります。
In an example VoIP application that uses RTP [RFC3550] and the G.711 Codec [G.711], the TMOD-1 parameter could be set as follows:
RTP [RFC3550]とG.711コーデック[G.711]を使用するVOIPアプリケーションの例では、TMOD-1パラメーターを次のように設定できます。
In the simplest case, the Minimum Policed Unit m is the sum of the IP, UDP, and RTP headers + payload. The IP header in the IPv4 case has a size of 20 octets (40 octets if IPv6 is used). The UDP header has a size of 8 octets, and RTP uses a 12-octet header. The G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming RTP transmits voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets.
最も簡単な場合、最小ポリシーユニットMは、IP、UDP、およびRTPヘッダーペイロードの合計です。IPv4ケースのIPヘッダーのサイズは20オクテット（IPv6を使用する場合は40オクテット）です。UDPヘッダーのサイズは8オクターで、RTPは12オクテットのヘッダーを使用します。G.711コーデックは、64 kbit/s（8000オクテット/s）の帯域幅を指定します。RTPが20ミリ秒ごとに音声データグラムを送信すると仮定すると、1つのデータグラムのペイロードは8000オクテット/s * 0.02 s = 160オクテットです。
IPv4 + UDP + RTP + payload: m = 20 + 8 + 12 + 160 octets = 200 octets
IPv6 + UDP + RTP + payload: m = 40 + 8 + 12 + 160 octets = 220 octets
The Rate r specifies the amount of octets per second. 50 datagrams are sent per second.
レートrは、1秒あたりのオクテットの量を指定します。50個のデータグラムが1秒あたり送信されます。
IPv4: r = 50 1/s * m = 10,000 octets/s IPv6: r = 50 1/s * m = 11,000 octets/s The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used.
IPv4：r = 50 1/s * m = 10,000オクテット/s IPv6：r = 50 1/s * m = 11,000オクテット/sバケットサイズbは最大バーストを指定します。この例では、10個のパケットのバーストが使用されています。
IPv4: b = 10 * m = 2000 octets
IPv6: b = 10 * m = 2200 octets
A number of extra headers (e.g., for encapsulation) may be included in the datagram. A non-exhaustive list is given below. For additional headers, m, r, and b have to be set accordingly.
Datagramには、多くの追加のヘッダー（例：カプセル化用）が含まれる場合があります。以下の網羅的でないリストを示します。追加のヘッダーの場合、M、R、およびBをそれに応じて設定する必要があります。
Protocol Header Size
--------------------------+------------
GRE [RFC1701] | 8 octets
GREIP4 [RFC1702] | 4-8 octets
IP4INIP4 [RFC2003] | 20 octets
MINENC [RFC2004] | 8-12 octets
IP6GEN [RFC2473] | 40 octets
IP6INIP4 [RFC4213] | 20 octets
IPsec [RFC4301, RFC4303] | variable
--------------------------+------------
Authors' Addresses
著者のアドレス
Gerald Ash (Editor) AT&T EMail: gash5107@yahoo.com
Gerald Ash（編集者）AT＆Tメール：gash5107@yahoo.com
Attila Bader (Editor) Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com
Attila Bader（編集者）Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u。1 H-1037 Budapestハンガリーメール：attila.bader@ericsson.com
Cornelia Kappler (Editor) ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
Cornelia Kappler（編集者）CK Technology Concepts Berlin、Germany Email：cornelia.kappler@cktecc.de
David R. Oran (Editor) Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720, USA EMail: oran@cisco.com
David R. Oran（編集者）Cisco Systems、Inc。7 Ladyslipper Lane Acton、MA 01720、USAメール：oran@cisco.com