[要約] RFC 5976は、Y.1541品質サービスクラスを使用するネットワークのモデルに関するものです。このRFCの目的は、ネットワークの品質サービスクラスを定義し、ネットワークのパフォーマンスを向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) G. Ash
Request for Comments: 5976 A. Morton
Category: Experimental M. Dolly
ISSN: 2070-1721 P. Tarapore
C. Dvorak
AT&T Labs
Y. El Mghazli
Alcatel-Lucent
October 2010
Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
Y.1541-QOSM：Y.1541サービス品質クラスを使用したネットワークのモデル
Abstract
概要
This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.
このドキュメントでは、ITU-Tの推奨Y.1541ネットワークQoSクラスとシグナリングに関する関連ガイダンスに基づいたQOS-NSLPサービス品質モデル（QOSM）について説明します。Y.1541 8つのクラスのネットワークパフォーマンス目標を指定し、Y.1541-QOSM拡張には追加のQSPECパラメーターとQOSM処理ガイドラインが含まれます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5976.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5976で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Summary of ITU-T Recommendations Y.1541 and Signaling
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Description of Y.1541 Classes . . . . . . . . . . . . . . 4
2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 6
3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 7
3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 7
3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 8
4. Y.1541-QOSM Considerations and Processing Example . . . . . . 10
4.1. Deployment Considerations . . . . . . . . . . . . . . . . 10
4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 10
4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 10
4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 10
4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 12
4.6. Preemption Behavior . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. Assignment of QSPEC Parameter IDs . . . . . . . . . . . . 14
5.2. Restoration Priority Parameter Registry . . . . . . . . . 14
5.2.1. Restoration Priority Field . . . . . . . . . . . . . . 14
5.2.2. Time to Restore Field . . . . . . . . . . . . . . . . 15
5.2.3. Extent of Restoration Field . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document describes a QoS model (QOSM) for Next Steps in Signaling (NSIS) QoS signaling layer protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. [Y.1541] currently specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC [RFC5975] parameters and QOSM processing guidelines. The extensions are based on standardization work in the ITU-T on QoS signaling requirements ([Y.1541] and [E.361]), and guidance in [TRQ-QoS-SIG].
このドキュメントでは、ITU-T推奨Y.1541ネットワークQoSクラスとシグナリングに関する関連ガイダンスに基づいて、シグナリング（NSIS）QoSシグナルレイヤープロトコル（QOS-NSLP）アプリケーションの次のステップのQoSモデル（QOSM）について説明します。[Y.1541]は現在、8つのクラスのネットワークパフォーマンス目標を指定しており、Y.1541-QOSM拡張には追加のQSPEC [RFC5975]パラメーターとQOSM処理ガイドラインが含まれています。拡張機能は、QoSシグナリング要件に関するITU-Tの標準化作業（[Y.1541]および[E.361]）と[TRQ-QOS-SIG]のガイダンスに基づいています。
[RFC5974] defines message types and control information for the QoS-NSLP that are generic to all QOSMs. A QOSM is a defined mechanism for achieving QoS as a whole. The specification of a QOSM includes a description of its QSPEC parameter information, as well as how that information should be treated or interpreted in the network. The QSPEC [RFC5975] contains a set of parameters and values describing the requested resources. It is opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec, and AdSpec specified in [RFC2205] and [RFC2210]. A QOSM provides a specific set of parameters to be carried in the QSPEC object. At each QoS NSIS Entity (QNE), the QSPEC contents are interpreted by the resource management function (RMF) for purposes of policy control and traffic control, including admission control and configuration of the scheduler.
[RFC5974]は、すべてのQOSMにジェネリックであるQOS-NSLPのメッセージタイプと制御情報を定義します。QoSMは、QoS全体を達成するための定義されたメカニズムです。QOSMの仕様には、QSPECパラメーター情報の説明と、その情報をネットワークで扱うか解釈する方法が含まれています。QSPEC [RFC5975]には、要求されたリソースを記述する一連のパラメーターと値が含まれています。これはQoS-NSLPに不透明であり、[RFC2205]および[RFC2210]で指定されたTSPEC、RSPEC、およびADSPECと同様です。QOSMは、QSPECオブジェクトに携帯する特定のパラメーターセットを提供します。各QoS NSISエンティティ（QNE）で、QSPECの内容は、スケジューラの入場管理と構成を含む、ポリシー管理とトラフィック管理の目的でリソース管理機能（RMF）によって解釈されます。
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]で説明されているように解釈されます。
As stated above, [Y.1541] is a specification of standardized QoS classes for IP networks (a summary of these classes is given below). Section 7 of [TRQ-QoS-SIG] describes the signaling features needed to achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a basis. [Y.1541] recommends a flexible allocation of the end-to-end performance objectives (e.g., delay) across networks, rather than a fixed per-network allocation. NSIS protocols already address most of the requirements; this document identifies additional QSPEC parameters and processing requirements needed to support the Y.1541 QOSM.
上記のように、[Y.1541]は、IPネットワークの標準化されたQoSクラスの仕様です（これらのクラスの概要を以下に示します）。[TRQ-QOS-SIG]のセクション7では、IPネットワークでエンドツーエンドQOSを達成するために必要なシグナリング機能について説明します。[Y.1541]は、固定されたネットワークごとの割り当てではなく、ネットワーク全体でエンドツーエンドのパフォーマンス目標（たとえば、遅延）の柔軟な割り当てを推奨しています。NSISプロトコルはすでにほとんどの要件に対処しています。このドキュメントは、Y.1541 QOSMをサポートするために必要な追加のQSPECパラメーターと処理要件を識別します。
[Y.1541] proposes grouping services into QoS classes defined according to the desired QoS performance objectives. These QoS classes support a wide range of user applications. The classes group objectives for one-way IP packet delay, IP packet delay variation, IP packet loss ratio, etc., where the parameters themselves are defined in [Y.1540].
[Y.1541]は、目的のQoSパフォーマンス目標に従って定義されたQoSクラスへのグループ化サービスを提案しています。これらのQoSクラスは、幅広いユーザーアプリケーションをサポートしています。一元配置IPパケット遅延、IPパケット遅延の変動、IPパケット損失比などのクラスグループの目的。パラメーター自体が[Y.1540]で定義されています。
Note that [Y.1541] is maintained by the ITU-T and subject to occasional updates and revisions. The material in this section is provided for information and to make this document easier to read. In the event of any discrepancies, the normative definitions found in [Y.1541] take precedence.
[Y.1541]はITU-Tによって維持され、時折更新と改訂の対象となることに注意してください。このセクションの資料は、情報のために提供され、このドキュメントを読みやすくします。矛盾が発生した場合、[Y.1541]で見つかった規範的定義が優先されます。
Classes 0 and 1 might be implemented using the Diffserv Expedited Forwarding (EF) Per-Hop Behavior (PHB), and they support interactive real-time applications [RFC3246]. Classes 2, 3, and 4 might be implemented using the Diffserv Assured Forwarding (AFxy) PHB Group, and they support data transfer applications with various degrees of interactivity [RFC2597]. Class 5 generally corresponds to the Diffserv Default PHB, and it has all the QoS parameters unspecified consistent with a best-effort service[RFC2474]. Classes 6 and 7 provide support for extremely loss-sensitive user applications, such as high-quality digital television, Time Division Multiplexing (TDM) circuit emulation, and high-capacity file transfers using TCP. These classes are intended to serve as a basis for agreements between end-users and service providers, and between service providers. They support a wide range of user applications including point-to-point telephony, data transfer, multimedia conferencing, and others. The limited number of classes supports the requirement for feasible implementation, particularly with respect to scale in global networks.
クラス0と1は、DiffServ Expedited Forwarding（EF）Per Hopの動作（PHB）を使用して実装され、インタラクティブなリアルタイムアプリケーション[RFC3246]をサポートします。クラス2、3、および4は、DiffServ Assured Forwarding（AFXY）PHBグループを使用して実装される可能性があり、さまざまな程度のインタラクティブ性でデータ転送アプリケーションをサポートします[RFC2597]。クラス5は一般に、DiffServデフォルトPHBに対応しており、すべてのQoSパラメーターが最適なサービスと一致する不特定のQoSパラメーターを持っています[RFC2474]。クラス6と7は、高品質のデジタルテレビ、時代分割多重化（TDM）回路エミュレーション、TCPを使用した大容量ファイル転送など、非常に損失に敏感なユーザーアプリケーションをサポートしています。これらのクラスは、エンドユーザーとサービスプロバイダーの間、およびサービスプロバイダー間の契約の基礎として機能することを目的としています。ポイントツーポイントテレフォニー、データ転送、マルチメディア会議などを含む幅広いユーザーアプリケーションをサポートしています。限られた数のクラスは、特にグローバルネットワークの規模に関して、実行可能な実装の要件をサポートしています。
The QoS classes apply to a packet flow, where [Y.1541] defines a packet flow as the traffic associated with a given connection or connectionless stream having the same source host, destination host, class of service, and session identification. The characteristics of each Y.1541 QoS class are summarized here:
QoSクラスは、[Y.1541]が特定の接続に関連付けられたトラフィックまたは同じソースホスト、宛先ホスト、サービスクラス、およびセッション識別を持つ接続のないストリームに関連付けられたトラフィックとしてパケットフローを定義するパケットフローに適用されます。各Y.1541 QoSクラスの特性をここにまとめます。
Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
クラス0：ジッターに敏感なリアルタイム、高度にインタラクティブなアプリケーション。平均遅延<= 100 ms、遅延変動<= 50 ms、および損失比<= 10^-3。アプリケーションの例には、VoIPとビデオ通信が含まれます。
Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
クラス1：ジッターに敏感なリアルタイムのインタラクティブなアプリケーション。平均遅延<= 400 ms、遅延変動<= 50 ms、および損失比<= 10^-3。アプリケーションの例には、VoIPとビデオ通信が含まれます。
Class 2: Highly interactive transaction data. Mean delay <= 100 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
クラス2：高度にインタラクティブなトランザクションデータ。平均遅延<= 100ミリ秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、シグナリングが含まれます。
Class 3: Interactive transaction data. Mean delay <= 400 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
クラス3：インタラクティブトランザクションデータ。平均遅延<= 400ミリ秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、シグナリングが含まれます。
Class 4: Low Loss Only applications. Mean delay <= 1 s, delay variation is unspecified, loss ratio <= 10^-3. Application examples include short transactions, bulk data, and video streaming.
クラス4：低損失のみのアプリケーション。平均遅延<= 1秒、遅延変動は不特定で、損失比<= 10^-3。アプリケーションの例には、短いトランザクション、バルクデータ、ビデオストリーミングが含まれます。
Class 5: Unspecified applications with unspecified mean delay, delay variation, and loss ratio. Application examples include traditional applications of default IP networks.
クラス5：不特定の平均遅延、遅延変動、および損失比を持つ不特定のアプリケーション。アプリケーションの例には、デフォルトのIPネットワークの従来のアプリケーションが含まれます。
Class 6: Applications that are highly sensitive to loss. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and Time-Division Multiplexing (TDM) circuit emulation.
クラス6：損失に非常に敏感なアプリケーション。平均遅延<= 100 ms、遅延変動<= 50 ms、および損失比<= 10^-5。アプリケーションの例には、テレビ輸送、大容量のTCP転送、および時間分割多重化（TDM）回路エミュレーションが含まれます。
Class 7: Applications that are highly sensitive to loss. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and TDM circuit emulation.
クラス7：損失に非常に敏感なアプリケーション。平均遅延<= 400 ms、遅延変動<= 50 ms、および損失比<= 10^-5。アプリケーションの例には、テレビ輸送、大容量のTCP転送、およびTDM回路エミュレーションが含まれます。
These classes enable service level agreements (SLAs) to be defined between customers and network service providers with respect to QoS requirements. The service provider then needs to ensure that the requirements are recognized and receive appropriate treatment across network layers.
これらのクラスにより、QoS要件に関して、顧客とネットワークサービスプロバイダー間でサービスレベル契約（SLA）を定義できます。サービスプロバイダーは、要件が認識され、ネットワークレイヤー全体で適切な処理を受けることを確認する必要があります。
Work is in progress to specify methods for combining local values of performance metrics to estimate the performance of the complete path. See Section 8 of [Y.1541], [RFC5835], and [COMPOSITION].
パフォーマンスメトリックのローカル値を組み合わせて完全なパスのパフォーマンスを推定する方法を指定する作業が進行中です。[Y.1541]、[RFC5835]、および[組成]のセクション8を参照してください。
[TRQ-QoS-SIG] guides the specification of signaling information for IP-based QoS at the interface between the user and the network (UNI) and across interfaces between different networks (NNI). To meet specific network performance requirements specified for the Y.1541 QoS classes [Y.1541] , a network needs to provide specific user-plane functionality at the UNI and NNI. Dynamic network provisioning at a UNI and/or NNI node allows a traffic contract for an IP flow to be dynamically requested from a specific source node to one or more destination nodes. In response to the request, the network determines if resources are available to satisfy the request and provision the network.
[TRQ-QOS-SIG]は、ユーザーとネットワーク（UNI）間のインターフェイスと、異なるネットワーク間のインターフェイス（NNI）間のインターフェイスでIPベースのQOのシグナリング情報の仕様をガイドします。Y.1541 QOSクラス[Y.1541]に指定された特定のネットワークパフォーマンス要件を満たすには、ネットワークはUNIおよびNNIで特定のユーザー面機能を提供する必要があります。UNIおよび/またはNNIノードでの動的ネットワークプロビジョニングにより、IPフローのトラフィック契約を特定のソースノードから1つ以上の宛先ノードに動的に要求できます。要求に応じて、ネットワークは、リクエストを満たしてネットワークを提供するためにリソースが利用可能かどうかを判断します。
For implementations to claim compliance with this memo, it MUST be possible to derive the following service-level parameters as part of the process of requesting service:
このメモのコンプライアンスを請求するためには、サービスを要求するプロセスの一部として、次のサービスレベルパラメーターを導き出すことができる必要があります。
a. Y.1541 QoS class, 32-bit integer, range: 0-7
a. Y.1541 QoSクラス、32ビット整数、範囲：0-7
b. rate (r), octets per second
b. レート（r）、1秒あたりのオクテット
c. peak rate (p), octets per second
c. ピークレート（P）、1秒あたりのオクテット
d. bucket size (b), octets
d. バケットサイズ（B）、オクテット
e. maximum packet size (MPS), octets, IP header + IP payload
e. 最大パケットサイズ（MPS）、オクテット、IPヘッダーIPペイロード
f. Diffserv PHB class [RFC2475]
f. Diffserv PHBクラス[RFC2475]
g. admission priority, 32-bit integer, range: 0-2
g. 入場の優先順位、32ビット整数、範囲：0-2
Compliant implementations MAY derive the following service-level parameters as part of the service request process:
準拠の実装は、サービス要求プロセスの一部として、次のサービスレベルのパラメーターを導き出すことができます。
h. peak bucket size (Bp), octets, 32-bit floating point number in single-precision IEEE floating point format [IEEE754]
h. ピークバケットサイズ（bp）、オクテット、32ビットのフローティングポイント数字IEEEフローティングポイント形式[IEEE754]
i. restoration priority, multiple integer values defined in Section 3 below
i. 復元の優先順位、以下のセクション3で定義されている複数の整数値
All parameters except Bp and restoration priority have already been specified in [RFC5975]. These additional parameters are defined as
BPおよび回復優先度を除くすべてのパラメーターは、[RFC5975]ですでに指定されています。これらの追加パラメーターは、次のように定義されています
o Bp, the size of the peak-rate bucket in a dual-token bucket arrangement, essentially setting the maximum length of bursts in the peak-rate stream. For example, see Annex B of [Y.1221]
o BPは、デュアルトークンバケット配置のピークレートバケットのサイズであり、基本的にピークレートストリームのバーストの最大長を設定します。たとえば、[Y.1221]の付録Bを参照してください
o restoration priority, as defined in Section 3 of this memo
o このメモのセクション3で定義されているように、復元の優先順位
Their QSPEC Parameter format is specified in Section 3.
それらのQSPECパラメーター形式は、セクション3で指定されています。
It MUST be possible to perform the following QoS-NSLP signaling functions to meet Y.1541-QOSM requirements:
Y.1541-QOSM要件を満たすために、次のQOS-NSLPシグナル伝達関数を実行することが可能である必要があります。
a. accumulate delay, delay variation, and loss ratio across the end-to-end connection, which may span multiple domains.
a. エンドツーエンド接続全体に遅延、遅延変動、および損失比が蓄積され、複数のドメインにまたがる可能性があります。
b. enable negotiation of Y.1541 QoS class across domains.
b. ドメイン全体でY.1541 QoSクラスの交渉を有効にします。
c. enable negotiation of delay, delay variation, and loss ratio across domains.
c. ドメイン全体で遅延、遅延変動、および損失比の交渉を可能にします。
These signaling requirements are supported in [RFC5974], and the functions are illustrated in Section 4 of this memo.
これらのシグナル伝達要件は[RFC5974]でサポートされており、機能はこのメモのセクション4に示されています。
The specifications in this section extend the QSPEC [RFC5975].
このセクションの仕様は、QSPEC [RFC5975]を拡張します。
The traffic model (TMOD) extension parameter is represented by one floating point number in single-precision IEEE floating point format and one 32-bit reserved field.
トラフィックモデル（TMOD）拡張パラメーターは、単一の精度IEEEフローティングポイント形式の1つのフローティングポイント番号と1つの32ビット予約フィールドで表されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 15 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TMOD Extension
図1：TMOD拡張機能
The Peak Bucket Size term, Bp, is represented as an IEEE floating point value [IEEE754] in units of octets. 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 zeros.
ピークバケットサイズの用語であるBPは、オクテットの単位でIEEEフローティングポイント値[IEEE754]として表されます。記号ビットはゼロでなければなりません（すべての値は非陰性でなければなりません）。127（つまり、0）未満の指数は禁止されています。162（つまり、正の35）を超える指数は、無限のピーク速度を指定することを除き、落胆しています。Infinityは、すべての指数（255）とすべてのゼロのサインビットとマンティッサで表されます。
The QSPEC parameter behavior for the TMOD extended parameter follows that defined in Section 3.3.1 of [RFC5975]. The new parameter (and all traffic-related parameters) are specified independently from the Y.1541 class parameter.
[RFC5975]のセクション3.3.1で定義されているTMOD拡張パラメーターのQSPECパラメーター動作は次のとおりです。新しいパラメーター（およびすべてのトラフィック関連パラメーター）は、Y.1541クラスパラメーターとは独立して指定されています。
Restoration priority is the urgency with which a service requires successful restoration under failure conditions. Restoration priority is achieved by provisioning sufficient backup capacity, as necessary, and allowing relative priority for access to available bandwidth when there is contention for restoration bandwidth. Restoration priority is defined 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| 16 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest. Priority| TTR | EOR | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Restoration Priority Parameter
図2：復元優先パラメーター
This parameter has three fields and a reserved area, as defined below.
このパラメーターには、以下に定義されているように、3つのフィールドと予約領域があります。
Restoration Priority Field (8-bit unsigned integer): 3 priority values are listed here in the order of lowest priority to highest priority:
修復優先フィールド（8ビットの符号なし整数）：3つの優先度の優先度が最も低い順にリストされています。
0 - best effort
0-最善の努力
1 - normal
1-通常
2 - high
2-ハイ
These priority values are described in [Y.2172], where best-effort priority is the same as Priority level 3, normal priority is Priority level 2, and high priority is Priority level 1. There are several ways to elaborate on restoration priority, and the two current parameters are described below.
これらの優先度の値は[Y.2172]で説明されています。ここでは、最良の優先度は優先度レベル3と同じで、通常の優先度は優先度レベル2、優先度が優先度レベル1です。2つの現在のパラメーターについては、以下に説明します。
Time-to-Restore (TTR) Field (4-bit unsigned integer): Total amount of time to restore traffic streams belonging to a given restoration class impacted by the failure. This time period depends on the technology deployed for restoration. A fast recovery period of < 200 ms is based on current experience with Synchronous Optical Network (SONET) rings and a slower recovery period of 2 seconds is suggested in order to enable a voice call to recover without being dropped. Accordingly, TTR restoration suggested ranges are:
回復時間（TTR）フィールド（4ビットの符号なし整数）：障害の影響を受けた特定の修復クラスに属するトラフィックストリームを復元するための合計時間。この期間は、復元のために展開された技術に依存します。200 ms未満の高速回復期間は、同期光ネットワーク（SONET）リングの現在の経験に基づいており、音声通話がドロップされずに回復できるようにするために、2秒の回復期間が遅いことが提案されています。したがって、TTRの復元範囲は次のとおりです。
0 - Unspecified Time-to-Restore
0-不特定の時間からの時間
1 - Best Time-to-Restore: <= 200 ms
2 - Normal Time-to-Restore <= 2 s
Extent of Restoration (EOR) Field (4-bit unsigned integer): Percentage of traffic belonging to the restoration class that can be restored. This percentage depends on the amount of spare capacity engineered. All high-priority restoration traffic, for example, may be "guaranteed" at 100% by the service provider. Other classes may offer lesser chances for successful restoration. The restoration extent for these lower priority classes depend on SLAs developed between the service provider and the customer.
修復範囲（EOR）フィールド（4ビットの符号なし整数）：復元できる修復クラスに属するトラフィックの割合。この割合は、設計された予備容量の量に依存します。たとえば、すべての優先度回復トラフィックは、サービスプロバイダーによって100％で「保証」される場合があります。他のクラスは、復元を成功させるためのより少ないチャンスを提供する場合があります。これらのより低い優先度クラスの回復範囲は、サービスプロバイダーと顧客の間で開発されたSLAに依存します。
EOR values are assigned as follows:
EOR値は次のように割り当てられます。
0 - unspecified EOR
0-特定されていないEOR
1 - high priority restored at 100%; medium priority restored at 100%
1-高い優先度は100％で復元されました。100％で復元された中程度の優先度
2 - high priority restored at 100%; medium priority restored at 80%
2-高い優先度は100％で復元されました。80％で復元された中程度の優先度
3 - high priority restored >= 80%;
medium priority restored >= 80%
4 - high priority restored >= 80%;
medium priority restored >= 60%
5 - high priority restored >= 60%;
medium priority restored >= 60%
Reserved: These 2 octets are reserved. The Reserved bits MAY be designated for other uses in the future. Senders conforming to this version of the Y.1541 QOSM SHALL set the Reserved bits to zero. Receivers conforming to this version of the Y.1541 QOSM SHALL ignore the Reserved bits.
予約済み：これら2つのオクテットは予約されています。予約されたビットは、将来の他の用途に指定される場合があります。Y.1541 QOSMのこのバージョンに準拠している送信者は、予約ビットをゼロに設定するものとします。Y.1541 QOSMのこのバージョンに準拠した受信機は、予約済みのビットを無視するものとします。
In this section, we illustrate the operation of the Y.1541 QOSM, and show how current QoS-NSLP and QSPEC functionality is used. No new processing capabilities are required to enable the Y.1541 QOSM (excluding the two OPTIONAL new parameters specified in Section 3).
このセクションでは、Y.1541 QOSMの動作を示し、現在のQOS-NSLPおよびQSPEC機能がどのように使用されるかを示します。Y.1541 QOSM（セクション3で指定された2つのオプションの新しいパラメーターを除く）を有効にするために、新しい処理機能は必要ありません。
[TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders of supporting domains. There may be domain configurations where interior QNEs are desirable, and the example below addresses this possibility.
[TRQ-QOS-SIG]は、支持ドメインの境界でのY.1541 QNESの展開を強調しています。インテリアQNEが望ましいドメイン構成がある場合があり、以下の例はこの可能性に対処しています。
All procedures defined in Section 5.3 of [RFC5975] are applicable to this QOSM.
[RFC5975]のセクション5.3で定義されているすべての手順は、このQoSMに適用できます。
Section 7 of [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs.
[TRQ-QOS-SIG]のセクション7では、Y.1541 QNESの情報処理について説明します。
Section 8 of [Y.1541] defines the accumulation rules for individual performance parameters (e.g., delay, jitter).
[Y.1541]のセクション8では、個々のパフォーマンスパラメーター（遅延、ジッターなど）の蓄積規則を定義しています。
When a QoS NSIS initiator (QNI) specifies the Y.1541 QoS Class number, <Y.1541 QoS Class>, it is a sufficient specification of objectives for the <Path Latency>, <Path Jitter>, and <Path BER> parameters. As described in Section 2, some Y.1541 Classes do not set objectives for all the performance parameters above. For example, Classes 2, 3, and 4 do not specify an objective for <Path Jitter> (referred to as IP Packet Delay Variation). In the case that the QoS Class leaves a parameter unspecified, then that parameter need not be included in the accumulation processing.
QoS NSISイニシエーター（QNI）がY.1541 QOSクラス番号<Y.1541 QOSクラス>を指定する場合、<Path Latency>、<Path Jitter>、および<Path Ber>パラメーターの目的の十分な仕様である場合。セクション2で説明したように、一部のY.1541クラスは、上記のすべてのパフォーマンスパラメーターの目標を設定しません。たとえば、クラス2、3、および4は、<Path Jitter>（IPパケット遅延バリエーションと呼ばれる）の目的を指定しません。QoSクラスがパラメーターを不特定のままにする場合、そのパラメーターを蓄積処理に含める必要はありません。
As described in the example given in Section 3.4 of [RFC5975] and as illustrated in Figure 3, the QoS NSIS initiator (QNI) initiates an end-to-end, interdomain QoS NSLP RESERVE message containing the Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC specifies the <Y.1541 QOS Class>, <TMOD>, <TMOD Extension>, <Admission Priority>, <Restoration Priority>, and perhaps other QSPEC parameters for the flow. As described in Section 3, the TMOD extension parameter contains the OPTIONAL Y.1541-QOSM-specific terms; restoration priority is also an OPTIONAL Y.1541-QOSM-specific parameter.
[RFC5975]のセクション3.4で示されている例で説明されており、図3に示すように、QoS NSISイニシエーター（QNI）は、イニシエーターQSPECを含むエンドツードメインQoS NSLPリザーブメッセージを開始します。Y.1541 QOSMの場合、イニシエーターQSPECは<Y.1541 QOSクラス>、<tmod>、<tmod extension>、<入場優先>、<復元優先>、およびおそらくフローの他のQSPECパラメーターを指定します。。セクション3で説明したように、TMOD拡張パラメーターにはオプションのY.1541-QOSM固有の項が含まれています。復元優先度は、オプションのY.1541-QOSM固有のパラメーターでもあります。
As Figure 3 below shows, the RESERVE message may cross 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. As described in [RFC5974] and [RFC5975], at the ingress edge node of the local-QOSM domain, the end-to-end, interdomain QoS-NSLP message may trigger 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. As specified in [RFC5975], if any QNE cannot meet the requirements designated by the Initiator QSPEC to support an optional QSPEC parameter (i.e., with the M bit set to zero for the parameter), the QNE sets the N flag (not supported flag) for the parameter to one. For example, if the QNE cannot support the accumulation of end-to-end delay with the <Path Latency> parameter, where the M flag for the <Path Latency> parameter is set to zero denoting <Path Latency> as an optional parameter, the QNE sets the N flag (not supported flag) for the <Path Latency> parameter to one.
以下の図3に示すように、予備のメッセージは異なるQoSMをサポートする複数のドメインを横切る可能性があります。この図では、イニシエーターQSPECは、ローカルQOSMドメインのイングレスノードにQOS NSLPリザーブメッセージに到着します。[RFC5974]および[RFC5975]で説明されているように、ローカルQOSMドメインのイングレスエッジノードでは、エンドツーエンドのドメインQOS-NSLPメッセージがローカルQSPECの生成をトリガーする可能性があり、イニシエーターQSPECはカプセル化されています。ローカルドメインを介して通知されたメッセージ内。ローカルQSPECは、ローカルQOSMドメインでのQOS処理に使用され、イニシエーターQSPECはローカルドメイン外のQOS処理に使用されます。[RFC5975]で指定されているように、QNEがイニシエーターQSPECによって指定された要件を満たすことができない場合、オプションのQSPECパラメーター（つまり、パラメーターの場合はmビットがゼロに設定されています）をサポートします。）パラメーターに対して1つ。たとえば、QNEが<パスレイテンシ>パラメーターでエンドツーエンドの遅延の蓄積をサポートできない場合、<パスレイテンシ>パラメーターのmフラグは、オプションパラメーターとして<パスレイテンシ>を示すゼロに設定されています。QNEは、<パスレイテンシ>パラメーターのnフラグ（サポートされていないフラグ）を1に設定します。
Also, the Y.1541-QOSM requires negotiation of the <Y.1541 QoS Class> across domains. This negotiation can be done with the use of the existing procedures already defined in [RFC5974]. For example, the QNI sets <Desired QoS>, <Minimum QoS>, and <Available QoS> objects to include <Y.1541 QoS Class>, which specifies objectives for the <Path Latency>, <Path Jitter>, and <Path BER> parameters. In the case that the QoS Class leaves a parameter unspecified, then that parameter need not be included in the accumulation processing. The QNE/domain SHOULD set the Y.1541 class and cumulative parameters, e.g., <Path Latency>, that can be achieved in the <QoS Available> object (but not less than specified in <Minimum QoS>). This could include, for example, setting the <Y.1541 QoS Class> to a lower class than specified in <QoS Desired> (but not lower than specified in <Minimum QoS>). If the <Available QoS> fails to satisfy one or more of the <Minimum QoS> objectives, the QNE/domain notifies the QNI and the reservation is aborted. Otherwise, the QoS NSIS Receiver (QNR) notifies the QNI of the <QoS Available> for the reservation.
また、Y.1541-QOSMには、ドメイン全体の<Y.1541 QoSクラス>の交渉が必要です。この交渉は、[RFC5974]ですでに定義されている既存の手順を使用して行うことができます。たとえば、QNIは、<Y.1541 QoSクラス>、<パスレイテンシ>、<パスジッター>、および<パスを指定する<y.1541 qos class>を含むように<希望のqos>、<byminib qos>、および<利用可能なqos>オブジェクトを設定します。BER>パラメーター。QoSクラスがパラメーターを不特定のままにする場合、そのパラメーターを蓄積処理に含める必要はありません。QNE/ドメインは、<QOS利用可能>オブジェクトで実現できるY.1541クラスと累積パラメーター（<Path Latency>）を設定する必要があります（ただし、<最小QoS>で指定されていません）。これには、たとえば、<y.1541 qosクラス>を<qos recired>で指定されたよりも低いクラスに設定することが含まれます（ただし、<minimum qos>で指定されているよりも低くはありません）。<利用可能なQoS>が1つ以上の<最小QoS>目的を満たさない場合、QNE/ドメインはQNIを通知し、予約は中止されます。それ以外の場合、QOS NSISレシーバー（QNR）は、予約の<QOS利用可能>のQNIに通知します。
When the available <Y.1541 QoS Class> must be reduced from the desired <Y.1541 QoS Class> (say, because the delay objective has been exceeded), then there is an incentive to respond with an available value for delay in the <Path Latency> parameter. If the available <Path Latency> is 150 ms (still useful for many applications) and the desired QoS is Class 0 (with its 100 ms objective), then the response would be that Class 0 cannot be achieved, and Class 1 is available (with its 400 ms objective). In addition, this QOSM allows the response to include an available <Path Latency> = 150 ms, making acceptance of the available <Y.1541 QoS Class> more likely. There are many long paths where the propagation delay alone exceeds the Y.1541 Class 0 objective, so this feature adds flexibility to commit to exceed the Class 1 objective when possible.
利用可能な<Y.1541 QOSクラス>を目的の<Y.1541 QOSクラス>（遅延目標が超えたため）から削減する必要がある場合、遅延の利用可能な値で応答するインセンティブがあります。<パスレイテンシ>パラメーター。利用可能な<パスレイテンシ>が150ミリ秒（多くのアプリケーションにまだ役立つ）であり、目的のQosがクラス0（100ミリ秒の目的で）である場合、応答はクラス0を達成できず、クラス1が利用可能であるということです（クラス1が利用可能です（400ミリ秒の目的で）。さらに、このQOSMにより、応答は利用可能な<Path Latency> = 150 msを含めることができ、利用可能な<Y.1541 QoSクラス>を受け入れる可能性が高くなります。伝播遅延だけでY.1541クラス0の目的を超える多くの長いパスがあるため、この機能は、可能な場合はクラス1の目的を超える柔軟性を追加します。
This example illustrates Y.1541-QOSM negotiation of <Y.1541 QoS Class> and cumulative parameter values that can be achieved end-to-end. The example illustrates how the QNI can use the cumulative values collected in <QoS Available> to decide if a lower <Y.1541 QoS Class> than specified in <QoS Desired> is acceptable.
この例は、エンドツーエンドを達成できる<Y.1541 QOSクラス> <Y.1541 QoSクラス>のY.1541-QOSM交渉と累積パラメーター値を示しています。この例は、QNIが<QOS利用可能>で収集された累積値を使用して、<QOS希望>で指定されているよりも低い<Y.1541 QOSクラス>を決定するかを決定する方法を示しています。
|------| |------| |------| |------|
| 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 3: Example of Y.1541-QOSM Operation
図3：Y.1541-QOSM操作の例
This is an example where the QOS Desired specification contains the TMOD-1 parameters and TMOD extended parameters defined in this specification, as well as the Y.1541 Class parameter. The QOS Available specification utilizes the Latency, Jitter, and Loss parameters to enable accumulation of these parameters for easy comparison with the objectives desired for the Y.1541 Class.
これは、QoSの目的仕様に、この仕様で定義されているTMOD-1パラメーターとTMOD拡張パラメーター、およびY.1541クラスパラメーターが含まれる例です。QOS利用可能な仕様は、Y.1541クラスに必要な目標と簡単に比較するために、これらのパラメーターの蓄積を可能にするために、レイテンシ、ジッター、および損失パラメーターを使用します。
This example assumes that all the parameters MUST be supported by the QNEs, so all M-flags have been set to 1.
この例では、すべてのパラメーターがQNESによってサポートされている必要があるため、すべてのMフラグが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 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 [MPS] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 15 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: An Example QSPEC (Initiator)
図4：QSPECの例（イニシエーター）
where 32-bit floating point numbers are as specified in [IEEE754].
ここで、32ビットの浮動小数点数は[IEEE754]で指定されています。
The default QNI behavior of tearing down a preempted reservation is followed in the Y.1541 QOSM. The restoration priority parameter described above does not rely on preemption.
Y.1541 QOSMで、先制予約を引き裂くというデフォルトのQNI動作が続きます。上記の復元優先パラメーターは、先制に依存していません。
This section defines additional codepoint assignments in the QSPEC Parameter ID registry and establishes one new registry for the Restoration Priority Parameter (and assigns initial values), in accordance with BCP 26 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints for the new registry.
このセクションでは、QSPECパラメーターIDレジストリの追加のコードポイント割り当てを定義し、BCP 26 [RFC5226]に従って、復元優先パラメーターの1つの新しいレジストリ（および初期値を割り当てる）を確立します。また、新しいレジストリに新しいコードポイントを割り当てる際にIANAが従うべき手続き要件を定義します。
This document specifies the following QSPEC parameters, which have been assigned in the QSPEC Parameter ID registry created in [RFC5975]:
このドキュメントは、[RFC5975]で作成されたQSPECパラメーターIDレジストリに割り当てられている次のQSPECパラメーターを指定します。
<TMOD Extension> parameter (Section 3.1, ID=15)
<Restoration Priority> parameter (Section 3.2, ID=16)
The Registry for Restoration Priority contains assignments for 3 fields in the 4-octet word and a Reserved section of the word.
復元の優先順位のレジストリには、4-OCTETワードの3つのフィールドの割り当てと単語の予約セクションが含まれています。
This specification creates the following registry with the structure as defined below.
この仕様では、以下に定義するように、構造を持つ次のレジストリが作成されます。
The Restoration Priority Field is 8 bits in length.
修復優先フィールドの長さは8ビットです。
The following values are allocated by this specification: 0-2: assigned as specified in Section 3.2:
次の値は、この仕様によって割り当てられます。0-2：セクション3.2で指定されているように割り当てられます：
0: best-effort priority
0：最優秀優先度
1: normal priority
1：通常の優先度
2: high priority
2：優先度が高い
Further values are as follows:
さらに値は次のとおりです。
3-255: Unassigned
3-255：割り当てられていない
The registration procedure is Specification Required.
登録手順が必要です。
The Time to Restore Field is 4 bits in length.
フィールドを復元する時間の長さは4ビットです。
The following values are allocated by this specification:
次の値は、この仕様によって割り当てられます。
0-2: assigned as specified in Section 3.2:
0-2：セクション3.2で指定されていると割り当てられます：
0 - Unspecified Time-to-Restore
0-不特定の時間からの時間
1 - Best Time-to-Restore: <= 200 ms
2 - Normal Time-to-Restore <= 2 s
Further values are as follows:
さらに値は次のとおりです。
3-15: Unassigned
3-15：割り当てられていない
The registration procedure is Specification Required.
登録手順が必要です。
The Extent of Restoration (EOR) Field is 4 bits in length.
修復（EOR）フィールドの範囲の長さは4ビットです。
The following values are allocated by this specification:
次の値は、この仕様によって割り当てられます。
0-5: assigned as specified in Section 3.2:
0-5：セクション3.2で指定されていると割り当てられます：
0 - unspecified EOR
0-特定されていないEOR
1 - high priority restored at 100%; medium priority restored at 100%
1-高い優先度は100％で復元されました。100％で復元された中程度の優先度
2 - high priority restored at 100%; medium priority restored at 80%
2-高い優先度は100％で復元されました。80％で復元された中程度の優先度
3 - high priority restored >= 80%;
medium priority restored >= 80%
4 - high priority restored >= 80%;
medium priority restored >= 60%
5 - high priority restored >= 60%;
medium priority restored >= 60%
Further values are as follows:
さらに値は次のとおりです。
6-15: Unassigned
6-15：割り当てられていない
The registration procedure is Specification Required.
登録手順が必要です。
The security considerations of [RFC5974] and [RFC5975] apply to this document.
[RFC5974]および[RFC5975]のセキュリティ上の考慮事項は、このドキュメントに適用されます。
The restoration 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 from getting 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 or fire departments)
- すべてのユーザーは、特定の目的地アドレス（警察や消防署など）に緊急事態の優先ビットを使用することを許可されています
There are no other known security considerations based on this document.
このドキュメントに基づいた他の既知のセキュリティ上の考慮事項はありません。
The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, and Hannes Tschofenig for helpful comments and discussion.
著者は、Attila Bader、Cornelia Kappler、Sven van den Bosch、およびHannes Tschofenigに、有益なコメントと議論をしてくれたことに感謝します。
[IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic", 1985.
[IEEE754] ANSI/IEEE、「ANSI/IEEE 754-1985、バイナリ浮動小数点算術のIEEE標準」、1985。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、RFC 5974、2010年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975] Ash、G.、Bader、A.、Kappler、C。、およびD. Oran、「サービス品質NSISシグナリング層プロトコル（NSLP）のQSPECテンプレート」、RFC 5975、2010年10月。
[Y.1221] ITU-T Recommendation Y.1221, "Traffic control and congestion control in IP based networks", March 2002.
[Y.1221] ITU-Tの推奨Y.1221、「IPベースのネットワークにおける交通制御と混雑制御」、2002年3月。
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2007.
[Y.1540] ITU -Tの推奨Y.1540、「インターネットプロトコルデータ通信サービス - IPパケット転送および可用性パフォーマンスパラメーター」、2007年12月。
[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.2172] ITU-T Recommendation Y.2172, "Service restoration priority levels in Next Generation Networks", June 2007.
[Y.2172] ITU-Tの推奨Y.2172、「次世代ネットワークにおけるサービス回復優先レベル」、2007年6月。
[COMPOSITION] Morton, A. and E. Stephan, "Spatial Composition of Metrics", Work in Progress, July 2010.
[構成] Morton、A。およびE. Stephan、「メトリックの空間的構成」、2010年7月の作業。
[E.361] ITU-T Recommendation E.361, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies", May 2003.
[E.361] ITU-T推奨E.361、「ルーティングテクノロジー全体のQoSサービスクラスのインターワーキングのQoSルーティングサポート」、2003年5月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、Bennet、J.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[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月。
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5835] Morton、A。およびS. Van den Berghe、「メトリック組成のフレームワーク」、RFC 5835、2010年4月。
[TRQ-QoS-SIG] ITU-T Supplement 51 to the Q-Series, "Signaling Requirements for IP-QoS", January 2004.
[TRQ-QOS-SIG] QシリーズのITU-Tサプリメント51、2004年1月、「IP-QOSのシグナリング要件」。
Authors' Addresses
著者のアドレス
Gerald Ash AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
ジェラルドアッシュAT＆Tラボ200ローレルアベニューサウスミドルタウン、ニュージャージー07748 USA
EMail: gash5107@yahoo.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA
Phone: +1 732 420 1571 Fax: +1 732 368 1192 EMail: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Martin Dolly AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
電話：1 732 420 1571 FAX：1 732 368 1192メール：acmorton@att.com URI：http：//home.comcast.net/~acmacm/ Martin Dolly AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA
EMail: mdolly@att.com
Percy Tarapore AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
パーシータラポアAT＆Tラボ200ローレルアベニューサウスミドルタウン、ニュージャージー07748 USA
EMail: tarapore@att.com
Chuck Dvorak AT&T Labs 180 Park Ave Bldg 2 Florham Park, NJ 07932 USA
Chuck Dvorak AT＆T Labs 180 Park Ave Bldg 2 Florham Park、NJ 07932 USA
Phone: + 1 973-236-6700
EMail: cdvorak@att.com
Yacine El Mghazli Alcatel-Lucent Route de Nozay Marcoussis cedex 91460 France
YACINE EL MGHAZLI ALCATEL-LUCENT ROUTE DE NOZAY MARCOSSIS CEDEX 91460フランス
Phone: +33 1 69 63 41 87
EMail: yacine.el_mghazli@alcatel.fr