[要約] RFC 5977は、Diffservにおけるリソース管理のためのNSIS品質サービスモデルであり、要約すると以下のようになります。1. RFC 5977は、Diffservネットワークでのリソース管理のためのNSIS品質サービスモデルを提供します。 2. このRFCの目的は、ネットワーク内のリソースの効率的な管理と品質サービスの提供を可能にすることです。 3. RMD-QOSMは、ネットワーク内のリソースの予約、制御、および監視を行うためのプロトコルと手順を定義しています。
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
RMD-QOSM：diffservのリソース管理のためのNSISサービス品質モデル
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ネットワークの外部のデバイスは、RMDネットワークのエッジノードへのリクエストを予約リクエストに信号することができます。RMD Ingress Edgeノードは、流入フローをトラフィッククラスに分類し、各フローの出力エッジノードへのデータパスに沿った対応するトラフィッククラスのリソース要求を信号します。出力ノードは、元の要求を再構成し、最終目的地に向かってデータパスに沿って転送し続けます。さらに、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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5977.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
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.
このドキュメントでは、DiffServ（RMD）フレームワーク（[RMD1]、[RMD2]、[RMD3]、および[RMD4]）でリソース管理を使用するネットワークのシグナリング（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.
これらは、QOS-NSLPと組み合わせて使用され、RMDネットワークでQoSシグナリングサービスを提供します。図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シグナル伝達プロトコルの影響を最小限に抑える必要があります。このようなネットワークシナリオでは、通信パスで使用される各ネットワークノードのパフォーマンスは、エンドツーエンドのパフォーマンスに影響を与えます。そのため、インテリアノードのパフォーマンスを最適化することにより、通信パスのエンドツーエンドのパフォーマンスを改善できます。この最適化に寄与する要因の1つは、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.
このようなネットワークシナリオによって課されるもう1つの要件は、ネットワークで深刻な輻輳状況が発生するたびに、使用される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.
RMDネットワークに内部的には、RMD-QOSMとQOS-NSLP [RFC5974]とともに、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の用語の後、セクション3のRMDとRMD-QOSMの概要を説明します。このドキュメントは、いくつかのRMD-QOSM/ QOS-NSLPシグナリングスキームを指定します。特に、セクション3.2.3では、各RMD-QOSM/QOS-NSLPシグナル伝達スキームの仕様に使用されるセクションの組み合わせを特定します。セクション4では、QoS NSISエンティティ（QNES）の役割、QSPECの定義、QSPECジェネリックパラメーターのRMD-QOSMパラメーターへのマッピング、QNESの状態管理、操作および操作および操作および一連のイベント。セクション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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
エッジノード：ある管理ドメインの境界上のQOS-NSLPノードは、1つのNSISドメインを別のNSISドメインまたは非NSISドメインのノードに接続します。
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-AWAREノード：NSISシグナル伝達とRMD-QOSM操作を認識しているノード（重度のうっ血検出や差別化されたサービスコードポイント（DSCP）マーキングなど）。
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-Unawareノード：NSISシグナル伝達を認識していないが、重度の輻輳検出やDSCPマーキングなどのRMD-QOSM操作を認識しているノード。
Ingress node: an Edge node in its role in handling the traffic as it enters the NSIS domain.
Ingressノード：NSISドメインに入るときのトラフィックの処理における役割のエッジノード。
Egress node: an Edge node in its role in handling the traffic as it leaves the NSIS domain.
出力ノード：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）に関連するトラフィックがリンクに割り当てられた容量（または特定の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ヘッダーの差別化されたサービス（DS）フィールドを使用して、メインビルディングブロックとしてホップごとの動作（PHB）を使用して達成されます。パケットは、メッセージヘッダーの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で説明されています。2つの主要な基本的な入場制御モードがサポートされています。予約ベースと測定ベースの入場制御は、深刻な輻輳処理ソリューションと組み合わせて使用できます。故障したリンク/ノードによってサポートされているトラフィックが再ルーティングされ、このリンク/ノードによって処理される必要があるため、リンク/ノードがひどく混雑するという状況では、深刻な輻輳処理ソリューションが使用されます。さらに、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つの重要な特徴は、エッジでサポートされているドメイン内セッションは、フローごとのセッションまたは総合セッションのいずれかであることです。フローごとのドメイン内セッションの場合、維持されているフローごとのドメイン内領域は、同じエッジによってサポートされているフローごとのエンドツーエンド状態に1対1の依存関係を持っています。総合的なセッションの場合、維持されている総合的な状態は、同じエッジによってサポートされているフローごとのエンドツーエンドの状態と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つの予約状態のみを維持しています。Ingress Edgeノードは、個々のフロー要求をPHBトラフィッククラスに集約し、必要に応じてクラスの予約の変更を信号します。予約は、リソースユニット（または帯域幅）の観点から定量化されます。これらのリソースは、PHBごとに動的に要求され、侵入ノードから出口ノードまでの通信パスのすべてのノードでオンデマンドで予約されています。
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に基づいたホップバイホップ入場制御。リクエストを認める内部ノードの2つの可能な操作モードがあります。1つのモードは、ドメイン内のリソースが照会されたステートレスまたは測定ベースのモードです。別の動作モードは、ドメイン内のリソースが予約されている縮小状態の予約または予約ベースのモードです。
* a method to forward the original requests across the domain up to the Egress node and beyond.
* ドメインを介して元の要求を出力ノードおよびそれ以降に転送する方法。
* 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のプロトコルモデルを図2に示します。図は、QoS NSISイニシエーター（QNI）およびQoS NSISレシーバー（QNR）ノードを示しています。リクエスト。また、RMDドメインのイングレスノードと出口ノードであるQNEノード（QNE IngressおよびQNE Egress）、および内部ノード（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認識ノードです。ただし、プロービングに基づいた輻輳通知機能が使用されるシナリオでは、内部ノードはNSIに気付いていません。エッジノードはQOS-NSLPおよびNTLP状態を保存および維持するため、ステートフルノードです。NSISが認識しているインテリアノードは、NTLPステートレスです。さらに、それらは、QOS-NSLPステートレス（NSIS測定ベースの動作の場合）または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に不名誉なノードの一部は、データパス上のトラフィック渋滞レベルを測定するために使用される場合があります。これらの測定値は、調査操作および/または重度の混雑操作に基づいて、混雑制御でRMD-QOSMによって使用できます（セクション4.6.1.6を参照）。
|------| |-------| |------| |------|
| 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
St.ful：Stateful、St.Less：Stateless St.less Red.st。：ステートレスまたは縮小状態
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シグナル伝達を図3に示します。シグナル伝達シナリオは、[RFC5974]で定義されたQOS-NSLP処理ルールを使用して、QOSを介して送信されたリソース管理関数（RMF）トリガーと組み合わせて達成されます。[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を参照）。したがって、RMDドメイン内で2つの異なる予備メッセージが使用されます。フローごとのエンドツーエンドの予約に関連付けられており、RMDドメインのエッジによって使用される1つの予備メッセージと、RMDドメイン内の縮小状態の予約に関連するもの。
A RESERVE message is created by a QNI with an Initiator QSPEC describing the reservation and forwarded along the path towards the QNR.
予約メッセージは、予約を記述し、QNRに向かってパスに沿って転送されるイニシエーターQSPECを備えたQNIによって作成されます。
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.
元の予備メッセージがイングレスノードに到着すると、メッセージの初期QSPEC（通常はイニシエーターQSPEC）に基づいてRMD-QSPECが構築されます。RMD-QSPECは、QNRに向かって内部ノードを介してドメイン内の独立した予備のメッセージで送信されます。このドメイン内リザーブメッセージは、GISTデータグラムシグナリングメカニズムを使用します。RMD-QOSMは、GISTデータグラムモードを使用する必要があることを直接指定できないことに注意してください。ただし、これは、信頼性が低い、低レベルのセキュリティやローカルポリシーの使用など、GIST API Transfer-Attributesを使用することで通知できます。
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.
一方、元の予備メッセージは、NTLPの信頼できる輸送モードを使用して、QNRへのパス上の出口ノードに送信されます。データパス上の各QOS-NSLPノードは、ドメイン内予約メッセージを処理し、リソースの可用性を予約ベースまたは測定ベースの方法でチェックします。
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.
メッセージが出口ノードに到達し、各インテリアノードで予約が成功すると、ドメイン内（ローカル）応答がイングレスノードに送信され、元の（エンドツーエンド）予備のメッセージが次のものに転送されますドメイン。出力ノードが下流端から応答メッセージを受信すると、イングレスノードに直接転送されます。
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.
中間ノードが新しいリクエストに対応できない場合、メッセージに1つのビットをマークすることでこれを示し、出口ノードに到達するまでメッセージの転送を続けます。出力ノードから、ドメイン内応答 'と元の応答メッセージがイングレスノードに直接送信されます。
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.
結果として、Stateless/Reductent-Stateドメインでは、送信者が開始した予約のみを実行でき、Flow NTLPまたはQOS-NSLP状態を要約やRedument Refreshesなどの機能を必要とする機能は使用できません。フローごとの識別が必要な場合、つまり予約されたリソースのフロー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希望>パラメーターの帯域幅情報を運ぶRMD-QOSMによってサポートできます（[RFC5975]を参照）。（保証された転送）AFのような機能の完全なセットには、2つのトークンバケットで指定された情報が必要です。RMD-QOSMは2つのトークンバケットの使用をサポートしていないため、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 Ingressが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を使用することに関する非常に重要な考慮事項は、1つのRMDドメイン内で、次のRMD-QOSMスキームの1つだけが一度に使用できることです。したがって、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 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.
ただし、この仕様をサポートするすべてのRMD QNESは、「フローごとのRMD予約ベース」と、比例データパケットマーキングによる「重度の渋滞処理」スキームの組み合わせをサポートする必要があります。RMD QNESがより多くのRMD-QOSMスキームをサポートしている場合、そのRMDドメインの演算子は、1つのドメイン内のすべてのQNEエッジノードを事前に設定する必要があります。「PDRコンテナ」（セクション4.1.3）は常に同じ値を使用します。これにより、1つのRMDドメイン内で、以下のRMD-QOSMスキームの1つのみが一度に使用されます。
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を参照）を使用して、入院制御メカニズムを使用して解決されます（セクション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]を参照してください。これは、RMD-QOSMメッセージが断片化なしで輸送されるようにMTUを設計する必要があることを意味します。さらに、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].
Qモードで送信されたクエリメッセージとデータメッセージに対して、GISTコンテキストフリーフラグ（C-FLAG）を設定する必要があるように、RMDドメインを構成する必要があります。[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を参照）。さらに、内部ノードは拡散していると見なされますが、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-QOSMリフレッシュによる重度の輻輳処理」手順と組み合わせて、「流量ごとのRMD予約ベース」（セクション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-QOSMリフレッシュによる重度の混雑処理」手順と組み合わせて、「群ごとのRMD予約ベース」と組み合わせて（セクション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について詳しく説明します。特に、StatelessおよびRedement-State QNESの役割、RMD-QOSM QSPECオブジェクト、RMD-QOSM QOS-NSLPメッセージの形式、およびさまざまなプロトコル操作でQSPECが処理および使用される方法を定義します。
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
* メッセージシーケンス= 0：送信者開始 *オブジェクトの組み合わせ= 0：<Qos希望>予約のために<qos reserved>応答
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:
RMD-QOSMで使用される<QSPECバージョン>は、デフォルトバージョン、つまり「0」、[RFC5975]を参照してください。RMD-QOSMで使用される<QSPECタイプ>値は[RFC5975]で指定され、「2」に等しくなります。<トラフィックハンドリングディレクティブ>には、次のフィールドが含まれています。
<Traffic Handling Directives> = <PHR container> <PDR container>
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.
ホップごとの予約容器（容器）とドメインごとの予約容器（PDRコンテナ）は、それぞれセクション4.1.2と4.1.3に指定されています。<fr container>には、ドメイン内通信と予約のためのトラフィック処理指令が含まれています。<PDRコンテナ>には、エッジ間通信に必要な追加のトラフィック処理指令が含まれています。<fr container>および<pdr container>で使用されるパラメーター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 container>は、エッジとインテリアノードによって使用および処理されます。<PDRコンテナ>フィールドは、エッジノードによってのみ処理されます。
The RESERVE message contains only the <QoS Desired> object [RFC5975]. The <QoS Reserved> object is carried by the RESPONSE message.
予備のメッセージには、<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>
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機能で使用されるContainer Frで使用されるパラメーターについて説明します。
<PHR container> = <O> <K> <S> <M>, <Admitted Hops>, <B> <Hop_U> <Time
Lag> <SCH> <Max Admitted Hops>
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>.
容器式のビット形式は、図6に示すことができます。図6 <hop_u>は<u>として表されていることに注意してください。さらに、図6では、<Max Admided Hops>は<Max Adm Hops>として表されています。
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：容器式
Parameter ID: 12-bit field, indicating the PHR type: PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.
パラメーターID：12ビットフィールド、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（Ingress）とQNE（Egress）ノードの間の通信パスにあるすべてのノードで、トラフィッククラスの予約ソフト状態を更新し、以前のリソース予約要求に従って、前のリソース予約要求に従って処理されたリソースのリクエストに従って、更新期間。
<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ビット。ルートの変更の場合、リフレッシュリザーブメッセージは新しいデータパスに従っているため、リソースがリクエストされます。リソースが新しいトラフィックに対応するのに十分でない場合、深刻な輻輳が発生します。重度の混雑した内部ノードは、<s>ビットを設定することにより、混雑についてEdge 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ビットフィールド。<Admitted Hops>は、予約が成功したRMDドメインのホップ数をカウントします。<Hop_u>ビットが設定されていない限り、予備のメッセージがドメインに入ると、各インテリアQNEによってインクリメントをインクリメントする必要がある場合、<Admitted Hops>は「0」に設定されます。ただし、予約に到達するのに十分なリソースがないQNEが到達すると、<m>ビットが設定され、<Hop_u>ビットを「1」に設定することにより、<Admided Hops>値が凍結されます。RMD部分リリース手順中に<MAX Admided Hops>および<k>パラメーターと組み合わせた<Admided Hops>パラメーターは、セクション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 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).
<Hop_u>（nslp_hops unset）：1ビット。QNE（INGRESS）ノードは、<Hop_u>パラメーターを0に設定する必要があります。このパラメーターは、ノードが<Admided Hops>値を増加させない場合、ノードによって「1」に設定する必要があります。これは、RMD-QOSM予約ベースのノードが予約リクエストを認めていない場合です。<Hop_u>が「1」に設定されている場合、<Admitted Hops>は変更しないでください。このフラグは、<Admitted Hops>フラグと組み合わせて、予約要求を正常に処理する最後のノードを見つけるために使用されることに注意してください（セクション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.
<タイムラグ>：「T_LAG」パラメーターの比率を表します。これは、最後に送信された「PHR_REFRESH_UPDATE」制御情報コンテナの出発時間と「PHR_RELEASE_REQUEST」制御情報コンテナの出発時間と、更新期間の長さ、「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」に設定すると、裂け目の予備によって運ばれるリソース/帯域幅をリリースしてはならず、非引習保護区によって運ばれるリソース/帯域幅を予約/リフレッシュしてはならないことを示します。詳細については、セクション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".
<Max Admitted Hops>：8ビット。<fr container>フィールドによって運ばれた<入学ホップ>の値は、「phrresource_request」を認めたり処理したRMD予約ベースのノードを識別するために使用されます。
<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ビット。RMDドメイン内で使用する6つのRMD-QOSMシナリオのどれを指定するために使用される<Sch>値。RMDドメインの演算子は、1つのドメイン内のすべてのQNEエッジノードを事前に設定する必要があります。これにより、「fr container」に含まれる<sch>フィールドが常に同じ値を使用します。RMD-QOSMスキームは一度に使用できます。すべてのQNEインテリアノードは、他のフルコンテナペイロードフィールドを処理する前に、このフィールドを解釈する必要があります。現在定義されている<sch>値は次のとおりです。
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
o 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予約ベースを1つの総計」と組み合わせて必要です。
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予約ベースを1つの総計」と組み合わせて行う必要があります。
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.
このセクションでは、Edgeノードで利用可能な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>]
In Figure 7, note that <Max Admitted Hops> is represented as <Max Adm Hops>.
図7では、<max admited hops>は<max adm hops>として表されていることに注意してください。
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：12ビットフィールド<PDRコンテナ>フィールドのタイプを識別します。
"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_RESERATION_REQUEST」（パラメーターID = 20）：QNE（Egress）ノードの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（出口）ノードに送信されて、必要に応じてQOS-NSLPドメインごとの予約状態（Egress）ノード。
"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（Ingress）ノードによって生成および送信されたQNE（Egress）ノードに送信され、ドメインごとの予約状態を明示的にリリースします。
"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_RESERATIAN_REPORT"（パラメーターID = 23）：QNE（Egress）ノードによってQNE（gress）ノードに生成および送信され、「phr_resource_request」と「pdr_reservation_request」と報告します。入院または拒否されました。
"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）が生成され、QNE（Egress）ノードによって必要な場合に必要な場合、QNE（Ingress）ノードに送信され、「PhR_REFRESH_UPDATE」トラフィックハンドリングディレクティブフィールドが受信され、処理されたと報告します。
"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）は、QNE（Egress）ノードによって必要な場合にQNE（ingress）ノードに生成および送信され、「phr_release_request」と「PDR_RELEASE_REQUEST」トラフィックハンドリングディレクティブフィールドが受信され、処理されています。
"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（Egress）ノードによってQNE（Ingress）ノードに生成および送信され、混雑通知に使用されます。
<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ビット。深刻な輻輳状況が発生したかどうかを指定します。また、<shr_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>（Marked）：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".
<Max Admitted Hops>：8ビット。<fr container>フィールドによって運ばれた<入学ホップ>の値は、「phrresource_request」を認めたり処理したRMD予約ベースのノードを識別するために使用されます。
<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を維持したときに、帯域幅を適用する帯域幅を指定します。状態とそれは通知メッセージによって運ばれます。<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シナリオのどれを指定するために使用される<Sch>値。RMDドメインの演算子は、「PDRコンテナ」に含まれる<Sch>フィールドが常に同じ値を使用するように、1つのドメイン内のすべてのQNEエッジノードを事前に設定する必要があります。RMD-QOSMスキームは一度に使用できます。すべてのQNEインテリアノードは、他の<PDRコンテナ>ペイロードフィールドを処理する前に、このフィールドを解釈する必要があります。現在定義されている<sch>値は次のとおりです。
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
o 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予約ベースを1つの総計」と組み合わせて必要です。
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予約ベースを1つの総計」と組み合わせて行う必要があります。
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エッジは、ドメイン内QOS-NSLP運用状態と予約状態の両方を維持し、QNEインテリアノードは予約状態のみを維持します。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.
この集約されたドメイン内セッションの運用状態には、バウンドセッション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- 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.
運用状態（QNE IngressおよびQNE Egress）が一方向の予約をサポートする場合、この状態は、バウンドエンドツーエンドセッションの<Session-ID>値を維持するバウンドセッションIDのリストを含める必要があります。このバウンドセッションIDに関連付けられたBinding_Codeは、コード（集約セッション）に設定されています。したがって、運用状態は、バウンドセッション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 IngressおよびQNE Egress）は、BoundSession-IDに含まれている必要があることを強調することが重要です。、バインドされたトンネル領域内（集計）セッションの<Session-ID>値。このBoundSession-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 IngressおよびQNE Egress）が双方向の留保をサポートする場合、運用状態にはバウンドセッションIDセットのリストが含まれている必要があります。各セットには、2つのバウンドセッションIDが含まれています。Boundsession-IDの1つは、バインドされたエンドツーエンドセッションの1つの<session-id>値を維持しています。このBoundSession-IDに関連付けられたBinding_Codeは、コード（集約セッション）に設定されています。別のバウンドセッションIDは、同じセットエントリ内で、双方向のバインドエンドツーエンドセッションのセッションIDを維持します。このBoundSession-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.
各セットでは、Bunding_Codeが（集約セッション）に設定された各バウンドセッションIDと、Binding_Codeセット（Bidirectional Sessions）に設定された各Boundsession-IDの間に1対1の関係が存在することに注意してください。各セットは、エンドツーエンドのセッションが集約された運用状態に結合するときに作成され、エンドツーエンドのセッションが集約された運用状態を離れると削除されます。
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 IngressおよびQNE Egress）は、2種類の境界セッションを含める必要があることを強調することが重要です。-ids。1つは、Binding_codeセットを（集約セッション）に使用しているバインドされたトンネル編成領域内セッションの<session-id>値を含める必要があるBoundsession-idです。もう1つのBoundsession-IDは、バインドされた双方向のエンドツーエンドセッションのセッションIDを維持しています。このBoundSession-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).
ポリシーを使用して、基礎となる領域間（エンドツーエンド）の予約の合計を考慮しながら、予約を頻繁に変更するよう努めることにより、特定の集約された予約に必要な帯域幅の量を維持することができます。これには、トレンド分析が必要になる場合があります。次の時間間隔で現在の集約された予約が使い果たされる可能性がある場合、イングレスルーターは必要な帯域幅を予測して要求する必要があります。Ingressルーターにはかなりの量の帯域幅が予約されているが、それを使用する確率がほとんどない場合、ポリシーは必要な帯域幅の量を予測し、過剰を解放する場合があります。凝集体を増やすか減少させるには、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で説明されているものと同様のデータ構造を含む、domainごとのdomain QoS-NSLP運用および予約状態を維持します。主な違いは、使用されているメッセージルーティング情報（MRI）およびバインドされたエンドツーエンドセッションのさまざまなタイプに関連付けられています。維持されているバウンドセッション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).
一方向の予約がサポートされている場合、このフローごとのドメイン内セッションに関連する運用状態には、バウンドセッションIDにバインドエンドツーエンドセッションの<セッションID>値が含まれている必要があります。このBoundSession-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 IngressおよびQNE Egress）には、2種類のバウンドセッションIDが含まれている必要があります。1つは、バインドされたトンネルごとのフロー内ドメインセッションの<session-id>値を維持するバウンドセッションIDです。このBoundSession-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).
もう1つのBoundsession-IDは、バインドされた双方向のエンドツーエンドセッションのセッションIDを維持しています。このBoundSession-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予約状態は、ドメイン内セッションにバインドされたエンドツーエンドセッションで要求される帯域幅の値、および優先レベルの値を維持します。
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-akeareですが、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シグナル伝達の影響を受けません。1つの州は、PHRグループに関連付けられた測定されたユーザートラフィック負荷を保存し、別の州は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エッジは、セクション4.3.1で説明されているように、同様のデータ構造を含むドメイン内QOS-NSLP運用および予約状態を維持します。
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.
この場合、エッジでサポートされるドメイン内セッションは、同じエッジによってサポートされている流量ごとのエンドツーエンド状態と1対1の関係を持つ流量あたりのセッションです。
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インテリアノードは、QOS-NSLP縮小状態ノードです。つまり、NTLP/GIST状態を保存しませんが、PHB凝集した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.
予約ベースのPHは、通信パスにあるすべてのノードに、PHBごとに1つの予約状態をインストールおよび維持します。この状態は<PHBクラス>値で識別され、現在予約されているリソースユニット（または帯域幅）の数を維持します。したがって、QNEイングレスノードは、各フローによって要求されたリソースユニットのみを信号します。これらのリソースユニットは、入院した場合、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によって開始される定期的なリフレッシュドメイン内予備メッセージを送信することで更新されます。多くの予約されたリソースユニット（つまり、帯域幅）に対応する更新メッセージが受信されない場合、集約された予約状態は、リフレッシュされていないリソースのリソースの次の更新期間に減少します。[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によって生成されるドメイン内予備のリリース/涙メッセージによって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に関連付けられているこれらの3つの異なる優先交通クラスは、このドキュメントで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 IngressとQNE Egressノードのみが特定のシグナリングメッセージを開始できます。たとえば、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で使用されるドメイン内メッセージは、NTLP/GISTデータグラムモードで動作することを目的としています（[RFC5971]を参照）。すべてのRMD-QOSM対応QOS-NSLPノードで利用可能なNSLP機能には、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.
* 信頼できないモードで動作します。これは、QOS-NSLPレイヤーからAPI転送アトリビュートを介して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ルーティング状態を作成しないでください。これは、QoS-NSLPレイヤーからAPIを介してGISTレイヤーにこの要件を渡すことで満たすことができます。ただし、ドメイン内セッションに関連付けられており、QNE出口から直接QNE侵入に直接送信されたGISTデータメッセージの通信に使用できるQNE出口とQNEのイングレスルーティング状態の間に作成する必要があります。ドメイン内セッションに関連付けられたこのタイプのルーティング状態は、次の方法で生成し、使用できます。
* 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 Ingressが最初のドメイン内予備メッセージを送信する必要がある場合、QOS-NSLPは、GIST API SendMessage Primitiveに、信頼できないセキュリティ属性を含めることにより、このメッセージを送信します。この手順を最適化するには、GISTがGISTクエリメッセージでこのNSLPメッセージを選択できるように、RMDドメインを設計する必要があります。さらに、GISTはC-FLAG（C = 1）を設定し、[RFC5971]を参照し、Qモードを使用します。各QNEインテリアノードのGIST機能はGISTクエリメッセージを受信し、RecVMessage Gist APIプリミティブを使用することにより、ドメイン内予備メッセージをQOS-NSLP機能に渡します。同時に、GIST機能はルーティング状態チェックブール波を使用して、QOS-NSLPがルーティング状態を作成する必要があるかどうかを調べます。QOS-NSLPは、このブール値を設定して、ルーティング状態を作成しないようにGISTに通知し、変更されたQOS-NSLPペイロードをさらに下流に転送するように設定します。これには、変更されたドメイン内リザーブメッセージが含まれます。ドメイン内保護区は、同じように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機能がGIST Recvmessage Primitiveを介してドメイン内予備メッセージをQOS-NSLPに渡すと同じ瞬間に、QOS-NSLPがルーティング状態チェックブールを設定してルーティング状態を作成するように設定します。GISTは、通常のGIST手順を使用してルーティング状態を作成します。このフェーズの後、QNE IngressとQNE Egressは、特定のセッションで、QNE IngressからQNE Egress、およびQNE EgressからQNE Ingressに直接トラフィックをルーティングできるルーティング状態を持っています。QNE出口のルーティング状態は、QOS-NSLPとGISTで使用してドメイン内応答を送信するか、GISTデータメッセージを使用してQNEイングレスにドメイン内通知を直接通知できます。このルーティング状態は、通常のGIST手順を使用して更新されていることに注意してください。上記の説明では、qne侵入がGISTクエリメッセージの初期予備（NSLP）メッセージを豚にぶら下げていると考えられていることに注意してください。このNSLP（初期予約）メッセージのピギーバックがGISTクエリメッセージで不可能な場合、QNE Ingressノードによって送信されたGISTクエリメッセージには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出口のルーティング状態が開始されることを通知された後、初期予約ではないドメイン内予備メッセージを送信する状況と同様の手順を使用して、初期予約メッセージを送信する必要があります。次の弾丸を参照してください。この手順は効率的ではないため、RMDドメインは、QNE侵入で処理されるGISTプロトコルレイヤーが、GISTクエリメッセージの初期リザーブ（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 Ingressが初期予約ではないドメイン内予備メッセージを送信する必要がある場合、QOS-NSLPは、GIST API SendMessage Primitiveに、データグラムモードの使用が暗示されるような属性を含めることにより、このメッセージを送信します。信頼できない属性。さらに、ローカルポリシー属性は、QNEイングレスにルーティング状態がある場合でも、GISTがQモードでドメイン内予備メッセージを送信するように設定されています。このようにして、GIST機能はローカルポリシーを使用して、このセッションにルーティング状態がある場合でも、GISTデータメッセージでそれをピギーバックし、Qモードで送信することにより、ドメイン内予備メッセージを送信します。ドメイン内リザーブメッセージは、QNEインテリアノードによって転送および処理されたGISTデータメッセージにピギーバックされています。
The transport of the original (end-to-end) RESERVE message is accomplished in the following way:
元の（エンドツーエンド）予備のメッセージの輸送は、次の方法で達成されます。
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 Ingressでは、元の（エンドツーエンド）予備のメッセージは転送されますが、ステートレスまたは縮小状態ノードによって無視されます。図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]を参照）。これは、エンドツーエンドの予備メッセージをマークすることによって達成されます。つまり、QOS-NSLPデフォルトNSLPID値を別のNSLPID事前定義値に変更します。
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].
QOS_NSLPデフォルトNSLPID値をNSLPID事前定義値に変更することにより、マーキングは、イングレスによって達成する必要があります。このようにして、出口は、QOS-NSLPデフォルトNSLPID値を元の（エンドツーエンド）予備メッセージに再割り当てすることにより、このマーキングプロセスを停止する必要があります。これらのNSLPID値の割り当てはQOS-NSLPの問題であり、IANA [RFC5974]を介して達成する必要があることに注意してください。
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.
主に、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.
ドメイン内予約メッセージは、クエリ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.66.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は、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モデルに適用されることに注意してください。ただし、QSモデルが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-QOSMリフレッシュによる深刻な輻輳処理」手順と組み合わせて、「流量あたりRMD予約ベース」。
* "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-QOSMリフレッシュによる重度の輻輳処理」手順と組み合わせて、「群ごとのRMD予約ベース」と組み合わせて。
* "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-QOSM機能がRMD修正手順を達成する可能性があります（セクション4.6.1.4を参照）。RMD-QOSMのQNE実装は、データパケットよりも優先度が高いQOS-NSLPシグナリングメッセージを処理することをお勧めします。これは、[RFC5974]のセクション3.3.4で説明されているように達成でき、[RFC5974]で説明されているQOS-NSLP-RMF APIを介して要求できます。このセクションで説明するシグナル伝達シナリオは、[RFC5974]で定義された[RFC5974]で定義されたQOS-NSLP処理ルールを使用して、[RFC5974]で説明されているQOS-NSLP-RMF APIを介して送信されたRMFトリガーと組み合わせて達成されます。
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によれば、「フローごとのRMD予約ベース」のみが、「比例データパケットマーキングによる重度の渋滞処理」と組み合わせて、1つのRMDドメイン内で実装する必要があることが指定されています。ただし、この仕様をサポートするすべてのRMD QNESは、「フローごとのRMD予約ベース」の組み合わせをサポートする必要があります。RMD QNESがより多くのRMD-QOSMスキームをサポートしている場合、そのRMDドメインの演算子は、1つのドメイン内のすべてのQNEエッジノードを事前に設定する必要があります。「PDRコンテナ」（セクション4.1.3）は常に同じ値を使用します。これにより、1つのRMDドメイン内で、以下のRMD-QOSMスキームの1つのみが一度に使用されます。
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ノードは、他のすべての「コンテナ」ペイロードフィールドを処理する前に、「fr container」に含まれる<sch>フィールドを読み取り、解釈する必要があります。さらに、RMDドメインのボーダーにあるすべてのQNEエッジノードは、他のすべての<PDRコンテナ>ペイロードフィールドを処理する前に、「PDRコンテナ」に含まれる<Sch>フィールドを読み取り、解釈する必要があります。
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は最初の予備メッセージを生成し、通常どおりNTLPによって転送されます[RFC5971]。
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.
エンドツーエンドの予約リクエスト（リザーブ）がイングレスノード（QNE）に到着すると（図8を参照）、エンドツーエンドQoSモデルに基づいて処理されます。その後、<tmod-1>、<phb class>、および<adizent priority>の組み合わせは、初期qspecの<qos希望>オブジェクトから導出されます。
The QNE Ingress MUST maintain information about the smallest MTU that is supported on the links within the RMD domain.
QNE Ingressは、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.
エンドツーエンドQoSモデル<TMOD-1>パラメーターに含まれる<最大パケットサイズ1（MPS）>値は、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]は、バイトで測定された整数であり、最大パケットサイズ（MP）以下でなければなりません。したがって、（m）ができる最大値は（MPS）です。[PART94]および[TACH99]は、トークンバケットパラメーターの値を計算する方法を説明しています。議員が知られています。
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>.
<ピークデータレート1（P）>エンドツーエンドQOSモデルの値<TMOD-1>パラメーターは、<ピークデータレート1の<ピークデータレート1（P）>値にコピーされます。（P）>ローカルRMD-QSPEC <TMOD-1>の値。
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は、ドメイン内RMD-QSPECによって運ばれる<PHBクラス>パラメーターを設定するのに適しています（[RFC3175を参照]）。
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が<Antisment Priority>パラメーターを搭載していない場合、RMD-QSPECの<Antisment Priority>パラメーターは入力されません。初期QSPECが<Antisment Priority>パラメーターを運ばないが、他の優先度パラメーターを搭載している場合、エッジは、ステートフルノードであるため、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 <QOS予約>オブジェクトに関連付けられている<e>フラグと、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられている<e>フラグが設定されています。さらに、<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.
リクエストがローカルで満たされた場合（セクション4.3を参照）、Ingress QNEノードは2つの予備メッセージを生成します。1つのドメインと1つのエンドツーエンドの予備メッセージです。ただし、集約されたQOS-NSLP運用状態と予約状態がQNEイングレスによって使用される場合、ドメイン内予備のメッセージの生成は、集約された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インテリアノードが特定のセッションに関連付けられた再送信予定メッセージと別のセッションに属する初期予約メッセージを区別できないという事実に関連しています。ただし、QNE Ingressは、上流の障害状況を報告する必要があります。QNE Ingressが（ドメイン内またはエンドツーエンド）リザーブを<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:
QNE Ingressが<RII>オブジェクトセットを使用してドメイン内またはエンドツーエンドの予備メッセージを送信し、QOSNSLP_REQUEST_RETRY期間が期限切れになった後、それぞれ関連するドメイン内またはエンドツーエンドの応答を受信できない場合、予約が失敗したと考えています。この場合、QNE Ingressは、とりわけ<情報スペック>オブジェクトを含むエンドツーエンドの応答メッセージを生成する必要があります。この<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 Ingressは[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.
この時点で、必要な拘束力のある手順に従って、ドメイン内およびエンドツーエンドの動作状態を開始または変更する必要があります。ドメイン内およびエンドツーエンドのQOS-NSLP運用状態で境界セッションIDが開始および維持される方法は、セクション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.
これらの2つのメッセージは、次の方法で結合されます。エンドツーエンドのリザーブには、バウンドセッション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].
これに加えて、ドメイン内およびエンドツーエンドの予備メッセージは、[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>オブジェクトはドメイン内リザーブメッセージに含まれており、そのバウンド<Bound-MSG-ID>オブジェクトはエンドツーエンドの予備メッセージによって運ばれます。さらに、<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 Ingressは[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.
ドメイン内リザーブメッセージは、上記の（ローカルNTLP）セッションIDに関連付けられています。このメッセージのIPソースとIP宛先アドレスの選択は、異なるドメイン（エンドツーエンド）の流れがQNE Ingressノードによってどのように集約されるかによって異なります（セクション4.3.1を参照）。セクション4.3.1で説明されているように、QNEエッジは、（ローカルNTLP）セッションIDで識別されるRMD QOSモデルのフローごとまたは集約されたQOS-NSLP予約状態を維持します（[RFC5971を参照]）。このNTLPセッションIDは、エンドツーエンドの予備メッセージに関連付けられたセッションIDとは異なることに注意してください。
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宛先アドレスに等しくなければなりません。ドメイン内予約メッセージは、NTLPデータグラムモードを使用して送信されます（セクション4.4および4.5を参照）。GIST Datagramモードは、信頼できないGIST API Transfer-Attributesを使用して選択できることに注意してください。さらに、ドメイン内保護区（RMD-QSPEC）メッセージには、container（phr_resource_request）とrmd qosm <qos desired>オブジェクトを含める必要があります。
The end-to-end RESERVE message includes the initial QSPEC and it is sent towards the Egress QNE.
エンドツーエンドのリザーブメッセージには、初期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 API Transfer-Attributesを使用して、GIST接続モードを選択できることに注意してください。
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.
エンドツーエンドの予備メッセージは、GIST転送手順を使用して転送され、内部のステートレスまたは縮小状態のQNEノードをバイパスします。図8を参照してください。バイパス手順については、セクション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 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 Ingressでは、エンドツーエンドの予備メッセージがマークされています。つまり、QOS-NSLPデフォルトNSLPID値を別の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出口に向かってエンドツーエンドの予備メッセージを送信するプロセスは同時に行われる可能性があることに注意してください。これは、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]):
（初期）ドメイン内予備メッセージはQNE Ingressによって送信されなければならず、次の値を含める必要があります（[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;
* <telplect>フラグは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で説明されているように、<refreed-period>オブジェクトの値はqne侵入ノードによって計算および設定する必要があります。
* 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で使用されるため、<パケットクラシファイア>オブジェクトの値は、パス結合ルーティングメッセージルーティングメッセージ（MRM）に関連付けられています。設定する必要があるフラグは、<t>フラグ（トラフィッククラス）です。つまり、パケットのパケット分類は、パケットのIPヘッダーに含まれる<DSCP>値に基づいています。MRIで使用される<DSCP>値は、<PHBクラス>パラメーターの値によって導出できることに注意してください。QNE Ingressは、ドメイン内セッションのQNIであることに注意してください。これにより、GIST APIを介してこの値をGISTに渡すことができます。
* 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 Resourceユニットは、<QOS希望>オブジェクトのローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート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クラス>パラメーターの値は、初期QSPECによって運ばれる<PHBクラス>パラメーターをコピーする方法を使用して定義できます。このサブセクションで上記で説明するRMD-QSPECによって運ばれた<PHBクラス>に運ばれます。
* the value of the <Parameter ID> field of the PHR container MUST be set to "17", (i.e., PHR_Resource_Request).
* <parameter id> for containerのフィールドの値は、「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.
* fr containerの<admitted Hops>パラメーターの値は、「1」に設定する必要があります。予約が成功したときに、RMD-QOSM対応ノードがRMD-QSPECを処理するたびに、<ADMITED HOPS>パラメーターが1つ増加することに注意してください。
* the value of the <Hop_U> parameter in the PHR container MUST be set to "0".
* コンテナの<Hop_u>パラメーターの値は、「0」に設定する必要があります。
* the value of the <Max Admitted Hops> is set to "0".
* <max admided hops>の値は「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が<Antisment Priority>パラメーターを携帯している場合、このパラメーターはRMD-QSPECにコピーし、ドメイン内保護区（開始）によって運ばれる必要があります。
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.
RMD-QOSMの場合、<入場優先度>パラメーターなしで確立された予約は、1の<indation Priority>値を持つ予約に相当することに注意してください。
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.
ドメイン内リザーブメッセージには<バウンドセッションID>オブジェクトが含まれていないことに注意してください。この理由は、エンドツーエンドのリザーブが、<バウンドセッション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.
QNE Egressノード（セクション4.6.1.1.3を参照）によって送信された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を参照）、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).
RMD QOSM予約は、「PDRコンテナ」によって運ばれる<m>ビットが「0」（つまり、設定されていない）に等しい場合に成功しています。
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:
さらに、<info-spec>オブジェクトは、qos-nslp仕様で定義されているように処理されます。予約が成功した場合、<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 Ingressによってエンドツーエンドのクエリが受信された場合、エンドツーエンドの予備メッセージに適用されるものとして同じバイパス手順を使用する必要があります。特に、GIST転送手順を使用して転送され、内部のステートレスまたは縮小状態のQNEノードをバイパスします。
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インテリアノードは、次のようにドメイン内予備（RMD-QSPEC）メッセージのQOS-NSLPおよびRMD-QOSMパラメーターを使用する必要があります（[RFC5974]で説明されているQOS-NSLP-RMF APIを参照）：
* the values of the <RSN>, <RII>, <PACKET-CLASSIFIER>, <REFRESH-PERIOD>, objects MUST NOT be changed.
* <rsn>、<rii>、<packet-classifier>、<lefreas-period>の値は、オブジェクトを変更してはなりません。
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>値で実行する必要があることを通知されます。この場合に設定する必要があるフラグは、<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;
* フラグは<plateg> false = 0に設定する必要があります。
* 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インテリアノード入学制御用。さらに、<Antisment Priority>パラメーターが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を参照）、現在予約されているリソースに追加されます。さらに、fr containerの<admitted Hops>パラメーターの値を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を参照）、および<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1>パラメーターの値に要求された場合、測定ベースの入場制御（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.
Engressノードによってエンドツーエンドの予備メッセージが受信されると、Domain Intra Reserve（RMD-QSPEC）メッセージの処理がRMDドメインのすべてのノードで成功した場合、QNRに向かってさらに転送されます。この場合、QNE出口は、QOS-NSLPデフォルトNSLPID値をエンドツーエンドの予備メッセージに再割り当てすることにより、QNEインテリアノードをバイパスするために使用されたマーキングプロセスを停止する必要があります（セクション4.4を参照）。さらに、ドメイン内セッションに関連付けられたcrided <boundsession-id>オブジェクトは、処理後に削除する必要があります。受信したエンドツーエンドの保護区は、RMDドメイン内でトンネルされていたことに注意してください。したがって、エンドツーエンドの予備メッセージによって運ばれるトンネル済みの初期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.
ドメイン内およびエンドツーエンドのQOS-NSLP運用状態で境界セッションIDが開始および維持される方法は、セクション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.
ドメイン内保護区（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オブジェクトがタイプ1または2のオブジェクトの組み合わせを使用した場合、<QOS利用可能>が入力され、ドメイン内予備（RMD-QSPEC）がRMDドメインのすべてのノードで成功していないことを考慮する必要があります。<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- 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:
さらに、QNE出口がドメインごとのQOS-NSLP動作状態を使用する場合（セクション4.3.2および4.3.3を参照）、QNE出口は[RFC5974]で説明されているメッセージバインディング手順をサポートする必要があることに注意してください。エンドトゥエンドリザーブとドメイン内保護区（RMD-QSPEC）メッセージの到着を同期するために使用されます。[RFC5974]で説明されているセクション5.7およびQOS-NSLP-RMF APIを参照してください。ドメイン内リザーブメッセージには<MSG-ID>オブジェクトが搭載されており、そのバインドエンドツーエンドリザーブメッセージには<Bound-MSG-ID>オブジェクトが含まれていることに注意してください。これらのオブジェクトは両方とも、<メッセージ_binding_type>フラグを「1」の値に設定します。MSGIDWAITタイマーによって定義された時間中にこれら2つのメッセージが届かない場合、予約は失敗したと見なされます。タイマーを事前に設定する必要があり、RMDドメインで同じ値が必要であることに注意してください。この場合、エンドツーエンドの応答メッセージは、[RFC5974]で説明されているQOS-NSLP-RMF APIを参照して、次の<情報>値でQNEイングレスに向けて送信されます。
Error class: Transient Failure Error code: Mismatch synchronization between end-to-end RESERVE and intra-domain 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.
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 Egressノードは[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.
エンドツーエンドの予備メッセージは、[RFC5974]および[RFC5975]の仕様に従って、さらに上流に生成/転送されます。さらに、エンドツーエンドリザーブメッセージの<b>（break）qos-nslpフラグを設定しないでください。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出口は、ドメイン内応答（RMD-QSPEC）メッセージを生成する必要があります。ドメイン内応答（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]):
ドメイン内応答メッセージによって運ばれる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.
* ドメイン内リザーブメッセージによって運ばれる<rii>オブジェクトは、セクション4.6.1.1.1を参照して、ドメイン内応答メッセージでコピーして携帯する必要があります。
* 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_RESERAVENT_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>フィールドの値は、関連するドメイン内保護区（RMD-QSPEC）メッセージによって運ばれた容器の<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.
ドメイン内セッションとエンドツーエンドセッションの間のバインディングが（集約されたセッション）であるバインディング_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 Egressがエンドツーエンドの応答メッセージを受信した場合、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インテリアノードをバイパスするために使用されたマーキングプロセスを停止する必要があることに注意してください。これは、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 Ingress、QNEインテリア、およびQNE出口ノードは、セクション4.6.1.1で指定されているように、エンドツーエンドリザーブメッセージとドメイン内保護区（RMD-QSPEC）メッセージを同様の方法で転送します。失敗した操作と操作の成功との主な違いは、QNEノードの1つがリクエストを認めないことです。たとえば、リソースの不足により。これはまた、QNEエッジノードがQNRノードにエンドツーエンドの予備メッセージを転送してはならないことを意味します。
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).
記載されている機能は、RMD予約ベースの方法（セクション4.3.1および4.3.2を参照）およびNSIS測定ベースの入場制御方法（セクション4.3.2を参照）に適用されることに注意してください。
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-QOSM機能が達成される場合があります（セクション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].
エンドツーエンドの予備メッセージがQNEイングレスに到着し、（1）エンドツーエンドQoSモデルに含まれる「最大パケットサイズ1（MPS）」がこの最小よりも大きい場合の場合RMDドメイン内のMTU値または（2）利用可能なリソースはありません。QNEINGRESSは、このエンドツーエンドの予備メッセージを拒否し、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.
イングレスノード（セクション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).
ドメイン内応答メッセージがQNE出口によって送信されたQNE Ingressノードによって受信されると（セクション4.6.1.2.3を参照）、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インテリアノードで認められない場合、コンテナの<HOP_U>および<M>パラメーターを「1」に設定する必要があります。<入学ホップ>カウンターを増やしてはなりません。さらに、<max admided hops>カウンターの値は、<admided hops>値に等しく設定する必要があります。
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.
さらに、QSPEC <QOS希望>オブジェクトに関連付けられた<e>フラグと、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられた<e>フラグを設定する必要があります。RMD測定ベースのシナリオの場合、fr containerの<m>パラメーターを「1」に設定する必要があります。さらに、QSPEC <QOS希望>オブジェクトに関連付けられた<e>フラグと、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられた<e>フラグを設定する必要があります。<m>フラグは、ローカルRMD-QSPEC <TMOD-1>パラメーターで使用される<e>フラグと同様の方法で設定されているように見えることに注意してください。ただし、QNEによって2つのフラグが処理される方法は異なります。
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>フラグセットとfr containerタイプ「phr_resource_request」を備えたrmd-qspec <tmod-1>パラメーターを受信した場合、<m>パラメーターは「1」に設定されています。fr container "およびrmd-qosm <qos desired>オブジェクト）を処理してはなりません。さらに、「fr container」に含まれ、予備のメッセージによって運ばれる<k>パラメーターが「1」に設定されている場合、この「fr container」とrmd-qosm <qos desired>オブジェクト）処理。
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予約ベース（セクション4.3.3）およびRMD NSIS測定ベースのシナリオ（セクション4.3.2）では、<m>マークされたドメインリザーブ（RMD-QSPEC）がQNE Egressノードによって受信される場合（参照図9）、ドメイン内保護区（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.
さらに、初期QSPECオブジェクト（エンドツーエンドQoSモデルで使用）が使用可能なタイプ1または2のオブジェクトの組み合わせを使用した場合、<QOSが利用可能>が入力され、ドメイン内予備（RMD-QSPEC）はそうではありませんでしたRMDドメインのすべてのノード、つまりドメイン内リザーブ（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 EgressがドメインごとのQOS-NSLP動作状態を使用する場合（セクション4.3.2および4.3.3を参照）、QNE Egressノードは、そのために送信する必要があるエンドツーエンドの応答メッセージを生成する必要があります。以前のステートフル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.
このエンドツーエンドの応答メッセージと同じセッションに属するエンドツーエンドの予備メッセージによって実行された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予約>オブジェクトに含まれるパラメーターは、関連するエンドツーエンドリザーブメッセージに含まれる初期<QOS希望>値からコピーされます。QSPEC <QOS予約>オブジェクトに関連付けられている<e>フラグと、エンドツーエンド応答に含まれる<tmod-1>パラメーターに関連付けられた<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ホップに送信する必要があるドメイン内応答メッセージを生成する必要があります。
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
図9：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_RESERAVENT_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;
* 受信した<m>マーク付きドメインリザーブ（RMD-QSPEC）に含まれる<max admided hops> containerのパラメーターの値は、pdrコンテナの<max admided hops>パラメーターに含める必要があります。
* 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測定ベースの方法の場合、RMDドメインのQOS-NSLP予約状態のセクション4.3.2を参照してください。したがって、この方法は通常、ドメイン内の更新手順を使用しません。
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エッジがドメイン内リフレッシュ手順を実行するように構成され、すべてのQNEインテリアノードが測定ベースの最適化スキームを実行するように構成されている場合にのみ、RMDドメインに適用できます。
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を参照）、更新手順は非常に似ています。予備のメッセージがソフトステートタイムアウト期間内に到着した場合、対応するリソースユニットの数は削除されません。ただし、ドメイン内およびエンドツーエンド（更新）リザーブメッセージの送信は、必ずしも同期されるわけではありません。さらに、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ノードは、更新期間/タイマーで定義されたいつでもドメイン内（REFRESH）リザーブ（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).
RMDトラフィッククラスの更新期間は、すべてのQNEエッジおよびQNEインテリアノードで等しく、エンドツーエンドリザーブで使用されるQNEイングレスノードの更新期間よりも小さく（デフォルト：2倍小さい）する必要があることに注意してください。メッセージ。ドメイン内保護区（RMD-QSPEC）メッセージには、RMD-QOSM <QOS desired>と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）>フィールドに含める必要があります。ローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールド値は、異なるドメイン（エンドツーエンド）の流れがQNE Ingressノード（例：、集約された流れのすべてのPHRが要求されたリソースの合計）;セクション4.3.1を参照してください。QOS-NSLP集約がQNE Ingressノードによって達成されない場合、ローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>値は<ピークデータレート1に等しくなければなりません（p）>ローカルRMD-QSPEC <TMOD-1>関連する新しい（初期）ドメイン内保護区（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".
* <fr container>のコンテナフィールドの値は、「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:
ドメイン内応答（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に向かって送信されるエラーエンドツーエンドの応答メッセージ。
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.
ドメイン内保護区（RMD-QSPEC）メッセージは、QNEインテリアノードによって受信および処理されます。A <PhR_REFRESH_UPDATE>フィールドを受信するQNEエッジまたはQNEインテリアノードは、トラフィッククラスの状態（PHB）を識別する必要があります（<PHBクラス>パラメーターを使用）。このリフレッシュドメインリザーブ（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".
* <ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1> RMD-QOSM <QOS希望>のパラメーターは、QNEインテリアノードでRMDトラフィッククラスの状態を更新するために使用されます。これらのリソース（<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1>の値に含まれる）は、PHBごとに現在予約されているリソースに追加されるため、それらはトラフィックごとのクラス（PHB）予約状態（セクション4.3.1および4.3.3を参照）。更新手順を満たすことができない場合、コンテナによって運ばれる<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.
* さらに、<Qos希望>オブジェクトに関連付けられた<e>フラグと、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられた<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_REFRESH_UPDATE」の任意のフロントコンテナ、およびそれに関連するローカル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).
ドメイン内保護区（RMD-QSPEC）メッセージは、QNE出口ノードによって受信および処理されます。新しいドメイン内応答（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ノード、つまり以前のStateful Hopに送信する必要があります。（更新）ドメイン内応答（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>オブジェクトの値は、標準のQoS-NSLPプロトコル関数によって設定されています。[RFC5974]を参照してください。
* 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".
このドメイン内応答と同じセッションに属するドメイン内保護区によって運ばれたRMD-QSPECは、ドメイン内応答メッセージに含まれています。QSPEC <QOS予約>オブジェクトに含まれるパラメーターは、元の<QOS希望>値からコピーされます。予約が失敗した場合、QSPEC <QOS予約>オブジェクトに関連付けられている<e>フラグとローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられたフラグが設定されます。さらに、<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）>値に対応する値を含める必要があります。QOSM <QOS希望>。これは、「PHR_RESOURCE_REQUEST」制御情報と一緒に送信されます。QNEエッジまたはQNEインテリアノードが要求されたリソースの数を予約できない場合、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連する「PhR_Resource_Request」は<m>、つまり<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-QOSMのローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>値にこの値を<ピークデータレート1（P）>値に含める必要があります。<qos希望>。その後、RMDリリース手順を実行する必要があります（セクション4.6.1.5を参照）。QNE Ingressで維持されている集計予約に関連付けられた完全な帯域幅をリリースする必要がない場合は、<tear>フラグをオフに設定する必要があることに注意してください。これは、エッジQNESの集計された予約状態に関連するNSLP運用状態をオフにしてはならないためです。ただし、QNEイングレスで維持されている集計予約に関連付けられた完全な帯域幅をリリースする必要がある場合、<tear>フラグをオンにする必要があります。
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-QOSMリフレッシュによる重度の輻輳処理」手順と組み合わせて、「群ごとのRMD予約ベース」と組み合わせて。
* "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メカニズムに適用されます。更新リザーブメッセージが更新タイムアウト期間内にQNEインテリアノードに到達しない場合、この更新リザーブメッセージが要求する帯域幅は更新されません。これは、還元状態に関連付けられた予約された帯域幅が、リフレッシュされていない対応する帯域幅の量によって次の更新期間に減少することを意味します。セクション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.
このソフト状態の動作は、システムに一定の堅牢性を提供し、未使用のリソースが長い間予約されていないことを保証します。リソースは、明示的なリリースによっていつでも削除できます。ただし、エンドツーエンド（涙）予備が再送信される状況では（[RFC5974]のセクション5.2.4を参照）、このメッセージはドメイン内（涙）予備のメッセージを開始してはなりません。これは、（涙）エンドツーエンドの予備に関連付けられているRMDドメイン内の帯域幅の量がすでにリリースされているため、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].
QNEエッジまたはQNEインテリアノードのRMD-RMFが「PHR_RELEASE_REQUEST」PRコンテナを処理する場合、<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」と「phr_release_request」の間に「phr_release_update」と「phr_release_request」制御情報コンテナの間に、「t_lag」と言うタイムラグを示すことで行うことができます。詳細については、[RMD1]および[CSTA05]を参照してください。「T_LAG」の値は、最初に更新期間の長さに正規化され、「T_Period」と言われます。「T_LAG」と更新期間「T_PerioD」の長さの比率が計算されます。この比率は、「PHR_RELEASE_REQUEST」の<タイムラグ>フィールドに導入されます。上記の「T_LAG」を示す手順が使用され、ノード（QNE出口またはQNEインテリア）が「PHR_RELEASE_REQUEST」FRコンテナを受信すると、到着時間を保存する必要があります。次に、到着時間と現在の更新期間の開始「T_Period」の間の時差「T_DIFF」を計算する必要があります。さらに、このノードは、<Time Lag>パラメーターから「T_LAG」の値を導出する必要があります。「T_LAG」は、<TimeLag>パラメーターに含まれる値を更新期間「T_Period」に掛けることで見つけることができます。導出されたタイムラグ「T_LAG」が計算された時間差「T_DIFF」よりも小さい場合、このノードは、<ピークデータレート1（P）>に示されているリソースユニットの数でPHB予約状態を減らす必要があります。ローカルRMD-QSPEC <TMOD-1>のフィールドRMD-QOSM <QOS desired>のパラメーターは、「phr_release_request」「phr container」と一緒に送信されますが、ゼロ以下ではありません。
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固有のリリース手順は、<teal>フラグがオンに設定されたエンドツーエンドの予備によってトリガーできます（セクション4.6.1.5.1を参照）。エンドツーエンドの応答、またはマークされた（すなわち、pdr <m>および/またはpdr <s>パラメーターがオンに設定されている）「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と説明のリリース手順は、エンドツーエンドのリザーブメッセージ（<teal>フラグが設定されている）によってトリガーできます。エンドツーエンドの予備のメッセージがQNEイングレスに到着する涙（<tear>フラグが設定されています）が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 Ingressでは、エンドツーエンドリザーブメッセージがマークされています。つまり、QOS-NSLPデフォルトNSLPID値を別の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.
ドメイン内涙液を生成する前に、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-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールドに含まれるRMDトラフィッククラス要求リソースの量を減算することで実現できます。、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が使用する予備によってトリガーされる明示的なリリース
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 IngressのRMD-QOSMトラフィッククラスの状態から解放され、ドメイン内保護区（RMD-QOSM）メッセージを生成する必要があります。ドメイン内保護区（RMD-QSPEC）メッセージには、<RMD QoSオブジェクトの組み合わせ>フィールドとフロットコンテナ（つまり、 "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]):
涙領域内予備メッセージに含まれるオブジェクトの非デフォルト値のほとんどは、セクション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 Egressノードから応答を受信する必要がないためです。
* 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>フラグをオンに設定する必要があります。
* 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>;
* frリソースユニットは、<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1> RMD-QOSM <QOS DESPERIED>のパラメーターに含める必要があります。
* the value of the <Admitted Hops> parameter MUST be set to "1";
* <Admitted Hops>パラメーターの値は「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).
* fr containerの<タイムラグ>パラメーターの値は、RMD-QOSM機能（セクション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希望>オブジェクトの組み合わせを受信するQNEインテリアノードと「PhR_RELEASE_REQUEST」制御情報コンテナは、トラフィッククラス（PHB）を識別し、<ピークデータレート1に含まれる要求されたリソースをリリースする必要があります（P）>ローカルRMD-QSPEC <TMOD-1>パラメーターの値。これは、保存されているリソースの合計量から、ローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールドに含まれる、RMDトラフィッククラス要求リソースの量を差し引くことで実現できます。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.
ドメイン内涙リザーブ（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.
<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1>のフィールドの値rmd-qosm <qos希望>のパラメーターと、containerの<タイムラグ>フィールドの値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トラフィッククラスの要求されたリソースの量を差し引くことで実現できます。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).
エンドツーエンドのリザーブメッセージは、ドメイン内涙リザーブ（RMD-QSPEC）メッセージがQNE出口ノードに到着する場合にのみ、次のホップ（つまり、QNE出口）によって転送されます。さらに、QNE出口は、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>フラグをオンにする必要があることに注意してください。それ以外の場合、<tear>フラグをオフに設定する必要があります。セクション4.6.1.4を参照してください。
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> = 1および<s> = 0を持つ<m>および<s>パラメーターを運ぶPDRコンテナを含むドメイン内応答メッセージのいずれかによってトリガーできます（セクション4.6を参照してください。1.2）、<m> = 1および<s> = 1（セクション4.6.1.6.1を参照）を持つPDRコンテナを運ぶドメイン内（更新）応答メッセージ、またはエンドツーエンドの通知メッセージ（セクションを参照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リリース手順をトリガーするために使用されるエンドツーエンドの通知メッセージには、値が<m>および<s> <s>が<m> <s>を運ぶPDRコンテナが含まれている場合があります。= 1および<s> = 1、および「PDR_REFRESH_REPORT」または「PDR_CONGESTION_REPORT」コンテナに含まれる<PDR Bandwidth>パラメーターの帯域幅値。
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.
すべての明示的なリリース手順において、ドメイン内涙液を生成する前に、RMD-QOSMは、QNEイングレスに維持されているRMDトラフィッククラスの状態から要求されたRMD-QOSM帯域幅をリリースする必要があることに注意してください。これは、トラフィッククラス（PHB）を識別し、ローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールドに含まれるRMDトラフィッククラス要求リソースの量を減算することで実現できます。、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は、<m> = 1と<s> = 1のPDRコンテナを運ぶドメイン内（更新）応答メッセージのいずれかによってトリガーされた後にドメイン内涙液予備が生成されるという状況を示しています。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.
Tear The Tear Intra Domain 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]に記載されているQOS-NSLP-RMFを参照してください）を使用する必要があります。
* the value of the <M> parameter of the PHR container MUST be set to "1".
* コンテナの<m>パラメーターの値は、「1」に設定する必要があります。
* the value of the <S> parameter of the "PHR container" MUST be set to "1".
* 「fr container」の<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.
* 予備のメッセージには、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.
ドメイン内涙液（RMD-QOSM）が運ぶコンテナに含まれる<m>および<s>パラメーターの値が（（<m> = 0および<s> = 1）として設定されている場合に注意してください。または（<m> = 0および<s> = 0）または（<m> = 1および<s> = 1））、<max admided hops>値を<admided hops>値と比較してはなりません。<k>フィールドの値を設定してはなりません。ドメイン内涙液を受信するQNEエッジまたはQNEインテリアノードは、コンテナに含まれる<K>フィールドを確認する必要があります。<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-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールドに含まれる、RMDトラフィッククラス要求リソースの量を差し引くことで実現できます。RMDトラフィッククラスの状態。セクション4.6.1.5の導入部分で説明されているように、PhRフィールドの<タイムラグ>パラメーターの値は、リリース手順中に使用されます。その後、QNE出口ノードは、ティアイントラドメインリザーブ（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固有のリリース手順は、組み合わせを使用するドメイン内涙リザーブメッセージを生成します。<max admitted hops>および<Admitted_hops>フィールドのフィールドは、「fr container」によって運ばれる<k>値をいつ設定できるかを計算および指定します。<k>フィールドが設定されている場合、「fr container」とドメイン内の涙液の保護区によって運ばれるrmd-qosm <qos> cos>を処理する必要はありません。
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ドメインの一部でのみリソース/帯域幅をリリースするために、<max admited hops>、<admited_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シグナル伝達モデル機能が、「PDR_RESERATION_REPORT」タイプの値<M> = 1および<S> = 0のPDRコンテナを受信する場合、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 Ingressの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.
Tear The Tear Intra Domain 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".
* コンテナの<m>パラメーターの値は、「1」に設定する必要があります。
* the RESERVE message MAY include a PDR container.
* 予備のメッセージには、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.
* 「fr container」によって運ばれる<max入場ホップ>の値は、「pdr container」（<m> = 1および<s> = 0）によって運ばれる<max admided hops>値に等しく設定する必要があります。リリース手順をトリガーするドメイン内応答メッセージの受信。
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.
ドメイン内涙液を受信するQNEエッジまたはQNEインテリアノードは、要求されたリソースをリリースする前に、「fr container」の<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 container」とrmd-qosm <qos desired>オブジェクトを処理してはなりません。引き裂き保護区。
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」の場合、ドメイン内涙リザーブを受信するQNEエッジまたはQNEインテリアノードは、<ピークデータレートに含まれるRMDトラフィッククラスの要求されたリソースの量を差し引くことでリソースをリリースできます。1（p）> RMDトラフィッククラスの状態に保存されているリソースの合計量から、ローカルRMD-QSPEC <TMOD-1>パラメーターのフィールド。セクション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" fr containerに含まれる<m>および<s>パラメーターの値が（<m = 1>および<s> = 0）の場合、<max Admided Hops>値を計算された<と比較する必要があります。認められたホップ>値。ドメイン内裂け目予備が処理され、QNEによって転送される前に、<入院ホップ>容器に含まれる値が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出口に向かってさらに転送されるドメイン内保護区（RMD-QSPEC）は、「fr container」の<k>値を「1」に設定する必要があります。
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希望>）とその関連する初期予約リクエストのfr containerを正常に処理した最後のQNEノードであるためです（つまり、初期ドメイン内リザーブ（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出口ノードはドメイン内予備（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イングレスは、<mを運ぶPDRコンテナを使用してエンドツーエンドの通知メッセージ（セクション4.6.1.6を参照）を受信する場合があります。> = 0および<s> = 1フィールドと<PDR帯域幅>パラメーターの帯域幅値「PDR_CONGESTION_REPORT」コンテナに含まれています。さらに、同じエンドツーエンドの通知メッセージには、次の値が<情報スペック>オブジェクトが含まれています。
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メッセージに関連付けられたエンドツーエンドセッションは、バインドされた集約セッションのバウンドセッションIDを維持します。セクション4.3.1を参照してください。QNE IngressのRMD-QOSMは、このセクションで上記のRMD明示リリース手順を使用するRMD変更手順（セクション4.6.1.4を参照）を開始する必要があります。特に、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.
通信パス、たとえばルーターやリンクの障害が発生する場合、ルーティングアルゴリズムは、トポロジと交通量の変化を反映するためにルーティングの決定を変更することにより、障害に適応します。その結果、再ルーティングされたトラフィックは新しいパスに従い、より多くのトラフィックをサポートする必要があるため、過負荷のノードになる可能性があります。これにより、通信経路に深刻な輻輳が発生する可能性があります。この状況では、利用可能なリソースは、新しいパスに沿ったすべてのフローに必要なQOを満たすのに十分ではありません。
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>フィールドを設定することによって通知されます。ドメイン内リザーブメッセージによって。
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>フィールドの値は、それぞれ<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で説明されている追加機能を使用する必要があります。
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-Awareではない」ノードを構成する必要があり、「NSIS-Aware」ノードと同じ方法で、混雑/重度の混雑状況を検出し、パケットを再マークすることができることを意味します。
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.
インテリアノードは、ノードを通過する深刻な混雑を検出します。データパケットを再マークします。この再マークのために、トラフィッククラスごとに2つの追加のDSCPを割り当てることができます。1つの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対応（等しいコストの複数のパス）ルーティングにより、出口ノードがパケットを検出しないか、重度の混雑したノードを検出しないか、実際にはなかったパケットを誤って検出する可能性が排除されます。重度の混雑したノードを渡します。このタイプのDSCPは、RMDドメイン内のすべてのノードが使用するように構成されている場合にのみ使用する必要があることに注意してください。それ以外の場合、このタイプの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の総数は、できるだけ低くすることをお勧めします。8の制限を超えてはなりません。「エンコードされたDSCP」のみを使用し、「影響を受けるDSCP」マーキングを使用しないことです。別の可能な解決策は、たとえば、RMD-QOSMによってサポートできるAFクラスのそれぞれに重度の鬱血指示に1つの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エッジがドメインごとのdomain QOS-NSLP動作状態を維持すると（セクション4.3.2および4.3.3を参照）、次の手順に従います。QNE Egressノードは、優先順位の低いキューで終了または転送する必要がある多数のドメイン（エンドツーエンド）フローを選択することにより、事前定義されたポリシーを適用して、重度の輻輳状況を解決します。
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を運ぶ予備メッセージ、例えば<Preemption Priority>および<<Defending Priority>パラメーターを使用するか、ローカルで使用して、エグレスノードとイングレスノードに通知できます。定義されたポリシー。優先順位は予約状態に保持されます（セクション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 EgressノードはQNE Ingressノード（上流のステートフルなQOS-NSLPピア）にエンドツーエンドの通知メッセージを生成し、通信パスの深刻な輻輳を示すことを示します。。
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の動作状態ごとに総計を維持する場合（セクション4.3.1を参照）、QNEエッジは、ドメイン内QOS-NSLP動作状態ごとに計算する必要があります。重度の混雑を解決するために終了します。リリースされる総帯域幅は、QNEエッジが流量ごとのdomain QOS-NSLP運用状態を維持する状況と同じ方法で計算されます。影響を受ける集約されたセッションでは、QNE Egressノードが1つのエンドツーエンドの通知メッセージを生成し、QNE Ingressノード（上流のステートフルなQOS-NSLPピア）に送信して、通信パスの深刻な輻輳を示すことに注意してください。このエンドツーエンドの通知メッセージは、集計されたドメイン内QOS-NSLP運用状態に拘束されるエンドツーエンドセッションの1つに関連付けられていることに注意してください。
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.
Notifyメッセージに含まれるオブジェクトの非デフォルト値は、QNE EgressがQNE EgressがPerを維持する状況について、上記のエンドツーエンドNotifyメッセージで使用されているものと同じ方法でQNE Egressノードによって設定する必要があります。-Flowドメイン内操作状態。これに加えて、エンドツーエンドの通知は、パラメーターID = 26、つまり「PDR_CONGESTION_REPORT」を持つPDRコンテナを含むRMD-QSPECを運ぶ必要があります。<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エッジがドメインごとのdomain内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).
（エンドツーエンドの）通知メッセージを受信すると、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.
この操作は図14に示されています。ここで、終了する各フロー（セッション）のQNEイングレスは、「混雑状況」エラーコードを運ぶ通知メッセージを受信します。
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ノードがエンドツーエンドの通知メッセージを受信すると、この通知メッセージは、端に含まれるバウンドセッションID情報を介して、バインドされたドメイン内セッション（セクション4.3.2および4.3.3を参照）に関連付けます。 - フローごとのQOS-NSLP状態まで。QNE Ingressは、セクション4.6.1.5.2で説明されている操作を使用して、ドメイン内セッションを終了します。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
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).
上記の機能は、RMD予約ベース（セクション4.3.3を参照）と両方の測定ベースの入場制御方法（つまり、プロービングとNSIS測定ベースの入場制御に基づく混雑通知）に適用されることに注意してください。セクション4.3.2を参照してください。）。
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 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.
QNEエッジが集計されたドメイン内QOS-NSLP運用状態をサポートする場合、次のアクションが行われます。QNE Ingressは、「PDR_CONGESTION_REPORT」コンテナに含まれる<PDR帯域幅>パラメーターのマークされた帯域幅値と帯域幅値を搭載したPDRコンテナを使用して、エンドツーエンドの通知メッセージを受信できます。さらに、同じエンドツーエンドの通知メッセージには、「うっ血状況」エラーコードを備えた<情報スペック>オブジェクトが含まれます。
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メッセージを受信すると、エンドツーエンドあたりの1階に含まれるバウンドセッションID情報を介して、領域内QOS-NSLPの操作状態を集計する通知メッセージを関連付けます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.
<PDR帯域幅>パラメーターに含まれるリリースされる合計帯域幅値を使用して、QNE IngressノードのRMD-QOSMは、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運用状態に縛られたエンドツーエンドセッションから選択されます。受信したエンドツーエンドの通知メッセージに関連付けられたエンドツーエンドのセッションも、厳しい混雑を通知したことを終了するために選択する必要があることに注意してください。
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）に向けて上流に送信します。このメッセージによって伝える値は次のとおりです。
* 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
エラー重大度クラス：情報エラーコード値：混雑の状況
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.
エンドツーエンドの予約リクエスト（リザーブ）がイングレスノード（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.
このプローブリザーブメッセージの輸送に使用されるGISTデータグラムメッセージの<DSCP>フィールドは、同じセッションに関連付けられたデータパスパケットと同じ値のDSCPでマークする必要があります。このようにして、エンドツーエンドの予備（プローブ）パケットがノードを通過して混雑していることが保証されています。この機能は、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.
（エンドツーエンド）応答メッセージがイングレスノードによって受信されると、エンドツーエンド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-Aware」ノードと同じ方法で、混雑/重度の混雑状況を検出し、パケットを再マークすることができるように構成する必要があることに注意してください。
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を参照）。図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で強調されているように、出力ノードは、流れごとのエンドツーエンド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.
各侵入について、出口は、サポートされている各PHBに対して、侵入/出口ペア集約（RMF）予約状態を生成する必要があります。この集計された予約状態では、総ドメイン内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には、出口に到達する（プローブ）がいつどのように、いつ認められたか拒否されるかの例が含まれています。
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:
リクエストが拒否された場合、出力ノードは（エンドツーエンドの）応答メッセージを生成して、予約に失敗したことを通知する必要があります。特に、以下の<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.
このエンドツーエンドの応答と同じセッションに属するエンドツーエンドの保護区によって運ばれたQSPECは、このメッセージに含まれています。QSPEC <QOS予約>オブジェクトに含まれるパラメーターは、元の<QOS希望>値からコピーされます。<QOS予約>オブジェクトに関連付けられた<e>フラグと、ローカルRMD-QSPEC <TMOD-1>パラメーターに関連付けられた<e>フラグも設定されています。この応答メッセージはイングレスノードに送信され、エンドツーエンド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合意がある場合、この値は再マーク形式のままになる場合があります。エンドツーエンドの予備メッセージによって運ばれるブレーク<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).
* 成功し、失敗した予約（セクション4.6.2.1）;*予約を更新する（セクション4.6.2.2）;*集約された予約の変更（セクション4.6.2.3）。*リリース手順（セクション4.6.2.4）;*重度の混雑処理（セクション4.6.2.5）;*プロービングに基づく混雑通知を使用した入場管理（セクション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-QOSMリフレッシュによる深刻な輻輳処理」手順と組み合わせて、「流量あたりRMD予約ベース」。
* "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-QOSMリフレッシュによる重度の輻輳処理」手順と組み合わせて、「群ごとのRMD予約ベース」と組み合わせて。
* "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ドメインでは、Sender-Receiverを組み合わせて開始された予約は効率的に行うことはできません。
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.
したがって、双方向の操作は、2つの送信者が開始した予約（送信者と送信者）によって実行する必要があります。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.
この（ドメイン内）双方向の送信者および送信者手順は、RMD QoSシグナル伝達モデルのQNE Edge（QNE IngressおよびQNE Egress）ノード間に適用できます。QNE IngressとQNE Egressノードの間にセキュリティ関連が存在する状況（図15を参照）、およびQNE Ingressノードには、ローカルRMD-QSPEC <TMODの必須<ピークデータレート1（P）>値があります-1>両方の方向のパラメーター、つまりqne gressに向けてqne侵入、qne侵入に向かうqne出口に向けて、qne侵入には、ローカルrmd-qspec <tmod-1の両方の<ピークデータレート1（p）>値が含まれる場合があります。>リザーブメッセージ内のRMD-QSPECへのパラメーター（両方方向に必要）。このようにして、QNE Egressノードは、「侵入に向けて出口」方向（QOS-2）に必要なQoSパラメーターを使用できます。QNE出口は、QSPEC、つまりリザーブ（QOS-2）に含まれる適切なQoSパラメーターを備えたリザーブを作成できます。フローの両方の方向は、QNEイングレスとQNE出口に<バウンドセッション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のQNE実装は、データパケットよりも優先度が高いQOS-NSLPシグナリングメッセージを処理することをお勧めします。これは、[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つの<BoundSession-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 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動作状態を維持すると、エンドツーエンドの予備メッセージには2つのバウンドセッションIDが含まれます。1つのBoundSession-IDには、コード（トンネル付きセッションとエンドツーエンドセッション）に設定された値を使用してBinding_Codeを使用しているトンネルドメイン内（フローあたり）セッションのセッションIDを運びます。別のバウンドセッションIDは、バインドされた双方向のエンドツーエンドセッションのセッションIDを運びます。このBoundSession-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動作状態を維持すると、エンドツーエンドの予備メッセージには2つのバウンドセッションIDが含まれます。1つのBoundSession-IDには、コードに設定された値（集約セッション）を使用してBinding_Codeを使用しているトンネル化された集約されたドメイン内セッションのセッションIDが含まれます。別のバウンドセッションIDは、バインドされた双方向のエンドツーエンドセッションのセッションIDを運びます。このBoundSession-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 IngressノードとQNE出口ノードの間にセキュリティ協会が存在しない場合、RMDドメインの送信者と送信者のシナリオの双方向予約は、[RFC5974]で指定されたシナリオを「送信者および送信者シナリオの双方向予約」として使用する必要があります。これは、このシナリオでは、QNE IngressからQNE Egressに送信された予備のメッセージが、「イングレスに向かって出口」方向（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エッジノードは上流と下流の方向の両方で一般的であるため、2つの予約/セッションをQNEエッジノードでバインドできます。さらに、QNE IngressとQNE Egressノードの間にセキュリティアソシエーションが存在すると考えられており、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によれば、「フローごとのRMD予約ベース」のみが、「比例データパケットマーキングによる重度の渋滞処理」と組み合わせて、1つのRMDドメイン内で実装する必要があることが指定されています。ただし、この仕様をサポートするすべてのRMD QNESは、「フローごとのRMD予約ベース」の組み合わせをサポートする必要があります。RMD QNESがより多くのRMD-QOSMスキームをサポートしている場合、そのRMDドメインの演算子は、1つのドメイン内のすべてのQNEエッジノードを事前に設定する必要があります。「PDRコンテナ」（セクション4.1.3）は常に同じ値を使用します。これにより、1つのRMDドメイン内で、以下のRMD-QOSMスキームの1つのみが一度に使用されます。
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ノードは、他のすべての<句コンテナ>ペイロードフィールドを処理する前に、「fr container」に含まれる<sch>フィールドを読み取り、解釈する必要があります。さらに、RMDドメインのボーダーにあるすべてのQNEエッジノードは、他のすべての<PDRコンテナ>ペイロードフィールドを処理する前に、「PDRコンテナ」に含まれる<Sch>フィールドを読み取り、解釈する必要があります。
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ドメイン内の双方向予約操作が図16およびセクション4.6.2を参照しているRMD-QOSMの操作について説明します。
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運用状態は、エンドツーエンドの予備メッセージによって生成および維持されていることに注意してください。セクション4.3.1、4.3.2、および4.3.3）。このシナリオでは、QNE IngressノードによってQNE Egressノードに向かって送信されたドメイン内リザーブメッセージは、図17で予備（RMD-QSPEC）「フォワード」として示されています。ドメイン内保護区（RMD-QSPEC）の主な違い：双方向の成功した予約手順と予備（RMD-QSPEC）メッセージに使用される「フォワード」メッセージは、次のとおりです（QOS-NSLPを参照してください-RMF APIは[RFC5974]で説明されています）：
* 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".
* コンテナの<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コンテナは、保護区（RMD-QSPEC）にも含まれています：「フォワード」メッセージ。パラメーターIDの値は「20」です。つまり、「PDR_RESERATIAN_REQUEST」です。QNE出口によってQNEイングレスノードに送信された応答PDRコンテナは、エンドツーエンドの応答メッセージによっては掲載されていませんが、QNE Egressノードによって送信されるドメイン内予備メッセージによって運ばれていることに注意してください。QNE Ingressノード（図16で予備として示されています（RMD-QSPEC）：「逆」）。
* 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帯域幅>フィールドは、QNE Egressノードで使用する必要がある要求された帯域幅を指定して、逆方向に別のドメイン内予備メッセージを開始する必要があります。
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.
リザーブ（RMD-QSPEC）：「リバース」メッセージは、リザーブ（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:
保護区（RMD-QSPEC）の主な違い：双方向の成功した予約手順に使用される「逆」メッセージと、一方向の成功した予約に使用される予備（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
図17：双方向留保を成功させるためのドメイン内シグナリング操作
* 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>パラメーターの<ピークデータレート1（P）>フィールドの値は、予備（RMD-QSPEC）に含まれる<PDR帯域幅>フィールドの値に等しく設定されています。このリザーブの生成をトリガーした「フォワード」メッセージ（RMD-QSPEC）：「逆」メッセージ。
* the <B> bit of the PHR container indicates a bidirectional reservation and is set to "1";
* コンテナの<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コンテナは予備（RMD-QSPEC）に含まれています：「逆」メッセージ。パラメーターIDの値は「23」です。つまり、「PDR_RESERAVENT_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では、要求された<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1>の値をサポートできないQNEは、QNE速度に向かう方向QNEイングレスにあります。図19では、要求された<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1>の値をサポートできない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".
* 要求された<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1の値をサポートできないQNEノードは、<m>ビット、つまり値「1」に設定する必要があります。リザーブ（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".
* 要求された<ピークデータレート1（P）>ローカルRMD-QSPEC <TMOD-1の値をサポートできないQNEノードは、<m>ビット、つまり値「1」に設定する必要があります。リザーブ（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.
* QNE Ingressは、保護区の受信されたPHRおよびPDRコンテナ（RMD-QSPEC）に含まれる情報を使用し、「逆」を生成し、ドメイン内保護区（RMD-QSPEC）を生成します。このメッセージには、「PHR_RELEASE_REQUEST」および「PDR_RELEASE_REQUEST」制御情報が含まれています。このメッセージは、QNE出口ノードに送信されます。QNE Egressノードは、「PHR_RELEASE_REQUEST」に含まれる情報と「PDR_RELEASE_REQUEST」制御情報コンテナに含まれる情報を使用して、リザーブ（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:
保護区の主な違い（RMD-QSPEC）：双方向リフレッシュ手順とリザーブ（RMD-QSPEC）に使用される「フォワード」メッセージ：双方向の成功した予約手順に使用される「フォワード」メッセージは次のとおりです。
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* コンテナのパラメーター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:
保護区の主な違い（RMD-QSPEC）：双方向リフレッシュ手順とリザーブ（RMD-QSPEC）に使用される「逆」メッセージ：双方向の成功した予約手順に使用される「逆」メッセージは次のとおりです。
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* コンテナのパラメーター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」です。
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>パラメーターに対応する値を含める必要があります<QOS希望>）、「phr_resource_request」制御情報と一緒に送信されます。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-QOSMのローカルRMD-QSPEC <TMOD-1>パラメーターの<ピークデータレート1（P）>フィールドにこの値を含める必要があります。<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の操作について説明します。この手順で使用されているメッセージシーケンス図は、セクション4.6.2.1で説明し、図17に示す予約手順の成功したものと類似しています。ただし、予約のリリースがどのように達成されるかは、使用される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:
保護区の主な違い（RMD-QSPEC）：双方向リリース手順と予備（RMD-QSPEC）に使用される「フォワード」メッセージ：双方向の成功した予約手順に使用される「フォワード」メッセージは次のとおりです。
* the value of the Parameter ID of the PHR container is "18", i.e."PHR_Release_Request";
* コンテナのパラメーター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:
保護区の主な違い（RMD-QSPEC）：双方向リリース手順と予備（RMD-QSPEC）に使用される「逆」メッセージ：双方向の成功した予約手順に使用される「逆」メッセージは次のとおりです。
* the value of the Parameter ID of the PHR container is "18", i.e., "PHR_Release_Request";
* コンテナのパラメーターIDの値は「18」です。つまり、「phr_release_request」;
* the PDR container is not included in the RESERVE (RMD-QSPEC): "reverse" message.
* PDRコンテナは保護区に含まれていません（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で説明したものと似ています。
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を参照）に関連しています。
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-Unawareノードにも適用されることに注意してください。しかし、これは、「NSISではない」内部ノードを構成する必要があり、内部の「NSIS-Aware」ノードと同じように、混雑状況を検出し、パケットを再マークすることができるように構成する必要があります。
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 Egressノードは、エンドツーエンドNotify（PDR）メッセージを生成する必要があります。このようにして、QNE Ingressは、混雑した「フォワード」パスの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.1.6.2で説明し、図14に示す重度の輻輳処理シナリオに非常に似ています。違いは、セクション4.6.2.4で説明されているのと同じ方法で達成されるリリース手順に関連しています。
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に示すシナリオの主な違いは、QNE出口ノードでエンドツーエンドの通知（PDR）メッセージを生成する必要がないことです。
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を参照して、「フォワード」および「逆」パスで予約されたリソースをリリースするために開始されます。
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は、混雑したノードが「逆」パスにあるシナリオを示しています。「フォワード」方向に送信されたプローブリザーブメッセージは、重度の混雑したノードの影響を受けませんが、「逆」方向フローのパケットのIPヘッダーの<DSCP>値と、また「逆」方向に送信されたプローブリザーブメッセージは、混雑したノードによって再マ化されます。このようにして、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-Aware」ノードと同じように、混雑/重度の混雑状況を検出し、パケットを再マークすることができるように構成する必要があることに注意してください。
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 IngressとQNE Egressノードのみが、特定のシグナリングメッセージを開始できます。
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 IngressおよびQNE Egressノードは、ネットワークの全体的な安定性に制御されていない動作がより大きな意味を持つため、QNEインテリアノードよりも多くのセキュリティと障害保護が必要です。QNE IngressとQNE Egressノードは、セキュリティ協会を共有し、シグナリングメッセージを保護するために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）シグナリング交換に基づいてトリガーされた場合、リザーブメッセージはRMDドメインの外側のノードによって作成され、その後さらに移動します（たとえば、データ受信機に）。このような交換を図3に示します。そのため、RMDのセキュリティの評価は常に2つのシグナル伝達セッションの組み合わせと見なされなければなりません（1）と（2）の図24。保護区や応答メッセージなど、単一の「ホップ」とは、QNEインテリアノードが交換に参加しないため、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）フレームワークを使用して、サービス品質の予約を許可することは、基礎となるNSIS QoS NSLPから継承され、[RFC5974]を参照し、このドキュメントでは再び説明されていません。技術的なソリューションメカニズムとして、直径QoSアプリケーション[RFC5866]を使用できます。イングレスノードに到着するエンドツーエンドの予約リクエストは、バックエンドAAAインフラストラクチャを使用して承認手順をトリガーします。エンドツーエンドの予約は、通常、電話をかける際のボイスオーバーIPクライアントなど、ソフトウェアアプリケーションとの人間の相互作用によってトリガーされます。承認が成功した場合、ドメイン内予約のためにRMDドメイン内でQOS認可チェックを開始することは予想されません。
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ネットワーク内の内部ノードは、エンドツーエンドのシグナリングメッセージを無視しますが、ドメイン内のシグナリングメッセージをEgressノードに向けて処理、変更、転送します。それまでの間、リソース予約状態は、各ドメイン内シグナリングメッセージのコンテンツに従って、データパスに沿って各インテリアノードでインストール、変更、または削除されます。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を使用すると、侵入と出口ノードは敵によって制御されず、イングレスと出口ノードの間の通信は標準のGISTセキュリティを使用して保護されていると仮定します（[RFC5971]のセクション6を参照）メカニズムと経験整合性、リプレイ、および機密保護。
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.
これは、これら2つのノードによって直接扱われるメッセージのみに影響し、仲介者が処理する必要がある他のメッセージではないことに注意してください。エンドツーエンド通信の<Session-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].
敵の場所に応じて、私たちはパス上の敵またはパスの敵について話します。RFC4081[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.
失われたシグナルメッセージを再送信するようにイングレスノードをトリガーする場合があります。このシナリオでは、敵が選択したシグナル伝達メッセージ、たとえばドメイン内予約メッセージをドロップします。RMD-QOSMでは、イングレスノードで再送信メカニズムを提供して、シグナリングメッセージが出口ノードに到達できるようにすることができます。ただし、敵のドロップメッセージによってトリガーされた再送信は、特定の問題を引き起こす可能性があります。したがって、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.
シグナリングメッセージは、敵によって遅れる可能性があります。たとえば、更新期間中に予備のメッセージが遅れている場合、対応するセッションのノードに沿って予約されたリソースユニット（帯域幅）が削除されます。この状況では、イングレスノードは特定の期間内に応答を受け取らず、シグナリングメッセージが失敗したと考えています。これにより、「失敗した」メッセージが再送信される可能性があります。出力ノードは、2つのメッセージ、つまり遅延メッセージと再送信メッセージを区別することができ、適切な応答が得られる可能性があります。
However, Interior nodes suffer from this retransmission and they may reserve twice the resource units (bandwidth) requested by the Ingress node.
ただし、インテリアノードはこの再送信に悩まされており、イングレスノードが要求するリソースユニット（帯域幅）の2倍を予約する場合があります。
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.
予備の「メッセージが<rii>オブジェクトを運ぶと、出口はイングレスノードに向けて応答「メッセージ」メッセージで返信します。Ingressノードは、応答 'メッセージの<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.
パス上の敵は、信号メッセージの一部を変更することができます。たとえば、敵はRMD-QSPECメッセージの<m>、<s>、および<o>パラメーターを変更できます。出力ノードは、セッション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>、<rsn>、<session-id> sを知りません。したがって、敵は新しいパラメーターを生成し、新しいシグナリングメッセージを構築する必要があります。内部ノードは縮小状態モードで動作するため、注入されたシグナル伝達メッセージは新しい1回として扱われ、インテリアノードが追加の予約状態を割り当てます。
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 IngressとQNE Egressノードのみが特定のシグナリングメッセージを開始できます。たとえば、QNEインテリアノードは、特定の信号メッセージペイロードを変更できます。
Note that the term "interfere" refers to all sorts of security threats, such as denial-of-service, spoofing, replay, signaling message injection, etc.
「interfere」という用語は、サービスの拒否、スプーフィング、リプレイ、シグナリングメッセージインジェクションなど、あらゆる種類のセキュリティの脅威を指すことに注意してください。
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に組み込まれた重要なセキュリティメカニズムは、Bound-Session-IDを使用してエンドツーエンドリザーブとリザーブメッセージを一緒に結び付け、イングレスノードがリザーブと対応することを可能にする能力でした。'<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.
保護区/応答は、GISTが提供するホップバイホップチャネルセキュリティで送信され、QNEイングレスとQNE出口の間で保護されていると仮定します。GISTセキュリティメカニズムを使用して、認証、整合性、およびリプレイ保護を提供する必要があります。さらに、暗号化を使用して、予備のメッセージの経路に沿って配置された敵が、後で保護区のメッセージを注入するために使用できるセッションに関する情報を学習することを防ぐ必要があります。
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) 保護区と保護区は、QNE出口で互いに関連しています。と
b) the RESPONSE and the RESERVE relate to each other at the QNE Ingress; and
b) 応答と予備は、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) 保護区と応答は互いに関連しています。<rii>は、qne出口ノードによって生成されるリザーブの「メッセージと応答」メッセージに掲載されています。<rii>は、qne侵入で使用されて、リザーブを「応答」と一致させることができます。QNE出口は、リザーブを送信したドメイン内セッション以来、リザーブがQNE Ingressノードによって作成されたかどうかを判断することができます」は、<Bound-Session-Id>>を介してエンドツーエンドセッションにバインドされていますドメイン内QOS-NSLP運用状態に含まれる値は、QNE出口で維持されています。
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.
保護区と保護区のメッセージは、ドメイン内およびエンドツーエンドのQOS-NSLP運用状態によって維持されているバウンドセッションIDを使用して結び付けられます。.2、および4.3.3）。したがって、対応する保護区なしで保護区はありません。セッションIDは、保護区と予備のメッセージに掲載されているセッション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.
ただし、パスが変更された場合（再ルーティングまたはモビリティにより）、敵は予備のメッセージ（以前に見られたセッションIDを使用）を注入し、潜在的に害を引き起こす可能性があります。
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.
オフパス敵は、もちろん、中間ノードに何らかの状態を作成する（および他のアクションを引き起こす）予定のメッセージを作成することができますが、メッセージは最終的にQNE Egressノードにヒットします。QNE Egressノードは、何か問題が発生していることを判断し、エラーメッセージを生成することができます。
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ノードによってまだ開始され、セッションIDを運びます。QNE Egressノードは、セッションIDを使用し、その後、ドメイン内QOS-NSLP運用状態によって維持されるバウンドセッション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'.
更新手順中に、予備が「応答を作成する」、図25を参照してください。<rii>は、qne gurssノードによって生成されるリザーブの「メッセージと応答」メッセージに掲載されています。'。
The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'.
<rii>は、qne侵入で使用されて、リザーブを「応答」と一致させることができます。
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更新メッセージ交換
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_Release_Request> (Section 4.1.2 above, ID=18)
<PHR_Refresh_Update> (Section 4.1.2 above, ID=19)
<PDR_Reservation_Request> (Section 4.1.3 above, ID=20)
<PDR_Refresh_Request> (Section 4.1.3 above, ID=21)
<PDR_Release_Request> (Section 4.1.3 above, ID=22)
<PDR_Reservation_Report> (Section 4.1.3 above, ID=23)
<PDR_Refresh_Report> (Section 4.1.3 above, ID=24)
<PDR_Release_Report> (Section 4.1.3 above, ID=25)
<PDR_Congestion_Report> (Section 4.1.3 above, 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.
著者は、RMDコンセプトに取り組んだ人々に承認を表明しています：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。DeKogel、M。Zoumaro-Djayoon、M。Swanink、R。KlaverG. Stokkink、J。W。Van Houwelingen、D。Dimitrova、T。Sealy、H。Chang、およびJ. de Waal。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、RFC 5974、2010年10月。
[RFC5975] Ash, G., Bader, A., Kappler C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975] Ash、G.、Bader、A.、Kappler C.、およびD. Oran、「サービス品質NSISシグナリング層プロトコル（NSLP）のQSPECテンプレート」、RFC 5975、2010年10月。
[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] Adler、M.、Cai、J.-Y.、Shapiro、J.K.、Towsley、D。、「確率的パケットマーキングを使用した混雑価格の推定」、Proc。IEEE Infocom、pp。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] LACHLAN L. H. Andrew and Stephen V. Hanly、「適応決定論的パケットマーキングの推定誤差」、第44回アラートン通信、コントロール、コンピューティングに関するアラートン会議、2006年。
[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.、Li、V。H.、Low、S。H.、Yin、Q。、「Rem：Active Keue Management」、IEEE Network、Vol。15、pp。48-53、2001年5月/6月。
[Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis, University of Twente, 2007.
[Chan07] H. Chang、「RMD-QOSMのセキュリティサポート」、マスターズ論文、トゥエンテ大学、2007年。
[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.、Takacs、A.、Szabo、R.、Henk、T。、「Resilient Reducted Resource Reservation」、Journal of Communication and Networks、Vol。7、No。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.、de Boer、P.-T。、「双方向予約を備えたNSIS RMDドメインの重度のうっ血処理アプローチ」、Journal of Computer Communications、Elsevier、vol。31、pp。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.
[Jash97] Jamin、S.、Shenker、S.、Danzig、P。、「制御されたロードサービスの測定ベースの入場制御アルゴリズムの比較」、Proceedings IEEE INFOCOM '97、KOBE、日本、1997年4月。
[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.、TSE、D.N.C、「測定ベースの入容能力制御に対するタイムスケール分解アプローチ」、IEEE/ACMトランザクション、Networking、vol。11、No。4、2003年8月。
[Part94] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994).
[Part94] C. Partridge、Gigabit Networking、Addison Wesley Publishers（1994）。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、R.、Clark、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、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] Nichols、K.、Jacobson、V.、およびL. Zhang、「インターネット用の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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。、およびEFelstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「IPv4およびIPv6予約のRSVPの集約」、RFC 3175、2001年9月。
[RFC3726] Brunner, M., Ed., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726] Brunner、M.、ed。、「シグナリングプロトコルの要件」、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] Le Faucheur、F。およびW. Lai、「Diffserv-Aware 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] Le Faucheur、F.、ed。、「Diffserv-Aware MPLS Traffic Engineeringのロシア人形帯域幅の制約モデル」、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.、ed。、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、ed。、「直径のサービス品質アプリケーション」、RFC5866、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] MANNER、J.、Bless、R.、Loughney、J。、およびE. Davies、ed。、「NSISプロトコルファミリーの使用と拡張」、RFC 5978、2010年10月。
[RMD1] Westberg, L., et al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", IFIP PfHSN 2002.
[RMD1] Westberg、L.、et al。、「Diffserv（RMD）のリソース管理：機能とパフォーマンスの動作の概要」、IFIP PFHSN 2002。
[RMD2] G. Karagiannis, et al., "RMD - a lightweight application of NSIS" Networks 2004, Vienna, Austria.
[RMD2] G. Karagiannis、et al。、「RMD -NSISの軽量アプリケーション」Networks 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.、Pop O.、Szabo R.、Dinnyes G.、Turanyi Z.、「負荷制御への新規強化 - ソフトステート、軽量入院制御プロトコル」、Proc。2番目のint。将来のインターネットサービスの品質に関するワークショップ、コインブラ、ポルトガル、2001年9月24〜26日、pp。82-96。
[RMD4] A. Csaszar et al., "Severe congestion handling with resource management in diffserv on demand", Networking 2002.
[RMD4] A. Csaszar et al。、「Diffserv On Demandでのリソース管理との重度の輻輳処理」、Networking 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. Tang、T-Y Charles Tai、「トークンバケットモデルを使用したネットワークトラフィックの特性評価」、IEEE Infocom 1999、コンピューター通信会議、No。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.、Coates、M。J.、「混雑パケット推定のための決定論的パケットマーキング」Proc。IEEE Infocom、2004年。
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.
サポートされているPHBごとに、内部ノードは、調査シグナル伝達スキームに基づいた流量ごとの混雑通知がこの重度の輻輳タイプと組み合わせて使用される場合、図26に示す操作状態をサポートできます。図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」ではない内部ノードを通過するすべてのパケットをマークするために使用されます。さらに、内部ノードが輻輳通知または重度の混雑状態にある場合、ドメイン内予備のメッセージと内部ノードを通過するプローブパケットは「エンコードされた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に関連する内部ノードが重度に混雑している状態を表します。重度の混雑状態の行動を通常の状態に直接変えるために、重度の輻輳状態解決策のターゲットの1つが強調することが重要です。
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」しきい値以下の場合に発生します。これは、重度の混雑状態の解決策のターゲットの1つをサポートして、重度の混雑状態の行動を正常状態に直接変更することを強調することが重要です。
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で使用される1つの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」までのみ。同じ通信パスにある複数のインテリアノードがひどく混雑し、これらのインテリアノードの1つが「Encoded_DSCP」マークされたパケットを受信した場合、このインテリアノードはマークなし、つまり「元のDSCP」または「影響を受けたDSCP」または「影響を受けたDSCP」または「「Notified DSCP」エンコードされたパケットは、最大PHB容量と「重度の輻輳しきい値」の差に等しいレートまで、着信「エンコードされたDSCP」マークされたパケットがすでにこの差を知らせることができます。この場合、「重度の輻輳しきい値」は、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.
threadold_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秒の最後に、次の方程式を使用して、測定された_Overload_rateなどの現在の推定過負荷率を計算します。
measured_overload_rate = =((total_received_bytes)/T)-severe_congestion_restoration)
meadured_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].
エンコードされた情報の信頼できる推定を提供するために、いくつかの手法を使用できます。[atli01]、[adca03]、[thco04]、および[anha06]を参照してください。マーキングは内部ノードで行われるため、脱出ノードで決定が行われ、フローの終了はイングレスノードによって実行されることに注意してください。イングレスノードによって過負荷情報が学習されるまで大きな遅延があります（[セクション6を参照]CSTA05]）。遅延は、重度の混雑した内部ノードから出口へのデータパケットのトリップ時間、測定間隔、つまりT、および出口から侵入までの通知シグナリングメッセージのトリップ時間で構成されています。さらに、重度の混雑した内部ノードで過負荷が減少するまで、イングレスノードから重度の混雑した内部ノードまでの追加のトリップ時間が期限切れになる必要があります。これは、混雑通知を受信する直前に、入り口が終了のために選択されたフローにパケットを送信した可能性があるためです。つまり、終了したフローは、侵入から内部ノードに採取される時間より長い間混雑に寄与する可能性があります。上記を考慮せずに、測定された使用率が深刻な輻輳回復のしきい値を下回るまで、内部ノードはパケットをマークし続けます。このようにして、最終的には、必要以上に多くのフローが終了します。つまり、過剰反応が起こります。[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:
Sum_Mi =0
For i =1 to n
{
Sum_Mi = Sum_Mi + Mi
}
signaled_overload_rate = measured_overload_rate - Sum_Mi,
signaled_overload_rate = meadured_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
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は、次のpseudocodeを使用して計算されます。
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
Where the incoming "encoded DSCP" rate is calculated as follows:
着信「エンコードされたDSCP」レートが次のように計算される場合：
incoming_encoded-DSCP_rate =
= (received number of "encoded_DSCP" during T) * 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の間に、各測定間隔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％を超える過負荷状況を処理するには、ドメイン内のすべてのノードを構成し、スケーリングパラメーターを維持する必要があることに注意してください。マークされたバイト、たとえば、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.
「エンコードされたDSCP」と「影響を受けるDSCP」マークされたパケット（RMDドメイン全体に適用される場合）は、QNEエッジノードに伝播されます。
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.
さらに、調査に基づいた輻輳通知が重度のうっ血と組み合わせて使用される場合、次に「エンコードされたDSCP」と「影響を受けるDSCP」に加えて、同じPHBの再マークのための別のDSCPが使用されることに注意してください（参照セクション4.6.1.7）。この追加のDSCPは、このドキュメントで「通知されたDSCP」として示されています。内部ノードが重度の混雑状態で動作し（図27を参照）、「通知されたDSCP」パケットを受信すると、これらのパケットはマークされていないパケットと見なされます（ただし、「影響を受けるDSCP」パケットではありません）。これは、深刻な輻輳中に、「通知されたDSCP」パケットも再マ化して、「エンコードされたDSCP」または「影響を受けたDSCP」パケットとしてエンコードできることを意味します。
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」とマークされたバイトの事前定義速度は、うっ血通知検出しきい値として示されます。この混雑通知検出しきい値もゼロになる可能性があることに注意してください。つまり、イベントAは、間隔tの間に出力ノードが少なくとも1つの「通知されたDSCP」パケットを受信するときにアクティブになります。
* 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」（「影響を受けるDSCP」がRMDドメイン全体に適用されるとき）としてマークされたパケットを受信したときに発生します。
* 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の間に出力ノードが「通知された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」（「影響を受けるDSCP」がRMDドメイン全体に適用されるとき）としてマークされたパケットを受け取らないときに発生します。渋滞通知をサポートするために「通知された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の間に出口が（1）「エンコードされたDSCP」または「影響を受けるDSCP」のいずれか（「影響を受けるDSCP」がRMDドメイン全体に適用される場合）と（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」（「影響を受けるDSCP」がRMDドメイン全体に適用されるとき）としてマークされたパケットを受け取らないときに発生します。
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.
「エンコードされたDSCP」と「影響を受けるDSCP」マークされたパケット（RMDドメイン全体に適用される場合）は、QNE Edgeノードによって受信されます。
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 Egressノードは、すべてのフローの過剰レートとアイデンティティを記録し、QNE出口ノードに到達し、「エンコードされたDSCP」と「影響を受けるDSCP」（RMDドメイン全体に適用される場合）を記録します。重度の混雑した内部ノードを通過するものであるこれらのフローのみが、終了の候補です。過剰率は、QNE出口ノードに到達するすべての「エンコードされたDSCP」データパケットのレートを測定することによって計算されます。測定された過剰速度は、QNEインテリアノードで使用されて過負荷レベルをエンコードするために使用された因子Nを掛けることにより、出口ノードによって変換されます。
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.
異なる優先フローがサポートされると、出口ノードに到達したすべての低優先フローが最初に終了します。次に、すべての中程度の優先フローが停止し、最後に、必要に応じて、高優先度のフローも選択されます。優先クラス内で、「エンコードされたDSCP」と「影響を受けるDSCP」の両方が、メカニズムがより高い優先度クラスに移動する前に考慮されます。最後に、Egressノードを終了する必要がある各フローについて、Flowを停止するIngressノードに通知メッセージを送信します。
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 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:
Total_congested_bandwidth = n*input_remarked_bytes/tでは、input_remarked_bytesは、1つの測定間隔tの間に出口に到達する「エンコードされたdscp」マークされたバイトの数を表します。Terminated_BandWidthとして示される用語は、同じPHBトラフィッククラスに属する終了する必要がある総帯域幅を表す時間変数です。terminate_flow_bandwidth（priority_class）は、優先度クラスの流れに関連する帯域幅です。パラメーターPriority_Classは、整数が充実しています。
0 =< priority_class =< Maximum_priority.
0 = <priority_class = <maxim_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().
QNE Egressノードは、各フロー、Total_Congested_BandWidth、およびすべてのフローのアイデンティティを転送するQNE IngressノードのIDを記録し、QNE Egressノードに到着し、「エンコードされたDSCP」と「影響を受けたDSCP」（RMD全体に適用されるとドメイン）。これにより、重度の過負荷の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（priortive_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.
出力ノードがイングレス/エグレスペアの予約集約を維持する場合、上記のアルゴリズムは、各イングレス/出口ペアの予約集約に対して実行されます。
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 EgressノードはQNE Ingressノードに通知メッセージを送信してフローを終了します。
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 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.
* 異なる<DSCP>値（再マーク<DSCP>値）を使用します。この目的に使用される再マークされたDSCPは、このドキュメントで「通知されたDSCP」として示されます。この方法が使用され、内部ノードが「混雑通知」状態にある場合、付録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」マーキングを使用します。この方法については、この例の付録で詳しく説明していません。
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で述べたように、2つの方法が使用されます。
* 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の間、出口は、同じPHBに属し、同じイングレス/出口ペア集約に関連付けられている「通知されたDSCP」マークされたバイトの数を数えます。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.
以下に、最初の方法の詳細な説明のみが示されています。
The incoming congestion_rate can be then calculated as follows:
次のように、入ってくる混雑_rateは次のように計算できます。
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.
出力ノードが「混雑通知」状態で動作し、エンドツーエンドの予備（プローブ）が出口に到着する場合、この要求は拒否されるはずです。これは、プローブパケットが「通知されたDSCP」または「エンコードされたDSCP」のマークのいずれかである場合にのみ発生することに注意してください。このようにして、エンドツーエンドの予備（プローブ）パケットが混雑しているノードを通過することが保証されます。この機能は、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.
（プローブ）予備のメッセージが出口に到着したときにそのような侵入/出口ペアの集約状態が利用できない場合、予備メッセージを運ぶパケットのDSCPがマークされていない場合、この要求は受け入れられます。それ以外の場合（パケットが「通知されたDSCP」または「エンコードされたDSCP」のいずれかである場合）は、拒否されます。
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.
* 出力ノードは、可能であれば、双方向の流れの代わりに最初の一方向の流れを選択する必要があります。
* 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.
* 出力ノードは、可能であれば、混雑の経路に逆転するパス上の比較的少量のリソースを予約する双方向の流れを選択する必要があります。
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を参照してください。出力ノードは、終了する多くの双方向の流れを選択することを考えてください。この場合、出口は、双方向の流れごとに、イングレスへの通知メッセージを送信します。イングレスがこれらの通知メッセージを受信し、その動作状態（リバースパスに関連付けられている）が深刻な混雑状態にある場合（図26および27を参照）、イングレスは次のように動作します。
* For each NOTIFY message, the Ingress SHOULD identify the bidirectional flows that have to be terminated.
* 通知メッセージごとに、イングレスは終了する必要がある双方向フローを識別する必要があります。
* 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」と言う場合（したがって前方方向ではない）、逆方向にリリースされるべき合計帯域幅を計算します。この帯域幅は、（深刻な輻輳）通知メッセージを受け取ったすべてのエンドツーエンドセッションに関連付けられた帯域幅値の合計によって計算できます。
* 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:
* イングレスは、終了する必要がある追加のフローの帯域幅を計算します。「追加の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_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 "addational_reverse_bandwidth" = = "marked_reverse_bandwidth" - "notify_reverse_bandwidth";else "addational_reverse_bandwidth" = 0
* Ingress terminates the flows that experienced a severe congestion in the forward path and received a (severe congestion) NOTIFY message.
* Ingressは、前方経路で深刻な輻輳を経験し、（深刻な渋滞）通知メッセージを受け取ったフローを終了します。
* 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.
* 可能であれば、侵入は、同じ出力炎逆方向の方向通信パスを使用する単方向の流れを終了し、「Addational_Reverse_BandWidth」に等しい総帯域幅のリリースを満たす必要があります。付録A.5を参照してください。
* 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.
* 必要な単方向フローの数（上記の問題を満たすため）が利用できない場合、合計のリリースを満たすために、同じ出力炎の逆方向方向通信パスを使用するために同じ出力炎の逆方向通信パスを選択することができます。帯域幅は、「adthide_reverse_bandwidth」に等しくなります。付録A.5に記載されているガイドラインを使用して、最初に、輻輳の経路に逆転するパス上の比較的少量のリソースを予約した双方向フローを終了のために選択する必要があることに注意してください。
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」コンテナ内のA <PDR帯域幅>のこの帯域幅値を含めます。
* 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.
* IngressはNotifyメッセージを受信し、「PDR_CONGESTION_REPORT」コンテナに含まれる<PDR Bandwidth>値を読み取ります。この値は、QNEエッジがドメインごとのQOS-NSLP動作状態を維持するという状況では、「notify_reverse_bandwidth」として示されるが、異なる方法で計算されることに注意してください。変数「Marked_Reverse_BandWidth」および「Addational_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に含めることにより、「フォワード」および「逆」方向で削減できます（P）>ローカルRMD-QSPEC <TMOD-1> rmd-qosm <qos desired>のパラメーターのパラメーター<notify_reverse_bandwidth>に等しい値を、ドメイン内領域内に保持するフィールドと同じドメイン内予備メッセージによって運ばれる「PDR_RELEASE_REQUEST」コンテナ内の<PDR帯域幅>パラメーター。
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]で指定されている先制ビルディングブロックを使用します。
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 Ingressが、これらのプリエンプトされたセッションのそれぞれについて、他のセッションを先取りするセッションの保護区を受け取った場合、QNE Ingressは次の手順に従います。
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 Ingressは、下流の涙のリザーブを送信し、Boundsession-IDを追加する必要があります。<binding_code>値は、先制を引き起こしたセッションのセッションIDを示す「指定セッションを引き起こした」と等しい。さらに、「予約された予約」に等しいエラーコード値を持つ<情報スペック>オブジェクトは、これらの裂け目の予備メッセージのそれぞれに含める必要があります。
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 Ingressは、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.
送信されるティアリングリザーブのそれぞれについて、QNE Ingressは、QNIに向かって「予約された予約」に等しいエラーコード値を持つ<情報スペック>オブジェクトを含む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.
先制（引き裂き）保護区を送信した後、侵入QNEは（予約）予備を送信し、これにより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.
QNEインテリアは、<バインドセッションID>オブジェクトを「binding_code>値が「示されたセッションを引き起こした」と等しい<binding_code>値を持つ最初の（引き裂き）リザーブを受信し、エラーコード値を等しいエラーコード値を持つ<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インテリアは、いわゆる「先制状態」を作成します。これは、先制関連の<バウンドセッションID>オブジェクトで運ばれるセッションIDによって識別されます。さらに、この「先制状態」には、（引き裂き）予備に関連するセッションのセッションIDが含まれます。その後、BoundSession-IDと<情報スペック>オブジェクトの同じ値を含む追加の裂傷予備が到着すると、これらの（引き裂き）予備のメッセージの関連するセッションIDが既に作成されたものに含まれます」先制状態」。その後、QNEはタイマーを設定し、（予約する）予備が到着する前に期限切れにならないように十分に高い値を設定します。
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インテリアノードが、関連する（予約）予備メッセージが届く前にQNEイングレスによって送信された予備のすべての（引き裂き）予備のメッセージをすべて受信しない場合、（予約）予備のメッセージはリソースとこのメッセージを予約せず、このメッセージは予約されません「M」とマークされます（セクション4.6.1.2を参照）。この状況は典型的な状況ではないことに注意してください。通常、この状況は、エラーの状態により、少なくとも1つ（引き裂く）予備メッセージがドロップされた場合にのみ発生します。
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 Ingressによって送信されたすべてのプリエンプト（引き裂き）予備のメッセージをすべて受信した場合、QNEインテリアは保留中のリソースを削除し、通常のRMD-QOSM帯域幅のリリースと予約手順を使用して新しい予約を作成します。。
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.
QNEインテリア操作と同様に、QNE出口は、「指定されたセッションを引き起こした」と<info-specに等しい<バインディング_code>値を持つ<バウンドセッションID>オブジェクトを運ぶ最初の（引き裂き）リザーブを受信すると>エラーコード値が「予約された予約」に等しいオブジェクトは、このセッションを先制する必要があると考えています。QNEインテリア操作と同様に、QNE出口はいわゆる「先制状態」を作成します。これは、プリエンプション関連の<バウンドセッション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".
その後、BoundSession-IDと<情報スペック>オブジェクトの同じ値を含む追加の裂傷予備が到着すると、これらの（引き裂き）予備のメッセージの関連するセッションIDが既に作成されたものに含まれます」先制状態」。
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ノードから送信された（予約）予約メッセージが到着し、「M」とマークされていない場合、すべてのプリエンプト（引き裂き）の予備メッセージが到着した場合、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」マークされた予備のメッセージを受信した場合、QNE出口は通常の部分的なRMD-QOSM手順を使用して、「M」マークされた予備に関連付けられた部分予約リソースをリリースします（セクション4.6.1.2を参照）。
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出口が、関連する（M」マークされた（予約）予備のメッセージではなく、QNE Ingressによって送信されたすべてのプリエンプト（引き裂き）予備のメッセージを受け取らない場合、次の手順に従うことができます。
* 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 Egressが先制処理をサポートするエンドツーエンドの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出口は優先度の高いセッションに関連付けられた要求（予約）リザーブメッセージを拒否する必要があります（セクション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.
通常、QNE出口がQNE侵入者によって送信されたすべてのプリエンプトされた（引き裂かれた）予備のメッセージをすべて受け取らない状況は、（引き裂き）予備のメッセージの少なくとも1つがドロップされた場合にのみ発生する可能性があることに注意してください。エラー状態。
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ドメイン内のドメイン内予約メッセージの再送信が許可されていない場合、すべての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>、<session-id>（gist経由で入手可能）が含まれるリプレイキャッシュを維持できるようにします。、および最後に受け取った「fr container」<parameter id>各セッション[RFC5975]のRMD-QSPECによって運ばれました。したがって、このソリューションは、<qos-nslp>オブジェクト[RFC5974]によって運ばれる情報と、RMD-QSPEC「fr container」によって運ばれるパラメーターを使用します。次のフェーズを区別できます。
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>.
インテリアノードがドメイン内予備のメッセージを受信し、キャッシュが空になっている場合、または一致するエントリがない場合、受信したメッセージの「fr parameter id> fieldのフィールドが読み取られます。<parameter id>がphr_resource_requestである場合、ドメイン内予定メッセージが予約リクエストであることを示す場合、qneインテリアノードはキャッシュに新しいエントリを作成し、<rsn>、<session-id>、<パラメーターID>エントリに合わせて<ReshePerioD>を設定します。
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.
リストに保存されている情報を使用することにより、インテリアノードは、受信したドメイン内予備メッセージが敵によって送信されるかどうかを確認します。たとえば、受信したドメイン内リザーブメッセージの<session-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;
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;
Situation D3: <Parameter ID> in its own list is PHR_REFRESH_UPDATE,
and <Parameter ID> in the message is 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インテリアノードは、受信したドメイン内リザーブメッセージによって運ばれるローカルRMD-QSPEC <TMOD-1>パラメーターを使用/処理しません。さらに、「fr container」の<k>フラグを設定する必要があります。これにより、ドメイン内リザーブメッセージによって運ばれるローカル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インテリアノードはドメイン内リザーブメッセージを処理しませんが、QNE Ingressノードによって再送信された可能性があるため、下流ノードに渡すだけです。状況S2の場合、QNEインテリアノードは、リフレッシュ期間内に最初の着信ドメイン（更新）予約メッセージを処理し、エントリを更新してダウンストリームノードに転送します。
If only <Session-ID> is matched to the list, then the QNE Interior node checks the <RSN>. Here also two situations can be distinguished:
<session-id>のみがリストに一致する場合、QNEインテリアノードは<RSN>をチェックします。ここでは、2つの状況を区別できます。
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:
The QNE Interior node will check the <Parameter ID> part;
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>が保存されたリストの<RSN2>に等しく、<パラメーターID>がPHR_RESOURCE_REQUESTまたはPHR_REFRESH_UPDATEである場合、受信したドメイン内リザーブメッセージは典型的なものとして解釈および処理する必要があります（非非処理する必要があります。-tearing）リロウトによる予約メッセージは、[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である場合、受信したドメイン内予備のメッセージは、典型的な（引き裂き）と解釈および処理する必要があります。再ルーティングによって引き起こされる予約メッセージ（[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インテリアノードは、受信したドメイン内予備メッセージによって運ばれるローカル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インテリアノードがドメイン内リザーブメッセージを受信すると、キャッシュから対応するエントリを取得し、値を比較します。メッセージが有効な場合、インテリアノードはリストエントリで<パラメーターID>および<refreed-feriod>を更新します。
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インテリアノードがドメイン内（涙）予備のメッセージを受信し、リプレイキャッシュのエントリが見つかると、メッセージの処理後にQNEインテリアノードがこのエントリを削除します。さらに、インテリアノードは、<parameter id> valueがphr_refresh_updateに等しい<parameter id>値を使用して、ドメイン内（更新）の期間中にドメイン内（更新）を受信しなかった場合にキャッシュエントリを削除します。
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では、QS-NSLP内でQSPECをどのように使用できるかの例を説明します。図29は、QNIとQNRがこのコンテキストでZ-E2Eとして示されるエンドツーエンドQOSMを使用している状況を示しています。QNI Access Network側は、QOSサポートを「X」で定義しているQOSサポートを備えた生成「X」テクノロジーに基づいて構築されたワイヤレスアクセスネットワークであり、QNRアクセスネットワークは、独自の定義されたQOSサポートを備えた有線/固定アクセスネットワークです。
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エッジはZ-E2E QOSMとRMD-QOSMの両方を実行できますが、QNEインテリアノードはRMD-QOSMのみを実行できます。たとえば、QNIはワイヤレスラップトップと見なされますが、QNRはPCと見なされます。
|------| |------| |------| |------|
|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
図29.イニシエーターとローカルドメインQOSM操作の例
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 desired>および<qosavailaber> qspecオブジェクトを開始者qspecに設定し、<qos desired>に<qosavail>を初期化します。この例では、<最小QoS>オブジェクトは入力されていません。QNIは、QSPECパラメーターに入力して、パスのドメインでのトラフィックの正しい処理を確保します。さらに、パスのさらに正しい治療を確保するために、QNIには<QOS希望>の<PHBクラス>が含まれます。したがって、QNIにはQSPECに含まれます。
<QoS Desired> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
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 G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming RTP transmits voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets.
最も単純な場合、最小ポリシーユニットMは、IP-、UDP、およびRTP-ヘッダーのペイロードの合計です。IPv4ケースのIPヘッダーのサイズは20オクテット（IPv6を使用する場合は40オクテット）です。UDPヘッダーのサイズは8オクターで、RTPは12オクテットヘッダーを使用します。G.711コーデックは、64 kbit/s（8000オクテット/s）の帯域幅を指定します。RTPが20ミリ秒ごとに音声データグラムを送信すると仮定すると、1つのデータグラムのペイロードは8000オクテット/s * 0.02 s = 160オクテットです。
IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets
IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets
The Rate r specifies the amount of octets per second. 50 datagrams are sent per second.
レートrは、1秒あたりのオクテットの量を指定します。50個のデータグラムが1秒あたり送信されます。
IPv4: r = 50 1/s * m = 10,000 octets/s
IPv6: r = 50 1/s * m = 11,000 octets/s
The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used.
バケットサイズBは、最大バーストを指定します。この例では、10個のパケットのバーストが使用されています。
IPv4: b = 10 * m = 2000 octets
IPv6: b = 10 * m = 2200 octets
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）>およびMPは上記で指定されていませんが、この例では、次のとおりです。
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.
<Path Latency>および<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.
RMDドメイン境界のQNEイングレスノードでエンドツーエンドの予備メッセージが受信されると、QNEイングレスはイニシエーターエンドツーエンドリザーブメッセージを「非表示」して、QNEエッジのみがイニシエーターを処理するようにします（エンド - トゥエンド）予約メッセージ。これは、ドメインのエッジ間に中間ノードをバイパスし、独自のローカルリザーブメッセージを発行します（セクション6を参照）。この新しいローカルリザーブメッセージの場合、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 Ingressは、元のイニシエーターQSPECに含まれる<TMOD-1>パラメーターを、ローカルRMD-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-QOSM帯域幅等価<TMOD-1> RMD-QSPECのパラメーターは次のとおりです。
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
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
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
* メッセージシーケンス= 0：送信者開始 *オブジェクトの組み合わせ= 0：<Qos希望>予約のために<qos reserved>応答
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".
RMD-QOSMで使用される<QSPECバージョン>は、デフォルトバージョン、つまり「0」、[RFC5975]を参照してください。RMD-QOSMで使用される<QSPECタイプ>値は[RFC5975]で指定され、 "2"に等しくなります。
The <Traffic Handling Directives> contains the following fields:
<トラフィックハンドリングディレクティブ>には、次のフィールドが含まれています。
<Traffic Handling Directives> = <PHR container> <PDR container>
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.
ホップごとの予約容器（容器）とドメインごとの予約容器（PDRコンテナ）は、それぞれセクション4.1.2と4.1.3に指定されています。<fr container>には、ドメイン内通信と予約のためのトラフィック処理指令が含まれています。<PDRコンテナ>には、エッジ間通信に必要な追加のトラフィック処理指令が含まれています。RMD-QOSM <QOS希望>および<QOS予約>は、セクション4.1.1で指定されています。
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>
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予約は、<Antisment Priority>パラメーターなしで確立されます。これは、値が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 Egressノードは、RMDドメイン全体に代わって<QOSAvailable>を更新できます。できない場合（<m>フラグは<パスレイテンシ>に設定されていないため）、パラメーター固有の「サポートされていない」フラグを上げ、QNRに<QOS利用可能>の最終レイテンシ値が不正確であることを警告します。
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.
「Y」アクセスドメインでは、イニシエーターQSPECは、同様のQNRによって処理され、QNIによって「X」ワイヤレスアクセスドメインで処理されたものでした。
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:
予約が成功した場合、最終的に予備要求はQNRに到着します（そうでなければ、予約が失敗したQNEは予備を中止し、QNIにエラー応答を送り返します）。<rii>がqos-nslpメッセージに含まれている場合、qnrはqspecオブジェクト<qos予約>および<qos available>を使用して正の応答を生成します。<QOS予約>に表示されるパラメーターは、<QOS希望>と同じであり、<QOS利用可能>から値がコピーされています。したがって、QNRには、応答メッセージに次のQSPECオブジェクトが含まれています。
<QoS Reserved> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
Contributors
貢献者
Attila Takacs Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Takacs@ericsson.com
Attila Takacs Ericsson Research Ericsson Hungary Ltd. Laborc 1、Budapest、Hungary、H-1037メール：attila.takacs@ericsson.com
Andras Csaszar Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Andras.Csaszar@ericsson.com
Andras Csaszar Ericsson Research Ericsson Hungary Ltd. Laborc 1、Budapest、Hungary、H-1037メール：andras.csaszar@ericsson.com
Authors' Addresses
著者のアドレス
Attila Bader Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Bader@ericsson.com
Attila Bader Ericsson Research Ericsson Hungary Ltd. Laborc 1、Budapest、Hungary、H-1037メール：attila.bader@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 Se-164 80 Stockholm、Sweden Email：lars.westberg@ericsson.com
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@ewi.utwente.nl
Georgios Karagiannis University of Twente P.O.Box 217 7500 AE Enschede、The Netherlandsメール：g.karagiannis@ewi.utwente.nl
Cornelia Kappler ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
Cornelia Kappler CK Technology Conceptsベルリン、ドイツのメール：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
Hannes tschofenig nokia siemens Networks linnoitustie 6 espoo 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
Tom Phelan Sonus Networks 250 Apollo Dr. Chelmsford、MA 01824 USAメール：tphelan@sonusnet.com