Internet Engineering Task Force (IETF) A. Bader
Request for Comments: 5977 L. Westberg
Category: Experimental Ericsson
ISSN: 2070-1721 G. Karagiannis
University of Twente
C. Kappler
ck technology concepts
T. Phelan
Sonus
October 2010
RMD-QOSM: The NSIS Quality-of-Service Model
for Resource Management in Diffserv
Abstract
抽象
This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.
この文書では、Diffservの中にリソース管理（RMD）の概念を使用するネットワークのためのシグナリングにおける次のステップ（NSIS）のサービス品質（QoS）モデルについて説明します。 RMDは、差別化サービス（DiffServ）のネットワークにアドミッション制御とプリエンプション機能を追加するための技術です。 RMDのQoSモデルは、RMDネットワーク内のノードをEdgeに予約要求を通知するRMDネットワークの外部機器を可能にします。 RMD入口エッジノードは、トラフィッククラスおよび信号フロー毎出口エッジノードへのデータパスに沿って対応するトラフィック・クラスのためのリソース要求の中に入ってくる流れを分類します。出口ノードは、元の要求を再構成し、最終的な宛先に向けてデータパスに沿ってそれらを転送し続けます。また、RMDは、エッジノードにドメイン内の過負荷状態を示すために、通知機能を定義します。
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/rfc5977.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5977で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of RMD and RMD-QOSM ....................................7
3.1. RMD ........................................................7
3.2. Basic Features of RMD-QOSM ................................10
3.2.1. Role of the QNEs ...................................10
3.2.2. RMD-QOSM/QoS-NSLP Signaling ........................11
3.2.3. RMD-QOSM Applicability and Considerations ..........13
4. RMD-QOSM, Detailed Description .................................15
4.1. RMD-QSPEC Definition ......................................16
4.1.1. RMD-QOSM <QoS Desired> and <QoS Reserved> ..........16
4.1.2. PHR Container ......................................17
4.1.3. PDR Container ......................................20
4.2. Message Format ............................................23
4.3. RMD Node State Management .................................23
4.3.1. Aggregated Operational and Reservation
States at the QNE Edges ............................23
4.3.2. Measurement-Based Method ...........................25
4.3.3. Reservation-Based Method ...........................27
4.4. Transport of RMD-QOSM Messages ............................28
4.5. Edge Discovery and Message Addressing .....................31
4.6. Operation and Sequence of Events ..........................32
4.6.1. Basic Unidirectional Operation .....................32
4.6.1.1. Successful Reservation ....................34
4.6.1.2. Unsuccessful Reservation ..................46
4.6.1.3. RMD Refresh Reservation ...................50
4.6.1.4. RMD Modification of Aggregated
Reservations ..............................54
4.6.1.5. RMD Release Procedure .....................55
4.6.1.6. Severe Congestion Handling ................64
4.6.1.7. Admission Control Using Congestion
Notification Based on Probing .............70
4.6.2. Bidirectional Operation ............................73
4.6.2.1. Successful and Unsuccessful Reservations ..77
4.6.2.2. Refresh Reservations ......................82
4.6.2.3. Modification of Aggregated Intra-Domain
QoS-NSLP Operational Reservation States ...82
4.6.2.4. Release Procedure .........................83
4.6.2.5. Severe Congestion Handling ................84
4.6.2.6. Admission Control Using Congestion
Notification Based on Probing .............87
4.7. Handling of Additional Errors .............................89
5. Security Considerations ........................................89
5.1. Introduction ..............................................89
5.2. Security Threats ..........................................91
5.2.1. On-Path Adversary ..................................92
5.2.2. Off-Path Adversary .................................94
5.3. Security Requirements .....................................94
5.4. Security Mechanisms .......................................94
6. IANA Considerations ............................................97
6.1. Assignment of QSPEC Parameter IDs .........................97
7. Acknowledgments ................................................97
8. References .....................................................97
8.1. Normative References ......................................97
8.2. Informative References ....................................98
Appendix A. Examples .............................................101
A.1. Example of a Re-Marking Operation during Severe
Congestion in the Interior Nodes .........................101
A.2. Example of a Detailed Severe Congestion Operation in the
Egress Nodes .............................................107
A.3. Example of a Detailed Re-Marking Admission Control
(Congestion Notification) Operation in Interior Nodes ....111
A.4. Example of a Detailed Admission Control (Congestion
Notification) Operation in Egress Nodes ..................112
A.5. Example of Selecting Bidirectional Flows for Termination
during Severe Congestion .................................113
A.6. Example of a Severe Congestion Solution for
Bidirectional Flows Congested Simultaneously on Forward
and Reverse Paths ........................................113
A.7. Example of Preemption Handling during Admission Control ..117
A.8. Example of a Retransmission Procedure within the RMD
Domain ...................................................120
A.9. Example on Matching the Initiator QSPEC to the Local
RMD-QSPEC ................................................122
This document describes a Next Steps in Signaling (NSIS) QoS Model for networks that use the Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2], [RMD3], and [RMD4]). RMD adds admission control to Diffserv networks and allows nodes external to the networks to dynamically reserve resources within the Diffserv domains.
この文書では、（[RMD1]、[RMD2]、[RMD3]、および[RMD4]）のDiffserv（RMD）枠組みの中でリソース管理を使用するネットワークのためのシグナリング（NSIS）のQoSモデルで次のステップを説明します。 RMDは、Diffservのネットワークにアドミッション制御を追加し、ネットワークへの外部ノードが動的のDiffservドメイン内のリソースを予約することを可能にします。
The Quality-of-Service NSIS Signaling Layer Protocol (QoS-NSLP) [RFC5974] specifies a generic protocol for carrying QoS signaling information end-to-end in an IP network. Each network along the end-to-end path is expected to implement a specific QoS Model (QOSM) specified by the QSPEC template [RFC5975] that interprets the requests and installs the necessary mechanisms, in a manner that is appropriate to the technology in use in the network, to ensure the delivery of the requested QoS. This document specifies an NSIS QoS Model for RMD networks (RMD-QOSM), and an RMD-specific QSPEC (RMD-QSPEC) for expressing reservations in a suitable form for simple processing by internal nodes.
サービス品質NSISシグナリング層プロトコル（QoSの-NSLP）[RFC5974]は、エンドツーエンドのIPネットワークに情報をQoSシグナリングを運ぶための汎用プロトコルを指定します。エンドツーエンドパスに沿った各ネットワークは、使用中の技術に適切であるように、要求を解釈し、必要な機構をインストールQSPECテンプレート[RFC5975]で指定された特定のQoSモデル（QOSM）を実装することが期待されますネットワーク内で、要求されたQoSの配信を保証します。この文書では、内部ノードによって簡単な処理に適した形態で予約を発現させるためのRMDネットワークのNSISのQoSモデル（RMD-QOSM）、及びRMD特異QSPEC（RMD-QSPEC）を指定します。
They are used in combination with the QoS-NSLP to provide QoS signaling service in an RMD network. Figure 1 shows an RMD network with the respective entities.
彼らは、RMDネットワークでサービスをQoSシグナリングを提供するために、QoSの-NSLPとの組み合わせで使用されています。図1は、それぞれのエンティティとRMDネットワークを示します。
Stateless or reduced-state Egress
Ingress RMD Nodes Node
Node (Interior Nodes; I-Nodes) (Stateful
(Stateful | | | RMD QoS
RMD QoS-NLSP | | | NSLP Node)
Node) V V V
+-------+ Data +------+ +------+ +------+ +------+
|-------|--------|------|------|------|-------|------|---->|------|
| | Flow | | | | | | | |
|Ingress| |I-Node| |I-Node| |I-Node| |Egress|
| | | | | | | | | |
+-------+ +------+ +------+ +------+ +------+
=================================================>
<=================================================
Signaling Flow
Figure 1: Actors in the RMD-QOSM
図1：RMD-QOSMにおけるアクタ
Many network scenarios, such as the "Wired Part of Wireless Network" scenario, which is described in Section 8.4 of [RFC3726], require that the impact of the used QoS signaling protocol on the network performance should be minimized. In such network scenarios, the performance of each network node that is used in a communication path has an impact on the end-to-end performance. As such, the end-to-end performance of the communication path can be improved by optimizing the performance of the Interior nodes. One of the factors that can contribute to this optimization is the minimization of the QoS signaling protocol processing load and the minimization of the number of states on each Interior node.
このような[RFC3726]のセクション8.4に記載されているシナリオ、「無線ネットワークの有線部分」などの多くのネットワークシナリオは、ネットワーク性能にシグナリングプロトコル使用のQoSの影響は最小限にすべきであることを必要とします。このようなネットワークシナリオでは、通信経路に使用される各ネットワーク・ノードの性能は、エンドツーエンドのパフォーマンスに影響を与えます。このように、通信パスのエンド・ツー・エンドの性能は内部ノードの性能を最適化することによって改善することができます。この最適化に寄与し得る要因の一つは、プロトコル処理負荷及び各内部ノードの状態数の最小化をQoSシグナリングの最小化です。
Another requirement that is imposed by such network scenarios is that whenever a severe congestion situation occurs in the network, the used QoS signaling protocol should be able to solve them. In the case of a route change or link failure, a severe congestion situation may occur in the network. Typically, routing algorithms are able to adapt and change their routing decisions to reflect changes in the topology and traffic volume. In such situations, the rerouted traffic will have to follow a new path. Interior nodes located on this new path may become overloaded, since they suddenly might need to support more traffic than for which they have capacity. These severe congestion situations will severely affect the overall performance of the traffic passing through such nodes.
このようなネットワークシナリオによって課される他の要件が厳しい混雑状況がネットワークに発生するたびに、シグナリングプロトコル使用QoSは、それらを解決することができなければならないということです。経路変更またはリンク障害が発生した場合に、厳しい輻輳状況がネットワークに発生し得ます。一般的に、ルーティングアルゴリズムは適応し、トポロジとトラフィック量の変化を反映するために、ルーティング決定を変更することができます。このような状況では、再ルーティングトラフィックが新しい道をたどる必要があります。彼らは突然、彼らが能力を持っているよりも多くのトラフィックをサポートする必要がある場合がありますので、この新しいパス上にあるインテリア・ノードは、過負荷になることがあります。これらの深刻な混雑状況は厳しく、このようなノードを通過するトラフィックの全体的なパフォーマンスに影響します。
RMD-QOSM is an edge-to-edge (intra-domain) QoS Model that, in combination with the QoS-NSLP and QSPEC specifications, is designed to support the requirements mentioned above:
RMD-QOSMは、QoS-NSLPとQSPEC仕様と組み合わせて、上記の要件をサポートするように設計され、エッジ・ツー・エッジ（イントラドメイン）QoSモデルです。
o Minimal impact on Interior node performance;
内部ノードのパフォーマンスにO最小限の影響。
o Increase of scalability;
スケーラビリティのO増加。
o Ability to deal with severe congestion
ひどい渋滞に対処するためのO能力
Internally to the RMD network, RMD-QOSM together with QoS-NSLP [RFC5974] defines a scalable QoS signaling model in which per-flow QoS-NSLP and NSIS Transport Layer Protocol (NTLP) states are not stored in Interior nodes but per-flow signaling is performed (see [RFC5974]) at the Edges.
一緒のQoS-NSLP [RFC5974]と内部RMDネットワークに、RMD-QOSMは、フロー単位のQoS-NSLPとNSISトランスポート層プロトコル（NTLP）状態が内部ノードに格納されているが、フロー毎されていないモデルシグナリングスケーラブルなQoSを定義しますシグナリングは、エッジで（[RFC5974]を参照）が行われます。
In the RMD-QOSM, only routers at the Edges of a Diffserv domain (Ingress and Egress nodes) support the (QoS-NSLP) stateful operation; see Section 4.7 of [RFC5974]. Interior nodes support either the (QoS-NSLP) stateless operation or a reduced-state operation with coarser granularity than the Edge nodes.
RMD-QOSMにおいて、Diffservのドメインのエッジでのみルータ（入力および出力ノード）（QOS-NSLP）ステートフル動作をサポートします。 [RFC5974]のセクション4.7を参照してください。内部ノードは、（QOS-NSLP）ステートレス動作またはエッジノードよりも粗い粒度で低減状態動作のいずれかをサポートします。
After the terminology in Section 2, we give an overview of RMD and the RMD-QOSM in Section 3. This document specifies several RMD-QOSM/ QoS-NSLP signaling schemes. In particular, Section 3.2.3 identifies which combination of sections are used for the specification of each RMD-QOSM/QoS-NSLP signaling scheme. In Section 4 we give a detailed description of the RMD-QOSM, including the role of QoS NSIS entities (QNEs), the definition of the QSPEC, mapping of QSPEC generic parameters onto RMD-QOSM parameters, state management in QNEs, and operation and sequence of events. Section 5 discusses security issues.
第2節での用語の後、私たちは、このドキュメントでは、いくつかのRMD-QOSM / QoSの-NSLP信号方式を指定する3章でRMDの概要とRMD-QOSMを与えます。特に、セクション3.2.3は、識別セクションのどの組み合わせが各RMD-QOSM /のQoS-NSLPシグナリングスキームの指定のために使用されます。第4節では、我々は、QoSのNSISエンティティ（QNEs）の役割を含む、RMD-QOSMパラメータへQSPEC汎用パラメータのQSPEC、マッピング、QNEsでの状態管理、および操作の定義をRMD-QOSMの詳細な説明を与え、イベントのシーケンス。第5節では、セキュリティの問題について説明します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terminology defined by GIST [RFC5971] and QoS-NSLP [RFC5974] applies to this document.
GIST [RFC5971]およびQoS-NSLP [RFC5974]で定義された用語は、この文書に適用されます。
In addition, the following terms are used:
また、以下の用語が使用されます。
NSIS domain: an NSIS signaling-capable domain.
NSISドメイン：NSISシグナリング可能なドメイン。
RMD domain: an NSIS domain that is capable of supporting the RMD-QOSM signaling and operations.
RMDドメイン：RMD-QOSMシグナリングおよび操作をサポートすることができるNSISドメイン。
Edge node: a QoS-NSLP node on the boundary of some administrative domain that connects one NSIS domain to a node in either another NSIS domain or a non-NSIS domain.
エッジノード：別のNSISドメインまたは非NSISドメインのいずれかでノードに1つのNSISドメインを接続しているいくつかの管理ドメインの境界上のQoS-NSLPノード。
NSIS-aware node: a node that is aware of NSIS signaling and RMD-QOSM operations, such as severe congestion detection and Differentiated Service Code Point (DSCP) marking.
NSIS対応ノード：そのような重度の輻輳検出および差別化サービスコードポイント（DSCP）マーキングなどのNSISシグナリングおよびRMD-QOSM操作を認識しているノード。
NSIS-unaware node: a node that is unaware of NSIS signaling, but is aware of RMD-QOSM operations such as severe congestion detection and DSCP marking.
NSIS非対応ノード：NSISシグナリングを知らないが、そのようなマーキング重度の輻輳検出およびDSCPとしてRMD-QOSM操作を認識しているノード。
Ingress node: an Edge node in its role in handling the traffic as it enters the NSIS domain.
イングレスノード：それはNSISドメインに入ると、トラフィックを処理する際のその役割でエッジノード。
Egress node: an Edge node in its role in handling the traffic as it leaves the NSIS domain.
Egressノード：それはNSISドメインを離れると、トラフィックを処理する際のその役割でエッジノード。
Interior node: a node in an NSIS domain that is not an Edge node.
インテリアノード：エッジノードではないNSISドメイン内のノード。
Congestion: a temporal network state that occurs when the traffic (or when traffic associated with a particular Per-Hop Behavior (PHB)) passing through a link is slightly higher than the capacity allocated for the link (or allocated for the particular PHB). If no measures are taken, then the traffic passing through this link may temporarily slightly degrade in QoS. This type of congestion is usually solved using admission control mechanisms.
輻輳：トラフィック（または場合トラフィックが特定のホップ単位動作（PHB）に関連付けられている）は、リンクを通過するときに発生する一時的なネットワークの状態がリンク（または特定のPHBのために割り当てられた）のために割り当てられた容量よりもわずかに高いです。何の措置がとられていない場合は、このリンクを通過するトラフィックが一時的にわずかなQoSに低下することがあります。混雑のこのタイプは、通常、アドミッション制御メカニズムを使用して解決されます。
Severe congestion: the congestion situation on a particular link within the RMD domain where a significant increase in its real packet queue situation occurs, such as when due to a link failure rerouted traffic has to be supported by this particular link.
重度の輻輳：特定のリンク上の混雑状況の実際のパケットキューの状況の大幅な増加は、このような原因リンク障害へのトラフィックは、この特定のリンクによってサポートされていなければなりリルート時のように、発生RMDドメイン内。
The Differentiated Services (Diffserv) architecture ([RFC2475], [RFC2638]) was introduced as a result of efforts to avoid the scalability and complexity problems of IntServ [RFC1633]. Scalability is achieved by offering services on an aggregate rather than per-flow basis and by forcing as much of the per-flow state as possible to the Edges of the network. The service differentiation is achieved using the Differentiated Services (DS) field in the IP header and the Per-Hop Behavior (PHB) as the main building blocks. Packets are handled at each node according to the PHB indicated by the DS field in the message header.
差別化サービス（DiffServ）のアーキテクチャ（[RFC2475]、[RFC2638]）をのIntServ [RFC1633]の拡張性と複雑さの問題を回避する努力の結果として導入されました。スケーラビリティは、集約ではなくフロー単位でサービスを提供することによって、ネットワークのエッジにできるだけフロー毎の状態の多くを強制することによって達成されます。サービスの差別化は、IPヘッダとメインビルディングブロックとしてごとホップ挙動（PHB）で差別化サービス（DS）フィールドを使用して達成されます。パケットは、メッセージヘッダ内のDSフィールドによって示さPHBに従って各ノードで処理されます。
The Diffserv architecture does not specify any means for devices outside the domain to dynamically reserve resources or receive indications of network resource availability. In practice, service providers rely on short active time Service Level Agreements (SLAs) that statically define the parameters of the traffic that will be accepted from a customer.
DiffServアーキテクチャは、動的にリソースを予約またはネットワークリソースの可用性の指示を受信するドメイン外のデバイスのためのあらゆる手段を指定しません。実際には、サービスプロバイダは、静的に、顧客から受け入れられるトラフィックのパラメータを定義し、短いアクティブタイムサービスレベル契約（SLA）に依存しています。
RMD was introduced as a method for dynamic reservation of resources within a Diffserv domain. It describes a method that is able to provide admission control for flows entering the domain and a congestion handling algorithm that is able to terminate flows in case of congestion due to a sudden failure (e.g., link, router) within the domain.
RMDは、Diffservのドメイン内のリソースを動的に確保する方法として導入されました。これは、ドメインと、ドメイン内の急激な故障（例えば、リンク、ルータ）に、輻輳の場合の流れを停止することができ、輻輳処理アルゴリズムを入力フローに対してアドミッション制御を提供することができる方法を記載しています。
In RMD, scalability is achieved by separating a fine-grained reservation mechanism used in the Edge nodes of a Diffserv domain from a much simpler reservation mechanism needed in the Interior nodes. Typically, it is assumed that Edge nodes support per-flow QoS states in order to provide QoS guarantees for each flow. Interior nodes use only one aggregated reservation state per traffic class or no states at all. In this way, it is possible to handle large numbers of flows in the Interior nodes. Furthermore, due to the limited functionality supported by the Interior nodes, this solution allows fast processing of signaling messages.
RMDでは、スケーラビリティは、インテリア・ノードに必要なはるかに簡単な予約機構からのDiffservドメインのエッジノードで使用されるきめの細かい予約メカニズムを分離することによって達成されます。典型的には、エッジは、支持フローごとのQoSノードと仮定される各フローのQoS保証を提供するために述べて。インテリア・ノードは、すべてのトラフィッククラスまたはなしの状態ごとに1つだけの集約予約状態を使用しています。これにより、内部ノードにおけるフローの多数を処理することが可能です。また、内部ノードによってサポートされる限定された機能のために、この解決策は、シグナリングメッセージの高速処理を可能にします。
The possible RMD-QOSM applicabilities are described in Section 3.2.3. Two main basic admission control modes are supported: reservation-based and measurement-based admission control that can be used in combination with a severe congestion-handling solution. The severe congestion-handling solution is used in the situation that a link/node becomes severely congested due to the fact that the traffic supported by a failed link/node is rerouted and has to be processed by this link/node. Furthermore, RMD-QOSM supports both unidirectional and bidirectional reservations.
可能RMD-QOSMの適用可能性は、3.2.3項で説明されています。二つの主要な基本的なアドミッション制御モードがサポートされています。予約ベースと厳しい混雑ハンドリングソリューションと組み合わせて使用することができる測定ベースのアドミッション制御。ひどい渋滞ハンドリングソリューションは、リンク/ノードが失敗したため、リンク/ノードによってサポートされたトラフィックを再ルーティングし、このリンク/ノードによって処理しなければならないという事実にひどく混雑している状況で使用されています。さらに、RMD-QOSMは、両方の単方向および双方向の予約をサポートしています。
Another important feature of RMD-QOSM is that the intra-domain sessions supported by the Edges can be either per-flow sessions or per-aggregate sessions. In the case of the per-flow intra-domain sessions, the maintained per-flow intra-domain states have a one-to-one dependency to the per-flow end-to-end states supported by the same Edge. In the case of the per-aggregate sessions the maintained per-aggregate states have a one-to-many relationship to the per-flow end-to-end states supported by the same Edge.
RMD-QOSMのもう一つの重要な特徴は、エッジでサポートされているドメイン内のセッションは、フロー単位のセッションまたはごとの集計のセッションのいずれかであることができるということです。フロー毎のドメイン内のセッションの場合には、維持フローごとのイントラドメイン状態が同じエッジによってサポートされるフローごとのエンドツーエンドの状態に一対一の依存性を有しています。ごとの集計セッションの場合に維持ごと凝集状態が同じエッジによってサポートされるフローごとのエンドツーエンドの状態に1対多の関係を有しています。
In the reservation-based method, each Interior node maintains only one reservation state per traffic class. The Ingress Edge nodes aggregate individual flow requests into PHB traffic classes, and signal changes in the class reservations as necessary. The reservation is quantified in terms of resource units (or bandwidth). These resources are requested dynamically per PHB and reserved on demand in all nodes in the communication path from an Ingress node to an Egress node.
予約ベースの方法では、各内部ノードは、トラフィッククラスごとに1つの予約状態を維持します。入口エッジは、PHBのトラフィッククラスに集約個別流リクエストノード、および必要に応じてクラスの予約の変更を知らせます。予約は、リソースユニット（または帯域幅）の観点で定量化されます。これらのリソースは、PHBごとに動的に要求および出力ノードにIngressノードから通信経路内のすべてのノードで必要に応じて予約されています。
The measurement-based algorithm continuously measures traffic levels and the actual available resources, and admits flows whose resource needs are within what is available at the time of the request. The measurement-based algorithm is used to support a predictive service where the service commitment is somewhat less reliable than the service that can be supported by the reservation-based method.
測定ベースのアルゴリズムは、連続トラフィックレベルと実際の利用可能なリソースを測定し、そのリソースニーズリクエストの時点で利用可能なものの範囲内である流れる認めます。測定ベースのアルゴリズムは、サービスコミットメントは予約ベースの方法でサポートすることができるサービスよりも幾分少ない信頼性の高い予測サービスをサポートするために使用されます。
A main assumption that is made by such measurement-based admission control mechanisms is that the aggregated PHB traffic passing through an RMD Interior node is high and therefore, current measurement characteristics are considered to be an indicator of future load. Once an admission decision is made, no record of the decision need be kept at the Interior nodes. The advantage of measurement-based resource management protocols is that they do not require pre-reservation state nor explicit release of the reservations at the Interior nodes. Moreover, when the user traffic is variable, measurement-based admission control could provide higher network utilization than, e.g., peak-rate reservation. However, this can introduce an uncertainty in the availability of the resources. It is important to emphasize that the RMD measurement-based schemes described in this document do not use any refresh procedures, since these approaches are used in stateless nodes; see Section 4.6.1.3.
そのような測定ベースのアドミッション制御メカニズムによって行われる主な仮定はRMD内部ノードを通過する集約PHBトラフィックが高く、従って、現在の測定特性は、将来の負荷の指標であると考えられることです。入学の決定が行われると、意思決定のレコードは、インテリア・ノードで保持する必要はありません。測定ベースのリソース管理プロトコルの利点は、事前予約の状態でもインテリアノードでの予約の明示的な解放を必要としないということです。ユーザトラフィックが可変である場合また、測定ベースのアドミッション制御は、より高いネットワーク使用率、例えば、ピークレートの予約を提供することができます。しかし、これは、リソースの可用性における不確実性を導入することができます。これらのアプローチは、ステートレスのノードで使用されているので、この文書で説明RMD測定ベースのスキームは、任意のリフレッシュ手順を使用していないことを強調することが重要です。セクション4.6.1.3を参照してください。
Two types of measurement-based admission control schemes are possible:
測定ベースのアドミッション制御スキームの2種類が選択できます：
* Congestion notification function based on probing:
プロービングに基づく*輻輳通知機能：
This method can be used to implement a simple measurement-based admission control within a Diffserv domain. In this scenario, the Interior nodes are not NSIS-aware nodes. In these Interior nodes, thresholds are set for the traffic belonging to different PHBs in the measurement-based admission control function. In this scenario, an end-to-end NSIS message is used as a probe packet, meaning that the <DSCP> field in the header of the IP packet that carries the NSIS message is re-marked when the predefined congestion threshold is exceeded. Note that when the predefined congestion threshold is exceeded, all packets are re-marked by a node, including NSIS messages. In this way, the Edges can admit or reject flows that are requesting resources. The frequency and duration that the congestion level is above the threshold resulting in re-marking is tracked and used to influence the admission control decisions.
この方法は、Diffservのドメイン内の単純な測定ベースのアドミッション制御を実施するために使用することができます。このシナリオでは、インテリアノードはNSISに対応していないノードがあります。これらの内部ノードでは、閾値は、測定ベースのアドミッション制御機能に別のPHBに属するトラフィックのために設定されています。このシナリオでは、エンドツーエンドのNSISメッセージは、あらかじめ定義された輻輳閾値を超えたときNSISメッセージを運ぶIPパケットのヘッダに<DSCP>フィールドが再マークされていることを意味し、プローブパケットとして使用されます。事前に定義された輻輳しきい値を超えた場合、すべてのパケットがNSISメッセージを含む、ノードによって再マークされていることに注意してください。このように、エッジは、リソースを要求されたフローを認めるか拒否することができます。輻輳レベルは、再マーキングをもたらす閾値以上であること周波数および持続時間を追跡し、アドミッション制御の決定に影響を与えるために使用されます。
* NSIS measurement-based admission control:
* NSIS測定ベースのアドミッションコントロール：
In this case, the measurement-based admission control functionality is implemented in NSIS-aware stateless routers. The main difference between this type of admission control and the congestion notification based on probing is related to the fact that this type of admission control is applied mainly on NSIS-aware nodes. With the measurement-based scheme, the requested peak bandwidth of a flow is carried by the admission control request. The admission decision is considered as positive if the currently carried traffic, as characterized by the measured statistics, plus the requested resources for the new flow exceeds the system capacity with a probability smaller than a value alpha. Otherwise, the admission decision is negative. It is important to emphasize that due to the fact that the RMD Interior nodes are stateless, they do not store information of previous admission control requests.
この場合には、測定ベースのアドミッション制御機能はNSIS対応ステートレスルータに実装されています。プローブに基づくアドミッション制御のこのタイプおよび輻輳通知の主な違いは、アドミッション制御のこのタイプは、NSIS対応ノードに主に適用されるという事実に関連しています。測定ベースのスキームでは、フローの要求されたピーク帯域幅は、受付制御要求によって運ばれます。現在実施し、トラフィック場合は入場の決定が陽性と判断され、新しいフローのために測定された統計情報に加え、要求されたリソースによって特徴付けられるように値アルファよりも小さい確率でシステム容量を超えています。そうでない場合は、入学決定が否定的です。原因RMDインテリアノードはステートレスであるという事実に、彼らは以前のアドミッション制御要求の情報を格納しないことを強調することが重要です。
This could lead to a situation where the admission control accuracy is decreased when multiple simultaneous flows (sharing a common Interior node) are requesting admission control simultaneously. By applying measuring techniques, e.g., see [JaSh97] and [GrTs03], which use current and past information on NSIS sessions that requested resources from an NSIS-aware Interior node, the decrease in admission control accuracy can be limited. RMD describes the following procedures:
これは、（共通の内部ノードを共有する）複数の同時の流れを同時に許可制御を要求しているときにアドミッション制御精度が低下する事態につながる可能性があります。測定技術を適用することにより、例えば、[JaSh97]参照[GrTs03]、NSIS認識インテリアノードからリソースを要求されたNSISセッションの現在と過去の情報を使用した、アドミッション制御精度の低下を制限することができます。 RMDは、次の手順について説明します。
* classification of an individual resource reservation or a resource query into Per-Hop Behavior (PHB) groups at the Ingress node of the domain,
ドメインの入口ノードにおけるホップ単位動作（PHB）グループに個々のリソース予約やリソースクエリの*分類
* hop-by-hop admission control based on a PHB within the domain. There are two possible modes of operation for internal nodes to admit requests. One mode is the stateless or measurement-based mode, where the resources within the domain are queried. Another mode of operation is the reduced-state reservation or reservation-based mode, where the resources within the domain are reserved.
*ドメイン内のPHBに基づいてホップバイホップのアドミッション制御。要求を認める内部ノードのための二つの動作可能なモードがあります。一つのモードは、ドメイン内のリソースを照会するステートレスまたは測定ベースモードです。別の動作モードは、ドメイン内のリソースが予約されている縮小状態の予約または予約ベースモードです。
* a method to forward the original requests across the domain up to the Egress node and beyond.
Egressノードまでの枠を越えて、ドメイン全体にオリジナルの要求を転送する*方法。
* a congestion-control algorithm that notifies the Egress Edge nodes about congestion. It is able to terminate the appropriate number of flows in the case a of congestion due to a sudden failure (e.g., link or router failure) within the domain.
*混雑についての出口エッジノードに通知輻輳制御アルゴリズム。ドメイン内の突然の障害（例えば、リンクまたはルータの障害）に、輻輳の場合にフローの適切な数を終了することができます。
The protocol model of the RMD-QOSM is shown in Figure 2. The figure shows QoS NSIS initiator (QNI) and QoS NSIS Receiver (QNR) nodes, not part of the RMD network, that are the ultimate initiator and receiver of the QoS reservation requests. It also shows QNE nodes that are the Ingress and Egress nodes in the RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are Interior nodes (QNE Interior).
RMD-QOSMのプロトコルモデル図は、QoS予約の最終的なイニシエータと受信されたQoS NSIS開始剤（QNI）およびQoS NSISレシーバ（QNR）ノード、RMDネットワークの一部ではないが、示している。図2に示されています。リクエスト。また、RMDドメイン（QNE進入及び退出QNE）における入力および出力ノードであるQNEノード、及び内部ノード（QNEインテリア）であるQNEノードを示しています。
All nodes of the RMD domain are usually QoS-NSLP-aware nodes. However, in the scenarios where the congestion notification function based on probing is used, then the Interior nodes are not NSIS aware. Edge nodes store and maintain QoS-NSLP and NTLP states and therefore are stateful nodes. The NSIS-aware Interior nodes are NTLP stateless. Furthermore, they are either QoS-NSLP stateless (for NSIS measurement-based operation) or reduced-state nodes storing per PHB aggregated QoS-NSLP states (for reservation-based operation).
RMDドメインのすべてのノードは、通常のQoS-NSLP認識ノードです。しかしながら、プローブに基づく輻輳通知機能を使用するシナリオでは、内部ノードはNSIS気づいていません。エッジノードストアとQoS-NSLPとNTLP状態を維持し、したがって、ステートフル・ノードです。 NSIS認識インテリアノードはNTLPステートレスです。さらに、それらは、（NSIS測定に基づく動作用）のQoS-NSLPのステートレスまたはPHBごと（予約ベースの動作のための）集約のQoS-NSLP状態を格納低減状態ノードです。
Note that the RMD domain MAY contain Interior nodes that are not NSIS-aware nodes (not shown in the figure).
RMDドメインはNSISを意識したノード（図には示されていない）ではないインテリア・ノードが含まれているかもしれないことに注意してください。
These nodes are assumed to have sufficient capacity for flows that might be admitted. Furthermore, some of these NSIS-unaware nodes MAY be used for measuring the traffic congestion level on the data path. These measurements can be used by RMD-QOSM in the congestion control based on probing operation and/or severe congestion operation (see Section 4.6.1.6).
これらのノードが入院される可能性がありますフローのための十分な容量を有するものとします。さらに、これらのNSIS非対応ノードの一部は、データパス上の交通渋滞のレベルを測定するために使用され得ます。これらの測定は、（セクション4.6.1.6参照）を操作および/または重度の輻輳動作をプローブに基づく輻輳制御にRMD-QOSMで使用することができます。
|------| |-------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QoS | | QoS | | QoS | | QoS |
| | |-------| |------| |------|
| | |-------| |-------| |-------| |------| | |
| | | local |<->| local |<->| local |<->| local| | |
| | | QoS | | QoS | | QoS | | QoS | | |
| | | | | | | | | | | |
| NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP |
|st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful|
| | | | |red.st.| |red.st.| | | | |
| | |-------| |-------| |-------| |------| | |
|------| |-------| |-------| |-------| |------| |------|
------------------------------------------------------------------
|------| |-------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
|------| |-------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress) (Interior) (Interior) (Egress) (End)
st.ful: stateful, st.less: stateless
st.less red.st.: stateless or reduced-state
Figure 2: Protocol model of stateless/reduced-state operation
図2：ステートレス/縮小状態動作のプロトコルモデル
The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The signaling scenarios are accomplished using the QoS-NSLP processing rules defined in [RFC5974], in combination with the Resource Management Function (RMF) triggers sent via the QoS-NSLP-RMF API described in [RFC5974].
基本的なRMD-QOSM /のQoS-NSLPシグナリングは、リソース管理機能（RMF）との組み合わせでQoS-を介して送信トリガ、シグナリングシナリオは[RFC5974]で定義されたQoS-NSLP処理ルールを使用して達成され、図3に示します。 [RFC5974]で説明NSLP-RMFのAPI。
Due to the fact that within the RMD domain a QoS Model that is different than the end-to-end QoS Model applied at the Edges of the RMD domain can be supported, the RMD Interior node reduced-state reservations can be updated independently of the per-flow end-to-end reservations (see Section 4.7 of [RFC5974]). Therefore, two different RESERVE messages are used within the RMD domain. One RESERVE message that is associated with the per-flow end-to-end reservations and is used by the Edges of the RMD domain and one that is associated with the reduced-state reservations within the RMD domain.
RMDドメイン内のRMD領域のエッジに適用されるエンドツーエンドのQoSモデルは異なるQoSモデルをサポートすることができるという事実のために、RMDインテリアノード低減状態の予約は、独立に更新することができますフロー毎のエンドツーエンド予約（[RFC5974]のセクション4.7を参照）。したがって、2つの異なるRESERVEメッセージは、RMDのドメイン内で使用されています。フロー毎のエンドツーエンドの予約に関連付けられ、RMDドメイン内低減状態の予約に関連付けられているRMDドメインと一つの縁部によって使用されるものRESERVEメッセージ。
A RESERVE message is created by a QNI with an Initiator QSPEC describing the reservation and forwarded along the path towards the QNR.
RESERVEメッセージは、予約を説明イニシエータQSPECとQNIにより作成されQNRに向かって経路に沿って転送されます。
When the original RESERVE message arrives at the Ingress node, an RMD-QSPEC is constructed based on the initial QSPEC in the message (usually the Initiator QSPEC). The RMD-QSPEC is sent in a intra-domain, independent RESERVE message through the Interior nodes towards the QNR. This intra-domain RESERVE message uses the GIST datagram signaling mechanism. Note that the RMD-QOSM cannot directly specify that the GIST Datagram mode SHOULD be used. This can however be notified by using the GIST API Transfer-Attributes, such as unreliable, low level of security and use of local policy.
元のRESERVEメッセージが入口ノードに到着すると、RMD-QSPECは、メッセージに初期QSPEC（通常イニシエータQSPEC）に基づいて構築されています。 RMD-QSPECがドメイン内で送信され、内部を通って独立RESERVEメッセージはQNR向かっノード。このドメイン内RESERVEメッセージは、GISTデータグラムのシグナリングメカニズムを使用しています。 RMD-QOSMが直接GISTデータグラムモードを使用するように指定できないことに注意してください。しかし、これは、このようなローカルポリシーのセキュリティと使用の信頼性が低い、低レベルとしてGISTのAPI転送-属性を使用して通知することができます。
Meanwhile, the original RESERVE message is sent to the Egress node on the path to the QNR using the reliable transport mode of NTLP. Each QoS-NSLP node on the data path processes the intra-domain RESERVE message and checks the availability of resources with either the reservation-based or the measurement-based method.
一方、元のRESERVEメッセージはNTLPの信頼性の高いトランスポートモードを使用してQNRへのパス上の出力ノードに送信されます。データパス上の各QoS-NSLPノードがドメイン内RESERVEメッセージを処理し、予約ベースまたは測定に基づく方法のいずれかで、リソースの利用可能性をチェックします。
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE'|
|<---------------------------------------------+
| | | | RESERVE
| | | +------->
| | | |RESPONSE
| | | |<-------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 3: Sender-initiated reservation with reduced-state Interior nodes
図3：低減状態インテリアノードと送信者が開始する予約
When the message reaches the Egress node, and the reservation is successful in each Interior node, an intra-domain (local) RESPONSE' is sent towards the Ingress node and the original (end-to-end) RESERVE message is forwarded to the next domain. When the Egress node receives a RESPONSE message from the downstream end, it is forwarded directly to the Ingress node.
メッセージが出口ノードに到達し、予約が各内部ノードに成功した場合、ドメイン内（ローカル）RESPONSE」はIngressノードに向けて送信され、元の（エンドツーエンド）RESERVEメッセージは、次に転送されますドメイン。出口ノードが下流端からの応答メッセージを受信すると、それはIngressノードへ直接転送されます。
If an intermediate node cannot accommodate the new request, it indicates this by marking a single bit in the message, and continues forwarding the message until the Egress node is reached. From the Egress node, an intra-domain RESPONSE' and an original RESPONSE message are sent directly to the Ingress node.
中間ノードが新しい要求に対応できない場合は、メッセージ内の単一ビットをマーキングすることによって、これを示し、および出力ノードに到達するまで、メッセージを転送し続けます。 Egressノードから、ドメイン内RESPONSE」と元の応答メッセージはIngressノードに直接送信されます。
As a consequence, in the stateless/reduced-state domain only sender-initiated reservations can be performed and functions requiring per-flow NTLP or QoS-NSLP states, like summary and reduced refreshes, cannot be used. If per-flow identification is needed, i.e., associating the flow IDs for the reserved resources, Edge nodes act on behalf of Interior nodes.
その結果、ステートレス/縮小状態の領域でのみ、送信者によって開始予約を行うことができ、要約及び減少リフレッシュのようなフローごとのNTLPまたはQoS-NSLP状態を、必要とする機能は、使用することができません。フロー毎の識別が必要な場合、すなわち、予約されたリソースのためにフローIDを関連付ける、エッジノードは、内部ノードに代わって行動します。
The RMD-QOSM is a Diffserv-based bandwidth management methodology that is not able to provide a full Diffserv support. The reason for this is that the RMD-QOSM concept can only support the (Expedited Forwarding) EF-like functionality behavior, but is not able to support the full set of (Assured Forwarding) AF-like functionality. The bandwidth information REQUIRED by the EF-like functionality behavior can be supported by RMD-QOSM carrying the bandwidth information in the <QoS Desired> parameter (see [RFC5975]). The full set of (Assured Forwarding) AF-like functionality requires information that is specified in two token buckets. The RMD-QOSM is not supporting the use of two token buckets and therefore, it is not able to support the full set of AF-functionality. Note however, that RMD-QOSM could also support a single AF PHB, when the traffic or the upper limit of the traffic can be characterized by a single bandwidth parameter. Moreover, it is considered that in case of tunneling, the RMD-QOSM supports only the uniform tunneling mode for Diffserv (see [RFC2983]).
RMD-QOSMはフルDiffservのサポートを提供することができないのDiffservベースの帯域幅管理の方法論です。この理由は、RMD-QOSMコンセプトのみ（緊急転送）EF-ような機能の動作をサポートしていますが、（保証転送）AFのような機能のフルセットをサポートすることができないということです。 EFのような機能の動作によって必要とされる帯域幅情報は<QoSが希望>パラメータ（[RFC5975]を参照）に帯域情報を搬送RMD-QOSMによって支持することができます。 （保証転送）AFのような機能のフルセットは、二つのトークンバケットに指定された情報を必要とします。 RMD-QOSMは、二つのトークンバケットの使用を支持していないため、AF-機能のフルセットをサポートすることができません。トラフィックまたはトラフィックの上限は、単一の帯域幅パラメータによって特徴付けることができる場合RMD-QOSMはまた、単一のAF PHBをサポートできることが留意されたいです。また、それはトンネルの場合には、RMD-QOSMはDiffservのための唯一の均一なトンネリングモードをサポートすると考えられている（[RFC2983]を参照）。
The RMD domain MUST be engineered in such a way that each QNE Ingress maintains information about the smallest MTU that is supported on the links within the RMD domain.
RMDドメインは、それぞれQNEイングレスは、RMDドメイン内のリンクでサポートされている最小のMTUに関する情報を保持するように設計されなければなりません。
A very important consideration on using RMD-QOSM is that within one RMD domain only one of the following RMD-QOSM schemes can be used at a time. Thus, an RMD router can never process and use two different RMD-QOSM signaling schemes at the same time.
RMD-QOSMを使用しての非常に重要な考慮事項は、次のRMD-QOSMスキームの1つのRMDドメイン内の一つだけが一度に使用することができるということです。このように、RMDルータは、同時に2つの異なるRMD-QOSM信号方式を処理しないと使用できません。
However, all RMD QNEs supporting this specification MUST support the combination of the "per-flow RMD reservation-based" and the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container" (Section
しかし、この仕様をサポートするすべてのRMDのQNEsは、「フローごとのRMD予約・ベース」との方式を「マーキング比例データパケットによって深刻な輻輳処理」の組み合わせをサポートしなければなりません。 RMDのQNEsがよりRMD-QOSM方式をサポートしている場合、そのRMDドメインのオペレータは、一つのドメイン（<SCH>フィールドが「PHR容器」内に含まれるように、セクション内のすべてのQNEエッジノードを事前に設定しなければなりません
4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes is used at a time.
4.1.2）と「PDRコンテナ」（4.1.3項）は常に、以下に説明RMD-QOSM方式の一つRMDドメイン内の一方のみが一度に使用されるように同じ値を使用します。
The congestion situations (see Section 2) are solved using an admission control mechanism, e.g., "per-flow congestion notification based on probing", while the severe congestion situations (see Section 2), are solved using the severe congestion handling mechanisms, e.g., "severe congestion handling by proportional data packet marking".
重度の輻輳状況は（セクション2を参照）しながら、輻輳状況（セクション2を参照）、例えば、重度の輻輳処理メカニズムを使用して解決される、例えば、「フローごとの輻輳通知プロービングに基づく」、アドミッション制御メカニズムを使用して解決されます、「マーキング比例データパケットによって深刻な輻輳処理」。
The RMD domain MUST be engineered in such a way that RMD-QOSM messages could be transported using the GIST Query and DATA messages in Q-mode; see [RFC5971]. This means that the Path MTU MUST be engineered in such a way that the RMD-QOSM message are transported without fragmentation. Furthermore, the RMD domain MUST be engineered in such a way to guarantee capacity for the GIST Query and Data messages in Q-mode, within the rate control limits imposed by GIST; see [RFC5971].
RMDドメインは、RMD-QOSMメッセージがQモードでGISTクエリとデータメッセージを使用して輸送することができように設計されなければなりません。 [RFC5971]を参照してください。これは、パスMTUがRMD-QOSMメッセージが断片化することなく搬送されるように操作されなければならないことを意味します。また、RMDドメインはGISTによって課されるレート制御限界内で、QモードでGISTクエリおよびデータメッセージの容量を保証するように操作されなければなりません。 [RFC5971]を参照してください。
The RMD domain has to be configured such that the GIST context-free flag (C-flag) MUST be set (C=1) for QUERY messages and DATA messages sent in Q-mode; see [RFC5971].
RMDドメインはGISTの文脈自由フラグ（Cフラグ）はQモードで送信されたクエリーメッセージとデータメッセージのために（C = 1）に設定しなければならないように構成されなければなりません。 [RFC5971]を参照してください。
Moreover, the same deployment issues and extensibility considerations described in [RFC5971] and [RFC5978] apply to this document.
また、[RFC5971]及び[RFC5978]で説明したのと同じ配置の問題と拡張性の考慮事項は、この文書に適用されます。
It is important to note that the concepts described in Sections 4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2, and 4.6.2.5.2 contributed to the PCN WG standardization.
概念は、セクション4.6.1.6.2、4.6.2.5.2、4.6.1.6.2に記載されており、4.6.2.5.2はPCN WGの標準化に貢献していることに注意することが重要です。
The available RMD-QOSM/QoS-NSLP signaling schemes are:
利用可能RMD-QOSM / QoSの-NSLP信号方式は以下のとおりです。
* "per-flow congestion notification based on probing" (see Sections 4.3.2, 4.6.1.7, and 4.6.2.6). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the Interior nodes are considered to be Diffserv aware, but NSIS-unaware nodes (see Section 4.3.2).
*「フローごとの輻輳通知のプロービングに基づく」（セクション4.3.2、4.6.1.7、および4.6.2.6を参照）。この方式は、重度輻輳処理のために、使用することに注意してください、「比例データパケットマーキングにより、深刻な輻輳処理は、」（セクション4.6.1.6.2と4.6.2.5.2を参照します）。さらに、内部ノードはDiffServ認識していると考えられるが、NSIS非対応ノード（4.3.2項を参照してください）。
* "per-flow RMD NSIS measurement-based admission control" (see Sections 4.3.2, 4.6.1, and 4.6.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the Interior nodes are considered to be NSIS-aware nodes (see Section 4.3.2).
*「フロー毎RMD NSIS測定ベースのアドミッション制御」（セクション4.3.2、4.6.1および4.6.2を参照されたいです）。この方式は、重度輻輳処理のために、使用することに注意してください、「比例データパケットマーキングにより、深刻な輻輳処理は、」（セクション4.6.1.6.2と4.6.2.5.2を参照します）。また、内部ノードはNSIS認識ノード（セクション4.3.2を参照）であると考えられます。
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1 and 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the Edge nodes are per-flow sessions (see Section 4.3.3).
*「フローごとのRMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで（セクション4.3.3、4.6.1、4.6.1.6.1、及び4.6.2.5.1を参照してください） 。この方式は、手順「RMD-QOSMリフレッシュによって深刻な輻輳処理」、深刻な輻輳処理のために、使用することに注意してください（セクション4.6.1.6.1と4.6.2.5.1を参照）。また、エッジノードによってサポートされているドメイン内のセッションは、フロー毎のセッション（セクション4.3.3を参照）です。
* "per-flow RMD reservation-based" in combination with the "severe the congestion handling by proportional data packet marking" procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the Edge nodes are per-flow sessions (see Section 4.3.3).
*「フロー毎RMD予約ベースの」手順「をマーキング比例データパケットによって重度輻輳処理」と組み合わせて（セクション4.3.3、4.6.1、4.6.1.6.2、及び4.6.2.5.2を参照のこと） 。この方式は、重度輻輳処理のために、使用することに注意してください、手順を「マーキング比例データパケットによって深刻な輻輳処理は、」（セクション4.6.1.6.2と4.6.2.5.2を参照します）。また、エッジノードによってサポートされているドメイン内のセッションは、フロー毎のセッション（セクション4.3.3を参照）です。
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1 and 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the Edge nodes are per-aggregate sessions (see Section 4.3.1). Moreover, this scheme can be considered to be a reservation-based scheme, since the RMD Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states.
*「ごとの集計RMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで（セクション4.3.1、4.6.1、4.6.1.6.1、及び4.6.2.5.1を参照してください） 。この方式は、手順「RMD-QOSMリフレッシュによって深刻な輻輳処理」、深刻な輻輳処理のために、使用することに注意してください（セクション4.6.1.6.1と4.6.2.5.1を参照）。また、エッジノードによってサポートされているドメイン内のセッションごとの集計セッション（セクション4.3.1を参照）です。また、この方式はRMDインテリアノードが低減状態ノードであるので、すなわち、それらはNTLP / GISTの状態を記憶していないが、彼らはPHB凝集のQoS-NSLPの予約状態ごとに記憶するか、予約ベースの方式であると考えることができます。
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the Edge nodes are per-aggregate sessions (see Section 4.3.1). Moreover, this scheme can be considered to be a reservation-based scheme, since the RMD Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states.
*「ごと集約RMD予約ベースの」手順「をマーキング比例データパケットによって重度輻輳処理」と組み合わせて（セクション4.3.1、4.6.1、4.6.1.6.2、及び4.6.2.5.2参照）。この方式は、重度輻輳処理のために、使用することに注意してください、手順を「マーキング比例データパケットによって深刻な輻輳処理は、」（セクション4.6.1.6.2と4.6.2.5.2を参照します）。また、エッジノードによってサポートされているドメイン内のセッションごとの集計セッション（セクション4.3.1を参照）です。また、この方式はRMDインテリアノードが低減状態ノードであるので、すなわち、それらはNTLP / GISTの状態を記憶していないが、彼らはPHB凝集のQoS-NSLPの予約状態ごとに記憶するか、予約ベースの方式であると考えることができます。
This section describes the RMD-QOSM in more detail. In particular, it defines the role of stateless and reduced-state QNEs, the RMD-QOSM QSPEC Object, the format of the RMD-QOSM QoS-NSLP messages, and how QSPECs are processed and used in different protocol operations.
このセクションでは、より詳細にRMD-QOSMを説明しています。特に、それはステートレスと低減状態QNEsの役割を定義し、RMD-QOSM QSPECオブジェクト、RMD-QOSMのQoS-NSLPメッセージのフォーマット、及びどのQSPECsが処理され、異なるプロトコル操作に使用されています。
The RMD-QOSM uses the QSPEC format specified in [RFC5975]. The Initiator/Local QSPEC bit, i.e., <I> is set to "Local" (i.e., "1") and the <QSPEC Proc> is set as follows:
RMD-QOSMは[RFC5975]で指定QSPECフォーマットを使用します。イニシエータ/ローカルQSPECビット、すなわち、<I>が「ローカル」（すなわち、「1」）と<QSPEC PROC>に設定されている次のように設定されています。
* Message Sequence = 0: Sender initiated * Object combination = 0: <QoS Desired> for RESERVE and <QoS Reserved> for RESPONSE
応答のためのRESERVEのための<QoSが希望>と<QoSの予約>：*メッセージシーケンス= 0：送信者開始*オブジェクトの組み合わせ= 0
The <QSPEC Version> used by RMD-QOSM is the default version, i.e., "0", see [RFC5975]. The <QSPEC Type> value used by the RMD-QOSM is specified in [RFC5975] and is equal to "2". The <Traffic Handling Directives> contains the following fields:
<QSPEC版> RMD-QOSMによって使用される既定のバージョン、すなわち、 "0" である、[RFC5975]を参照。 RMD-QOSMによって使用される<QSPECタイプ>値は[RFC5975]で指定され、「2」に等しいです。 <トラフィック処理ディレクティブ>は、次のフィールドが含まれています。
<Traffic Handling Directives> = <PHR container> <PDR container>
<トラフィック処理ディレクティブ> = <PHRコンテナ> <PDRコンテナ>
The Per-Hop Reservation container (PHR container) and the Per-Domain Reservation container (PDR container) are specified in Sections 4.1.2 and 4.1.3, respectively. The <PHR container> contains the traffic handling directives for intra-domain communication and reservation. The <PDR container> contains additional traffic handling directives that are needed for edge-to-edge communication. The parameter IDs used by the <PHR container> and <PDR container> are assigned by IANA; see Section 6.
パーホップ予約容器（PHR容器）ごとのドメイン予約容器（PDR容器）は、それぞれ、セクション4.1.2及び4.1.3で指定されています。 <PHRコンテナは>ドメイン内のコミュニケーションや予約のためのトラフィック処理ディレクティブが含まれています。 <PDRコンテナは>エッジ間の通信のために必要な追加のトラフィック処理ディレクティブが含まれています。 <PHR容器>と<PDR容器>で使用するパラメータIDは、IANAによって割り当てられています。第6章を参照してください。
The RMD-QOSM <QoS Desired> and <QoS Reserved>, are specified in Section 4.1.1. The RMD-QOSM <QoS Desired> and <QoS Reserved> and the <PHR container> are used and processed by the Edge and Interior nodes. The <PDR container> field is only processed by Edge nodes.
RMD-QOSM <望ましいQoS>と<QoSの予約は>、4.1.1に規定されています。 RMD-QOSM <QoSの希望>と<QoSが確保>と<PHR容器は>エッジと内部ノードによって使用され処理されます。 <PDRコンテナ>フィールドは、エッジノードによって処理されます。
The RESERVE message contains only the <QoS Desired> object [RFC5975]. The <QoS Reserved> object is carried by the RESPONSE message.
RESERVEメッセージのみ<望ましいQoS>を含むオブジェクト[RFC5975]。 <QoSの予約>オブジェクトは、応答メッセージによって運ばれます。
In RMD-QOSM, the <QoS Desired> and <QoS Reserved> objects contain the following parameters:
RMD-QOSMでは、<QoSは希望>と<QoSが予約>オブジェクトは、次のパラメータが含まれています。
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority> <QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
<QoSの希望> = <TMOD-1> <PHBクラス> <入場優先順位> <QoSの予約> = <TMOD-1> <PHBクラス> <入場優先順位>
The bit format of the <PHB Class> (see [RFC5975] and Figures 4 and 5) and <Admission Priority> complies with the bit format specified in [RFC5975].
<PHBクラス>のビット・フォーマット（[RFC5975]を参照し、4及び5図）と<入場優先度は> [RFC5975]で指定されたビットフォーマットに準拠。
Note that for the RMD-QOSM, a reservation established without an <Admission Priority> parameter is equivalent to a reservation established with an <Admission Priority> whose value is 1.
RMD-QOSMため、<アドミッション優先>パラメータなしで確立された予約は、その値が1である<アドミッション優先>で確立予約と等価であることに留意されたいです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
Figure 4: DSCP parameter
図4：DSCPパラメータ
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID code |0 0 X X|
+---+---+---+---+---+---+---+---+
Figure 5: PHB ID Code parameter
図5：PHB IDコードパラメータ
This section describes the parameters used by the PHR container, which are used by the RMD-QOSM functionality available at the Interior nodes.
このセクションでは、内部ノードで利用可能なRMD-QOSM機能によって使用されるPHRコンテナによって使用されるパラメータを記述する。
<PHR container> = <O> <K> <S> <M>, <Admitted Hops>, <B> <Hop_U> <Time Lag> <SCH> <Max Admitted Hops>
<PHR容器> = <O> <K> <S> <M>、<是認ホップ>、<B> <Hop_U> <所要時間> <SCH> <最大ホップを認め>
The bit format of the PHR container can be seen in Figure 6. Note that in Figure 6 <Hop_U> is represented as <U>. Furthermore, in Figure 6, <Max Admitted Hops> is represented as <Max Adm Hops>.
PHR容器のビット・フォーマットは、図6の<Hop_U> <U>のように表される6。なお、図に見ることができます。また、図6において、<最大ホップを認め> <最大のAdmホップ>として表されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Admitted Hops|B|U| Time Lag |O|K| SCH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Adm Hops | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PHR container
図6：PHR容器
Parameter ID: 12-bit field, indicating the PHR type: PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.
パラメータID：12ビットのフィールドで、PHRのタイプを示す：PHR_Resource_Request、PHR_Release_Request、PHR_Refresh_Updateを。
"PHR_Resource_Request" (Parameter ID = 17): initiate or update the traffic class reservation state on all nodes located on the communication path between the QNE(Ingress) and QNE(Egress) nodes.
「PHR_Resource_Request」（パラメータID = 17）：開始またはQNE（入力）とQNE（出力）ノード間の通信経路上に位置するすべてのノードでトラフィッククラス予約状態を更新します。
"PHR_Release_Request" (Parameter ID = 18): explicitly release, by subtraction, the reserved resources for a particular flow from a traffic class reservation state.
「PHR_Release_Request」（パラメータID = 18）：明示的に解放する、減算することにより、トラフィッククラス予約状態から特定のフローのために予約されたリソース。
"PHR_Refresh_Update" (Parameter ID = 19): refresh the traffic class reservation soft state on all nodes located on the communication path between the QNE(Ingress) and QNE(Egress) nodes according to a resource reservation request that was successfully processed during a previous refresh period.
「PHR_Refresh_Update」（パラメータID = 19）：正常前中に処理されたリソース予約要求に従ってQNE（入力）とQNE（出力）との間の通信経路上に位置するすべてのノード上のトラフィッククラス予約柔らかい状態をリフレッシュするノードリフレッシュ期間。
<S> (Severe Congestion): 1 bit. In the case of a route change, refreshing RESERVE messages follow the new data path, and hence resources are requested there. If the resources are not sufficient to accommodate the new traffic, severe congestion occurs. Severe congested Interior nodes SHOULD notify Edge QNEs about the congestion by setting the <S> bit.
<S>（重度輻輳）：1ビット。ルート変更の場合には、さわやかなRESERVEメッセージは、新たなデータパスをたどる、ひいては資源があり、要求されています。リソースが新しいトラフィックに対応するのに十分でない場合は、深刻な輻輳が発生します。重度の輻輳インテリアノードは<S>ビットを設定することにより、輻輳約エッジQNEsを通知すべきです。
<O> (Overload): 1 bit. This field is used during the severe congestion handling scheme that is using the RMD-QOSM refresh procedure. This bit is set when an overload on a QNE Interior node is detected and when this field is carried by the "PHR_Refresh_Update" container. <O> SHOULD be set to"1" if the <S> bit is set. For more details, see Section 4.6.1.6.1.
<O>（過負荷）：1ビット。このフィールドは、RMD-QOSMリフレッシュ手順を使用している深刻な輻輳処理スキーム中に使用されます。 QNEインテリアノードの過負荷が検出された場合、このフィールドは「PHR_Refresh_Update」コンテナによって実行されるとき、このビットがセットされています。 <S>ビットが設定されている場合、<O>「1」に設定されるべきです。詳細については、セクション4.6.1.6.1を参照してください。
<M>: 1 bit. In the case of unsuccessful resource reservation or resource query in an Interior QNE, this QNE sets the <M> bit in order to notify the Egress QNE.
<M>：1ビット。インテリアQNEで失敗資源予約又はリソースクエリの場合、このQNEは、出力QNEを知らせるために、<M>ビットをセットします。
<Admitted Hops>: 8-bit field. The <Admitted Hops> counts the number of hops in the RMD domain where the reservation was successful. The <Admitted Hops> is set to "0" when a RESERVE message enters a domain and it MUST be incremented by each Interior QNE, provided that the <Hop_U> bit is not set. However, when a QNE that does not have sufficient resources to admit the reservation is reached, the <M> bit is set, and the <Admitted Hops> value is frozen, by setting the <Hop_U> bit to "1". Note that the <Admitted Hops> parameter in combination with the <Max Admitted Hops> and <K> parameters are used during the RMD partial release procedures (see Section 4.6.1.5.2).
<入所ホップ>：8ビットのフィールド。 <入所ホップ>予約が成功したRMDドメイン内のホップ数をカウントします。 <入所ホップ> RESERVEメッセージがドメインに入るときに「0」に設定され、それは各インテリアQNEだけ増分されなければならない、<Hop_U>ビットが設定されていないこと。提供しかし、予約を是認するのに十分なリソースを持っていないQNEに達したときに、<M>ビットがセットされ、そして<入所ホップ>値は「1」<Hop_U>ビットを設定することにより、凍結されます。 <入所ホップ>と組み合わせてパラメータ<最大ホップを認め>と<K>パラメータはRMD部分解放手順（セクション4.6.1.5.2参照）の間に使用されることに留意されたいです。
<Hop_U> (NSLP_Hops unset): 1 bit. The QNE(Ingress) node MUST set the <Hop_U> parameter to 0. This parameter SHOULD be set to "1" by a node when the node does not increase the <Admitted Hops> value. This is the case when an RMD-QOSM reservation-based node is not admitting the reservation request. When <Hop_U> is set to "1", the <Admitted
<Hop_U>（NSLP_Hops未設定）：1ビット。 QNE（入力）ノードを0に<Hop_U>パラメータを設定する必要があり、ノードが<入所ホップ>の値を増加させない場合、このパラメータは、ノードが「1」に設定されるべきです。これは、RMD-QOSM予約ベースノードは予約要求を認めていない場合です。 <Hop_U>「1」に設定されている場合は、<入所
Hops> SHOULD NOT be changed. Note that this flag, in combination with the <Admitted Hops> flag, are used to locate the last node that successfully processed a reservation request (see Section 4.6.1.2).
ホップ>は変更しないでください。このフラグは、<是認ホップ>フラグとの組み合わせで、正常予約要求（セクション4.6.1.2を参照）最後に処理ノードを見つけるために使用されることに留意されたいです。
<B>: 1 bit. When set to "1", it indicates a bidirectional reservation.
<B>：1ビット。 「1」に設定すると、それは双方向予約を示しています。
<Time Lag>: It represents the ratio between the "T_Lag" parameter, which is the time difference between the departure time of the last sent "PHR_Refresh_Update" control information container and the departure time of the "PHR_Release_Request" control information container, and the length of the refresh period, "T_period", see Section 4.6.1.5.
<所要時間>：これは、最後に送信された「PHR_Refresh_Update」情報コンテナと情報コンテナを制御「PHR_Release_Request」の出発時刻を制御し、の出発時刻との時間差である「T_Lag」パラメータとの比を表します。リフレッシュ期間の長さは、「T_period」、セクション4.6.1.5を参照してください。
<K>: 1 bit. When set to "1", it indicates that the resources/bandwidth carried by a tearing RESERVE MUST NOT be released, and the resources/bandwidth carried by a non-tearing RESERVE MUST NOT be reserved/refreshed. For more details, see Section 4.6.1.5.2.
<K>：1ビット。 「1」に設定すると、それは引き裂きRESERVEによって運ばれたリソース/帯域幅が解放されてはならない、と非引裂きRESERVEによって運ばれたリソース/帯域幅は/リフレッシュに予約されてはならないことを示しています。詳細については、セクション4.6.1.5.2を参照してください。
<Max Admitted Hops>: 8 bits. The <Admitted Hops> value that has been carried by the <PHR container> field used to identify the RMD reservation-based node that admitted or processed a "PHR_Resource_Request".
<最大ホップを認め>：8ビット。入院または「PHR_Resource_Request」処理RMD予約ベースノードを識別するために使用される<PHR容器>フィールドによって搬送された<是認ホップ>値。
<SCH>: 3 bits. The <SCH> value that is used to specify which of the 6 RMD-QOSM scenarios (see Section 3.2.3) MUST be used within the RMD domain. The operator of an RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container", will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes can be used at a time. All the QNE Interior nodes MUST interpret this field before processing any other PHR container payload fields. The currently defined <SCH> values are:
<SCH>：3ビット。 （セクション3.2.3参照）6 RMD-QOSMシナリオを指定するために使用される<SCH>値は、RMDのドメイン内で使用されなければなりません。 RMDドメインの演算子は常に同じ値、例えば、以下のいずれかのRMDドメイン内の一方のみが記載されたものが使用され、<SCH>フィールドが「PHRコンテナ」に含まれる、1つのドメイン内のすべてのQNEエッジノードを事前に設定しなければなりませんRMD-QOSM方式は、一度に使用することができます。すべてのQNEインテリア・ノードは、他のPHRのコンテナのペイロードフィールドを処理する前に、このフィールドを解釈する必要があります。現在定義されている<SCH>値は次のとおりです。
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
0：RMD-QOSM方式は、「プローブに基づくフローごとの輻輳通知」されなければなりません。
o 1: RMD-QOSM scheme MUST be "per-flow RMD NSIS measurement-based admission control",
O 1：RMD-QOSM方式は、 "フロー毎RMD NSIS測定ベースのアドミッション制御" でなければなりません、
o 2: RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
O 2：RMD-QOSM方式は、手順「RMD-QOSMリフレッシュによる重度輻輳処理」と組み合わせて「フロー毎RMD予約ベース」でなければなりません。
o 3 : RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
O 3：RMD-QOSM方式は、手順を「マーキング比例データパケットによって重度輻輳処理」と組み合わせて「フロー毎RMD予約ベース」でなければなりません。
o 4: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
O 4：RMD-QOSM方式は、手順「RMD-QOSMリフレッシュによる重度輻輳処理」と組み合わせて「当たり総計RMD予約ベース」でなければなりません。
o 5: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
O 5：RMD-QOSM方式は、手順を「マーキング比例データパケットによって重度輻輳処理」と組み合わせて「当たり総計RMD予約ベース」でなければなりません。
o 6 - 7: reserved.
O 6から7：予約済み。
The default value of the <SCH> field MUST be set to the value equal to 3.
<SCH>フィールドのデフォルト値は3に等しい値に設定しなければなりません。
This section describes the parameters of the PDR container, which are used by the RMD-QOSM functionality available at the Edge nodes.
このセクションでは、エッジノードで利用可能なRMD-QOSM機能によって使用されるPDR容器のパラメータを示します。
The bit format of the PDR container can be seen in Figure 7.
PDR容器のビット・フォーマットは、図7に見ることができます。
<PDR container> = <O> <S> <M> <Max Admitted Hops> <B> <SCH> [<PDR Bandwidth>]
<PDR容器> = <O> <S> <M> <マックスが許可ホップ> <B> <SCH> [<PDR帯域幅>]
In Figure 7, note that <Max Admitted Hops> is represented as <Max Adm Hops>.
図7に、<Maxはホップを認め>注<最大のAdmホップ>として表されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Max Adm Hops |B|O| SCH | EMPTY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDR Bandwidth(32-bit IEEE floating point.number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PDR container
図7：PDRコンテナ
Parameter ID: 12-bit field identifying the type of <PDR container> field.
パラメータID：<PDR容器>フィールドの種類を識別する12ビットフィールド。
"PDR_Reservation_Request" (Parameter ID = 20): generated by the QNE(Ingress) node in order to initiate or update the QoS-NSLP per-domain reservation state in the QNE(Egress) node.
「PDR_Reservation_Request」（パラメータID = 20）：QNE（出力）ノードにおけるQoS-NSLPあたりのドメインの予約状態を開始または更新するために、QNE（入力）ノードによって生成されます。
"PDR_Refresh_Request" (Parameter ID = 21): generated by the QNE(Ingress) node and sent to the QNE(Egress) node to refresh, in case needed, the QoS-NSLP per-domain reservation states located in the QNE(Egress) node.
「PDR_Refresh_Request」（パラメータID = 21）：QNEに位置QNE（入力）ノードによって生成された場合に必要で、リフレッシュするQNE（出力）ノードに送信されると、QoS-NSLPあたりドメイン予約状態（出力）ノード。
"PDR_Release_Request" (Parameter ID = 22): generated and sent by the QNE(Ingress) node to the QNE(Egress) node to release the per-domain reservation states explicitly.
「PDR_Release_Request」（パラメータID = 22）：生成され、明示的にドメインごとの予約状態を解放するQNE（出力）ノードにQNE（入力）ノードによって送信されます。
"PDR_Reservation_Report" (Parameter ID = 23): generated and sent by the QNE(Egress) node to the QNE(Ingress) node to report that a "PHR_Resource_Request" and a "PDR_Reservation_Request" traffic handling directive field have been received and that the request has been admitted or rejected.
「PDR_Reservation_Report」（パラメータID = 23）：生成され、「PHR_Resource_Request」および「PDR_Reservation_Request」トラフィック処理指示フィールドは、受信されたことを報告するQNE（入力）ノードにQNE（出力）ノードによって送信され、要求されました入院または拒否されています。
"PDR_Refresh_Report" (Parameter ID = 24) generated and sent by the QNE(Egress) node in case needed, to the QNE(Ingress) node to report that a "PHR_Refresh_Update" traffic handling directive field has been received and has been processed.
「PDR_Refresh_Report」（パラメータID = 24）が生成され、指示フィールドを取り扱う「PHR_Refresh_Update」トラフィックが受信され、処理されたことを報告しQNE（入力）ノードに、必要な場合にQNE（出力）ノードによって送信されます。
"PDR_Release_Report" (Parameter ID = 25) generated and sent by the QNE(Egress) node in case needed, to the QNE(Ingress) node to report that a "PHR_Release_Request" and a "PDR_Release_Request" traffic handling directive field have been received and have been processed.
「PDR_Release_Report」（パラメータID = 25）が生成され、「PHR_Release_Request」および「PDR_Release_Request」トラフィック処理指示フィールドは、受信されたことを報告するQNE（入力）ノードに、必要な場合にQNE（出力）ノードによって送信されたと処理されています。
"PDR_Congestion_Report" (Parameter ID = 26): generated and sent by the QNE(Egress) node to the QNE(Ingress) node and used for congestion notification.
「PDR_Congestion_Report」（パラメータID = 26）：生成され、QNE（入力）ノードにQNE（出力）ノードによって送信され、輻輳通知のために使用しました。
<S> (PDR Severe Congestion): 1 bit. Specifies if a severe congestion situation occurred. It can also carry the <S> parameter of the <PHR_Resource_Request> or <PHR_Refresh_Update> fields.
<S>（PDR厳しい混雑）：1ビット。厳しい混雑状況が発生したかどうかを指定します。また、<PHR_Resource_Request>または<PHR_Refresh_Update>フィールドの<S>パラメータを運ぶことができます。
<O> (Overload): 1 bit. This field is used during the severe congestion handling scheme that is using the RMD-QOSM refresh procedure. This bit is set when an overload on a QNE Interior node is detected and when this field is carried by the "PDR_Congestion_Report" container. <O> SHOULD be set to "1" if the <S> bit is set. For more details, see Section 4.6.1.6.1.
<O>（過負荷）：1ビット。このフィールドは、RMD-QOSMリフレッシュ手順を使用している深刻な輻輳処理スキーム中に使用されます。 QNEインテリアノードの過負荷が検出された場合、このフィールドは「PDR_Congestion_Report」コンテナによって実行されるとき、このビットがセットされています。 <S>ビットが設定されている場合、<O>「1」に設定されるべきです。詳細については、セクション4.6.1.6.1を参照してください。
<M> (PDR Marked): 1 bit. Carries the <M> value of the "PHR_Resource_Request" or "PHR_Refresh_Update" traffic handling directive field.
<M>（PDRマーク）：1ビット。 「PHR_Resource_Request」または「PHR_Refresh_Update」トラフィック処理ディレクティブフィールドの<M>の値を運びます。
<B>: 1 bit. Indicates bidirectional reservation.
<B>：1ビット。双方向予約を示します。
<Max Admitted Hops>: 8 bits. The <Admitted Hops> value that has been carried by the <PHR container> field used to identify the RMD reservation-based node that admitted or processed a "PHR_Resource_Request".
<最大ホップを認め>：8ビット。入院または「PHR_Resource_Request」処理RMD予約ベースノードを識別するために使用される<PHR容器>フィールドによって搬送された<是認ホップ>値。
<PDR Bandwidth>: 32 bits. This field specifies the bandwidth that either applies when the <B> flag is set to "1" and when this parameter is carried by a RESPONSE message or when a severe congestion occurs and the QNE Edges maintain an aggregated intra-domain QoS-NSLP operational state and it is carried by a NOTIFY message. In the situation that the <B> flag is set to "1", this parameter specifies the requested bandwidth that has to be reserved by a node in the reverse direction and when the intra-domain signaling procedures require a bidirectional reservation procedure. In the severe congestion situation, this parameter specifies the bandwidth that has to be released.
<PDR帯域幅>：32ビット。このフィールドは、<B>フラグが設定されている場合のいずれかが適用されること帯域幅を指定する「1」及びこのパラメータは、応答メッセージによって運ばれる、または重度の輻輳が発生したときにQNEエッジが凝集ドメイン内のQoS-NSLPが動作を維持された場合状態とそれがNOTIFYメッセージによって運ばれます。 <B>フラグが「1」に設定されている状況では、このパラメータは逆方向とするときドメイン内のシグナリング手順は、双方向予約の手順を必要にノードによって予約されなければならない要求された帯域幅を指定します。厳しい混雑状況では、このパラメータを解放する必要がある帯域幅を指定します。
<SCH>: 3 bits. The <SCH> value that is used to specify which of the 6 RMD scenarios (see Section 3.2.3) MUST be used within the RMD domain. The operator of an RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PDR container", will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes can be used at a time. All the QNE Interior nodes MUST interpret this field before processing any other <PDR container> payload fields. The currently defined <SCH> values are:
<SCH>：3ビット。 RMDドメイン内で使用しなければならない6つのRMDシナリオ（セクション3.2.3を参照）を指定するために使用される<SCH>値。 RMDドメインの演算子は常に同じ値、例えば、以下のいずれかのRMDドメイン内の一方のみが記載されたものが使用され、<SCH>フィールドは「PDRコンテナ」に含まれる、1つのドメイン内のすべてのQNEエッジノードを事前に設定しなければなりませんRMD-QOSM方式は、一度に使用することができます。すべてのQNEインテリアノードは、他の<PDRコンテナ>ペイロードフィールドを処理する前に、このフィールドを解釈する必要があります。現在定義されている<SCH>値は次のとおりです。
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
0：RMD-QOSM方式は、「プローブに基づくフローごとの輻輳通知」されなければなりません。
o 1: RMD-QOSM scheme MUST be "per-flow RMD NSIS measurement-based admission control";
O 1：RMD-QOSM方式は、「フロー毎RMD NSIS測定ベースのアドミッション制御」されなければなりません。
o 2: RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
O 2：RMD-QOSM方式は、手順「RMD-QOSMリフレッシュによる重度輻輳処理」と組み合わせて「フロー毎RMD予約ベース」でなければなりません。
o 3 : RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
O 3：RMD-QOSM方式は、手順を「マーキング比例データパケットによって重度輻輳処理」と組み合わせて「フロー毎RMD予約ベース」でなければなりません。
o 4: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
O 4：RMD-QOSM方式は、手順「RMD-QOSMリフレッシュによる重度輻輳処理」と組み合わせて「当たり総計RMD予約ベース」でなければなりません。
o 5: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
O 5：RMD-QOSM方式は、手順を「マーキング比例データパケットによって重度輻輳処理」と組み合わせて「当たり総計RMD予約ベース」でなければなりません。
o 6 - 7: reserved.
O 6から7：予約済み。
The default value of the <SCH> field MUST be set to the value equal to 3.
<SCH>フィールドのデフォルト値は3に等しい値に設定しなければなりません。
The format of the messages used by the RMD-QOSM complies with the QoS-NSLP and QSPEC template specifications. The QSPEC used by RMD-QOSM is denoted in this document as RMD-QSPEC and is described in Section 4.1.
RMD-QOSMで使用されるメッセージのフォーマットは、QoS-NSLPとQSPECテンプレートの仕様に準拠しています。 RMD-QOSMで使用QSPECはRMD-QSPECとして本書で示され、セクション4.1に記載されています。
The QoS-NSLP state creation and management is specified in [RFC5974]. This section describes the state creation and management functions of the Resource Management Function (RMF) in the RMD nodes.
QoSの-NSLP状態の作成と管理は、[RFC5974]で指定されています。このセクションでは、RMDノードにリソース管理機能（RMF）の状態の作成および管理機能について説明します。
The QNE Edges maintain both the intra-domain QoS-NSLP operational and reservation states, while the QNE Interior nodes maintain only reservation states. The structure of the intra-domain QoS-NSLP operational state used by the QNE Edges is specified in [RFC5974].
QNEインテリアノードのみ予約状態を維持しながら、QNEのエッジは、ドメイン内のQoS-NSLP運用および予約状態の両方を維持します。 QNEエッジによって使用されるドメイン内のQoS-NSLP動作状態の構造は、[RFC5974]で指定されています。
In this case, the intra-domain sessions supported by the Edges are per-aggregate sessions that have a one-to-many relationship to the per-flow end-to-end states supported by the same Edge.
この場合、エッジでサポートされているドメイン内のセッションは、同じエッジでサポートされているフローごとのエンド・ツー・エンドの状態に1対多の関係を持っているあたり、集約セッションです。
Note that the method of selecting the end-to-end sessions that form an aggregate is not specified in this document. An example of how this can be accomplished is by monitoring the GIST routing states used by the end-to-end sessions and grouping the ones that use the same <PHB Class>, QNE Ingress and QNE Egress addresses, and the value of the priority level. Note that this priority level should be deduced from the priority parameters carried by the initial QSPEC object.
凝集体を形成するエンドツーエンドのセッションを選択する方法は、この文書で指定されていないことに留意されたいです。これを達成することができる方法の例は、エンドツーエンドセッションで使用GISTルーティング状態を監視し、同じ<PHBクラス>、QNE進入及び退出QNEアドレスを使用するものをグループ化することで、優先度の値レベル。この優先度は、初期QSPECオブジェクトによって運ばれる優先パラメータから推定されるべきであることに留意されたいです。
The operational state of this aggregated intra-domain session MUST contain a list with BOUND-SESSION-IDs.
この集約されたドメイン内のセッションの動作状態がBOUND-SESSION-IDを持つリストを含まなければなりません。
The structure of the list depends on whether a unidirectional reservation or a bidirectional reservation is supported.
リストの構造は、単方向または双方向予約予約がサポートされているかどうかに依存します。
When the operational state (at QNE Ingress and QNE Egress) supports unidirectional reservations, then this state MUST contain a list with BOUND-SESSION-IDs maintaining the <SESSION-ID> values of its bound end-to-end sessions. The Binding_Code associated with this BOUND-
（QNE入力およびQNE出口で）運転状態が一方向の予約をサポートしている場合、この状態はBOUND-SESSION-IDがその結合エンド・ツー・エンドのセッションの<SESSION-ID>の値を維持してリストを含まなければなりません。これに関連しBinding_Code BOUND-
SESSION-ID is set to code (Aggregated sessions). Thus, the operational state maintains a list of BOUND-SESSION-ID entries. Each entry is created when an end-to-end session joins the aggregated intra-domain session and is removed when an end-to-end session leaves the aggregate.
セッションIDは、コード（アグリゲートされたセッション）に設定されています。このように、動作状態がBOUND-SESSION-IDエントリのリストを保持します。エンドツーエンドのセッションが凝集ドメイン内のセッションに参加し、エンドツーエンドのセッションが凝集体を出るときに除去される場合、各エントリが作成されます。
It is important to emphasize that, in this case, the operational state (at QNE Ingress and QNE Egress) that is maintained by each end-to-end session bound to the aggregated intra-domain session MUST contain in the BOUND-SESSION-ID, the <SESSION-ID> value of the bound tunneled intra-domain (aggregate) session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Aggregated sessions).
なお、この場合には、凝集ドメイン内のセッションに結合した各エンド・ツー・エンドのセッションが維持される（QNE入力およびQNE出口で）動作状態がBOUND-SESSION-IDに含まれなければならないことを強調することは重要です結合トンネリングドメイン内（骨材）セッションの、<セッションID>値。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（アグリゲートされたセッション）に設定されています。
When the operational state (at QNE Ingress and QNE Egress) supports bidirectional reservations, the operational state MUST contain a list of BOUND-SESSION-ID sets. Each set contains two BOUND-SESSION-IDs. One of the BOUND-SESSION-IDs maintains the <SESSION-ID> value of one of bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Aggregated sessions). Another BOUND-SESSION-ID, within the same set entry, maintains the SESSION-ID of the bidirectional bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
（QNE入力およびQNE出口で）動作状態が双方向予約をサポートしている場合、動作状態がBOUND-SESSION-IDセットのリストを含まなければなりません。各セットは、2 BOUND-SESSION-IDが含まれています。 BOUND-SESSION-IDの一つは、バインドされたエンド・ツー・エンドのセッションの1の<SESSION-ID>の値を保持します。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（アグリゲートされたセッション）に設定されています。別BOUND-SESSION-IDは、同じセットのエントリーの中に、双方向バインドエンド・ツー・エンドのセッションのセッション-IDを維持します。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（双方向セッション）に設定されています。
Note that, in each set, a one-to-one relation exists between each BOUND-SESSION-ID with Binding_Code set to (Aggregate sessions) and each BOUND-SESSION-ID with Binding_Code set to (bidirectional sessions). Each set is created when an end-to-end session joins the aggregated operational state and is removed when an end-to-end session leaves the aggregated operational state.
各セットにおいて、1対1の関係がBinding_Code各BOUND-SESSION-IDとの間に存在することに留意されたい（集約セッション）に設定され、Binding_Code各BOUND-SESSION-IDは、（双方向セッション）に設定されます。エンドツーエンドのセッションが集約動作状態を結合し、エンドツーエンドのセッションが集約動作状態を出るときに除去される場合、各セットが作成されます。
It is important to emphasize that, in this case, the operational state (at QNE Ingress and QNE Egress) that is maintained by each end-to-end session bound to the aggregated intra-domain session it MUST contain two types of BOUND-SESSION-IDs. One is the BOUND-SESSION-ID that MUST contain the <SESSION-ID> value of the bound tunneled aggregated intra-domain session that is using the Binding_Code set to (Aggregated sessions). The other BOUND-SESSION-ID maintains the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
それはこの場合には、それを強調することは重要である、凝集ドメイン内のセッションに結合した各エンド・ツー・エンドのセッションによって維持される動作状態は、（QNE入力およびQNE出口で）、それは、結合したセッションの二つのタイプを含まなければなりません-Ids。一つは、（アグリゲートされたセッション）に設定Binding_Codeを使用して結合トンネリング凝集ドメイン内のセッションの<セッションID>値を含まなければならないBOUND-SESSION-IDです。他BOUND-SESSION-IDは、バインドされた双方向のエンドツーエンドのセッションのセッションIDを維持します。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（双方向セッション）に設定されています。
When the QNE Edges use aggregated QoS-NSLP reservation states, then the <PHB Class> value and the size of the aggregated reservation, e.g., reserved bandwidth, have to be maintained. Note that this type of aggregation is an edge-to-edge aggregation and is similar to the aggregation type specified in [RFC3175].
QNEエッジが凝集したQoS-NSLPの予約状態は、<PHBクラス>値と集約予約のサイズ、例えば、確保された帯域幅を使用するときに維持されなければなりません。凝集のこのタイプは、エッジ・ツー・エッジ集合であり、[RFC3175]で指定された集約型に類似していることに留意されたいです。
The size of the aggregated reservations needs to be greater or equal to the sum of bandwidth of the inter-domain (end-to-end) reservations/sessions it aggregates (e.g., see Section 1.4.4 of [RFC3175]).
集約の予約のサイズが大きいか、またはそれが凝集ドメイン間（エンド・ツー・エンド）予約/セッション（例えば、[RFC3175]のセクション1.4.4を参照）の帯域幅の和に等しくする必要があります。
A policy can be used to maintain the amount of REQUIRED bandwidth on a given aggregated reservation by taking into account the sum of the underlying inter-domain (end-to-end) reservations, while endeavoring to change reservation less frequently. This MAY require a trend analysis. If there is a significant probability that in the next interval of time the current aggregated reservation is exhausted, the Ingress router MUST predict the necessary bandwidth and request it. If the Ingress router has a significant amount of bandwidth reserved, but has very little probability of using it, the policy MAY predict the amount of bandwidth REQUIRED and release the excess. To increase or decrease the aggregate, the RMD modification procedures SHOULD be used (see Section 4.6.1.4).
ポリシーは、それほど頻繁に予約を変更するために努力しながら、口座に下層のドメイン間（エンド・ツー・エンド）予約の和をとることによって与えられる凝集予約に必要な帯域幅の量を維持するために使用することができます。これは、トレンド分析が必要な場合があります。次の時間間隔で、現在の集約予約が排出されることを大きな可能性がある場合には、入口ルータは、必要な帯域幅を予測し、それを要求しなければなりません。入口ルータが予約された帯域幅を大量に持っていますが、それを使用しての非常に少ない確率を持っている場合、ポリシーは必要な帯域幅の量を予測し、過剰分を解放することができます。凝集体を増加または減少させるために、RMD修正手順（セクション4.6.1.4を参照）が使用されるべきです。
The QNE Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states. These reservation states are maintained and refreshed in the same way as described in Section 4.3.3.
QNEインテリアノード、すなわち、それらはNTLP / GISTの状態を記憶していないが、彼らはPHB凝集のQoS-NSLPの予約状態ごとに記憶するか、低減状態ノードです。これらの予約状態は、セクション4.3.3で説明したのと同じ方法で維持され、更新されます。
The QNE Edges maintain per-flow intra-domain QoS-NSLP operational and reservation states that contain similar data structures as those described in Section 4.3.1. The main difference is associated with the different types of the used Message-Routing-Information (MRI) and the bound end-to-end sessions. The structure of the maintained BOUND-SESSION-IDs depends on whether a unidirectional reservation or a bidirectional reservation is supported.
QNEのエッジは、セクション4.3.1に記載されているものと同様のデータ構造を含むフローごとのドメイン内のQoS-NSLP運用および予約状態を維持します。主な違いは、使用するメッセージルーティング-情報（MRI）と結合したエンドツーエンドのセッションの異なるタイプに関連付けられています。維持BOUND-SESSION-IDの構造は、単方向または双方向予約の予約がサポートされているかどうかに依存します。
When unidirectional reservations are supported, the operational state associated with this per-flow intra-domain session MUST contain in the BOUND-SESSION-ID the <SESSION-ID> value of its bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions).
一方向の予約がサポートされている場合は、このフローごとのドメイン内のセッションに関連付けられた動作状態がBOUND-SESSION-IDにその結合のエンドツーエンドのセッションの<SESSION-ID>の値を含まなければなりません。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（トンネリングとエンドツーエンドセッション）に設定されています。
When bidirectional reservations are supported, the operational state (at QNE Ingress and QNE Egress) MUST contain two types of BOUND-SESSION-IDs. One is the BOUND-SESSION-ID that maintains the <SESSION-ID> value of the bound tunneled per-flow intra-domain session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions).
双方向予約がサポートされている場合、（QNE入力およびQNE退出時）の動作状態は、結合、セッションIDの二つのタイプを含まなければなりません。一つは、バインドされたトンネル化フローごとのドメイン内のセッションの<SESSION-ID>の値を維持しBOUND-SESSION-IDです。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（トンネリングとエンドツーエンドセッション）に設定されています。
The other BOUND-SESSION-ID maintains the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
他BOUND-SESSION-IDは、バインドされた双方向のエンドツーエンドのセッションのセッションIDを維持します。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（双方向セッション）に設定されています。
Furthermore, the QoS-NSLP reservation state maintains the <PHB Class> value, the value of the bandwidth requested by the end-to-end session bound to the intra-domain session, and the value of the priority level.
さらに、QoSの-NSLPの予約状況は、<PHBクラス>値、ドメイン内のセッションにバインドされたエンド・ツー・エンドのセッションによって要求された帯域幅の値、および優先順位の値を維持しています。
The measurement-based method can be classified in two schemes:
測定に基づく方法は、2つの方式に分類することができます。
* Congestion notification based on probing:
プロービングに基づく*輻輳通知：
In this scheme, the Interior nodes are Diffserv-aware but not NSIS-aware nodes. Each Interior node counts the bandwidth that is used by each PHB traffic class. This counter value is stored in an RMD_QOSM state. For each PHB traffic class, a predefined congestion notification threshold is set. The predefined congestion notification threshold is set according to an engineered bandwidth limitation based, e.g., on a Service Level Agreement or a capacity limitation of specific links. The threshold is usually less than the capacity limit, i.e., admission threshold, in order to avoid congestion due to the error of estimating the actual traffic load. The value of this threshold SHOULD be stored in another RMD_QOSM state.
この方式では、インテリア・ノードは、Diffservの認識が、NSISに対応していないノードがあります。各インテリアノードは、各PHBのトラフィッククラスによって使用される帯域幅をカウントします。このカウンタ値はRMD_QOSM状態で格納されています。各PHBトラフィッククラスに対して、あらかじめ定義された輻輳通知閾値が設定されています。事前定義された輻輳通知閾値は、サービスレベル契約または特定のリンクの容量限界に基づいて操作された帯域幅の制限、例えば、に応じて設定されます。閾値は、実際のトラフィック負荷を推定する誤差に起因する輻輳を回避するために、すなわち、受付閾値、容量限界よりも通常小さいです。このしきい値の値は別のRMD_QOSM状態で保存されるべきです。
In this scenario, an end-to-end NSIS message is used as a probe packet. In this case, the <DSCP> field of the GIST message is re-marked when the predefined congestion notification threshold is exceeded in an Interior node. It is required that the re-marking happens to all packets that belong to the congested PHB traffic class so that the probe can't pass the congested router without being re-marked. In this way, it is ensured that the end-to-end NSIS message passed through the node that is congested. This feature is very useful when flow-based ECMP (Equal Cost Multiple Path) routing is used to detect only flows that are passing through the congested node.
このシナリオでは、エンドツーエンドのNSISメッセージは、プローブパケットとして使用されます。事前定義された輻輳通知閾値は内部ノードに超えたときこの場合、GISTメッセージの<DSCP>フィールドは再びマークされます。プローブが再マークされずに混雑してルータを渡すことができないように再マーキングが輻輳PHBのトラフィッククラスに属するすべてのパケットに起こっていることが必要です。このようにして、エンド・ツー・エンドのNSISメッセージが輻輳しているノードを通過したことが保証されます。フローベースのECMP（等価コストマルチパス）ルーティングが輻輳したノードを通過しているだけの流れを検出するために使用される場合、この機能は非常に有用です。
* NSIS measurement-based admission control:
* NSIS測定ベースのアドミッションコントロール：
The measurement-based admission control is implemented in NSIS-aware stateless routers. Thus, the main difference between this type of the measurement-based admission control and the congestion notification-based admission control is the fact that the Interior nodes are NSIS-aware nodes. In particular, the QNE Interior nodes operating in NSIS measurement-based mode are QoS-NSLP stateless nodes, i.e., they do not support any QoS-NSLP or NTLP/GIST states. These measurement-based nodes store two RMD-QOSM states per PHR group. These states reflect the traffic conditions at the node and are not affected by QoS-NSLP signaling. One state stores the measured user traffic load associated with the PHR group and another state stores the maximum traffic load threshold that can be admitted per PHR group. When a measurement-based node receives a intra-domain RESERVE message, it compares the requested resources to the available resources (maximum allowed minus current load) for the requested PHR group. If there are insufficient resources, it sets the <M> bit in the RMD-QSPEC. No change to the RMD-QSPEC is made when there are sufficient resources.
測定ベースのアドミッション制御は、NSIS対応ステートレスルータに実装されています。したがって、測定ベースのアドミッション制御のこのタイプおよび輻輳通知ベースのアドミッション制御との間の主な違いは、内部ノードがNSIS対応ノードであるという事実です。具体的には、NSIS測定ベースモードで動作QNE内部ノードがQoS-NSLPステートレスノード、すなわちされ、それらは任意のQoS-NSLPまたはNTLP / GIST状態をサポートしていません。これらの測定に基づくノードはPHRグループごとに2つのRMD-QOSM状態を記憶します。これらの状態は、ノードでの交通状況を反映し、QoS-NSLPシグナリングの影響を受けません。一つの状態を格納PHRグループに関連付けられた測定されたユーザトラフィック負荷と別の状態を格納PHRグループごとに入院することができる最大トラフィック負荷しきい値。測定ベースのノードがドメイン内RESERVEメッセージを受信すると、要求されたPHRグループに対して利用可能なリソース（マイナス電流負荷許容最大値）に要求されたリソースを比較します。十分なリソースがある場合は、RMD-QSPECで<M>ビットをセットします。 RMD-QSPECへの変更なしには十分なリソースがある場合に行われません。
The QNE Edges maintain intra-domain QoS-NSLP operational and reservation states that contain similar data structures as described in Section 4.3.1.
QNEのエッジは、ドメイン内のQoS-NSLP 4.3.1項で説明したのと同様のデータ構造を含んで運用し、予約状態を維持します。
In this case, the intra-domain sessions supported by the Edges are per-flow sessions that have a one-to-one relationship to the per-flow end-to-end states supported by the same Edge.
この場合、エッジでサポートされているドメイン内のセッションは、同じエッジでサポートされているフローごとのエンド・ツー・エンドの状態に一対一の関係を持つフローごとのセッションです。
The QNE Interior nodes operating in reservation-based mode are QoS-NSLP reduced-state nodes, i.e., they do not store NTLP/GIST states but they do store per PHB-aggregated QoS-NSLP states.
QNEインテリアは、予約ベースのモードで動作するノード、すなわち、それらはNTLP / GISTの状態を記憶していないが、それらはPHB凝集のQoS-NSLP状態ごとに記憶するか、のQoS-NSLP低減状態ノードです。
The reservation-based PHR installs and maintains one reservation state per PHB, in all the nodes located in the communication path. This state is identified by the <PHB Class> value and it maintains the number of currently reserved resource units (or bandwidth). Thus, the QNE Ingress node signals only the resource units requested by each flow. These resource units, if admitted, are added to the currently reserved resources per PHB.
予約ベースのPHRは、通信経路に位置する全てのノードで、PHBごとに1つの予約状態をインストールし、維持します。この状態は、<PHBクラス>の値によって識別され、それが現在予約リソースユニット（または帯域幅）の数を維持します。したがって、QNE Ingressノード信号のみリソースユニットは、各フローによって要求されます。これらのリソースユニットは、認めた場合、PHBあたり現在予約リソースに追加されます。
For each PHB, a threshold is maintained that specifies the maximum number of resource units that can be reserved. This threshold could, for example, be statically configured.
各PHBのために、閾値が確保できるリソースユニットの最大数を指定するに維持されます。この閾値は、例えば、静的に構成することができます。
An example of how the admission control and its maintenance process occurs in the Interior nodes is described in Section 3 of [CsTa05].
アドミッションコントロールとそのメンテナンス処理が内部ノードで発生方法の例は、[CsTa05]のセクション3に記載されています。
The simplified concept that is used by the per-traffic class admission control process in the Interior nodes, is based on the following equation:
内部ノードに当たり、トラフィッククラスアドミッション制御プロセスによって使用される簡略化の概念は、以下の式に基づいています。
last + p <= T,
最後+ P <= T、
where p is the requested bandwidth rate, T is the admission threshold, which reflects the maximum traffic volume that can be admitted in the traffic class, and last is a counter that records the aggregated sum of the signaled bandwidth rates of previous admitted flows.
pは、要求された帯域幅レートであり、Tは、トラフィッククラスに入院することができる最大のトラフィック量を反映受付閾値、であり、そして最後は前の許可されたフローのシグナリング帯域幅レートの集合和を記録するカウンタです。
The PHB group reservation states maintained in the Interior nodes are soft states, which are refreshed by sending periodic refresh intra-domain RESERVE messages, which are initiated by the Ingress QNEs. If a refresh message corresponding to a number of reserved resource units (i.e., bandwidth) is not received, the aggregated reservation state is decreased in the next refresh period by the corresponding amount of resources that were not refreshed. The refresh period can be refined using a sliding window algorithm described in [RMD3].
インテリア・ノードで維持PHBグループ予約状態が進入QNEsによって開始され、定期的にリフレッシュドメイン内RESERVEメッセージを送信することにより更新され、ソフトの状態、です。予約されたリソースユニットの数に対応するリフレッシュメッセージ（すなわち、帯域幅）が受信されない場合、集約の予約状態がリフレッシュされなかったリソースの分だけ次のリフレッシュ期間で減少されます。リフレッシュ期間は、[RMD3]に記載のスライディングウィンドウアルゴリズムを使用して精製することができます。
The reserved resources for a particular flow can also be explicitly released from a PHB reservation state by means of a intra-domain RESERVE release/tear message, which is generated by the Ingress QNEs.
特定のフローのための予約されたリソースは、明示的進入QNEsによって生成されたドメイン内RESERVE放出/涙メッセージによってPHB予約状態から解除することができます。
The use of explicit release enables the instantaneous release of the resources regardless of the length of the refresh period. This allows a longer refresh period, which also reduces the number of periodic refresh messages.
明示的なリリースでの使用にかかわらず、リフレッシュ期間の長さの資源の瞬間解放を可能にします。これはまた、定期的なリフレッシュメッセージの数を減らし、より長いリフレッシュ周期を、ことができます。
Note that both in the case of measurement- and (per-flow and aggregated) RMD reservation-based methods, the way in which the maximum bandwidth thresholds are maintained is out of the specification of this document. However, when admission priorities are supported, the Maximum Allocation [RFC4125] or the Russian Dolls [RFC4127] bandwidth allocation models MAY be used. In this case, three types of priority traffic classes within the same PHB, e.g., Expedited Forwarding, can be differentiated. These three different priority traffic classes, which are associated with the same PHB, are denoted in this document as PHB_low_priority, PHB_normal_priority, and PHB_high_priority, and are identified by the <PHB Class> value and the priority value, which is carried in the <Admission Priority> RMD-QSPEC parameter.
両方の測定 - 及び（フローごとの凝集）RMD予約ベースの方法の場合には、最大帯域幅閾値が維持される方法は、このドキュメントの仕様外であることに留意されたいです。入場の優先順位がサポートされている場合しかし、最大割当[RFC4125]やロシアの人形は、[RFC4127]帯域幅割り当てモデルが使用されるかもしれません。この場合には、同じPHB内プライオリティトラフィッククラスの3つのタイプが、例えば、緊急転送は、区別することができます。同じPHBに関連付けられているこれらの三つの異なる優先順位トラフィッククラスは、PHB_low_priority、PHB_normal_priority、およびPHB_high_priorityとして、この文書で示され、そして<PHBクラス>値と優先順位の値によって識別され、<入場で運ばれます優先順位> RMD-QSPECパラメータ。
As mentioned in Section 1, the RMD-QOSM aims to support a number of additional requirements, e.g., Minimal impact on Interior node performance. Therefore, RMD-QOSM is designed to be very lightweight signaling with regard to the number of signaling message round trips and the amount of state established at involved signaling nodes with and without reduced state on QNEs. The actions allowed by a QNE Interior node are minimal (i.e., only those specified by the RMD-QOSM).
第1節で述べたように、RMD-QOSMは、例えば、内部ノードのパフォーマンスへの影響を最小限に抑える追加要件の数をサポートすることを目的とします。従って、RMD-QOSMは、シグナリングメッセージのラウンドトリップの数とを有するとQNEsに還元状態ずに関与するシグナルノードで確立状態の量に関して非常に軽量なシグナルであるように設計されています。 QNEインテリアノードによって許可されるアクションは最小である（すなわち、唯一RMD-QOSMによって指定されたもの）。
For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads. Moreover, RMD signaling is targeted towards intra-domain signaling only. Therefore, RMD-QOSM relies on the security and reliability support that is provided by the bound end-to-end session, which is running between the boundaries of the RMD domain (i.e., the RMD-QOSM QNE Edges), and the security provided by the D-mode. This implies the use of the Datagram Mode.
例えば、QNE入力およびQNE出口ノードのみが、特定のシグナリングメッセージを開始することを許可されています。 QNE内部ノードは、例えば、特定のシグナリングメッセージペイロードを修正することが許されます。また、RMDシグナリングは、ドメイン内のシグナリングのみを対象としています。したがって、RMD-QOSMはRMDドメインの境界（すなわち、RMD-QOSM QNEがエッジ）との間で実行されているバインドエンド・ツー・エンドのセッションによって提供されるセキュリティと信頼性の支持体上に依存しており、セキュリティが提供さDモードによる。これは、データグラムモードを使用することを意味します。
Therefore, the intra-domain messages used by the RMD-QOSM are intended to operate in the NTLP/GIST Datagram mode (see [RFC5971]). The NSLP functionality available in all RMD-QOSM-aware QoS-NSLP nodes requires the intra-domain GIST, via the QoS-NSLP RMF API see [RFC5974], to:
従って、RMD-QOSMによって使用されるドメイン内のメッセージは、（[RFC5971]を参照）NTLP / GISTデータグラムモードで動作するように意図されています。すべてのRMD-QOSMを意識したQoS-NSLPノードで利用可能なNSLP機能は、[RFC5974]、し参照のQoS-NSLP RMF APIを介して、ドメイン内のGISTが必要です。
* operate in unreliable mode. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API Transfer-Attributes.
*信頼できないモードで動作します。これは、API転送-属性経由のQoS-NSLP層からGIST層にこの要件を渡すことで満足することができます。
* not create a message association state. This requirement can be satisfied by a local policy, e.g., the QNE is configured to not create a message association state.
*メッセージの会合状態を作成していません。この要件は、ローカルポリシーによって満足することができ、例えば、QNEは、メッセージ関連の状態を作成しないように構成されています。
* not create any NTLP routing state by the Interior nodes. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API. However, between the QNE Egress and QNE Ingress routing states SHOULD be created that are associated with intra-domain sessions and that can be used for the communication of GIST Data messages sent by a QNE Egress directly to a QNE Ingress. This type of routing state associated with an intra-domain session can be generated and used in the following way:
*インテリアノードで状態をルーティング任意のNTLPを作成していません。これは、API経由でのQoS-NSLP層からGIST層にこの要件を渡すことで満足することができます。しかし、QNE出口とQNE進入間のルーティング状態は、ドメイン内のセッションに関連付けられており、それが直接QNE進入にQNE退出によって送信されたGISTデータメッセージの通信のために使用することができるが作成されるべきです。ドメイン内のセッションに関連付けられた状態をルーティングするこのタイプは、以下のように生成して使用することができます。
* When the QNE Ingress has to send an initial intra-domain RESERVE message, the QoS-NSLP sends this message by including, in the GIST API SendMessage primitive, the Unreliable and No security attributes. In order to optimize this procedure, the RMD domain MUST be engineered in such a way that GIST will piggyback this NSLP message on a GIST Query message. Furthermore, GIST sets the C-flag (C=1), see [RFC5971] and uses the Q-mode. The GIST functionality in each QNE Interior node will receive the GIST Query message and by using the RecvMessage GIST API primitive it will pass the intra-domain RESERVE message to the QoS-NSLP functionality. At the same time, the GIST functionality uses the Routing-State-Check boolean to find out if the QoS-NSLP needs to create a routing state. The QoS-NSLP sets this boolean to inform GIST to not create a routing state and to forward the GIST Query further downstream with the modified QoS-NSLP payload, which will include the modified intra-domain RESERVE message. The intra-domain RESERVE is sent in the same way up to the QNE Egress. The QNE Egress needs to create a routing state.
QNEイングレスは、初期ドメイン内RESERVEメッセージを送信するために持っている場合は*、QoSの-NSLPは、プリミティブGISTのAPIのSendMessageで、含めることにより、このメッセージを送信し、信頼できないとノーセキュリティ属性。この手順を最適化するために、RMDドメインは、GISTは、GISTクエリメッセージにこのNSLPメッセージをピギーバックするような方法で操作されなければなりません。さらに、GISTは、[RFC5971]を参照して、（C = 1）Cフラグをセットし、Qモードを使用します。各QNEインテリアノードにおけるGISTの機能は、GISTのクエリメッセージを受信すると、プリミティブRecvMessage GIST APIを使用することによって、それは、QoS-NSLP機能にドメイン内RESERVEメッセージを渡します。同時に、GISTの機能は、QoS-NSLPは、ルーティング状態を作成する必要があるかどうかを調べるにはルーティングステートチェックブール値を使用しています。 QoS-NSLPは、ルーティング状態を作成しないようにGISTを通知するために、修正ドメイン内RESERVEメッセージを含む修飾のQoS-NSLPペイロードとさらに下流GISTクエリを転送するためにこのブール値を設定します。ドメイン内RESERVEはQNE出口まで同じ方法で送信されます。 QNE出口は、ルーティング状態を作成する必要があります。
Therefore, at the same moment that the GIST functionality passes the intra-domain RESERVE message, via the GIST RecvMessage primitive, to the QoS-NSLP, the QoS-NSLP sets the Routing-State-Check boolean such that a routing state is created. The GIST creates the routing state using normal GIST procedures. After this phase, the QNE Ingress and QNE Egress have, for the particular session, routing states that can route traffic directly from QNE Ingress to QNE Egress and from QNE Egress to QNE Ingress. The routing state at the QNE Egress can be used by the QoS-NSLP and GIST to send an intra-domain RESPONSE or intra-domain NOTIFY directly to the QNE Ingress using GIST Data messages. Note that this routing state is refreshed using normal GIST procedures. Note that in the above description, it is considered that the QNE Ingress can piggyback the initial RESERVE (NSLP) message on the GIST Query message. If the piggybacking of this NSLP (initial RESERVE) message would not be possible on the GIST Query message, then the GIST Query message sent by the QNE Ingress node would not contain any NSLP data. This GIST Query message would only be processed by the QNE Egress to generate a routing state.
したがって、GIST機能は、QoS-NSLPに、プリミティブGIST RecvMessageを介して、ドメイン内RESERVEメッセージを渡すのと同じ瞬間に、QoSの-NSLPはルーティング状態が作成されるようにルーティングステートチェックブール値を設定します。 GISTは、通常GISTの手順を使用してルーティング状態を作り出します。この段階の後、QNE進入及び退出QNEはQNE出口へとQNE出口からQNEイングレスにQNE進入から直接ルーティングできるトラフィック状態をルーティングする、特定のセッションのために、持っています。 QNE出口でルーティング状態はドメイン内応答またはドメイン内にGISTデータメッセージを使用して、QNEイングレスに直接NOTIFY送信にQoS-NSLPおよびGISTで使用することができます。このルーティング状態が正常GISTの手順を使用して更新されることに留意されたいです。上記の説明では、QNE進入がGISTクエリメッセージに初期RESERVE（NSLP）メッセージをピギーバックすることができると考えられることに留意されたいです。このNSLP（初期RESERVE）メッセージのピギーバックがGISTクエリメッセージに可能ではない場合、QNE Ingressノードによって送信されたGIST Queryメッセージは、任意のNSLPデータが含まれないであろう。このGISTクエリメッセージは、ルーティング状態を生成するQNE退出によって処理されるであろう。
After the QNE Ingress is informed that the routing state at the QNE Egress is initiated, it would have to send the initial RESERVE message using similar procedures as for the situation that it would send an intra-domain RESERVE message that is not an initial RESERVE, see next bullet. This procedure is not efficient and therefore it is RECOMMENDED that the RMD domain MUST be engineered in such a way that the GIST protocol layer, which is processed on a QNE Ingress, will piggyback an initial RESERVE (NSLP) message on a GIST Query message that uses the Q-mode.
QNE進入がQNE出口でのルーティング状態が開始されたことを知らされた後、それが初期RESERVEないドメイン内RESERVEメッセージを送信し、状況の場合と同様の手順を使用して初期RESERVEメッセージを送信しなければなりません、次の項目を参照してください。この手順は、効率的ではないため、RMDドメインはQNE入力で処理されGISTプロトコル層は、GISTクエリメッセージに初期RESERVE（NSLP）メッセージをピギーバックするような方法で操作されなければならないことが推奨されQモードを使用しています。
* When the QNE Ingress needs to send an intra-domain RESERVE message that is not an initial RESERVE, then the QoS-NSLP sends this message by including in the GIST API SendMessage primitive such attributes that the use of the Datagram Mode is implied, e.g., the Unreliable attribute. Furthermore, the Local policy attribute is set such that GIST sends the intra-domain RESERVE message in a Q-mode even if there is a routing state at the QNE Ingress. In this way, the GIST functionality uses its local policy to send the intra-domain RESERVE message by piggybacking it on a GIST Data message and sending it in Q-mode even if there is a routing state for this session. The intra-domain RESERVE message is piggybacked on the GIST Data message that is forwarded and processed by the QNE Interior nodes up to the QNE Egress.
QNEイングレスは初期RESERVEないドメイン内RESERVEメッセージを送信する必要がある場合*、その後のQoS-NSLPは、例えば、データグラムモードを使用することが暗示されたGISTのAPIのSendMessage原始的な属性を含めることによって、このメッセージを送信します、信頼できない属性。さらに、ローカルポリシー属性は、GISTはQNE入口でのルーティングの状態がある場合でもQモードでは、ドメイン内のRESERVEメッセージを送信するように設定されています。このように、GISTの機能はGISTデータメッセージの上に便乗し、このセッションのルーティング状態がある場合でもQモードでそれを送信することにより、ドメイン内RESERVEメッセージを送信するために、ローカルポリシーを使用しています。ドメイン内RESERVEメッセージはQNEインテリアによって転送され処理されるGISTデータメッセージがQNE出口までのノードにピギーバックされます。
The transport of the original (end-to-end) RESERVE message is accomplished in the following way:
搬送元（エンドツーエンド）のRESERVEメッセージは、次のように達成されます。
At the QNE Ingress, the original (end-to-end) RESERVE message is forwarded but ignored by the stateless or reduced-state nodes, see Figure 3.
QNE入口で、元（エンドツーエンド）RESERVEメッセージは、図3を参照して、ステートレスまたは低減状態ノードによって転送が、無視されます。
The intermediate (Interior) nodes are bypassed using multiple levels of NSLPID values (see [RFC5974]). This is accomplished by marking the end-to-end RESERVE message, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value.
中間体（内部）ノードはNSLPID値の複数のレベルを使用してバイパスされる（[RFC5974]を参照）。これは、別のNSLPID所定値にQoS-NSLPデフォルトNSLPID値を変更する、すなわち、エンドツーエンドのRESERVEメッセージをマーキングすることによって達成されます。
The marking MUST be accomplished by the Ingress by modifying the QoS_NSLP default NSLPID value to a NSLPID predefined value. In this way, the Egress MUST stop this marking process by reassigning the QoS-NSLP default NSLPID value to the original (end-to-end) RESERVE message. Note that the assignment of these NSLPID values is a QoS-NSLP issue, which SHOULD be accomplished via IANA [RFC5974].
マーキングはNSLPID所定値にQoS_NSLPデフォルトNSLPID値を変更することにより、進入することによって達成されなければなりません。このように、出口は、元の（エンドツーエンド）RESERVEメッセージへのQoS-NSLPデフォルトNSLPID値を再割り当てすることにより、このマーキングプロセスを停止しなければなりません。これらNSLPID値の割り当てはIANA [RFC5974]を介して達成されるべきであるのQoS-NSLPの問題であることに留意されたいです。
Mainly, the Egress node discovery can be performed by using either the GIST discovery mechanism [RFC5971], manual configuration, or any other discovery technique. The addressing of signaling messages depends on which GIST transport mode is used. The RMD-QOSM/QoS-NSLP signaling messages that are processed only by the Edge nodes use the peer-peer addressing of the GIST Connection (C) mode.
主に、Egressノード発見は、GIST発見メカニズム[RFC5971]、手動設定、または任意の他の検出技術のいずれかを用いて行うことができます。シグナリングメッセージのアドレス指定は使用されているGISTの輸送モードに依存します。エッジノードによってのみ処理されるRMD-QOSM /のQoS-NSLPシグナリングメッセージは、GIST接続（C）モードのアドレッシングピアツーピアを使用します。
RMD-QOSM/QoS-NSLP signaling messages that are processed by all nodes of the Diffserv domain, i.e., Edges and Interior nodes, use the end-to-end addressing of the GIST Datagram (D) mode. Note that the RMD-QOSM cannot directly specify that the GIST Connection or the GIST Datagram mode SHOULD be used. This can only be specified by using, via the QoS-NSLP-RMF API, the GIST API Transfer-Attributes, such as Reliable or Unreliable, high or low level of security, and by the use of local policies. RMD QoS signaling messages that are addressed to the data path end nodes are intercepted by the Egress nodes. In particular, at the ingress and for downstream intra-domain messages, the RMD-QOSM instructs the GIST functionality, via the GIST API to do the following:
Diffservのドメインのすべてのノードによって処理されるメッセージ、すなわち、エッジおよび内部ノードをシグナリングRMD-QOSM /のQoS-NSLP、エンドツーエンドGISTデータグラム（D）モードのアドレッシングを使用します。 RMD-QOSM直接GIST接続又はGISTデータグラムモードを使用するように指定することができないことに留意されたいです。これは、QoSの-NSLP-RMF APIを介して、このようなセキュリティの信頼性や信頼できない、ハイまたはローレベルとしてGISTのAPI転送-属性を使用することにより、およびローカルポリシーを使用して指定することができます。データパスのエンドノードにアドレス指定されるシグナリングメッセージをRMD QoSは、出口ノードによってインターセプトされます。具体的には、入口で、下流のドメイン内のメッセージに対して、RMD-QOSMは、次の操作を実行するためにGISTのAPIを介して、GISTの機能を指示します。
* use unreliable and low level security Transfer-Attributes,
*信頼性が低く、低レベルのセキュリティ転送-属性を使用し、
* do not create a GIST routing state, and
* GISTルーティング状態を作成しないと、
* use the D-mode MRI.
* DモードMRIを使用しています。
The intra-domain RESERVE messages can then be transported by using the Query D-mode; see Section 4.4.
ドメイン内RESERVEメッセージは、その後、クエリDモードを使用して輸送することができます。 4.4節を参照してください。
At the QNE Egress, and for upstream intra-domain messages, the RMD-QOSM instructs the GIST functionality, via the GIST API, to use among others:
QNE出口で、上流ドメイン内のメッセージのために、RMD-QOSMは、とりわけ使用するために、GISTのAPIを介して、GISTの機能を指示します。
* unreliable and low level security Transfer-Attributes
*信頼性が低く、低レベルのセキュリティ転送-属性
* the routing state associated with the intra-domain session to send an upstream intra-domain message directly to the QNE Ingress; see Section 4.4.
* QNE進入に直接上流のドメイン内のメッセージを送信するドメイン内のセッションに関連付けられたルーティング状態。 4.4節を参照してください。
This section describes the basic unidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished:
このセクションでは、RMD-QOSMのイベント/トリガの基本的な一方向の操作とシーケンスを説明します。次の基本的な操作例は区別されます。
* Successful reservation (Section 4.6.1.1), * Unsuccessful reservation (Section 4.6.1.2), * RMD refresh reservation (Section 4.6.1.3), * RMD modification of aggregated reservation (Section 4.6.1.4), * RMD release procedure (Section 4.6.1.5.), * Severe congestion handling (Section 4.6.1.6.), * Admission control using congestion notification based on probing (Section 4.6.1.7.).
*成功した予約（セクション4.6.1.1）、*失敗予約（セクション4.6.1.2）、* RMDリフレッシュ予約（セクション4.6.1.3）、*集約予約のRMD修飾（セクション4.6.1.4）、* RMD解放手順（セクション4.6.1.5。）、*重度の輻輳の取り扱い（セクション4.6.1.6。）、*アドミッションコントロール（セクション4.6.1.7を。）プロービングに基づいて輻輳通知を使用。
The QNEs at the Edges of the RMD domain support the RMD QoS Model and end-to-end QoS Models, which process the RESERVE message differently.
RMDドメインのエッジでQNEsは異なっRESERVEメッセージを処理RMDのQoSモデルとエンドツーエンドのQoSモデルをサポートしています。
Note that the term end-to-end QoS Model applies to any QoS Model that is initiated and terminated outside the RMD-QOSM-aware domain. However, there might be situations where a QoS Model is initiated and/or terminated by the QNE Edges and is considered to be an end-to-end QoS Model. This can occur when the QNE Edges can also operate as either QNI or as QNR and at the same time they can operate as either sender or receiver of the data path.
用語のエンドツーエンドのQoSモデルは、RMD-QOSMアウェアドメインの外で開始し、終了したすべてのQoSモデルに適用されることに注意してください。しかし、QoSのモデルが開始および/またはQNEエッジで終了し、エンドツーエンドのQoSモデルであると考えられている状況があるかもしれません。 QNEエッジもQNI又はQNRとして、それらはデータパスのいずれかの送信側または受信側として動作することができると同時に、のいずれかとして動作することができる場合に発生する可能性があります。
It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed:
基本的な一方向の操作を想定した場合、このセクションの内容は、信号方式以下RMD-QOSM / QoSの-NSLPの仕様のために使用されていることを強調することが重要です。
* "per-flow congestion notification based on probing";
*「探査に基づいて、フローごとの輻輳通知」。
* "per-flow RMD NSIS measurement-based admission control";
*「フロー毎RMD NSIS測定ベースのアドミッション制御」。
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
*「フローごとのRMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで、
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
*「フローごとのRMD予約ベースの」手順「の比例データパケットマーキングにより、深刻な輻輳処理」との組み合わせで、
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
*「ごとの集計RMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで、
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
*「ごとの集計RMD予約ベースの」手順「をマーキング比例データパケットによって深刻な輻輳処理」との組み合わせで。
For more details, please see Section 3.2.3.
詳細については、3.2.3項を参照してください。
In particular, the functionality described in Sections 4.6.1.1, 4.6.1.2, 4.6.1.3, 4.6.1.5, 4.6.1.4, and 4.6.1.6 applies to the RMD reservation-based and to the NSIS measurement-based admission control methods. The described functionality in Section 4.6.1.7 applies to the admission control procedure that uses the congestion notification based on probing. The QNE Edge nodes maintain either per-flow QoS-NSLP operational and reservation states or aggregated QoS-NSLP operational and reservation states.
具体的には、機能はセクション4.6.1.1、4.6.1.2、4.6.1.3、4.6.1.5、4.6.1.4に記載され、そして4.6.1.6はRMD予約ベースおよびNSIS測定ベースのアドミッション制御方法に適用されます。セクション4.6.1.7に記載された機能は、プローブに基づく輻輳通知を使用するアドミッション制御手順に適用されます。 QNEエッジノードは、いずれかのフローごとのQoS-NSLP動作及び予約状態または凝集のQoS-NSLP動作と予約状態を維持します。
When the QNE Edges maintain aggregated QoS-NSLP operational and reservation states, the RMD-QOSM functionality MAY accomplish an RMD modification procedure (see Section 4.6.1.4), instead of the reservation initiation procedure that is described in this subsection. Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM process the QoS-NSLP signaling messages with a higher priority than data packets. This can be accomplished as described in Section 3.3.4 of [RFC5974] and it can be requested via the QoS-NSLP-RMF API described in [RFC5974]. The signaling scenarios described in this section are accomplished using the QoS-NSLP processing rules defined in [RFC5974], in combination with the RMF triggers sent via the QoS-NSLP-RMF API described in [RFC5974].
QNEエッジが凝集したQoS-NSLP動作と予約状態を維持する場合、RMD-QOSM機能は、代わりにこのサブセクションに記載された予約開始手順の、RMD修正手順（セクション4.6.1.4を参照）を達成することができます。 RMD-QOSMプロセスのQoS-NSLPのQNE実装は、データパケットよりも高い優先度を有するメッセージをシグナリングすることを推奨されていることに留意されたいです。 [RFC5974]のセクション3.3.4で説明したように、これは達成することができ、それは、[RFC5974]で説明されたQoS-NSLP-RMFのAPIを介して要求することができます。このセクションで説明するシグナリングシナリオは[RFC5974]で定義されたQoS-NSLP処理ルールを用いて達成され、RMFとの組み合わせで、[RFC5974]に記載されたQoS-NSLP-RMFのAPIを介して送信トリガします。
According to Section 3.2.3, it is specified that only the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme MUST be implemented within one RMD domain. However, all RMD QNEs supporting this specification MUST support the combination the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container" (Section
3.2.3項によれば、スキームは1つのRMDドメイン内に実装しなければならない「マーキング比例データパケットによって深刻な輻輳処理」のみと組み合わせた「フローごとのRMD予約・ベース」と指定されています。しかし、この仕様をサポートするすべてのRMDのQNEsは、「フローごとのRMD予約がベース」の組み合わせをサポートしなければならないとの組み合わせでスキームを「比例データパケットによって深刻な輻輳処理マーキング」。 RMDのQNEsがよりRMD-QOSM方式をサポートしている場合、そのRMDドメインのオペレータは、一つのドメイン（<SCH>フィールドが「PHR容器」内に含まれるように、セクション内のすべてのQNEエッジノードを事前に設定しなければなりません
4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes is used at a time.
4.1.2）と「PDRコンテナ」（4.1.3項）は常に、以下に説明RMD-QOSM方式の一つRMDドメイン内の一方のみが一度に使用されるように同じ値を使用します。
All QNE nodes located within the RMD domain MUST read and interpret the <SCH> field included in the "PHR container" before processing all the other "PHR container" payload fields. Moreover, all QNE Edge nodes located at the boarder of the RMD domain, MUST read and interpret the <SCH> field included in the "PDR container" before processing all the other <PDR container> payload fields.
RMDドメイン内にあるすべてのQNEノードは、<SCH>フィールドを読み、解釈しなければならない他のすべての「PHRコンテナ」ペイロードフィールドを処理する前に、「PHRコンテナ」に含まれています。また、RMDドメインの境界に位置するすべてのQNEエッジノード、<SCH>フィールドを読み取って解釈しなければならない他のすべての<PDR容器>ペイロード・フィールドを処理する前に「PDRコンテナ」に含まれます。
This section describes the operation of the RMD-QOSM where a reservation is successfully accomplished.
このセクションでは、予約が正常に達成されるRMD-QOSMの動作を説明します。
The QNI generates the initial RESERVE message, and it is forwarded by the NTLP as usual [RFC5971].
QNI初期RESERVEメッセージを生成し、それは通常、[RFC5971]としてNTLPによって転送されます。
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE) (see Figure 8), it is processed based on the end-to-end QoS Model. Subsequently, the combination of <TMOD-1>, <PHB Class>, and <Admission Priority> is derived from the <QoS Desired> object of the initial QSPEC.
エンドツーエンド予約要求（RESERVE）はIngressノード（QNE）に到着すると、それはエンド・ツー・エンドのQoSモデルに基づいて処理されている（図8参照）。その後、<TMOD-1>、<PHBクラス>、および<入場優先順位>の組み合わせは<望ましいQoS>初期QSPECのオブジェクトから派生しています。
The QNE Ingress MUST maintain information about the smallest MTU that is supported on the links within the RMD domain.
QNEイングレスは、RMDドメイン内のリンクでサポートされている最小のMTUの情報を維持しなければなりません。
The <Maximum Packet Size-1 (MPS)> value included in the end-to-end QoS Model <TMOD-1> parameter is compared with the smallest MTU value that is supported by the links within the RMD domain. If the "Maximum Packet Size-1 (MPS)" is larger than this smallest MTU value within the RMD domain, then the end-to-end reservation request is rejected (see Section 4.6.1.1.2). Otherwise, the admission process continues.
<最大パケットサイズ-1（MPS）>の値は、エンドツーエンドのQoSモデル<TMOD-1>パラメータに含まれるRMDドメイン内のリンクによってサポートされる最小のMTU値と比較されます。 「最大パケットサイズ-1（MPS）」は、次いで、エンドツーエンド予約要求が拒否されたRMDドメイン内のこの最小のMTU値よりも大きい場合（セクション4.6.1.1.2参照）。そうでない場合は、入学プロセスは継続します。
The <TMOD-1> parameter contained in the original initiator QSPEC is mapped into the equivalent RMD-Qspec <TMOD-1> parameter representing only the peak bandwidth in the local RMD-QSPEC. This can be accomplished by setting the RMD-QSPEC <TMOD-1> fields as follows: token rate (r) = peak traffic rate (p), the bucket depth (b) = large, and the minimum policed unit (m) = large.
元のイニシエータQSPECに含まれる<TMOD-1>パラメータは、ローカルRMD-QSPECでのみピーク帯域幅を表す等価RMD-Qspec <TMOD-1>パラメータにマッピングされます。これは、RMD-QSPEC <TMOD-1>フィールド次のように設定することによって達成することができる。トークンレート（R）=ピークトラフィックレート（P）、（B）が大きい=バケット深さを、最小ポリシング単位（M）=大。
Note that the bucket size, (b), is measured in bytes. Values of this parameter may range from 1 byte to 250 gigabytes; see [RFC2215]. Thus, the maximum value that (b) could be is in the order of 250 gigabytes. The minimum policed unit, [m], is an integer measured in bytes and must be less than or equal to the Maximum Packet Size (MPS). Thus, the maximum value that (m) can be is (MPS). [Part94] and [TaCh99] describe a method of calculating the values of some Token Bucket parameters, e.g., calculation of large values of (m) and (b), when the token rate (r), peak rate (p), and MPS are known.
バケットサイズ、（b）は、バイト単位で測定されることに留意されたいです。このパラメータの値は、1バイトから250ギガバイトの範囲であってよいです。 [RFC2215]を参照してください。従って、（B）とすることができる最大値は、250ギガバイト程度です。最小ポリシング単位は、[m]は、バイト単位で測定された整数であり、最大パケットサイズ（MPS）以下でなければなりません。従って、（m）は可能な最大値（MPS）です。 【Part94]および[TaCh99いくつかのトークンバケットパラメータの値を計算する方法、例えば、（M）の大きな値の計算と、（b）、トークン・レート（r）は、ピークレート（p）を記述し、そしてMPSが知られています。
The <Peak Data Rate-1 (p)> value of the end-to-end QoS Model <TMOD-1> parameter is copied into the <Peak Data Rate-1 (p)> value of the <Peak Data Rate-1 (p)> value of the local RMD-Qspec <TMOD-1>.
エンドツーエンドのQoSモデル<TMOD-1>パラメータ<ピークデータレート-1（P）>値<ピークデータレート-1の<ピークデータレート-1（P）>の値にコピーされローカルRMD-Qspec <TMOD-1>の（P）>値。
The MPS value of the end-to-end QoS Model <TMOD-1> parameter is copied into the MPS value of the local RMD-Qspec <TMOD-1>.
エンド・ツー・エンドのQoSモデルのMPS値が<TMOD-1>パラメータは、ローカルRMD-Qspec <TMOD-1>のMPS値にコピーされます。
If the initial QSPEC does not contain the <PHB Class> parameter, then the selection of the <PHB Class> that is carried by the intra-domain RMD-QSPEC is defined by a local policy similar to the procedures discussed in [RFC2998] and [RFC3175].
初期QSPECは<PHBクラス>パラメータが含まれていない場合、次いで、ドメイン内RMD-QSPECによって運ばれる<PHBクラス>の選択は、[RFC2998]で説明した手順と同様のローカルポリシーによって定義され、そして[RFC3175]。
For example, in the situation that the initial QSPEC is used by the IntServ Controlled Load QOSM, then the Expedited Forwarding (EF) PHB is appropriate to set the <PHB Class> parameter carried by the intra-domain RMD-QSPEC (see [RFC3175]).
例えば、初期QSPECがIntServの制御負荷QOSMによって使用されている状況では、緊急転送（EF）PHBは、（[RFC3175参照イントラドメインRMD-QSPECによって運ば<PHBクラス>パラメータを設定することが適当です]）。
If the initial QSPEC does not carry the <Admission Priority> parameter, then the <Admission Priority> parameter in the RMD-QSPEC will not be populated. If the initial QSPEC does not carry the <Admission Priority> parameter, but it carries other priority parameters, then it is considered that Edges, as being stateful nodes, are able to control the priority of the sessions that are entering or leaving the RMD domain in accordance with the priority parameters.
初期QSPECは<入場プライオリティ>パラメータを運ぶしない場合は、RMD-QSPECで<入場優先順位>パラメータが設定されません。初期QSPECは<入場プライオリティ>パラメータを運ぶことはありませんが、それは他の優先度パラメータを有するならば、縁が、ステートフルノードであるとして、入力したり、RMDドメインを残しているセッションの優先順位を制御することができると考えられています優先度パラメータに従ってインチ
Note that the RMF reservation states (see Section 4.3) in the QNE Edges store the value of the <Admission Priority> parameter that is used within the RMD domain in case of preemption and severe congestion situations (see Section 4.6.1.6).
QNEのエッジにおけるRMF予約状態は（4.3節を参照してください）<入場優先順位>プリエンプションと厳しい混雑状況の場合、RMDのドメイン内で使用されたパラメータの値を格納していることに注意してください（セクション4.6.1.6を参照）。
If the RMD domain supports preemption during the admission control process, then the QNE Ingress node can support the building blocks specified in [RFC5974] and during the admission control process use the example preemption handling algorithm described in Appendix A.7.
RMD領域は、アドミッション制御プロセス中にプリエンプションをサポートしている場合、QNE Ingressノードは[RFC5974]で指定されたビルディングブロックをサポートし、アドミッション制御プロセス中でき付録A.7に記載のアルゴリズムを処理する例プリエンプションを使用します。
Note that in the above described case, the QNE Egress uses, if available, the tunneled initial priority parameters, which can be interpreted by the QNE Egress.
利用可能な場合、上述の場合には、QNE退出は、QNE退出によって解釈することができるトンネリング初期優先パラメータを使用することに注意してください。
If the initial QSPEC carries the <Excess Treatment> parameter, then the QNE Ingress and QNE Egress nodes MUST control the excess traffic that is entering or leaving the RMD domain in accordance with the <Excess Treatment> parameter. Note that the RMD-QSPEC does not carry the <Excess Treatment> parameter.
初期QSPECは<過剰処理>パラメータを搬送する場合、QNE入力およびQNE出口ノードは<過剰処理>パラメータに従ってRMD領域に入るまたは離脱される過剰なトラフィックを制御しなければなりません。 RMD-QSPECは<過剰治療>パラメータを運ばないことに注意してください。
If the requested <TMOD-1> parameter carried by the initial QSPEC, cannot be satisfied, then an end-to-end RESPONSE message has to be generated. However, in order to decide whether the end-to-end reservation request was locally (at the QNE Ingress) satisfied, a local (at the QNE_Ingress) RMD-QOSM admission control procedure also has to be performed. In other words, the RMD-QOSM functionality has to verify whether the value included in the <Peak Data Rate-1 (p)> field of RMD-QOSM <TMOD-1> can be reserved and stored in the RMD-QOSM reservation states (see Sections 4.6.1.1.2 and 4.3).
初期QSPECによって運ば要求<TMOD-1>パラメータは、満足できない場合は、エンドツーエンドの応答メッセージが生成されなければなりません。しかし、エンドツーエンド予約要求が（QNE入口で）局所的に満足したかどうかを決定するために、ローカル（QNE_Ingressで）RMD-QOSMアドミッション制御手順も実行しなければなりません。換言すれば、RMD-QOSM機能は、RMD-QOSM <TMOD-1>の<ピークデータレート-1（P）>フィールドに含まれる値は、予約さRMD-QOSM予約状態に格納することができるかどうかを確認しなければなりません（セクション4.6.1.1.2および4.3を参照）。
An initial QSPEC object MUST be included in the end-to-end RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values.
初期QSPECオブジェクトは、エンドツーエンドの応答メッセージに含まれなければなりません。 QSPEC <確保されたQoS>に含まれるパラメータは、オブジェクトは、値が元の<望ましいQoS>からコピーされます。
The <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are set. In addition, the <INFO-SPEC> object is included in the end-to-end RESPONSE message. The error code used by this <INFO-SPEC> is:
QSPECに関連付けられた<E>フラグが<QoSが予約>オブジェクトとローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<E>フラグが設定されています。また、<INFO-SPEC>オブジェクトは、エンドツーエンドの応答メッセージに含まれています。この<INFO-SPEC>で使用されるエラーコードは次のとおりです。
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
Furthermore, all of the other RESPONSE parameters are set according to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].
また、他の応答パラメータの全ては、エンドツーエンドのQoSモデルに応じて設定または[RFC5974]及び[RFC5975]に記載されています。
If the request was satisfied locally (see Section 4.3), the Ingress QNE node generates two RESERVE messages: one intra-domain and one end-to-end RESERVE message. Note however, that when the aggregated QoS-NSLP operational and reservation states are used by the QNE Ingress, then the generation of the intra-domain RESERVE message depends on the availability of the aggregated QoS-NSLP operational state. If this aggregated QoS-NSLP operational state is available, then the RMD modification of aggregated reservations described in Section 4.6.1.4 is used.
1つのイントラドメインと一つのエンドツーエンドRESERVEメッセージ：要求は（セクション4.3を参照）ローカル満足していた場合、入口QNEノードは、二つのRESERVEメッセージを生成します。凝集したQoS-NSLP動作し、予約状態はQNE進入で使用される場合、次いで、ドメイン内RESERVEメッセージの生成は、凝集のQoS-NSLP動作状態の利用可能性に依存することが留意されたいです。この凝集のQoS-NSLP動作状態が利用可能である場合、セクション4.6.1.4に記載の凝集予約のRMDの変形が使用されます。
It is important to note that when the "per-flow RMD reservation-based" scenario is used within the RMD domain, the retransmission within the RMD domain SHOULD be disallowed. The reason for this is related to the fact that the QNI Interior nodes are not able to differentiate between a retransmitted RESERVE message associated with a certain session and an initial RESERVE message belonging to another session. However, the QNE Ingress have to report a failure situation upstream. When the QNE Ingress transmits the (intra-domain or end-to-end) RESERVE with the <RII> object set, it waits for a RESPONSE from the QNE Egress for a QOSNSLP_REQUEST_RETRY period.
「フローごとのRMD予約・ベース」のシナリオがRMDのドメイン内で使用されている場合、RMDドメイン内の再送信が禁止されるべきであることに注意することが重要です。この理由は、QNIインテリアノードは特定のセッションに関連付けられている再送RESERVEメッセージと別のセッションに属する初期RESERVEメッセージを区別することができないという事実に関連しています。しかし、QNEイングレスは、上流の故障状況を報告しなければなりません。 QNE進入が（ドメイン内またはエンドツーエンド）<RII>オブジェクトセットで予約を送信する場合、それはQOSNSLP_REQUEST_RETRY期間のQNE出口からの応答を待ちます。
If the QNE Ingress transmitted an intra-domain or end-to-end RESERVE message with the <RII> object set and it fails to receive the associated intra-domain or end-to-end RESPONSE, respectively, after the QOSNSLP_REQUEST_RETRY period expires, it considers that the reservation failed. In this case, the QNE Ingress SHOULD generate an end-to-end RESPONSE message that will include, among others, an <INFO-SPEC> object. The error code used by this <INFO-SPEC> object is:
QOSNSLP_REQUEST_RETRY期間が終了した後に、それぞれ、QNE進入は<RII>オブジェクトセットでイントラドメインまたはエンド・ツー・エンドのRESERVEメッセージを送信し、それが関連付けられているドメイン内またはエンド・ツー・エンドの応答を受信できなかった場合それは予約が失敗したと考えています。この場合、QNE進入は、とりわけ、含むエンドツーエンドの応答メッセージ<INFO-SPEC>オブジェクトを生成する必要があります。この<INFO-SPEC>オブジェクトによって使用されるエラー・コードです：
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
Furthermore, all of the other RESPONSE parameters are set according to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].
また、他の応答パラメータの全ては、エンドツーエンドのQoSモデルに応じて設定または[RFC5974]及び[RFC5975]に記載されています。
Note however, that if the retransmission within the RMD domain is not disallowed, then the procedure described in Appendix A.8 SHOULD be used on QNE Interior nodes; see also [Chan07]. In this case, the stateful QNE Ingress uses the retransmission procedure described in [RFC5974].
RMDドメイン内の再送信が禁止されていない場合には、付録A.8に記載された手順は、QNEインテリアノードで使用されるべきであること、しかし、注意してください。 [Chan07]も参照してください。この場合には、ステートフルQNE進入は[RFC5974]で説明再送手順を使用します。
If a rerouting takes place, then the stateful QNE Ingress is following the procedures specified in [RFC5974].
再ルーティングが行われる場合には、ステートフルQNE進入は[RFC5974]で指定された手順に従っています。
At this point, the intra-domain and end-to-end operational states MUST be initiated or modified according to the REQUIRED binding procedures. The way of how the BOUND-SESSION-IDs are initiated and maintained in the intra-domain and end-to-end QoS-NSLP operational states is described in Sections 4.3.1 and 4.3.2.
この時点で、ドメイン内およびエンド・ツー・エンド動作状態は、必要な結合手順に従って開始又は変更しなければなりません。 BOUND-SESSION-IDが開始され、ドメイン内およびエンドツーエンドのQoS-NSLP動作状態に維持されているかの方法は、セクション4.3.1および4.3.2に記載されています。
These two messages are bound together in the following way. The end-to-end RESERVE SHOULD contain, in the BOUND-SESSION-ID, the SESSION-ID of its bound intra-domain session.
これら二つのメッセージは、次のように一緒にバインドされています。エンド・ツー・エンドのRESERVEはBOUND-SESSION-ID、その結合ドメイン内のセッションのセッションIDで、含むべきです。
Furthermore, if the QNE Edge nodes maintain intra-domain per-flow QoS-NSLP reservation states, then the value of Binding_Code MUST be set to code "Tunnel and end-to-end sessions" (see Section 4.3.2).
QNEエッジノードがドメイン内あたりフローのQoS-NSLP予約状態を維持する場合はさらに、次いでBinding_Codeの値は、コード「トンネルエンドツーエンドのセッション」に設定しなければなりません（セクション4.3.2を参照）。
In addition to this, the intra-domain and end-to-end RESERVE messages are bound using the Message binding procedure described in [RFC5974].
これに加えて、ドメイン内およびエンドツーエンドRESERVEメッセージは、[RFC5974]に記載の手順を結合メッセージを使用して結合されています。
In particular the <MSG-ID> object is included in the intra-domain RESERVE message and its bound <BOUND-MSG-ID> object is carried by the end-to-end RESERVE message. Furthermore, the <Message_Binding_Type> flag is SET (value is 1), such that the message dependency is bidirectional.
特に<MSG-ID>オブジェクトは、ドメイン内RESERVEメッセージに含まれており、その結合<BOUND-MSG-ID>オブジェクトは、エンドツーエンドのRESERVEメッセージによって運ばれます。また、<Message_Binding_Type>フラグがメッセージ依存性が双方向であるように、（値は1）に設定されています。
If the QoS-NSLP Edges maintain aggregated intra-domain QoS-NSLP operational states, then the value of Binding_Code MUST be set to code "Aggregated sessions".
QoSの-NSLPが集約されたドメイン内のQoS-NSLP動作状態を維持するエッジ場合、Binding_Codeの値は、コード「アグリゲートされたセッション」に設定しなければなりません。
Furthermore, in this case, the retransmission within the RMD domain is allowed and the procedures described in Appendix A.8 SHOULD be used on QNE Interior nodes. This is necessary due to the fact that when retransmissions are disallowed, then the associated with (micro) flows belonging to the aggregate will loose their reservations. Note that, in this case, the stateful QNE Ingress uses the retransmission procedure described in [RFC5974].
また、この場合には、RMDドメイン内の再送信が許可され、付録A.8に記載された手順は、QNEインテリアノードで使用されてください。これは、再送信が禁止されているという事実のために必要であるその後、（マイクロ）に関連付けられている彼らの予約を失うことになるの集計に属すると流れます。なお、この場合には、ステートフルQNE進入は[RFC5974]で説明再送手順を使用します。
The intra-domain RESERVE message is associated with the (local NTLP) SESSION-ID mentioned above. The selection of the IP source and IP destination address of this message depends on how the different inter-domain (end-to-end) flows are aggregated by the QNE Ingress node (see Section 4.3.1). As described in Section 4.3.1, the QNE Edges maintain either per-flow, or aggregated QoS-NSLP reservation states for the RMD QoS Model, which are identified by (local NTLP) SESSION-IDs (see [RFC5971]). Note that this NTLP SESSION-ID is a different one than the SESSION-ID associated with the end-to-end RESERVE message.
ドメイン内RESERVEメッセージは、セッションIDは、上記の（ローカルNTLP）と関連しています。 IPソースと、このメッセージのIP宛先アドレスの選択は、（セクション4.3.1を参照）は、異なるドメイン間（エンドツーエンド）フローがQNE Ingressノードによって集約される方法に依存します。セクション4.3.1で説明したように、QNEは、（ローカルNTLP）セッションIDによって識別されるRMDのQoSモデル、（[RFC5971]を参照）ごとのフローのいずれかを維持するエッジ、または凝集のQoS-NSLPの予約状態。このNTLPセッションIDはセッションID、エンド・ツー・エンドRESERVEメッセージに関連付けられているとは異なるものであることに留意されたいです。
If no QoS-NSLP aggregation procedure at the QNE Edges is supported, then the IP source and IP destination address of this message MUST be equal to the IP source and IP destination addresses of the data flow. The intra-domain RESERVE message is sent using the NTLP datagram mode (see Sections 4.4 and 4.5). Note that the GIST Datagram mode can be selected using the unreliable GIST API Transfer-Attributes. In addition, the intra-domain RESERVE (RMD-QSPEC) message MUST include a PHR container (PHR_Resource_Request) and the RMD QOSM <QoS Desired> object.
QNE端で何のQoS-NSLP凝集手順がサポートされていない場合、このメッセージのIPソースおよびIP宛先アドレスは、データフローのIPソースおよびIP宛先アドレスと等しくなければなりません。ドメイン内RESERVEメッセージはNTLPデータグラムモード（セクション4.4および4.5を参照）を使用して送信されます。 GISTデータグラムモードが信頼できないGISTのAPI転送-属性を使用して選択することができることに注意してください。また、ドメイン内RESERVE（RMD-QSPEC）メッセージは、PHR容器（PHR_Resource_Request）とRMD QOSM <望ましいQoS>オブジェクトを含まなければなりません。
The end-to-end RESERVE message includes the initial QSPEC and it is sent towards the Egress QNE.
エンドツーエンドのRESERVEメッセージは、初期QSPECを含み、それが退出QNEに向けて送信されます。
Note that after completing the initial discovery phase, the GIST Connection mode can be used between the QNE Ingress and QNE Egress. Note that the GIST Connection mode can be selected using the reliable GIST API Transfer-Attributes.
初期の発見フェーズを完了した後、GIST接続モードがQNE入力およびQNE出口の間で使用できることに注意してください。 GIST接続モードは、信頼性の高いGISTのAPI転送-属性を使用して選択することができることに注意してください。
The end-to-end RESERVE message is forwarded using the GIST forwarding procedure to bypass the Interior stateless or reduced-state QNE nodes; see Figure 8. The bypassing procedure is described in Section 4.4.
エンドツーエンドのRESERVEメッセージはインテリアステートレスまたは低減状態QNEノードをバイパスするGIST転送手順を使用して転送されます。バイパス手順はセクション4.4に記載されている8.図を参照してください。
At the QNE Ingress, the end-to-end RESERVE message is marked, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value that will be used by the GIST message carrying the end-to-end RESPONSE message to bypass the QNE Interior nodes. Note that the QNE Interior nodes (see [RFC5971]) are configured to handle only certain NSLP-IDs (see [RFC5974]).
QNE入口で、エンド・ツー・エンドのRESERVEメッセージは、マークされている、すなわち、バイパスへのエンドツーエンドの応答メッセージを運ぶGISTメッセージによって使用される別のNSLPID所定値へのQoS-NSLPデフォルトNSLPID値を変更QNEインテリア・ノード。 QNEインテリアノードことに注意してください（[RFC5971]を参照）のみ特定のNSLP-IDを処理するように構成されている（[RFC5974]を参照）。
Furthermore, note that the initial discovery phase and the process of sending the end-to-end RESERVE message towards the QNE Egress MAY be done simultaneously. This can be accomplished only if the GIST implementation is configured to perform that, e.g., via a local policy. However, the selection of the discovery procedure cannot be selected by the RMD-QOSM.
さらに、初期の発見フェーズとQNE出口に向けたエンド・ツー・エンドのRESERVEメッセージを送信する処理を同時に行うことができることに注意してください。これは、ローカルポリシーを介して、例えば、GIST実装はそれを実行するように構成されている場合にのみ達成することができます。しかし、発見手順の選択は、RMD-QOSMによって選択することができません。
The (initial) intra-domain RESERVE message MUST be sent by the QNE Ingress and it MUST contain the following values (see the QoS-NSLP-RMF API described in [RFC5974]):
（最初の）ドメイン内RESERVEメッセージはQNE進入によって送信されなければならなくて、それは次の値を含まなければなりません（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）。
* the <RSN> object, whose value is generated and processed as described in [RFC5974];
その値は[RFC5974]で説明されるように生成され、処理される* <RSN>オブジェクト。
* the <SCOPING> flag MUST NOT be set, meaning that a default scoping of the message is used. Therefore, the QNE Edges MUST be configured as RMD boundary nodes and the QNE Interior nodes MUST be configured as Interior (intermediary) nodes;
* <SCOPING>フラグは、メッセージのデフォルトのスコープが使用されていることを意味し、設定してはいけません。したがって、QNEエッジはRMD境界ノードとして構成されなければならないとQNEインテリアノードは、内部（中間）ノードとして構成されなければなりません。
* the <RII> MUST be included in this message, see [RFC5974];
* <RII> [RFC5974]を参照して、このメッセージに含まれなければなりません。
* the <REPLACE> flag MUST be set to FALSE = 0;
* <REPLACE>フラグがFALSE = 0に設定しなければなりません。
* The value of the <Message ID> value carried by the <MSG-ID> object is set according to [RFC5974]. The value of the <Message_Binding_Type> is set to "1".
* <MSG-ID>オブジェクトによって運ばれる<メッセージID>値の値は、[RFC5974]に応じて設定されます。 <Message_Binding_Type>の値が「1」に設定されています。
* the value of the <REFRESH-PERIOD> object MUST be calculated and set by the QNE Ingress node as described in Section 4.6.1.3;
セクション4.6.1.3に記載されるよう* <REFRESH-PERIOD>オブジェクトの値を計算し、QNE Ingressノードによって設定されなければなりません。
* the value of the <PACKET-CLASSIFIER> object is associated with the path-coupled routing Message Routing Message (MRM), since RMD-QOSM is used with the path-coupled MRM. The flag that has to be set is the <T> flag (traffic class) meaning that the packet classification of packets is based on the <DSCP> value included in the IP header of the packets. Note that the <DSCP> value used in the MRI can be derived by the value of <PHB Class> parameter, which MUST be carried by the intra-domain RESERVE message. Note that the QNE Ingress being a QNI for the intra-domain session it can pass this value to GIST, via the GIST API.
RMD-QOSMがパス結合MRMで使用されるため* <パケットCLASSIFIER>オブジェクトの値は、パス結合ルーティングメッセージルーティングメッセージ（MRM）に関連しています。設定しなければならないフラグは、パケットのパケット分類は、パケットのIPヘッダに含まれる<DSCP>値に基づいていることを意味する<T>フラグ（トラフィッククラス）です。 MRIで使用される<DSCP>値がイントラドメインRESERVEメッセージによって実行されなければならない<PHBクラス>パラメータの値によって導出することができることに留意されたいです。それはGISTのAPIを介して、GISTにこの値を渡すことができQNEイングレスは、ドメイン内のセッションのQNIていることに注意してください。
* the PHR resource units MUST be included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the <QoS Desired> object.
* PHRのリソースユニットは、ローカルRMD-QSPEC <TMOD-1> <望ましいQoS>のパラメータオブジェクトの<ピークデータレート-1（P）>フィールドに含まれなければなりません。
When the QNE Edges use per-flow intra-domain QoS-NSLP states, then the <Peak Data Rate-1 (p)> value included in the initial QSPEC <TMOD-1> parameter is copied into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter.
QNE縁使用あたりフロードメイン内のQoS-NSLP状態は、次に初期QSPEC <TMOD-1>に含まれる<ピークデータレート-1（P）>の値は、パラメータは、<ピークデータレート-1にコピーされると（P）>ローカルRMD-QSPEC <TMOD-1>パラメータの値。
When the QNE Edges use aggregated intra-domain QoS-NSLP operational states, then the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter can be obtained by using the bandwidth aggregation method described in Section 4.3.1;
QNEエッジが凝集ドメイン内のQoS-NSLP動作状態を使用する場合、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>値が記述帯域幅凝集法を用いて求めることができます4.3.1項では、
* the value of the <PHB Class> parameter can be defined by using the method of copying the <PHB Class> parameter carried by the initial QSPEC into the <PHB Class> carried by the RMD-QSPEC, which is described above in this subsection.
* <PHBクラス>パラメータの値は、この節で上述したRMD-QSPEC、によって運ば<PHBクラス>に初期QSPECによって運ば<PHBクラス>パラメータをコピーする方法を使用して定義することができます。 。
* the value of the <Parameter ID> field of the PHR container MUST be set to "17", (i.e., PHR_Resource_Request).
* PHRコンテナの<パラメータID>フィールドの値が「17」（すなわち、PHR_Resource_Request）に設定しなければなりません。
* the value of the <Admitted Hops> parameter in the PHR container MUST be set to "1". Note that during a successful reservation, each time an RMD-QOSM-aware node processes the RMD-QSPEC, the <Admitted Hops> parameter is increased by one.
* <入所ホップ>の値がPHR容器中のパラメータを「1」に設定する必要があります。成功した予約の際に、各時間RMD-QOSM対応ノードがRMD-QSPEC、<是認ホップ>パラメータが1だけ増加させる処理することに留意されたいです。
* the value of the <Hop_U> parameter in the PHR container MUST be set to "0".
* PHR容器内の<Hop_U>パラメータの値が「0」に設定しなければなりません。
* the value of the <Max Admitted Hops> is set to "0".
* <マックスはホップを認め>の値が「0」に設定されています。
* If the initial QSPEC carried an <Admission Priority> parameter, then this parameter SHOULD be copied into the RMD-QSPEC and carried by the (initiating) intra-domain RESERVE.
初期QSPECは<入場プライオリティ>パラメータを実施した場合は*、このパラメータは、RMD-QSPECにコピーされ、（開始）、ドメイン内RESERVEによって実行されるべきです。
Note that for the RMD-QOSM, a reservation established without an <Admission Priority> parameter is equivalent to a reservation with <Admission Priority> value of 1.
<入場優先>パラメータが1の<アドミッション優先>値と予約に相当することなく、RMD-QOSMため、予約が確立されていることに注意してください。
Note that, in this case, each admission priority is associated with a priority traffic class. The three priority traffic classes (PHB_low_priority, PHB_normal_priority, and PHB_high_priority) MAY be associated with the same PHB (see Section 4.3.3).
なお、この場合には、各アドミッション優先度は、優先度のトラフィッククラスに関連付けられています。 3つの優先トラフィッククラス（PHB_low_priority、PHB_normal_priority、およびPHB_high_priorityは）同じPHB（セクション4.3.3を参照）と関連付けられてもよいです。
* In a single RMD domain case, the PDR container MAY not be included in the message.
*単一RMDドメイン場合、PDR容器は、メッセージに含まれていなくてもよいです。
Note that the intra-domain RESERVE message does not carry the <BOUND-SESSION-ID> object. The reason for this is that the end-to-end RESERVE carries, in the <BOUND-SESSION-ID> object, the <SESSION-ID> value of the intra-domain session.
ドメイン内RESERVEメッセージは、<BOUND-SESSION-ID>オブジェクトを運ばないことに注意してください。この理由は、エンドツーエンドRESERVEは、運ぶことである<BOUND-SESSION-ID>オブジェクトで、ドメイン内のセッションの<セッションID>値。
When an end-to-end RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress node (see Section 4.6.1.1.3), then it is processed according to [RFC5974] and end-to-end QoS Model rules.
エンドツーエンドの応答メッセージは（セクション4.6.1.1.3参照）QNE出口ノードによって送信されたQNE Ingressノードによって受信されると、それは、[RFC5974]に従って処理され、エンドツーエンドQoSモデルルール。
When an intra-domain RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress (see Section 4.6.1.1.3), it uses the QoS-NSLP procedures to match it to the earlier sent intra-domain RESERVE message. After this phase, the RMD-QSPEC has to be identified and processed.
ドメイン内の応答メッセージがQNE退出によって送信されたQNE Ingressノードによって受信されると（セクション4.6.1.1.3を参照）、それは以前に送信されたドメイン内RESERVEにそれを一致させるのQoS-NSLPの手順を使用しメッセージ。この段階の後、RMD-QSPECを識別し、処理しなければなりません。
The RMD QOSM reservation has been successful if the <M> bit carried by the "PDR Container" is equal to "0" (i.e., not set).
「PDRコンテナ」によって運ば<M>ビットが「0」（即ち、設定されていない）と等しい場合RMDのQOSM予約が成功しています。
Furthermore, the <INFO-SPEC> object is processed as defined in the QoS-NSLP specification. In the case of successful reservation, the <INFO-SPEC> object MUST have the following values:
QoS-NSLP仕様で定義されているようさらに、<INFO-SPEC>オブジェクトが処理されます。成功した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持つ必要があります。
* Error severity class: Success * Error code value: Reservation successful
*エラーの重大度クラス：成功*エラーコード値：成功予約
If the end-to-end RESPONSE message has to be forwarded to a node outside the RMD-QOSM-aware domain, then the values of the objects contained in this message (i.e., <RII> <RSN>, <INFO-SPEC>, [<QSPEC>]) MUST be set by the QoS-NSLP protocol functions of the QNE. If an end-to-end QUERY is received by the QNE Ingress, then the same bypassing procedure has to be used as the one applied for an end-to-end RESERVE message. In particular, it is forwarded using the GIST forwarding procedure to bypass the Interior stateless or reduced-state QNE nodes.
エンドツーエンドの応答メッセージは、RMD-QOSM認識ドメイン外のノードに転送されなければならない場合、オブジェクトの値は、このメッセージに含まれている（すなわち、<RII> <RSN>、<INFO-SPEC> 、[<QSPECは>]）QNEののQoS-NSLPプロトコル機能によって設定されなければなりません。エンドツーエンドのクエリがQNE進入によって受信された場合、同一のバイパス手順は、エンドツーエンドRESERVEメッセージに適用されるものとして使用されなければなりません。特に、インテリアステートレスまたは低減状態QNEノードをバイパスするGIST転送手順を使用して転送されます。
Each QNE Interior node MUST use the QoS-NSLP and RMD-QOSM parameters of the intra-domain RESERVE (RMD-QSPEC) message as follows (see QoS-NSLP-RMF API described in [RFC5974]):
次のように各QNE内部ノードは、（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）内ドメインRESERVE（RMD-QSPEC）メッセージのQoS-NSLPとRMD-QOSMパラメータを使用する必要があります。
* the values of the <RSN>, <RII>, <PACKET-CLASSIFIER>, <REFRESH-PERIOD>, objects MUST NOT be changed.
*の値は<RSN>、<RII>、<PACKET-CLASSIFIER>、<REFRESH期間>、オブジェクトは変更しないでください。
The Interior node is informed by the <PACKET-CLASSIFIER> object that the packet classification SHOULD be done on the <DSCP> value. The flag that has to be set in this case is the <T> flag (traffic class). The value of the <DSCP> value MUST be obtained via the MRI parameters that the QoS-NSLP receives from GIST. A QNE Interior MUST be able to associate the value carried by the RMD-QSPEC <PHB Class> parameter and the <DSCP> value obtained via GIST. This is REQUIRED, because there are situations in which the <PHB Class> parameter is not carrying a <DSCP> value but a PHB ID code, see Section 4.1.1.
内部ノードは、パケット分類が<DSCP>値で行われるべきであること<パケットCLASSIFIER>オブジェクトによって通知されます。この場合に設定されなければならないフラグが<T>フラグ（トラフィッククラス）です。 <DSCP>値の値は、QoS-NSLPがGISTから受け取るMRIパラメータを介して取得しなければなりません。 QNEインテリアRMD-QSPEC <PHBクラス>パラメータとGISTを介して得られた<DSCP>値によって運ばれる値を関連付けることができなければなりません。これは要求され、<PHBクラス>パラメータは、<DSCP>値が、PHBのIDコードを持っていないという状況があるので、4.1.1項を参照してください。
* the flag <REPLACE> MUST be set to FALSE = 0;
*フラグ<REPLACE> 0 = FALSEに設定しなければなりません。
* when the RMD reservation-based methods, described in Section 4.3.1 and 4.3.3, are used, the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter is used by the QNE Interior node for admission control. Furthermore, if the <Admission Priority> parameter is carried by the RMD-QOSM <QoS Desired> object, then this parameter is processed as described in the following bullets.
セクション4.3.1および4.3.3に記載RMD予約ベースの方法が、使用されている場合*、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>値で使用されアドミッション制御のためのQNEインテリアノード。 <入場優先>パラメータがオブジェクトRMD-QOSM <望ましいQoS>によって運ばれていれば、以下の箇条書きに記載されているようにまた、このパラメータが処理されます。
* in the case of the RMD reservation-based procedure, and if these resources are admitted (see Sections 4.3.1 and 4.3.3), they are added to the currently reserved resources. Furthermore, the value of the <Admitted Hops> parameter in the PHR container has to be increased by one.
* RMD予約ベースの手順の場合には、これらのリソースは（セクション4.3.1および4.3.3を参照のこと）を認めている場合、それらは現在予約されたリソースに追加されます。また、PHR容器内の<是認ホップ>パラメータの値が1だけ増加されなければなりません。
* If the bandwidth allocated for the PHB_high_priority traffic is fully utilized, and a high priority request arrives, other policies on allocating bandwidth can be used, which are beyond the scope of this document.
PHB_high_priorityトラフィックに割り当てられる帯域幅を十分に利用し、優先度の高い要求が到着した場合*、割り当て帯域幅の他のポリシーは、このドキュメントの範囲を超えており、使用することができます。
* If the RMD domain supports preemption during the admission control process, then the QNE Interior node can support the building blocks specified in the [RFC5974] and during the admission control process use the preemption handling algorithm specified in Appendix A.7.
RMDドメインは、アドミッション制御プロセス中にプリエンプションをサポートしている場合*、その後、QNEインテリアノードは、[RFC5974]で指定されたビルディングブロックをサポートし、アドミッションコントロールプロセスの間に、付録A.7で指定されたアルゴリズムを処理プリエンプションを使用することができます。
* in the case of the RMD measurement-based method (see Section 4.3.2), and if the requested into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter is admitted, using a measurement-based admission control (MBAC) algorithm, then the number of this resource will be used to update the MBAC algorithm according to the operation described in Section 4.3.2.
* RMDの測定に基づく方法の場合には（セクション4.3.2を参照）、およびローカルRMD-QSPEC <TMOD-1>の<ピークデータレート-1（P）>値に要求された場合のパラメータが許可されます測定ベースのアドミッション制御（MBAC）アルゴリズムを使用して、このリソースの数は、セクション4.3.2で説明した動作に従ってMBACアルゴリズムを更新するために使用されるであろう。
When the end-to-end RESERVE message is received by the egress node, it is only forwarded further, towards QNR, if the processing of the intra-domain RESERVE(RMD-QSPEC) message was successful at all nodes in the RMD domain. In this case, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4). Furthermore, the carried <BOUND-SESSION-ID> object associated with the intra-domain session MUST be removed after processing. Note that the received end-to-end RESERVE was tunneled within the RMD domain. Therefore, the tunneled initial QSPEC carried by the end-to-end RESERVE message has to be processed/set according to the [RFC5975] specification.
エンドツーエンドのRESERVEメッセージが出口ノードで受信されると、ドメイン内RESERVEの処理（RMD-QSPEC）メッセージは、RMDのドメイン内のすべてのノードに成功した場合、それだけ、QNRに向かって、さらに転送されます。この場合、QNE退出は、エンドツーエンドRESERVEメッセージにQoS-NSLPデフォルトNSLPID値を再割り当てすることによってQNEインテリアノードをバイパスするために使用されたマーキングプロセスを停止しなければなりません（セクション4.4を参照）。また、ドメイン内のセッションに関連する実施<BOUND-SESSION-ID>オブジェクトは、処理後に除去しなければなりません。受け取ったエンド・ツー・エンドのRESERVEがRMDドメイン内でトンネリングされたことに注意してください。したがって、エンド・ツー・エンドのRESERVEメッセージによって運ばトンネリング初期QSPECは[RFC5975]の仕様に応じて設定/処理されなければなりません。
If a rerouting takes place, then the stateful QNE Egress is following the procedures specified in [RFC5974].
再ルーティングが行われる場合には、ステートフルQNE出口は、[RFC5974]で指定された手順に従っています。
At this point, the intra-domain and end-to-end operational states MUST be initiated or modified according to the REQUIRED binding procedures.
この時点で、ドメイン内およびエンド・ツー・エンド動作状態は、必要な結合手順に従って開始又は変更しなければなりません。
The way in which the BOUND-SESSION-IDs are initiated and maintained in the intra-domain and end-to-end QoS-NSLP operational states is described in Sections 4.3.1 and 4.3.2.
BOUND-SESSION-IDは、ドメイン内およびエンドツーエンドのQoS-NSLP動作状態で開始され、維持される方法は、セクション4.3.1および4.3.2に記載されています。
If the processing of the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, then the inter-domain (end-to-end) reservation is considered to have failed.
ドメイン内RESERVE（RMD-QSPEC）の処理はRMDドメイン内のすべてのノードで成功しなかった場合は、ドメイン間（エンドツーエンド）の予約は失敗したと考えられています。
Furthermore, if the initial QSPEC object used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to-end) reservation is considered to have failed.
初期QSPECオブジェクトが<利用可能なQoS>が移入されるタイプ1又は2のオブジェクトの組み合わせ、及びRMDドメイン内のすべてのノードのドメイン内RESERVE（RMD-QSPEC）成功しなかったを使用した場合、さらに、ことを考慮しなければなりません<QoSが利用可能>満たされず、ドメイン間（エンドツーエンド）予約が失敗したと考えられます。
Furthermore, note that when the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), the QNE Egress SHOULD support the message binding procedure described in [RFC5974], which can be used to synchronize the arrival of the end-
また、QNE退出あたりフロードメイン内のQoS-NSLP動作状態を（セクション4.3.2および4.3.3を参照）を使用する場合、QNE退出をすることができる[RFC5974]に記載メッセージ結合手順をサポートすべきであることに注意エンドの到着を同期するために使用
to-end RESERVE and the intra-domain RESERVE (RMD-QSPEC) messages, see Section 5.7, and QoS-NSLP-RMF API described in [RFC5974]. Note that the intra-domain RESERVE message carries the <MSG-ID> object and its bound end-to-end RESERVE message carries the <BOUND-MSG-ID> object. Both these objects carry the <Message_Binding_Type> flag set to the value of "1". If these two messages do not arrive during the time defined by the MsgIDWait timer, then the reservation is considered to have failed. Note that the timer has to be preconfigured and it has to have the same value in the RMD domain. In this case, an end-to-end RESPONSE message, see QoS-NSLP-RMF API described in [RFC5974], is sent towards the QNE Ingress with the following <INFO-SPEC> values:
エンドツーエンドのRESERVEおよびドメイン内RESERVE（RMD-QSPEC）メッセージ、セクション5.7、および[RFC5974]で説明されたQoS-NSLP-RMFのAPIを参照してください。ドメイン内RESERVEメッセージは<MSG-ID>オブジェクトを搬送し、その結合したエンド・ツー・エンドのRESERVEメッセージは<BOUND-MSG-ID>オブジェクトを運ぶことに留意されたいです。これらのオブジェクトの両方が「1」の値に設定<Message_Binding_Type>フラグを運びます。これら2件のメッセージがMsgIDWaitタイマーによって定義された時間の間に到着しない場合は、予約は失敗したと考えられています。タイマーが事前に設定する必要があり、それがRMDドメインで同じ値を有していなければならないことに注意してください。この場合、エンドツーエンドの応答メッセージ[RFC5974]に記載されたQoS-NSLP-RMFのAPIを参照に、次の<INFO-SPEC>値とQNE進入に向けて送信されます。
Error class: Transient Failure Error code: Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE
Errorクラス：一時的なエラーエラーコード：エンドツーエンドRESERVE間のミスマッチの同期や、ドメイン内RESERVE
When the intra-domain RESERVE (RMD-QSPEC) is received by the QNE Egress node of the session associated with the intra-domain RESERVE(RMD-QSPEC) (the PHB session) with the session included in its <BOUND-SESSION-ID> object MUST be bound according to the specification given in [RFC5974]. The SESSION-ID included in the BOUND-SESSION-ID parameter stored in the intra-domain QoS-NSLP operational state object is the SESSION-ID of the session associated with the end-to-end RESERVE message(s). Note that if the QNE Edge nodes maintain per-flow intra-domain QoS-NSLP operational states, then the value of Binding_Code = (Tunnel and end-to-end sessions) is used. If the QNE Edge nodes maintain per-aggregated QoS-NSLP intra-domain reservation states, then the value of Binding_Code = (Aggregated sessions), see Sections 4.3.1 and 4.3.2.
ドメイン内RESERVE（RMD-QSPEC）は、その<BOUND-SESSION-IDに含まれるセッションにドメイン内RESERVE（RMD-QSPEC）（PHBセッション）に関連付けられたセッションのQNE出口ノードによって受信されると>オブジェクトは、[RFC5974]で与えられた仕様に従ってバインドする必要があります。セッションIDは、ドメイン内のQoS-NSLP動作状態オブジェクトに格納されBOUND-SESSION-IDパラメータに含まれるエンド・ツー・エンドのRESERVEメッセージ（単数または複数）に関連付けられたセッションのセッションIDです。 QNEエッジノードは、フロー毎のドメイン内のQoS-NSLP動作状態を維持する場合、Binding_Code =（トンネルとエンドツーエンドセッション）の値が使用されていることに注意してください。 QNEエッジノードごとの集計のQoS-NSLPドメイン内の予約状態を維持する場合、Binding_Code =（アグリゲートされたセッション）の値は、セクション4.3.1および4.3.2を参照します。
If the RMD domain supports preemption during the admission control process, then the QNE Egress node can support the building blocks specified in the [RFC5974] and during the admission control process use the example preemption handling algorithm described in Appendix A.7.
RMD領域は、アドミッション制御プロセス中にプリエンプションをサポートしている場合、QNE出口ノードは、[RFC5974]で指定されたビルディングブロックをサポートし、アドミッション制御プロセス中の付録A.7で説明した例プリエンプション処理アルゴリズムを使用することができます。
The end-to-end RESERVE message is generated/forwarded further upstream according to the [RFC5974] and [RFC5975] specifications. Furthermore, the <B> (BREAK) QoS-NSLP flag in the end-to-end RESERVE message MUST NOT be set, see the QoS-NSLP-RMF API described in QoS-NSLP.
エンドツーエンドのRESERVEメッセージが生成/ [RFC5974]及び[RFC5975]の仕様に応じてさらに上流に転送されます。また、<B>（BREAK）のQoS-NSLPフラグでエンドツーエンドのRESERVEメッセージは、QoS-NSLPに記載のQoS-NSLP-RMFのAPIを参照して、設定してはいけません。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | RESERVE
| | | |-->
| | | RESPONSE
| | | |<--
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
Figure 8: Basic operation of successful reservation procedure used by the RMD-QOSM
図8：RMD-QOSMで使用される成功した予約手続きの基本操作
The QNE Egress MUST generate an intra-domain RESPONSE (RMD-Qspec) message. The intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the QNE Ingress node, i.e., the previous stateful hop by using the procedures described in Sections 4.4 and 4.5.
QNE出口は、ドメイン内RESPONSE（RMD-Qspec）メッセージを生成しなければなりません。イントラドメインRESPONSE（RMD-QSPEC）メッセージは、セクション4.4および4.5に記載の手順を用いて、すなわち、QNE Ingressノードにステートフル前ホップを送らなければなりません。
The values of the RMD-QSPEC that are carried by the intra-domain RESPONSE message MUST be used and/or set in the following way (see the QoS-NSLP-RMF API described in [RFC5974]):
ドメイン内RESPONSEメッセージによって運ばれるRMD-QSPECの値は、（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）を使用し、および/または以下のように設定しなければなりません。
* the <RII> object carried by the intra-domain RESERVE message, see Section 4.6.1.1.1, has to be copied and carried by the intra-domain RESPONSE message.
*ドメイン内RESERVEメッセージによって運ば<RII>オブジェクトは、セクション4.6.1.1.1を参照し、コピーし、ドメイン内RESPONSEメッセージによって運ばれなければなりません。
* the value of the <Parameter ID> field of the PDR container MUST be set to "23" (i.e., PDR_Reservation_Report);
* PDRコンテナの<パラメータID>フィールドの値が「23」（すなわち、PDR_Reservation_Report）に設定しなければなりません。
* the value of the <M> field of the PDR container MUST be equal to the value of the <M> parameter of the PHR container that was carried by its associated intra-domain RESERVE(RMD-QSPEC) message. This is REQUIRED since the value of the <M> parameter is used to indicate the status if the RMD reservation request to the Ingress Edge.
* PDRコンテナの<M>フィールドの値は、その関連ドメイン内RESERVE（RMD-QSPEC）メッセージによって運ばれたPHR容器の<M>パラメータの値に等しくなければなりません。 <M>パラメータの値は、ステータスを示すために使用されるので、これは必要な場合に入口エッジにRMD予約要求。
If the binding between the intra-domain session and the end-to-end session uses a Binding_Code that is (Aggregated sessions), and there is no aggregated QoS-NSLP operational state associated with the intra-domain session available, then the RMD modification of aggregated reservation procedure described in Section 4.6.1.4 can be used.
ドメイン内のセッションの間の結合およびエンドツーエンドセッション（アグリゲートされたセッション）であるBinding_Codeを使用し、利用可能なドメイン内のセッションに関連する凝集のQoS-NSLP動作状態が存在しない場合、RMDの変形ならセクション4.6.1.4に記載の凝集予約手順を使用することができます。
If the QNE Egress receives an end-to-end RESPONSE message, it is processed and forwarded towards the QNE Ingress. In particular, the non-default values of the objects contained in the end-to-end RESPONSE message MUST be used and/or set by the QNE Egress as follows (see the QoS-NSLP-RMF API described in [RFC5974]):
QNE出口は、エンドツーエンドの応答メッセージを受信した場合、それは処理され、QNE進入向かって転送されます。次のように具体的には、エンドツーエンドの応答メッセージに含まれるオブジェクトの非デフォルト値が使用されなければならない、および/またはQNE出口によって設定された（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）。
* the values of the <RII>, <RSN>, <INFO-SPEC>, [<QSPEC>] objects are set according to [RFC5974] and/or [RFC5975]. The <INFO-SPEC> object SHOULD be set by the QoS-NSLP functionality. In the case of successful reservation, the <INFO-SPEC> object SHOULD have the following values:
* <RII>、<RSN>、<INFO-SPEC>の値は、[<QSPEC>]オブジェクトは、[RFC5974]及び/又は[RFC5975]に応じて設定されます。 <INFO-SPEC>オブジェクトは、QoS-NSLP機能によって設定されるべきです。成功した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持っている必要があります。
Error severity class: Success Error code value: Reservation successful
エラーの重大度クラス：成功エラーコード値：成功予約
* furthermore, an initial QSPEC object MUST be included in the end-to-end RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values.
*また、初期QSPECオブジェクトは、エンドツーエンドの応答メッセージに含まれなければなりません。 QSPEC <確保されたQoS>に含まれるパラメータは、オブジェクトは、値が元の<望ましいQoS>からコピーされます。
The end-to-end RESPONSE message is delivered as normal, i.e., is addressed and sent to its upstream QoS-NSLP neighbor, i.e., the QNE Ingress node.
エンドツーエンドの応答メッセージは通常どおり配信され、すなわち、アドレス指定およびその上流のQoS-NSLP隣接、すなわち、QNE Ingressノードへ送信されます。
Note that if a QNE Egress receives an end-to-end QUERY that was bypassed through the RMD domain, it MUST stop the marking process that was used to bypass the QNE Interior nodes. This can be done by reassigning the QoS-NSLP default NSLPID value to the end-to-end QUERY message; see Section 4.4.
QNE出口がRMDドメインを介してバイパスされたエンドツーエンドのクエリを受信した場合、それはQNEインテリアノードをバイパスするために使用されたマーキングプロセスを停止しなければならないことに留意されたいです。これは、エンドツーエンドのQUERYメッセージへのQoS-NSLPのデフォルトNSLPID値を再割り当てすることによって行うことができます。 4.4節を参照してください。
This subsection describes the operation where a request for reservation cannot be satisfied by the RMD-QOSM.
ここでは、予約要求がRMD-QOSMによって満たすことができない動作を説明します。
The QNE Ingress, the QNE Interior, and QNE Egress nodes process and forward the end-to-end RESERVE message and the intra-domain RESERVE(RMD-QSPEC) message in a similar way, as specified in Section 4.6.1.1. The main difference between the unsuccessful operation and successful operation is that one of the QNE nodes does not admit the request, e.g., due to lack of resources. This also means that the QNE Edge node MUST NOT forward the end-to-end RESERVE message towards the QNR node.
QNE進入、QNEインテリア、及びQNE出口ノード処理及びセクション4.6.1.1で指定されるように、エンドツーエンドのRESERVEメッセージと同様にドメイン内RESERVE（RMD-QSPEC）メッセージを転送します。失敗した操作と正常な動作の主な違いは、QNEノードの一つは、リソース不足のため、例えば、要求を認めていないということです。また、これはQNEエッジノードはQNRノードに向けて、エンドツーエンドのRESERVEメッセージを転送してはならないことを意味します。
Note that the described functionality applies to the RMD reservation-based methods (see Sections 4.3.1 and 4.3.2) and to the NSIS measurement-based admission control method (see Section 4.3.2).
説明された機能（セクション4.3.2を参照）RMD予約ベースの方法（セクション4.3.1および4.3.2を参照）とNSIS測定ベースのアドミッション制御方法に適用されることに留意されたいです。
The QNE Edge nodes maintain either per-flow QoS-NSLP reservation states or aggregated QoS-NSLP reservation states. When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY accomplish an RMD modification procedure (see Section 4.6.1.4), instead of the reservation initiation procedure that is described in this subsection.
QNEエッジノードは、いずれかのフローごとのQoS-NSLP予約状態または凝集のQoS-NSLP予約状態を維持します。 QNEエッジが凝集したQoS-NSLP予約状態を維持する場合、RMD-QOSM機能は、代わりにこのサブセクションに記載された予約開始手順の、RMD修正手順（セクション4.6.1.4を参照）を達成することができます。
When an end-to-end RESERVE message arrives at the QNE Ingress and if (1) the "Maximum Packet Size-1 (MPS)" included in the end-to-end QoS Model <TMOD-1> is larger than this smallest MTU value within the RMD domain or (2) there are no resources available, the QNE Ingress MUST reject this end-to-end RESERVE message and send an end-to-end RESPONSE message back to the sender, as described in the QoS-NSLP specification, see [RFC5974] and [RFC5975].
エンドツーエンドのRESERVEメッセージはQNEイングレスに到着し、（1）「最大パケットサイズ-1（MPS）は、」エンドツーエンドのQoSモデル<TMOD-1>に含まれている場合は、この最小よりも大きい場合MTUのRMDのドメイン内の値又は（2）利用可能なリソースが存在しない、QNEイングレスは、このエンドツーエンドのRESERVEメッセージを拒絶しなければなりませんし、QoS-に記載されているように、送信者へのエンドツーエンドの応答メッセージを送信NSLP仕様は、[RFC5974]と[RFC5975]を参照してください。
When an end-to-end RESPONSE message is received by an Ingress node (see Section 4.6.1.2.3), the values of the <RII>, <RSN>, <INFO-SPEC>, and [<QSPEC>] objects are processed according to the QoS-NSLP procedures.
エンドツーエンドの応答メッセージはIngressノードによって受信されると（セクション4.6.1.2.3参照）、<RII>、<RSN>、<INFO-SPEC>の値、および[<QSPEC>]オブジェクトQoSの-NSLPの手順に従って処理されます。
If the end-to-end RESPONSE message has to be forwarded upstream to a node outside the RMD-QOSM-aware domain, then the values of the objects contained in this message (i.e., <RII<, <RSN>, <INFO-SPEC>, [<QSPEC>]) MUST be set by the QoS-NSLP protocol functions of the QNE.
エンドツーエンドの応答メッセージは、RMD-QOSM認識ドメイン外のノードへアップストリームに転送されなければならない場合、オブジェクトの値は、このメッセージに含まれている（すなわち、<RII <、<RSN>、<INFO- SPEC> [<QSPECは>]）QNEののQoS-NSLPプロトコル機能によって設定されなければなりません。
When an intra-domain RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress (see Section 4.6.1.2.3), it uses the QoS-NSLP procedures to match it to the intra-domain RESERVE message that was previously sent. After this phase, the RMD-QSPEC has to be identified and processed. Note that, in this case, the RMD Resource Management Function (RMF) is notified that the reservation has been unsuccessful, by reading the <M> parameter of the PDR container. Note that when the QNE Edges maintain a per-flow QoS-NSLP reservation state, the RMD-QOSM functionality, has to start an RMD release procedure (see Section 4.6.1.5). When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4).
ドメイン内の応答メッセージは（セクション4.6.1.2.3参照）QNE退出によって送信されたQNE Ingressノードによって受信されると、そのドメイン内のRESERVEメッセージにそれを一致させるのQoS-NSLPの手順を使用し以前に送信されました。この段階の後、RMD-QSPECを識別し、処理しなければなりません。なお、この場合には、RMDリソース管理機能（RMF）は予約がPDRコンテナの<M>のパラメータを読み込むことで、失敗したことが通知されます。 QNEエッジは、フロー単位のQoS-NSLPの予約状態を維持する場合、RMD-QOSM機能は、RMD解放手順（セクション4.6.1.5を参照）を開始することがあることに注意してください。 QNEのエッジが集約されたQoS-NSLPの予約状態を維持する場合、RMD-QOSM機能は、RMDの変更手順（セクション4.6.1.4を参照）を起動することがあります。
In the case of the RMD reservation-based scenario, and if the intra-domain reservation request is not admitted by the QNE Interior node, then the <Hop_U> and <M> parameters of the PHR container MUST be set to "1". The <Admitted Hops> counter MUST NOT be increased. Moreover, the value of the <Max Admitted Hops> counter MUST be set equal to the <Admitted Hops> value.
RMD予約ベースのシナリオの場合には、イントラドメイン予約要求がQNEインテリアノードによって認められない場合、PHRコンテナの<Hop_U>と<M>パラメータが「1」に設定しなければなりません。 <入所ホップ>カウンタが増加してはなりません。また、の値カウンタ<是認ホップ>の値に等しく設定されなければならない<最大ホップが許可しました>。
Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. In the case of the RMD measurement-based scenario, the <M> parameter of the PHR container MUST be set to "1". Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. Note that the <M> flag seems to be set in a similar way to the <E> flag used by the local RMD-QSPEC <TMOD-1> parameter. However, the ways in which the two flags are processed by a QNE are different.
<E>フラグが関連付けられ、さらに、QSPEC <QoSの希望>オブジェクトとローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<E>フラグがセットされるべきです。 RMD測定ベースシナリオの場合に、PHR容器の<M>パラメータが「1」に設定しなければなりません。 <E>フラグが関連付けられ、さらに、QSPEC <QoSの希望>オブジェクトとローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<E>フラグがセットされるべきです。 <M>フラグがローカルRMD-QSPEC <TMOD-1>パラメータが使用する<E>フラグと同様に設定されているように見えることに留意されたいです。しかし、2つのフラグはQNEによって処理される方法が異なっています。
In general, if a QNE Interior node receives an RMD-QSPEC <TMOD-1> parameter with the <E> flag set and a PHR container type "PHR_Resource_Request", with the <M> parameter set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed. Furthermore, when the <K> parameter that is included in the "PHR Container" and carried by a RESERVE message is set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed.
一般的に、QNEインテリアノードは、この "、<E>フラグセットと「1」にセット<M>パラメータとPHR容器種類「PHR_Resource_Request」とRMD-QSPEC <TMOD-1>パラメータを受信した場合PHRコンテナ」とRMD-QOSM <望ましいQoS>オブジェクト）が処理されてはなりません。 「PHRコンテナ」に含まれ、RESERVEメッセージによって運ばれる<K>パラメータが設定されている場合また、「1」、この「PHRコンテナ」とオブジェクトRMD-QOSM <望ましいQoS>）があるはずがありません処理されました。
In the RMD reservation-based (Section 4.3.3) and RMD NSIS measurement-based scenarios (Section 4.3.2), when the <M> marked intra-domain RESERVE(RMD-QSPEC) is received by the QNE Egress node (see Figure 9), the session associated with the intra-domain RESERVE(RMD-QSPEC) (the PHB session) and the end-to-end session MUST be bound.
RMD予約ベースで<M>マークドメイン内RESERVE（RMD-QSPEC）はQNE出口ノードによって受信される（セクション4.3.3）とRMD NSIS測定ベースシナリオ（4.3.2）は、（参照図9）、ドメイン内RESERVE（RMD-QSPEC）（PHBセッション）と、エンドツーエンドセッションに関連するセッションがバインドされなければなりません。
Moreover, if the initial QSPEC object (used by the end-to-end QoS Model) used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, i.e., the intra-domain RESERVE(RMD-QSPEC) message is marked, it MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to-end) reservation is considered as to have failed.
また、（エンド・ツー・エンドのQoSモデルで使用される）初期QSPECオブジェクトは、<利用可能なQoS>が移入されるタイプ1又は2のオブジェクトの組み合わせ、およびドメイン内RESERVE（RMD-QSPEC）ではありませんでしたを使用した場合すなわち、RMDドメイン内のすべてのノードで成功し、ドメイン内RESERVE（RMD-QSPEC）メッセージがマークされている、<QoSの利用>が成立せず、ドメイン間（エンドツーエンドということを考えなければなりません）予約が失敗したと見なされます。
When the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), then the QNE Egress node MUST generate an end-to-end RESPONSE message that has to be sent to its previous stateful QoS-NSLP hop (see the QoS-NSLP-RMF API described in [RFC5974]).
QNE出口あたりフロードメイン内のQoS-NSLP動作状態を（セクション4.3.2および4.3.3を参照）を使用する場合、次にQNE出口ノードは、に送信する必要があり、エンドツーエンドの応答メッセージを生成しなければなりません前ステートフルなQoS-NSLPホップ（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）。
* the values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values:
* <RII>の値は、<RSN>と<INFO-SPEC>オブジェクトは、標準のQoS-NSLPプロトコル機能によって設定されます。失敗した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持っている必要があります。
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
The QSPEC that was carried by the end-to-end RESERVE message that belongs to the same session as this end-to-end RESPONSE message is included in this message.
このエンドツーエンドの応答メッセージは、このメッセージに含まれているのと同じセッションに属するエンド・ツー・エンドのRESERVEメッセージによって運ばれたQSPEC。
In particular, the parameters included in the QSPEC <QoS Reserved> object of the end-to-end RESPONSE message are copied from the initial <QoS Desired> values included in its associated end-to-end RESERVE message. The <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the <TMOD-1> parameter included in the end-to-end RESPONSE are set.
具体的には、パラメータはQSPEC <QoSが確保>エンドツーエンドRESPONSEメッセージの目的は、その関連するエンドツーエンドのRESERVEメッセージに含まれる値が初期<望ましいQoS>からコピーされているに含まれます。 <QoSが確保> QSPECオブジェクトと<TMOD-1>に関連付けられている<E>フラグに関連付けられた<E>フラグパラメータが設定され、エンドツーエンドの応答に含まれます。
In addition to the above, similar to the successful operation, see Section 4.6.1.1.3, the QNE Egress MUST generate an intra-domain RESPONSE message that has to be sent to its previous stateful QoS-NSLP hop.
上記に加えて、成功した動作と同様に、セクション4.6.1.1.3は、QNE退出は、その前のステートフルなQoS-NSLPホップに送信されなければならないドメイン内RESPONSEメッセージを生成しなければならない参照。
The values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values (see the QoS-NSLP-RMF API described in [RFC5974]):
<RII>、<RSN>の値とは、<INFO-SPEC>オブジェクトは、標準のQoS-NSLPプロトコル機能によって設定されます。失敗した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持っているべきである（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）。
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:M=0) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:M=1) |
| |------------------>| |
| | | RESERVE(RMD-QSPEC:M=1)
| | |------------------->|
| |RESPONSE(RMD-QOSM) | |
|<------------------------------------------------------------|
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops>
|------------------->| | |
|RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
Figure 9: Basic operation during unsuccessful reservation
initiation used by the RMD-QOSM
The values of the RMD-QSPEC MUST be used and/or set in the following way (see the QoS-NSLP-RMF API described in [RFC5974]):
RMD-QSPECの値が使用され、および/または（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）、以下のように設定しなければなりません。
* the value of the <PDR Control Type> of the PDR container MUST be set to "23" (PDR_Reservation_Report);
* PDRコンテナの<PDR制御タイプ>の値が「23」（PDR_Reservation_Report）に設定しなければなりません。
* the value of the <Max Admitted Hops> parameter of the PHR container included in the received <M> marked intra-domain RESERVE (RMD-QSPEC) MUST be included in the <Max Admitted Hops> parameter of the PDR container;
; *の値PHR容器のパラメータを受信<M>ドメイン内RESERVE（RMD-QSPECが）で<Maxはホップを認め> PDR容器のパラメータを含まなければなりませんマークに含まれる<最大ホップを認め>
* the value of the <M> parameter of the PDR container MUST be "1".
* PDRコンテナの<M>パラメータの値が「1」でなければなりません。
In the case of the RMD measurement-based method, see Section 4.3.2, QoS-NSLP reservation states in the RMD domain are not typically maintained, therefore, this method typically does not use an intra-domain refresh procedure.
RMD測定に基づく方法の場合、セクション4.3.2を参照に、RMDドメインにおけるQoS-NSLPの予約状態は、典型的には維持されないため、この方法は、典型的には、ドメイン内のリフレッシュ・プロシージャを使用していません。
However, there are measurement-based optimization schemes, see [GrTs03], that MAY use the refresh procedures described in Sections 4.6.1.3.1 and 4.6.1.3.3. However, this measurement-based optimization scheme can only be applied in the RMD domain if the QNE Edges are configured to perform intra-domain refresh procedures and if all the QNE Interior nodes are configured to perform the measurement-based optimization schemes.
しかしながら、セクション4.6.1.3.1と4.6.1.3.3に記載されたリフレッシュ・プロシージャを使用できること、[GrTs03]参照、測定ベースの最適化スキームが存在します。しかし、この測定に基づく最適化方式は、QNEエッジがドメイン内の更新手順を実行するように構成されている場合のみRMD領域に適用することができ、全てのQNE内部ノードは、測定ベースの最適化スキームを実行するように構成されている場合。
In the description given in this subsection, it is assumed that the RMD measurement-based scheme does not use the refresh procedures.
このサブセクションでの説明では、RMDの測定に基づく方式は、リフレッシュ・プロシージャを使用しないことが想定されます。
When the QNE Edges maintain aggregated or per-flow QoS-NSLP operational and reservation states (see Sections 4.3.1 and 4.3.3), then the refresh procedures are very similar. If the RESERVE messages arrive within the soft state timeout period, the corresponding number of resource units are not removed. However, the transmission of the intra-domain and end-to-end (refresh) RESERVE message are not necessarily synchronized. Furthermore, the generation of the end-to-end RESERVE message, by the QNE Edges, depends on the locally maintained refreshed interval (see [RFC5974]).
QNEエッジが凝集またはフローごとのQoS-NSLP動作と予約状態を維持するとき（セクション4.3.1および4.3.3を参照）、次にリフレッシュ手順は非常に類似しています。 RESERVEメッセージは柔らかい状態のタイムアウト期間内に到着した場合、リソースユニットの対応する数は除去されません。しかし、ドメイン内およびエンド・ツー・エンド（リフレッシュ）RESERVEメッセージの送信は、必ずしも同期していません。また、エンドツーエンドのRESERVEメッセージの生成は、QNEエッジによって、局所的に維持リフレッシュ間隔に依存する（[RFC5974]を参照）。
The Ingress node MUST be able to generate an intra-domain (refresh) RESERVE(RMD-QSPEC) at any time defined by the refresh period/timer. Before generating this message, the RMD QoS signaling model functionality is using the RMD traffic class (PHR) resource units for refreshing the RMD traffic class state.
Ingressノードは、リフレッシュ周期/タイマーによって定義され、いつでもイントラドメイン（リフレッシュ）RESERVE（RMD-QSPEC）を生成することができなければなりません。このメッセージを生成する前に、RMDのQoSシグナリング・モデルの機能は、RMDトラフィッククラスの状態をリフレッシュするためのRMDトラフィッククラス（PHR）リソースユニットを使用しています。
Note that the RMD traffic class refresh periods MUST be equal in all QNE Edge and QNE Interior nodes and SHOULD be smaller (default: more than two times smaller) than the refresh period at the QNE Ingress node used by the end-to-end RESERVE message. The intra-domain RESERVE (RMD-QSPEC) message MUST include an RMD-QOSM <QoS Desired> and a PHR container (i.e., PHR_Refresh_Update).
エンド・ツー・エンドRESERVEで使用QNE入口ノードにおけるリフレッシュ周期より：RMDトラフィッククラスリフレッシュ期間はすべてのQNEエッジとQNE内部ノードに等しくなければならないと（2倍以上小さいデフォルト）小さくなければならないことに注意してくださいメッセージ。ドメイン内RESERVE（RMD-QSPEC）メッセージは、RMD-QOSM <QoSの希望>とPHRの容器（すなわち、PHR_Refresh_Update）を含まなければなりません。
An example of this refresh operation can be seen in Figure 10.
このリフレッシュ動作の例を図10に見ることができます。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| | | |
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | |
Figure 10: Basic operation of RMD-specific refresh procedure
図10：RMD-固有のリフレッシュ手順の基本操作
Most of the non-default values of the objects contained in this message MUST be used and set by the QNE Ingress in the same way as described in Section 4.6.1.1. The following objects are used and/or set differently:
このメッセージに含まれるオブジェクトの非デフォルト値のほとんどは、セクション4.6.1.1に記載したのと同じ方法でQNE進入によって使用され、設定されなければなりません。次のオブジェクトが使用され、および/または異なって設定されています。
* the PHR resource units MUST be included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter. The <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter depends on how the different inter-domain (end-to-end) flows are aggregated by the QNE Ingress node (e.g., the sum of all the PHR-requested resources of the aggregated flows); see Section 4.3.1. If no QoS-NSLP aggregation is accomplished by the QNE Ingress node, the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter SHOULD be equal to the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of its associated new (initial) intra-domain RESERVE (RMD-QSPEC) message; see Section 4.3.3.
* PHRリソースユニットは、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドに含まれなければなりません。 <ピークデータレート-1（P）>ローカルRMD-QSPECのフィールド値<TMOD-1>パラメータが異なるドメイン間（エンドツーエンド）フローがQNE Ingressノードによって集約される方法に依存する（例えば、集約フローの全てのPHR-要求されたリソースの合計）。 4.3.1項を参照してください。何のQoS-NSLPの凝集がQNE Ingressノードによって達成されていない場合、ローカルRMD-QSPEC <TMOD-1>の<ピークデータレート-1（P）>値は、パラメータが（<ピークデータレート-1に等しくなければなりませんP）>ローカルRMD-QSPEC <TMOD-1の値>それに関連する新たな（初期パラメータ）ドメイン内RESERVE（RMD-QSPEC）メッセージ。セクション4.3.3を参照してください。
* the value of the Container field of the <PHR Container> MUST be set to "19", i.e., "PHR_Refresh_Update".
* <PHRコンテナ>のコンテナフィールドの値が「19」、すなわち、「PHR_Refresh_Update」に設定されなければなりません。
When the intra-domain RESPONSE (RMD-QSPEC) message (see Section 4.6.1.3.3), is received by the QNE Ingress node, then:
ドメイン内RESPONSE（RMD-QSPEC）メッセージ（セクション4.6.1.3.3参照）、次いで、QNE Ingressノードによって受信されます。
* the values of the <RII>, <RSN>, <INFO-SPEC>, and [RFC5975] objects are processed by the standard QoS-NSLP protocol functions (see Section 4.6.1.1);
*の値<RII>、<RSN>、<INFO-SPEC>、および[RFC5975]オブジェクトは、標準のQoS-NSLPプロトコル機能によって処理される（セクション4.6.1.1を参照）。
* the "PDR Container" has to be processed by the RMD-QOSM functionality in the QNE Ingress node. The RMD-QOSM functionality is notified by the <PDR M> parameter of the PDR container that the refresh procedure has been successful or unsuccessful. All sessions associated with this RMD-specific refresh session MUST be informed about the success or failure of the refresh procedure. (When aggregated QoS-NSLP operational and reservation states are used (see Section 4.3.1), there will be more than one session.) In the case of failure, the QNE Ingress node has to generate (in a standard QoS-NSLP way) an error end-to-end RESPONSE message that will be sent towards the QNI.
*「PDRコンテナは、」QNE IngressノードでRMD-QOSM機能によって処理しなければなりません。 RMD-QOSM機能はリフレッシュ手順が成功したか失敗したPDRコンテナの<PDR M>パラメータで通知されます。このRMD-固有のリフレッシュセッションに関連するすべてのセッションは、リフレッシュ手順の成否について通知しなければなりません。 （凝集したQoS-NSLP動作し、予約状態は（）セクション4.3.1を参照して使用される場合、複数のセッションが存在するであろう。）故障の場合には、QNE Ingressノードは、標準のQoS-NSLPの方法で（生成しなければなりませんQNI向けて送信される）エラーエンドツーエンドRESPONSEメッセージ。
The intra-domain RESERVE (RMD-QSPEC) message is received and processed by the QNE Interior nodes. Any QNE Edge or QNE Interior node that receives a <PHR_Refresh_Update> field MUST identify the traffic class state (PHB) (using the <PHB Class> parameter). Most of the parameters in this refresh intra-domain RESERVE (RMD-QSPEC) message MUST be used and/or set by a QNE Interior node in the same way as described in Section 4.6.1.1.
ドメイン内RESERVE（RMD-QSPEC）メッセージが受信され、QNEインテリアノードによって処理されます。 <PHR_Refresh_Update>フィールドを受信する任意のQNEエッジ又はQNE内部ノードが（<PHBクラス>パラメータを使用して）トラフィッククラスの状態（PHB）を識別しなければなりません。このリフレッシュ・ドメイン内RESERVE（RMD-QSPEC）メッセージ内のパラメータのほとんどは、セクション4.6.1.1に記載したのと同じように使用および/またはQNEインテリアノードによって設定されなければなりません。
The following objects are used and/or set differently:
次のオブジェクトが使用され、および/または異なって設定されています。
* the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> is used by the QNE Interior node for refreshing the RMD traffic class state. These resources (included in the <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1>), if reserved, are added to the currently reserved resources per PHB and therefore they will become a part of the per-traffic class (PHB) reservation state (see Sections 4.3.1 and 4.3.3). If the refresh procedure cannot be fulfilled then the <M> and <S> fields carried by the PHR container MUST be set to "1".
*ローカルRMD-QSPEC RMD-QOSM RMDトラフィッククラスの状態をリフレッシュするためQNE内部ノードによって使用される<望ましいQoS>の<TMOD-1>パラメータ<ピークデータレート-1（P）>値。 （ローカルRMD-QSPEC <TMOD-1>の<ピークデータレート-1（P）>値に含まれる）、これらのリソースは、予約された場合、PHBあたり現在予約されたリソースに追加され、したがって、それらはの一部となります毎のトラフィッククラス（PHB）予約状態（セクション4.3.1と4.3.3を参照してください）。リフレッシュ手順を満たすことができない場合は、PHRコンテナで運ば<M>と<S>フィールドは「1」に設定しなければなりません。
* furthermore, the <E> flag associated with <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set.
*また、ローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<QoSの希望>オブジェクトと<E>フラグに関連付けられた<E>フラグがセットされるべきです。
Any PHR container of type "PHR_Refresh_Update", and its associated local RMD-QSPEC <TMOD-1>, whether or not it is marked and independent of the <E> flag value of the local RMD-QSPEC <TMOD-1> parameter, is always processed, but marked bits are not changed.
タイプの任意PHR容器「PHR_Refresh_Update」、およびそれに関連するローカルRMD-QSPEC <TMOD-1>、それがマークされ、<E>ローカルRMD-QSPEC <TMOD-1>のフラグ値パラメータとは独立しているか否か、常に処理されますが、マークされたビットは変更されません。
The intra-domain RESERVE(RMD-QSPEC) message is received and processed by the QNE Egress node. A new intra-domain RESPONSE (RMD-QSPEC) message is generated by the QNE Egress node and MUST include a PDR (type PDR_Refresh_Report).
ドメイン内RESERVE（RMD-QSPEC）メッセージが受信され、QNE出口ノードによって処理されます。新しいドメイン内RESPONSE（RMD-QSPEC）メッセージは、QNE出口ノードによって生成され、PDR（タイプPDR_Refresh_Report）を含まなければなりません。
The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the QNE Ingress node, i.e., the previous stateful hop. The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be explicitly routed to the QNE Ingress node, i.e., the previous stateful hop, using the procedures described in Section 4.5.
（リフレッシュ）ドメイン内応答（RMD-QSPEC）メッセージは、QNE Ingressノード、すなわち、前ステートフルのホップに送信されなければなりません。 （リフレッシュ）ドメイン内応答（RMD-QSPEC）メッセージを明示的に4.5節に記載の手順を用いて、QNE Ingressノード、すなわち、前ステートフルホップにルーティングされなければなりません。
* the values of the <RII>, <RSN>, and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions, see [RFC5974].
* <RII>の値を、<RSN>、および<INFO-SPEC>オブジェクトは、[RFC5974]を参照し、標準のQoS-NSLPプロトコル機能によって設定されます。
* the value of the <PDR Control Type> parameter of the PDR container MUST be set "24" (i.e., PDR_Refresh_Report). In case of successful reservation, the <INFO-SPEC> object SHOULD have the following values:
* PDRコンテナの<PDR制御タイプ>パラメータの値が「24」（すなわち、PDR_Refresh_Report）設定しなければなりません。成功した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持っている必要があります。
Error severity Class: Success Error code value: Reservation successful
エラーの重大度クラス：成功エラーコード値：成功予約
* In the case of unsuccessful reservation the <INFO-SPEC> object SHOULD have the following values:
*失敗した予約の場合には、<INFO-SPEC>オブジェクトは、次の値を持っている必要があります。
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
The RMD-QSPEC that was carried by the intra-domain RESERVE belonging to the same session as this intra-domain RESPONSE is included in the intra-domain RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. If the reservation is unsuccessful, then the <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are set. Furthermore, the <M> and <S> PDR container bits are set to "1".
このドメイン内RESPONSEと同じセッションに属するドメイン内RESERVEによって運ばれたRMD-QSPECは、ドメイン内の応答メッセージに含まれています。 QSPEC <確保されたQoS>に含まれるパラメータは、オブジェクトは、値が元の<望ましいQoS>からコピーされます。予約が失敗した場合、その後QSPECに関連付けられた<E>フラグは、オブジェクトとローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<E>フラグ<確保されたQoS>が設定されています。また、<M>及び<S> PDR容器ビットが "1" に設定されています。
In the case when the QNE Edges maintain QoS-NSLP-aggregated operational and reservation states and the aggregated reservation has to be modified (see Section 4.3.1) the following procedure is applied:
：QNEエッジがQoS-NSLP凝集運用および予約状態を維持し、集約の予約は、以下の手順が適用される（セクション4.3.1を参照）を変更しなければならない場合には
* When the modification request requires an increase of the reserved resources, the QNE Ingress node MUST include the corresponding value into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>, which is sent together with a "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, the "PHR_Resource_Request" that is associated with the local RMD-QSPEC <TMOD-1> parameter MUST be <M> marked, i.e., the <M> bit is set to the value of "1". In this situation, the RMD-specific operation for unsuccessful reservation will be applied (see Section 4.6.1.2).
*変更要求が予約されたリソースの増加を必要とする場合、QNE Ingressノードは、RMDのローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>の値に対応する値を含まなければなりません「PHR_Resource_Request」制御情報と共に送信される-QOSM <QoSが希望>。 QNEエッジまたはQNEインテリアノードは、要求されたリソースの数を確保できない場合は、関連付けられている「PHR_Resource_Requestは、」ローカルRMD-QSPEC <TMOD-1>パラメータは、<M>マーク、すなわち、<Mでなければなりません>ビットが「1」の値に設定されています。このような状況では、失敗した予約のためのRMD-特定の操作（セクション4.6.1.2を参照）が適用されます。
* When the modification request requires a decrease of the reserved resources, the QNE Ingress node MUST include this value into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>. Subsequently, an RMD release procedure SHOULD be accomplished (see Section 4.6.1.5). Note that if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress does not have to be released, then the <TEAR> flag MUST be set to OFF. This is because the NSLP operational states associated with the aggregated reservation states at the Edge QNEs MUST NOT be turned off. However, if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress has to be released, then the <TEAR> flag MUST be set to ON.
*変更要求が予約されたリソースの減少を必要とする場合、QNE IngressノードがRMD-のローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>値にこの値を含まなければなりませんQOSM <QoSが希望>。その後、RMD解放手順（セクション4.6.1.5を参照）達成されなければなりません。 QNE入口で維持集約の予約に関連付けられた完全な帯域幅を解放する必要がない場合、<TEAR>フラグがOFFに設定しなければならないことに留意されたいです。エッジQNEsで集約された予約状態に関連付けられているNSLP動作状態がオフになってはならないからです。 QNE入口で維持集約の予約に関連付けられた完全な帯域幅が解放されなければならない場合は、その後<TEAR>フラグがONに設定されなければなりません。
It is important to emphasize that this RMD modification scheme only applies to the following two RMD-QOSM schemes:
このRMD修正スキームのみ、以下の2 RMD-QOSMスキームに適用されることを強調することが重要です。
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
*「ごとの集計RMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで、
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
*「ごとの集計RMD予約ベースの」手順「をマーキング比例データパケットによって深刻な輻輳処理」との組み合わせで。
This procedure is applied to all RMD mechanisms that maintain reservation states. If a refresh RESERVE message does not arrive at a QNE Interior node within the refresh timeout period, then the bandwidth requested by this refresh RESERVE message is not updated. This means that the reserved bandwidth associated with the reduced state is decreased in the next refresh period by the amount of the corresponding bandwidth that has not been refreshed, see Section 4.3.3.
この手順は、予約状態を維持し、すべてのRMDメカニズムに適用されます。リフレッシュRESERVEメッセージは、リフレッシュタイムアウト期間内にQNEインテリアノードに到達していない場合、このリフレッシュRESERVEメッセージによって要求された帯域幅が更新されません。これは、還元状態に関連付けられた予約帯域幅は、セクション4.3.3を参照して、リフレッシュされていない対応する帯域幅の量によって次のリフレッシュ期間に減少することを意味します。
This soft state behavior provides certain robustness for the system ensuring that unused resources are not reserved for a long time. Resources can be removed by an explicit release at any time. However, in the situation that an end-to-end (tear) RESERVE is retransmitted (see Section 5.2.4 in [RFC5974]), then this message MUST NOT initiate an intra-domain (tear) RESERVE message. This is because the amount of bandwidth within the RMD domain associated with the (tear) end-to-end RESERVE has already been released, and therefore, this amount of bandwidth within the RMD domain MUST NOT once again be released.
このソフト状態の動作では、未使用のリソースが長時間のために予約されていないことを保証するシステムの特定のロバスト性を提供します。リソースはいつでも明示的に解放することによって除去することができます。しかし、エンドツーエンド（涙）RESERVEが再送される状況では、イントラドメインを開始してはいけませんこのメッセージは（涙）RESERVEメッセージ（[RFC5974]セクション5.2.4を参照）。これが（涙）に関連付けられたRMDドメイン内の帯域幅の量ので、エンド・ツー・エンドRESERVEは、すでにリリースされているされているため、RMDドメイン内の帯域幅のこの量は、再び解放してはなりません。
When the RMD-RMF of a QNE Edge or QNE Interior node processes a "PHR_Release_Request" PHR container, it MUST identify the <PHB Class> parameter and estimate the time period that elapsed after the previous refresh, see also Section 3 of [CsTa05].
RMD-RMF QNEエッジ又はQNE内部のノードが「PHR_Release_Request」PHRコンテナを処理するとき、それは<PHBクラス>パラメータを識別し、以前の更新からの経過時間を推定し、また[CsTa05]のセクション3を参照しなければなりません。
This MAY be done by indicating the time lag, say "T_Lag", between the last sent "PHR_Refresh_Update" and the "PHR_Release_Request" control information container by the QNE Ingress node, see [RMD1] and [CsTa05] for more details. The value of "T_Lag" is first normalized to the length of the refresh period, say "T_period". The ratio between the "T_Lag" and the length of the refresh period, "T_period", is calculated. This ratio is then introduced into the <Time Lag> field of the "PHR_Release_Request". When the above mentioned procedure of indicating the "T_Lag" is used and when a node (QNE Egress or QNE Interior) receives the "PHR_Release_Request" PHR container, it MUST store the arrival time. Then, it MUST calculate the time difference, "T_diff", between the arrival time and the start of the current refresh period, "T_period". Furthermore, this node MUST derive the value of the "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by multiplying the value included in the <Time Lag> parameter with the length of the refresh period, "T_period". If the derived time lag, "T_Lag", is smaller than the calculated time difference, "T_diff", then this node MUST decrease the PHB reservation state with the number of resource units indicated in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> that has been sent together with the "PHR_Release_Request" "PHR Container", but not below zero.
これは、時間遅れを示すことによって行うことができる、最後の送信「PHR_Refresh_Update」とQNE Ingressノードによって「PHR_Release_Request」制御情報容器との間に、[RMD1]および[CsTa05]詳細について参照、「T_Lag」と言います。 「T_Lag」の値が「T_period」と言う、リフレッシュ周期の長さに最初の正規化されています。 「T_Lag」とリフレッシュ周期の長さ、「T_period」との間の比が計算されます。この比率は、その後、「PHR_Release_Request」の<タイムラグ>フィールド内に導入されます。 「T_Lag」を示すの上述の手順が使用され、ノード（QNE退出又はQNEインテリア）「PHR_Release_Request」PHRコンテナを受信すると、到着時刻を格納する必要がある場合。その後、それは到着時刻と現在のリフレッシュ期間、「T_period」の開始との間の時間差、「T_diff」を、計算しなければなりません。また、このノードは、<タイムラグ>パラメータから、「T_Lag」の値を導出しなければなりません。 「T_Lagは、」リフレッシュ期間、「T_period」の長さを持つ<タイムラグ>に含まれる値のパラメータを乗じることにより求めることができます。派生タイムラグ場合、「T_Lag」は、算出した時間差よりも小さい場合、「T_diff」、このノードは、<ピークデータレート-1（P）>で示されるリソースユニットの数とPHB予約状態を減少しなければなりませんではなく、ゼロ以下「PHR_Release_Request」「PHRコンテナ」と一緒に送られてきたRMD-QOSM <望ましいQoS>のローカルRMD-QSPEC <TMOD-1>パラメータのフィールド。
An RMD-specific release procedure can be triggered by an end-to-end RESERVE with a <TEAR> flag set to ON (see Section 4.6.1.5.1), or it can be triggered by either an intra-domain RESPONSE, an end-to-end RESPONSE, or an end-to-end NOTIFY message that includes a marked (i.e., PDR <M> and/or PDR <S> parameters are set to ON) "PDR_Reservation_Report" or "PDR_Congestion_Report" and/or an <INFO-SPEC> object.
RMD固有のリリース手順は（セクション4.6.1.5.1参照）をONに設定する<TEAR>フラグをエンド・ツー・エンドRESERVEによってトリガすることができ、またはそれは、ドメイン内の応答のいずれかによってトリガすることができます。エンドツーエンドの応答、またはエンド・ツー・エンドは、マークされた（すなわち、PDR <M>および/またはPDR <S>パラメータがONに設定されている）を含むNOTIFYメッセージを「PDR_Reservation_Report」または「PDR_Congestion_Report」及び/又は<INFO-SPEC>オブジェクト。
This RMD-explicit release procedure can be triggered by a tear (<TEAR> flag set to ON) end-to-end RESERVE message. When a tear (<TEAR> flag set ON) end-to-end RESERVE message arrives to the QNE Ingress, the QNE Ingress node SHOULD process the message in a standard QoS-NSLP way (see [RFC5974]). In addition to this, the RMD RMF is notified, as specified in [RFC5974].
このRMD-明示的な解放手順は、引裂き（<TEAR> ONに設定されたフラグ）エンドツーエンドのRESERVEメッセージによってトリガすることができます。涙（<TEAR>フラグがONに設定）エンドツーエンドのRESERVEメッセージはQNEイングレスに到着すると、QNE Ingressノードは、標準のQoS-NSLPの方法でメッセージを処理しなければならない（参照[RFC5974]）。 [RFC5974]で指定されるようにこれに加えて、RMD RMFは、通知されます。
Like the scenario described in Section 4.6.1.1., a bypassing procedure has to be initiated by the QNE Ingress node. The bypassing procedure is performed according to the description given in Section 4.4. At the QNE Ingress, the end-to-end RESERVE message is marked, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value that will be used by the GIST message that carries the end-to-end RESERVE message to bypass the QNE Interior nodes.
セクション4.6.1.1に記載されたシナリオのように、バイパス手順は、QNE Ingressノードによって開始されなければなりません。バイパス手順はセクション4.4で与えられた説明に従って行われます。 QNE入口で、エンド・ツー・エンドのRESERVEメッセージは、マークされている、すなわち、にエンドツーエンドのRESERVEメッセージを運ぶGISTメッセージによって使用される別のNSLPID所定値へのQoS-NSLPデフォルトNSLPID値を変更QNEインテリア・ノードをバイパスします。
Before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress.
ドメイン内の涙RESERVEを生成する前に、RMD-QOSMはQNEイングレスに維持RMDトラフィッククラスの状態から要求されたRMD-QOSM帯域幅を解放する必要があります。
This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The <Time Lag> is used as explained in the introductory part of Section 4.6.1.5.
これは、トラフィッククラス（PHB）を識別し、次にRMDトラフィッククラス要求されたリソースの量を差し引くことによって達成することができ、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドに含ま、RMDトラフィッククラス状態に格納されているリソースの総蓄積量から。セクション4.6.1.5の導入部分で説明したように、<タイムラグが>使用されています。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:Tear=1) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:Tear=1) |
| |------------------->| |
| | RESERVE(RMD-QSPEC:Tear=1)
| | |------------------->|
| | | RESERVE
| | | |-->
Figure 11: Explicit release triggered by RESERVE used by the RMD-QOSM
図11：RMD-QOSMで使用RESERVEによってトリガ明示的なリリース
After that, the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-QOSM) message has to be generated. The intra-domain RESERVE (RMD-QSPEC) message MUST include an <RMD QoS object combination> field and a PHR container, (i.e., "PHR_Release_Request") and it MAY include a PDR container, (i.e., PDR_Release_Request). An example of this operation can be seen in Figure 11.
その後、必要な帯域幅は、メッセージが生成されなければならないQNE入力、イントラドメインRESERVE（RMD-QOSM）でRMD-QOSMトラフィッククラスの状態から解放されます。ドメイン内RESERVE（RMD-QSPEC）メッセージは、<RMDのQoSオブジェクトの組み合わせ>フィールドとPHRの容器（すなわち、 "PHR_Release_Request"）を含む必要があり、PDRの容器（すなわち、PDR_Release_Request）を含むことができます。この動作の例は図11に見ることができます。
Most of the non-default values of the objects contained in the tear intra-domain RESERVE message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1. The following objects are set differently (see the QoS-NSLP-RMF API described in [RFC5974]):
ほとんどの涙ドメイン内RESERVEメッセージに含まれるオブジェクトの非デフォルト値は、セクション4.6.1.1に記載したのと同じ方法でQNE Ingressノードによって設定されます。以下のオブジェクトは、（[RFC5974]で説明されたQoS-NSLP-RMFのAPIを参照してください）別々に設定されています。
* The <RII> object MUST NOT be included in this message. This is because the QNE Ingress node does not need to receive a response from the QNE Egress node;
* <RII>オブジェクトは、このメッセージに含まれてはなりません。 QNE IngressノードがQNE出口ノードからの応答を受信する必要がないためです。
* if the release procedure is not applied for the RMD modification of aggregated reservation procedure (see Section 4.6.1.4), then the <TEAR> flag MUST be set to ON;
*解放手順が凝集予約手続きのRMDの修正に適用されていない場合（セクション4.6.1.4を参照）、次に<TEAR>フラグがONに設定されなければなりません。
* the PHR resource units MUST be included into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>;
* PHRリソースユニットは、RMD-QOSM <望ましいQoS>のローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>値に含めなければなりません。
* the value of the <Admitted Hops> parameter MUST be set to "1";
* <入所ホップ>パラメータの値が「1」に設定しなければなりません。
* the value of the <Time Lag> parameter of the PHR container is calculated by the RMD-QOSM functionality (see Section 4.6.1.5) the value of the <Control Type> parameter of the PHR container is set to "18" (i.e., PHR_Release_Request).
* PHRコンテナのパラメータはRMD-QOSM機能によって計算される<タイムラグ>の値がPHRコンテナのパラメータが「18」に設定されている<制御タイプ>の値を（セクション4.6.1.5を参照）（すなわち、PHR_Release_Request）。
Any QNE Interior node that receives the combination of the RMD-QOSM <QoS Desired> object and the "PHR_Release_Request" control information container MUST identify the traffic class (PHB) and release the requested resources included in the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter. This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the "PHR_Release_Request" container is used during the release procedure as explained in the introductory part of Section 4.6.1.5.
RMD-QOSM <QoSの希望>オブジェクト情報コンテナを制御「PHR_Release_Request」トラフィッククラス（PHB）を識別し、要求されたリソースは、<ピークデータレート-1（Pに含まれる解放しなければならないの組み合わせを受信する任意のQNE内部ノード）>ローカルRMD-QSPEC <TMOD-1>パラメータの値。これはRMDトラフィッククラス要求されたリソースの量を差し引くことによって達成することができ、格納されたリソースの総蓄積量から、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドに含まRMDトラフィッククラスの状態インチセクション4.6.1.5の導入部分で説明したように、<タイムラグ>の値が「PHR_Release_Request」コンテナのパラメータが解放手続きの際に使用されます。
The intra-domain tear RESERVE (RMD-QSPEC) message is received and processed by the QNE Egress node. The RMD-QOSM <QoS Desired> and the "PHR RMD-QOSM control" container (and if available the "PDR Container") are read and processed by the RMD QoS node.
イントラドメイン涙RESERVE（RMD-QSPEC）メッセージが受信され、QNE出口ノードによって処理されます。 RMD-QOSM <望ましいQoS>と「PHR RMD-QOSM制御」コンテナ（および可能な場合、「PDRコンテナ」）はRMDのQoSノードによって読み取られて処理されます。
The value of the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> and the value of the <Time Lag> field of the PHR container MUST be used by the RMD release procedure.
ローカルRMD-QSPEC <TMOD-1> <QoSが希望> RMD-QOSMのパラメータの<ピークデータレート-1（P）>フィールドの値と<所要時間>の値PHR容器の分野RMDの解放手順で使用しなければなりません。
This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state.
これは、リソースの総蓄積量から、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールド値に含まれるRMDトラフィッククラス要求されたリソースの量を差し引くことによって達成することができますRMDトラフィッククラスの状態で保存されました。
The end-to-end RESERVE message is forwarded by the next hop (i.e., the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSPEC) message arrives at the QNE Egress node. Furthermore, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4).
エンドツーエンドのRESERVEメッセージは、ドメイン内涙RESERVE（RMD-QSPEC）メッセージがQNE出口ノードに到達した場合にのみ次のホップ（すなわち、QNE出力）によって転送されます。また、QNE退出は、エンドツーエンドRESERVEメッセージにQoS-NSLPデフォルトNSLPID値を再割り当てすることによってQNEインテリアノードをバイパスするために使用されたマーキングプロセスを停止しなければなりません（セクション4.4を参照）。
Note that when the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4) that uses the explicit release procedure, described above in this subsection. Note that if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress has to be released, then the <TEAR> flag MUST be set to ON. Otherwise, the <TEAR> flag MUST be set to OFF, see Section 4.6.1.4.
QNEエッジが凝集したQoS-NSLP予約状態を維持する場合、RMD-QOSM機能は、この節で上述した明示的な解放の手順を使用しRMD修正手順（セクション4.6.1.4を参照）を開始してもよいことに留意されたいです。 QNE入口で維持集約の予約に関連付けられた完全な帯域幅を解放しなければならない場合、その後<TEAR>フラグがONに設定しなければならないことに留意されたいです。そうでなければ、<TEAR>フラグは、セクション4.6.1.4を参照して、OFFに設定しなければなりません。
This RMD explicit release procedure can be triggered by either an intra-domain RESPONSE message with a PDR container carrying among others the <M> and <S> parameters with values <M>=1 and <S>=0 (see Section 4.6.1.2), an intra-domain (refresh) RESPONSE message carrying a PDR container with <M>=1 and <S>=1 (see Section 4.6.1.6.1), or an end-to-end NOTIFY message (see Section 4.6.1.6) with an <INFO-SPEC> object with the following values:
このRMD明示的な解放手順が値で、とりわけ<M>及び<S>のパラメータを運ぶPDR容器とイントラドメイン応答メッセージのいずれかによってトリガすることができる<M> = 1と<S> = 0（4.6節を参照。 1.2）、イントラドメイン（リフレッシュ）とPDR容器を搬送する応答メッセージ<M> = 1と<S> = 1（セクション4.6.1.6.1）、またはNOTIFYメッセージをエンドツーエンド（セクションを参照以下の値を有する<INFO-SPEC>オブジェクトと4.6.1.6）。
Error severity class: Informational Error code value: Congestion situation
エラーの重大度クラス：情報エラーコード値：混雑状況
When the aggregated intra-domain QoS-NSLP operational states are used, an end-to-end NOTIFY message used to trigger an RMD release procedure MAY contain a PDR container that carries an <M> and an <S> with values <M>=1 and <S>=1, and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Refresh_Report" or "PDR_Congestion_Report" container.
集約されたドメイン内のQoS-NSLP動作状態が使用される場合、RMDの解放手順をトリガするために使用されるエンドツーエンドのNOTIFYメッセージは、<M>及び<S>の値と<M>を運ぶPDR容器を含むかもしれ= 1と<S> = 1、及び「PDR_Refresh_Report」または「PDR_Congestion_Report」コンテナに含まれる<PDR帯域>パラメータで帯域幅の値。
Note that in all explicit release procedures, before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress. This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state.
すべての明示的な解放の手順で、ドメイン内の涙RESERVEを生成する前に、RMD-QOSMがQNEイングレスに維持RMDトラフィッククラスの状態から要求されたRMD-QOSM帯域幅を解放しなければならないことに注意してください。これは、トラフィッククラス（PHB）を識別し、次にRMDトラフィッククラス要求されたリソースの量を差し引くことによって達成することができ、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドに含ま、RMDトラフィッククラス状態に格納されているリソースの総蓄積量から。
Figure 12 shows the situation that the intra-domain tear RESERVE is generated after being triggered by either an intra-domain (refresh) RESPONSE message that carries a PDR container with <M>=1 and <S>=1 or by an end-to-end NOTIFY message that does not carry a PDR container, but an <INFO-SPEC> object. The error code values carried by this NOTIFY message are:
図12は、ドメイン内涙RESERVEは、<M> = 1と<S> = 1又はによるエンドとPDR容器を搬送するいずれかのドメイン内（リフレッシュ）RESPONSEメッセージによってトリガされた後に生成される様子を示していますエンドツーエンドPDRコンテナを運ぶことはありませんメッセージが、<INFO-SPEC>オブジェクトを通知します。このNOTIFYメッセージによって運ばれたエラーコード値は以下のとおりです。
Error severity class: Informational Error code value: Congestion situation
エラーの重大度クラス：情報エラーコード値：混雑状況
Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1.
涙ドメイン内RESERVE（RMD-QSPEC）メッセージに含まれるオブジェクトの非デフォルト値のほとんどは、セクション4.6.1.1に記載したのと同じ方法でQNE Ingressノードによって設定されます。
The following objects MUST be used and/or set differently (see the QoS-NSLP-RMF described in [RFC5974]):
次のオブジェクトを使用し、および/または（[RFC5974]に記載-NSLP-RMF QoSを参照）異なるように設定しなければなりません。
* the value of the <M> parameter of the PHR container MUST be set to "1".
* PHRコンテナの<M>パラメータの値が「1」に設定しなければなりません。
* the value of the <S> parameter of the "PHR container" MUST be set to "1".
*「PHRコンテナ」の<S>パラメータの値が「1」に設定しなければなりません。
* the RESERVE message MAY include a PDR container. Note that this is needed if a bidirectional scenario is used; see Section 4.6.2.
* RESERVEメッセージは、PDRコンテナを含むかもしれません。双方向のシナリオが使用されている場合、これは必要とされていることに注意してください。 4.6.2項を参照してください。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| NOTIFY | | |
|<-------------------------------------------------------|
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | |
| ---------------->|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) |
| | | |
| |----------------->| |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | |----------------->|
Figure 12: Basic operation during RMD-explicit release procedure triggered by NOTIFY used by the RMD-QOSM
図12：基本操作RMD-QOSMで使用されるNOTIFYによってトリガRMD-明示的な解放手順の間に
Note that if the values of the <M> and <S> parameters included in the PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1)), then the <Max Admitted Hops> value SHOULD NOT be compared to the <Admitted Hops> value and the value of the <K> field MUST NOT be set. Any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE MUST check the <K> field included in the PHR container. If the <K> field is "0", then the traffic class state (PHB) has to be identified, using the <PHB Class> parameter, and the requested resources included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter have to be released.
<M>及び<S>パラメータは、ドメイン内涙RESERVE（RMD-QOSM）によって運ばれるPHR容器に含まれるの値は（（<M> = 0と<S> = 1）に設定されている場合ことに注意してくださいまたは（<M> = 0と<S> = 0）または（<M> = 1と<S> = 1））、その値<是認ホップ>の値と比較するべきではない<最大ホップが許可>と<K>フィールドの値を設定してはいけません。 <K>フィールドをチェックしなければならないドメイン内涙RESERVEを受ける任意QNEエッジ又はQNEインテリアノードは、PHRの容器に含まれます。 <K>フィールドが「0」である場合には、トラフィッククラスの状態（PHB）は、<PHBクラス>パラメータを使用して、識別される必要があり、要求されたリソースは、<ピークデータレート-1（P）>フィールドに含まローカルRMD-QSPEC <TMOD-1>パラメータの解放する必要があります。
This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure, as explained in the introductory part of Section 4.6.1.5. Afterwards, the QNE Egress node MUST terminate the tear intra-domain RESERVE(RMD-QSPEC) message.
これはRMDトラフィッククラス要求されたリソースの量を差し引くことによって達成することができ、格納されたリソースの総蓄積量から、ローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドに含まRMDトラフィッククラスの状態インチセクション4.6.1.5の導入部分で説明したようにPHRフィールドの<タイムラグ>パラメータの値は、解放手順の間に使用されます。その後、QNE出口ノードは、涙ドメイン内RESERVE（RMD-QSPEC）メッセージを終了しなければなりません。
The RMD-specific release procedure that is triggered by an intra-domain RESPONSE message with an <M>=1 and <S>=0 PDR container (see Section 4.6.1.2) generates an intra-domain tear RESERVE message that uses the combination of the <Max Admitted Hops> and <Admitted_Hops> fields to calculate and specify when the <K> value carried by the "PHR Container" can be set. When the <K> field is set, then the "PHR Container" and the RMD-QOSM <QoS Desired> carried by an intra-domain tear RESERVE MUST NOT be processed.
<M> = 1と<S> = 0 PDR容器（セクション4.6.1.2を参照）内ドメイン応答メッセージによってトリガされるRMD固有のリリース手順は、組み合わせを使用するドメイン内涙RESERVEメッセージを生成します計算および「PHRコンテナ」によって運ばれる<K>の値を設定することができるときに指定し、<Admitted_Hops>フィールド<最大ホップを認め>。 <K>フィールドが設定されている場合は、「PHRコンテナ」とドメイン内の涙RESERVEによって運ばRMD-QOSM <望ましいQoS>は処理されてはなりません。
The RMD-specific explicit release procedure that uses the combination of <Max Admitted Hops>, <Admitted_Hops> and <K> fields to release resources/bandwidth in only a part of the RMD domain, is denoted as RMD partial release procedure.
RMD領域の一部のみにリソース/帯域幅を解放する<Admitted_Hops>、<最大ホップを認め>と<K>フィールド、RMD部分解放手順として示されている。の組み合わせを使用RMD固有の明示的な解放手順
This explicit release procedure can be used, for example, during unsuccessful reservation (see Section 4.6.1.2). When the RMD-QOSM/QoS-NSLP signaling model functionality of a QNE Ingress node receives a PDR container with values <M>=1 and <S>=0, of type "PDR_Reservation_Report", it MUST start an RMD partial release procedure.
この明示的なリリース手順が失敗した予約（セクション4.6.1.2を参照）中に、例えば、使用することができます。 QNE IngressノードのRMD-QOSM /のQoS-NSLPシグナリングモデル機能が値<M> = 1と<S> = 0とPDRコンテナを受信すると、タイプ "PDR_Reservation_Report" のではなく、RMD部分解放手順を開始しなければなりません。
In this situation, after the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-QOSM) message has to be generated. An example of this operation can be seen in Figure 13.
必要な帯域幅がQNEイングレス、ドメイン内RESERVE（RMD-QOSM）でRMD-QOSMトラフィッククラスの状態から解放された後にこのような状況では、メッセージが生成されることがあります。この動作の例を図13に見ることができます。
Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1.
涙ドメイン内RESERVE（RMD-QSPEC）メッセージに含まれるオブジェクトの非デフォルト値のほとんどは、セクション4.6.1.1に記載したのと同じ方法でQNE Ingressノードによって設定されます。
The following objects MUST be used and/or set differently:
次のオブジェクトが使用され、および/または別々に設定しなければなりません。
* the value of the <M> parameter of the PHR container MUST be set to "1".
* PHRコンテナの<M>パラメータの値が「1」に設定しなければなりません。
* the RESERVE message MAY include a PDR container.
* RESERVEメッセージは、PDRコンテナを含むかもしれません。
* the value of the <Max Admitted Hops> carried by the "PHR Container" MUST be set equal to the <Max Admitted Hops> value carried by the "PDR Container" (with <M>=1 and <S>=0) carried by the received intra-domain RESPONSE message that triggers the release procedure.
* <最大ホップを認め>「PHRコンテナ」によって運ばの値が「PDRコンテナ」（と<M> = 1と<S> = 0）によって運ばれる<最大ホップを認め>の値に等しく設定されなければなりません解放手順をトリガ受信ドメイン内RESPONSEメッセージによって運ばれます。
Any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE has to check the value of the <K> field in the "PHR Container" before releasing the requested resources.
ドメイン内の涙RESERVEを受ける任意のQNEエッジまたはQNEインテリアノードは、要求されたリソースを解放する前に、「PHRコンテナ」に<K>フィールドの値をチェックする必要があります。
If the value of the <K> field is "1", then all the QNEs located downstream, including the QNE Egress, MUST NOT process the carried "PHR Container" and the RMD-QOSM <QoS Desired> object by the intra-domain tearing RESERVE.
<K>フィールドの値が「1」であれば、QNE退出を含む下流に位置する全てQNEsは、実施「PHRコンテナ」とRMD-QOSM内ドメインによって<QoSの希望>オブジェクトを処理してはいけませんRESERVEを引き裂きます。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
Node that marked
PHR_Resource_Request
<PHR> object
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| RESPONSE (RMD-QSPEC: M=1) | |
|<------------------------------------------------------------|
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
|------------------->| | |
| |RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| | RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
| | | |
Figure 13: Basic operation during RMD explicit release procedure triggered by RESPONSE used by the RMD-QOSM
図13：RMD-QOSMによって使用される応答によってトリガRMD明示的なリリース手順の間の基本的な操作
If the <K> field value is "0", any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE can release the resources by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure as explained in the introductory part of Section 4.6.1.5.
<K>フィールドの値が「0」である場合、ドメイン内涙RESERVEを受ける任意QNEエッジ又はQNEインテリアノードはRMDトラフィッククラス要求されたリソースの量を差し引くことによってリソースを解放することができ、<ピークデータレート - に含まれますローカルRMD-QSPEC <1（P）>フィールドTMOD-1>パラメータ、RMDトラフィッククラス状態に格納されているリソースの総蓄積量から。セクション4.6.1.5の導入部分で説明したように、<タイムラグ>の値は、PHRフィールドのパラメータは、解放手続きの際に使用されます。
Furthermore, the QNE MUST perform the following procedures.
さらに、QNEは、以下の手順を実行しなければなりません。
If the values of the <M> and <S> parameters included in the "PHR_Release_Request" PHR container are (<M=1> and <S>=0) then the <Max Admitted Hops> value MUST be compared with the calculated <Admitted Hops> value. Note that each time that the intra-domain tear RESERVE is processed and before being forwarded by a QNE, the <Admitted Hops> value included in the PHR container is increased by one.
「PHR_Release_Request」PHRコンテナに含まれる<M>及び<S>パラメータの値である場合（<M = 1>及び0 <S> =）を<最大ホップを認め>値を算出して比較しなければなりません<ホップ>の値を認めました。ドメイン内涙RESERVEは、とQNEによって転送される前に処理されるたびに、PHRの容器に含まれる<入所ホップ>値が1だけ増加することに留意されたいです。
When these two values are equal, the intra-domain RESERVE(RMD-QSPEC) that is forwarded further towards the QNE Egress MUST set the <K> value of the carried "PHR Container" to "1".
これら2つの値が等しい場合、QNE出口に向かってさらに転送されるドメイン内RESERVE（RMD-QSPEC）が「1」に実施「PHRコンテナ」の<K>値を設定する必要があります。
The reason for doing this is that the QNE node that is currently processing this message was the last QNE node that successfully processed the RMD-QOSM <QoS Desired>) and PHR container of its associated initial reservation request (i.e., initial intra-domain RESERVE(RMD-QSPEC) message). Its next QNE downstream node was unable to successfully process the initial reservation request; therefore, this QNE node marked the <M> and <Hop_U> parameters of the "PHR_Resource_Request".
このようにする理由は、現在、このメッセージを処理しているQNEノードが正常にRMD-QOSM <望ましいQoS>を最後に処理QNEノードだったということです）とそれに関連する最初の予約要求（すなわち、初期ドメイン内RESERVEのPHRコンテナ（RMD-QSPEC）メッセージ）。その次のQNE下流のノードが正常に初期の予約リクエストを処理できませんでした。そのため、このQNEノードは "PHR_Resource_Request" の<M>と<Hop_U>パラメータをマーク。
Finally, note that the QNE Egress node MUST terminate the intra-domain RESERVE(RMD-QSPEC) message.
最後に、QNE出口ノードがドメイン内RESERVE（RMD-QSPEC）メッセージを終了する必要があります。
Moreover, note that the above described RMD partial release procedure applies to the situation that the QNE Edges maintain a per-flow QoS-NSLP reservation state.
また、上記RMD部分解放手順がQNEエッジがフロー毎のQoS-NSLP予約状態を維持することを状況に適用記載ことに注意してください。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states and a severe congestion occurs, then the QNE Ingress MAY receive an end-to-end NOTIFY message (see Section 4.6.1.6) with a PDR container that carries the <M>=0 and <S>=1 fields and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO-SPEC> object with the following values:
QNEエッジが凝集ドメイン内のQoS-NSLP動作状態を維持し、重度の輻輳が発生した場合、その後、QNE進入がNOTIFYメッセージをエンドツーエンドを受信することができる<Mを搬送PDR容器と（セクション4.6.1.6を参照） > = 0と<S> = 1つのフィールド及び「PDR_Congestion_Report」コンテナに含まれる<PDR帯域>パラメータで帯域幅の値。また、同一のエンド・ツー・エンドのメッセージが次の値で<INFO-SPEC>オブジェクトを担持NOTIFY。
Error severity class: Informational Error code value: Congestion situation
エラーの重大度クラス：情報エラーコード値：混雑状況
The end-to-end session associated with this NOTIFY message maintains the BOUND-SESSION-ID of the bound aggregated session; see Section 4.3.1. The RMD-QOSM at the QNE Ingress MUST start an RMD modification procedures (see Section 4.6.1.4) that uses the RMD explicit release procedure, described above in this section. In particular, the RMD explicit release procedure releases the bandwidth value included in the <PDR Bandwidth> parameter, within the "PDR_Congestion_Report" container, from the reserved bandwidth associated with the aggregated intra-domain QoS-NSLP operational state.
このNOTIFYメッセージに関連付けられたエンドツーエンドのセッションが結合し凝集セッションのBOUND-SESSION-IDを維持します。 4.3.1項を参照してください。 QNE入口でRMD-QOSMは、この節で上述したRMD明示的なリリース手順を使用すること（セクション4.6.1.4を参照）RMD修正手順を開始しなければなりません。具体的には、RMDの明示的な解放手順は、凝集ドメイン内のQoS-NSLP動作状態に関連付けられた予約帯域から、「PDR_Congestion_Report」コンテナ内<PDR帯域>パラメータに含まれる帯域値を、解放します。
This section describes the operation of the RMD-QOSM when a severe congestion occurs within the Diffserv domain.
このセクションでは、深刻な輻輳がDiffservのドメイン内で発生したRMD-QOSMの動作を説明します。
When a failure in a communication path, e.g., a router or a link failure occurs, the routing algorithms will adapt to failures by changing the routing decisions to reflect changes in the topology and traffic volume. As a result, the rerouted traffic will follow a new path, which MAY result in overloaded nodes as they need to support more traffic. This MAY cause severe congestion in the communication path. In this situation, the available resources, are not enough to meet the REQUIRED QoS for all the flows along the new path.
通信経路における障害が、例えば、ルータまたはリンク障害が発生した場合、ルーティングアルゴリズムが、トポロジおよびトラフィック量の変化を反映するために、ルーティングの決定を変更することにより、障害に適応します。その結果、再ルーティングトラフィックは、彼らがより多くのトラフィックをサポートする必要があるとして、過負荷状態のノードにつながる可能性がある、新しい道をたどるだろう。これは、通信経路における深刻な渋滞を引き起こす可能性があります。このような状況では、利用可能なリソースは、新しいパスに沿ってすべてのフローに必要なQoSを満たすのに十分ではありません。
Therefore, one or more flows SHOULD be terminated, or forwarded in a lower priority queue.
したがって、1または複数のフローが終了し、又は低い優先度のキューに転送されるべきです。
Interior nodes notify Edge nodes by data marking or marking the refresh messages.
インテリアノードは、リフレッシュメッセージをマーキングまたはマーキングデータにより、エッジノードに通知します。
This procedure applies to all RMD scenarios that use an RMD refresh procedure. The QoS-NSLP and RMD are able to cope with congested situations using the refresh procedure; see Section 4.6.1.3.
この手順は、RMDの更新手順を使用するすべてのRMDのシナリオに適用されます。 QoSの-NSLPとRMDは、リフレッシュ・プロシージャを使用して、混雑状況に対処することができます。セクション4.6.1.3を参照してください。
If the refresh is not successful in an QNE Interior node, Edge nodes are notified by setting <S>=1 (<M>=1) marking the refresh messages and by setting the <O> field in the "PHR_Refresh_Update" container, carried by the intra-domain RESERVE message.
リフレッシュQNEインテリアノードで成功しなかった場合、エッジノードを搭載し、<S> = 1（<M> = 1）にリフレッシュメッセージをマーキングし、「PHR_Refresh_Update」容器の<O>フィールドを設定することによって設定することによって通知されますドメイン内RESERVEメッセージによって。
Note that the overload situation can be detected by using the example given in Appendix A.1. In this situation, when the given signaled_overload_rate parameter given in Appendix A.1 is higher than 0, the value of the <Overload> field is set to "1". The calculation of this is given in Appendix A.1 and denoted as the signaled_overload_rate parameter. The flows can be terminated by the RMD release procedure described in Section 4.6.1.5.
過負荷状態は、付録A.1に示す例を用いて検出することができることに留意されたいです。付録A.1に示す所定のsignaled_overload_rateパラメータが0よりも大きい。このような状況において、<過負荷>フィールドの値が「1」に設定されています。この計算は、付録A.1で与えられ、signaled_overload_rateパラメータとして示されています。フローは、セクション4.6.1.5で説明RMD解放手順で終了させることができます。
The intra-domain RESPONSE message that is sent by the QNE Egress towards the QNE Ingress will contain a PDR container with a Parameter ID = 26, i.e., "PDR_Congestion_Report". The values of the <M>, <S>, and <O> fields of this container SHOULD be set equal to the values of the <M>, <S>, and <O> fields, respectively, carried by the "PHR_Refresh_Update" container. Part of the flows, corresponding to the <O>, are terminated, or forwarded in a lower priority queue.
QNE進入向かっQNE退出によって送信されるドメイン内の応答メッセージは、パラメータID = 26、即ち、「PDR_Congestion_Report」とPDRの容器を含むであろう。値は、<M>、<S>、および<O>このコンテナのフィールドは「PHR_Refresh_Updateによって<M>、<S>、および<O>フィールドは、それぞれ、実施の値に等しくなるように設定されてください「コンテナ。流れの一部は、<O>に対応し、終了、またはより低い優先度のキューに転送されます。
The flows can be terminated by the RMD release procedure described in Section 4.6.1.5.
フローは、セクション4.6.1.5で説明RMD解放手順で終了させることができます。
Furthermore, note that the above functionalities also apply to the scenario in which the QNE Edge nodes maintain either per-flow QoS-NSLP reservation states or aggregated QoS-NSLP reservation states.
また、QNEエッジノードは、いずれかのフローごとのQoS-NSLP予約状態または凝集のQoS-NSLP予約状態を維持している上記の機能はまた、シナリオに適用されることに注意してください。
In general, relying on the soft state refresh mechanism solves the congestion within the time frame of the refresh period. If this mechanism is not fast enough, additional functions SHOULD be used, which are described in Section 4.6.1.6.2.
一般に、ソフトステートリフレッシュ機構に依存して、リフレッシュ周期の時間枠内の輻輳を解決します。このメカニズムは十分に速くない場合は、追加機能を使用しなければならない、セクション4.6.1.6.2に記載されています。
4.6.1.6.2. Severe Congestion Handling by Proportional Data Packet Marking
4.6.1.6.2。マーキング比例データパケットによって重度輻輳処理
This severe congestion handling method requires the following functionalities.
この深刻な輻輳処理方法は、以下の機能が必要です。
The detection and marking/re-marking functionality described in this section applies to NSIS-aware and NSIS-unaware nodes. This means however, that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way the "NSIS-aware" nodes do.
このセクションで説明する検出およびマーキング/再マーキング機能は、NSIS認識およびNSIS非対応ノードに適用されます。これは、「NSIS、意識していない」ノードは、彼らが「NSIS対応」ノードが行うのと同じ方法で、輻輳/激しい混雑状況や再マークパケットを検出することができるように構成しなければならないことを、しかし意味します。
The Interior node detecting severe congestion re-marks data packets passing the node. For this re-marking, two additional DSCPs can be allocated for each traffic class. One DSCP MAY be used to indicate that the packet passed a congested node. This type of DSCP is denoted in this document as an "affected DSCP" and is used to indicate that a packet passed through a severe congested node.
ノードを通過厳しい輻輳再マークデータパケットを検出する内部ノード。この再マーキングのために、二つの追加のDSCPは、各トラフィッククラスに割り当てることができます。一つのDSCPは、パケットが輻輳したノードを通過したことを示すために使用されるかもしれません。 DSCPのこのタイプは、「影響を受けたDSCP」として、この文書で示され、パケットがひどい混雑ノードを通過したことを示すために使用されます。
The use of this DSCP type eliminates the possibility that, e.g., due to flow-based ECMP-enabled (Equal Cost Multiple Paths) routing, the Egress node either does not detect packets passed a severely congested node or erroneously detects packets that actually did not pass the severely congested node. Note that this type of DSCP MUST only be used if all the nodes within the RMD domain are configured to use it. Otherwise, this type of DSCP MUST NOT be applied. The other DSCP MUST be used to indicate the degree of congestion by marking the bytes proportionally to the degree of congestion. This type of DSCP is denoted in this document as "encoded DSCP".
このDSCPタイプの使用は例えば、ECMP対応（イコールコストマルチパス）ベースの流れによるルーティング、Egressノードのパケットを検出していないのどちらかがひどく混雑したノードを通過したか、誤って実際にはなかったパケットを検出し、という可能性を排除しますひどく混雑したノードを渡します。 RMDドメイン内のすべてのノードがそれを使用するように構成されている場合DSCPのこのタイプのみ使用されなければならないことに留意されたいです。それ以外の場合は、DSCPのこのタイプは、適用してはなりません。他のDSCPは、混雑度に比例バイトをマークすることによって混雑度を示すために使用されなければなりません。 DSCPのこのタイプは、「エンコードされたDSCP」として、この文書で示されています。
In this document, note that the terms "marked packets" or "marked bytes" refer to the "encoded DSCP". The terms "unmarked packets" or "unmarked bytes" represent the packets or the bytes belonging to these packets that their DSCP is either the "affected DSCP" or the original DSCP. Furthermore, in the algorithm described below, it is considered that the router MAY drop received packets. The counting/measuring of marked or unmarked bytes described in this section is accomplished within measurement periods. All nodes within an RMD domain use the same, fixed-measurement interval, say T seconds, which MUST be preconfigured.
この文書では、用語「マークされたパケット」または「マークされたバイトは」「エンコードされたDSCP」を参照していることに注意してください。用語「マーキングされていないパケット」または「マークされていないバイトが」パケット又はそれらのDSCPが「影響を受けたDSCP」または元のDSCPのいずれかで、これらのパケットに属するバイトを表します。また、以下に説明するアルゴリズムにおいては、ルータは受信したパケットをドロップすることが考えられます。このセクションで説明顕著な又はマークされていないバイトのカウント/測定は、測定期間内に達成されます。 RMDドメイン内のすべてのノードが同一の、固定測定間隔を使用して、事前設定されなければならないT秒は、言います。
It is RECOMMENDED that the total number of additional (local and experimental) DSCPs needed for severe congestion handling within an RMD domain SHOULD be as low as possible, and it SHOULD NOT exceed the limit of 8. One possibility to reduce the number of used DSCPs is to use only the "encoded DSCP" and not to use "affected DSCP" marking. Another possible solution is, for example, to allocate one DSCP for severe congestion indication for each of the AF classes that can be supported by RMD-QOSM.
RMDドメイン内重度輻輳処理に必要な追加（ローカルおよび実験）のDSCPの総数は可能な限り低くすべきであると推奨され、それは使用のDSCPの数を減らすために8つの可能性の限界を超えてはなりません唯一の「エンコードされたDSCP」を使用すると、マーキング「影響を受けたDSCP」を使用することではありません。別の可能な解決策は、RMD-QOSMによって支持することができるAFクラスの各々に対する厳しい輻輳表示ための一つのDSCPを割り当てること、例えば、です。
An example of a re-marking procedure can be found in Appendix A.1.
再マーキング手順の例を付録A.1で見つけることができます。
When the QNE Edges maintain a per-flow intra-domain QoS-NSLP operational state (see Sections 4.3.2 and 4.3.3), then the following procedure is followed. The QNE Egress node applies a predefined policy to solve the severe congestion situation, by selecting a number of inter-domain (end-to-end) flows that SHOULD be terminated or forwarded in a lower priority queue.
QNEエッジは、フローごとのドメイン内のQoS-NSLP動作状態を維持する場合（セクション4.3.2と4.3.3を参照）は、次の手順に従います。 QNE出口ノードは、優先度の低いキューに終端又は転送されるべきであるドメイン間（エンド・ツー・エンド）フローの数を選択することにより、厳しい輻輳状況を解決するために予め定められたポリシーを適用します。
When the RMD domain does not use the "affected DSCP" marking, the Egress MUST generate an Ingress/Egress pair aggregated state, for each Ingress and for each supported PHB. This is because the Edges MUST be able to detect in which Ingress/Egress pair a severe congestion occurs. This is because, otherwise, the QNE Egress will not have any information on which flows or groups of flows were affected by the severe congestion.
RMD領域がマーキング「影響DSCP」を使用しない場合、出口は、各進入のための入口/出口の対凝集状態を生成し、それぞれについてPHBをサポートしなければなりません。エッジがいる入口/出口は、重度の輻輳が発生したペアに検出できなければならないからです。それ以外の場合は、QNE出口が流れたり流れのグループが激しい混雑の影響を受けたその上の任意の情報を持っていないためです。
When the RMD domain supports the "affected DSCP" marking, the Egress is able to detect all flows that are affected by the severe congestion situation. Therefore, when the RMD domain supports the "affected DSCP" marking, the Egress MAY not generate and maintain the Ingress/Egress pair aggregated reservation states. Note that these aggregated reservation states MAY not be associated with aggregated intra-domain QoS-NSLP operational states.
RMDドメインは「影響を受けたDSCP」マーキングをサポートしている場合、出口は厳しい混雑状況の影響を受けている全てのフローを検出することが可能です。 RMDドメインはマーキング「の影響を受けDSCP」をサポートしている場合そのため、出口が生成し、入力/出力ペア集約予約状態を維持しない場合があります。これらの集計予約状態が集約されたドメイン内のQoS-NSLP動作状態に関連付けられているではないかもしれないことに注意してください。
The Ingress/Egress pair aggregated reservation state can be derived by detecting which flows are using the same PHB and are sent by the same Ingress (via the per-flow end-to-end QoS-NSLP states).
入口/出口の対凝集予約状態は、同じPHBを使用しており、（フローごとのエンドツーエンドのQoS-NSLP状態を介して）同一の進入によって送信さ流れる検出することによって導出することができます。
Some flows, belonging to the same PHB traffic class might get other priority than other flows belonging to the same PHB traffic class. This difference in priority can be notified to the Egress and Ingress nodes by either the RESERVE message that carries the QSPEC associated with the end-to-end QoS Model, e.g.,, <Preemption Priority> and <Defending Priority> parameter or using a locally defined policy. The priority value is kept in the reservation states (see Section 4.3), which might be used during admission control and/or severe congestion handling procedures. The terminated flows are selected from the flows having the same PHB traffic class as the PHB of the marked (as "encoded DSCP") and "affected DSCP" (when applied in the complete RMD domain) packets and (when the Ingress/Egress pair aggregated states are available) that belong to the same Ingress/Egress pair aggregate.
同じPHBのトラフィッククラスに属するいくつかのフローは、同じPHBのトラフィッククラスに属する他のフロー以外の優先権を得る可能性があります。優先度におけるこの差は、エンドツーエンドのQoSモデルに関連QSPECを運ぶことRESERVEメッセージのいずれかによって出入りノードに通知することができ、例えば,, <先取り優先権>とパラメータ<優先順位を守る>または局所使用定義されたポリシー。優先順位の値は、アドミッション制御および/または重度輻輳処理手続きの際に使用されるかもしれない予約状態（4.3節を参照）、に保たれています。終了フローがマークされ、「影響を受けたDSCP」（「符号化されたDSCP」という）（完全RMD領域に適用される）パケットのPHBと同じPHBトラフィッククラスを有するフローから選択され、（場合に入口/出口対れます凝集状態は同じ入口/出口の対の集合体に属する）が利用可能です。
For flows associated with the same PHB traffic class, the priority of the flow plays a significant role. An example of calculating the number of flows associated with each priority class that have to be terminated is explained in Appendix A.2.
同じPHBのトラフィッククラスに関連付けられたフローについて、フローの優先順位は、重要な役割を果たしています。付録A.2に説明されて終了しなければならないそれぞれの優先度クラスに関連付けられたフローの数を算出する例。
For the flows (sessions) that have to be terminated, the QNE Egress node generates and sends an end-to-end NOTIFY message to the QNE Ingress node (its upstream stateful QoS-NSLP peer) to indicate the severe congestion in the communication path.
終了しなければならないフロー（セッション）のために、QNE出口ノードは、エンドツーエンド通信パスにおける重度の輻輳を示すために、QNE Ingressノード（その上流ステートフルなQoS-NSLPピア）にNOTIFYメッセージを生成して送信します。
The non-default values of the objects contained in the NOTIFY message MUST be set by the QNE Egress node as follows (see QoS-NSLP-RMF API described in [RFC5974]):
次のようにNOTIFYメッセージがQNE出口ノードによって設定されなければならないに含まれるオブジェクトの非デフォルト値（[RFC5974]に記載のQoS-NSLP-RMFのAPIを参照）。
* the values of the <INFO-SPEC> object is set by the standard QoS-NSLP protocol functions.
* <INFO-SPEC>オブジェクトの値は、標準のQoS-NSLPプロトコル機能によって設定されています。
* the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows:
* <INFO-SPEC>オブジェクトは、エンド・ツー・エンドのフローを終了しなければならないことを通知情報を含まなければなりません。次のようにこの情報は次のとおりです。
Error severity class: Informational
Error code value: Congestion situation
When the QNE Edges maintain a per-aggregate intra-domain QoS-NSLP operational state (see Section 4.3.1), the QNE Edge has to calculate, per each aggregate intra-domain QoS-NSLP operational state, the total bandwidth that has to be terminated in order to solve the severe congestion. The total bandwidth to be released is calculated in the same way as in the situation in which the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states. Note that for the aggregated sessions that are affected, the QNE Egress node generates and sends one end-to-end NOTIFY message to the QNE Ingress node (its upstream stateful QoS-NSLP peer) to indicate the severe congestion in the communication path. Note that this end-to-end NOTIFY message is associated with one of the end-to-end sessions that is bound to the aggregated intra-domain QoS-NSLP operational state.
QNEエッジごとの集計ドメイン内のQoS-NSLP動作状態を維持する場合、QNEエッジは、各集約ドメイン内のQoS-NSLP動作状態ごとに有している総帯域幅を計算しなければならない（4.3.1項参照）深刻な渋滞を解消するために終了すること。リリースされる総帯域幅はQNEのエッジは、フローごとのドメイン内のQoS-NSLP動作状態を維持している状況と同じ方法で計算されます。影響を受けているアグリゲートされたセッションのために、QNE出口ノードを生成し、エンドツーエンド通信パスにおける重度の輻輳を示すために、QNE Ingressノード（その上流ステートフルなQoS-NSLPピア）にNOTIFYメッセージをいずれかを送信することに留意されたいです。このエンドツーエンドのメッセージが集約ドメイン内のQoS-NSLP動作状態に結合されたエンドツーエンドのセッションの1つに関連付けられるNOTIFYことに留意されたいです。
The non-default values of the objects contained in the NOTIFY message MUST be set by the QNE Egress node in the same way as the ones used by the end-to-end NOTIFY message described above for the situation that the QNE Egress maintains a per-flow intra-domain operational state. In addition to this, the end-to-end NOTIFY MUST carry the RMD-QSPEC, which contains a PDR container with a Parameter ID = 26, i.e., "PDR_Congestion_Report". The value of the <S> SHOULD be set. Furthermore, the value of the <PDR Bandwidth> parameter MUST contain the bandwidth associated with the aggregated QoS-NSLP operational state, which has to be released.
エンド・ツー・エンドで使用されるものはQNE出口あたりを維持する状況について上記NOTIFYメッセージとしてNOTIFYメッセージは、同様にQNE出口ノードによって設定されなければならないに含まれるオブジェクトの非デフォルト値-flowドメイン内の動作状態。これに加えて、エンド・ツー・エンドのパラメータID = 26、即ち、「PDR_Congestion_Report」とPDRの容器を含んRMD-QSPECを運ばなければなりませんNOTIFY。 <S>の値を設定する必要があります。また、<PDR帯域>パラメータの値は、解放されなければならない凝集のQoS-NSLP動作状態、関連付けられた帯域幅を含まなければなりません。
Furthermore, the number of end-to-end sessions that have to be terminated will be calculated as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states. Similarly for each, to be terminated, ongoing flow, the Egress will notify the Ingress in the same way as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
さらに、終了する必要があり、エンドツーエンドのセッション数はQNEのエッジは、フローごとのドメイン内のQoS-NSLP動作状態を維持している状況のように計算されます。同様にそれぞれのため、継続的な流れ、終了する、出口はQNEは、フローごとのドメイン内のQoS-NSLP動作状態を維持するエッジの状況と同様に、侵入を通知します。
Note that the QNE Egress SHOULD restore the original <DSCP> values of the re-marked packets; otherwise, multiple actions for the same event might occur. However, this value MAY be left in its re-marking form if there is an SLA agreement between domains that a downstream domain handles the re-marking problem.
QNE出口が再マークされたパケットの元<DSCP>の値を復元する必要がありますことに注意してください。それ以外の場合は、同じイベントに対して複数のアクションが発生する可能性があります。下流のドメインが再マーキング問題を扱うドメイン間のSLAの合意がある場合は、この値は、その再マーキングの形で残すことができます。
An example of a detailed severe congestion operation in the Egress Nodes can be found in Appendix A.2.
出口ノードにおける詳細な深刻な輻輳の動作の例は、付録A.2で見つけることができます。
Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node resolves the severe congestion by a predefined policy, e.g., by refusing new incoming flows (sessions), terminating the affected and notified flows (sessions), and blocking their packets or shifting them to an alternative RMD traffic class (PHB).
（エンドツーエンド）NOTIFYメッセージを受信すると、QNE Ingressノードは影響を受け、通知されたフロー（セッション）の終了、新しい着信フロー（セッション）を拒否し、それらをブロックすることにより、例えば予め定められたポリシーによって重度の輻輳を解消しますパケットまたは代替RMDトラフィッククラス（PHB）にそれらをシフト。
This operation is depicted in Figure 14, where the QNE Ingress, for each flow (session) to be terminated, receives a NOTIFY message that carries the "Congestion situation" error code.
各フロー（セッション）が終了するため、この動作は、QNE進入図14に示され、「渋滞状況」エラーコードを運ぶNOTIFYメッセージを受信します。
When the QNE Ingress node receives the end-to-end NOTIFY message, it associates this NOTIFY message with its bound intra-domain session (see Sections 4.3.2 and 4.3.3) via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP state. The QNE Ingress uses the operation described in Section 4.6.1.5.2 to terminate the intra-domain session.
QNE Ingressノードが受信した場合、エンドツーエンドのNOTIFYメッセージを、これがその結合ドメイン内のセッションにNOTIFYメッセージを関連付ける（セクション4.3.2および4.3.3を参照）の端部に含まBOUND-SESSION-ID情報を介して-to-エンドフロー単位のQoS-NSLP状態。 QNEイングレスは、ドメイン内のセッションを終了するために、セクション4.6.1.5.2に記載の操作を使用しています。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
QUE（入力）QUE（インテリア）QUE（インテリア）QUE（入力）
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|Term.
| NOTIFY S |flow?
|<-----------------|-----------------S------------------|YES
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) S |
| ---------------->|RESERVE(RMD-QSPEC:T=1,M=1,S=1) |
| | S |
| |---------------->S |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | S----------------->|
Figure 14: RMD severe congestion handling
図14：RMD深刻な輻輳処理
Note that the above functionality applies to the RMD reservation-based (see Section 4.3.3) and to both measurement-based admission control methods (i.e., congestion notification based on probing and the NSIS measurement-based admission control; see Section 4.3.2).
セクション4.3.2を参照のこと;上記の機能は、RMD予約ベース（セクション4.3.3を参照）との両方の測定に基づくアドミッション制御方法（すなわち、プロービングおよびNSIS測定ベースのアドミッション制御に基づいて、輻輳通知が適用されることに注意してください）。
In the case that the QNE Edges support aggregated intra-domain QoS-NSLP operational states, the following actions take place. The QNE Ingress MAY receive an end-to-end NOTIFY message with a PDR container that carries an <S> marked and a bandwidth value in the <PDR
QNEが集約されたドメイン内のQoS-NSLP動作状態をサポートするエッジの場合、次のアクションが実行されます。 QNEイングレスは、エンドツーエンドを受信することができる<S>マーク担持PDR容器と<PDRにおける帯域幅の値とNOTIFYメッセージ
Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO-SPEC> object with the "Congestion situation" error code.
帯域幅>「PDR_Congestion_Report」コンテナに含まれるパラメータ。また、同一のエンド・ツー・エンドは、メッセージが「混雑状況」エラーコードで<INFO-SPEC>オブジェクトを担持NOTIFY。
When the QNE Ingress node receives this end-to-end NOTIFY message, it associates the NOTIFY message with the aggregated intra-domain QoS-NSLP operational state via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP operational state, see Section 4.3.1.
QNE Ingressノードが受信した場合、このエンドツーエンドのNOTIFYメッセージを、それがエンド・ツー・エンドのフロー単位に含まBOUND-SESSION-ID情報を介して凝集し、ドメイン内のQoS-NSLP運転状態にNOTIFYメッセージを関連付けますQoSの-NSLP動作状態、4.3.1項を参照してください。
The RMD-QOSM at the QNE Ingress node by using the total bandwidth value to be released included in the <PDR Bandwidth> parameter MUST reduce the bandwidth associated and reserved by the RMD aggregated session. This is accomplished by triggering the RMD modification for aggregated reservations procedure described in Section 4.6.1.4.
放出される総帯域幅の値を用いて、QNE IngressノードでRMD-QOSMは<PDR帯域幅>パラメータに含まれるRMD集約セッションによって関連付けられ、予約された帯域幅を削減しなければなりません。これは、セクション4.6.1.4に記載の凝集予約手続きのためのRMD変更をトリガすることによって達成されます。
In addition to the above, the QNE Ingress MUST select a number of inter-domain (end-to-end) flows (sessions) that MUST be terminated. This is accomplished in the same way as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
上記に加えて、QNE進入を終了しなければならないドメイン間（エンドツーエンド）フロー（セッション）の数を選択しなければなりません。これは、QNEは、フローごとのドメイン内のQoS-NSLP動作状態を維持するエッジの状況と同様に行われます。
The terminated end-to-end sessions are selected from the end-to-end sessions bound to the aggregated intra-domain QoS-NSLP operational state. Note that the end-to-end session associated with the received end-to-end NOTIFY message that notified the severe congestion MUST also be selected for termination.
終了したエンドツーエンドのセッションが集約されたドメイン内のQoS-NSLP動作状態に結合されたエンド・ツー・エンドのセッションから選択されています。重度の輻輳を通知されたエンドツーエンドNOTIFY受信したメッセージに関連付けられたエンドツーエンドのセッションも終了するために選択されなければならないことに留意されたいです。
For the flows (sessions) that have to be terminated, the QNE Ingress node generates and sends an end-to-end NOTIFY message upstream towards the sender (QNI). The values carried by this message are:
終了しなければならないフロー（セッション）のために、QNE Ingressノードは、エンドツーエンドを生成して送信する送信側（QNI）に向かって上流NOTIFYメッセージ。このメッセージによって運ばれる値は次のとおりです。
* the values of the <INFO-SPEC> object set by the standard QoS-NSLP protocol functions.
*標準QoS-NSLPプロトコル機能によって設定された<INFO-SPEC>オブジェクトの値。
* the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows:
* <INFO-SPEC>オブジェクトは、エンド・ツー・エンドのフローを終了しなければならないことを通知情報を含まなければなりません。次のようにこの情報は次のとおりです。
Error severity class: Informational
Error code value: Congestion situation
4.6.1.7. Admission Control Using Congestion Notification Based on Probing
4.6.1.7。アドミッション制御プロービングに基づいて輻輳通知を使用します
The congestion notification function based on probing can be used to implement a simple measurement-based admission control within a Diffserv domain. At Interior nodes along the data path, congestion notification thresholds are set in the measurement-based admission control function for the traffic belonging to different PHBs. These Interior nodes are not NSIS-aware nodes.
プローブに基づく輻輳通知機能は、Diffservのドメイン内の単純な測定ベースのアドミッション制御を実施するために使用することができます。データパスに沿って内部ノードにおいて、輻輳通知閾値が異なるのPHBに属するトラフィックの測定に基づくアドミッション制御機能に設定されています。これらのインテリアノードは、NSIS、気づいていないノードです。
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE), see Figure 15, it is processed based on the procedures defined by the end-to-end QoS Model.
エンドツーエンド予約要求（RESERVE）はIngressノード（QNE）に到着すると、図15参照、それはエンド・ツー・エンドのQoSモデルによって定義された手順に基づいて処理されます。
The <DSCP> field of the GIST datagram message that is used to transport this probe RESERVE message, SHOULD be marked with the same value of DSCP as the data path packets associated with the same session. In this way, it is ensured that the end-to-end RESERVE (probe) packet passed through the node that it is congested. This feature is very useful when ECMP-based routing is used to detect only flows that are passing through the congested router.
このプローブRESERVEメッセージを搬送するために使用されるGISTデータグラムメッセージの<DSCP>フィールドは、同じセッションに関連付けられたデータ・パス・パケットとしてDSCPの同じ値でマークされるべきです。このようにして、エンド・ツー・エンドのRESERVE（プローブ）パケットは、それが輻輳しているノードを通過したことが保証されます。 ECMPベースのルーティングは、輻輳ルータを通過しているだけの流れを検出するために使用される場合、この機能は非常に有用です。
When a (end-to-end) RESPONSE message is received by the Ingress node,it will be processed based on the procedures defined by the end-to-end QoS Model.
（エンドツーエンド）応答メッセージがIngressノードによって受信されると、それはエンド・ツー・エンドのQoSモデルによって定義された手順に基づいて処理されます。
These Interior nodes do not need to be NSIS-aware nodes and they do not need to process the NSIS functionality of NSIS messages. Note that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way the "NSIS-aware" nodes do.
これらのインテリアノードは、NSIS認識ノードである必要はありません、彼らはNSISメッセージのNSISの機能を処理する必要はありません。 「NSISを認識しない」ノードは、彼らが「NSIS対応」ノードが行うのと同じ方法で、輻輳/激しい混雑状況や再マークパケットを検出することができるように構成しなければならないことに注意してください。
Using standard functionalities, congestion notification thresholds are set for the traffic that belongs to different PHBs (see Section 4.3.2). The end-to-end RESERVE message, see Figure 15, is used as a probe packet.
標準機能を使用して、輻輳通知しきい値が異なるのPHB（4.3.2項を参照）に所属するトラフィック用に設定されています。エンドツーエンドのRESERVEメッセージ、図15参照、プローブパケットとして使用されます。
The <DSCP> field of all data packets and of the GIST message carrying the RESERVE message will be re-marked when the corresponding "congestion notification" threshold is exceeded (see Section 4.3.2). Note that when the data rate is higher than the congestion notification threshold, the data packets are also re-marked. An example of the detailed operation of this procedure is given in Appendix A.2.
対応する「輻輳通知」しきい値を超えたときに、すべてのデータ・パケットのリザーブメッセージを運ぶGISTメッセージの<DSCP>フィールドが再マークされます（セクション4.3.2を参照）。データ・レートは、輻輳通知のしきい値よりも高い場合、データパケットはまた、再マークされていることに注意してください。この手順の詳細な動作の一例は、付録A.2に示されています。
As emphasized in Section 4.6.1.6.2.2, the Egress node, by using the per-flow end-to-end QoS-NSLP states, can derive which flows are using the same PHB and are sent by the same Ingress.
セクション4.6.1.6.2.2に強調したように、Egressノードは、フローごとのエンドツーエンドのQoS-NSLP状態を使用して、同じPHBを使用しており、同一の進入によって送信さ流れる導出することができます。
For each Ingress, the Egress SHOULD generate an Ingress/Egress pair aggregated (RMF) reservation state for each supported PHB. Note that this aggregated reservation state does not require that an aggregated intra-domain QoS-NSLP operational state is needed also.
各進入のために、退出が凝集入口/出口の対を生成する必要が各々について（RMF）予約状態は、PHBを支持しました。この集約された予約状態が集約されたドメイン内のQoS-NSLP動作状態も必要であることを必要としないことに注意してください。
Appendix A.4 contains an example of how and when a (probe) RESERVE message that arrives at the Egress is admitted or rejected.
付録A.4は、いつ、どのように出口に到達する（プローブ）RESERVEメッセージが許可または拒否されるの例を含んでいます。
If the request is rejected, then the Egress node SHOULD generate an (end-to-end) RESPONSE message to notify that the reservation is unsuccessful. In particular, it will generate an <INFO-SPEC> object of:
要求が拒否された場合、出口ノードは、予約が失敗したことを通知する（エンドツーエンド）RESPONSEメッセージを生成する必要があります。特に、それはの<INFO-SPEC>オブジェクトを生成します。
Error severity class: Transient Failure Error code value: Reservation failure
エラーの重大度クラス：一時失敗エラーコード値：予約失敗
The QSPEC that was carried by the end-to-end RESERVE that belongs to the same session as this end-to-end RESPONSE is included in this message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. The <E> flag associated with the <QoS Reserved> object and the <E> flag associated with local RMD-QSPEC <TMOD-1> parameter are also set. This RESPONSE message will be sent to the Ingress node and it will be processed based on the end-to-end QoS Model.
このエンドツーエンドの応答は、このメッセージに含まれているのと同じセッションに属するエンド・ツー・エンドRESERVEによって運ばれたQSPEC。 QSPEC <確保されたQoS>に含まれるパラメータは、オブジェクトは、値が元の<望ましいQoS>からコピーされます。 <確保されたQoS>オブジェクトとローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた<E>フラグに関連付けられた<E>フラグも設定されています。この応答メッセージは、Ingressノードに送信され、それは、エンドツーエンドのQoSモデルに基づいて処理されます。
Note that the QNE Egress SHOULD restore the original <DSCP> values of the re-marked packets; otherwise, multiple actions for the same event might occur. However, this value MAY be left in its re-marking form if there is an SLA agreement between domains that a downstream domain handles the re-marking problem. Note that the break <B> flag carried by the end-to-end RESERVE message MUST NOT be set.
QNE出口が再マークされたパケットの元<DSCP>の値を復元する必要がありますことに注意してください。それ以外の場合は、同じイベントに対して複数のアクションが発生する可能性があります。下流のドメインが再マーキング問題を扱うドメイン間のSLAの合意がある場合は、この値は、その再マーキングの形で残すことができます。エンドツーエンドのRESERVEメッセージによって運ばブレーク<B>フラグが設定されてはならないことに注意してください。
QNE(Ingress) Interior Interior QNE(Egress)
(not NSIS aware) (not NSIS aware)
user | | | |
data | user data | | |
------>|----------------->| user data | |
| |---------------->| user data |
| | |----------------->|
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|
| | S |
RESERVE | | S |
------->| | S |
|----------------------------------->S |
| | RESERVE(re-marked DSCP in GIST)
| | S----------------->|
| |RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------|
RESPONSE(unsuccessful INFO-SPEC) | |
<------| | | |
Figure 15: Using RMD congestion notification function for admission control based on probing
図15：プローブに基づくアドミッション制御のためのRMD輻輳通知機能を使用し
This section describes the basic bidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished:
このセクションでは、RMD-QOSMのイベント/トリガの基本的な双方向動作シーケンスを説明します。次の基本的な操作例は区別されます。
* Successful and unsuccessful reservation (Section 4.6.2.1);
* Refresh reservation (Section 4.6.2.2);
* Modification of aggregated reservation (Section 4.6.2.3);
* Release procedure (Section 4.6.2.4);
* Severe congestion handling (Section 4.6.2.5);
* Admission control using congestion notification based on probing
(Section 4.6.2.6).
It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed:
基本的な一方向の操作を想定した場合、このセクションの内容は、信号方式以下RMD-QOSM / QoSの-NSLPの仕様のために使用されていることを強調することが重要です。
* "per-flow congestion notification based on probing";
*「探査に基づいて、フローごとの輻輳通知」。
* "per-flow RMD NSIS measurement-based admission control",
*「フローごとのRMD NSIS測定ベースのアドミッション制御」、
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
*「フローごとのRMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで、
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
*「フローごとのRMD予約ベースの」手順「の比例データパケットマーキングにより、深刻な輻輳処理」との組み合わせで、
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
*「ごとの集計RMD予約ベースの」手順「RMD-QOSMリフレッシュすることにより、重度輻輳処理」との組み合わせで、
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
*「ごとの集計RMD予約ベースの」手順「をマーキング比例データパケットによって深刻な輻輳処理」との組み合わせで。
For more details, please see Section 3.2.3.
詳細については、3.2.3項を参照してください。
In particular, the functionality described in Sections 4.6.2.1, 4.6.2.2, 4.6.2.3, 4.6.2.4, and 4.6.2.5 applies to the RMD reservation-based and NSIS measurement-based admission control methods. The described functionality in Section 4.6.2.6 applies to the admission control procedure that uses the congestion notification based on probing. The QNE Edge nodes maintain either per-flow QoS-NSLP operational and reservation states or aggregated QoS-NSLP operational and reservation states.
具体的には、機能はセクション4.6.2.1、4.6.2.2に記載され、4.6.2.3、4.6.2.4と4.6.2.5はRMD予約ベースとNSIS測定ベースのアドミッション制御方法に適用されます。セクション4.6.2.6に記載された機能は、プローブに基づく輻輳通知を使用するアドミッション制御手順に適用されます。 QNEエッジノードは、いずれかのフローごとのQoS-NSLP動作及び予約状態または凝集のQoS-NSLP動作と予約状態を維持します。
RMD-QOSM assumes that asymmetric routing MAY be applied in the RMD domain. Combined sender-receiver initiated reservation cannot be efficiently done in the RMD domain because upstream NTLP states are not stored in Interior routers.
RMD-QOSMは、非対称ルーティングがRMDドメインに適用することができることを前提としています。上流NTLP状態は内部ルータに格納されていないので、合わせて、送信者、受信開始の予約を効率的にRMDドメインで行うことはできません。
Therefore, the bidirectional operation SHOULD be performed by two sender-initiated reservations (sender&sender). We assume that the QNE Edge nodes are common for both upstream and downstream directions, therefore, the two reservations/sessions can be bound at the QNE Edge nodes. Note that if this is not the case, then the bidirectional procedure could be managed and maintained by nodes located outside the RMD domain, by using other procedures than the ones defined in RMD-QOSM.
したがって、双方向動作は、二つの送信者が開始した予約情報（送信者および送信者）によって実行されるべきです。我々は、QNEエッジノードはしたがって、2つの予約/セッションがQNEエッジノードで結合することができ、上流及び下流方向の両方に共通であること。想定しますそうでない場合は、双方向の手順はRMD-QOSMで定義されたもの以外の手順を使用して、RMD領域の外側に位置するノードによって管理および維持することができることに留意されたいです。
This (intra-domain) bidirectional sender&sender procedure can then be applied between the QNE Edge (QNE Ingress and QNE Egress) nodes of the RMD QoS signaling model. In the situation in which a security association exists between the QNE Ingress and QNE Egress nodes (see Figure 15), and the QNE Ingress node has the REQUIRED <Peak Data Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress towards QNE Ingress, then the QNE Ingress MAY include both <Peak Data Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters (needed for both directions) into the RMD-QSPEC within a RESERVE message. In this way, the QNE Egress node is able to use the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2). The QNE Egress is then able to create a RESERVE with the right QoS parameters included in the QSPEC, i.e., RESERVE (QoS-2). Both directions of the flows are bound by inserting <BOUND-SESSION-ID> objects at the QNE Ingress and QNE Egress, which will be carried by bound end-to-end RESERVE messages.
この（イントラドメイン）双方向センダ・センダ手順は、次いで、QNEエッジ（QNE進入及び退出QNE）RMDのQoSシグナリングモデルのノードとの間に印加することができます。セキュリティアソシエーションは、QNE入力およびQNE出口ノード（図15参照）との間に存在し、QNE IngressノードがローカルRMD-QSPEC <TMODの必須<ピークデータレート-1（P）>値を有している状況で-1両方向のため>のパラメータ、すなわち、QNE進入向かっQNE出口とQNE出口に向かってQNE進入し、QNE進入ローカルRMD-QSPECの両方<ピークデータレート-1（P）>値を含んでいてもよい。<TMOD-1 > RESERVEメッセージ内のRMD-QSPECにパラメータ（両方向に必要）。このように、QNE出口ノードは、「出力イングレスに向かって」方向（QOS-2）のために必要なQoSパラメータを使用することができます。 QNE出口はその後QSPECに含まれる右QoSパラメータ、すなわち、RESERVE（QOS-2）で予約を作成することができます。流れの両方向に結合されたエンドツーエンドのRESERVEメッセージによって運ばれるQNE進入及び退出QNE、で<BOUND-SESSION-ID>オブジェクトを挿入することにより結合されています。
|------ RESERVE (QoS-1, QoS-2)----|
| V
| Interior/stateless QNEs
+---+ +---+
|------->|QNE|-----|QNE|------
| +---+ +---+ |
| V
+---+ +---+
|QNE| |QNE|
+---+ +---+
^ |
| | +---+ +---+ V
| |-------|QNE|-----|QNE|-----|
| +---+ +---+
Ingress/ Egress/
stateful QNE stateful QNE
|
<--------- RESERVE (QoS-2) -------|
Figure 16: The intra-domain bidirectional reservation scenario in the RMD domain
図16：RMDドメイン内のドメイン内の双方向予約のシナリオ
Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM process the QoS-NSLP signaling messages with a higher priority than data packets. This can be accomplished as described in Section 3.3.4 in [RFC5974] and the QoS-NSLP-RMF API [RFC5974].
RMD-QOSMプロセスのQoS-NSLPのQNE実装は、データパケットよりも高い優先度を有するメッセージをシグナリングすることを推奨されていることに留意されたいです。 [RFC5974]およびQoS-NSLP-RMFのAPI [RFC5974]セクション3.3.4に記載したように、これは達成することができます。
A bidirectional reservation, within the RMD domain, is indicated by the PHR <B> and PDR <B> flags, which are set in all messages. In this case, two <BOUND-SESSION-ID> objects SHOULD be used.
双方向予約は、RMDのドメイン内で、PHR <B>及びPDRのすべてのメッセージに設定されている<B>フラグによって示されています。この場合、2つの<BOUND-SESSION-ID>オブジェクトを使用すべきです。
When the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND-SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled intra-domain (per-flow) session that is using a Binding_Code with value set to code (Tunneled and end-to-end sessions). Another
QNEエッジあたりフロードメイン内のQoS-NSLP動作状態を維持する場合、エンド・ツー・エンドのRESERVEメッセージは、二つBOUND、セッションIDを運びます。一BOUND-SESSION-IDコード（トンネリングとエンドツーエンドセッション）に設定した値とBinding_Codeを使用しているトンネリングイントラドメイン（フローごとの）セッションのセッションIDを運びます。別の
BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
BOUND-SESSION-IDは、バインドされた双方向のエンドツーエンドのセッションのセッションIDを運びます。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（双方向セッション）に設定されています。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND-SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled aggregated intra-domain session that is using a Binding_Code with value set to code (Aggregated sessions). Another BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
QNEエッジが凝集ドメイン内のQoS-NSLP動作状態を維持する場合、エンド・ツー・エンドのRESERVEメッセージは、二つBOUND、セッションIDを運びます。一BOUND-SESSION-IDコード（アグリゲートされたセッション）に設定された値とBinding_Codeを使用しているトンネリング凝集ドメイン内のセッションのセッションIDを運びます。別BOUND-SESSION-IDは、バインドされた双方向のエンドツーエンドのセッションのセッションIDを運びます。このBOUND-SESSION-IDに関連付けられたBinding_Codeは、コード（双方向セッション）に設定されています。
The intra-domain and end-to-end QoS-NSLP operational states are initiated/modified depending on the binding type (see Sections 4.3.1, 4.3.2, and 4.3.3).
イントラドメインと、エンドツーエンドのQoS-NSLP動作状態が開始される/（セクション4.3.1、4.3.2を参照し、4.3.3）バインディング・タイプに応じて変更。
If no security association exists between the QNE Ingress and QNE Egress nodes, the bidirectional reservation for the sender&sender scenario in the RMD domain SHOULD use the scenario specified in [RFC5974] as "bidirectional reservation for sender&sender scenario". This is because in this scenario, the RESERVE message sent from the QNE Ingress to QNE Egress does not have to carry the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2).
いかなるセキュリティアソシエーションがQNE入力およびQNE出口ノードとの間に存在しない場合、RMDドメイン内の送信者および送信者シナリオの双方向予約「が送信者と送信者のシナリオのための双方向予約」と[RFC5974]で指定されたシナリオを使用すべきです。このシナリオでは、QNE出口にQNEイングレスから送られたRESERVEメッセージは、「出力入に向けた」方向（QoSの-2）のために必要なQoSパラメータを運ぶ必要がないためです。
In the following sections, it is considered that the QNE Edge nodes are common for both upstream and downstream directions and therefore, the two reservations/sessions can be bound at the QNE Edge nodes. Furthermore, it is considered that a security association exists between the QNE Ingress and QNE Egress nodes, and the QNE Ingress node has the REQUIRED <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress towards QNE Ingress.
以下のセクションでは、それはQNEエッジノードは、従って、上流及び下流方向の両方のために共通であると考えられる、/セッションがQNEエッジノードで結合することができる2つの予約。さらに、セキュリティアソシエーションがQNE入力およびQNE出口ノードとの間に存在し、QNE IngressノードがローカルRMD-QSPEC <TMOD-1>パラメータの必須の<ピークデータレート-1（P）>値を有すると考えられます両方向のため、すなわち、QNE進入に対するQNE出口とQNE出口に向けたQNE進入。
According to Section 3.2.3, it is specified that only the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme MUST be implemented within one RMD domain. However, all RMD QNEs supporting this specification MUST support the combination the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR Container" (Section 4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain, only one of the below described RMD-QOSM schemes is used at a time.
3.2.3項によれば、スキームは1つのRMDドメイン内に実装しなければならない「マーキング比例データパケットによって深刻な輻輳処理」のみと組み合わせた「フローごとのRMD予約・ベース」と指定されています。しかし、この仕様をサポートするすべてのRMDのQNEsは、「フローごとのRMD予約がベース」の組み合わせをサポートしなければならないとの組み合わせでスキームを「比例データパケットによって深刻な輻輳処理マーキング」。 RMDのQNEsがよりRMD-QOSM方式をサポートしている場合、そのRMDドメインのオペレータが一つのドメイン<SCH>フィールドが「PHRコンテナ」に含まれるように（セクション4.1.2）と内のすべてのQNEエッジノードを事前に設定しなければなりません「PDRコンテナ」（4.1.3項）は常に1つのRMDドメイン内で、以下に説明RMD-QOSM方式の一方のみが一度に使用されるように同じ値を使用します。
All QNE nodes located within the RMD domain MUST read and interpret the <SCH> field included in the "PHR Container" before processing all the other <PHR Container> payload fields. Moreover, all QNE Edge nodes located at the boarder of the RMD domain, MUST read and interpret the <SCH> field included in the "PDR container" before processing all the other <PDR Container> payload fields.
RMDドメイン内にあるすべてのQNEノードは、他のすべての<PHRコンテナ>ペイロードフィールドを処理する前に、「PHRコンテナ」に含まれ、<SCH>フィールドを読み、解釈する必要があります。また、RMDドメインの境界に位置するすべてのQNEエッジノード、<SCH>フィールドを読み取って解釈しなければならない他のすべての<PDRコンテナ>ペイロード・フィールドを処理する前に「PDRコンテナ」に含まれます。
This section describes the operation of the RMD-QOSM where an RMD Intra-domain bidirectional reservation operation, see Figure 16 and Section 4.6.2, is either successfully or unsuccessfully accomplished.
このセクションではRMDドメイン内の双方向予約操作RMD-QOSMの動作を説明する、図16およびセクション4.6.2を参照して、いずれかの成功または失敗に達成されます。
The bidirectional successful reservation is similar to a combination of two unidirectional successful reservations that are accomplished in opposite directions, see Figure 17. The main differences of the bidirectional successful reservation procedure with the combination of two unidirectional successful reservations accomplished in opposite directions are as follows. Note also that the intra-domain and end-to-end QoS-NSLP operational states generated and maintained by the end-to-end RESERVE messages contain, compared to the unidirectional reservation scenario, a different BOUND-SESSION-ID data structure (see Sections 4.3.1, 4.3.2, and 4.3.3). In this scenario, the intra-domain RESERVE message sent by the QNE Ingress node towards the QNE Egress node is denoted in Figure 17 as RESERVE (RMD-QSPEC): "forward". The main differences between the intra-domain RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure and a RESERVE (RMD-QSPEC) message used for the unidirectional successful reservation are as follows (see the QoS-NSLP-RMF API described in [RFC5974]):
双方向成功した予約は、以下のように反対方向に達成2つの単方向成功した予約の組み合わせとの双方向成功した予約手続きの主な相違点である図17を参照して、反対方向に達成されている2つの単方向予約成功の組み合わせに類似しています。ノートはまた、イントラドメインと、エンドツーエンドのQoS-NSLP動作状態が生成され、エンドツーエンドのRESERVEメッセージによって維持することを、一方向予約シナリオと比較して、異なるBOUND-SESSION-IDのデータ構造を含む（参照セクション4.3.1、4.3.2、および4.3.3）。このシナリオでは、QNE出口ノードに向かっQNE Ingressノードによって送信されたドメイン内のRESERVEメッセージはRESERVE（RMD-QSPEC）として図17に示されている：「フォワード」。ドメイン内RESERVE（RMD-QSPEC）との主な違いは：「フォワード」双方向成功した予約手続きと一方向の予約が成功するために使用さRESERVE（RMD-QSPEC）メッセージのために使用されるメッセージは、QoS-NSLPを参照してください（以下の通りです。 [RFC5974]で説明-RMF API）。
* the <RII> object MUST NOT be included in the message. This is because no RESPONSE message is REQUIRED.
* <RII>オブジェクトがメッセージに含まれてはなりません。何の応答メッセージが必要とされないためです。
* the <B> bit of the PHR container indicates a bidirectional reservation and it MUST be set to "1".
* PHRコンテナの<B>ビットは、双方向予約を示し、それが「1」に設定しなければなりません。
* the PDR container is also included in the RESERVE(RMD-QSPEC): "forward" message. The value of the Parameter ID is "20", i.e., "PDR_Reservation_Request". Note that the response PDR container sent by a QNE Egress to a QNE Ingress node is not carried by an end-to-end RESPONSE message, but it is carried by an intra-domain RESERVE message that is sent by the QNE Egress node towards the QNE Ingress node (denoted in Figure 16 as RESERVE(RMD-QSPEC): "reverse").
"前方" メッセージ：* PDR容器はまた、RESERVE（RMD-QSPEC）に含まれています。パラメータIDの値が「20」、すなわち、「PDR_Reservation_Request」です。 QNE IngressノードにQNE出口によって送信された応答PDR容器は、エンドツーエンドRESPONSEメッセージによって運ばれず、それが向かっQNE出口ノードによって送信されるドメイン内RESERVEメッセージによって運ばれることに注意してくださいQNE Ingressノード（RESERVE（RMD-QSPECとして図16に示されている）： "逆"）。
* the <B> PDR bit indicates a bidirectional reservation and is set to "1".
* <B> PDRビットは、双方向予約を示し、「1」に設定されています。
* the <PDR Bandwidth> field specifies the requested bandwidth that has to be used by the QNE Egress node to initiate another intra-domain RESERVE message in the reverse direction.
* <PDR帯域幅>フィールドは、逆方向に別のドメイン内RESERVEメッセージを開始するQNE出口ノードによって使用されなければならない要求された帯域幅を指定します。
The RESERVE(RMD-QSPEC): "reverse" message is initiated by the QNE Egress node at the moment that the RESERVE(RMD-QSPEC): "forward" message is successfully processed by the QNE Egress node.
RESERVE（RMD-QSPEC）：「前方」メッセージ正常QNE出口ノードによって処理される：メッセージがRESERVE（RMD-QSPEC）がその時点でQNE出口ノードによって開始される「逆」。
The main differences between the RESERVE(RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure and a RESERVE(RMD-QSPEC) message used for the unidirectional successful reservation are as follows:
RESERVE（RMD-QSPEC）との間の主な違いは以下の通り双方向成功した予約手順と一方向に成功した予約のために使用RESERVE（RMD-QSPEC）メッセージのために使用される「逆」メッセージは以下のとおりです。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | | |
| | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | | |
| |------------------------------>| |
| | | |------------->|
| | | | |
| | |RESERVE(RMD-QSPEC) |
| RESERVE(RMD-QSPEC) | "reverse" |<-------------|
| "reverse" | |<--------------| |
|<-------------------------------| | |
Figure 17: Intra-domain signaling operation for successful
bidirectional reservation
* the <RII> object is not included in the message. This is because no RESPONSE message is REQUIRED;
* <RII>オブジェクトがメッセージに含まれていません。何の応答メッセージが必要とされないためです。
* the value of the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter is set equal to the value of the <PDR Bandwidth> field included in the RESERVE(RMD-QSPEC): "forward" message that triggered the generation of this RESERVE(RMD-QSPEC): "reverse" message;
*ローカルRMD-QSPEC <TMOD-1>パラメータは<PDR帯域>フィールドの値に等しく設定されているの<ピークデータレート-1（P）>フィールドの値は、RESERVE（RMD-QSPEC）に含まれますこのRESERVE（RMD-QSPEC）の生成トリガ「前方」メッセージ：メッセージ「逆の」;
* the <B> bit of the PHR container indicates a bidirectional reservation and is set to "1";
* PHRコンテナの<B>ビットは、双方向予約を示し、「1」に設定されています。
* the PDR container is included into the RESERVE(RMD-QSPEC): "reverse" message. The value of the Parameter ID is "23", i.e., "PDR_Reservation_Report";
* PDR容器はRESERVE（RMD-QSPEC）に含まれている：メッセージを "逆"。パラメータIDの値が「23」、すなわち、「PDR_Reservation_Report」です。
* the <B> PDR bit indicates a bidirectional reservation and is set to "1".
* <B> PDRビットは、双方向予約を示し、「1」に設定されています。
Figures 18 and 19 show the flow diagrams used in the case of an unsuccessful bidirectional reservation. In Figure 18, the QNE that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> is located in the direction QNE Ingress towards QNE Egress. In Figure 19, the QNE that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> is located in the direction QNE Egress towards QNE Ingress. The main differences between the bidirectional unsuccessful procedure shown in Figure 18 and the bidirectional successful procedure are as follows:
18及び19は不成功双方向予約の場合に使用されるフロー図を示します。図18は、ローカルRMD-QSPEC <TMOD-1>の要求<ピークデータレート-1（P）>値がQNE出口に向かう方向QNEイングレスに位置しているサポートすることができないQNEで。図19は、ローカルRMD-QSPEC <TMOD-1>の要求<ピークデータレート-1（P）>値がQNE入向かう方向QNE出口に配置されているサポートすることができないQNEで。次のように図18に示す双方向失敗した手順と双方向成功手順の主な違いは以下のとおりです。
* the QNE node that is not able to reserve resources for a certain request is located in the "forward" path, i.e., the path from the QNE Ingress towards the QNE Egress.
*特定の要求のためのリソースを予約することができないQNEノードが「フォワード」のパスにあり、すなわち、QNE出口に向かって進入QNEからパス。
* the QNE node that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M> bit, i.e., set to value "1", of the RESERVE(RMD-QSPEC): "forward".
ローカルRMD-QSPEC <TMOD-1>の要求<ピークデータレート-1（P）>値をサポートすることができない* QNEノード<M>ビットをマークする必要があり、すなわち、「1」の値に設定し、 RESERVE（RMD-QSPEC）： "フォワード"。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | M RESERVE(RMD-QSPEC):
| |--------------------------->M "forward-M marked"
| | | M-------------->|
| | RESPONSE(PDR) M |
| | "forward - M marked"M |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC, K=0) | M |
|"forward - T tear" | M |
|--------------->| | M |
| RESERVE(RMD-QSPEC, K=1) M |
| | "forward - T tear" M |
| |--------------------------->M |
| | RESERVE(RMD-QSPEC, K=1) |
| | "forward - T tear" |
| | M-------------->|
Figure 18: Intra-domain signaling operation for unsuccessful bidirectional reservation (rejection on path QNE(Ingress) towards QNE(Egress))
図18：失敗した双方向予約のためのイントラドメインシグナリングオペレーション（QNEに向かってパスQNE（入力）に拒絶（出力））
The operation for this type of unsuccessful bidirectional reservation is similar to the operation for unsuccessful unidirectional reservation, shown in Figure 9.
失敗双方向予約のこのタイプの動作は、図9に示さ失敗一方向予約のための動作と同様です。
The main differences between the bidirectional unsuccessful procedure shown in Figure 19 and the in bidirectional successful procedure are as follows:
双方向失敗手順の主な違いは、図19に示されており、次のように双方向成功手順です。
* the QNE node that is not able to reserve resources for a certain request is located in the "reverse" path, i.e., the path from the QNE Egress towards the QNE Ingress.
*特定の要求のためのリソースを予約することができないQNEノードが「逆」のパスにあり、すなわち、QNE進入向かっQNE出口からパス。
* the QNE node that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M> bit, i.e., set to value "1", the RESERVE(RMD-QSPEC): "reverse".
ローカルRMD-QSPEC <TMOD-1>の要求<ピークデータレート-1（P）>値をサポートすることができない* QNEノード<M>ビットをマークする必要があり、すなわち、「1」の値に設定し、 RESERVE（RMD-QSPEC）： "逆"。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | RESERVE(RMD-QSPEC): |
| |-------------------------------->|"forward" |
| | RESERVE(RMD-QSPEC): |------------->|
| | "reverse" | | |
| | RESERVE(RMD-QSPEC) | |
| RESERVE(RMD-QSPEC): M "reverse" |<-------------|
| "reverse - M marked" M<---------------| |
|<--------------------------------M | |
| | M | |
|RESERVE(RMD-QSPEC, K=0): M | |
|"forward - T tear" M | |
|--------------->| RESERVE(RMD-QSPEC, K=0): | |
| | "forward - T tear" | |
| |-------------------------------->| |
| | M |------------->|
| | M RESERVE(RMD-QSPEC, K=0):
| | M "reverse - T tear" |
| | M |<-------------|
| M RESERVE(RMD-QSPEC, K=1) |
| | M "forward - T tear" |
| | M<---------------| |
| RESERVE(RMD-QSPEC, K=1)M | |
| "forward - T tear" M | |
|<--------------------------------M | |
Figure 19: Intra-domain signaling normal operation for unsuccessful bidirectional reservation (rejection on path QNE(Egress) towards QNE(Ingress)
図19：QNE（入力）に向かって失敗した双方向予約のためのイントラドメインシグナリング通常動作パスQNEに（拒絶（出力）
* the QNE Ingress uses the information contained in the received PHR and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and generates a tear intra-domain RESERVE(RMD-QSPEC): "forward - T tear" message. This message carries a "PHR_Release_Request" and "PDR_Release_Request" control information. This message is sent to the QNE Egress node. The QNE Egress node uses the information contained in the "PHR_Release_Request" and the "PDR_Release_Request" control info containers to generate a RESERVE(RMD-QSPEC): "reverse - T tear" message that is sent towards the QNE Ingress node.
メッセージ - 「T涙フォワード」：「リバース」と涙ドメイン内RESERVE（RMD-QSPEC）を生成する：* QNE進入はRESERVE（RMD-QSPEC）の受信されたPHR及びPDRの容器に含まれる情報を使用します。このメッセージは、「PHR_Release_Request」と「PDR_Release_Request」の情報をコントロールを運びます。このメッセージは、QNE出口ノードに送信されます。 QNE Ingressノードに向けて送信されるメッセージ - 「T涙リバース」：QNE出口ノード「はPHR_Release_Request」および「PDR_Release_Request」RESERVE（RMD-QSPEC）を生成する情報コンテナを制御するに含まれる情報を使用します。
This section describes the operation of the RMD-QOSM where an RMD intra-domain bidirectional refresh reservation operation is accomplished.
このセクションでは、RMDイントラドメイン双方向リフレッシュ予約動作が達成されるRMD-QOSMの動作を説明します。
The refresh procedure in the case of an RMD reservation-based method follows a scheme similar to the successful reservation procedure, described in Section 4.6.2.1 and depicted in Figure 17, and how the refresh process of the reserved resources is maintained and is similar to the refresh process used for the intra-domain unidirectional reservations (see Section 4.6.1.3).
RMD予約ベースの方法の場合のリフレッシュ手順が成功した予約の手順と同様の方式で、セクション4.6.2.1に記載されており、図17に示されているが、以下の、そしてどのように確保されたリソースのリフレッシュプロセスが維持され、同様ですドメイン内の単方向の予約に使用リフレッシュ処理（セクション4.6.1.3を参照）。
Note that the RMD traffic class refresh periods used by the bound bidirectional sessions MUST be equal in all QNE Edge and QNE Interior nodes.
バインドされた双方向セッションで使用RMDトラフィッククラスリフレッシュ期間は、すべてのQNEエッジとQNEインテリアのノードで同じでなければならないことに注意してください。
The main differences between the RESERVE(RMD-QSPEC): "forward" message used for the bidirectional refresh procedure and a RESERVE(RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows:
RESERVE（RMD-QSPEC）との間の主な相違点：双方向リフレッシュ手順のために使用される「前方」メッセージとRESERVE（RMD-QSPEC）：次のように双方向成功した予約手続きのために使用される「前方」メッセージは以下のとおりです。
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* PHR容器のパラメータIDの値が「19」、すなわち、「PHR_Refresh_Update」です。
* the value of the Parameter ID of the PDR container is "21", i.e., "PDR_Refresh_Request".
* PDR容器のパラメータIDの値が「21」、すなわち、「PDR_Refresh_Request」です。
The main differences between the RESERVE(RMD-QSPEC): "reverse" message used for the bidirectional refresh procedure and the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure are as follows:
RESERVE（RMD-QSPEC）との間の主な相違点：双方向リフレッシュ手順のために使用される「逆」メッセージとRESERVE（RMD-QSPEC）：次のように双方向成功した予約手続きのために使用される「逆」メッセージは以下のとおりです。
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* PHR容器のパラメータIDの値が「19」、すなわち、「PHR_Refresh_Update」です。
* the value of the Parameter ID of the PDR container is "24", i.e., "PDR_Refresh_Report".
* PDR容器のパラメータIDの値が「24」、すなわち、「PDR_Refresh_Report」です。
4.6.2.3. Modification of Aggregated Intra-Domain QoS-NSLP Operational Reservation States
4.6.2.3。集約ドメイン内のQoS-NSLPオペレーショナル予約状態の変更
This section describes the operation of the RMD-QOSM where RMD intra-domain bidirectional QoS-NSLP aggregated reservation states have to be modified.
このセクションでは、RMD内ドメイン双方向のQoS-NSLP凝集予約状態を変更しなければならないRMD-QOSMの動作を説明します。
In the case when the QNE Edges maintain, for the RMD QoS Model, QoS-NSLP aggregated reservation states and if such an aggregated reservation has to be modified (see Section 4.3.1), then similar procedures to Section 4.6.1.4 are applied. In particular:
QNEエッジがRMDのQoSモデルと、QoS-NSLP凝集予約状態のため、維持し、このような凝集した予約を変更しなければならない場合（セクション4.3.1を参照）場合には、セクション4.6.1.4に、同様の手順が適用されます。特に：
* When the modification request requires an increase of the reserved resources, the QNE Ingress node MUST include the corresponding value into the <Peak Data Rate-1 (p)> field local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>), which is sent together with "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, then the "PHR_Resource_Request" associated with the local RMD-QSPEC <TMOD-1> parameter MUST be marked. In this situation, the RMD-specific operation for unsuccessful reservation will be applied (see Section 4.6.2.1). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Reservation_Request" container, represents the increase of the reserved resources in the "reverse" direction.
*変更要求が予約されたリソースの増加を必要とする場合、QNE IngressノードがRMD-QOSMの<ピークデータレート-1（P）>フィールドローカルRMD-QSPEC <TMOD-1>パラメータに対応する値を含まなければなりません「PHR_Resource_Request」制御情報と共に送信される<QoSの希望>）。 QNEエッジ又はQNEインテリアノードは要求されたリソースの数を予約することができない場合、ローカルRMD-QSPEC <TMOD-1>パラメータに関連付けられた「PHR_Resource_Request」がマークされなければなりません。このような状況では、失敗した予約のためのRMD-特定の操作（セクション4.6.2.1を参照）が適用されます。 「PDR_Reservation_Request」コンテナ内で送信される<PDR帯域幅>パラメータの値は、「逆」方向に予約されたリソースの増加を表しています。
* When the modification request requires a decrease of the reserved resources, the QNE Ingress node MUST include this value into the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>). Subsequently, an RMD release procedure SHOULD be accomplished (see Section 4.6.2.4). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Release_Request" container, represents the decrease of the reserved resources in the "reverse" direction.
*変更要求が予約されたリソースの減少を必要とする場合、QNE IngressノードがRMD-のローカルRMD-QSPEC <TMOD-1>パラメータ<ピークデータレート-1（P）>フィールドにこの値を含まなければなりませんQOSM <QoSが希望>）。その後、RMD解放手順（セクション4.6.2.4を参照）達成されなければなりません。 「PDR_Release_Request」コンテナ内で送信される<PDR帯域>パラメータの値は、「逆」方向に予約されたリソースの減少を表しています。
This section describes the operation of the RMD-QOSM, where an RMD intra-domain bidirectional reservation release operation is accomplished. The message sequence diagram used in this procedure is similar to the one used by the successful reservation procedures, described in Section 4.6.2.1 and depicted in Figure 17. However, how the release of the reservation is accomplished is similar to the RMD release procedure used for the intra-domain unidirectional reservations (see Section 4.6.1.5 and Figures 18 and 19).
このセクションでは、RMD内ドメイン双方向予約の解除動作が実現されるRMD-QOSMの動作を説明します。この手順で使用されるメッセージのシーケンス図は、予約の放出が達成される方法を、しかし図17に、セクション4.6.2.1に記載され、示され成功した予約の手順で使用されるものに類似していることに使用RMD解放手順に類似していますイントラドメイン一方向予約のため（セクション4.6.1.5を参照し、18及び19図）。
The main differences between the RESERVE (RMD-QSPEC): "forward" message used for the bidirectional release procedure and a RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows:
RESERVE（RMD-QSPEC）との間の主な相違点：双方向解放手順とRESERVE（RMD-QSPEC）のために使用される「前方」メッセージ：次のように双方向成功した予約手続きのために使用される「前方」メッセージは以下のとおりです。
* the value of the Parameter ID of the PHR container is "18", i.e."PHR_Release_Request";
* PHR容器のパラメータIDの値が「18」、すなわち「PHR_Release_Request」です。
* the value of the Parameter ID of the PDR container is "22", i.e., "PDR_Release_Request";
* PDR容器のパラメータIDの値が「22」、すなわち、「PDR_Release_Request」です。
The main differences between the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional release procedure and the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure are as follows:
双方向解放手順とRESERVE（RMD-QSPEC）のために使用されるメッセージ「逆」：RESERVE（RMD-QSPEC）との間の主な違いは以下のように「逆」双方向成功した予約手続きのために使用されるメッセージは、次のとおり
* the value of the Parameter ID of the PHR container is "18", i.e., "PHR_Release_Request";
* PHR容器のパラメータIDの値が「18」、すなわち、「PHR_Release_Request」です。
* the PDR container is not included in the RESERVE (RMD-QSPEC): "reverse" message.
* PDR容器はRESERVE（RMD-QSPEC）に含まれていない：メッセージを "逆"。
This section describes the severe congestion handling operation used in combination with RMD intra-domain bidirectional reservation procedures. This severe congestion handling operation is similar to the one described in Section 4.6.1.6.
このセクションでは、RMDドメイン内の双方向予約手続きと組み合わせて使用する深刻な輻輳処理の動作を説明します。この深刻な輻輳処理操作は、セクション4.6.1.6に記載されたものと同様です。
4.6.2.5.1. Severe Congestion Handling by the RMD-QOSM Bidirectional Refresh Procedure
4.6.2.5.1。 RMD-QOSM双方向の更新手順によって重度輻輳処理
This procedure is similar to the severe congestion handling procedure described in Section 4.6.1.6.1. The difference is related to how the refresh procedure is accomplished (see Section 4.6.2.2) and how the flows are terminated (see Section 4.6.2.4).
この手順は、セクション4.6.1.6.1で説明深刻な輻輳処理の手順と同様です。差がリフレッシュ手続きが達成される方法に関連している（セクション4.6.2.2を参照）、フローが終了しているか（セクション4.6.2.4を参照）。
4.6.2.5.2. Severe Congestion Handling by Proportional Data Packet Marking
4.6.2.5.2。マーキング比例データパケットによって重度輻輳処理
This section describes the severe congestion handling by proportional data packet marking when this is combined with an RMD intra-domain bidirectional reservation procedure. Note that the detection and marking/re-marking functionality described in this section and used by Interior nodes, applies to NSIS-aware but also to NSIS-unaware nodes. This means however, that the "not NSIS-aware" Interior nodes MUST be configured such that they can detect the congestion situations and re-mark packets in the same way as the Interior "NSIS-aware" nodes do.
このセクションでは、これはRMDドメイン内の双方向予約手順と組み合わせた場合にマーキング比例データパケットによって深刻な輻輳処理を記述します。このセクションで説明すると内部ノードによって使用される検出およびマーキング/再マーキング機能は、NSIS認識にもNSIS非対応ノードに適用されることに留意されたいです。これは、「NSISを意識しない」インテリア・ノードは、彼らが「NSIS対応」のノードがそうインテリアのと同じ方法で、混雑状況や再マークパケットを検出することができるように構成しなければならないことを、しかし意味します。
This procedure is similar to the severe congestion handling procedure described in Section 4.6.1.6.2. The main difference is related to the location of the severe congested node, i.e., "forward" or "reverse" path. Note that when a severe congestion situation occurs, e.g., on a forward path, and flows are terminated to solve the severe congestion in forward path, then the reserved bandwidth associated with the terminated bidirectional flows will also be released. Therefore, a careful selection of the flows that have to be terminated SHOULD take place. An example of such a selection is given in Appendix A.5.
この手順は、セクション4.6.1.6.2で説明深刻な輻輳処理の手順と同様です。主な違いは、重度の輻輳ノードの位置、即ち、「前方」または「逆」の経路に関連しています。重度の輻輳状況が往路で、例えば、発生、およびフローが往路で重度の輻輳を解決するために終了すると、次に終了双方向フローに関連付けられた予約帯域も解放されることに留意されたいです。そのため、終了する必要がフローの慎重な選択が行われるべきです。そのような選択の例は、付録A.5に与えられています。
Furthermore, a special case of this operation is associated with the severe congestion situation occurring simultaneously on the forward and reverse paths. An example of this operation is given in Appendix A.6.
また、この操作の特別なケースは、重度の輻輳状況が前方に同時に発生し、経路を逆に関連しています。この動作の例は、付録A.6に示されています。
Simulation results associated with these procedures can be found in [DiKa08].
これらの手順に関連したシミュレーション結果は、[DiKa08]に見出すことができます。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | S |
| |--------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|Term
| | | S |flow?
| | NOTIFY (PDR) S |YES
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC) | S |
|"forward - T tear" | S |
|--------------->| | RESERVE(RMD-QSPEC):|
| |--------------------------->S"forward - T tear"
| | | S-------------->|
| | | RESERVE(RMD-QSPEC): |
| | | "reverse - T tear" |
| RESERVE(RMD-QSPEC): | |<--------------|
|"reverse - T tear" |<-------------S |
|<-----------------------------| S |
Figure 20: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Ingress) towards QNE(Egress))
図20：双方向予約のための処理イントラドメインRMD重度の輻輳（QNE（出口）に向かってパスQNE（入力）上の輻輳）
Figure 20 shows the scenario in which the severely congested node is located in the "forward" path. The QNE Egress node has to generate an end-to-end NOTIFY (PDR) message. In this way, the QNE Ingress will be able to receive the (#marked and #unmarked) that were measured by the QNE Egress node on the congested "forward" path. Note that in this situation, it is assumed that the "reverse" path is not congested.
図20は、深刻な輻輳ノードを「前方」の経路に配置されているシナリオを示しています。 QNE出口ノードは、エンドツーエンドのNOTIFY（PDR）メッセージを生成しなければなりません。このように、QNE侵入が混雑「前方」経路上のQNE出口ノードにより測定したもの（#markedと#unmarked）を受信することができるであろう。このような状況では、「逆」パスが混雑していないことを想定していることに注意してください。
This scenario is very similar to the severe congestion handling scenario described in Section 4.6.1.6.2 and shown in Figure 14. The difference is related to the release procedure, which is accomplished in the same way as described in Section 4.6.2.4.
このシナリオでは、差は、セクション4.6.2.4に記載したのと同じ方法で達成された解放手順に関連して図14に、セクション4.6.1.6.2に記載され、示される重度輻輳処理のシナリオに非常に類似しています。
Figure 21 shows the scenario in which the severely congested node is located in the "reverse" path. Note that in this situation, it is assumed that the "forward" path is not congested. The main difference between this scenario and the scenario shown in Figure 20 is that no end-to-end NOTIFY (PDR) message has to be generated by the QNE Egress node.
図21は、深刻な輻輳ノードは「逆」の経路に配置されているシナリオを示しています。このような状況で、「前進」のパスが混雑していないことを想定していることに注意してください。図20に示すこのシナリオとシナリオの主な違いはないエンドツーエンドNOTIFY（PDR）メッセージがQNE出口ノードによって生成されなければならないことです。
This is because now the severe congestion occurs on the "reverse" path and the QNE Ingress node receives the (#marked and #unmarked) user data passing through the severely congested "reverse" path. The QNE Ingress node will be able to calculate the number of flows that have to be terminated or forwarded in a lower priority queue.
今厳しい輻輳が「リバース」パス上で発生し、QNE Ingressノードが著しく混雑「逆」パスを通る（#markedと#unmarked）ユーザデータを受信するためです。 QNE Ingressノードは、優先度の低いキューに終端又は転送されなければならないフローの数を計算することができるであろう。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | | |
| |--------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
Figure 21: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Egress) towards QNE(Ingress))
図21：双方向予約のための処理イントラドメインRMD重度の輻輳（QNE（入力）に向かってパスQNE（出力）の輻輳）
For the flows that have to be terminated, a release procedure, see Section 4.6.2.4, is initiated to release the reserved resources on the "forward" and "reverse" paths.
終了する必要が流れについては、リリース手順、セクション4.6.2.4を参照してくださいは、「前方」および「逆」のパスに確保されたリソースを解放するために開始されます。
4.6.2.6. Admission Control Using Congestion Notification Based on Probing
4.6.2.6。アドミッション制御プロービングに基づいて輻輳通知を使用します
This section describes the admission control scheme that uses the congestion notification function based on probing when RMD intra-domain bidirectional reservations are supported.
このセクションでは、RMDドメイン内の双方向予約がサポートされていたときに、プロービングに基づく輻輳通知機能を使用して受付制御方式を説明しています。
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | |user data |
|-------------------------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|
| | | S |
| | RESERVE(re-marked DSCP in GIST)):|
| | | S |
|-------------------------------------------->S |
| | | S-------------->|
| | | S |
| | RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------------|
| | | S |
Figure 22: Intra-domain RMD congestion notification based on probing for bidirectional admission control (congestion on path from QNE(Ingress) towards QNE(Egress))
図22：双方向アドミッション制御のためにプロービングに基づいてドメイン内RMD輻輳通知（QNE（出口）に向かってQNE（入力）からパス上の輻輳）
This procedure is similar to the congestion notification for admission control procedure described in Section 4.6.1.7. The main difference is related to the location of the severe congested node, i.e., "forward" path (i.e., path between QNE Ingress towards QNE Egress) or "reverse" path (i.e., path between QNE Egress towards QNE Ingress).
この手順は、セクション4.6.1.7に記載のアドミッション制御手順の輻輳通知と同様です。主な違いは、重度の輻輳ノードの位置、即ち、「フォワード」の経路に関連している（すなわち、QNE QNE出口に向かって進入間の経路）、または「逆」の経路（すなわち、QNE進入向かっQNE出口との間の経路）。
Figure 22 shows the scenario in which the severely congested node is located in the "forward" path. The functionality of providing admission control is the same as that described in Section 4.6.1.7, Figure 15.
図22は、深刻な輻輳ノードを「前方」の経路に配置されているシナリオを示しています。アドミッション制御を提供する機能は、セクション4.6.1.7、図15で説明したものと同じです。
Figure 23 shows the scenario in which the congested node is located in the "reverse" path. The probe RESERVE message sent in the "forward" direction will not be affected by the severely congested node, while the <DSCP> value in the IP header of any packet of the "reverse" direction flow and also of the GIST message that carries the probe RESERVE message sent in the "reverse" direction will be re-marked by the congested node. The QNE Ingress is, in this way, notified that a congestion occurred in the network, and therefore it is able to refuse the new initiation of the reservation.
図23は、輻輳したノードは、「逆」の経路に配置されているシナリオを示しています。 「前方」「逆」方向の流れとも運ぶGISTメッセージの任意のパケットのIPヘッダ内の<DSCP>値つつ方向は、深刻な輻輳ノードによって影響されないで送信されたプローブRESERVEメッセージ「逆」方向に送信されたプローブRESERVEメッセージは、輻輳したノードによって再マークされます。 QNEイングレスは、このように、輻輳がネットワーク内で発生したことを通知し、あるので、予約の新しい開始を拒否することができます。
Note that the "not NSIS-aware" Interior nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way as the Interior "NSIS-aware" nodes do.
「NSISを意識しない」インテリア・ノードは、インテリア「NSIS対応」のノードがそうであるように、彼らは同じように渋滞/激しい混雑状況や再マークパケットを検出することができるように構成しなければならないことに注意してください。
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware NTLP st.less not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | | |
|-------------------------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | | |user
| | | | |data
| | | | |<---
| S | user data | |
| S user data |<--------------------------|
| user data S<---------------| | |
|<---------------S | | |
| user data S | | |
| (#marked bytes)S | | |
|<---------------S | | |
| S RESERVE(unmarked DSCP in GIST)): |
| S | | |
|----------------S------------------------------------------->|
| S RESERVE(re-marked DSCP in GIST) |
| S<-------------------------------------------|
|<---------------S | | |
Figure 23: Intra-domain RMD congestion notification for bidirectional admission control (congestion on path QNE(Egress) towards QNE(Ingress))
図23：双方向アドミッション制御のためのイントラドメインRMD輻輳通知（QNE（入力）に向かってパスQNEの輻輳（出力））
During the QSPEC processing, additional errors MAY occur. The way in which these additional errors are handled and notified is specified in [RFC5975] and [RFC5974].
QSPEC処理中に、別のエラーが発生することがあります。これらの付加的なエラーの処理と通知される方法は、[RFC5975]及び[RFC5974]で指定されています。
A design goal of the RMD-QOSM protocol is to be "lightweight" in terms of the number of exchanged signaling message and the amount of state established at involved signaling nodes (with and without reduced-state operation). A side effect of this design decision is to introduce second-class signaling nodes, namely QNE Interior nodes, that are restricted in their ability to perform QoS signaling actions. Only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages.
RMD-QOSMプロトコルの設計目標は、交換のシグナリングメッセージ及び（還元状態動作ととせずに）関与するシグナルノードで確立状態量の数の点で「軽量」であることです。この設計上の決定の副作用は、アクションをQoSシグナリングを実行する能力が制限されている二級シグナリング・ノード、すなわちQNEインテリア・ノードを、導入することです。 QNE入力およびQNE出口ノードのみが、特定のシグナリングメッセージを開始することを許可されています。
Moreover, RMD focuses on an intra-domain deployment only.
また、RMDは、ドメイン内の展開に焦点を当てています。
The above description has the following implications for security:
上記の説明には、セキュリティのために、以下の意味を持っています：
1) QNE Ingress and QNE Egress nodes require more security and fault protection than QNE Interior nodes because their uncontrolled behavior has larger implications for the overall stability of the network. QNE Ingress and QNE Egress nodes share a security association and utilize GIST security for protection of their signaling messages. Intra-domain signaling messages used for RMD signaling do not use GIST security, and therefore they do not store security associations.
その制御不能な行動は、ネットワークの全体的な安定性のために大きな意味を持っているので、1）QNE入力およびQNE出口ノードは、QNEインテリア・ノードよりもセキュリティと障害保護を必要としています。 QNE入力およびQNE出口ノードは、セキュリティアソシエーションを共有し、そのシグナリングメッセージの保護のためのGISTのセキュリティを利用しています。 RMDシグナリングに使用イントラドメインシグナリングメッセージは、GISTのセキュリティを使用していないので、彼らはセキュリティアソシエーションを格納しません。
2) The focus on intra-domain QoS signaling simplifies trust management and reduces overall complexity. See Section 2 of RFC 4081 for a more detailed discussion about the complete set of communication models available for end-to-end QoS signaling protocols. The security of RMD-QOSM does not depend on Interior nodes, and hence the cryptographic protection of intra-domain messages via GIST is not utilized.
2）ドメイン内のQoSシグナリング上の焦点は、信頼管理を簡素化し、全体的な複雑さを低減します。シグナリングプロトコルをエンド・ツー・エンドのQoSのために利用可能な通信モデルの完全なセットについてのより詳細な議論については、RFC 4081のセクション2を参照してください。 RMD-QOSMのセキュリティは、内部ノードに依存せず、したがって、GISTを経由して、ドメイン内のメッセージの暗号保護が利用されていません。
It is important to highlight that RMD always uses the message exchange shown in Figure 24 even if there is no end-to-end signaling session. If the RMD-QOSM is triggered based on an end-to-end (E2E) signaling exchange, then the RESERVE message is created by a node outside the RMD domain and will subsequently travel further (e.g., to the data receiver). Such an exchange is shown in Figure 3. As such, an evaluation of an RMD's security always has to be seen as a combination of the two signaling sessions, (1) and (2) of Figure 24. Note that for the E2E message, such as the RESERVE and the RESPONSE message, a single "hop" refers to the communication between the QNE Ingress and the QNE Egress since QNE Interior nodes do not participate in the exchange.
それには、エンドツーエンドシグナリングセッションがない場合でも、RMDは常に、図24に示すメッセージ交換を使用していることを強調することが重要です。 RMD-QOSMは、エンド・ツー・エンド（E2E）シグナリング交換に基づいてトリガされた場合には、RESERVEメッセージはRMDドメイン外のノードによって作成され、その後、（例えば、データ受信機）をさらに移動します。そのような交換は、そのようなものとして、図3に示され、RMDのセキュリティの評価は、常に、2つのシグナリングセッションの組み合わせとして見られるように（1）及び（2）図24の注を有するE2Eメッセージのため、 QNE内部ノードが交換に関与しないので、RESERVE応答メッセージのような、単一の「ホップ」はQNE入力およびQNE出口との間の通信を意味します。
QNE QNE QNE QNE
Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
+--------------------------------------------->|
| RESERVE' (2) | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' (2)|
|<---------------------------------------------+
| | | RESPONSE (1) |
|<---------------------------------------------+
Figure 24: RMD message exchange
図24：RMDメッセージ交換
Authorizing quality-of-service reservations is accomplished using the Authentication, Authorization, and Accounting (AAA) framework and the functionality is inherited from the underlying NSIS QoS NSLP, see [RFC5974], and not described again in this document. As a technical solution mechanism, the Diameter QoS application [RFC5866] may be used. The end-to-end reservation request arriving at the Ingress node will trigger the authorization procedure with the backend AAA infrastructure. The end-to-end reservation is typically triggered by a human interaction with a software application, such as a voice-over-IP client when making a call. When authorization is successful then no further user initiated QoS authorization check is expected to be performed within the RMD domain for the intra-domain reservation.
サービス品質予約を許可する認証を使用して達成され、許可、アカウンティング（AAA）フレームワークおよび機能は、[RFC5974]を参照して、下にあるNSISのQoS NSLPから継承されており、この文書では再び説明されません。技術的解決手段として、直径のQoSアプリケーション[RFC5866]は使用されてもよいです。 Ingressノードに到着するエンドツーエンド予約要求は、バックエンドAAAインフラストラクチャと認可手順をトリガします。電話をかける際に、エンドツーエンドの予約は典型的には、ボイスオーバーIPクライアントとして、ソフトウェア・アプリケーションとの人間の相互作用によって引き起こされます。認証が成功すると、その後何の更なるユーザが開始したQoS権限チェックは、ドメイン内の予約のためのRMDのドメイン内で実行されることが予想されていません。
In the RMD-QOSM, the Ingress node constructs both end-to-end and intra-domain signaling messages based on the end-to-end message initiated by the sender end node.
RMD-QOSMにおいて、入口ノードは、エンドツーエンド送信者エンドノードによって開始されるエンドツーエンドのメッセージに基づいてシグナリングメッセージ内ドメインの両方を構築します。
The Interior nodes within the RMD network ignore the end-to-end signaling message, but they process, modify, and forward the intra-domain signaling messages towards the Egress node. In the meantime, resource reservation states are installed, modified, or deleted at each Interior node along the data path according to the content of each intra-domain signaling message. The Edge nodes of an RMD network are critical components that require strong security protection.
RMDネットワーク内の内部ノードは、エンドツーエンドシグナリングメッセージを無視するが、それらは、処理、修正、および出力ノードに向けてイントラドメインシグナリングメッセージを転送します。一方、リソース予約状態は、インストールされ、変更、または各ドメイン内のシグナリングメッセージの内容に応じてデータパスに沿った各内部ノードに削除されます。 RMDネットワークのエッジノードは、強力なセキュリティ保護を必要とする重要な要素です。
Therefore, they act as security gateways for incoming and outgoing signaling messages. Moreover, a certain degree of trust has to be placed into Interior nodes within the RMD-QOSM network, such that these nodes can perform signaling message processing and take the necessary actions.
そのため、彼らは着信と発信シグナリング・メッセージのためのセキュリティゲートウェイとして機能します。また、信頼のある程度は、これらのノードは、シグナリングメッセージ処理を実行し、必要な処置を取ることができるように、RMD-QOSMネットワーク内の内部ノードに置かれなければなりません。
With the RMD-QOSM, we assume that the Ingress and the Egress nodes are not controlled by an adversary and the communication between the Ingress and the Egress nodes is secured using standard GIST security, (see Section 6 of [RFC5971]) mechanisms and experiences integrity, replay, and confidentiality protection.
RMD-QOSMで、我々は（[RFC5971]のセクション6を参照）機構と経験、入力および出力ノードが敵によって制御されず、入力および出力ノード間の通信は、標準的なGISTセキュリティを使用して固定されていることを前提としてい整合性、リプレイ、および機密保護。
Note that this only affects messages directly addressed by these two nodes and not any other message that needs to be processed by intermediaries. The <SESSION-ID> object of the end-to-end communication is visible, via GIST, to the Interior nodes. In order to define the security threats that are associated with the RMD-QOSM, we consider that an adversary that may be located inside the RMD domain and could drop, delay, duplicate, inject, or modify signaling packets.
これが唯一の直接これら二つのノードではなく仲介によって処理される必要がある他のメッセージによって対処メッセージを影響することに注意してください。エンド・ツー・エンド通信の<セッションID>オブジェクトは、内部ノードに、GISTを介して、表示されています。 RMD-QOSMに関連付けられているセキュリティの脅威を定義するために、我々は考えることRMD領域の内側に配置されてもよいし、シグナリングパケットを、遅延をドロップ複製し、注入し、または修正することができる敵。
Depending on the location of the adversary, we speak about an on-path adversary or an off-path adversary, see also RFC 4081 [RFC4081].
敵の場所に応じて、我々はまた、RFC 4081 [RFC4081]を参照してください、上のパス敵またはオフパスの敵について話します。
The on-path adversary is a node, which supports RMD-QOSM and is able to observe RMD-QOSM signaling message exchanges.
上のパスが敵RMD-QOSMをサポートし、RMD-QOSMシグナリングメッセージ交換を観察することができるノードです。
1) Dropping signaling messages
1）シグナリングメッセージを削除
An adversary could drop any signaling messages after receiving them. This will cause a failure of reservation request for new sessions or deletion of resource units (bandwidth) for ongoing sessions due to states timeout.
敵は、それらを受信した後、任意のシグナリングメッセージをドロップすることができます。これは、新しいセッションまたは状態のタイムアウトのために進行中のセッションのためのリソースユニット（帯域幅）の削除のための予約要求の失敗の原因となります。
It may trigger the Ingress node to retransmit the lost signaling messages. In this scenario, the adversary drops selected signaling messages, for example, intra-domain reserve messages. In the RMD-QOSM, the retransmission mechanism can be provided at the Ingress node to make sure that signaling messages can reach the Egress node. However, the retransmissions triggered by the adversary dropping messages may cause certain problems. Therefore, disabling the use of retransmissions in the RMD-QOSM-aware network is recommended, see also Section 4.6.1.1.1.
これは、失われたシグナリングメッセージを再送するIngressノードをトリガすることができます。このシナリオでは、敵滴は、シグナリングメッセージ、例えば、ドメイン内のリザーブメッセージを選択されました。 RMD-QOSMでは、再送信メカニズムは、シグナリングメッセージがEgressノードに到達できることを確認するために、Ingressノードで提供することができます。しかし、メッセージをドロップする敵によってトリガ再送は、特定の問題が発生することがあります。したがって、RMD-QOSM対応のネットワークにおける再送信の使用を無効にすると、推奨される節も4.6.1.1.1を参照してください。
2) Delaying Signaling Messages
2）遅延シグナリングメッセージ
Any signaling message could be delayed by an adversary. For example, if RESERVE' messages are delayed over the duration of the refresh period, then the resource units (bandwidth) reserved along the nodes for corresponding sessions will be removed. In this situation, the Ingress node does not receive the RESPONSE within a certain period, and considers that the signaling message has failed, which may cause a retransmission of the "failed" message. The Egress node may distinguish between the two messages, i.e., the delayed message and the retransmitted message, and it could get a proper response.
任意のシグナリングメッセージは、敵によって遅延され得ます。 RESERVE」メッセージはリフレッシュ周期の期間にわたって遅延される場合、例えば、対応するセッションのノードに沿って予約されたリソースユニット（帯域幅）が除去されます。この状況では、イングレスノードは、一定期間内に応答を受信し、シグナリングメッセージは「失敗」メッセージの再送を引き起こす可能性が、故障していると考えません。出口ノードは、二つのメッセージ、すなわち、遅延メッセージと再送メッセージとを区別することができる、それは適切な応答を得ることができます。
However, Interior nodes suffer from this retransmission and they may reserve twice the resource units (bandwidth) requested by the Ingress node.
しかし、インテリアノードは、この再送信に苦しむ彼らはIngressノードによって要求された二回リソースユニット（帯域幅）を予約することができます。
3) Replaying Signaling Messages
3）シグナリングメッセージをリプレイ
An adversary may want to replay signaling messages. It first stores the received messages and decides when to replay these messages and at what rate (packets per second).
敵はシグナリングメッセージを再生することもできます。これは、最初は、受信したメッセージと、これらのメッセージとどのような割合で（秒あたりのパケット）を再生する際に決定しました。
When the RESERVE' message carried an <RII> object, the Egress will reply with a RESPONSE' message towards the Ingress node. The Ingress node can then detect replays by comparing the value of <RII> in the RESPONSE' messages with the stored value.
RESERVE場合Ingressノードに向けてメッセージ「メッセージは<RII>オブジェクトを行っ、退出はRESPONSEで応答します」。イングレスノードは、格納された値を持つRESPONSE」メッセージに<RII>の値を比較することによって、リプレイを検出することができます。
4) Injecting Signaling Messages
4）シグナリングメッセージを注入
Similar to the replay-attack scenario, the adversary may store a part of the information carried by signaling messages, for example, the <RSN> object. When the adversary injects signaling messages, it puts the stored information together with its own generated parameters (RMD-QSPEC <TMOD-1> parameter, <RII>, etc.) into the injected messages and then sends them out. Interior nodes will process these messages by default, reserve the requested resource units (bandwidth) and pass them to downstream nodes.
リプレイ攻撃のシナリオと同様に、敵は、例えば、<RSN>オブジェクト、シグナリングメッセージによって搬送される情報の一部を格納することができます。敵対者がシグナリングメッセージを注入する場合、それはそれ自身の生成したパラメータ注入メッセージに（RMD-QSPEC <TMOD-1>パラメータ<RII>、など）と一緒に格納された情報を入れ、次にそれらを送出します。インテリアノードは、デフォルトではこれらのメッセージを処理し、要求されたリソースユニット（帯域幅）を確保し、下流のノードに渡します。
It may happen that the resource units (bandwidth) on the Interior nodes are exhausted if these injected messages consume too much bandwidth.
これらの注入されたメッセージは、あまりにも多くの帯域幅を消費した場合に内部ノード上のリソースユニット（帯域幅）が排出されることが起こり得ます。
5) Modifying Signaling Messages
5）シグナリングメッセージを変更
On-path adversaries are capable of modifying any part of the signaling message. For example, the adversary can modify the <M>, <S>, and <O> parameters of the RMD-QSPEC messages. The Egress node will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID> objects to refer to that flow to be terminated or set to lower priority. It is also possible for the adversary to modify the RMD-QSPEC <TMOD-1> parameter and/or <PHB Class> parameter, which could cause a modification of an amount of the requested resource units (bandwidth) changes.
オンパス敵は、シグナリングメッセージの任意の部分を変更することが可能です。例えば、敵対者は変更することができ、<M>、<S>、および<O> RMD-QSPECメッセージのパラメータ。出口ノードは、次に、セッションIDを使用し、その後<製本セッションID>オブジェクトが終了または低い優先度に設定すべきフローを参照します。敵が要求されたリソースユニット（帯域幅）の変化量の修正を引き起こす可能性がある、RMD-QSPEC <TMOD-1>パラメータおよび/または<PHBクラス>パラメータを変更することも可能です。
In this case, the adversary is not located on-path and it does not participate in the exchange of RMD-QOSM signaling messages, and therefore is unable to eavesdrop signaling messages. Hence, the adversary does not know valid <RII>s, <RSN>s, and <SESSION-ID>s. Hence, the adversary has to generate new parameters and constructs new signaling messages. Since Interior nodes operate in reduced-state mode, injected signaling messages are treated as new once, which causes Interior nodes to allocate additional reservation state.
この場合、敵対者はオン経路に配置されず、RMD-QOSMシグナリングメッセージの交換に参加し、したがってシグナリングメッセージを盗聴することができないありません。したがって、敵は有効な<RII> Sを知っている、<RSN> S、および<SESSION-ID>はありません。したがって、敵は新しいパラメータを生成する必要があり、新たなシグナリングメッセージを作成します。内部ノードは低減状態モードで動作するので、シグナリングメッセージを注入インテリアノードは、追加の予約状態を割り当てる引き起こす、一度新しいとして扱われます。
The following security requirements are set as goals for the intra-domain communication, namely:
以下のセキュリティ要件は、つまり、ドメイン内の通信のための目標として設定されています。
* Nodes, which are never supposed to participate in the NSIS signaling exchange, must not interfere with QNE Interior nodes. Off-path nodes (off-path with regard to the path taken by a particular signaling message exchange) must not be able to interfere with other on-path signaling nodes.
NSISシグナリング交換に参加することになってされることはありません*ノードは、QNEインテリアノードを妨害してはなりません。オフパスのノード（オフパス特定のシグナリングメッセージの交換によって取ら経路に関して）は、他にパスシグナリングノードを妨害することがあってはなりません。
* The actions allowed by a QNE Interior node should be minimal (i.e., only those specified by the RMD-QOSM). For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads.
* QNEインテリアノードにより許可されたアクションは最小限であるべきである（すなわち、唯一RMD-QOSMによって指定されたもの）。例えば、QNE入力およびQNE出口ノードのみが、特定のシグナリングメッセージを開始することを許可されています。 QNE内部ノードは、例えば、特定のシグナリングメッセージペイロードを修正することが許されます。
Note that the term "interfere" refers to all sorts of security threats, such as denial-of-service, spoofing, replay, signaling message injection, etc.
そのようなサービス拒否、なりすまし、リプレイ、メッセージ注入シグナリング、等のように、用語「干渉」はセキュリティ上の脅威のすべての種類を指すことに留意されたいです
An important security mechanism that was built into RMD-QOSM was the ability to tie the end-to-end RESERVE and the RESERVE' messages together using the BOUND-SESSION-ID and to allow the Ingress node to match the RESERVE' with the RESPONSE' by using the <RII>. These mechanisms enable the Edge nodes to detect unexpected signaling messages.
RMD-QOSMに組み込まれた重要なセキュリティメカニズムは、エンドツーエンドRESERVEを結びつける能力とRESERVE「メッセージを一緒BOUND-SESSION-IDを使用してIngressノードがRESERVEを一致させることができるように」応答していました'<RII>を使用します。これらのメカニズムは、予想外のシグナリングメッセージを検出するために、エッジ・ノードを有効にします。
We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel security provided by GIST and protected between the QNE Ingress and the QNE Egress. GIST security mechanisms MUST be used to offer authentication, integrity, and replay protection. Furthermore, encryption MUST be used to prevent an adversary located along the path of the RESERVE message from learning information about the session that can later be used to inject a RESERVE' message.
私たちは、RESERVE /レスポンスがGISTが提供するホップバイホップチャネルセキュリティで送信され、QNE入力およびQNE出口の間で保護されていることを前提としています。 GISTのセキュリティメカニズムは、認証、整合性、および再生保護を提供するために使用しなければなりません。さらに、暗号化は、後でRESERVE」メッセージを注入するために使用することができるセッションに関する情報を学習からRESERVEメッセージの経路に沿って位置する敵を防ぐために使用されなければなりません。
The following messages need to be mapped to each other to make sure that the occurrence of one message is not without the other:
次のメッセージが一つのメッセージの発生は他がないわけではないことを確認するために、相互にマップする必要があります。
a) the RESERVE and the RESERVE' relate to each other at the QNE Egress; and
A）RESERVEとRESERVE」はQNE出口で相互に関連し、そして
b) the RESPONSE and the RESERVE relate to each other at the QNE Ingress; and
B）RESPONSEとRESERVEはQNE入口で互いに関連。そして
c) the RESERVE' and the RESPONSE' relate to each other. The <RII> is carried in the RESERVE' message and the RESPONSE' message that is generated by the QNE Egress node contains the same <RII> as the RESERVE'. The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'. The QNE Egress is able to determine whether the RESERVE' was created by the QNE Ingress node since the intra-domain session, which sent the RESERVE', is bound to an end-to-end session via the <BOUND-SESSION-ID> value included in the intra-domain QoS-NSLP operational state maintained at the QNE Egress.
C）RESERVE「およびRESPONSE」は互いに関連しています。 <RII> RESERVEで運ば「メッセージとRESPONSE」QNE出口ノードによって生成されたメッセージは、<RII> RESERVE」と同じ含まれます。 <RII>「応答で」RESERVEと一致するQNEのIngressで使用することができます。 QNE出口は<BOUND-SESSION-ID>を介して、エンド・ツー・エンドのセッションにバインドされ、RESERVE「はRESERVEを送信したドメイン内のセッション、以降QNE Ingressノードによって作成された」かどうかを決定することが可能です値はQNE出口で維持し、ドメイン内のQoS-NSLP動作状態に含まれています。
The RESERVE and the RESERVE' message are tied together using the BOUND-SESSION-ID(s) maintained by the intra-domain and end-to-end QoS-NSLP operational states maintained at the QNE Edges (see Sections 4.3.1, 4.3.2, and 4.3.3). Hence, there cannot be a RESERVE' without a corresponding RESERVE. The SESSION-ID can fulfill this purpose quite well if the aim is to provide protection against off-path adversaries that do not see the SESSION-ID carried in the RESERVE and the RESERVE' messages.
RESERVEとRESERVE」というメッセージ内ドメインとエンドツーエンドのQoS-NSLP動作状態によって（S）BOUND-SESSION-IDを使用して一緒に結ば維持されているが、セクション4.3.1、4.3を参照してください（QNEのエッジに維持しました0.2、および4.3.3）。したがって、対応するRESERVE無しRESERVE」が存在することはできません。目的はRESERVEとRESERVE」メッセージで運ばSESSION-IDが表示されないオフパスの敵に対する保護を提供することであるならばSESSION-IDは非常によく、この目的を果たすことができます。
If, however, the path changes (due to rerouting or due to mobility), then an adversary could inject RESERVE' messages (with a previously seen SESSION-ID) and could potentially cause harm.
ただし、パスが（原因リルートするかによるモビリティに）変更された場合、その敵は（以前に見SESSION-IDを持つ）RESERVE」メッセージを注入でき、潜在的に害を引き起こす可能性があります。
An off-path adversary can, of course, create RESERVE' messages that cause intermediate nodes to create some state (and cause other actions) but the message would finally hit the QNE Egress node. The QNE Egress node would then be able to determine that there is something going wrong and generate an error message.
オフパスの敵は、当然のことながら、中間ノードは、いくつかの状態を作成（および他のアクションを起こす）を引き起こすRESERVE」メッセージを作成することができますが、メッセージは最終的にQNE出口ノードを打つでしょう。 QNE出口ノードは、間違っているものがあることを決定することができると、エラーメッセージが生成されます。
The severe congestion handling can be triggered by intermediate nodes (unlike other messages). In many cases, however, intermediate nodes experiencing congestion use refresh messages modify the <S> and <O> parameters of the message. These messages are still initiated by the QNE Ingress node and carry the SESSION-ID. The QNE Egress node will use the SESSION-ID and subsequently the BOUND-SESSION-ID, maintained by the intra-domain QoS-NSLP operational state, to refer to a flow that might be terminated. The aspect of intermediate nodes initiating messages for severe congestion handling is for further study.
重度の輻輳処理は、（他のメッセージとは異なり）中間ノードによってトリガすることができます。しかし、多くの場合、輻輳使用リフレッシュメッセージを経験中間ノードは、メッセージの<S>と<O>パラメータを変更します。これらのメッセージはまだQNE Ingressノードによって開始され、SESSION-IDを運ぶされています。 QNE出口ノードが停止される可能性がありますフローを参照するために、ドメイン内のQoS-NSLP動作状態で維持され、SESSION-ID、その後BOUND-SESSION-IDを使用します。深刻な輻輳処理のためのメッセージを開始する中間ノードの側面は、今後の検討課題です。
During the refresh procedure, a RESERVE' creates a RESPONSE', see Figure 25. The <RII> is carried in the RESERVE' message and the RESPONSE' message that is generated by the QNE Egress node contains the same <RII> as the RESERVE'.
リフレッシュ手順の間、RESERVEは、図25ザが<RIIは> RESERVE「メッセージとRESPONSE」QNE出口ノードによって生成されるメッセージで運ばれるが、<RII> RESERVE同じ含ま参照「応答を作成します」 」。
The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'.
<RII>「応答で」RESERVEと一致するQNEのIngressで使用することができます。
A further aspect is marking of data traffic. Data packets can be modified by an intermediary without any relationship to a signaling session (and a SESSION-ID). The problem appears if an off-path adversary injects spoofed data packets.
さらに別の態様は、データトラフィックのマーキングされています。データパケットは、シグナリングセッションに任意の関係（およびセッションID）なしで仲介することにより修飾することができます。オフパスの敵対者が偽装されたデータパケットを注入すると、問題が表示されます。
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| REFRESH RESERVE' | |
+-------------->| REFRESH RESERVE' |
| (+RII) +-------------->| REFRESH RESERVE'
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE'|
|<---------------------------------------------+
| | | (+RII) |
Figure 25: RMD REFRESH message exchange
図25：RMD REFRESHメッセージ交換
The adversary thereby needs to spoof data packets that relate to the flow identifier of an existing end-to-end reservation that SHOULD be terminated. Therefore, the question arises how an off-path adversary SHOULD create a data packet that matches an existing flow identifier (if a 5-tuple is used). Hence, this might not turn out to be simple for an adversary unless we assume the previously mentioned mobility/rerouting case where the path through the network changes and the set of nodes that are along a path changes over time.
敵対者は、これにより終了すべき既存のエンド・ツー・エンドの予約のフロー識別子に関連するデータパケットを偽装する必要があります。したがって、問題は、オフパス敵対者が（5タプルが使用される場合）は、既存のフロー識別子と一致するデータ・パケットを作成する必要がどのように生じます。我々は前述のモビリティ/ネットワークの変更を通過する経路と時間をかけてパスの変更に沿っているノードの集合ケースを再ルーティングを前提としない限り、したがって、これは敵のためのシンプルであることが判明しない場合があります。
This section defines additional codepoint assignments in the QSPEC Parameter ID registry, in accordance with BCP 26 [RFC5226].
このセクションでは、BCP 26 [RFC5226]に従って、QSPECパラメータIDレジストリに追加のコードポイントの割り当てを定義します。
This document specifies the following QSPEC containers in the QSPEC Parameter ID registry created in [RFC5975]:
この文書では、[RFC5975]で作成しQSPECパラメータIDレジストリに次のQSPECコンテナを指定します。
<PHR_Resource_Request> (Section 4.1.2 above, ID=17)
<PHR_Resource_Request>（4.1.2上記、ID = 17）
<PHR_Release_Request> (Section 4.1.2 above, ID=18)
<PHR_Release_Request>（4.1.2上記、ID = 18）
<PHR_Refresh_Update> (Section 4.1.2 above, ID=19)
<PHR_Refresh_Update>（4.1.2上記、ID = 19）
<PDR_Reservation_Request> (Section 4.1.3 above, ID=20)
<PDR_Reservation_Request>（セクション4.1.3上記、ID = 20）
<PDR_Refresh_Request> (Section 4.1.3 above, ID=21)
<PDR_Refresh_Request>（セクション4.1.3上記、ID = 21）
<PDR_Release_Request> (Section 4.1.3 above, ID=22)
<PDR_Release_Request>（セクション4.1.3上記、ID = 22）
<PDR_Reservation_Report> (Section 4.1.3 above, ID=23)
<PDR_Reservation_Report>（セクション4.1.3上記、ID = 23）
<PDR_Refresh_Report> (Section 4.1.3 above, ID=24)
<PDR_Refresh_Report>（セクション4.1.3上記、ID = 24）
<PDR_Release_Report> (Section 4.1.3 above, ID=25)
<PDR_Release_Report>（セクション4.1.3上記、ID = 25）
<PDR_Congestion_Report> (Section 4.1.3 above, ID=26)
<PDR_Congestion_Report>（セクション4.1.3上記、ID = 26）
The authors express their acknowledgement to people who have worked on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant, O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S. Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M. Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van Houwelingen, D. Dimitrova, T. Sealy, H. Chang, and J. de Waal.
Z. Turanyi、R.サボー、G. Pongracz、A. Marquetant、O.ポップ、V. Rexhepi、G. Heijenk、D.パーテイン、M.・ヤコブソン：著者は、RMDのコンセプトに働いている人々に彼らの承認を表明します、S. Oosthoek、P. Wallentin、P.ゲーリング、A. Stienstra、M.デコーゲル、M. Zoumaro-Djayoon、M. Swanink、R. G. Klaver Stokkink、JWバンHouwelingen、D. Dimitrova、T.シーリー、H.チャン、およびJ.デワール。
[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月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[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月。
[AdCa03] Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D., "Estimation of congestion price using probabilistic packet marking", Proc. IEEE INFOCOM, pp. 2068-2078, 2003.
【AdCa03]アドラー、M.、カイ、J.-Y.、シャピロ、J. K.、Towsley、D.、 "混雑価格の推定はマーキング確率パケットを使用して"、PROC。 IEEE INFOCOM、頁2068-2078、2003。
[AnHa06] Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation Error of Adaptive Deterministic Packet Marking", 44th Annual Allerton Conference on Communication, Control and Computing, 2006.
[AnHa06]ラクランL. H.アンドリュー・スティーブンV.ハンリー、「適応決定論パケットの推定誤差がマーキング」、コミュニケーション、コントロールとコンピューティング、2006年第44回年次大会アラートン。
[AtLi01] Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM: active queue management", IEEE Network, vol. 15, pp. 48-53, May/June 2001.
【AtLi01] Athuraliya、S.、リチウム、V. H.、低、S. H.、陰陽、Q.、 "REM：アクティブキュー管理"、IEEEネットワーク、体積15頁。 48〜53月/ 2001年6月。
[Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis, University of Twente, 2007.
[Chan07] H.チャン、修士論文、トウェンテ大学、2007年 "RMD-QOSMのセキュリティサポート"。
[CsTa05] Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient Reduced-State Resource Reservation", Journal of Communication and Networks, Vol. 7, No. 4, December 2005.
[CsTa05] Csaszar、A.、タカーチ、A.、サボー、R.、ヘンク、T.、 "弾力性の低減状態リソース予約"、通信・ネットワーク誌、Vol。図7に示すように、第4号、2005年12月。
[DiKa08] Dimitrova, D., Karagiannis, G., de Boer, P.-T., "Severe congestion handling approaches in NSIS RMD domains with bi-directional reservations", Journal of Computer Communications, Elsevier, vol. 31, pp. 3153-3162, 2008.
【DiKa08] Dimitrova、D.、Karagiannis、G.、デ・ボーア、P.-T.、 "双方向予約とNSIS RMDドメインにおける重度輻輳処理アプローチ"、コンピュータ通信、エルゼビア誌vol。 31頁。3153から3162、2008。
[JaSh97] Jamin, S., Shenker, S., Danzig, P., "Comparison of Measurement-based Admission Control Algorithms for Controlled-Load Service", Proceedings IEEE Infocom '97, Kobe, Japan, April 1997.
、議事IEEEインフォコム'97、神戸、日本、1997年4月[JaSh97]ヤミン、S.、Shenker、S.、ダンツィヒ、P.、 "制御・ロード・サービスのための測定に基づくアドミッション制御アルゴリズムの比較"。
[GrTs03] Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition Approach to Measurement-Based Admission Control", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, August 2003.
【GrTs03] Grossglauser、M.、ツェー、D.N.C、「測定ベースのアドミッション制御のタイムスケール分解アプローチ」、ネットワーキング、巻上のIEEE / ACMトランザクション。 11、第4号、2003年8月。
[Part94] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994).
[Part94] C.パートリッジ、ギガビットネットワーク、アディソンウェズリー出版社（1994）。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215] Shenker、S.とJ. Wroclawski、 "統合サービスネットワーク要素のための一般的な特性化パラメータ"、RFC 2215、1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2638] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[RFC2638]ニコルズ、K.、ヤコブソン、V.、およびL.チャン、 "インターネットのための2ビットの差別化サービスアーキテクチャ"、RFC 2638、1999年7月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE 。Felstaine、 "Diffservのネットワーク経由の統合サービス操作のための枠組み"、RFC 2998、2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC3726] Brunner, M., Ed., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、M.、エド。、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[RFC4125]ルFaucheur、F.およびW.ライ、 "Diffservの認識MPLSトラフィックエンジニアリングの最大割り当て帯域幅の制約モデル"、RFC 4125、2005年6月。
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、RFC 4127、2005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig、H.およびD. Kroeselberg、 "シグナリングにおける次のステップのためのセキュリティの脅威（NSIS）"、RFC 4081、2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866]のSun、D.、編、マッキャン、P.、Tschofenig、H.、ツオウ、T.、ドリア、A.、およびG.ゾルン、編、 "直径クオリティ・オブ・サービスアプリケーション"、RFC 5866、2010年5月。
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, Ed., "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[RFC5978]マナー、J.、ブレス、R.、Loughney、J.、およびE.デイヴィス、編、RFC 5978 "NSISプロトコルファミリを使用すると拡張" 2010年10月。
[RMD1] Westberg, L., et al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", IFIP PfHSN 2002.
[RMD1] Westberg、L.ら、 "Diffservの中にリソース管理（RMD）：機能とパフォーマンス動作概要"、2002 IFIP PfHSN。
[RMD2] G. Karagiannis, et al., "RMD - a lightweight application of NSIS" Networks 2004, Vienna, Austria.
[RMD2] G. Karagiannis、ら、 "RMD - NSISの軽量なアプリケーション"。ネットワーク2004、ウィーン、オーストリア。
[RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z., "Novel Enhancements to Load Control - A Soft-State, Lightweight Admission Control Protocol", Proc. of the 2nd Int. Workshop on Quality of Future Internet Services, Coimbra, Portugal, Sept 24-26, 2001, pp. 82-96.
【RMD3] MarquetantのA.、ポップO.、ザボR.、Dinnyes G.、Turanyi Z.、 "コントロールをロードするための新規の拡張 - ソフトステート、軽量アドミッション制御プロトコル"、PROC。第二のIntの。今後のインターネットサービスの品質、コインブラ、ポルトガル、9月24-26、2001年、頁82-96ワークショップ。
[RMD4] A. Csaszar et al., "Severe congestion handling with resource management in diffserv on demand", Networking 2002.
[RMD4] A. Csaszarら、「オンデマンドのDiffServにおける資源管理と取り扱い重度渋滞」、ネットワーク2002。
[TaCh99] P. P. Tang, T-Y Charles Tai, "Network Traffic Characterization Using Token Bucket Model", IEEE Infocom 1999, The Conference on Computer Communications, no. 1, March 1999, pp. 51-62.
[TaCh99] P. P.唐、T-Yチャールズ泰、「トークンバケットモデルを用いたネットワークトラフィックの特性評価」、IEEEインフォコム1999年、コンピュータコミュニケーションに関する会議、ありません。 1、1999年3月、頁51-62。
[ThCo04] Thommes, R. W., Coates, M. J., "Deterministic packet marking for congestion packet estimation" Proc. IEEE Infocom, 2004.
【ThCo04] Thommesの、R. W.、コーツ、M. J.、PROC "輻輳パケットの推定のためにマーキング確定パケット"。 IEEEインフォコム、2004。
Appendix A. Examples
付録A.例
A.1. Example of a Re-Marking Operation during Severe Congestion in the Interior Nodes
A.1。インテリアノードにおける重度の輻輳時に再マーキング動作例
This appendix describes an example of a re-marking operation during severe congestion in the Interior nodes.
この付録では、内部ノードにおける重度の輻輳中に再マーキング動作の例を説明します。
Per supported PHB, the Interior node can support the operation states depicted in Figure 26, when the per-flow congestion notification based on probing signaling scheme is used in combination with this severe congestion type. Figure 27 depicts the same functionality when the per-flow congestion notification based on probing scheme is not used in combination with the severe congestion scheme. The description given in this and the following appendices, focuses on the situation where: (1) the "notified DSCP" marking is used in congestion notification state, and (2) the "encoded DSCP" and "affected DSCP" markings are used in severe congestion state. In this case, the "notified DSCP" marking is used during the congestion notification state to mark all packets passing through an Interior node that operates in the congestion notification state. In this way, and in combination with probing, a flow-based ECMP solution can be provided for the congestion notification state. The "encoded DSCP" marking is used to encode and signal the excess rate, measured at Interior nodes, to the Egress nodes. The "affected DSCP" marking is used to mark all packets that are passing through a severe congested node and are not "encoded DSCP" marked.
あたりのインテリアノードは、図26、信号方式がこの厳しい輻輳タイプと組み合わせて使用されるプローブに基づくフローごとの輻輳通知に示されている動作状態をサポートすることができ、PHBを支持しました。図27は、スキームプロービングに基づいてフローごとの輻輳通知を重度の輻輳方式と組み合わせて使用されていない同じ機能を示しています。この中で与えられた説明および以下の付録は、状況に焦点を当てて：（1）「通知DSCPが」輻輳通知状態で使用されるマーキング、及び（2）「符号化DSCP」および「影響を受けたDSCP」マーキングは、で使用されています深刻な輻輳状態。この場合、マーキング「DSCPを通知は、」輻輳通知状態で動作する内部ノードを通過するすべてのパケットをマークする輻輳通知状態中に使用されます。このように、プロービングと組み合わせて、フローベースのECMP液が輻輳通知状態のために提供することができます。 「符号化されたDSCPが」マーキングが出口ノードに、内部ノードで測定された過剰率を、符号化及びシグナリングするために使用されます。 「影響を受けたDSCPは」マーキングが厳しい輻輳したノードを通過するとマークされ、「エンコードされたDSCP」ではありませんされているすべてのパケットをマークするために使用されます。
Another possible situation could be derived in which both congestion notification and severe congestion state use the "encoded DSCP" marking, without using the "notified DSCP" marking. The "affected DSCP" marking is used to mark all packets that pass through an Interior node that is in severe congestion state and are not "encoded DSCP" marked. In addition, the probe packet that is carried by an intra-domain RESERVE message and pass through Interior nodes SHOULD be "encoded DSCP" marked if the Interior node is in congestion notification or severe congestion states. Otherwise, the probe packet will remain unmarked. In this way, an ECMP solution can be provided for both congestion notification and severe congestion states. The"encoded DSCP" packets signal an excess rate that is not only associated with Interior nodes that are in severe congestion state, but also with Interior nodes that are in congestion notification state. The algorithm at the Interior node is similar to the algorithm described in the following appendix sections. However, this method is not described in detail in this example.
別の可能性のある状況は、輻輳通知と深刻な輻輳状態の両方をマーキング「通知DSCP」を使用せずに、マーキング「エンコードされたDSCP」を使用した導出することができます。 「影響を受けたDSCPが」マーキングが重度の輻輳状態であるとマークされた「符号化されたDSCP」ではない内部ノードを通過するすべてのパケットをマークするために使用されます。また、ドメイン内RESERVEメッセージによって運ばれ、内部ノードを通過されたプローブパケットは、内部ノードが輻輳通知または重度の輻輳状態である場合にマークされた「符号化されたDSCP」である必要があります。それ以外の場合は、プローブパケットがマークされていないままになります。このように、ECMP液は、輻輳通知および重度輻輳状態の両方のために提供することができます。 「符号化されたDSCP」パケットは、重度の輻輳状態にある内部ノードに関連付けられているだけでなく、輻輳通知状態にある内部ノードを有するだけでなく、過剰率を通知します。内部ノードのアルゴリズムは、以下の付録のセクションで説明したアルゴリズムと同様です。しかし、この方法は、この例で詳細に説明されていません。
---------------------------------------------
| event B |
| V
---------- ------------- ----------
| Normal | event A | Congestion | event B | Severe |
| state |---------->| notification|-------->|congestion|
| | | state | | state |
---------- ------------- ----------
^ ^ | |
| | event C | |
| ----------------------- |
| event D |
------------------------------------------------
Figure 26: States of operation, severe congestion combined with congestion notification based on probing
図26：操作の状態、プロービングに基づく輻輳通知と組み合わせる厳しい混雑
---------- -------------
| Normal | event B | Severe |
| state |-------------->| congestion |
| | | state |
---------- -------------
^ |
| event E |
---------------------------
Figure 27: States of operation, severe congestion without congestion notification based on probing
図27：操作の状態、プロービングに基づく輻輳通知なしに厳しい混雑
The terms used in Figures 26 and 27 are:
図26及び27で使用される用語です。
Normal state: represents the normal operation conditions of the node, i.e., no congestion.
正常状態：ノード、即ち、渋滞なしの通常の動作条件を表します。
Severe congestion state: represents the state in which the Interior node is severely congested related to a certain PHB. It is important to emphasize that one of the targets of the severe congestion state solution to change the severe congestion state behavior directly to the normal state.
重度の輻輳状態：インテリアノードが厳しく特定PHBに関連する混雑している状態を表しています。深刻な輻輳状態ソリューションの目標の一つは、通常の状態に直接的に深刻な輻輳状態の動作を変更することを強調することが重要です。
Congestion notification: state in which the load is relatively high, close to the level when congestion can occur.
輻輳通知：負荷は、輻輳が発生することができたときにレベルに近い、比較的高くなっている状態。
event A: this event occurs when the incoming PHB rate is higher than the "congestion notification detection" threshold and lower than the "severe congestion detection". This threshold is used by the congestion notification based on probing scheme, see Sections 4.6.1.7 and 4.6.2.6.
イベントA：着信PHB率が「輻輳通知検出」閾値と「重度輻輳検出」よりも低いよりも高い場合、このイベントが発生します。このしきい値は、スキームプロービングに基づく輻輳通知で使用され、セクション4.6.1.7と4.6.2.6を参照してください。
event B: this event occurs when the incoming PHB rate is higher than the "severe congestion detection" threshold.
イベントB：受信PHB率は「深刻な輻輳検出」しきい値よりも高い場合、このイベントが発生します。
event C: this event occurs when the incoming PHB rate is lower than or equal to the "congestion notification detection" threshold.
イベントC：着信PHB率が「輻輳通知検出」閾値以下である場合、このイベントが発生します。
event D: this event occurs when the incoming PHB rate is lower than or equal to the "severe_congestion_restoration" threshold. It is important to emphasize that this even supports one of the targets of the severe congestion state solution to change the severe congestion state behavior directly to the normal state.
イベントD：着信PHB率が「severe_congestion_restoration」閾値以下である場合、このイベントが発生します。でも正常な状態に直接深刻な輻輳状態の動作を変更するために深刻な輻輳状態ソリューションの目標の一つをサポートしていることを強調することが重要です。
event E: this event occurs when the incoming PHB rate is lower than or equal to the "severe congestion restoration" threshold.
イベントE：着信PHB率は「重度の輻輳復旧」閾値以下である場合、このイベントが発生します。
Note that the "severe congestion detection", "severe congestion restoration" and admission thresholds SHOULD be higher than the "congestion notification detection" threshold, i.e., "severe congestion detection" > "congestion notification detection" and "severe congestion restoration" > "congestion notification detection".
">「深刻な輻輳検出」、「深刻な渋滞回復」と入場しきい値は、「輻輳通知検出」しきい値、すなわち、「深刻な輻輳検出」>「輻輳通知検出」と「激しい渋滞回復」よりも高くする必要があることに注意してください輻輳通知検出」。
Furthermore, the "severe congestion detection" threshold SHOULD be higher than or equal to the admission threshold that is used by the reservation-based and NSIS measurement-based signaling schemes. "severe congestion detection" >= admission threshold.
また、「重度の輻輳検出」閾値は、予約ベースとNSIS測定ベースのシグナリング方式で使用されるアドミッション閾値以上であるべきです。 「深刻な輻輳検出」> =入場しきい値。
Moreover, the "severe congestion restoration" threshold SHOULD be lower than or equal to the "severe congestion detection" threshold that is used by the reservation-based and NSIS measurement-based signaling schemes, that is:
また、「重度の輻輳回復」閾値よりも低いか、予約ベースとNSIS測定ベースのシグナリング方式で使用される「重度輻輳検出」閾値に等しくなければならない、すなわち：
"severe congestion restoration" <= "severe congestion detection"
「ひどい渋滞復元」<=「深刻な輻輳検出」
During severe congestion, the Interior node calculates, per traffic class (PHB), the incoming rate that is above the "severe congestion restoration" threshold, denoted as signaled_overload_rate, in the following way:
重度の輻輳時に、内部ノードは、トラフィッククラス（PHB）、以下のように、signaled_overload_rateとして示される、「重度の輻輳回復」閾値を超えている着信レートあたり、計算します。
* A severe congested Interior node SHOULD take into account that packets might be dropped. Therefore, before queuing and eventually dropping packets, the Interior node SHOULD count the total number of unmarked and re-marked bytes received by the severe congested node, denote this number as total_received_bytes. Note that there are situations in which more than one Interior node in the same path become severely congested. Therefore, any Interior node located behind a severely congested node MAY receive marked bytes.
*激しい混雑インテリアノードは、パケットが廃棄される可能性がありますことを考慮すべきです。したがって、キューイングし、最終的にパケットをドロップする前に、内部ノードは、重度の輻輳ノードによって受信マークされていないと再マークされたバイトの総数をカウントtotal_received_bytes、この数を示すべきです。同じパス内に複数の内部ノードがひどく混雑した状況があることに留意されたいです。そのため、深刻な輻輳したノードの背後にある任意のインテリアノードがマークされたバイトを受け取ることができます。
When the "severe congestion detection" threshold per PHB is set equal to the maximum capacity allocated to one PHB used by the RMD-QOSM, it means that if the maximum capacity associated to a PHB is fully utilized and a packet belonging to this PHB arrives, then it is assumed that the Interior node will not forward this packet downstream.
PHBあたり「重度輻輳検出」閾値はRMD-QOSMによって使用されるものPHBに割り当てられた最大容量に等しく設定されている場合は、PHBに関連する最大容量が完全に利用されている場合は、このPHBに属するパケットが到着したことを意味します、インテリアノードは、下流このパケットを転送しないと想定されます。
In other words, this packet will either be dropped or set to another PHB. Furthermore, this also means that after the severe congestion situation is solved, then the ongoing flows will be able to send their associated packets up to a total rate equal to the maximum capacity associated with the PHB. Therefore, when more than one Interior node located on the same path will be severely congested and when the Interior node receives "encoded DSCP" marked packets, it means that an Interior node located upstream is also severely congested.
言い換えれば、このパケットは、いずれかの別のPHBに落としたり設定されます。さらに、これはまた、重度の輻輳状態が解消された後、その後の継続的な流れは、PHBに関連付けられた最大容量に等しい総速度までそれらに関連するパケットを送信することができるであろうことを意味します。したがって、同じ経路上に位置する複数の内部ノードがひどく混雑となり、内部ノードが「符号化されたDSCP」とマークされたパケットを受信すると、上流側の内部ノードもひどく輻輳していることを意味します。
When the "severe congestion detection" threshold per PHB is set equal to the maximum capacity allocated to one PHB, then this Interior node MUST forward the "encoded DSCP" marked packets and it SHOULD NOT consider these packets during its local re-marking process. In other words, the Egress should see the excess rates encoded by the different severely congested Interior nodes as independent, and therefore, these independent excess rates will be added.
PHBあたり「重度輻輳検出」閾値が1つのPHBに割り当てられた最大容量に等しく設定されている場合、この内部ノードは、「符号化されたDSCP」はパケットをマーク転送しなければならず、そのローカル再マーキング工程中にこれらのパケットを考慮すべきではありません。換言すれば、退出は独立として異なるひどく輻輳インテリアノードによってコード過剰率を表示する必要があり、したがって、これらの独立した過剰率が追加されます。
When the "severe congestion detection" threshold per PHB is not set equal to the maximum capacity allocated to one PHB, this means that after the severe congestion situation is solved, the ongoing flows will not be able to send their associated packets up to a total rate equal to the maximum capacity associated with the PHB, but only up to the "severe_congestion_threshold". When more than one Interior node located on the same communication path is severely congested and when one of these Interior node receives "encoded_DSCP" marked packets, this Interior node SHOULD NOT mark unmarked, i.e., either "original DSCP" or "affected DSCP" or "notified DSCP" encoded packets, up to a rate equal to the difference between the maximum PHB capacity and the "severe congestion threshold", when the incoming "encoded DSCP" marked packets are already able to signal this difference. In this case, the "severe congestion threshold" SHOULD be configured in all Interior nodes, which are located in the RMD domain, and equal to:
PHBあたり「重度輻輳検出」閾値が1つのPHBに割り当てられた最大容量に等しく設定されていない場合、これは、重度の輻輳状態が解消された後に、継続的なフローは合計それらの関連パケットを送信できないことを意味しますPHBに関連する最大容量に等しいが、唯一「severe_congestion_threshold」までの速度。同じ通信経路上にある複数の内部ノードがひどく混雑していると、これらの内部ノードの一つが「encoded_DSCP」と記されたパケットを受信したときに、このインテリアノードはすなわち、マークされていないマークし、いずれかの「元のDSCP」または「影響を受けたDSCP」またはNOT必要があるとき「通知されたDSCPが」パケットマーク着信「符号化されたDSCP」はすでにこの差をシグナリングすることができる最大PHB容量および「重度の輻輳閾値」との間の差に等しい速度まで、パケットを符号化されました。この場合、「重度輻輳閾値が」RMD領域に配置されているすべての内部ノードに設定する必要があり、そして等しいです。
"severe_congestion_threshold" = Maximum PHB capacity - threshold_offset_rate
"severe_congestion_threshold" =最大PHB容量 - threshold_offset_rate
The threshold_offset_rate represents rate and SHOULD have the same value in all Interior nodes.
threshold_offset_rateはレートを表し、すべての内部ノードで同じ値を持つべきです。
* before queuing and eventually dropping the packets, at the end of each measurement interval of T seconds, calculate the current estimated overloaded rate, say measured_overload_rate, by using the following equation:
*キューイングし、最終的に現在の推定オーバーロードされたレートを計算、T秒の各測定間隔の終わりに、パケットをドロップする前に、measured_overload_rate、次の式を使用して言います：
measured_overload_rate = =((total_received_bytes)/T)-severe_congestion_restoration)
measured_overload_rate = =（（total_received_bytes）/ T）-severe_congestion_restoration）
To provide a reliable estimation of the encoded information, several techniques can be used; see [AtLi01], [AdCa03], [ThCo04], and [AnHa06]. Note that since marking is done in Interior nodes, the decisions are made at Egress nodes, and the termination of flows is performed by Ingress nodes, there is a significant delay until the overload information is learned by the Ingress nodes (see Section 6 of [CsTa05]). The delay consists of the trip time of data packets from the severely congested Interior node to the Egress, the measurement interval, i.e., T, and the trip time of the notification signaling messages from Egress to Ingress. Moreover, until the overload decreases at the severely congested Interior node, an additional trip time from the Ingress node to the severely congested Interior node MUST expire. This is because immediately before receiving the congestion notification, the Ingress MAY have sent out packets in the flows that were selected for termination. That is, a terminated flow MAY contribute to congestion for a time longer that is taken from the Ingress to the Interior node. Without considering the above, Interior nodes would continue marking the packets until the measured utilization falls below the severe congestion restoration threshold. In this way, in the end, more flows will be terminated than necessary, i.e., an overreaction takes place. [CsTa05] provides a solution to this problem, where the Interior nodes use a sliding window memory to keep track of the signaling overload in a couple of previous measurement intervals. At the end of a measurement interval, T, before encoding and signaling the overloaded rate as "encoded DSCP" packets, the actual overload is decreased with the sum of already signaled overload stored in the sliding window memory, since that overload is already being handled in the severe congestion handling control loop. The sliding window memory consists of an integer number of cells, i.e., n = maximum number of cells. Guidelines for configuring the sliding window parameters are given in [CsTa05].
符号化された情報の信頼性の推定を提供するために、いくつかの技術を使用することができます。 [AnHa06] [AtLi01]参照、[AdCa03]、[ThCo04]、および。マーキングが内部ノードで行われるので、決定が出口ノードで行われ、そしてフローの終了が進入ノードによって実行される過負荷情報が進入ノードにより学習されるまで、かなりの遅延があることに注意してください（セクション6を参照してください[ CsTa05]）。遅延は、出力に深刻な輻輳インテリアノード、測定間隔、すなわち、T、および入力に出口からシグナリングメッセージ通知のトリップ時間からのデータパケットの往復時間から成ります。過負荷がひどく輻輳内部ノードに低下するまでさらに、深刻な輻輳内部ノードにIngressノードから追加の旅行時間が期限切れしなければなりません。すぐに輻輳通知を受信する前に、進入が終了するために選択したフローのパケットを送信した可能性があるためです。つまり、終了フローはインテリアノードへの進入から取られている長い時間のために渋滞に寄与することができます。上記を考慮せずに、インテリア・ノードは、測定された利用が深刻な輻輳復旧閾値を下回るまでパケットをマーキング続けるだろう。このように、最終的には、複数のフローが必要以上に終了する、すなわち、過剰反応が起こります。 【CsTa05】内部ノードは、前の測定間隔のカップルでシグナリング過負荷を追跡するためにスライディングウィンドウメモリを使用し、この問題に対する解決策を提供します。測定間隔の終了時に、Tは、符号化と「符号化されたDSCP」パケットとして過負荷率をシグナリングする前に、実際の過負荷は、その過負荷が既に処理されているので、既に、スライディングウィンドウメモリに格納された過負荷シグナリングの和と減少します深刻な輻輳処理制御ループインチスライディングウィンドウメモリセル、すなわちの整数で構成され、N =セルの最大数。スライディングウィンドウパラメータを設定するためのガイドラインは、[CsTa05]に記載されています。
At the end of each measurement interval, the newest calculated overload is pushed into the memory, and the oldest cell is dropped.
各測定間隔の終わりに、最新の計算された過負荷がメモリ内に押し込まれ、最も古いセルがドロップされます。
If Mi is the overload_rate stored in ith memory cell (i = [1..n]), then at the end of every measurement interval, the overload rate that is signaled to the Egress node, i.e., signaled_overload_rate is calculated as follows:
Miはi番目のメモリセルに記憶されoverload_rateある（I = [1..nの]）場合は、次のようにすべての測定間隔、Egressノードに通知され、過負荷率の端部に、すなわち、signaled_overload_rateが計算されます。
Sum_Mi =0 For i =1 to n { Sum_Mi = Sum_Mi + Mi }
Sum_Mi = 0 i = 1からn {Sum_Mi = Sum_Mi +ミ}
signaled_overload_rate = measured_overload_rate - Sum_Mi,
signaled_overload_rate = measured_overload_rate - Sum_Mi、
where Sum_Mi is calculated as above.
Sum_Miは、上記のように計算されます。
Next, the sliding memory is updated as follows: for i = 1..(n-1): Mi <- Mi+1 Mn <- signaled_overload_rate
ミ+ 1のMn < - - signaled_overload_rateミ<I = 1 ...（N-1）の場合：次に、スライドメモリは次のように更新されます
The bytes that have to be re-marked to satisfy the signaled overload rate: signaled_remarked_bytes, are calculated using the following pseudocode:
合図過負荷率を満たすために再マークする必要がバイト：signaled_remarked_bytesは、以下の擬似コードを使用して計算されます。
IF severe_congestion_threshold <> Maximum PHB capacity THEN { IF (incoming_encoded-DSCP_rate <> 0) AND (incoming_encoded-DSCP_rate =< termination_offset_rate) THEN { signaled_remarked_bytes = = ((signaled_overload_rate - incoming_encoded-DSCP_rate)*T)/N } ELSE IF (incoming_encoded-DSCP_rate > termination_offset_rate) THEN signaled_remarked_bytes = = ((signaled_overload_rate - termination_offset_rate)*T)/N ELSE IF (incoming_encoded-DSCP_rate =0) THEN signaled_remarked_bytes = = signaled_overload_rate*T/N } ELSE signaled_remarked_bytes = signaled_overload_rate *T/N
THEN <>最大PHB容量をsevere_congestion_threshold IF {（incoming_encoded-DSCP_rate <> 0）AND（incoming_encoded-DSCP_rate = <termination_offset_rate）THEN {signaled_remarked_bytes = =（（signaled_overload_rate - incoming_encoded-DSCP_rate）* T）IF / Nは} ELSE IF（incoming_encoded -DSCP_rate> termination_offset_rate）THEN signaled_remarked_bytes = =（（signaled_overload_rate - termination_offset_rate）* T）/ N ELSE IF（incoming_encoded-DSCP_rate = 0）THEN signaled_remarked_bytes = = signaled_overload_rate * T / N} ELSE signaled_remarked_bytes = signaled_overload_rate * T / N
Where the incoming "encoded DSCP" rate is calculated as follows:
次のようにどこに入ってくる「エンコードされたDSCP」率が計算されます。
incoming_encoded-DSCP_rate = = (received number of "encoded_DSCP" during T) * N)/T;
incoming_encoded-DSCP_rate = =（T中 "encoded_DSCP" の受信数）* N）/ T。
The signal_remarked_bytes also represents the number of the outgoing packets (after the dropping stage) that MUST be re-marked, during each measurement interval T, by a node when operates in severe congestion mode.
signal_remarked_bytesはまた、重度輻輳モードで動作するノードによって、各測定間隔Tの間に、再マークする必要があり（滴下段階後に）送信パケットの数を表します。
Note that, in order to process an overload situation higher than 100% of the maintained severe congestion threshold, all the nodes within the domain MUST be configured and maintain a scaling parameter, e.g., N used in the above equation, which in combination with the marked bytes, e.g., signaled_remarked_bytes, such a high overload situation can be calculated and represented. N can be equal to or higher than 1.
維持重度輻輳閾値の100％よりも高い過負荷状況を処理するために、ドメイン内のすべてのノードが構成され、スケーリングパラメータを維持しなければならない、ということに注意してください、上記の式で使用される、例えば、N、どの組み合わせで用いてマークされたバイトは、例えば、signaled_remarked_bytes、このような高い過負荷状態を計算して表現することができます。 Nに等しいか1よりも高くすることができます。
Note that when incoming re-marked bytes are dropped, the operation of the severe congestion algorithm MAY be affected, e.g., the algorithm MAY become, in certain situations, slower. An implementation of the algorithm MAY assure as much as possible that the incoming marked bytes are not dropped. This could for example be accomplished by using different dropping rate thresholds for marked and unmarked bytes.
着信再マークされたバイトが破棄されたときに、重度輻輳アルゴリズムの動作が影響を受ける可能性があること、例えば、アルゴリズムが遅く、特定の状況では、となることがあります。アルゴリズムの実装は、着信マークされたバイトが廃棄されていないことを可能な限り確保するかもしれません。これは、例えばマークとマークされていないバイトのための別の廃棄率のしきい値を使用することによって達成することができます。
Note that when the "affected DSCP" marking is used by a node that is congested due to a severe congestion situation, then all the outgoing packets that are not marked (i.e., by using the "encoded DSCP") have to be re-marked using the "affected DSCP" marking.
「影響を受けたDSCPが」厳しい混雑状況に混雑しているノードによって使用されているマーキングとき、そして（すなわち、「エンコードされたDSCP」を用いて）マークされていないすべての送信パケットが再マークする必要があることに注意してください「影響を受けたDSCP」マーキングを使用しました。
The "encoded DSCP" and the "affected DSCP" marked packets (when applied in the whole RMD domain) are propagated to the QNE Edge nodes.
QNEエッジノードに伝播されている（全体RMDドメインに適用された場合）、「エンコードされたDSCP」と「影響を受けたDSCPは、」パケットをマーク。
Furthermore, note that when the congestion notification based on probing is used in combination with severe congestion, then in addition to the possible "encoded DSCP" and "affected DSCP", another DSCP for the re-marking of the same PHB is used (see Section 4.6.1.7). This additional DSCP is denoted in this document as "notified DSCP". When an Interior node operates in the severe congested state (see Figure 27), and receives "notified DSCP" packets, these packets are considered to be unmarked packets (but not "affected DSCP" packets). This means that during severe congestion, also the "notified DSCP" packets can be re-marked and encoded as either "encoded DSCP" or "affected DSCP" packets.
また、プローブに基づく輻輳通知は、同じPHBの再マーキングのための別のDSCPを使用することが可能「符号化されたDSCP」および「影響を受けたDSCP」に加えて、重度の輻輳と組み合わせて使用されるときことに注意（参照セクション4.6.1.7）。この追加のDSCPは、「DSCPを通知」として、この文書で示されています。内部ノードが厳しい輻輳状態で動作する場合（図27参照）、及びパケット「DSCPを通知」を受信し、これらのパケットがマークされていないパケット（ただし、「影響を受けたDSCP」パケット）であると考えられます。これは深刻な輻輳時に、また、「DSCPを通知された」パケットが再マークされ、「エンコードされたDSCP」または「影響を受けたDSCP」のパケットのいずれかとしてエンコードすることができることを意味します。
A.2. Example of a Detailed Severe Congestion Operation in the Egress Nodes
A.2。出口ノードに詳述重度輻輳動作例
This appendix describes an example of a detailed severe congestion operation in the Egress nodes.
この付録では、出口ノードにおける詳細な深刻な輻輳の動作の一例を説明します。
The states of operation in Egress nodes are similar to the ones described in Appendix A.1. The definition of the events, see below, is however different than the definition of the events given in Figures 26 and 27:
出口ノードにおける動作状態は、付録A.1に記載のものと同様です。イベントの定義は、以下を参照、図26および図27に示すイベントの定義よりしかし異なります。
* event A: when the Egress receives a predefined rate of "notified DSCP" marked bytes/packets, event A is activated (see Sections 4.6.1.7 and A.4). The predefined rate of "notified DSCP" marked bytes is denoted as the congestion notification detection threshold. Note this congestion notification detection threshold can also be zero, meaning that the event A is activated when the Egress node, during an interval T, receives at least one "notified DSCP" packet.
*イベントA：退出バイト/パケットにマーク「通知DSCP」の事前に定義されたレートを受信した場合、イベントAが活性化される（セクション4.6.1.7およびA.4を参照のこと）。 「通知DSCP」とマークされたバイトの事前に定義されたレートは、輻輳通知検出閾値と表記されます。この輻輳通知検出閾値はまた、Egressノードは、時間間隔Tの間に、少なくとも1つの「通知されたDSCP」パケットを受信すると、イベントは、Aが活性化されることを意味し、ゼロであることに注意。
* event B: this event occurs when the Egress receives packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain).
*イベントB：出口が「符号化DSCP」または（「影響を受けたDSCPが」全体RMDドメインに適用される）、「影響を受けたDSCP」のいずれかとしてマークされたパケットを受信した場合、このイベントが発生します。
* event C: this event occurs when the rate of incoming "notified DSCP" packets decreases below the congestion notification detection threshold. In the situation that the congestion notification detection threshold is zero, this will mean that event C is activated when the Egress node, during an interval T, does not receive any "notified DSCP" marked packets.
*イベントC：着信「通知されたDSCP」パケットのレートは、輻輳通知検出閾値以下に低下すると、このイベントが発生します。輻輳通知検出閾値がゼロである状況では、この間隔Tの間Egressノードは、任意の「通知されたDSCP」とマークされたパケットを受信しない場合、そのイベントCが活性化された意味します。
* event D: this event occurs when the Egress, during an interval T, does not receive packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain). Note that when "notified DSCP" is applied in the whole RMD domain for the support of congestion notification, this event could cause the following change in operation state.
*イベントD：出口は、時間間隔Tの間に、「符号化されたDSCP」または（「影響を受けたDSCPが」全体RMDドメインに適用される）、「影響を受けたDSCP」のいずれかとしてマークされたパケットを受信しない場合、このイベントが発生します。 「通知DSCPが」輻輳通知のサポートのために全体のRMDドメインに適用される場合、このイベントは、動作状態を次のように変更を引き起こす可能性があることに注意してください。
When the Egress, during an interval T, does not receive (1) packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain) and (2) it does NOT receive "notified DSCP" marked packets, the change in the operation state occurs from the severe congestion state to normal state.
出口は、時間間隔Tの間、受信していない場合（1）パケットは、いずれかの「符号化されたDSCP」または「罹患DSCP」（「影響を受けたDSCPが」全体RMDドメインに適用される場合）、（2）それが受信していないとしてマーク「DSCPを通知された」パケットをマークし、運転状態の変化は、通常の状態に深刻な輻輳状態から発生します。
When the Egress, during an interval T, does not receive (1) packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain) and (2) it does receive "notified DSCP" marked packets, the change in the operation state occurs from the severe congestion state to the congestion notification state.
出口は、時間間隔Tの間に、「（「影響を受けたDSCPが」全体RMD領域に印加された場合）（1）パケットが「符号化されたDSCP」または「罹患DSCP」のいずれかとしてマークされ、（2）それが受信しないを受信しない場合パケットをマークし、」DSCPを通知し、運転状態の変化は、輻輳通知状態に深刻な輻輳状態から発生します。
* event E: this event occurs when the Egress, during an interval T, does not receive packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain).
*イベントE：このイベントが出力は、時間間隔Tの間に、「符号化されたDSCP」または（「影響を受けたDSCPが」全体RMDドメインに適用される）、「影響を受けたDSCP」のいずれかとしてマークされたパケットを受信しない場合に発生します。
An example of the algorithm for calculation of the number of flows associated with each priority class that have to be terminated is explained by the pseudocode below.
終了しなければならないそれぞれの優先度クラスに関連付けられたフローの数を計算するためのアルゴリズムの一例は、以下の擬似コードによって説明されます。
The Edge nodes are able to support severe congestion handling by: (1) identifying which flows were affected by the severe congestion and (2) selecting and terminating some of these flows such that the quality of service of the remaining flows is recovered.
（1）重度の輻輳の影響を受け、（2）残りのフローのサービスの品質が回復されるようにこれらのフローの一部を選択して終了した流れる識別する：エッジノードは、によって重度の輻輳処理をサポートすることができます。
The "encoded DSCP" and the "affected DSCP" marked packets (when applied in the whole RMD domain) are received by the QNE Edge node.
（全体RMD領域に適用される場合）、「符号化されたDSCP」および「影響を受けたDSCP」はパケットをマークQNEエッジノードによって受信されます。
The QNE Edge nodes keep per-flow state and therefore they can translate the calculated bandwidth to be terminated, to number of flows. The QNE Egress node records the excess rate and the identity of all the flows, arriving at the QNE Egress node, with "encoded DSCP" and with "affected DSCP" (when applied in the whole RMD domain); only these flows, which are the ones passing through the severely congested Interior node(s), are candidates for termination. The excess rate is calculated by measuring the rate of all the "encoded DSCP" data packets that arrive at the QNE Egress node. The measured excess rate is converted by the Egress node, by multiplying it by the factor N, which was used by the QNE Interior node(s) to encode the overload level.
QNEエッジノードは、フローごとの状態を保つため、彼らはフロー数に、終了する計算された帯域幅を翻訳することができます。 QNE出口ノード「は、符号化されたDSCP」とし、「影響を受けたDSCP」（全体RMD領域に適用される場合）と過剰率とQNE出口ノードに到着するすべてのフローの識別情報を、記録します。ひどく輻輳インテリアノード（複数可）を通過したもののみこれらのフローは、終了のための候補です。過剰率は、QNE出口ノードに到達する全ての「符号化されたDSCP」データパケットのレートを測定することにより算出されます。測定された過剰率は、過負荷レベルを符号化するためにQNEインテリアノード（単数または複数）によって使用された因数N、を乗じて、Egressノードによって変換されます。
When different priority flows are supported, all the low priority flows that arrived at the Egress node are terminated first. Next, all the medium priority flows are stopped and finally, if necessary, even high priority flows are chosen. Within a priority class both "encoded DSCP" and "affected DSCP" are considered before the mechanism moves to higher priority class. Finally, for each flow that has to be terminated the Egress node, sends a NOTIFY message to the Ingress node, which stops the flow.
異なる優先フローがサポートされている場合は、Egressノードに到着したすべての優先度の低いフローが最初に終了します。次に、すべての媒体優先フローが停止され、最終的に、必要であれば、さらに高い優先度のフローが選択されます。機構は、優先度の高いクラスに移動する前に、優先クラスの両方「符号化DSCP」および「影響を受けたDSCP」内にあると考えられます。最後に、Egressノードを終了しなければならない各フローに対して、フローを停止IngressノードにNOTIFYメッセージを送信します。
Below, this algorithm is described in detail.
以下は、このアルゴリズムを詳細に説明します。
First, when the Egress operates in the severe congestion state, the total amount of re-marked bandwidth associated with the PHB traffic class, say total_congested_bandwidth, is calculated. Note that when the node maintains information about each Ingress/Egress pair aggregate, then the total_congested_bandwidth MUST be calculated per Ingress/Egress pair reservation aggregate. This bandwidth represents the severely congested bandwidth that SHOULD be terminated. The total_congested_bandwidth can be calculated as follows:
まず、出口が厳しい輻輳状態、PHBのトラフィッククラスに関連付けられている再マークされた帯域幅の合計で動作する場合、total_congested_bandwidthが、計算されると言います。ノードは、各入口/出口の対の集合体に関する情報を保持するとき、その後total_congested_bandwidthは、入口/出口対予約集合ごとに計算しなければならないことに留意されたいです。この帯域幅は終了されるべき深刻な混雑帯域幅を表します。次のようにtotal_congested_bandwidthを計算することができます。
total_congested_bandwidth = N*input_remarked_bytes/T
total_congested_bandwidth = N * input_remarked_bytes / T
Where, input_remarked_bytes represents the number of "encoded DSCP" marked bytes that arrive at the Egress, during one measurement interval T, N is defined as in Sections 4.6.1.6.2.1 and A.1. The term denoted as terminated_bandwidth is a temporal variable representing the total bandwidth that has to be terminated, belonging to the same PHB traffic class. The terminate_flow_bandwidth (priority_class) is the total bandwidth associated with flows of priority class equal to priority_class. The parameter priority_class is an integer fulfilling:
input_remarked_bytesが出力に到達「符号化されたDSCP」とマークされたバイトの数を表し、1つの測定間隔Tの間に、Nは、4.6.1.6.2.1及びA.1セクションであると定義されます。 terminated_bandwidthとして示す用語は、同じPHBのトラフィッククラスに属する、終了する必要があり、総帯域幅を表す一時的な変数です。 terminate_flow_bandwidth（priority_class）はpriority_classに等しい優先度クラスのフローに関連付けられた総帯域幅です。パラメータpriority_classは満たす整数です。
0 =< priority_class =< Maximum_priority.
0 = <priority_class = <Maximum_priority。
The QNE Egress node records the identity of the QNE Ingress node that forwarded each flow, the total_congested_bandwidth and the identity of all the flows, arriving at the QNE Egress node, with "encoded DSCP" and "affected DSCP" (when applied in whole RMD domain). This ensures that only these flows, which are the ones passing through the severely overloaded QNE Interior node(s), are candidates for termination. The selection of the flows to be terminated is described in the pseudocode that is given below, which is realized by the function denoted below as calculate_terminate_flows().
全体RMDに適用した場合QNE出口ノードは、（「符号化されたDSCP」および「影響を受けたDSCP」と、QNE出口ノードに到達し、各フローを転送QNE Ingressノード、total_congested_bandwidthおよびすべてのフローのアイデンティティの識別情報を記録しますドメイン）。これは深刻な過負荷QNEインテリアノード（複数可）を通過するもので、これらのフローは、終了のための候補であることを保証します。フローの選択はcalculate_terminate_flowsとして以下に示される関数（）によって実現される以下に示す擬似コードに記載されて終了します。
The calculate_terminate_flows() function uses the <terminate_bandwidth_class> value and translates this bandwidth value to number of flows that have to be terminated. Only the "encoded DSCP" flows and "affected DSCP" (when applied in whole RMD domain) flows, which are the ones passing through the severely overloaded Interior node(s), are candidates for termination.
calculate_terminate_flows（）関数は、<terminate_bandwidth_class>値を使用し、終了しなければならないフローの数にこの帯域幅値を変換します。 「符号化されたDSCP」流れ、ひどく過負荷インテリアノード（複数可）を通過するものであり、「影響を受けたDSCP」（全体RMD領域に適用される場合）が流れるだけでは、終了のための候補です。
After the flows to be terminated are selected, the <sum_bandwidth_terminate(priority_class)> value is calculated that is the sum of the bandwidth associated with the flows, belonging to a certain priority class, which will certainly be terminated.
終了すべきフローが選択された後、<sum_bandwidth_terminate（priority_class）>値は、それが確実に終了する特定の優先度クラスに属する、フローに関連する帯域幅の和で算出されます。
The constraint of finding the total number of flows that have to be terminated is that sum_bandwidth_terminate(priority_class), SHOULD be smaller or approximately equal to the variable terminate_bandwidth(priority_class).
終了しなければならないフローの総数を求めるの制約はsum_bandwidth_terminate（priority_class）は、より小さな又は可変terminate_bandwidth（priority_class）にほぼ等しくなければならないということです。
terminated_bandwidth = 0;
priority_class = 0;
while terminated_bandwidth < total_congested_bandwidth
{
terminate_bandwidth(priority_class) =
= total_congested_bandwidth - terminated_bandwidth
calculate_terminate_flows(priority_class);
terminated_bandwidth =
= sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
priority_class = priority_class + 1;
}
If the Egress node maintains Ingress/Egress pair reservation aggregates, then the above algorithm is performed for each Ingress/Egress pair reservation aggregate.
Egressノードは、入口/出口対予約凝集を維持する場合、上記のアルゴリズムは、それぞれの入口/出口の対の予約集合に対して行われます。
Finally, for each flow that has to be terminated, the QNE Egress node sends a NOTIFY message to the QNE Ingress node to terminate the flow.
最後に、終了する必要があり、各フローに対して、QNE出口ノードは、フローを終了するQNE IngressノードにNOTIFYメッセージを送信します。
A.3. Example of a Detailed Re-Marking Admission Control (Congestion Notification) Operation in Interior Nodes
A.3。内部ノードに詳述再マーキングアドミッション制御（輻輳通知）動作例
This appendix describes an example of a detailed re-marking admission control (congestion notification) operation in Interior nodes. The predefined congestion notification threshold, see Appendix A.1, is set according to, and usually less than, an engineered bandwidth limitation, i.e., admission threshold, e.g., based on a Service Level Agreement or a capacity limitation of specific links.
この付録では、内部ノードにおける詳細な再マーキングアドミッション制御（輻輳通知）の動作例を説明します。事前定義された輻輳通知閾値は、付録A.1を参照して、に応じて設定され、通常より少ない操作帯域幅制限、以下、すなわち、受付閾値、例えば、サービスレベル契約または特定のリンクの容量制限に基づきます。
The difference between the congestion notification threshold and the engineered bandwidth limitation, i.e., admission threshold, provides an interval where the signaling information on resource limitation is already sent by a node but the actual resource limitation is not reached. This is due to the fact that data packets associated with an admitted session have not yet arrived, which allows the admission control process available at the Egress to interpret the signaling information and reject new calls before reaching congestion.
輻輳通知閾値と操作帯域制限との間の差、すなわち、入場しきい値は、リソース制限に関するシグナリング情報は既にノードによって送信される実際のリソース制限に達していない間隔を提供します。これは、出口で利用できるアドミッション制御プロセスは、シグナリング情報を解釈し、渋滞に到達する前に新しいコールを拒否することができます認めたセッションに関連付けられたデータパケットがまだ到着していないという事実にあります。
Note that in the situation when the data rate is higher than the preconfigured congestion notification rate, data packets are also re-marked (see Section 4.6.1.6.2.1). To distinguish between congestion notification and severe congestion, two methods MAY be used (see Appendix A.1):
（セクション4.6.1.6.2.1を参照）データレートが事前設定された輻輳通知レートよりも高い場合の状況では、データパケットはまた、再マークされていることに注意してください。輻輳通知と深刻な渋滞を区別するために、2つの方法は、（付録A.1を参照）を使用することができます。
* using different <DSCP> values (re-marked <DSCP> values). The re-marked DSCP that is used for this purpose is denoted as "notified DSCP" in this document. When this method is used and when the Interior node is in "congestion notification" state, see Appendix
*異なる<DSCP>の値（再マーク<DSCP>値）を使用。このドキュメントの「DSCPを通知」として、この目的のために使用される再マークDSCPが示されています。この方法を用いると内部ノードが「輻輳通知」状態にあるとき、付録を参照された場合
A.1, then the node SHOULD re-mark all the unmarked bytes passing through the node using the "notified DSCP". Note that this method can only be applied if all nodes in the RMD domain use the "notified" DSCP marking. In this way, probe packets that will pass through the Interior node that operates in congestion notification state are also encoded using the "notified DSCP" marking.
A.1、そのノードべきで再マーク「を通知DSCP」を使用してノードを通過する全てのマークされていないバイト。 RMDドメイン内のすべてのノードがマーキング「通知」DSCPを使用する場合は、この方法しか適用することができます。このように、輻輳通知状態で動作する内部ノードを通過するプローブパケットはまた、マーキング「通知DSCP」を使用して符号化されます。
* Using the "encoded DSCP" marking for congestion notification and severe congestion. This method is not described in detail in this example appendix.
*輻輳通知と激しい混雑のためにマーキング「エンコードされたDSCP」を使用。この方法は、この例の付録で詳しく説明されていません。
A.4. Example of a Detailed Admission Control (Congestion Notification) Operation in Egress Nodes
A.4。出口ノードに詳述アドミッション制御（輻輳通知）動作例
This appendix describes an example of a detailed admission control (congestion notification) operation in Egress nodes.
この付録では、出口ノードにおける詳細なアドミッション制御（輻輳通知）の動作例を説明します。
The admission control congestion notification procedure can be applied only if the Egress maintains the Ingress/Egress pair aggregate. When the operation state of the Ingress/Egress pair aggregate is the "congestion notification", see Appendix A.2, then the implementation of the algorithm depends on how the congestion notification situation is notified to the Egress. As mentioned in Appendix A.3, two methods are used:
アドミッション制御、輻輳通知手順は、出口が入口/出口の対の集合体を維持している場合にのみ適用することができます。入力/出力ペア集合体の動作状態が「輻輳通知」である場合には、付録A.2は、アルゴリズムの実装が輻輳通知状況が出口に通知される方法によって異なりご覧ください。付録A.3で述べたように、二つの方法が使用されます。
* using the "notified DSCP". During a measurement interval T, the Egress counts the number of "notified DSCP" marked bytes that belong to the same PHB and are associated with the same Ingress/Egress pair aggregate, say input_notified_bytes. We denote the rate as incoming_notified_rate.
*「通知DSCP」を使用。測定間隔Tの間に、出口は「通知DSCP」と同じPHBに属し、同じ入力/出力ペアの集約に関連付けられているマークされたバイト数をカウントし、input_notified_bytesは言います。私たちは、incoming_notified_rateとして割合を示します。
* using the "encoded DSCP". In this case, during a measurement interval T, the Egress measures the input_notified_bytes by counting the "encoded DSCP" bytes.
*「エンコードされたDSCP」を使用。この場合、測定間隔Tの間に、出口は、「符号化されたDSCP」バイトをカウントすることによってinput_notified_bytesを測定します。
Below only the detail description of the first method is given.
第1の方法のみ詳細な説明を以下に示します。
The incoming congestion_rate can be then calculated as follows:
次のように着信congestion_rateを計算することができます。
incoming_congestion_rate = input_notified_bytes/T
incoming_congestion_rate = input_notified_bytes / T
If the incoming_congestion_rate is higher than a preconfigured congestion notification threshold, then the communication path between Ingress and Egress is considered to be congested. Note that the pre-congestion notification threshold can be set to "0". In this case, the Egress node will operate in congestion notification state at the moment that it receives at least one "notified DSCP" encoded packet.
incoming_congestion_rateが事前設定された輻輳通知閾値よりも大きい場合には、入力および出力の間の通信経路が輻輳していると考えられます。前の輻輳通知のしきい値が「0」に設定することができることに注意してください。この場合、出口ノードは、パケット符号化された少なくとも1つの「通知されたDSCP」を受信した時点で、輻輳通知状態で動作します。
When the Egress node operates in "congestion notification" state and if the end-to-end RESERVE (probe) arrives at the Egress, then this request SHOULD be rejected. Note that this happens only when the probe packet is either "notified DSCP" or "encoded DSCP" marked. In this way, it is ensured that the end-to-end RESERVE (probe) packet passed through the node that is congested. This feature is very useful when ECMP-based routing is used to detect only flows that are passing through the congested router.
Egressノードが「輻輳通知」状態で動作したときに、エンドツーエンドRESERVE（プローブ）は出口に到達する場合、この要求は拒否されるべきです。プローブパケットはどちらかである「通知DSCP」または「エンコードされたDSCP」とマークされた場合にのみ、この問題が発生したことに注意してください。このようにして、エンド・ツー・エンドのRESERVE（プローブ）パケットが輻輳しているノードを通過したことが保証されます。 ECMPベースのルーティングは、輻輳ルータを通過しているだけの流れを検出するために使用される場合、この機能は非常に有用です。
If such an Ingress/Egress pair aggregated state is not available when the (probe) RESERVE message arrives at the Egress, then this request is accepted if the DSCP of the packet carrying the RESERVE message is unmarked. Otherwise (if the packet is either "notified DSCP" or "encoded DSCP" marked), it is rejected.
このような入口/出口の対凝集状態が利用できない場合（プローブ）RESERVEメッセージが出口に到達したときにRESERVEメッセージを運ぶパケットのDSCPがマークされていない場合、この要求は受け入れられます。 （パケットがどちらかである「DSCPの通知」または「エンコードされたDSCPが」マークされている場合）それ以外の場合は拒否されます。
A.5. Example of Selecting Bidirectional Flows for Termination during Severe Congestion
A.5。重度の輻輳時に終了の双方向フローを選択する例
This appendix describes an example of selecting bidirectional flows for termination during severe congestion.
この付録では、深刻な輻輳時終了のための双方向のフローを選択する例を説明します。
When a severe congestion occurs, e.g., in the forward path, and when the algorithm terminates flows to solve the severe congestion in the forward path, then the reserved bandwidth associated with the terminated bidirectional flows is also released. Therefore, a careful selection of the flows that have to be terminated SHOULD take place. A possible method of selecting the flows belonging to the same priority type passing through the severe congestion point on a unidirectional path can be the following:
重度の輻輳が発生した場合、例えば、フォワードパスで、アルゴリズムは、フォワードパスにおける重度の輻輳を解決するためのフローを終了したとき、次に終了双方向フローに関連する予約帯域も解除されます。そのため、終了する必要がフローの慎重な選択が行われるべきです。単方向経路上に重度の輻輳点を通る同じ優先度タイプに属するフローの選択可能な方法は次のようにすることができます。
* the Egress node SHOULD select, if possible, first unidirectional flows instead of bidirectional flows.
* Egressノードは、可能な場合、最初の単方向フローの代わりに双方向の流れを選択すべきです。
* the Egress node SHOULD select, if possible, bidirectional flows that reserved a relatively small amount of resources on the path reversed to the path of congestion.
* Egressノードは、輻輳の経路と逆の経路上のリソースの比較的少量を予約可能、双方向流れた場合、選択すべきです。
A.6. Example of a Severe Congestion Solution for Bidirectional Flows Congested Simultaneously on Forward and Reverse Paths
A.6。双方向のための重度の輻輳ソリューションの例は、順方向および逆方向のパス上で同時に混雑をフロー
This appendix describes an example of a severe congestion solution for bidirectional flows congested simultaneously on forward and reverse paths.
この付録では、前方に同時に上の混雑や経路を逆双方向フローの厳しい輻輳溶液の例について説明します。
This scenario describes a solution using the combination of the severe congestion solutions described in Section 4.6.2.5.2. It is considered that the severe congestion occurs simultaneously in forward and reverse directions, which MAY affect the same bidirectional flows.
このシナリオは、セクション4.6.2.5.2で説明深刻な渋滞ソリューションの組み合わせを使用して解決策を説明しています。ひどい渋滞が前方に同時に発生し、同じ双方向のフローに影響を与える可能性がある、方向を逆転させることが考えられます。
When the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, the steps can be the following, see Figure A.3. Consider that the Egress node selects a number of bidirectional flows to be terminated. In this case, the Egress will send, for each bidirectional flow, a NOTIFY message to Ingress. If the Ingress receives these NOTIFY messages and its operational state (associated with reverse path) is in the severe congestion state (see Figures 26 and 27), then the Ingress operates in the following way:
QNEは、フローごとのドメイン内のQoS-NSLP動作状態を維持するエッジすると、手順は、図A.3を参照して、以下のことができます。 Egressノードを終了する双方向フローの数を選択することを考えます。この場合、出口は、入口に、それぞれ双方向フローのために、NOTIFYメッセージを送信します。イングレスは、これらのメッセージと（逆経路に関連付けられている）は、その動作状態をNOTIFY受信重度の輻輳状態である場合（図26及び27参照）、次いで、イングレスは、次のように動作します。
* For each NOTIFY message, the Ingress SHOULD identify the bidirectional flows that have to be terminated.
*各NOTIFYメッセージについて、侵入が終了しなければならない双方向の流れを識別すべきです。
* The Ingress then calculates the total bandwidth that SHOULD be released in the reverse direction (thus not in forward direction) if the bidirectional flows will be terminated (preempted), say "notify_reverse_bandwidth". This bandwidth can be calculated by the sum of the bandwidth values associated with all the end-to-end sessions that received a (severe congestion) NOTIFY message.
*イングレスは、（順方向にないため）逆方向に解放する必要があり、総帯域幅双方向のフローが終了される場合（先取り）、「notify_reverse_bandwidthを」と言うが計算されます。この帯域幅は、（重度の輻輳）NOTIFYメッセージを受信したすべてのエンドツーエンドセッションに関連付けられた帯域幅の値の和によって計算することができます。
* Furthermore, using the received marked packets (from the reverse path) the Ingress will calculate, using the algorithm used by an Egress and described in Appendix A.2, the total bandwidth that has to be terminated in order to solve the congestion in the reverse path direction, say "marked_reverse_bandwidth".
*また、（逆方向パスから）受信マーキングされたパケットを使用して、イングレスは、出力によって使用されるアルゴリズムを使用して、計算および付録A.2、の輻輳を解決するために終了しなければならない全帯域幅に記載されますパスの方向を逆に、「marked_reverse_bandwidth」と言います。
* The Ingress then calculates the bandwidth of the additional flows that have to be terminated, say "additional_reverse_bandwidth", in order to solve the severe congestion in reverse direction, by taking into account:
*イングレスは、考慮に入れることによって、逆方向への深刻な渋滞を解決するために、「additional_reverse_bandwidth」と言う、終了する必要があり、追加のフローの帯域幅を計算します。
** the bandwidth in the reverse direction of the bidirectional flows that were appointed by the Egress (the ones that received a NOTIFY message) to be preempted, i.e., "notify_reverse_bandwidth".
**出口（NOTIFYメッセージを受信したもの）によって任命された双方向フローの逆方向の帯域幅は、すなわち、「notify_reverse_bandwidth」横取りされます。
** the total amount of bandwidth in the reverse direction that has been calculated by using the received marked packets, i.e., "marked_reverse_bandwidth".
**受信マーキングされたパケット、すなわち、「marked_reverse_bandwidth」を用いて算出された逆方向の帯域幅の合計量。
QNE(Ingress) NE (int.) NE (int.) NE (int.) QNE(Egress)
NTLP stateful NTLP stateful
data| user | | | |
--->| data | #unmarked bytes| | |
|--------------->S #marked bytes | | |
| S--------------------------->| |
| | | |-------------->|data
| | | | |--->
| | | | Term.?
| NOTIFY | | |Yes
|<------------------------------------------------------------|
| | | | |data
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
Figure 28: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion in both forward and reverse direction)
図28：双方向予約のための処理イントラドメインRMD重度の輻輳（両順方向及び逆方向の輻輳）
This additional bandwidth can be calculated using the following algorithm:
この追加の帯域幅は、次のアルゴリズムを用いて計算することができます。
IF ("marked_reverse_bandwidth" > "notify_reverse_bandwidth") THEN "additional_reverse_bandwidth" = = "marked_reverse_bandwidth"- "notify_reverse_bandwidth"; ELSE "additional_reverse_bandwidth" = 0
IF（ "marked_reverse_bandwidth"> "notify_reverse_bandwidth"）THEN "additional_reverse_bandwidth" = = "marked_reverse_bandwidth" - "notify_reverse_bandwidth"。 ELSE "additional_reverse_bandwidth" = 0
* Ingress terminates the flows that experienced a severe congestion in the forward path and received a (severe congestion) NOTIFY message.
*侵入が往路で重度の輻輳を経験し、NOTIFYメッセージ（重度の輻輳）を受信フローを終了します。
* If possible, the Ingress SHOULD terminate unidirectional flows that use the same Egress-Ingress reverse direction communication path to satisfy the release of a total bandwidth up equal to the "additional_reverse_bandwidth", see Appendix A.5.
*可能であれば、入口付録A.5を参照して、「additional_reverse_bandwidth」に等しい総帯域幅最大の放出を満たすために、同じ退出入逆方向通信路を使用する単方向フローを終了すべきです。
* If the number of REQUIRED unidirectional flows (to satisfy the above issue) is not available, then a number of bidirectional flows that are using the same Egress-Ingress reverse direction communication path MAY be selected for preemption in order to satisfy the release of a total bandwidth equal up to the "additional_reverse_bandwidth". Note that using the guidelines given in Appendix A.5, first the bidirectional flows that reserved a relatively small amount of resources on the path reversed to the path of congestion SHOULD be selected for termination.
* REQUIRED一方向流れ（上記問題を満足する）の数が利用できない場合、同じ退出入逆方向通信路を使用している双方向フローの数は、の放出を満たすために先取りのために選択することができます総帯域幅は「additional_reverse_bandwidth」まで等しいです。付録A.5に示すガイドラインを使用して、輻輳の経路と逆の経路上のリソースの比較的少量を予約第1の双方向フローが終了するために選択されるべきであることに留意されたいです。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states, the steps can be the following.
QNEのエッジが集約されたドメイン内のQoS-NSLP動作状態を維持する場合、手順は以下のことができます。
* The Egress calculates the bandwidth to be terminated using the same method as described in Section 4.6.1.6.2.2. The Egress includes this bandwidth value in a <PDR Bandwidth> within a "PDR_Congestion_Report" container that is carried by the end-to-end NOTIFY message.
*出口は、セクション4.6.1.6.2.2に記載したのと同じ方法を使用して終了される帯域幅を計算します。出口は、エンドツーエンドによって運ばれる「PDR_Congestion_Report」コンテナ内<PDR帯域>でこの帯域幅値を含むNOTIFYメッセージ。
* The Ingress receives the NOTIFY message and reads the <PDR Bandwidth> value included in the "PDR_Congestion_Report" container. Note that this value is denoted as "notify_reverse_bandwidth" in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, but is calculated differently. The variables "marked_reverse_bandwidth" and "additional_reverse_bandwidth" are calculated using the same steps as explained for the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP states.
*侵入がNOTIFYメッセージを受信し、「PDR_Congestion_Report」コンテナに含まれる<PDR帯域幅>の値を読み出します。この値はQNEのエッジは、フローごとのドメイン内のQoS-NSLP動作状態を維持するような状況で「notify_reverse_bandwidth」と表記されていますが、異なって計算されることに注意してください。変数「marked_reverse_bandwidth」と「additional_reverse_bandwidth」QNEのエッジは、フローごとのドメイン内のQoS-NSLP状態を維持するような状況のために説明したのと同じ手順を使用して計算されています。
* Regarding the termination of flows that use the same Egress-Ingress reverse direction communication path, the Ingress can follow the same procedures as the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
*同じ退出入逆方向通信路を使用するフローの終了については、入口は、QNEは、フロー毎のドメイン内のQoS-NSLP動作状態を維持するエッジ状況と同じ手順に従うことができます。
The RMD-aggregated (reduced-state) reservations maintained by the Interior nodes, can be reduced in the "forward" and "reverse" directions by using the procedure described in Section 4.6.2.3 and including in the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> field carried by the forward intra-domain RESERVE the value equal to <notify_reverse_bandwidth> and by including the <additional_reverse_bandwidth> value in the <PDR Bandwidth> parameter within the "PDR_Release_Request" container that is carried by the same intra-domain RESERVE message.
RMD凝集（還元状態）内部ノードによって維持予約、セクション4.6.2.3に記載された手順を使用し、<ピークデータレート-1に含めることによって、「前方」及び「逆」方向に低減することができます（ローカルRMD-QSPEC <TMOD-1> RMD-QOSM <たQoSは、所望のパラメータP）>値>フォワードドメイン内RESERVEによって<notify_reverse_bandwidth>及び<additional_reverse_bandwidth>値を含むことによって等しい値を実施フィールド同じドメイン内RESERVEメッセージによって運ばれる「PDR_Release_Request」コンテナ内<PDR帯域>パラメータ。
A.7. Example of Preemption Handling during Admission Control
A.7。アドミッション制御の際の取り扱いプリエンプションの例
This appendix describes an example of how preemption handling is supported during admission control.
この付録では、プリエンプション処理がアドミッション制御の際にサポートされている方法の例を説明します。
This section describes the mechanism that can be supported by the QNE Ingress, QNE Interior, and QNE Egress nodes to satisfy preemption during the admission control process.
このセクションでは、QNE進入、QNEインテリアで支持することができるメカニズムを説明し、そしてQNE退出は、アドミッション制御プロセス中にプリエンプションを満足するノード。
This mechanism uses the preemption building blocks specified in [RFC5974].
このメカニズムは[RFC5974]で指定されたプリエンプションビルディング・ブロックを使用しています。
A.7.1. Preemption Handling in QNE Ingress Nodes
A.7.1。 QNEのIngressノードでの取り扱いプリエンプション
If a QNE Ingress receives a RESERVE for a session that causes other session(s) to be preempted, for each of these to-be-preempted sessions, then the QNE Ingress follows the following steps:
QNE進入がこれらに-プリエンプトされるセッションのそれぞれに対して、プリエンプトされる他のセッション（複数可）を引き起こすセッション用に予約を受信した場合、その後、QNE進入は、以下のステップに従います。
Step_1:
ステップ1：
The QNE Ingress MUST send a tearing RESERVE downstream and add a BOUND-SESSION-ID, with <Binding_Code> value equal to "Indicated session caused preemption" that indicates the SESSION-ID of the session that caused the preemption. Furthermore, an <INFO-SPEC> object with error code value equal to "Reservation preempted" has to be included in each of these tearing RESERVE messages.
QNE進入下流引き裂きRESERVEを送信し、BOUND-SESSION-IDを追加し、等しい<Binding_Code>値としなければならないセッションIDプリエンプションを引き起こしたセッションを示す「指示されたセッションプリエンプションを引き起こしました」。また、<INFO-SPEC>オブジェクトエラーコード値に等しい「先取り予約」は、これら引き裂くRESERVEメッセージの各々に含まれなければなりません。
The selection of which flows have to be preempted can be based on predefined policies. For example, this selection process can be based on the MRI associated with the high and low priority sessions. In particular, the QNE Ingress can select low(er) priority session(s) where their MRI is "close" (especially the target IP) to the one associated with the higher priority session. This means that typically the high priority session and the to-be-preempted lower priority sessions are following the same communication path and are passing through the same QNE Egress node.
先取りする必要が流れるの選択は、事前に定義されたポリシーに基づいて行うことができます。例えば、この選択プロセスは、高および低優先度のセッションに関連付けられたMRIに基づくことができます。特に、QNE進入は、そのMRIは、より高い優先度のセッションに関連する一つの（特にターゲットIP）「近い」低（ER）優先セッション（複数可）を選択することができます。これは、典型的には、高優先度のセッションと、プリエンプトされるように、優先度の低いセッションが同じ通信経路に従っていると同じQNE出口ノードを通過していることを意味します。
Furthermore, the amount of lower priority sessions that have to be preempted per each high priority session, has to be such that the requested resources by the higher priority session SHOULD be lower or equal than the sum of the reserved resources associated with the lower priority sessions that have to be preempted.
また、各高優先度のセッションごとにプリエンプトされなければならない優先度の低いセッションの量は、より高い優先度のセッションによって要求されたリソースは、優先度の低いセッションに関連付けられた予約されたリソースの合計よりも低いか等しくなければならないようなものでなければなりませんそれは先取りする必要があります。
Step_2:
ステップ2：
For each of the sent tearing RESERVE(s) the QNE Ingress will send a NOTIFY message with an <INFO-SPEC> object with error code value equal to "Reservation preempted" towards the QNI.
送信引き裂くRESERVE（S）のそれぞれについて、QNE侵入がQNIに向かって「先取り予約」に等しいエラーコード値を持つ<INFO-SPEC>オブジェクトとNOTIFYメッセージを送信します。
Step_3:
Step_3：
After sending the preempted (tearing) RESERVE(s), the Ingress QNE will send the (reserving) RESERVE, which caused the preemption, downstream towards the QNE Egress.
先取り（引き裂く）RESERVE（複数可）を送信した後、入口QNEはQNE出口に向かって下流に、プリエンプションを引き起こした（予約）RESERVEを送信します。
A.7.2. Preemption Handling in QNE Interior Nodes
A.7.2。 QNEインテリアノードでの取り扱いプリエンプション
The QNE Interior upon receiving the first (tearing) RESERVE that carries the <BOUND-SESSION-ID> object with <Binding_Code> value equal to "Indicated session caused preemption" and an <INFO-SPEC> object with error code value equal to "Reservation preempted" it considers that this session has to be preempted.
等しい<Binding_Code>値<製本セッションID>オブジェクトを搬送する第一（引き裂く）RESERVEを受信するQNEインテリアに「示されセッションがプリエンプションを引き起こした」と<INFO-SPEC>に等しいエラーコード値を持つオブジェクト」先取り予約は」それはこのセッションがプリエンプトされなければならないことを考えています。
In this case, the QNE Interior creates a so-called "preemption state", which is identified by the SESSION-ID carried in the preemption-related <BOUND-SESSION-ID> object. Furthermore, this "preemption state" will include the SESSION-ID of the session associated with the (tearing) RESERVE. Subsequently, if additional tearing RESERVE(s) are arriving including the same values of BOUND-SESSION-ID and <INFO-SPEC> objects, then the associated SESSION-IDs of these (tearing) RESERVE message will be included in the already created "preemption state". The QNE will then set a timer, with a value that is high enough to ensure that it will not expire before the (reserving) RESERVE arrives.
この場合、QNEインテリアプリエンプション関連<BOUND-SESSION-ID>オブジェクトで運ばれるセッションIDによって識別される、いわゆる「プリエンプション状態」を生成します。また、この「プリエンプション状態」（引き裂く）RESERVEに関連付けられたセッションのセッションIDを含むであろう。その後、追加の引裂きRESERVE（S）場合、「これら（引き裂く）RESERVEメッセージの関連したセッションIDが既に作成に含まれる、同じBOUND-SESSION-IDの値と、<INFO-SPEC>オブジェクトを含む到着しますプリエンプション状態」。 QNEは、（予約）RESERVEが到着する前にそれが期限切れにならないことを保証するのに十分な高さの値で、タイマーを設定します。
Note that when the "preemption state" timer expires, the bandwidth associated with the preempted session(s) will have to be released, following a normal RMD-QOSM bandwidth release procedure. If the QNE Interior node will not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress before their associated (reserving) RESERVE message arrives, then the (reserving) RESERVE message will not reserve any resources and this message will be "M" marked (see Section 4.6.1.2). Note that this situation is not a typical situation. Typically, this situation can only occur when at least one of (tearing) the RESERVE messages is dropped due to an error condition.
「プリエンプション状態」タイマーが満了したとき、先取りセッション（複数可）に関連付けられている帯域幅は、通常のRMD-QOSM帯域開放の手順に従って、解放されなければならないことに注意してください。 QNEインテリアノードは、それに関連する（予約）RESERVEメッセージが到着する前に、それから（予約）RESERVEメッセージは、すべてのリソースと、このメッセージを予約しませんQNE進入によって送信されたすべての-プリエンプトする（涙）RESERVEメッセージを受信しない場合「M」マーク（セクション4.6.1.2を参照）になります。このような状況は、典型的な状況ではないことに注意してください。典型的には、このような状況のみ（引裂）の少なくとも1つのRESERVEメッセージがエラー状態にドロップされたときに起こり得ます。
Otherwise, if the QNE Interior receives all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress, then the QNE Interior will remove the pending resources, and make the new reservation using normal RMD-QOSM bandwidth release and reservation procedures.
QNEインテリアQNE進入によって送信されたすべての-プリエンプトする（涙）RESERVEメッセージを受信した場合それ以外の場合は、その後、QNEインテリアの保留中のリソースを削除し、通常のRMD-QOSMの帯域開放と予約手続きを使用して、新しい予約を行います。
A.7.3. Preemption Handling in QNE Egress Nodes
A.7.3。 QNE出口ノードでの取り扱いプリエンプション
Similar to the QNE Interior operation, the QNE Egress, upon receiving the first (tearing) RESERVE that carries the <BOUND-SESSION-ID> object with the <Binding_Code> value equal to "Indicated session caused preemption" and an <INFO-SPEC> object with error code value equal to "Reservation preempted", it considers that this session has to be preempted. Similar to the QNE Interior operation the QNE Egress creates a so called "preemption state", which is identified by the SESSION-ID carried in the preemption-related <BOUND-SESSION-ID> object. This "preemption state" will store the same type of information and use the same timer value as specified in Appendix A.7.2.
等しい<Binding_Code>値<BOUND-SESSION-ID>オブジェクト「と表示セッションがプリエンプションを引き起こし」運び、<INFO-SPEC最初（引き裂く）RESERVEを受信すると、QNEインテリア操作、QNE退出に類似>「先取り予約」に等しいエラーコード値を持つオブジェクトは、このセッションがプリエンプトされなければならないことを考えます。 QNEインテリア動作と同様QNE出口は、プリエンプション関連<BOUND-SESSION-ID>オブジェクトで運ばれるセッションIDによって識別される、いわゆる「プリエンプション状態」を生成します。この「プリエンプション状態は」同じ種類の情報を格納し、付録A.7.2で指定されたものと同じタイマー値を使用します。
Subsequently, if additional tearing RESERVE(s) are arriving including the same values of BOUND-SESSION-ID and <INFO-SPEC> objects, then the associated SESSION-IDs of these (tearing) RESERVE message will be included in the already created "preemption state".
その後、追加の引裂きRESERVE（S）場合、「これら（引き裂く）RESERVEメッセージの関連したセッションIDが既に作成に含まれる、同じBOUND-SESSION-IDの値と、<INFO-SPEC>オブジェクトを含む到着しますプリエンプション状態」。
If the (reserving) RESERVE message sent by the QNE Ingress node arrived and is not "M" marked, and if all the to-be-preempted (tearing) RESERVE messages arrived, then the QNE Egress will remove the pending resources and make the new reservation using normal RMD-QOSM procedures.
QNE Ingressノードによって送信された（予約）RESERVEメッセージが到着し、「M」マークされ、ものではなく、すべての-プリエンプトすることに-（引き裂く）RESERVEメッセージが到着した場合、QNE出口は保留中のリソースを削除して作れば通常のRMD-QOSMの手順を使用して新しい予約。
If the QNE Egress receives an "M" marked RESERVE message, then the QNE Egress will use the normal partial RMD-QOSM procedure to release the partial reserved resources associated with the "M" marked RESERVE (see Section 4.6.1.2).
QNE出口は「M」マークRESERVEメッセージを受信した場合、その後、QNE出口は「M」に関連した部分に予約されたリソースを解放するために、通常の部分RMD-QOSMの手順を使用します（セクション4.6.1.2を参照）RESERVEをマーク。
If the QNE Egress will not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress before their associated and not "M" marked (reserving) RESERVE message arrives, then the following steps can be followed:
QNE出口がQNE進入によって送信されたすべての-プリエンプトする（涙）RESERVEメッセージを受信しない場合は、その「M」マーク（予約）の関連はなくRESERVEメッセージが到着する前に、次の手順に従うことができます。
* If the QNE Egress uses an end-to-end QOSM that supports the preemption handling, then the QNE Egress has to calculate and select new lower priority sessions that have to be terminated. How the preempted sessions are selected and signaled to the downstream QNEs is similar to the operation specified in Appendix A.7.1.
QNE出口は、プリエンプション処理をサポートし、エンドツーエンドのQOSMを使用している場合*、その後、QNE出口を計算し、終了する必要があり、新たな優先度の低いセッションを選択しなければなりません。どのように横取りセッションが選択され、下流QNEsに通知される付録A.7.1で指定された動作と同様です。
* If the QNE Egress does not use an end-to-end QOSM that supports the preemption handling, then the QNE Egress has to reject the requesting (reserving) RESERVE message associated with the high priority session (see Section 4.6.1.2).
QNE出口は、プリエンプション処理をサポートし、エンドツーエンドのQOSMを使用していない場合は*、その後、QNE出口は、優先度の高いセッションに関連付けられた要求（保留）RESERVEメッセージを拒否しなければならない（セクション4.6.1.2を参照）。
Note that typically, the situation in which the QNE Egress does not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress can only occur when at least one of the (tearing) RESERVE messages are dropped due to an error condition.
（引き裂く）RESERVEメッセージの少なくとも一つがが原因でドロップされた場合には、典型的には、QNE退出がQNE進入によって送信された全プリエンプトされるように、（引き裂く）RESERVEメッセージを受信しない状況でのみ発生することができますエラー状態。
A.8. Example of a Retransmission Procedure within the RMD Domain
A.8。 RMDドメイン内の再送信手順の例
This appendix describes an example of a retransmission procedure that can be used in the RMD domain.
この付録では、RMDのドメインで使用することができ再送手順の一例を説明します。
If the retransmission of intra-domain RESERVE messages within the RMD domain is not disallowed, then all the QNE Interior nodes SHOULD use the functionality described in this section.
RMDドメイン内のドメイン内RESERVEメッセージの再送信が禁止されていない場合は、すべてのQNEインテリア・ノードは、このセクションで説明した機能を使用すべきです。
In this situation, we enable QNE Interior nodes to maintain a replay cache in which each entry contains the <RSN>, <SESSION-ID> (available via GIST), <REFRESH-PERIOD> (available via the QoS NSLP [RFC5974]), and the last received "PHR Container" <Parameter ID> carried by the RMD-QSPEC for each session [RFC5975]. Thus, this solution uses information carried by <QoS-NSLP> objects [RFC5974] and parameters carried by the RMD-QSPEC "PHR Container". The following phases can be distinguished:
この状況では、我々は、各エントリが含まれたリプレイ・キャッシュを維持するために、QNEインテリアノードを有効にする<RSN>、<セッションID>（GISTを介して利用可能）、<REFRESH周期>（のQoS NSLPを介して利用可能な[RFC5974]） 、そして最後に受信した「PHR容器は、」<パラメータID>各セッション[RFC5975]のためのRMD-QSPECによって運ばれます。従って、この溶液は、<なQoS-NSLP>オブジェクト[RFC5974]とRMD-QSPEC「PHRコンテナ」によって運ばれるパラメータによって運ばれる情報を使用します。次のフェーズを区別することができます。
Phase 1: Create Replay Cache Entry
フェーズ1：リプレイキャッシュエントリを作成します。
When an Interior node receives an intra-domain RESERVE message and its cache is empty or there is no matching entry, it reads the <Parameter ID> field of the "PHR Container" of the received message. If the <Parameter ID> is a PHR_RESOURCE_REQUEST, which indicates that the intra-domain RESERVE message is a reservation request, then the QNE Interior node creates a new entry in the cache and copies the <RSN>, <SESSION-ID> and <Parameter ID> to the entry and sets the <REFRESH-PERIOD>.
内部ノードがドメイン内RESERVEメッセージを受信し、キャッシュが空であるか、または一致するエントリが存在しない場合には、受信したメッセージの「PHRコンテナ」の<パラメータID>フィールドを読み取ります。 <パラメータID>はドメイン内RESERVEメッセージは、予約要求であることを示すPHR_RESOURCE_REQUEST、ある場合には、QNEインテリアノードは、キャッシュコピーに新しいエントリを作成し、<RSN>、<セッションID>と<パラメータのエントリにID>とは、<REFRESH期間>を設定します。
By using the information stored in the list, the Interior node verifies whether or not the received intra-domain RESERVE message is sent by an adversary. For example, if the <SESSION-ID> and <RSN> of a received intra-domain RESERVE message match the values stored in the list then the Interior node checks the <Parameter ID> part.
リストに格納された情報を使用して、内部ノードは、受信したドメイン内RESERVEメッセージが敵によって送信されるか否かを検証します。例えば、受信したドメイン内RESERVEメッセージがリストに格納された値と一致する<セッションID>と<RSN>場合、内部ノードは、<パラメータID>部分を確認します。
If the <Parameter ID> is different, then:
<パラメータID>が異なる場合は、次のようになります。
Situation D1: <Parameter ID> in its own list is PHR_RESOURCE_REQUEST, and <Parameter ID> in the message is PHR_REFRESH_UPDATE;
状況D1：<パラメータID>独自のリスト内のメッセージにPHR_RESOURCE_REQUEST、及び<パラメータID>はPHR_REFRESH_UPDATEです。
Situation D2: <Parameter ID> in its own list is PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, and <Parameter ID> in the message is PHR_RELEASE_REQUEST;
状況D2：<パラメータID>独自のリストには、メッセージにPHR_RESOURCE_REQUEST又はPHR_REFRESH_UPDATEであり、そして<パラメータID> PHR_RELEASE_REQUESTあります。
Situation D3: <Parameter ID> in its own list is PHR_REFRESH_UPDATE, and <Parameter ID> in the message is PHR_RESOURCE_REQUEST;
状況D3：メッセージ内の<パラメータID>独自のリストにはPHR_REFRESH_UPDATEであり、そして<パラメータID>はPHR_RESOURCE_REQUESTあります。
For Situation D1, the QNE Interior node processes this message by RMD-QOSM default operation, reserves bandwidth, updates the entry, and passes the message to downstream nodes. For Situation D2, the QNE Interior node processes this message by RMD-QOSM default operation, releases bandwidth, deletes all entries associated with the session and passes the message to downstream nodes. For situation D3, the QNE Interior node does not use/process the local RMD-QSPEC <TMOD-1> parameter carried by the received intra-domain RESERVE message. Furthermore, the <K> flag in the "PHR Container" has to be set such that the local RMD-QSPEC <TMOD-1> parameter carried by the intra-domain RESERVE message is not processed/used by a QNE Interior node.
状況D1ため、QNEインテリアノードは、RMD-QOSMデフォルト動作、埋蔵量の帯域幅によって、このメッセージを処理するエントリを更新し、下流ノードにメッセージを渡します。状況D2ため、QNEインテリアノードプロセスRMD-QOSMデフォルト動作、解放帯域幅によって、このメッセージは、セッションに関連するすべてのエントリを削除し、下流のノードにメッセージを渡します。状況D3ため、QNEインテリアノードは、/プロセス受信ドメイン内RESERVEメッセージによって運ばローカルRMD-QSPEC <TMOD-1>パラメータを使用しません。また、「PHRコンテナ」内の<K>フラグは、ドメイン内RESERVEメッセージによって運ばローカルRMD-QSPEC <TMOD-1>パラメータがQNEインテリアノードによって使用される/処理されないように設定されなければなりません。
If the <Parameter ID> is the same, then:
<パラメータID>は、その後、同じである場合：
Situation S1: <Parameter ID> is equal to PHR_RESOURCE_REQUEST;
Situation S2: <Parameter ID> is equal to PHR_REFRESH_UPDATE;
For situation S1, the QNE Interior node does not process the intra-domain RESERVE message, but it just passes it to downstream nodes, because it might have been retransmitted by the QNE Ingress node. For situation S2, the QNE Interior node processes the first incoming intra-domain (refresh) RESERVE message within a refresh period and updates the entry and forwards it to the downstream nodes.
状況S1の場合、QNEインテリアノードは、ドメイン内のRESERVEメッセージを処理しませんが、それはQNE Ingressノードによって再送された可能性があるので、それだけで、下流のノードに渡します。状況S2ため、QNEインテリアノードは、リフレッシュ期間内の最初の着信ドメイン内（リフレッシュ）RESERVEメッセージを処理し、エントリを更新し、下流ノードに転送します。
If only <Session-ID> is matched to the list, then the QNE Interior node checks the <RSN>. Here also two situations can be distinguished:
唯一の<セッションID>がリストに一致した場合には、QNEインテリアノードは、<RSN>をチェックします。ここでは、二つの状況を区別することができます。
If a rerouting takes place (see Section 5.2.5.2 in [RFC5974]), the <RSN> in the message will be equal to either <RSN + 2> in the stored list if it is not a tearing RESERVE or <RSN -1> in the stored list if it is a tearing RESERVE:
再ルーティングは（[RFC5974]セクション5.2.5.2を参照）で行われる場合は、引き裂きRESERVEないか、または<RSN -1場合、<RSN>メッセージに格納されたリストの<RSN + 2>のいずれかに等しくなります>それは引き裂きRESERVEある場合に記憶されたリストで：
The QNE Interior node will check the <Parameter ID> part;
QNEインテリアノードは、<パラメータID>の部分をチェックします。
If the <RSN> in the message is equal to <RSN + 2> in the stored list and the <Parameter ID> is a PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, then the received intra-domain RESERVE message has to be interpreted and processed as a typical (non-tearing) RESERVE message, which is caused by rerouting, see Section 5.2.5.2 in [RFC5974].
<RSN>メッセージに格納されたリスト内の<RSN + 2>に等しく、<パラメータID>はPHR_RESOURCE_REQUEST又はPHR_REFRESH_UPDATEであり、受信したドメイン内RESERVEメッセージは、（典型的なものとして解釈して処理しなければならない場合再ルーティングによって引き起こされる非引き裂き）RESERVEメッセージは、[RFC5974]に、セクション5.2.5.2を参照してください。
If the <RSN> in the message is equal to <RSN-1> in the stored list and the <Parameter ID> is a PHR_RELEASE_REQUEST, then the received intra-domain RESERVE message has to be interpreted and processed as a typical (tearing) RESERVE message, which is caused by rerouting (see Section 5.2.5.2 in [RFC5974]).
<RSN>メッセージに格納されたリスト内の<RSN-1>に等しく、<パラメータID>はPHR_RELEASE_REQUESTで、受信したドメイン内RESERVEメッセージは、（引き裂く）の典型的なものとして解釈して処理しなければならない場合再ルーティングによって引き起こされるRESERVEメッセージ（[RFC5974]に、セクション5.2.5.2を参照）。
If other situations occur than the ones described above, then the QNE Interior node does not use/process the local RMD-QSPEC <TMOD-1> parameter carried by the received intra-domain RESERVE message. Furthermore, the <K> parameter has to be set, see above.
他の状況は、上述したものより発生した場合、その後、QNEインテリアノードは/プロセスを受信し、ドメイン内RESERVEメッセージによって運ばローカルRMD-QSPEC <TMOD-1>パラメータを使用していません。また、<K>パラメータを設定する必要があり、上記を参照されたいです。
Phase 2: Update Replay Cache Entry
フェーズ2：アップデートリプレイキャッシュエントリ
When a QNE Interior node receives an intra-domain RESERVE message, it retrieves the corresponding entry from the cache and compares the values. If the message is valid, the Interior node will update <Parameter ID> and <REFRESH-PERIOD> in the list entry.
QNEインテリアノードがドメイン内RESERVEメッセージを受信すると、キャッシュから対応するエントリを検索し、値を比較します。メッセージが有効である場合は、リストのエントリに、インテリアノードは、<パラメータID>を更新すると、<REFRESH期間>。
Phase 3: Delete Replay Cache Entry
フェーズ3：リプレイキャッシュエントリの削除
When a QNE Interior node receives an intra-domain (tear) RESERVE message and an entry in the replay cache can be found, then the QNE Interior node will delete this entry after processing the message. Furthermore, the Interior node will delete cache entries, if it did not receive an intra-domain (refresh) RESERVE message during the <REFRESH-PERIOD> period with a <Parameter ID> value equal to PHR_REFRESH_UPDATE.
QNE内部ノードを見つけることができるイントラドメイン（涙）RESERVEメッセージと再生キャッシュ内のエントリを受信すると、次いで、QNEインテリアノードは、メッセージを処理した後、このエントリを削除します。それはPHR_REFRESH_UPDATEに等しい<パラメータID>値<REFRESH期間>期間中にイントラドメイン（リフレッシュ）RESERVEメッセージを受信しなかった場合はさらに、内部ノードは、キャッシュエントリを削除します。
A.9. Example on Matching the Initiator QSPEC to the Local RMD-QSPEC
A.9。ローカルRMD-QSPECにイニシエータQSPECマッチングの例
Section 3.4 of [RFC5975] describes an example of how the QSPEC can be Used within QoS-NSLP. Figure 29 illustrates a situation where a QNI and a QNR are using an end-to-end QOSM, denoted in this context as Z-e2e. It is considered that the QNI access network side is a wireless access network built on a generation "X" technology with QoS support as defined by generation "X", while QNR access network is a wired/fixed access network with its own defined QoS support.
[RFC5975]のセクション3.4はQSPECは、QoS-NSLP内で使用することができる方法の例を説明します。図29は、QNIとQNRはZ-E2Eこの文脈で示され、エンドツーエンドQOSMを使用している状況を示しています。 QNRアクセスネットワークは、独自の定義されたQoSをサポートした有線/固定アクセスネットワークである一方、QNIアクセスネットワーク側は世代によって定義された「X」などのQoSをサポートして世代「X」の技術で構築された無線アクセスネットワークであると考えられています。
Furthermore, it is considered that the shown QNE Edges are located at the boundary of an RMD domain and that the shown QNE Interior nodes are located inside the RMD domain.
更に、図示QNEエッジがRMD領域の境界に位置していることを図示QNE内部ノードはRMD領域の内部に位置していると考えられます。
The QNE Edges are able to run both the Z-e2e QOSM and the RMD-QOSM, while the QNE Interior nodes can only run the RMD-QOSM. The QNI is considered to be a wireless laptop, for example, while the QNR is considered to be a PC.
QNEエッジはQNEインテリアノードのみRMD-QOSMを実行することができるが、Z-E2EのQOSMとRMD-QOSM両方を実行することが可能です。 QNRがPCであると考えられている間QNIは、例えば、無線ラップトップであると考えられています。
|------| |------| |------| |------|
|Z-e2e |<->|Z-e2e |<------------------------->|Z-e2e |<->|Z-e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Z-e2e | | RMD | | RMD | | RMD | | RMD | | Z-e2e|
| 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 29. Example of initiator and local domain QOSM operation
イニシエータとローカルドメインQOSM動作の図29の例
The QNI sets <QoS Desired> and <QoS Available> QSPEC objects in the initiator QSPEC, and initializes <QoS Available> to <QoS Desired>. In this example, the <Minimum QoS> object is not populated. The QNI populates QSPEC parameters to ensure correct treatment of its traffic in domains down the path. Additionally, to ensure correct treatment further down the path, the QNI includes <PHB Class> in <QoS Desired>. The QNI therefore includes in the QSPEC.
QNIセット<望ましいQoS>と<利用可能なQoS> QSPECイニシエータQSPEC内のオブジェクト、および初期化<望ましいQoS>から<利用可能なQoS>。この例では、<最低限QoS>オブジェクトが移入されていません。 QNIパスダウンドメインにおけるトラフィックの正確な治療を確実にするためにQSPECパラメータを移入します。加えて、さらに経路ダウン正しい治療を確実にするために、QNIは<望ましいQoS>に<PHBクラス>を含みます。 QNIしたがってQSPECに含みます。
<QoS Desired> = <TMOD-1> <PHB Class> <QoS Available> = <TMOD-1> <Path Latency>
= <TMOD-1> = <TMOD-1> <PHBクラス> <利用可能なQoS> <パスレイテンシ> <QoSが希望します>
In this example, it is assumed that the <TMOD-1> parameter is used to encode the traffic parameters of a VoIP application that uses RTP and the G.711 Codec, see Appendix B in [RFC5975]. The below text is copied from [RFC5975].
この例では、<TMOD-1>パラメータは、RTPとG.711コーデックを使用するVoIPアプリケーションのトラフィックパラメータを符号化する[RFC5975]の付録Bを参照するために使用されているものとします。以下のテキストは、[RFC5975]からコピーされます。
In the simplest case the Minimum Policed Unit m is the sum of the IP-, UDP- and RTP- headers + payload. The IP header in the IPv4 case has a size of 20 octets (40 octets if IPv6 is used). The UDP header has a size of 8 octets and RTP uses a 12 octet header. The
最も単純な場合、最小ポリシングユニットMはIP-、UDP-及びRTP-ヘッダ+ペイロードの合計です。 IPv4のケースにおけるIPヘッダは20個のオクテット（IPv6が使用される場合、40オクテット）の大きさを有しています。 UDPヘッダは8つのオクテットのサイズを有し、RTPは、12オクテットのヘッダを使用します。ザ・
G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming RTP transmits voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets.
G.711コーデックは、64キロビット/秒の帯域幅（8000オクテット/秒）を指定します。 RTPは、音声は20msごとにデータグラムを送信すると仮定すると、あるデータグラムのペイロードは8000オクテット/秒* 0.02秒= 160オクテットです。
IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets
IPv4の+ UDP + RTP +ペイロード：M = 20 + 8 + 12 + 160 = 200オクテットオクテットのIPv6 + UDP + RTP +ペイロード：M = 40 + 8 + 12 + 160 = 220個のオクテットオクテット
The Rate r specifies the amount of octets per second. 50 datagrams are sent per second.
レートrは、毎秒のオクテットの量を指定します。 50グラム毎秒送信されます。
IPv4: r = 50 1/s * m = 10,000 octets/s IPv6: r = 50 1/s * m = 11,000 octets/s
IPv4のR = 50 1 / S *のM =万オクテット/秒のIPv6：R = 50 1 / S×m個= 11,000オクテット/秒
The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used.
バケットサイズbは最大バーストを指定します。この例では、10のパケットのバーストが使用されます。
IPv4: b = 10 * m = 2000 octets IPv6: b = 10 * m = 2200 octets
IPv4のA：B = 10×m個= 2000オクテットのIPv6：B = 10 * M = 2200オクテット
In our example, we will assume that IPV4 is used and therefore, the <TMOD-1> values will be set as follows:
この例では、次のようにIPV4が使用されるため、<TMOD-1>の値が設定されることを前提としています：
m = 200 octets r = 10000 octets/s b = 2000 octets
M = 200オクテットR = 10000オクテット/ S B = 2000オクテット
The <Peak Data Rate-1 (p)> and MPS are not specified above, but in our example we will assume:
<ピークデータレート-1（P）>とMPSは、上記で指定されていないが、私たちの例では、我々は仮定します：
p = r = 10000 octets/s MPS = 220 octets
P = R = 10000オクテット/ S MPS = 220オクテット
The <PHB Class> is set in such a way that the Expedited Forwarding (EF) PHB is used.
<PHBクラス>緊急転送（EF）PHBを使用するように設定されています。
Since <Path Latency> and <QoS Class> are not vital parameters from the QNI's perspective, it does not raise their <M> flags.
<パスレイテンシ>と<のQoSクラス>は、QNIの観点から極めて重要なパラメータではありませんので、それは彼らの<M>旗を上げていません。
Each QNE, which supports the Z-e2e QOSM on the path, reads and interprets those parameters in the initiator QSPEC.
パス上にZ-E2EのQOSMをサポートする各QNEは、イニシエータQSPECにそれらのパラメータを読み込み、解釈します。
When an end-to-end RESERVE message is received at a QNE Ingress node at the RMD domain border, the QNE Ingress can "hide" the initiator end-to-end RESERVE message so that only the QNE Edges process the initiator (end-to-end) RESERVE message, which then bypasses intermediate nodes between the Edges of the domain, and issues its own local RESERVE message (see Section 6). For this new local RESERVE message, the QNE Ingress node generates the local RMD-QSPEC.
エンドツーエンドのRESERVEメッセージはRMDドメイン境界におけるQNE Ingressノードで受信されると、QNE進入することができる「隠す」イニシエータエンドツーエンドRESERVEメッセージようのみQNEエッジが（イニシエータを処理するエンド次いで、ドメインのエッジの間の中間ノードをバイパスし、それ自身のローカルRESERVEメッセージを発行するエンド）RESERVEメッセージ（セクション6を参照）。この新しいローカルRESERVEメッセージを、QNE Ingressノードは、ローカル・RMD-QSPECを生成します。
The RMD-QSPEC corresponding to the RMD-QOSM is generated based on the original initiator QSPEC according to the procedures described in Section 4.5 of [RFC5974] and in Section 6 of this document. The RMD QNE Ingress maps the <TMOD-1> parameters contained in the original Initiator QSPEC into the equivalent <TMOD-1> parameter representing only the peak bandwidth in the local RMD-QSPEC.
RMD-QOSMに対応RMD-QSPECは、[RFC5974]のセクション4.5で、このドキュメントのセクション6で説明されている手順に従ってQSPEC元のイニシエータに基づいて生成されます。 RMD QNE進入は、ローカルRMD-QSPECでのみピーク帯域幅を表す等価<TMOD-1>パラメータに元のイニシエータQSPECに含まれる<TMOD-1>のパラメータをマッピングします。
In this example, the initial <TMOD-1> parameters are mapped into the RMD-QSPEC <TMOD-1> parameters as follows.
次のように、この例では、最初の<TMOD-1>パラメータは、RMD-QSPEC <TMOD-1>のパラメータにマッピングされます。
As specified, the RMD-QOSM bandwidth equivalent <TMOD-1> parameter of RMD-QSPEC should have:
指定されているように、RMD-QSPECのRMD-QOSM帯域幅と同等<TMOD-1>パラメータは、持っている必要があります。
r = p of initial e2e <TMOD-1> parameter
m = large;
b = large;
For the RMD-QSPEC <TMOD-1> parameter, the following values are calculated:
RMD-QSPEC <TMOD-1>パラメータに対して、以下の値が計算されます。
r = p of initial e2e <TMOD-1> parameter = 10000 octets/s m is set in this example to large as follows: m = MPS of initial e2e <TMOD-1> parameter = 220 octets
初期E2EのR = P <TMOD-1>パラメータ= 10000オクテットで次のようにmが大きいと、この例で設定されている/ S：M =初期E2EのMPS <TMOD-1>パラメータ= 220個のオクテット
The maximum value of b = 250 gigabytes, but in our example this value is quite large. The b parameter specifies the extent to which the data rate can exceed the sustainable level for short periods of time.
B = 250ギガバイトの最大値は、私たちの例では、この値が非常に大きいです。 Bパラメータは、データレートが短時間持続可能なレベルを超えることができる範囲を指定します。
In order to get a large b, in this example we consider that for a period of certain period of time the data rate can exceed the sustainable level, which in our example is the peak rate (p).
大Bを得るために、この例では、我々は、一定期間の期間のためのデータレートは、私たちの例では、ピークレート（P）である持続可能なレベルを超えることができると考えています。
Thus, in our example, we calculate b as:
したがって、この例では、我々としてbを計算します。
b = p * "period of time"
B = P * "の期間"
For this VoIP example, we can assume that this period of time is 1.5 seconds, see below:
このVoIPの例では、我々は以下を参照してください、この時間は1.5秒であると仮定することができます：
b = 10000 octets/s * 1.5 seconds = 15000 octets
B = 10000オクテット/秒* 1.5秒= 15000個のオクテット
Thus, the local RMD-QSPEC <TMOD-1> values are:
したがって、ローカルRMD-QSPEC <TMOD-1>の値は次のとおりです。
r = 10000 octets/s p = 10000 octets/s m = 220 octets b = 15000 octets MPS = 220 octets
R = 10000オクテット/ S P = 10000オクテット/ S M = 220オクテットB = 15000オクテットMPS = 220個のオクテット
The bit level format of the RMD-QSPEC is given in Section 4.1. In particular, the Initiator/Local QSPEC bit, i.e., <I> is set to "Local" (i.e., "1") and the <Qspec Proc> is set as follows:
RMD-QSPECのビットレベルのフォーマットは、セクション4.1に記載されています。具体的には、イニシエータ/ローカルQSPECビット、すなわち、<I>は、「ローカル」に設定されている（すなわち、「1」）と、以下のように<Qspec PROC>が設定されています。
* Message Sequence = 0: Sender initiated * Object combination = 0: <QoS Desired> for RESERVE and <QoS Reserved> for RESPONSE
応答のためのRESERVEのための<QoSが希望>と<QoSの予約>：*メッセージシーケンス= 0：送信者開始*オブジェクトの組み合わせ= 0
The <QSPEC Version> used by RMD-QOSM is the default version, i.e., "0", see [RFC5975]. The <QSPEC Type> value used by the RMD-QOSM is specified in [RFC5975] and is equal to: "2".
<QSPEC版> RMD-QOSMによって使用される既定のバージョン、すなわち、 "0" である、[RFC5975]を参照。 「2」：RMD-QOSMによって使用される<QSPECタイプ>値は[RFC5975]で指定さに等しいです。
The <Traffic Handling Directives> contains the following fields:
<トラフィック処理ディレクティブ>は、次のフィールドが含まれています。
<Traffic Handling Directives> = <PHR container> <PDR container>
<トラフィック処理ディレクティブ> = <PHRコンテナ> <PDRコンテナ>
The Per-Hop Reservation container (PHR container) and the Per-Domain Reservation container (PDR container) are specified in Sections 4.1.2 and 4.1.3, respectively. The <PHR container> contains the traffic handling directives for intra-domain communication and reservation. The <PDR container> contains additional traffic handling directives that are needed for edge-to-edge communication. The RMD-QOSM <QoS Desired> and <QoS Reserved>, are specified in Section 4.1.1.
パーホップ予約容器（PHR容器）ごとのドメイン予約容器（PDR容器）は、それぞれ、セクション4.1.2及び4.1.3で指定されています。 <PHRコンテナは>ドメイン内のコミュニケーションや予約のためのトラフィック処理ディレクティブが含まれています。 <PDRコンテナは>エッジ間の通信のために必要な追加のトラフィック処理ディレクティブが含まれています。 RMD-QOSM <望ましいQoS>と<QoSの予約は>、4.1.1に規定されています。
In RMD-QOSM the <QoS Desired> and <QoS Reserved> objects contain the following parameters:
<QoSが希望>と<QoSが確保> RMD-QOSM内のオブジェクトは、次のパラメータが含まれています。
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority> <QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
<QoSの希望> = <TMOD-1> <PHBクラス> <入場優先順位> <QoSの予約> = <TMOD-1> <PHBクラス> <入場優先順位>
The bit format of the <PHB Class> (see [RFC5975] and Figures 4 and 5) and <Admission Priority> complies to the bit format specified in [RFC5975].
<PHBクラス>のビット・フォーマット（[RFC5975]を参照し、4及び5図）と<入場優先度は> [RFC5975]で指定されたビットフォーマットに準拠。
In this example, the RMD-QSPEC <TMOD-1> values are the ones that were calculated and given above. Furthermore, the <PHB Class>, represents the EF PHB class. Moreover, in this example the RMD reservation is established without an <Admission Priority> parameter, which is equivalent to a reservation established with an <Admission Priority> whose value is 1.
この例では、RMD-QSPEC <TMOD-1>の値を計算し、上記に与えたものです。さらに、<PHBクラス>、EFのPHBクラスを表します。また、この例ではRMD予約は、その値が1である<アドミッション優先>で確立予約に相当する<アドミッション優先>パラメータなしで確立されます。
The RMD QNE Egress node updates <QoS Available> on behalf of the entire RMD domain if it can. If it cannot (since the <M> flag is not set for <Path Latency>) it raises the parameter-specific, "not-supported" flag, warning the QNR that the final latency value in <QoS Available> is imprecise.
RMD QNE出口ノードの更新全体RMDドメインの代わりに、<利用可能なQoS>それができれば。それができない場合（<M>フラグが<パス待ち時間>のために設定されていないので）それは、<利用可能なQoS>の最後のレイテンシ値が不正確であることをQNRを警告し、パラメータ固有の、「-サポートされていない」フラグを発生させます。
In the "Y" access domain, the initiator QSPEC is processed by the QNR in the similar was as it was processed in the "X" wireless access domain, by the QNI.
それはQNIにより、「X」無線アクセス・ドメイン内で処理されたように「Y」アクセスドメインにおいて、イニシエータQSPECは、同様にQNRによりた処理されます。
If the reservation was successful, eventually the RESERVE request arrives at the QNR (otherwise, the QNE at which the reservation failed would have aborted the RESERVE and sent an error RESPONSE back to the QNI). If the <RII> was included in the QoS-NSLP message, the QNR generates a positive RESPONSE with QSPEC objects <QoS Reserved> and <QoS Available>. The parameters appearing in <QoS Reserved> are the same as in <QoS Desired>, with values copied from <QoS Available>. Hence, the QNR includes the following QSPEC objects in the RESPONSE message:
予約が成功した場合、最終的にRESERVE要求がQNR（そうでない場合は、予約が失敗した時QNEがRESERVEを中止されているだろうとバックQNIにエラー応答を送っ）に到着します。 <RII>のQoS-NSLPメッセージに含まれていた場合は、QNRはQSPECオブジェクト<予約済みのQoS>と<利用可能なQoS>と正の応答を生成します。 <QoSの予約>に登場するパラメータは、<利用可能なQoS>からコピーした値で、<望ましいQoS>の場合と同様です。したがって、QNRは、応答メッセージの次のQSPECオブジェクトを含みます。
<QoS Reserved> = <TMOD-1> <PHB Class> <QoS Available> = <TMOD-1> <Path Latency>
= <TMOD-1> = <TMOD-1> <PHBクラス> <利用可能なQoS> <パスレイテンシ> <QoSが予約します>
Contributors
協力者
Attila Takacs Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Takacs@ericsson.com
アッティラタカーチエリクソンリサーチエリクソンハンガリー株式会社Laborc 1、ブダペスト、ハンガリー、H-1037 Eメール：Attila.Takacs@ericsson.com
Andras Csaszar Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Andras.Csaszar@ericsson.com
アンドラーシュCsaszarエリクソンリサーチエリクソンハンガリー株式会社Laborc 1、ブダペスト、ハンガリー、H-1037 Eメール：Andras.Csaszar@ericsson.com
Authors' Addresses
著者のアドレス
Attila Bader Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Bader@ericsson.com
アッティラバーダーエリクソンリサーチエリクソンハンガリー株式会社Laborc 1、ブダペスト、ハンガリー、H-1037 Eメール：Attila.Bader@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com
ラースWestbergエリクソン研究Torshamnsgatan 23 SE-164 80ストックホルム、スウェーデンのEメール：Lars.Westberg@ericsson.com
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@ewi.utwente.nl
トウェンテの私書箱のゲオルギオスカラGiannis大学g.karagiannis@ewi.utwente.nl：217 7500 AEエンスヘーデをボックス、ネザーメールランズ
Cornelia Kappler ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
コルネリアKappler CK技術の概念ベルリン、ドイツのEメール：cornelia.kappler@cktecc.de
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポーフィンランドメール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.priv.at
Tom Phelan Sonus Networks 250 Apollo Dr. Chelmsford, MA 01824 USA EMail: tphelan@sonusnet.com
トム・フェランソナス・ネットワーク250アポロ博士チェルムズフォード、MA 01824 USA Eメール：tphelan@sonusnet.com