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)
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パラメータは、いくつかのQOSMsに再利用するための共通言語を提供し、それによって、QoSのNSLPの拡張性と相互運用性を確保することを目指しています。ベースプロトコルはQOSMにとらわれないであるが、QSPEC対象に実施することができるパラメータは、おそらく密接特定のモデルに結合されています。 NSISシグナリングを開始ノードは、それによってシグナリング経路に沿って保持されNSIS開始の意図を確実に、より少ない予約が失敗した下流ノードによって解釈されなければならないQSPECパラメータを示すイニシエータQSPECを、追加します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5975.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5975で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の設計は、（RMF区別はシグナリングプロトコルの動作およびリソース管理機能の動作に必要な情報との間に形成されているRSVP [RFC2205]とのIntServアーキテクチャとの間のデカップリング[RFC2210]に概念的に類似しています）。この文書は、QoS NSLPメッセージで運ばQSPEC（QOS仕様）オブジェクトで運ばRMF関連情報について説明しているが[RFC5974]は、シグナリングプロトコルを記載しています。
[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.
この文書はQSPECオブジェクトのテンプレートを記述しながら、QSPECオブジェクトを搬送することができるそれぞれが - RESERVE、QUERY、RESPONSE、およびNOTIFY - [RFC5974]は4つのQoS NSLPメッセージを定義します。 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のみRMFの特定がQSPECを解釈する必要があり、異なるQOSMsのQoS予約を通知することが可能です。 QOSMsの例は、のIntServ、Diffservのアドミッション制御、および[CL-QOSM]で指定されたもの、[RFC5976]及び[RFC5977]です。
QSPEC parameters include, for example:
QSPECパラメータは、例えば：
o a mandatory traffic model (TMOD) parameter, o constraints parameters such as path latency and path jitter, o traffic handling directives such as excess treatment, and o traffic classifiers such as PHB class.
O必須のトラフィックモデル（TMOD）のパラメータ、例えばそのような過剰処理としてトラフィック処理の指示、およびPHBクラスなどOトラフィック分類Oパス遅延と経路ジッタ、などの制約パラメータO。
While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models.
ベースプロトコルはQOSMにとらわれないであるが、QSPEC対象に実施することができるパラメータは、おそらく密接特定のモデルに結合されています。
QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec objects specified in RSVP and may contain, respectively, a description of QoS Desired, QoS Reserved, and QoS Available. Going beyond RSVP functionality, the QSPEC also allows indicating a range of acceptable QoS by defining a QSPEC object denoting minimum QoS. Usage of these QSPEC objects is not bound to particular message types, thus allowing for flexibility. A QSPEC object collecting information about available resources may travel in any QoS NSLP message, for example, a QUERY message or a RESERVE message, as defined in [RFC5974]. The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP and is only interpreted by the RMF.
QSPECは緩くRSVPで指定TSpecの、RSpecの、およびADSPECオブジェクトに対応するオブジェクトと、それぞれ、利用可能な望ましいQoS、確保されたQoS、およびQoSの記述を含んでいてもよいです。 RSVP機能にとどまらず、QSPECも最低限のQoSを示すQSPECオブジェクトを定義することによって、許容されるのQoSの範囲を示すことができます。これらQSPECオブジェクトの使用は、このような柔軟性を可能にする、特定のメッセージ・タイプにバインドされていません。 [RFC5974]で定義されるように利用可能なリソースに関する情報を収集QSPECオブジェクトは、例えば、任意のQoS NSLPメッセージ、QUERYメッセージまたはRESERVEメッセージに移動することができます。 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パラメータは予約が失敗した他、パス内のすべてのQNEsによって解釈されなければなりません。理解されていない場合はこれとは対照的に、QNIによりフラグが立てられていないQSPECパラメータがスキップされてもよいです。追加QSPECパラメータは、情報の仕様書で定義され、それによってQoSのNSLPの拡張性と柔軟性を確保することができます。
A Local QSPEC can be defined in a local domain with the Initiator QSPEC encapsulated, where the Local QSPEC must be functionally consistent with the Initiator QSPEC in terms of defined source traffic and other constraints. That is, a domain-specific local QSPEC can be defined and processed in a local domain, which could, for example, enable simpler processing by QNEs within the local domain.
ローカルQSPECローカルQSPECが定義されたソース・トラフィック及び他の制約の観点からイニシエータQSPECと機能的に一致していなければならないカプセル化されたイニシエータQSPECのローカルドメインで定義することができます。すなわち、ドメイン固有のローカルQSPECを定義し、例えば、ローカルドメイン内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：、一緒に望ましいQoSまたは利用可能なQoSの説明とQSPECオブジェクトは、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イニシエータと、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は、希望：QSPECオブジェクト送信者が予約を要求するための所望のQoSを記述するパラメータを含みます。
QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF.
QoSモデル（QOSM）：トラフィックフローのためのQoSを達成するための方法、例えば、IntServの制御負荷。そのQOSMを実装QNEが支援し、どのように資源がRMFによって管理されることが可能であることQSPEC QoS制約とトラフィック処理ディレクティブのサブセットを指定します。
QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters.
QoSの予約：予約されたリソースと関連の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方法およびQoSシグナリングを使用するための手順およびQSPECパラメータ/オブジェクト内を定義することです特定のQoS展開。 QoSのNSLPは、多くのQOSMsのために信号を送ることができるシグナリングプロトコルの一般的な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はY. 1541のQoSクラス[RFC5976]のためのシグナリングトラフィックフローのQoS、例えば、制御のIntServロード[CL-QOSM]、Diffservの[RFC5977]とリソース管理、およびQoSを達成するための方法です。 QOSMは望ましい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.
QOSMsはNSIS対応ノードにおけるRMFの動作とQSPECオブジェクトで運ばれる情報に影響を与えます。いくつかの状況（例えば、集合）の下で、それらは別個NSLPセッションがQNIとしてRMFを有することによってインスタンス化させてもよいです。 [RFC5974]のセクション5.2で定義されるようQOSM仕様は、状態およびメッセージング処理ルールシグナリング根底のQoS NSLP内の意味論を実行するためのQoS NSLPを引き起こすRMFトリガを定義することができます。新しいQoSのNSLPメッセージ処理ルールは唯一のQoS NSLPの拡張で定義することができます。 QOSM仕様は既存のQoS NSLP処理ルールから逸脱トリガを定義している場合、そのQOSMをサポートしていないQNEsのフォールバックは、QoS NSLPの状態遷移/メッセージ処理ルールです。
The QOSM specification includes how the requested QoS resources will be described and how they will be managed by the RMF. For this purpose, the QOSM specification defines a set of QSPEC parameters it uses to describe the desired QoS and resource control in the RMF, and it may define additional QSPEC parameters.
QOSM仕様は、要求されたQoSリソースを説明し、それらがどのようにRMFによって管理される方法を含んでいます。この目的のために、QOSM仕様はQSPECのセットは、それがRMFに所望のQoSおよびリソース制御を説明するために使用するパラメータ定義し、それは追加のQSPECパラメータを定義することができます。
When a QoS NSLP message travels through different domains, it may encounter different QOSMs. Since QOSMs use different QSPEC parameters for describing resources, the QSPEC parameters included by the QNI may not be understood in other domains. The QNI therefore can flag those QSPEC parameters it considers vital with the M flag. QSPEC parameters with the M flag set must be interpreted by the downstream QNEs, or the reservation fails. QSPEC parameters without the M flag set should be interpreted by the downstream QNEs, but may be ignored if not understood.
QoS NSLPメッセージが異なるドメインを通過するとき、それは異なるQOSMsが発生することがあります。 QOSMsリソースを記述するために異なる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)
- QNEsの役割、例えば、位置、周波数、ステートフル、等 - 本QOSMに適用QSPEC手続き - - QSPECパラメータを含むQSPEC定義QNE処理ルールRMFで処理し、解釈する方法QSPEC記述する情報、例えば、アドミッション制御、スケジューリングデフォルトQNI動作（場合プリエンプションの場合に何が起こるかの定義 - 、ポリシー制御、QoSパラメータの蓄積（例えば、遅延） - 少なくとも1つのビットレベルQSPEC例 - QOSM仕様が定義する新しいQSPECパラメータのQSPECパラメータ挙動ティアダウン先取り予約）が続いていません（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節で述べたように、追加QOSM固有のエラー・コードの定義は、 - - QOSMを使用したいのQoS-NSLPオプション、いくつかのオプションがQOSMに利用可能である（例えば、ローカルQSPECいずれかaがする）イニシエータQSPECを隠しますローカル・ドメイン・メッセージ、またはb）内のイニシエータQSPECをカプセル化）。
QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the QSPEC. This includes traffic description parameters, constraint parameters, and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the QSPEC parameters specified in this document. Note that signaling functionality is only defined by the QoS NSLP document [RFC5974] and not by this document or by QOSM specification documents.
QOSMsはQSPECでサポートされている種類のいずれかのパラメータを追加することによって、QSPECsを拡張するために、IANA登録及び審査ルールの対象、無料です。これは、トラフィック記述パラメータ、制約パラメータ、およびトラフィック処理ディレクティブが含まれています。 QOSMsは、この文書で指定QSPECパラメータを再解釈または再定義するために、しかし、許可されていません。シグナル機能のみのQoS NSLPドキュメント[RFC5974]によると、この文書ではないか、またはQOSM仕様書で定義されていることに注意してください。
The QSPEC is the object of QoS NSLP containing QSPEC objects and parameters. QSPEC objects are the main building blocks of the QSPEC parameter set that is input or output of an RMF operation. QSPEC parameters are the parameters appearing in a QSPEC, which must include the traffic model parameter (TMOD), and may optionally include constraints (e.g., path latency), traffic handling directives (e.g., excess treatment), and traffic classifiers (e.g., PHB class). The RMF implements functions that are related to resource management and processes the QSPEC parameters.
QSPECはQSPECオブジェクトとパラメータを含むQoSのNSLPの目的です。 QSPECオブジェクトは、RMFの操作の入力または出力されるQSPECパラメータセットの主要なビルディングブロックです。 QSPECパラメータがトラフィックモデルパラメータ（TMOD）を含める必要がありQSPECに現れるパラメータであり、および任意の制約（例えば、パス待ち時間）、トラフィック処理の指示（例えば、過剰治療）、およびトラフィック分類を含むことができる（例えば、PHBクラス）。 RMFは、資源管理に関連する機能を実装し、QSPECパラメータを処理します。
The QSPEC consists of a QSPEC version number and QSPEC objects. IANA assigns a new QSPEC version number when the current version is deprecated or deleted (as required by a specification). Note that a new QSPEC version number is not needed when new QSPEC parameters are specified. Later QSPEC versions MUST be backward compatible with earlier QSPEC versions. That is, a version n+1 device must support QSPEC version n (or earlier). On the other hand, if a QSPEC version n (or earlier) device receives an NSLP message specifying QSPEC version n+1, then the version n device responds with an 'Incompatible QSPEC' error code (0x0f) response, as discussed in Section 4.2.3, allowing the QNE that sent the NSLP message to retry with a lower QSPEC version.
QSPECはQSPECのバージョン番号とQSPECオブジェクトで構成されています。 IANAは（仕様によって要求されるように）現在のバージョンは廃止又は削除され、新しいQSPECバージョン番号を割り当てます。新しいQSPECパラメータが指定された場合に、新たなQSPECのバージョン番号が必要とされていないことに注意してください。その後QSPECのバージョンは、以前のQSPECのバージョンとの下位互換性がなければなりません。すなわち、バージョンはn + 1デバイスはQSPECバージョンnをサポートする（またはそれ以前）しなければなりません。 QSPECバージョンN（またはそれ以前）デバイスがQSPECバージョンN + 1を指定NSLPメッセージを受信した場合、セクション4.2で議論するように一方、その後バージョンnデバイスは、「互換性のないQSPEC」エラーコード（0x0Fの）応答で応答します.3、下部QSPECバージョンで再試行するNSLPメッセージを送信したQNEを可能にします。
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.
この文書は、QOSMs間の相互運用性を促進するためにQSPECためのテンプレートを提供します。図1は、QSPECは最大4 QSPECオブジェクト、すなわちQoSがQoSが確保、QoSの利用可能な、所望の、そして最低限のQoSから構成されている様子を示します。これらQSPECの各オブジェクトは、QSPECパラメータの数で構成されています。所与QSPECはQSPECオブジェクトのサブセットのみを含んでいてもよい、例えば、QoSが望ましいです。 QSPECが望ましいQoSオブジェクト、利用可能なQoS、QoSの予約および最小QoSはすべてQNEsでサポートしなければならないし、任意のQoS NSLPメッセージ（RESERVE、QUERY、RESPONSE、NOTIFY）で運ばれた任意のQSPECオブジェクトに表示されることがあります。 QoSのNSLP RESERVE、QUERY、応答の説明については、[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）の使用は、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は常にRESERVEメッセージに含まれ、時にはQUERYメッセージ（詳細はセクション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の利用可能なオブジェクトは、RESERVEメッセージ、応答メッセージ、またはQUERYメッセージに移動することができるし、パス上で現在利用可能なリソースに関する情報を収集することがあります。この場合、利用可能なQoSを更新することができる利用可能なQoSに含まれるQSPECパラメータを意味読み書きオブジェクトですが、彼らは削除することはできません。そのため、各QNEは、このQSPECオブジェクトのすべてのパラメータを検査しなければならない、とこのQNEに利用可能なリソースが特定のパラメータが現在言うよりも小さい場合、QNEはそれに応じて、このパラメータを適応しなければなりません。したがって、メッセージは、メッセージ、<QoSが利用可能>の受信者に到達したときに、現在入手可能なパス上のリソースのボトルネックを反映しています。データパスに沿って利用可能なリソースを収集するために、例えば、QUERYメッセージに使用することができます。
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は、応答メッセージに移動するとき、それは実際には単にバックイニシエータにRESERVEまたはQUERYメッセージによって実行される前の測定の結果を搬送します。したがって、この場合には、利用可能なQoSは読み取り専用です。 4.3.2項（ケース3）に記載のものの他の例では、利用可能なQoSは読み取り専用QSPECオブジェクト（詳細については、セクション4.3.2を参照）のようにRESERVEメッセージにQNIにより送信されます。
The QoS Reserved object reflects the resources that are being reserved. It is a read-only object and is always included in a RESPONSE message if QoS Desired is included in the RESERVE message (see Section 4.3 for details).
オブジェクトを予約QoSが確保されているリソースを反映しています。これは、読み取り専用オブジェクトであり、所望のQoSが（詳細はセクション4.3を参照）RESERVEメッセージに含まれている場合、常に応答メッセージに含まれています。
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値と同じメッセージで許容可能な最小のQoSの両方を含むことによって許容されるQoSレベルの範囲を定義することを可能にします。このような損失率及び待ち時間のようないくつかのパラメータのために、どのように指定されているが最大許容値であるので、用語「最小」は、一般的に使用されることに注意してください。これは読み取り専用オブジェクトであり、RESERVEメッセージ、応答メッセージ、またはクエリメッセージ（詳細はセクション4.3を参照）に含まれていてもよいです。所望のQoSは、所望のQoSおよび/または利用可能QSPECオブジェクトが所望のQoS値に播種したQoSに含まれています。最小許容されるQoS値は、最低限のQoS QSPECオブジェクト内に符号化されてもよいです。メッセージはQNRに向かって移動したよう、利用可能なQoSは、パス上のQNEsによって更新されます。その値が最小のQoSの値を下回った場合、予約は失敗し、中止されます。この方法を採用した場合、予約は（詳細はセクション4.3を参照）に応じて適応する必要があるかもしれないので、QNRは、バックQNIにエンドで達成利用可能なQoSの値を知らせます。
Note that the relationship of QSPEC objects to RSVP objects is covered in Appendix A.
オブジェクトをRSVPにQSPECオブジェクトの関係は、付録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.
一つQSPECパラメータ、<TMOD>は、特別です。これは、リソースが予約されているため、トラフィックの説明を提供します。このパラメータは、QNIによって含まれている必要があり、それはすべてのQNEsによって解釈されなければなりません。それらが所望の基礎となるのQoSに適用されている場合は他のすべてのQSPECパラメータはQNIによって移入されています。それらは下流QNEsによって解釈されなければならない場合には、これらQSPECパラメータについて、QNIは、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.
この文書では、この用語は、RMF各QSPECパラメータに指定された参照で指定された一般的に受け入れられている規範的手順に従ってQSPECパラメータを処理すること、QSPECパラメータのRMF処理に関連して、手段を「解釈します」。それはQNIによりQSPECオブジェクトに移入されている場合QNEのみ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を無視することができることに留意されたいです。しかし、ローカルドメインのエッジ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.
前のセクションで説明したように、QoSパラメータはQSPECオブジェクトとどのメッセージ彼らはに表示さに応じて上書きされてもよいです。
The <Traffic Model> (TMOD) parameter is mandatory for the QNI to include in the Initiator QSPEC and mandatory for downstream QNEs to interpret. The traffic description specified by the TMOD parameter is a container consisting of 5 sub-parameters [RFC2212]:
QNIがイニシエータQSPECに含めると下流QNEsを解釈するために必須とするために、<交通モデル>（TMOD）パラメータが必須です。 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バケットサイズあたりのオクテットで指定されたOレート（r）は（b）のオクテットで指定された最大パケットサイズ（MPS）Oオクテットで指定された第二のO最小ポリシング単位（M）当たりのオクテットで指定されたピークレート（P）Oオクテットで指定されました
The TMOD parameter takes the form of a token bucket of rate (r) and bucket size (b), plus a peak rate (p), minimum policed unit (m), and maximum packet size (MPS).
TMODパラメータは、レート（R）とバケットサイズ（B）、プラスピーク率（P）、最小ポリシング単位（M）、および最大パケットサイズ（MPS）のトークンバケットの形をとります。
Both b and r MUST be positive. The rate, r, is measured in octets of IP packets per second, and can range from 1 octet per second to as large as 40 teraoctets per second. The bucket depth, b, is also measured in octets and can range from 1 octet to 250 gigaoctets. The peak rate, p, is measured in octets of IP packets per second and has the same range and suggested representation as the bucket rate.
BとRの両方が正でなければなりません。レートは、R、秒あたりのIPパケットのオクテットで測定され、毎秒1つのオクテットから毎秒40 teraoctetsと大きい範囲とすることができます。バケット深さ、Bは、また、オクテット単位で測定され、1つのオクテットから250 gigaoctetsの範囲とすることができます。ピークレート、pは、秒あたりのIPパケットのオクテットで測定され、同じ範囲を有しており、バケットレートとして表現を示唆しています。
The peak rate is the maximum rate at which the source and any reshaping (defined below) may inject bursts of traffic into the network. More precisely, it is a requirement that for all time periods the amount of data sent cannot exceed MPS+pT, where MPS is 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 + MPSが最大パケットサイズであるPtおよび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およびMPSの両方が正でなければならない、そしてmは以下MPSと等しくなければなりません。
Policing compares arriving traffic against the TMOD parameters at the edge of the network. Traffic is policed to ensure it conforms to the token bucket. Reshaping attempts to restore the (possibly distorted) traffic's shape to conform to the TMOD parameters, and traffic that is in violation of the TMOD is discovered because the reshaping fails and the reshaping buffer overflows.
ポリシングは、ネットワークのエッジでTMODパラメータに対するトラフィック到着比較します。トラフィックは、それがトークンバケットに準拠を保証するためにポリシングされます。 TMODパラメータに合致するトラフィックの形状は、（おそらく歪ん）を復元しようとする試みを再成形し、整形に失敗し、整形バッファオーバーフローのでTMODに違反しているトラフィックが発見されました。
The token bucket and peak rate parameters require that traffic MUST obey the rule that over all time periods, the amount of data sent cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token bucket parameters, MPS is the maximum packet size, and T is the length of the time period (note that when p is infinite, this reduces to the standard token bucket requirement). For the purposes of this accounting, links MUST count packets that are smaller than the minimum policing unit as being of size m. Packets that arrive at an element and cause a violation of the MPS + min[pT, rT+b-MPS] bound are considered non-conformant.
トークンバケットピークレートパラメータはトラフィックがすべての期間にわたって、送信されるデータの量を超えることができないという規則に従わなければならないことを必要とMPS +分間RとBがトークンバケットパラメータは、[pTを室温+ B-MPS]、 MPSは、最大パケットサイズであり、Tは（pが無限大である場合、これは標準のトークンバケット要件を減少させることに注意）期間の長さです。この会計の目的のために、リンクはサイズmのものとして最小ポリシング単位より小さいパケットをカウントしなければなりません。要素に到着し、MPS + minの違反を引き起こすパケット[pTを室温+の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 =大きく設定。
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の入力なる値です。エンド・ツー・エンドを構成する場合、この量は、QNR QNIからQNRへの経路に沿って最小TMODリソース（または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].
二つTMODパラメータは、いくつかのDiffservのアプリケーションをサポートするために必要とされ得るように、第2のパラメータ（<TMOD-2>）が指定されている場合、<TMOD-1>、セクション5で定義され、<TMOD-2>されています。例えば、典型的には、Diffservの緊急転送（EF）トラフィックが単一レートのトークンバケットが入口に成形されているものとします。したがって、単一TMODパラメータはDiffservのEFトラフィックをシグナリングするのに十分です。しかし、Diffservの保証転送（AF）トラフィックのために、トークン・バケット・パラメータの二組が必要とされている - 平均トラフィックのための1つのバースト・トラフィックのための1つ。 [RFC2697]は3つのトラフィックパラメータ、認定情報速度（CIR）、認定バーストサイズ（CBS）、及び超過バーストサイズに応じて（EBS）のシングルレート3カラーマーカー（srTCM）、メートルトラフィックストリームを定義し、そのパケットをマーク、緑色、黄色、または赤色のいずれかであることができます。それはCBSを超えていない場合、パケットは緑色にマーキングされます。黄色はEBS CBSを超えますが、しない場合、と赤そう。 [RFC2697]は同じ速度で動作2つのトークンバケットを使用して特定の手順を定義します。したがって、2つのTMODパラメータは、廃棄優先順位の3つのレベルを区別するのに十分です。例はまた、[RFC2597]の付録に記載されています。
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC parameters describing the desired path latency, path jitter, packet loss ratio, and path packet error ratio, respectively. Since these parameters are cumulative, an individual QNE cannot decide whether the desired path latency, etc., is available, and hence they cannot decide whether a reservation fails. Rather, when these parameters are included in <Desired QoS>, the QNI SHOULD also include corresponding parameters in a QoS Available QSPEC object in order to facilitate collecting this information.
<パス遅延>、<パスジッタ>、<パスPLR>、および<パスPER>それぞれ、所望のパス待ち時間、パスジッタ、パケット損失率、及びパスパケット誤り率を記述するQSPECパラメータです。これらのパラメータは累積的であるため、個々のQNEは、所望の経路の待ち時間、等が利用可能であるかどうかを決定することができない、したがって彼らは、予約が失敗したかどうかを決定することができません。これらのパラメータは、<望ましいQoS>に含まれている場合むしろ、QNIも、この情報の収集を容易にするために利用可能なQoS QSPECオブジェクトに対応するパラメータを含むべきです。
The <Path Latency> parameter accumulates the latency of the packet forwarding process associated with each QNE, where the latency is defined to be the mean packet delay, measured in microseconds, added by each QNE. This delay results from the combination of link propagation delay, packet processing, and queuing. Each QNE MUST add the propagation delay of its outgoing link, if this link exists.
<パス遅延>パラメータは待ち時間が各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は、入口リンクの伝搬遅延を追加する必要があります。 1最大値に - <パス遅延>パラメータの複合ルールは（2 ^ 32）のクランプとの合計です。エンド・ツー・エンドを構成する場合、この量は、QNR QNIから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].
<パスジッタ>パラメータは、ジッタは、各QNEによって追加マイクロ秒で測定された公称ジッタ、と定義される各QNE、関連付けられたパケット転送処理のジッタを蓄積します。 IPパケットジッタ、または遅延変動、[RFC3393]で定義され、セクション3.4（タイプP-ワンウェイIPDV）、そしてここで、[RFC3393]の選択関数は分布と等価であるような最小の遅延でパケットを含みます[Y.1540]の2点遅延変動。提案評価間隔は1分です。このジッタは、パケット処理の制限の結果、および存在し得る任意の変数キューイング遅延を含みます。このリンクが存在する場合、各QNEは、その発信リンクのジッタを追加しなければなりません。このリンクが存在する場合はさらに、QNIは、進入リンクのジッタを追加する必要があります。 <パスジッタ>パラメータの合成方法は、最大値にクランプ付き遅延変動分布を記述するいくつかの統計を組み合わせたものである（公称QNEジッタの蓄積および推定の方法は、[Yの項8に指定されていることに注意してください1541]）。エンド・ツー・エンドを構成する場合、この量は、QNR QNIから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.
<パスPLR>パラメータは、送信されたIPパケットを合計総失われたIPパケットの無単位比です。 <パスPLR>はPLR各QNEによって追加PLRであると定義されている各QNE、関連付けられたパケット転送処理のパケット損失率（PLR）を蓄積します。このリンクが存在する場合、各QNEは、その発信リンクのPLRを加えなければなりません。このリンクが存在する場合はさらに、QNIは、進入リンクのPLRを加えなければなりません。 <パスPLR>パラメータの複合ルールは、最大値にクランプ付き合計です。 、エンド・ツー・エンドを構成する場合、この量は、（QNRに通知する（但し、より正確な組成の機能は[Y. 1541]の項8に指定されている。これは、合計エラーは重要ではないことを十分に低いPLR値そのような前提）またはQNRへQNIから経路に沿って最小のパケット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。より低い解像度の価値が利用可能である場合、未使用の桁をゼロに設定しなければなりません。観測エラーが発生したパケット数が、結果の信頼に直接関係していることに注意してください。パラメータ<PERパス>は、PERがPER各QNEによって追加することと定義される各QNE、関連付けられたパケット転送処理のパケット誤り率（PER）を蓄積します。このリンクが存在する場合、各QNEは、その発信リンクのPERを加えなければなりません。このリンクが存在する場合はさらに、QNIは、進入リンクのPERを追加する必要があります。 <パス毎>パラメータの複合ルールは、最大値にクランプ付き合計です。 、エンド・ツー・エンドを構成する場合、この量は、（QNRに通知する（但し、より正確な組成の機能は[Y. 1541]の項8に指定されている。これは、合計エラーは重要ではないことを十分に低いPER値そのような前提）またはQNRへQNIから経路に沿って最小のパケットごとの応答メッセージ）で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].
スラック用語パラメータが帯域予約を用いて得られた所望の遅延と遅延の間の差であり、流れ[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>に含まれないように。このようなパラメータは、<利用可能なQoS>に含まれている場合は、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.
<先取り優先権>パラメータは、以前に許可されたフローの<守る優先>に比べて新たなフローの優先度です。フローが許可されると、先取り優先順位は無関係となります。 <ディフェンディング優先順位>パラメータは、新しいフローの先取優先順位を比較するために使用されます。任意の特定のフローのために、その先取り優先順位は常に防御優先より小さいか等しくなければなりません。 <入学優先順位>と<RPH優先順位>は緊急サービスのためのフローを区別するための基本的な方法を提供し、緊急通信サービス（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ホップ単位動作（PHB）[RFC2475]のパケットのためのリソースを確保するようなことがあります。 PHBクラスは、通常、アドミッション制御により指定された治療を確実にするために、トラフィックをマークする方法QNIを伝えるために下流QNEによって設定されていることに注意してください。しかし、QNIにより、パラメータの設定が排除されません。アプリケーションは、特定のQoSクラス、例えば、Y. 1541のQoSクラス[Y. 1541]またはdiffserv対応MPLSトラフィックエンジニアリング（DSTE）クラスタイプ[RFC3564、RFC4124]を用いてパケットのためのリソースを確保するようなことがあります。これらのパラメータは、様々なQOSMsに有用である、例えば、[RFC5976]、[RFC5977]、および他のQOSMs未だ定義される（例えば、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のコアの反対側には世代「X」で定義されたQoSサポートと世代「X」の技術で構築された無線アクセスネットワークです。そして最後に、携帯型のエンドポイントは、無線アクセスネットワークに接続されています。
We assume that the laptop is the QNI, and the handheld device is the QNR. The QNI will signal an Initiator QSPEC object to achieve the QoS desired on the path.
私たちは、ラップトップがQNIであると仮定し、ハンドヘルドデバイスはQNRです。 QNIは、経路上の所望の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は望ましいQoS、利用可能なQoSを設定し、おそらく最小のQoS QSPECはイニシエータQSPEC内のオブジェクト、および望ましいQoSに利用可能なQoSを初期化します。パス上の各QNEは、QoS利用可能なリソースを予約することができるかどうかを確認するためにイニシエータQSPECをチェックして、これらのパラメータを読み取り、解釈します。そうでない場合、QNEは、利用可能なQoSの各パラメータの値を低減し、これらの値を保有します。移入場合に最小パラメータ値は、最低限QoSに与えられています。最低QoSが含まれていない場合、彼らはゼロです。利用可能なQoSに1つまたは複数のパラメータが、最低限のQoSに対応する最小値を満たさない場合、QNEはQNIに対する応答メッセージを生成し、予約が中止されます。それ以外の場合は、QNRは予約のために利用可能なQoSとQNIへの応答を生成します。 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がイントサーブ制御されたロードサービスに類似保証し、また、それは達成することができますどのようなパスの待ち時間に興味を持っているQoSを実現したいと仮定しましょう。加えて、さらに経路ダウン正しい治療を確実にするために、QNIは<望ましいQoS>に<PHBクラス>を含みます。 QNIしたがってQSPECに含ま
QoS Desired = <TMOD> <PHB Class> QoS Available = <TMOD> <Path Latency>
QoSが希望= <TMOD> <PHBクラス>のQoS利用可能= <TMOD> <パスレイテンシ>
Since <Path Latency> and <PHB Class> are not vital parameters from the QNI's perspective, it does not raise their M flags.
<パスレイテンシ>と<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:
RESERVEメッセージは、ドメイン境界での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).
- ローカルQSPECを追加して、イニシエータQSPECをカプセル化することができますQNE（4.1節での議論を参照してください; - RSVPはこれを行いません。これは、QoS NSLPで新たに追加されました）。
- 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は、ドメインのエッジの間の中間ノードをバイパスし、それ自身のローカルRESERVEメッセージを発行するイニシエータRESERVEメッセージを処理することQNEは（[RFC5974のセクション3.3.1を「隠す」イニシエータRESERVEメッセージを見ることができるように]）。この新しいローカルRESERVEメッセージの場合、QNEはQNIとして機能し、ドメイン内QSPECはイニシエータQSPECです。同様の手順が、各新しく到着ドメイン間（フロー単位）RESERVEのための新たなイントラドメイン（凝集）RESERVEがされていない場合には、集約の予約を行う際に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ローカルRESERVEは、[RFC5974]のセクション4.5および[RFC5977]に記載の手順に従って、元のイニシエータQSPECに基づいて生成されます。 RMDドメインへの入口QNEは、ローカルQSPECで唯一のピーク帯域幅を表す同等のTMODパラメータに、元のイニシエータQSPECに含まれるTMODパラメータをマップします。例えばローカルRMD QSPECは、この場合にもQNIにより提供された<PHBクラス>を、必要とします。
Furthermore, if the node can, at the egress to the RMD domain, it updates QoS Available on behalf of the entire RMD domain. If it cannot (since the M flag is not set for <Path Latency>), it raises the parameter-specific, Not Supported N flag, warning the QNR that the final latency value in QoS Available is imprecise.
ノードができればさらに、RMDドメインへの出口で、それは全体のRMDドメインの代わりにQoSが利用可能な更新します。それは（Mフラグが<パス待ち時間>のために設定されていないため）ことができない場合は、利用可能なQoSの最後のレイテンシ値が不正確であることをQNRを警告し、パラメータ固有の、サポートされていないNフラグを発生させます。
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
予約が成功した場合、最終的にRESERVE要求がQNRに到着（それ以外の場合は、予約が失敗した時QNEはRESERVEを中止し、バックQNIにエラー応答を送信します）。 RIIは、QoSのNSLPメッセージに含まれていた場合、QNRはQSPECと肯定的な応答は、QoS予約と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:
利用可能。 QoSの予約に登場するパラメータは、利用可能なQoSからコピーされた値を使用して、望ましいQoSの場合と同様です。したがって、QNRは応答して、次のQSPECオブジェクトを含みます。
QoS Reserved = <TMOD> <PHB Class> QoS Available = <TMOD> <Path Latency>
QoSの予約= <TMOD> <PHBクラス>のQoS利用可能= <TMOD> <パスレイテンシ>
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無線ネットワークは異なるQOSMsをサポートするかもしれないので、そのQoSが経路上変更される可能性があります。その結果、QoSのNSLP / QSPEC処理は、パス上の利用可能なQoSを再交渉する必要があります。 QSPECの観点から、これはパスの新しいセクションに新たな予約のようなもので、基本的に他の再ルーティングイベントと同じである - 新しいパス上のQNEsに、それは新たな予約のように見えます。つまり、このモバイルシナリオでは、新しいセグメントが古いセグメントとは異なるQOSMをサポートしており、QNIは今XGで異なるQOSMを考慮して（次のさわやかRESERVEメッセージまたは暗黙的に）明示的に新しい予約に信号を送ります無線ドメイン。再ルーティングに関する詳細については、[RFC5974]で指定されています。
For bit-level examples of QSPECs, see the documents specifying QOSMs: [CL-QOSM], [RFC5976], and [RFC5977].
[CL-QOSM]、[RFC5976]及び[RFC5977]：QSPECsのビットレベルの例については、QOSMsを特定のドキュメントを参照。
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.
3つのフラグは、このセクションで説明されているQSPEC処理、Mフラグ、Eフラグ、及びNフラグで使用されています。 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
生成することにより、ローカルドメインと予備リソースをローカルドメインのエッジでQNE A）ローカルQSPECにイニシエータQSPECを翻訳し、RESERVEメッセージのイニシエータQSPECをカプセル化することができるいずれか、またはb）「隠す」イニシエータQSPEC新着
RESERVE message through the local domain containing the Local QSPEC. In either case, the Initiator QSPEC parameters are interpreted at the local domain edges.
ローカルQSPECを含むローカルドメインを介しRESERVEメッセージ。いずれの場合においても、イニシエータ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タイプに使用すること、例えば、示しています。下流QNEは、それが持つかもしれない様々なQOSM関連プロセス間で選択することができるようにQNIは（必ずしも一定QOSM関連パラメータを取り込むことを必要とするであろう）は、いくつかのQOSMに基づいQSPECタイプをシグナリングすることが有用であり得ます。つまり、QNIは、例えば、QSPECタイプ移入CL-QSPECタイプと「イニシエータ」にイニシエータ/ローカルQSPECビットをセットします。地元QNEは、例えば、ローカルQSPECタイプを挿入するために、どのような理由のために、決めRMD-QSPECタイプ、およびローカルQSPECタイプ= RMD-QSPECを設定し、「ローカル」にイニシエータ/ローカルQSPECビットをセット（およびカプセル化することができますRESERVEまたは何NSLPメッセージ）でイニシエータQSPEC。
+--------------------------------+\
| QSPEC Type, QSPEC Procedure | \
+--------------------------------+ / Common QSPEC Header
| Init./Local QSPEC bit=Local |/
+================================+\
| Local-QSPEC Parameter 1 | \
+--------------------------------+ \
| .... | Local-QSPEC Parameters
+--------------------------------+ /
| Local-QSPEC Parameter n | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC Type, QSPEC Procedure| |
| +----------------------------+ |
| | Init./Local QSPEC bit=Init.| |
| +============================+ |
| | | | Encapsulated Initiator QSPEC
| | .... | |
| +----------------------------+ |
+--------------------------------+
Figure 3: Defining a Local QSPEC
図3：ローカルQSPECの定義
Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. Thus, the type of the QSPEC may change within a local domain. Hence:
ここでのQoS-NSLPはRMFまで1 QSPECを見て渡します。このように、QSPECの種類は、ローカルドメイン内の変更されることがあります。したがって：
o the QNI signals its QoS requirements with the Initiator QSPEC,
QNIがイニシエータQSPECとのQoS要件を信号O、
o the ingress edge QNE in the local domain translates the Initiator QSPEC parameters to equivalent parameters in the local QSPEC,
Oローカルドメイン内入口エッジQNEは、ローカルQSPEC等価パラメータにイニシエータQSPECパラメータを変換します
o the QNEs in the local domain only interpret the Local QSPEC parameters, and
ローカルドメインのQNEs oを唯一のローカルQSPECパラメータを解釈し、
o the egress QNE in the local domain processes the Local QSPEC and also interprets the QSPEC parameters in the Initiator QSPEC.
ローカルドメイン内の出口QNE oをローカル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.
ローカルQSPECsのサポートは、イニシエータとローカルQSPECsが使用される場所を示すために単一のフローについては、図4に示されています。 QNIはY. 1541 QOSM開始剤QSPECを含むエンドツーエンドの、ドメイン間のQoS NSLPのRESERVEメッセージを開始します。図4に示すように、RESERVEメッセージは異なるQOSMsをサポートする複数のドメインを横切ります。この図では、イニシエータQSPECは、ローカルQOSMドメインの入口ノードでのQoS NSLP RESERVEメッセージに到着します。ローカル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セットは、<パスの遅延時間>、<パスジッタ>、および<パスPER>パラメータのための目標を含めるために、<最小のQoS> <望ましいQoS>、および<利用可能なQoS>オブジェクトを。 QNE /ローカルドメインは、<利用可能なQoS>オブジェクト（しかし<最低限のQoS>で指定されたより小さくない）で達成することができ、累積パラメータ、例えば、<パス遅延>を設定します。 <利用可能なQoSが> <最小のQoS>目的の一つ以上を満たすために失敗した場合、QNE /ローカルドメインはQNIを通知し、予約が中止されます。 Mがゼロに設定ビットが任意QNEはQSPECパラメータをサポートするために、イニシエータQSPECによって指定要件を満たすことができない場合、QNEは、一つのそのパラメータのNフラグをセットします。それ以外の場合は、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動作例
4.2. Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC Notification
4.2. 予約成功/失敗、QSPECエラーコード、およびINFO-SPEC通知
A reservation may not be successful for several reasons:
予約はいくつかの理由で成功しない場合があります。
- a reservation may fail because the desired resources are not available. This is a reservation failure condition.
- 目的のリソースが使用できないため、予約が失敗することがあります。これは、予約失敗状態です。
- a reservation may fail because the QSPEC is erroneous or because of a QNE fault. This is an error condition.
- QSPECが誤っているか、理由はQNEの障害のため、予約が失敗することがあります。これはエラー状態です。
A reservation may be successful even though some parameters could not be interpreted or updated properly:
いくつかのパラメータを解釈または適切に更新することができなかったにもかかわらず、予約が成功することがあります。
- a QSPEC parameter cannot be interpreted because it is an unknown QSPEC parameter type. This is a QSPEC parameter not supported condition. However, the reservation does not fail. The QNI can still decide whether to keep or tear down the reservation depending on the procedures specified by the QNI's QOSM.
- それは未知QSPECパラメータタイプであるためQSPECパラメータは解釈できません。これは、条件をサポートしていないQSPECパラメータです。ただし、予約は失敗しません。 QNIはまだQNIのQOSMによって指定された手順に応じて、予約を維持するか、取り壊すするかどうかを決定することができます。
The following sections provide details on the handling of unsuccessful reservations and reservations where some parameters could not be met, as follows:
次のように次のセクションでは、いくつかのパラメータを満たすことができなかった失敗した予約や予約の取り扱いに関する詳細を提供します。
- details on flags used inside the QSPEC to convey information on success or failure of individual parameters. The formats and semantics of all flags are given in Section 5.
- QSPEC内で使用されるフラグの詳細については、個々のパラメータの成功または失敗についての情報を伝えるために。すべてのフラグの形式と意味論はセクション5に記載されています。
- the content of the INFO-SPEC [RFC5974], which carries a code indicating the outcome of reservations.
- 予約の結果を示すコードを運ぶINFO-SPEC [RFC5974]の内容。
- the generation of a RESPONSE message to the QNI containing both QSPEC and INFO-SPEC objects.
- QSPECとINFO-SPECオブジェクトの両方を含む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汎用フラグBREAK（B）が設定されていることに留意されたいです。 BREAKフラグは[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にINFO-SPECに対応するエラーコードによって決定することができます。
Each QSPEC parameter has an associated 'Not Supported N flag'. If the Not Supported N flag is set, then at least one QNE along the data transmission path between the QNI and QNR cannot interpret the specified QSPEC parameter. A QNE MUST set the Not Supported N flag if it cannot interpret the QSPEC parameter. If the M flag for the parameter is not set, the message should continue to be forwarded but with the N flag set, and the QNI has the option of tearing down the reservation.
各QSPECパラメータは、関連する「サポートされていないNフラグ」を有します。サポートされていないNフラグが設定されている場合、QNIとQNR間のデータ伝送経路に沿って少なくとも1つのQNEは、指定されたQSPECパラメータを解釈できません。それはQSPECパラメータを解釈できない場合QNEはサポートされていない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]で規定されるように、応答メッセージは常に適切な「エラー」コードとINFO-SPECを含有します。 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に設けられたコードに基づいて、INFO-SPECにエラーコードを設定するために設けられています。
- NSLP error class 2 (Success) / 0x01 (Reservation Success): This code is set when all QSPEC parameters have been satisfied. In this case, no E Flag is set; however, one or more N flags may be set.
- NSLPのエラークラス2（成功）/ 0x01の（予約成功）：すべてのQSPECパラメータが満たされたときに、このコードが設定されています。この場合、Eフラグがセットされていません。しかしながら、一つ以上のNフラグが設定されてもよいです。
- NSLP error class 4 (Transient Failure) / 0x07 (Reservation Failure): This code is set when at least one QSPEC parameter could not be satisfied, or when a QSPEC parameter with M flag set could not be interpreted. E flags are set for the parameters that could not be satisfied at each QNE up to the QNE issuing the RESPONSE message. The N flag is set for those parameters that could not be interpreted by at least one QNE. In this case, QNEs receiving the RESPONSE message MUST remove the corresponding reservation.
- NSLPエラークラス4（一時的な障害）/ 0x07の（予約失敗）：少なくとも一つQSPECパラメータを満たすことができなかった場合、又はMフラグが設定されたQSPECパラメータを解釈することができなかった場合、このコードが設定されています。 Eフラグは、応答メッセージを発行するQNEまでの各QNEで満足することができなかったパラメータに設定されています。 Nフラグが少なくとも一つの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").
RESERVEメッセージがQNRに到着し、何のEフラグが設定されていない場合は、予約が成功しています。上記及び4.3節（「QSPEC手順」）に記載されているように応答メッセージがINFO-SPECコード「予約成功」で生成されてもよいです。
- Reservation Failure Condition
- 予約の障害状態
When a QNE detects that a reservation failure occurs for at least one parameter, the QNE sets the E Flags for the QSPEC parameters and QSPEC object that failed to be satisfied. According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines the reservation failed, it formulates a RESPONSE message that includes an INFO-SPEC with the 'reservation failure' error code and QSPEC object. The QSPEC in the RESPONSE message includes the failed QSPEC parameters marked with the E Flag to clearly identify them.
QNEは、予約失敗は、少なくとも一つのパラメータのために発生したことを検出した場合、QNEを満たすことに失敗したQSPECパラメータとQSPECオブジェクトのEフラグを設定します。 [RFC5974]によると、QNEの行動は、それがステートフルであるかどうかに依存します。ステートフルQNE予約が失敗した判断した場合、それは予約失敗」エラーコードとQSPECオブジェクトにINFO-SPECを含む応答メッセージを定式化します。応答メッセージにQSPECは明らかにそれらを識別するために、Eフラグが付け失敗QSPECパラメータを含んでいます。
The default action for a stateless QoS NSLP QNE that detects a reservation failure condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE then formulates the RESPONSE message as described above.
予約失敗状態を検出ステートレスなQoS NSLPのQNEのデフォルトアクションは、それが適切に各QSPECパラメータの設定Eフラグと、次のステートフルQNEにRESERVEメッセージを転送し続けなければならないということです。上述したように、次のステートフル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は、INFO-SPECにエラーコード「奇形QSPEC」を設定します。この場合、適切に誤パラメータのセットEフラグとQSPECオブジェクトは、INFO-SPECオブジェクト内に戻されます。 QSPECオブジェクトが切り捨てられたか、完全にINFO-SPEC内に含めることができます。
According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines a malformed QSPEC error condition, it formulates a RESPONSE message that includes an INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.
[RFC5974]によると、QNEの行動は、それがステートフルであるかどうかに依存します。ステートフルQNEが不正QSPECエラー状態を判断した場合、それは不正な形式QSPEC 'エラーコードとQSPECオブジェクトとINFO-SPECを含む応答メッセージを定式化します。
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.
RESPONSEメッセージ内QSPECのみ誤っQSPECパラメータなし他、可能であれば、含まれています。誤っQSPECパラメータ（複数可）、明らかにそれらを識別するために、Eフラグが付いています。 QSPECパラメータはEフラグでマークされていないINFO-SPECに返された場合、これらのパラメータの任意の値は無関係であると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にRESERVEメッセージを転送し続けなければならないということです。 [RFC5974]に記載されているように、次のステートフルQNEは、次に作用します。
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.
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.
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はRESERVEメッセージ中RII（要求識別情報）が含まれている場合にのみ生成され、否定応答メッセージは常にエラーまたは障害が発生した場合に生成されます。以下QSPEC手順のいくつかは、しかし、応答メッセージが可能である場合にのみ意味があります。これらのケースでQNI SHOULDは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:
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はRESERVEメッセージに含まれている場合、暗黙の仮定は正確にこれらのリソースを予約しなければならないということです。これが不可能な場合は、予約は失敗します。 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はRESERVEメッセージに含まれている場合にも、いくつかのパラメータが唯一の希望の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と同様とすることができます。これらのパラメータのために、暗黙のメッセージは、QNIが所望のQoSに指定されたよりも低いパラメータ値で予約することによって満足されることです。これらのパラメータについては、望ましいQoSのものとのQoSのパラメータ値が利用可能QNI種子（のような累積パラメータを除き、<パスレイテンシ>）。
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のRESERVEDオブジェクトから）で、すぐに適切なサイズのさわやかRESERVEを発行することができるものを学習します。アプローチの利点は、予約が半-往復時間で行われることです。
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).
QSPECパラメータIDと値RESPONSEメッセージ内のQoS予約オブジェクトに含まれるRESERVEメッセージにオブジェクト望ましいQoSと同じでなければなりません。また、RESERVEメッセージ内のQoS利用可能オブジェクトに含まれていたものQSPECパラメータについて、その値は（応答して）オブジェクトを確保されたQoSへのQoS（RESERVEで）使用可能なオブジェクトからコピーされます。他の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の所望のオブジェクトにコピーされたかどうかの）RESERVEメッセージ内のQoS利用可能オブジェクトから値を用いてコピーされます。彼らは応答メッセージに上書きすることができないのに対し、QoSの利用可能なオブジェクトのパラメータは、RESERVEメッセージで上書きされることに注意してください。
In this case, the QNI SHOULD request a RESPONSE message since it will otherwise not learn what QoS is available.
それはそうQoSが使用可能なものを学びませんので、この場合は、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.
利用可能なQoSが1つのパラメータの最小のQoS未満になると、予約が失敗したことを除いて、このケースは、ケース2として扱われます。パラメータは、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によってRESERVEメッセージに含まれているすべての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:
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
Table 2: Message Sequence 1: Three-Way Transactions Defining Object Combinations 0, 1, and 2
表2：メッセージシーケンス1：オブジェクトの組み合わせ0、1、および2を定義する3ウェイ取引
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オブジェクトを含む受信機にQUERYメッセージを送信します。 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オブジェクトを含む）交渉であることを合図場合RESERVEメッセージは、QoS利用可能オブジェクトを含みます。最低限のQoSオブジェクトがクエリメッセージに含まれる送信者から受信した場合、QNIもRESERVEメッセージに最低限の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にRESPONSEメッセージは省略可能である（内部QSPECであるように）。ケース2では、しかし、応答メッセージがQNIが利用可能なQoSについて学ぶために必要です。
Case 3:
ケース3：
This is the 'RSVP-style' scenario. The sender (QNR in this scenario) issues a QUERY message with a QoS Desired object informing the receiver (QNI in this scenario) about the QoS it desires, as above. It also includes a QoS Available object to collect path properties. Note that here path properties are collected with the QUERY message, whereas in the previous case, 2 path properties were collected in the RESERVE message.
これは、「RSVP-スタイル」シナリオです。送信者（このシナリオでQNR）は上記のように、それは希望のQoSについて（このシナリオでQNI）受信機に通知オブジェクトを望ましいQoSとQUERYメッセージを発行します。また、パスのプロパティを収集するためのQoS利用可能なオブジェクトが含まれています。前のケースで、2つのパスの特性はRESERVEメッセージに収集されたのに対し、ここでパス特性は、QUERYメッセージで収集されることに留意されたいです。
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の所望のオブジェクトをシグナル：QUERYメッセージにオブジェクトを望ましいQoS利用可能オブジェクトおよびQoSの両方に表示されるそれらのパラメータについては、それが利用可能なQoSから（おそらく再マッピング）QSPECパラメータ値をとりオブジェクト。唯一のQoS目的のオブジェクトに表示され、それらのパラメータの場合、それは、QoS目的のオブジェクトからパラメータ値を採用しています。
The parameters in the QoS Available QSPEC object in the RESERVE message are copied with their values from the QoS Available QSPEC object in the QUERY message. Note that the parameters in the QoS Available object can be overwritten in the QUERY message, whereas they cannot be overwritten in the RESERVE message.
RESERVEメッセージ内のQoS利用可能QSPECオブジェクトのパラメータは、QoS QUERYメッセージで利用可能QSPECオブジェクトから値をコピーされます。彼らはRESERVEメッセージで上書きすることができないのに対し、QoSの利用可能なオブジェクトのパラメータは、QUERYメッセージに上書きされることに注意してください。
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におけるオーバー予約の状況が（上記のように）が生じないことです。一方、QUERYメッセージは、例えば、特定の帯域幅が利用可能でない、見つけることができます。実際の予約が行われた場合、しかし、所望の帯域幅は、一方で自由になっている可能性があります。つまり、必要以上に小さい予約をもたらすことができる「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.
送信者は、それがQUERYメッセージに気にすべてのQSPECパラメータを含んでいます。 QUERYメッセージは受信機に向かって移動するように上書きすることができるパラメータはQNEsによって更新されます。受信機は、受信機に到着したときに、彼らが持っていた値で、RESERVEメッセージでも、QUERYメッセージに到着するすべての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.
それはそうQoSが使用可能なものを学びませんので、また、このシナリオでは、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によってRESERVEメッセージに含まれているすべての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.
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
Note that the QoS Available object when traveling in the QUERY message can be overwritten, whereas in the RESPONSE message it cannot be overwritten.
応答メッセージに、それを上書きすることができないのに対し、利用可能なオブジェクトQUERYメッセージ内を移動する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によってRESERVEメッセージに含まれているすべての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.
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.
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].
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パラメータのための新しいコードポイントの割り当ての要求を評価する際に従うべき技術的基準に関するガイドラインはセクション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.
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].
[RFC4506]、[IEEE754]、および[NETWORK-OCTET-ORDER]で指定されるように、すべての16ビットおよび32ビットの整数、ならびに32ビット浮動小数点数のネットワークオクテットの順序が（ 'ビッグ・エンディアン'）、あります。
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:
o The overall format is Type-Length-Value (in that order).
O全体的なフォーマットは、タイプレングス値（この順序で）です。
o Some parts of the type field are set aside for control flags.
O型フィールドのいくつかの部分は、制御フラグのために確保されています。
o Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. The Object length excludes the header.
O Lengthは、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空QSPECsと空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
Length: The total length of the QSPEC (in 32-bit words) excluding the common header
長さ（32ビット・ワードで）QSPECの全長共通ヘッダを除きます
The QSPEC Objects field is a collection of QSPEC objects (QoS Desired, QoS Available, etc.), which share a common format and each contain several parameters.
QSPECオブジェクトフィールドには、共通フォーマットを共有し、それぞれがいくつかのパラメータが含まれているQSPECオブジェクト（望ましいQoS、利用可能なQoSなど）のコレクションです。
QSPEC objects share a common header format:
QSPECオブジェクトは、共通ヘッダフォーマットを共有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
オブジェクト・タイプ= 0：望ましいQoS（パラメータが上書きできない）= 1：利用可能なQoSは、（パラメータが上書きされる可能性があり、3.2節を参照のこと）= 2：QoSの予約（パラメータが上書きできない）= 3：最低限のQoS（パラメータが上書きできません）
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フラグ：セットは、QSPECパラメータが満たされていないいずれかのa）は予約の失敗を示し、またはこのパラメータは解釈された場合b）は、エラーが発生した場合（）セクション4.2.1を参照。
N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2).
Nフラグ：QSPECパラメータフラグをサポートされていない（4.2.2項を参照してください）。
Parameter ID: Assigned consecutively to each QSPEC parameter. Parameter IDs are assigned to each QSPEC parameter defined in this document in Sections 5.2 and 7 (IANA Considerations).
パラメータID：各QSPECパラメータに連続して割り当てられました。パラメータIDは、セクション5.2および7（IANAの考慮事項）この文書で定義されている各QSPECパラメータに割り当てられています。
Parameters are usually coded individually, for example, the <Excess Treatment> parameter (Section 5.2.11). However, it is also possible to combine several sub-parameters into one parameter field, which is called 'container coding'. This coding is useful if either a) the sub-parameters always occur together (as for example the 5 sub-parameters that jointly make up the TMOD), or b) in order to make coding more efficient when the length of each sub-parameter value is much less than a 32-bit word (as for example described in [RFC5977]) and to avoid header overload. When a container is defined, the Parameter ID and the M, E, and N flags refer to the container. Examples of container parameters are <TMOD> (specified below) and the PHR (Per Hop Reservation) container parameter specified in [RFC5977].
パラメータは、通常、個別に符号化される、例えば、<過剰処理>パラメータ（セクション5.2.11）。しかし、コンテナコーディング」と呼ばれる一つのパラメータフィールドにいくつかのサブパラメータを組み合わせることも可能です。この符号化は、各サブパラメータの長さ符号化をより効率的にするために、a）のサブパラメータは常に共同TMODを構成する（例えば、5サブパラメータ）を一緒に起こるのいずれか場合に有用である、またはb）値は、32ビットのワードよりもはるかに小さい（例えば、[RFC5977]に記載されているように）、ヘッダのオーバーロードを回避します。コンテナが定義されている場合、パラメータIDとM、E、およびNフラグが容器を指します。コンテナ・パラメータの例は、<TMOD>（以下に指定）および[RFC5977]で指定されたPHR（パーホップ予約）コンテナパラメータです。
The references in the following sections point to the normative procedures for processing the QSPEC parameters and sub-parameters.
以下のセクションの参照はQSPECパラメータとサブパラメータを処理するための規範的な手順を指します。
The <TMOD-1> parameter consists of the <r>, <b>, <p>, <m>, and <MPS> sub-parameters [RFC2212], which all must be populated in the <TMOD-1> parameter. Note that a second TMOD QSPEC parameter <TMOD-2> is specified below in Section 5.2.2.
<TMOD-1>パラメータ<R>、<B>、<P>、<M>で構成されており、すべてが<TMOD-1>パラメータに移入されなければならない<MPS>サブパラメータ[RFC2212]、 。第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>パラメータは[IEEE754]ネットワークオクテット順に2つの32ビット整数に続く単精度IEEE浮動小数点形式の3つの浮動小数点数で表されます。第1の浮動小数点値は、レート（R）であり、第二の浮動小数点値はバケットサイズ（B）は、第三の浮動小数点は、ピークレート（P）であり、最初の符号なし整数は、最小ポリシング単位（M）であります第二の符号なし整数は、最大パケットサイズ（MPS）です。 Rおよびpの値は、秒あたりのオクテットで測定されます。 B、M、及びMPSは、オクテット単位で測定されます。 R、B、およびP用語はIEEE浮動小数点値として表現される場合、符号ビットは、（すべての値は非負でなければなりません）ゼロでなければなりません。指数未満127（即ち、0）禁止されています。 162（即ち、正35）より大きい指数は無限のピーク速度を指定する以外は、推奨されています。無限大は、すべてのもの（255）の指数、及び全ゼロの符号ビットと仮数で表現されます。
A second QSPEC <TMOD-2> parameter is specified as could be needed, for example, to support some Diffserv applications.
第QSPEC <TMOD-2>パラメータ、例えば、必要とされる可能性があるので、いくつかのDiffservのアプリケーションをサポートするために、指定されています。
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>パラメータは[IEEE754]ネットワークオクテット順に2つの32ビット整数に続く単精度IEEE浮動小数点形式の3つの浮動小数点数で表されます。第1の浮動小数点値は、レート（R）であり、第二の浮動小数点値はバケットサイズ（B）は、第三の浮動小数点は、ピークレート（P）であり、最初の符号なし整数は、最小ポリシング単位（M）であります第二の符号なし整数は、最大パケットサイズ（MPS）です。 Rおよびpの値は、秒あたりのオクテットで測定されます。 B、M、及びMPSは、オクテット単位で測定されます。 R、B、およびP用語はIEEE浮動小数点値として表現される場合、符号ビットは、（すべての値は非負でなければなりません）ゼロでなければなりません。指数未満127（即ち、0）禁止されています。 162（即ち、正35）より大きい指数は無限のピーク速度を指定する以外は、推奨されています。無限大は、すべてのもの（255）の指数、及び全ゼロの符号ビットと仮数で表現されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]ネットワークオクテット順に1つの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.
1最大値に - <パス遅延>パラメータの複合ルールは（2 ^ 32）のクランプとの合計です。待ち時間は、1マイクロ秒の単位で報告された平均値です。以下、1マイクロ秒未満の分解能を有するシステムがゼロに未使用の数字を設定しなければなりません。個々QNEは1 ^ 28 2（やや上2分）の間の待ち時間の値を追加することができ、そして全てQNEs横切っ添加総待ち時間は、（2 ^ 32）-2ほど高い範囲とすることができます。異なる要素の遅延の合計が（2 ^ 32）を超えた場合-2、エンド・ツー・エンドの累積遅延は、（2 ^ 32）=不定-1として報告されるべきです。正確にそれが処理しているパケットの遅延を予測することはできませんQNEはサポートされていないNフラッグを上げ、のいずれかであるように、パスのレイテンシの値を残すか、その下限の最善の見積りを加えなければなりません。上がっていない、サポートされているフラグは、Pathレイテンシの値が実際のパス遅延時間の下限であることを示します。組成関数がこの値になる合計を制限するので識別値（2 ^ 32）-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| 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遅延変動」と呼ばれています。各値の最大値に1 - パスジッタパラメータは、ジッタ（2 ^ 32）のクランプを持つ分布を記述する統計4の組み合わせです。ジッタの統計は、1マイクロ秒の単位で報告されています。以下、1マイクロ秒未満の分解能を有するシステムがゼロに未使用の数字を設定しなければなりません。個々QNEは1 ^ 28 2（やや上2分）の間にジッタ値を追加することができ、そして全てQNEs横切っ計算トータルジッタは（2 ^ 32）-2ほど高い範囲とすることができます。異なる要素値の組み合わせは、（2 ^ 32）-2を超えた場合、エンドツーエンドの累積ジッタは、不確定として報告されるべきです。正確にそれが処理しているパケットのジッタを予測することはできませんQNEは、サポートされていないフラグを立てると、どちらかであるように、パスジッタの値を残す、またはそのSTAT値の最善の見積りを加えなければなりません。上げ、サポートされていないフラグはパスジッタの値が実際のパスジッタの下限であることを示します。識別値は、（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]).
注：ジッタ合成機能は、<パスレイテンシ>パラメータを使用しています。ロス、遅延、およびジッタのための組成物の機能は、[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.
パスPLRは、ネットワークオクテットオーダー[Y. 1541]における単一の32ビットIEEE単精度浮動小数点数です。 [Y.1540]で定義されるように、パスPLRは、送信されたIPパケットの合計に対する総失われたIPパケットの比です。 1分間の評価区間が観察損失の数を直接結果の信頼性に関連している[Y. 1541]で提案されています。 <パスPLR>パラメータの複合ルールは、最大値に10 ^ -1のクランプ付き合計です。 PLRsは10 ^ -11の単位で報告されています。 10未満の分解能を有するシステムは^ -11ゼロに未使用の数字を設定しなければなりません。個々QNEは、総経路PLR値の良否が全てQNEs横切って加えここで、（10 ^ -1の最大まで）総経路PLR値に（10 ^ -2の最大まで）そのローカルPLR値を加算し使用されているQOSMに基づいて決定されます。蓄積されたエンドツーエンドパスのPLR値に10 ^ -2 QNEのローカルPLR値と上限（クランプ値）に10 ^ -1の上限は、単純な添加蓄積機能の精度を維持するために使用されています指定された、より複雑な蓄積機能を避けるために。これらの最大値を超えた場合さらに、その後、パスは可能性が高いQoSの目標を満たしていないでしょう。異なる要素の値の合計が10 ^ -1を超える場合には、エンドツーエンドの累積PLRは不定として報告されるべきです。正確にそれが処理しているパケットのPLRを予測することはできませんQNEは、サポートされていないフラグを立てると、どちらかであるように、パスのPLRの値を残すか、その下限の最善の見積りを加えなければなりません。上げ、サポートされていないフラグはパス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.
パス毎に、ネットワークオクテットオーダー[Y. 1541]における単一の32ビットの単精度IEEE浮動小数点数です。 [Y.1540]で定義されるように、パス毎に観察エラーの発生したパケットの数を直接結果の信頼性に関連した成功したIPパケットに加えてエラーの発生したIPパケットの総数、総エラー状態のIPパケットの比です。 <パス毎>パラメータの複合ルールは、最大値に10 ^ -1のクランプ付き合計です。 PERが10 ^ -11の単位で報告されています。 10未満の分解能を有するシステムは^ -11ゼロに未使用の数字を設定しなければなりません。個々QNE値PER総経路の良否が全てQNEs横切って加え（10 ^ -1の最大値まで）値PER総経路に（10 ^ -2の最大まで）そのローカルPER値を加算し使用されているQOSMに基づいて決定されます。値PER累積エンドツーエンドパス上の10 ^ -2 QNEのローカルPER値と上限（クランプ値）に10 ^ -1の上限は、単純な添加蓄積機能の精度を維持するために使用されています指定された、より複雑な蓄積機能を避けるために。これらの最大値を超えた場合さらに、その後、パスは可能性が高いQoSの目標を満たしていないでしょう。異なる要素の値の合計が10 ^ -1を超える場合には、エンドツーエンドの累積PERは不定として報告されるべきです。正確にそれが処理しているパケットのPERを予測することはできませんQNEはサポートされていないNフラッグを上げ、のいずれかであるように、パスPERの値を残すか、その下限の最善の見積りを加えなければなりません。調達サポートされていないNフラグはパスPERの値が実際のパスPERの下限であることを示します。区別値10 ^ -1不定のPERを意味すると解釈されます。正確にそれが処理しているパケットのPERは、この値にパラメータごとにそのローカルパスを設定すべきである予測できない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.
スラック項Sが非負でなければならなくて、マイクロ[RFC2212]で測定されます。スラックという用語は、Sは、32ビットの符号なし整数として表現されます。その値は、0から（2 ^ 32）-1マイクロ秒の範囲とすることができます。
The coding for the <Preemption Priority> and <Defending Priority> sub-parameters is as follows [RFC3181]:
[RFC3181]を次のように<先取り優先権>のための符号化及び<防衛優先>サブパラメータは次のとおり
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]で指定されるように、<先取り優先権>と<防衛優先度> 16ビットの整数値であり、パラメータが使用される場合の両方が取り込まれなければなりません。
The coding for the <Admission Priority> parameter is as follows:
次のように<入場優先順位>パラメータのコーディングは次のとおりです。
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つのフィールドは、<入場優先順位>パラメータのために提供されており、以下のルールに従って取り込まれます。
<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がイニシエータQSPECと一致していなければならない（セクション4.1で指定）ローカル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.
[EMERGENCY-RSVP]に応じQNIの信号の入場優先する場合は、<Y.2171入場優先順位>フィールド内のすべてのものを<入場優先順位>フィールドと場所で、ローカルで有効な値を移入します。この場合、<入場優先順位>値の機能的意義は、ローカルネットワーク管理者によって指定されます。より高い値は高い優先度を示しています。下流QNEsとRSVPノードは、ローカルネットワーク管理者が指定した地域のルールに従って<入場優先順位>の値がリセットされる場合がありますが、<Y.2171入場優先>フィールドの値をリセットしてはいけません。
A reservation without an <Y.2171 Admission Priority> parameter MUST be treated as a reservation with an <Y.2171 Admission Priority> = 1.
<Y.2171アドミッション優先>なしの予約パラメータは、<Y.2171アドミッション優先度> = 1で予約として扱わなければなりません。
The coding for the <RPH Priority> parameter is as follows:
次のように<RPH優先順位>パラメータのコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC4412] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority", and if populated is applicable only to flows with high admission priority. A registry is created in [RFC4412] and extended in [EMERG-RSVP] for IANA to assign the RPH priority parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces and "Priority Numerical Values" are assigned to the RPH Priority.
[RFC4412]はパラメータ「RPH名前空間」および「RPH優先」のリソース優先順位ヘッダ（RPH）を定義し、そして移入場合にのみ高い受付優先度フローに適用可能です。レジストリは、[RFC4412]で作成され、IANAはRPH優先度パラメータを割り当てるための[EMERG-RSVP]に拡張されます。拡張されたレジストリでは、「名前空間数値値」RPH名前空間にIANAによって割り当てられ、「優先順位の数値は」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.
<入場優先順位>パラメータがサポートさQOSMに依存<RPHプライオリティ>パラメータと組み合わせて使用することができることに注意してください。複数RPH名前空間はQOSMによってサポートされている場合さらに、その後QOSMは異なるRPH名前空間に属する優先度との間のマッピングが互いにマッピングされる方法を指定しなければなりません。
Note also that additional work is needed to communicate these flow priority values to bearer-level network elements [VERTICAL-INTERFACE].
メモはまた、追加の作業は、ネットワーク要素[VERTICAL-INTERFACE]レベルベアラにこれらのフローの優先度値を通信するために必要とされます。
For the 4 priority parameters, the following cases are permissible (procedures specified in references):
4つの優先パラメータについては、次のような場合は、許容（参考文献中に指定された手順）です。
1 parameter: <Admission Priority> [Y.2171] 2 parameters: <Admission Priority>, <RPH Priority> [RFC4412] 2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181] 3 parameters: <Preemption Priority>, <Defending Priority>, <Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3] 4 parameters: <Preemption Priority>, <Defending Priority>, <Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2, 3GPP-3]
1パラメータ<入場優先> [Y.2171] 2つのパラメータ<アドミッション優先度>、<RPH優先> [RFC4412] 2つのパラメータ<先取り優先権>、<守る優先> [RFC3181] 3つのパラメータ：<先取り優先権> <守る優先>、<入場優先> [3GPP-1、3GPP-2、3GPP-3] 4つのパラメータ<先取り優先権>、<守る優先度>、<アドミッション優先度>、<RPH優先> [3GPP-1、3GPP -2、3GPP-3]
It is permissible to have <Admission Priority> without <RPH Priority>, but not permissible to have <RPH Priority> without <Admission Priority>. (Alternatively, <RPH Priority> is ignored in instances without <Admission Priority>.)
<RPH優先>なし<入場優先順位を>持っていることは許さますが、<入場優先順位>なし<RPH優先順位>を持つことは許されません。 （また、<RPHプライオリティ> <入場優先順位>なしの場合には無視されます。）
Functionality similar to enhanced Multi-Level Precedence and Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) specifies use of <Admission Priority> corresponding to the 'queuing allowed' part of eMLPP, as well as <Preemption/Defending Priority> corresponding to the 'preemption capable' and 'may be preempted' parts of eMLPP.
拡張マルチレベル優先順位および優先処理サービスと同様の機能（eMLPP [3GPP-1、3GPP-2]で定義されるように）<入場優先>の使用を指定eMLPPの「キューイング許可」部分、ならびに<プリエンプションに対応/「ができるプリエンプション」に対応し、eMLPPの一部を「先行され得る、」>優先順位を守ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
過剰治療は：それは、<TMOD>パラメータでカバーされていないトラフィックで、QNEはプロファイル外のトラフィックを処理する方法を示します。過剰治療パラメータは、QNIによって設定されます。次のように使用できる値は以下のとおりです。
0: drop 1: shape 2: re-mark 3: no metering or policing is permitted
0：ドロップ1：形状2：再マーク3：NO計量またはポリシングが許可されていません
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フラグがパラメータに設定され、予約が失敗しています。過剰治療が「形状」二つ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のコードポイント（DSCP）値）に関係する再マークすることができます。後者の場合には、再マーキングは、パケットが特定のQoSクラス/ DSCPに属するものとしてマークされて到着し、それらは過剰として識別される場合、それらはその後、異なるQoSクラス（DSCP値に再マークされなければならないのDiffservモデルに関する次のように）、「再マーク値」で示さ。
Re-mark Value (6 bits): indicates DSCP value [RFC2474] to re-mark packets to when identified as excess
再マーク値（6ビット）：[RFC2474] DSCP値を示して再マークパケットに過剰として同定する際に
If 'no metering or policing is permitted' is signaled, the QNE should accept the Excess Treatment Parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, and should be used with caution.
「は計量またはポリシングが許可されていない」が通知された場合は過剰なトラフィックが問題を起こさないように、QNEは特別な注意を払って、送信者によって設定された過剰治療パラメータを受け入れる必要があります。ヌルメーター[RFC3290]を要求することは、特に強く、注意して使用すべきです。
A NULL metering application [RFC2997] would not include the traffic profile, and conceptually it should be possible to support this with the QSPEC. A QSPEC without a traffic profile is not excluded by the current specification. However, note that the traffic profile is important even in those cases when the excess treatment is not specified, e.g., in negotiating bandwidth for the best-effort aggregate. However, a "NULL Service QOSM" would need to be specified where the desired QNE Behavior and the corresponding QSPEC format are described.
NULLの計量アプリケーション[RFC2997]はトラフィックプロファイルが含まれていないだろう、と概念的にはQSPECでこれをサポートすることが可能です。トラフィックプロファイルなしQSPECは、現在の仕様では除外されていません。しかし、過剰治療が指定されていない場合、トラフィックプロファイルはベストエフォート型の集約のための帯域幅を交渉中で、例えば、でもその場合に重要であることに注意してください。しかし、「NULLサービスQOSM」は、所望のQNE挙動と対応QSPEC形式が記載されている場所を指定する必要があります。
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.
NULL計量するための例示的な動作として、適切に構成されたDiffservのルータでは、リソースは、スケジューリング規律によって凝集体間で共有されます。他の全ての凝集体が十分な帯域幅リソースが提供されつつ、受信率が増加した場合、それは、その集合体の中にキューの状態に影響を与えます。 NULLの計量は、ベストエフォートと、それは、おそらく、アクティブキュー管理機構が割り当てられた帯域幅によって暗黙的ポリシングとされるようにメーターと警察への必要は、このデータが存在しないデータを、シグナリングのために有用です。
The coding for the <PHB Class> parameter is as follows [RFC3140]:
[RFC3140]を次のように<PHBクラス>パラメータのコーディングは次のとおりです。
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.
[RFC2474]によって許容されるよう標準化作用、すなわち、実験的または局所使用のPHBによって定義されていないのPHB。この場合には、IANAによって割り当てられた任意の12ビットPHB識別コードは、16ビットのフィールドで左詰めに配置されます。ビット15が1に設定され、のPHBのセットのための単一のPHBのために0または1である14ビットです。ビット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.
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のセットを識別するために使用される場合の両方の場合において、PHBスケジューリングのクラスを構成しなければならないのPHBのセット（すなわち、セットからのPHBの使用がイントラ引き起こしてはならない、（すなわち、14は、1に設定されているビット）セットとは異なるのPHBを同じマイクロトラフィックに適用される-microflowトラフィック並べ替え）。 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ミリ秒、遅延変動<= 50ミリ秒、および損失率<= 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ミリ秒、遅延変動<= 50ミリ秒、および損失率<= 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ミリ秒、遅延変動<= 50ミリ秒、および損失率<= 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ミリ秒、遅延変動<= 50ミリ秒、および損失率<= 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の非常に詳細なセキュリティ議論の7節で詳述すべての考慮事項[RFC5974]はQSPECに適用されています。
The priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such attacks, for example:
ユーザーは、それによって効果的に重大な緊急事態を防止介して取得するために呼び出して、実際の必要なく、そのフローのための緊急の優先権を主張する可能性があるため、優先度パラメータは、サービスの窃盗攻撃の可能性を提起します。いくつかのオプションには、例えば、このような攻撃に対抗するために存在します。
- 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ビット）：0：セクション5で指定されるように、以下の値が割り当てられている1望ましいQoS：2利用可能なQoS：QoSの予約3：最低限のQoS
Further values are as follows: 4-63: Unassigned 64-67: Private/Experimental Use 68-4095: Reserved (Note: 'Reserved' just means 'do not give these out'.) The registration procedure is Specification Required.
次のようにさらに値は次のとおりです。4-63：未割り当て64-67：プライベート/実験的な使用68から4095：予約（注：単に「はこれらを与えていない」という意味「予約済み」）登録手続きは仕様が必要です。
QSPEC Version (4 bits): The following value is allocated by this specification: 0: Version 0 QSPEC Further values are as follows: 1-15: Unassigned The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QSPEC versions.)
QSPECバージョン（4ビット）：0：次の値は、本明細書によって割り当てられ、次のようにバージョン0 QSPECさらなる値は：1~15：未割り当ての登録手順は、仕様が必要です。 （仕様は、減価削除、またはQSPECバージョンを変更する必要があります。）
QSPEC Type (5 bits): The following values are allocated by this specification: 0: Default 1: Y.1541-QOSM [RFC5976] 2: RMD-QOSM [RFC5977] Further values are as follows: 3-12: Unassigned 13-16: Local/Experimental Use 17-31: Reserved The registration procedure is Specification Required.
QSPECタイプ（5ビット）：次の値は、本明細書によって割り振られる：0：デフォルト1：Y. 1541-QOSM [RFC5976] 2：3-12：次のようにRMD-QOSM [RFC5977]さらなる値が割り当てられていません13- 16：ローカル/実験的な使用17-31：予約登録手続きは仕様が必要です。
QSPEC Procedure (8 bits): The QSPEC Procedure object consists of the Message Sequence parameter (4 bits) and the Object Combination parameter (4 bits), as discussed in Section 4.3. Message Sequences 0 (Two-Way Transactions), 1 (Three-Way Transactions), and 2 (Resource Queries) are explained in Sections 4.3.1, 4.3.2, and 4.3.3, respectively. Tables 1, 2, and 3 in Section 4.3 assign the Object Combination Number to Message Sequences 0, 1, and 2, respectively. The values assigned by this specification for the Message Sequence parameter and the Object Combination parameter are summarized here:
QSPEC手順（8ビット）：セクション4.3で議論するようにQSPEC手順オブジェクトは、メッセージシーケンスパラメータ（4ビット）とオブジェクト結合パラメータ（4ビット）で構成されています。メッセージは、それぞれ、0（双方向取引）、1（三方取引）、およびセクション4.3.1、4.3.2で説明されている2（リソースクエリ）、および4.3.3を配列します。 4.3節の表1,2、及び3は、それぞれ、メッセージシーケンス0、1、及び2にオブジェクト組み合わせ番号を割り当てます。メッセージシーケンスパラメータとオブジェクトの結合パラメータについては、この仕様によって割り当てられた値は、ここに要約されています：
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS Available
Further values of the Message Sequence parameter (4 bits) are as follows: 3-15: Unassigned
3-15：次のようにメッセージのシーケンスパラメータ（4ビット）のさらなる値は、割り当てられていません
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
QoSのモデルエラーコード（8ビット）：[RFC5974]のセクション6.4に記載したようなQoSモデルエラーコードは、NSLPエラークラス6（QOSモデル誤差）のために定義されてもよいです。値は次のとおりです：0-63：未割り当て64-67：プライベート/実験的な使用
68-255: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QoS Model Error Codes.)
68から255：登録手続き予約は仕様が必要です。 （仕様は、減価削除、またはQoSモデルのエラーコードを修正する必要があります。）
Parameter ID (12 bits): The following values are allocated by this specification: 1-14: assigned as specified in Section 5.2: 1: <TMOD-1> 2: <TMOD-2> 3: <Path Latency> 4: <Path Jitter> 5: <Path PLR> 6: <Path PER> 7: <Slack Term> 8: <Preemption Priority> and <Defending Priority> 9: <Admission Priority> 10: <RPH Priority> 11: <Excess Treatment> 12: <PHB Class> 13: <DSTE Class Type> 14: <Y.1541 QoS Class> Further values are as follows: 15-255: Unassigned 256-259: Private/Experimental Use 260-4095: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify Parameter IDs.)
パラメータID（12ビット）：以下の値はこの仕様で割り当てられる：1-14：1：5.2節で指定されるように割り当てられた<TMOD-1> 2 <TMOD-2> 3 <パス遅延> 4 <パスジッタ> 5 <パスPLR> 6 <パスPER> 7 <スラック期間> 8 <先取り優先>と<防衛優先> 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：0-2：以下の値は、本明細書により割り当てられるセクション5.2.9で指定されるように割り当てられたベストエフォート優先フロー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]のセクション12.6を参照）[RFC4412]は既にRPH名前空間と優先順位値のレジストリを作成しなお、このレジストリへの拡張は[EMERG-RSVP]に作成され、その意志またQSPEC RPHパラメータのために使用されます。拡張されたレジストリでは、「名前空間数値値」RPH名前空間にIANAによって割り当てられ、
"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：次の値は、本明細書により割り当てられ0：セクション5.2.11で指定されるように割り当てられた1ドロップ：形状2：再マーク3：NO計量またはポリシングをさらに許可されていません値は次のとおりです。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：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.
著者は、（アルファベット順）デヴィッド・ブラック、ケン・カールバーグ、アンナCharny、クリスチャン・ディックマン、エードリアンファレル、Ruediger Geib、マティアス・フリードリヒ、暁明フー、ジャネット・ガン、ロバート・ハンコック、クリス・ラング、ユッカマナー、マーティンStiemerlingに感謝したいと思い、彼らは非常に有益な提案のためのグエン、トム・フェラン、ジェームズ・ポーク、アレクサンダーSayenko、ジョン・ローゼンバーグ、ハンネスTschofenig、とスヴェン・バン・デン・ボッシュ。
This document is the result of the NSIS Working Group effort. In addition to the authors/editors listed in Section 12, the following people contributed to the document:
この文書では、NSISワーキンググループの努力の結果です。第12節に記載されている著者/編集者に加えて、次の人が文書に貢献しました。
Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany Phone: +49 721 608 6413 EMail: bless@kit.edu URI: http://tm.kit.edu/~bless
ローランドは、テレマティクス研究所、カールスルーエ工科大学（KIT）Zirkel 2、20.20私書箱の構築を祝福しますボックス6980カールスルーエ76049ドイツ電話：+49 721 608 6413 Eメール：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
チャック・ドヴォルザークAT＆Tルーム2A37 180パークアベニュー、建物2フローハムパーク、NJ 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 MghazliアルカテルルートドゥNozay 91460 Marcoussis CedexのFRANCE電話：+33 1 69 63 41 87 Eメール：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
トウェンテの私書箱のゲオルギオスカラGiannis大学g.karagiannis@ewi.utwente.nl：BOX 217 7500 AEエンスヘーデ、ネザーメールランズ
Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk
アンドリュー・マクドナルドシーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国Eメール：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
アルモートンAT＆TルームD3-3C06 200 S.ローレルアベニューミドルタウン、NJ 07748電話：+1 732 420から1571ファックス：+1 732 368から1192 Eメール：acmorton@att.com
Bernd Schloer University of Goettingen EMail: bschloer@cs.uni-goettingen.de
ゲッティンゲンメールのベルントSchloer大学：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
パーシーTarapore AT＆TルームD1-33 200 S.ローレルアベニューミドルタウン、NJ 07748電話：+1 732 420から4172 Eメール：tarapore @ .att.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com
ラースWestbergエリクソン研究Torshamnsgatan 23 SE-164 80ストックホルム、スウェーデンのEメール：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世代パートナーシッププロジェクト。技術仕様グループコアネットワーク;ステージ2（リリース7） - マルチレベル優先順位および優先処理サービス（eMLPP）を強化。
[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世代パートナーシッププロジェクト。技術仕様グループコアネットワーク;ステージ3（リリース6） - マルチレベル優先順位および優先処理サービス（eMLPP）を強化。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、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]黒、D.、つば、S.、大工、B.、およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]ヘルツォーク、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]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、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.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506]アイスラー、M.、エド、 "XDR：外部データ表現標準"。、STD 67、RFC 4506、2006年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、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]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "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.
[組成]モートン、A.及びE.ステファン、「メトリックの空間的組成物」は、進歩、2010年7月に作業。
[DQOS] CableLabs, "PacketCable Dynamic Quality of Service Specification", CableLabs Specification PKT-SP-DQOS-I12-050812, August 2005.
[DQOS] CableLabsの、 "サービス仕様のPacketCableのダイナミックな品質"、CableLabsの仕様PKT-SP-DQOS-I12-050812、2005年8月。
[EMERG-RSVP] Le Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority", Work in Progress, March 2010.
[EMERG-RSVP]ルFaucheur、F.、ポーク、J.、およびK.カールバーグ、 "アドミッション優先順位のためのリソース予約プロトコル（RSVP）の拡張"、進歩、2010年3月での作業。
[G.711] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies", November 1988.
[G.711] ITU-T勧告G.711、 "音声周波数のパルス符号変調（PCM）"、1988年11月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985.
[IEEE754]電気電子技術者協会、「バイナリ浮動小数点演算のためのIEEE規格」、ANSI / IEEE規格754-1985、1985年8月。
[CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.
[CL-QOSM] Kappler、C.、 "NSISとシグナリングイントサーブ制御・ロード・サービスのためのQoSモデル"、進歩、2010年4月の作業。
[DSCP-REGISTRY] IANA, "Differentiated Services Field Codepoints", http://www.iana.org.
[DSCP-REGISTRY] IANA、 "差別化サービスフィールドコードポイント"、http://www.iana.org。
[NETWORK-OCTET-ORDER] Wikipedia, "Endianness", http://en.wikipedia.org/wiki/Endianness.
[NETWORK-OCTET-ORDER]ウィキペディア、 "エンディアン"、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]ハンクス、S.、李、T.、ファリナッチ、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]ハンクス、S.、李、T.、ファリナッチ、D.、およびP. Trainaの、 "IPv4ネットワーク上総称ルーティングカプセル化"、RFC 1702、1994年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]パーキンス、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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen、J.とR.ゲラン、 "シングルレート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.、スミス、A.、およびB.デイビー、 "ヌルサービスタイプの仕様"、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.、ブレイク、S.、グロスマン、D.、およびA.スミス、 "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]デミチェリス、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識した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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
[RFC4301]ケントと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]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]モートン、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]アッシュ、G.、モートン、A.、ドリー、M.、Tarapore、P.、ドヴォルザーク、C.、およびY.エルMghazli、「Y. 1541-QOSM：Y. 1541 Quality-を使用するネットワークのモデルの-サービスクラス」、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]ベイダー、A.、Westberg、L.、Karagiannis、G.、Kappler、C、およびT.フェラン、 "RMD-QOSM：NSISサービス品質のDiffservの中にリソース管理のためのモデル"、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]ドリー、M.、Tarapore、P.、およびS.セイヤーズ、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
ADSPEC、TSpecの、およびRSVPイントサーブのRSpecの上に所望のQoS、使用可能なQoS、およびNSISのQoSの予約の付録A.マッピング
The union of QoS Desired, QoS Available, and QoS Reserved can provide all functionality of the objects specified in RSVP IntServ; however, it is difficult to provide an exact mapping.
望ましいQoSの労働組合、QoSが使用可能な、およびQoS予約は、RSVPイントサーブで指定されたオブジェクトのすべての機能を提供することができます。しかし、正確なマッピングを提供することは困難です。
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の、ならびに追加のIntServ QoSモデルの特定のパラメータを提供RSpecの、例えば、速度およびスラックを含むたFlowSpecを送信します。
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のモデルが採用し、受信が開始したシグナリングに合わせました。例えば、著者らの知る限り、送信者が暗黙とmutably応じADSPECを播種することによって除く所望の最大遅延を指定することは不可能です。同様に、RSpecののみ有意義受信発行RSVPのRESERVEメッセージで送信されます。このため、この時点で私たちの議論は、より柔軟なシグナリング・モデルを生じるはずであるオブジェクトに必要な機能のわずかに異なるマッピングに私たちをリードしています。
Appendix B. Example of TMOD Parameter Encoding
TMODパラメータエンコーディングの付録B.例
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キロビット/秒の帯域幅（8000オクテット/秒）を指定します。 RTPは、音声は20msごとにデータグラムを送信すると仮定すると、あるデータグラムのペイロードは8000オクテット/秒* 0.02秒= 160オクテットです。
IPv4 + UDP + RTP + payload: m = 20 + 8 + 12 + 160 octets = 200 octets IPv6 + UDP + RTP + payload: m = 40 + 8 + 12 + 160 octets = 220 octets
IPv4の+ UDP + RTP +ペイロード：M = 20 + 8 + 12 + 160 = 200オクテットオクテットのIPv6 + UDP + RTP +ペイロード：M = 40 + 8 + 12 + 160 = 220個のオクテットオクテット
The Rate r specifies the amount of octets per second. 50 datagrams are sent per second.
レートrは、毎秒のオクテットの量を指定します。 50グラム毎秒送信されます。
IPv4: r = 50 1/s * m = 10,000 octets/s IPv6: r = 50 1/s * m = 11,000 octets/s
IPv4のR = 50 1 / S *のM =万オクテット/秒のIPv6：R = 50 1 / S×m個= 11,000オクテット/秒
The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used.
バケットサイズbは最大バーストを指定します。この例では、10のパケットのバーストが使用されます。
IPv4: b = 10 * m = 2000 octets IPv6: b = 10 * m = 2200 octets
IPv4のA：B = 10×m個= 2000オクテットのIPv6：B = 10 * M = 2200オクテット
A number of extra headers (e.g., for encapsulation) may be included in the datagram. A non-exhaustive list is given below. For additional headers, m, r, and b have to be set accordingly.
エクストラヘッダ（例えば、カプセル化のための）の数は、データグラムに含まれていてもよいです。非網羅的なリストは以下のとおりです。追加ヘッダ、M、R、B用に応じて設定されなければなりません。
Protocol Header Size
--------------------------+------------
GRE [RFC1701] | 8 octets
GREIP4 [RFC1702] | 4-8 octets
IP4INIP4 [RFC2003] | 20 octets
MINENC [RFC2004] | 8-12 octets
IP6GEN [RFC2473] | 40 octets
IP6INIP4 [RFC4213] | 20 octets
IPsec [RFC4301, RFC4303] | variable
--------------------------+------------
Authors' Addresses
著者のアドレス
Gerald Ash (Editor) AT&T EMail: gash5107@yahoo.com
ジェラルド・アッシュ（編集）AT＆T Eメール：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
アッティラベイダー（編集）交通研究所エリクソンエリクソンハンガリー株式会社Laborc U。 1 H-1037ブダペスト、ハンガリーのEメール：Attila.Bader@ericsson.com
Cornelia Kappler (Editor) ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
コーネリアKappler（編集）CK技術の概念ベルリン、ドイツのEメール：cornelia.kappler@cktecc.de
David R. Oran (Editor) Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720, USA EMail: oran@cisco.com
デヴィッド・R.オラン（編集）シスコシステムズ、株式会社7 Ladyslipperレーンアクトン、MA 01720、USA Eメール：oran@cisco.com