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.
この文書は、インターネットコミュニティのために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/rfc5976.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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クラスと関連する指針に基づいて、層プロトコル（QOS-NSLP）アプリケーションシグナリング（NSIS）のQoSのためのQoSモデル（QOSM）を記述する。 [Y. 1541]現在ネットワークパフォーマンス目標の8クラスを指定し、Y. 1541-QOSM拡張子が追加QSPEC [RFC5975]パラメータとQOSM処理ガイドラインが含まれます。拡張機能は[TRQ-のQoS-SIG]に要件（[Y. 1541]及び[E.361]）、及びガイダンスをQoSシグナリングに関するITU-Tで標準化作業に基づいています。
[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]はメッセージタイプを定義し、QoS-NSLP全てQOSMsに一般的なもののための制御情報。 QOSMは全体としてQoSを実現するために定義されたメカニズムです。 QOSMの仕様は、情報がネットワークで処理又は解釈されるべき方法、ならびに、そのQSPECパラメータ情報の記述を含みます。 QSPEC [RFC5975]は要求されたリソースを記述するパラメータと値のセットを含みます。それは、QoS-NSLPとTSpecの、RSpecの、および[RFC2205]及び[RFC2210]で指定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を基礎として、Y. 1541回のQoSクラスで、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クラスは、ユーザアプリケーションの広い範囲をサポートしています。パラメータ自体は[Y.1540]で定義されているワンウェイIPパケット遅延、IPパケット遅延変動、IPパケット損失率などのクラスグループの目標。
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の緊急転送（EF）ホップ単位動作（PHB）を使用して実装されるかもしれない、と彼らはインタラクティブなリアルタイム・アプリケーション[RFC3246]をサポートしています。クラス2、3、および4は、転送（AFxy）PHBグループアシュアードのDiffservを使用して実現されるかもしれない、と彼らは双方向[RFC2597]の種々の程度との間のデータ転送アプリケーションをサポートします。クラス5は、一般的にはDiffservデフォルトPHBに対応し、それはベストエフォート型サービス[RFC2474]で指定されていない一貫性のあるすべてのQoSパラメータを持っています。クラス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ミリ秒、遅延変動<= 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回路エミュレーションを含みます。
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]、および[COMPOSITION]の第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ベースのQoSのためのシグナリング情報の仕様を導きます。 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）は、毎秒のオクテット
c. peak rate (p), octets per second
C。ピーク率（p）は、毎秒のオクテット
d. bucket size (b), octets
D。バケットサイズ（B）、オクテット
e. maximum packet size (MPS), octets, IP header + IP payload
電子。最大パケットサイズ（MPS）、オクテット、IPヘッダ+ IPペイロード
f. Diffserv PHB class [RFC2475]
F。たDiffserv PHBクラス[RFC2475]
g. admission priority, 32-bit integer, range: 0-2
グラム。アドミッション優先、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]
時間。ピークバケットサイズ（BP）、オクテット、単精度IEEE浮動小数点形式の32ビット浮動小数点数[IEEE754]
i. restoration priority, multiple integer values defined in Section 3 below
私。復元の優先度、下記のセクション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:
次のQoS-NSLP Y. 1541-QOSMの要件を満たすための機能を、シグナリングを行うことが可能でなければなりません。
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つの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| 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が、[IEEE754]オクテット単位のIEEE浮動小数点値として表されます。符号ビットは、（すべての値は非負でなければなりません）ゼロでなければなりません。指数未満127（即ち、0）禁止されています。 162（即ち、正35）より大きい指数は無限のピーク速度を指定する以外は、推奨されています。無限大は、すべてのもの（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.
TMOD拡張パラメータのQSPECパラメータの動作は、[RFC5975]のセクション3.3.1で定義されたことになります。新しいパラメータ（およびすべてのトラフィック関連のパラメータが）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.
下記に定義されるように、このパラメータは、三つのフィールドや予約領域を持っています。
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.
これらの優先順位の値はベストエフォート優先度が優先度レベル3と同じである[Y.2172]に記載されており、通常の優先度は、優先度レベル2であり、そして高優先度は、復元の優先度について詳しく説明するいくつかの方法があり優先レベル1です。二つの電流のパラメータは以下の通りです。
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
タイム・ツー・リストア（TTR）フィールド（4ビットの符号なし整数）：障害によって影響を受ける所与復元クラスに属するトラフィックストリームを復元するための時間の合計。この期間は、修復のために配備技術に依存しています。 <200ミリ秒の高速リカバリ期間が付き、現在の経験に基づいています
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:
同期光ネットワーク（SONET）リングと2秒の低速の回復期間はドロップされずに回復する音声通話を可能とするために提案されています。したがって、TTRの復元は、範囲は、提案しました：
0 - Unspecified Time-to-Restore
0 - 未指定の時間・ツー・復元
1 - Best Time-to-Restore: <= 200 ms
1 - ベストタイム・ツー・復元：<= 200ミリ秒
2 - Normal Time-to-Restore <= 2 s
2 - ノーマルタイム・ツー・復元<= 2秒
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%
3 - 高優先度は、> = 80％回復します。中優先度は、> = 80％回復します
4 - high priority restored >= 80%; medium priority restored >= 60%
4 - 高優先度は、> = 80％回復します。中優先度は、> = 60％回復します
5 - high priority restored >= 60%; medium priority restored >= 60%
5 - 高い優先順位が復元> = 60％。中優先度は、> = 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機能を使用する方法を示しています。新たな処理能力は、（セクション3で指定された2つのオプションの新しいパラメータを除く）Y. 1541 QOSMを有効にする必要はありません。
[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の展開を強調しています。インテリアQNEsが望ましく、以下の例では、この可能性に対処したドメインの設定があるかもしれません。
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クラス>を指定すると、それは<パスの遅延時間>、<パスジッタ>、および<パスのBER>パラメータのための目的を十分に仕様です。第2節で述べたように、いくつかのY. 1541クラスは、上記のすべての性能パラメータのための目標を設定しないでください。例えば、クラス2、3、及び4は、（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
[RFC5975]のセクション3.4および図3に示すように与えられた例で説明したように、QoSのNSISイニシエータ（QNI）がイニシエータQSPECを含むエンドツーエンドの、ドメイン間のQoS NSLP RESERVEメッセージを開始します。 Y. 1541 QOSMの場合は、イニシエータQSPECは、フローのための<Y. 1541 QOSクラス>、<TMOD>、<TMOD拡張>、<入場優先順位>、<復旧の優先順位>とは、おそらく他のQSPECのパラメータを指定します。第3、TMODに記載されるように
extension parameter contains the OPTIONAL Y.1541-QOSM-specific terms; restoration priority is also an OPTIONAL Y.1541-QOSM-specific parameter.
拡張パラメータはオプション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のように、RESERVEメッセージは異なるQOSMsをサポートする複数のドメインを横切ることができます。この図では、イニシエータQSPECは、ローカルQOSMドメインの入口ノードでのQoS NSLP RESERVEメッセージに到着します。 [RFC5974]及び[RFC5975]に記載されているように、ローカルQOSMドメインの入口エッジノードで、エンドツーエンド、ドメイン間のQoS-NSLPメッセージはローカルQSPECの生成をトリガすることができる、および開始剤QSPECが封入されていますメッセージ内のローカルドメインを介して合図をしました。ローカルQSPECは、ローカルQOSMドメインでQoS処理のために使用され、イニシエータQSPECは、ローカルドメイン外のQoS処理のために使用されています。 [RFC5975]で指定されるように、任意のQNEは（Mはパラメータにゼロに設定ビットが、すなわち、）任意QSPECパラメータをサポートするために、イニシエータQSPECによって指定要件を満たすことができないならば、QNEは、（フラグがサポートされていないNフラグをセット）1へのパラメータのため。例えば、QNEは<パス遅延>パラメータはオプションのパラメータとして<パス遅延>を示すゼロに設定されているため、Mフラグ<パス遅延>パラメータとエンドツーエンド遅延の蓄積をサポートできない場合QNEは、一つの<パス遅延>パラメータのNフラグ（フラグがサポートされていない）を設定します。
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セット<望ましいQoS>、<最小のQoS>、および<利用可能なQoS>オブジェクトが含まれるように<Y. 1541のQoSクラス>、 BER>パラメーター。 QoSのクラスが指定されていないパラメータを離れる場合には、そのパラメータは、蓄積処理に含まれる必要がありません。 QNE /ドメインは<QoSが利用可能>オブジェクトで達成することができるY. 1541クラスおよび累積パラメータ、例えば、<パス遅延>、（ただし<最低限のQoS>で指定されたよりも少ない）を設定すべきです。これは、<望ましいQoS>で指定されたよりも低いクラスに<Y. 1541のQoSクラス>設定（ただし、<最低限のQoS>で指定されたよりも低くない）、例えば、含むことができます。 <利用可能なQoSが> <最小の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クラス>から減少しなければならない場合（たとえば、遅延目標を超えたため）、その後の遅れのために利用できる値で応答するインセンティブがあります<パスのレイテンシ>パラメータ。利用可能な<パス遅延が>（まだ多くの用途に有用である）と、所望のQoSが（対物その100ミリ秒で）クラス0である150ミリ秒である場合、（応答が0を達成することができないクラスであろうと、クラス1が利用可能です）その400ミリ秒を目的としました。また、このQOSMは応答が利用できる<Y. 1541のQoSクラス>の受け入れ可能性が高くなって、利用可能<パスレイテンシ> = 150ミリ秒を含めることができます。そこだけでは、伝搬遅延が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-QOSMネゴシエーションとエンド・ツー・エンドを達成することができ、累積パラメータ値を示します。例は、QNIが低い<Y. 1541のQoSクラス> <望ましいQoS>で指定されたよりも許容可能であるかどうかを判断するには、<利用可能な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.
この例では、すべてのパラメータがので、すべてのM-フラグが1に設定されている、QNEsによってサポートされなければならないことを前提としています。
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].
[IEEE754]で指定されるように32ビットの浮動小数点数である場合。
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.
先取り予約を取り壊すのデフォルトQNI動作はY. 1541のQOSMに続いています。上記の復旧の優先度パラメータは、プリエンプションに依存しません。
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.
このセクションでは、BCP 26 [RFC5226]に従って、QSPECパラメータIDレジストリに追加のコードポイントの割り当てを定義し、リストア優先度パラメータの一つの新たなレジストリを確立する（初期値を割り当てます）。また、新しいレジストリのための新しいコードポイントを割り当てるに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)
<TMOD拡張>パラメータ（セクション3.1、ID = 15）
<Restoration Priority> parameter (Section 3.2, ID=16)
<復旧の優先順位>パラメータ（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オクテットの単語と単語の予約セクションの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
1 - ベストタイム・ツー・復元：<= 200ミリ秒
2 - Normal Time-to-Restore <= 2 s
2 - ノーマルタイム・ツー・復元<= 2秒
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%
3 - 高優先度は、> = 80％回復します。中優先度は、> = 80％回復します
4 - high priority restored >= 80%; medium priority restored >= 60%
4 - 高優先度は、> = 80％回復します。中優先度は、> = 60％回復します
5 - high priority restored >= 60%; medium priority restored >= 60%
5 - 高い優先順位が復元> = 60％。中優先度は、> = 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.
著者は、有益なコメントや議論のためアッティラバーダー、コーネリアKappler、スヴェン・ヴァン・デン・ボッシュ、およびハンネスTschofenigに感謝します。
[IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic", 1985.
[IEEE754] ANSI / IEEE、 "ANSI / IEEE 754-1985、2進浮動小数点演算のためのIEEE規格"、1985年。
[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月。
[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月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]アッシュ、G.、ベイダー、A.、Kappler、C.、およびD.オラン、 "サービス品質NSISシグナリング層プロトコルのためのQSPECテンプレート（NSLP）"、RFC 5975、2010年10月。
[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.
[組成]モートン、A.及びE.ステファン、「メトリックの空間構成」、進歩、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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 Services", 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月。
[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.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、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]モートン、A.及びS.ヴァンデンベルグフ、 "メトリック組成物のためのフレームワーク"、RFC 5835、2010年4月。
[TRQ-QoS-SIG] ITU-T Supplement 51 to the Q-Series, "Signaling Requirements for IP-QoS", January 2004.
、2004年1月 "IP-QoSの要件をシグナリング" Qシリーズへ[TRQ-QoSの-SIG] ITU-Tサプリメント51、。
Authors' Addresses
著者のアドレス
Gerald Ash AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
ジェラルド・アッシュAT＆T Labsの200ローレルアベニュー南ミドルタウン、NJ 07748 USA
EMail: gash5107@yahoo.com
メールアドレス：gash5107@yahoo.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
アルモートンAT＆T Labsの200ローレルアベニュー南ミドルタウン、NJ 07748 USA
Phone: +1 732 420 1571 Fax: +1 732 368 1192 EMail: acmorton@att.com URI: http://home.comcast.net/~acmacm/
電話：+1 732 420 1571ファックス：+1 732 368 1192 Eメール：acmorton@att.com URI：http://home.comcast.net/~acmacm/
Martin Dolly AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
マーティン・ドリーAT＆T Labsの200ローレルアベニュー南ミドルタウン、NJ 07748 USA
EMail: mdolly@att.com
メールアドレス：mdolly@att.com
Percy Tarapore AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
パーシーTarapore AT＆T Labsの200ローレルアベニュー南ミドルタウン、NJ 07748 USA
EMail: tarapore@att.com
メールアドレス：tarapore@att.com
Chuck Dvorak AT&T Labs 180 Park Ave Bldg 2 Florham Park, NJ 07932 USA
チャック・ドヴォルザークAT＆T Labsの180パークアベニュービル2フローラムパーク、NJ 07932 USA
Phone: + 1 973-236-6700 EMail: cdvorak@att.com
電話：+ 1 973-236-6700 Eメール：cdvorak@att.com
Yacine El Mghazli Alcatel-Lucent Route de Nozay Marcoussis cedex 91460 France
エルYacine Mghazliアルカテル・ルーセントルートドゥNozay 91460 Marcoussisセデックスフランス
Phone: +33 1 69 63 41 87 EMail: yacine.el_mghazli@alcatel.fr
電話：+33 1 69 63 41 87 Eメール：yacine.el_mghazli@alcatel.fr