[要約] RFC 6601は、IP/MPLSネットワークのための汎用接続承認制御（GCAC）アルゴリズムの仕様を提供しています。このRFCの目的は、ネットワークリソースの効果的な管理と、トラフィックの品質を確保するための接続承認制御の方法を定義することです。
Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 6601 AT&T
Category: Experimental D. McDysan
ISSN: 2070-1721 Verizon
April 2012
Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks
IP / MPLSネットワーク用のGeneric Connection Admission Control（GCAC）アルゴリズム仕様
Abstract
概要
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.
このドキュメントでは、IP / MPLSベースのネットワークの一般的な接続受付制御（GCAC）リファレンスモデルとアルゴリズムについて説明します。サービスプロバイダー（SP）のIP / MPLSネットワークでは、動機付けの1つの例として、追加の通話が既に進行中の通話に悪影響を及ぼす場合にVoice over IP（VoIP）通話を拒否するためのMPLS GCACメカニズムが必要です。 MPLS GCACがないと、輻輳したリンク上の接続の品質が低下します。 MPLS GCACアルゴリズムは、オプションでベンダー機器に実装し、サービスプロバイダーが展開できます。 MPLS GCACは、ベンダー機器間および複数のサービスプロバイダードメイン間で相互運用します。 MPLS GCACアルゴリズムは、RSVP、Diffserv対応のMPLSトラフィックエンジニアリング（DS-TE）、パス計算要素（PCE）、シグナリングの次のステップ（NSIS）、Diffserv、OSPFなど、MPLSベースのネットワークで利用可能な標準メカニズムを使用します。 MPLS GCACアルゴリズムには、詳細なパス選択メカニズムなど、ベンダー独自の実装と見なされる可能性のあるCACの側面は含まれていません。 MPLS GCAC機能は、指定されたQoS制約に対して客観的なサービス品質（QoS）を提供するために分散して実装されます。目的は、ソースが、選択されたパスに沿ったvia要素が実際にリクエストを受け入れる可能性が高いソースルートを計算できることです。場合によっては（複数の自律システム（AS）など）、この目的が常に満たされるとは限りませんが、このドキュメントでは、この目的を部分的に満たす方法を要約しています。 MPLS GCACは、指定された量のトラフィックに対して目的のQoS（遅延、ジッター、パケット損失率）を満たさなければならないすべてのサービスまたはフローに適用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6601.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6601で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. MPLS GCAC Reference Model and Algorithm Summary .................6
2.1. Inputs to MPLS GCAC ........................................8
2.2. MPLS GCAC Algorithm Summary ................................9
3. MPLS GCAC Algorithm ............................................12
3.1. Bandwidth Allocation Parameters ...........................12
3.2. GCAC Algorithm ............................................15
4. Security Considerations ........................................18
5. Acknowledgements ...............................................20
6. Normative References ...........................................20
7. Informative References .........................................21
Appendix A: Example MPLS GCAC Implementation Including Path
Selection, Bandwidth Management, QoS Signaling, and
Queuing ...............................................24
A.1 Example of Path Selection and Bandwidth Management
Implementation .............................................26
A.2 Example of QoS Signaling Implementation ....................32
A.3 Example of Queuing Implementation ..........................34
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. Given the capital constraints in some SP networks, over-provisioning is not acceptable. MPLS GCAC supports all access technologies, protocols, and services while meeting performance objectives with a cost-effective solution and operates across routing areas, autonomous systems, and service provider boundaries.
このドキュメントでは、IP / MPLSベースのネットワークの一般的な接続受付制御（GCAC）リファレンスモデルとアルゴリズムについて説明します。サービスプロバイダー（SP）のIP / MPLSネットワークでは、動機付けの1つの例として、追加の通話が既に進行中の通話に悪影響を及ぼす場合にVoice over IP（VoIP）通話を拒否するためのMPLS GCACメカニズムが必要です。 MPLS GCACがないと、輻輳したリンク上の接続の品質が低下します。一部のSPネットワークには資本の制約があるため、オーバープロビジョニングは受け入れられません。 MPLS GCACは、すべてのアクセステクノロジー、プロトコル、およびサービスをサポートし、コスト効率の高いソリューションでパフォーマンス目標を満たし、ルーティングエリア、自律システム、およびサービスプロバイダーの境界を越えて動作します。
This document defines an MPLS GCAC reference model, algorithm, and functions implemented in one or more types of network elements in different domains that operate together in a distributed manner to deliver the objective QoS for specified QoS constraints, such as bandwidth. With MPLS GCAC, the source router/server is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. MPLS GCAC includes nested CAC actions, such as RSVP aggregation, nested RSVP - Traffic Engineering (RSVP-TE) for scaling between provider edge (PE) routers, and pseudowire (PW) CAC within traffic-engineered tunnels. MPLS GCAC focuses on MPLS and PW-level CAC functions, rather than application-level CAC functions.
このドキュメントでは、帯域幅などの指定されたQoS制約に目的のQoSを提供するために分散して連携して動作する、異なるドメインの1つ以上のタイプのネットワーク要素に実装されたMPLS GCAC参照モデル、アルゴリズム、および機能を定義します。 MPLS GCACを使用すると、ソースルーター/サーバーは、選択されたパスに沿ったvia要素が実際に要求を受け入れる可能性が高いソースルートを計算できます。 MPLS GCACには、RSVP集約、プロバイダーエッジ（PE）ルーター間のスケーリングのためのネストされたRSVP-トラフィックエンジニアリング（RSVP-TE）、およびトラフィックエンジニアリングされたトンネル内の疑似配線（PW）CACなどのネストされたCACアクションが含まれます。 MPLS GCACは、アプリケーションレベルのCAC機能ではなく、MPLSおよびPWレベルのCAC機能に焦点を当てています。
MPLS GCAC is applicable to any service or flow that must meet an objective QoS (latency, delay variation, loss) for a specified quantity of traffic. This would include, for example, most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Other services subject to MPLS GCAC could include, for example, manually provisioned label switched paths (LSPs) or PWs and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. MPLS GCAC is applicable to both access and backbone networks, for example, to slow-speed access networks and to broadband DSL, cable, and fiber access networks.
MPLS GCACは、指定された量のトラフィックに対して目的のQoS（遅延、遅延変動、損失）を満たさなければならないすべてのサービスまたはフローに適用できます。これには、たとえば、ほとんどのリアルタイム/ RTPサービス（音声、ビデオなど）と一部の非リアルタイムサービスが含まれます。リアルタイム/ RTPサービスは通常、インタラクティブで比較的持続的なトラフィックフローです。 MPLS GCACの対象となるその他のサービスには、手動でプロビジョニングされたラベルスイッチドパス（LSP）またはPW、およびPEルーター間でLSPメッシュを自動的に構築するアプリケーションの自動帯域幅割り当てなどがあります。 MPLS GCACは、アクセスネットワークとバックボーンネットワークの両方に適用できます。たとえば、低速アクセスネットワークや、ブロードバンドDSL、ケーブル、ファイバーアクセスネットワークなどです。
This document is Experimental. It is intended that service providers and vendors experiment with the GCAC concept and the algorithm described in this document in a controlled manner to determine the benefits of such a mechanism. That is, they should first experiment with the GCAC algorithm in their laboratories and test networks. When testing in live networks, they should install the GCAC algorithm on selected routers in only part of their network, and they should carefully monitor the effects. The installation should be managed such that the routers can quickly be switched back to normal operation if any problem is seen.
このドキュメントは実験的です。サービスプロバイダーとベンダーは、このドキュメントで説明されているGCACの概念とアルゴリズムを制御された方法で実験して、そのようなメカニズムの利点を判断することを目的としています。つまり、彼らは最初にラボとテストネットワークでGCACアルゴリズムを実験する必要があります。ライブネットワークでテストする場合、ネットワークの一部の選択したルーターにGCACアルゴリズムをインストールし、影響を注意深く監視する必要があります。問題が発生した場合にルーターをすばやく通常の動作に戻すことができるように、インストールを管理する必要があります。
Since application of GCAC is most likely in Enterprise VPNs and/or internal TE infrastructure, it is RECOMMENDED that the experiment be conducted in such applications, and it is NOT RECOMMENDED that the experiment be conducted in the Internet. If possible, the experimental configuration will address interoperability issues, such as, for example, the use of different constraint models across different traffic domains.
GCACの適用はエンタープライズVPNや内部TEインフラストラクチャで最も可能性が高いため、このようなアプリケーションで実験を行うことをお勧めします。実験をインターネットで行うことはお勧めしません。可能であれば、実験的な構成は、たとえば、異なるトラフィックドメインにわたる異なる制約モデルの使用などの相互運用性の問題に対処します。
The experiment can monitor various measures of quality of service before and after deployment of GCAC, particularly when the experimental network is under stress during an overload or failure condition. These quality-of-service measures might include, for example, dropped packet rate and end-to-end packet delay. The results of such experiments may be fed back to the IETF community to refine this document and to move it to the Standards Track (probably within the MPLS working group) if the experimental results are positive.
実験では、GCACの導入前後のサービス品質のさまざまな指標を監視できます。特に、実験ネットワークが過負荷状態または障害状態のときにストレスがかかっている場合に役立ちます。これらのサービス品質の測定には、たとえば、ドロップされたパケットレートやエンドツーエンドのパケット遅延などがあります。そのような実験の結果は、IETFコミュニティにフィードバックしてこのドキュメントを改良し、実験結果が肯定的である場合は、標準のトラック（おそらくMPLSワーキンググループ内）に移動することができます。
It should be noted that the algorithm might have negative effects on live deployments if the experiment is a failure. Effects might include blockage of traffic that would normally be handled or congestion caused by allowing excessive traffic on a link. For these reasons, experimentation in production networks needs to be treated with caution as described above and should only be carried out after successful simulation and experimentation in test environments. In Section 2, we describe the MPLS GCAC reference model, and in Section 3, we specify the MPLS GCAC algorithm based on the principles in the reference model and requirements. Appendix A gives an example of MPLS GCAC implementation including path selection, bandwidth management, QoS signaling, and queuing implementation.
実験が失敗した場合、ライブデプロイメントにアルゴリズムが悪影響を及ぼす可能性があることに注意してください。影響には、通常は処理されるトラフィックのブロックや、リンク上で過剰なトラフィックを許可することによって引き起こされる輻輳が含まれる場合があります。これらの理由により、本番ネットワークでの実験は、上記のように注意して扱う必要があり、テスト環境でのシミュレーションと実験が成功した後にのみ実行する必要があります。セクション2では、MPLS GCAC参照モデルについて説明し、セクション3では、参照モデルの原理と要件に基づいてMPLS GCACアルゴリズムを指定します。付録Aは、パス選択、帯域幅管理、QoSシグナリング、およびキューイングの実装を含むMPLS GCAC実装の例を示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Figure 1 illustrates the reference model for the MPLS GCAC algorithm:
図1は、MPLS GCACアルゴリズムの参照モデルを示しています。
,-. ,-.
,--+ `--+--'- --'\
+----+_____+------+ { +----+ +----+ `. +------+
|GEF1| | |______| P |___| P |______| |
| |-----| PE1 | { +----+ +----+ /+| PE2 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAR Tunnels ; +------+
_,' \-| ./ -'._ !|
| Access \ / +----+ \, !|
| Network | \_ | P | | !|
| / `| +----+ / !|
`--. ,.__,| | IP/MPLS Network / !|
'`' '' ' .._,,'`.__ _/ '---' !|
| '`''' !|
C1 !|
,-. ,-. !|
,--+ `--+--'- --'\ !|
+----+_____+------+ { +----+ +----+ `. +------+
|GEF2| | |______| P |___| P |______| |
| |-----| PE4 | { +----+ +----+ /+| PE3 |
| | | |==========================>| ASBR |
+-:--+ | |<==========================| |
_|..__ +------+ { DS-TE/MAM Tunnels ; +------+
_,' \-| ./ -'._
| Access \ / +----+ \,
| Network | \_ | P | |
| / `| +----+ /
`--. ,.__,| | IP/MPLS Network /
'`' '' ' .._,,'`.__ _/ '---'
| '`'''
C2
CUSTOMER I/F PARAMETERS: BW, QoS, CoS, priority
お客様のI / Fパラメータ：BW、QoS、CoS、優先度
NOTE: PE, P, ASBR, GEF elements all support GCFs
LEGEND:
---------
ASBR: Autonomous System Border Router
BW: bandwidth
CoS: class of service
DS-TE: Diffserv-aware MPLS Traffic Engineering
GCAC: generic connection admission control
GCF: GCAC core function
GEF: GCAC edge function
I/F: interface
MAM: Maximum Allocation Model
MAR: Maximum Allocation with Reservation
P: provider router
PE: provider edge router
--- connection signaling
___ bearer/media flows
Figure 1: MPLS GCAC Reference Model
図1：MPLS GCAC参照モデル
MPLS GCAC is applicable to any service or flow for which MPLS GCAC is required to meet a given QoS. As such, the reference model applies to most real-time/RTP services (voice, video, etc.) as well as some non-real-time services. Real-time/RTP services are typically interactive, relatively persistent traffic flows. Non-real-time applications subject to MPLS GCAC could include, for example, manually provisioned LSPs or PWs and automatic bandwidth assignment for applications that automatically build LSP meshes among PE routers. The reference model also applies to MPLS GCAC when MPLS is used in access networks, which include, for example, slow-speed access networks and broadband DSL, cable, and fiber access networks. Endpoints will be IP/PBXs (Private Branch Exchanges) and individual-usage SIP/RTP end devices (hard and soft SIP phones, Integrated Access Devices (IADs)). This traffic will enter and leave the core via possibly bandwidth-constrained access networks, which may also be MPLS aware but may use some other admission control technology.
MPLS GCACは、特定のQoSを満たすためにMPLS GCACが必要なすべてのサービスまたはフローに適用できます。そのため、参照モデルは、ほとんどのリアルタイム/ RTPサービス（音声、ビデオなど）および一部の非リアルタイムサービスに適用されます。リアルタイム/ RTPサービスは通常、インタラクティブで比較的持続的なトラフィックフローです。 MPLS GCACの対象となる非リアルタイムアプリケーションには、たとえば、手動でプロビジョニングされたLSPまたはPW、およびPEルーター間でLSPメッシュを自動的に構築するアプリケーションの自動帯域幅割り当てが含まれます。 MPLSがアクセスネットワーク（低速アクセスネットワーク、ブロードバンドDSL、ケーブル、ファイバーアクセスネットワークなど）で使用されている場合、参照モデルはMPLS GCACにも適用されます。エンドポイントは、IP / PBX（構内交換機）および個別使用のSIP / RTPエンドデバイス（ハードおよびソフトSIP電話、統合アクセスデバイス（IAD））になります。このトラフィックは、帯域幅が制限されている可能性のあるアクセスネットワークを介してコアに出入りします。これはMPLSにも対応していますが、他のアドミッションコントロールテクノロジーを使用している場合もあります。
The basic elements considered in the reference model are the MPLS GCAC edge function (GEF), GCAC core functions (GCFs), the PE routers, Autonomous System Border Routers (ASBRs), and provider (P) routers. As illustrated in Figure 1, the GEF interfaces to the application at the source and destination PE, and the GCF exists at the PE, P, and ASBR routers. GEF has an end-to-end focus and deals with whether individual connection requests fit within an MPLS tunnel, and GCF has a hop-by-hop focus and deals with whether an MPLS tunnel can be established across specific core network elements on a path. The GEF functionality may be implemented in the PE, ASBR, or a stand-alone network element. The source/destination routers (or external devices through a router interface) support both GEF and GCF, while internal routers (or external devices through a router interface) support GCF. In Figure 1, the GEF handles both signaling and bearer control.
参照モデルで考慮される基本要素は、MPLS GCACエッジ関数（GEF）、GCACコア関数（GCF）、PEルーター、自律システムボーダールーター（ASBR）、プロバイダー（P）ルーターです。図1に示すように、GEFは送信元および宛先PEでアプリケーションにインターフェイスし、GCFはPE、P、およびASBRルーターに存在します。 GEFはエンドツーエンドの焦点を持ち、個々の接続要求がMPLSトンネル内に収まるかどうかを扱い、GCFはホップバイホップの焦点を持ち、パス上の特定のコアネットワーク要素間でMPLSトンネルを確立できるかどうかを扱います。 GEF機能は、PE、ASBR、またはスタンドアロンネットワーク要素に実装できます。送信元/宛先ルーター（またはルーターインターフェイスを介した外部デバイス）はGEFとGCFの両方をサポートし、内部ルーター（またはルーターインターフェイスを介した外部デバイス）はGCFをサポートします。図1では、GEFはシグナリングとベアラ制御の両方を処理します。
Inputs to the GEF and GCF include the following, where most are inputs to both GEF and GCF, except as noted. Most of the parameters apply to the specific flow/LSP being calculated, while some parameters, such as request type, apply to the calculation method. Required inputs are marked with (*); all other inputs are optional:
GEFとGCFへの入力には次のものが含まれます。注記されている場合を除き、ほとんどがGEFとGCFの両方への入力です。ほとんどのパラメータは計算される特定のフロー/ LSPに適用されますが、リクエストタイプなどの一部のパラメータは計算方法に適用されます。必須入力には（*）が付いています。他のすべての入力はオプションです。
Traffic Description * Bandwidth per DS-TE class type [RFC4124] (GEF, GCF) * Bandwidth for LSP from [RFC3270] (GEF, GCF) * Aggregated RSVP bandwidth requirements from [RFC4804] (GEF) Variance Factor (GEF, GCF)
トラフィックの説明* DS-TEクラスタイプごとの帯域幅[RFC4124]（GEF、GCF）* [RFC3270]からのLSPの帯域幅（GEF、GCF）* [RFC4804]からの集約RSVP帯域幅要件（GEF）分散係数（GEF、GCF）
Class of Service (CoS) and Quality of Service (QoS) * Class Type (CT) from [RFC4124] (GEF, GCF) Signaled or configured Traffic Class (TC) [RFC5462] to Per Hop Behavior (PHB) mapping from [RFC3270] (GEF, GCF) Signaled or configured PHB from [RFC3270] (GEF, GCF) QoS requirements from NSIS/Y.1541 [RFC5971][RFC5974][RFC5975] [RFC5976] (GEF)
サービスクラス（CoS）およびサービス品質（QoS）* [RFC4124]からのクラスタイプ（CT）（GEF、GCF）[RFC3270]からのホップ単位の動作（PHB）マッピングへのトラフィッククラス（TC）[RFC5462]のシグナリングまたは構成]（GEF、GCF）[RFC3270]からシグナリングまたは構成されたPHB（GEF、GCF）NSIS / Y.1541からのQoS要件[RFC5971] [RFC5974] [RFC5975] [RFC5976]（GEF）
Priority Admission priority (high, normal, best effort) from NSIS/Y.1541 [RFC5971][RFC5974][RFC5975][RFC5976] (GEF, GCF) Preemption priority from [RFC4124] (GEF, GCF)
NSIS / Y.1541 [RFC5971] [RFC5974] [RFC5975] [RFC5976]からの優先度アドミッション優先度（高、通常、ベストエフォート）（GEF、GCF）[RFC4124]からの優先権の優先度（GEF、GCF）
Request type Primary tunnel (GEF, GCF) Backup tunnel and fraction of capacity reserved for backup (GEF, GCF)
リクエストタイププライマリトンネル（GEF、GCF）バックアップトンネルとバックアップ用に予約された容量の割合（GEF、GCF）
Oversubscription method (see [RFC3270]) Over/undersubscribe requested capacity (GEF, GCF) Over/undersubscribe available bandwidth (GEF, GCF)
オーバーサブスクリプション方式（[RFC3270]を参照）オーバー/サブスクライブ要求容量（GEF、GCF）オーバー/アンダーサブスクライブ利用可能帯域幅（GEF、GCF）
These inputs can be received by the GEF and GCF from a signaling interface (such as SIP or H.323), RSVP, or an NMS. They can also be derived from measured traffic levels or from elsewhere.
これらの入力は、シグナリングインターフェイス（SIPやH.323など）、RSVP、またはNMSからGEFおよびGCFで受信できます。また、測定されたトラフィックレベルまたは他の場所から取得することもできます。
Figure 1 is a reference model for MPLS GCAC and illustrates the GEF to GEF MPLS GCAC algorithm to determine whether there is sufficient bandwidth to complete a connection. The originating GEF receives a connection request including the above input parameters over the input interface, for example, via an RSVP bandwidth request as specified in [RFC4804]. The GEF a) determines whether there is enough bandwidth on the route between the originating and terminating GEFs via routing and signaling communication with the GCFs at the P, PE, and ASBR network elements along the path to accommodate the connection, b) communicates the accept/reject decision on the input interface for the connection request, and c) keeps account of network resource allocations by tracking bandwidth use and allocations per CoS. Optionally, the GEF may dynamically adjust the tunnel size by signaling communication with the GCFs at nodes along the candidate paths. For example, the GEF could a) maintain per-CoS tunnel capacity based on aggregated connection requests and respond on a connection-by-connection basis based on the available capacity, b) periodically adjust the tunnel capacity upward, when needed, and downward when spare capacity exists in the tunnel, and c) use a 'make before break' mechanism to adjust tunnel capacity in order to minimize disruption to the bearer traffic.
図1はMPLS GCACの参照モデルであり、接続を完了するのに十分な帯域幅があるかどうかを判断するためのGEF to GEF MPLS GCACアルゴリズムを示しています。発信GEFは、たとえば[RFC4804]で指定されているRSVP帯域幅要求を介して、入力インターフェイスを介して上記の入力パラメータを含む接続要求を受信します。 GEFは、a）接続に対応するために、パスに沿ったP、PE、およびASBRネットワーク要素のGCFとのルーティングおよびシグナリング通信を介して、発信GEFと終端GEFの間のルートに十分な帯域幅があるかどうかを決定します。b）受け入れを通信します。接続要求の入力インターフェイスでの/ reject決定、およびc）CoSごとの帯域幅の使用と割り当てを追跡することにより、ネットワークリソースの割り当てを考慮します。オプションで、GEFは、候補パスに沿ったノードでGCFとの通信をシグナリングすることにより、トンネルサイズを動的に調整できます。たとえば、GEFは、a）集約された接続要求に基づいてCoSごとのトンネル容量を維持し、使用可能な容量に基づいて接続ごとに応答します。b）必要に応じて、定期的にトンネル容量を上方に調整します。予備の容量がトンネル内に存在し、c）ベアトラフィックの中断を最小限に抑えるために、トンネルの容量を調整するために「make before break」メカニズムを使用します。
In the reference model, DS-TE [RFC4124] tunnels are configured between the GEFs based on the traffic forecast and current network utilization. These guaranteed bandwidth DS-TE tunnels are created using RSVP-TE [RFC3209]. DS-TE bandwidth constraints models are applied uniformly within each domain, such as the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model [RFC4126], the Maximum Allocation Model (MAM) [RFC4125], and the Russian Dolls Model (RDM) [RFC4127]. An IGP such as OSPF or IS-IS is used to advertise bandwidth availability by CT for use by the GCF to determine MPLS tunnel bandwidth allocation and admission on core (backbone) links. These DS-TE tunnels are configured based on the forecasted traffic load, and when needed, LSPs for different CTs can take different paths.
参照モデルでは、トラフィック予測と現在のネットワーク使用率に基づいて、GEF間にDS-TE [RFC4124]トンネルが構成されています。これらの保証帯域幅DS-TEトンネルは、RSVP-TE [RFC3209]を使用して作成されます。 DS-TE帯域幅制約モデルは、予約付き最大割り当て（MAR）帯域幅制約モデル[RFC4126]、最大割り当てモデル（MAM）[RFC4125]、ロシア人形モデル（RDM）など、各ドメイン内で均一に適用されます。 RFC4127]。 OSPFやIS-ISなどのIGPは、GCFがコア（バックボーン）リンクでのMPLSトンネル帯域幅の割り当てと許可を決定するために使用するCTによる帯域幅の可用性を通知するために使用されます。これらのDS-TEトンネルは、予測されるトラフィック負荷に基づいて構成され、必要に応じて、異なるCTのLSPは異なるパスを使用できます。
As described in Section 3, the unreserved link bandwidth on CTc on link k (ULBCck) is the only bandwidth allocation parameter that must be available to the MPLS GCAC algorithm. In the case that a connection is set up across multiple service provider networks, i.e., across multiple routing domains/autonomous systems (ASes), there are several options to enable MPLS GCAC to be implemented:
セクション3で説明したように、CTk on link k（ULBCck）の予約されていないリンク帯域幅は、MPLS GCACアルゴリズムで使用できる必要がある唯一の帯域幅割り当てパラメーターです。複数のサービスプロバイダーネットワーク間、つまり複数のルーティングドメイン/自律システム（AS）間で接続が設定されている場合、MPLS GCACを実装できるようにするいくつかのオプションがあります。
1. Use [OIF-E-NNI] to advertise ULBCck parameters to the originating GEF, for the full topology of adjacent domains/areas/ASes, as described in Section 3.3.2.1.2 of [OIF-E-NNI]. Note that the
1. [OIF-E-NNI]のセクション3.3.2.1.2で説明されているように、[OF-E-NNI]を使用して、隣接するドメイン/エリア/ ASの完全なトポロジのUNLOckパラメータを発信元のGEFにアドバタイズします。ことに注意してください
option of abstract node summarization described in [OIF-E-NNI] will not suffice since the process of summarization results in loss of topology and capacity usage information. In this manner, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes.
[OIF-E-NNI]で説明されている抽象ノード要約のオプションは、要約のプロセスがトポロジーと容量使用情報の損失をもたらすため、十分ではありません。このようにして、元のGEFは、セクション3で説明されているMPLS GCACアルゴリズムを複数のドメイン/エリア/ ASに実装できます。
2. Use [BGP-TE] to advertise ULBCck parameters via BGP to the originating GEF for the full topology of adjacent domains/areas/ASes. In this manner, the originating GEF can implement the MPLS GCAC algorithm described in Section 3 across multiple domains/areas/ASes. However, network providers may be reluctant to divulge full topology and capacity usage information to other providers. Furthermore, [BGP-TE] was never intended to provide full TE topology distribution across ASBRs. Such a mechanism would be neither stable nor scalable.
2. [BGP-TE]を使用して、隣接するドメイン/エリア/ ASの完全なトポロジのBGPを介して発信元のGEFにULBCckパラメータをアドバタイズします。このようにして、元のGEFは、セクション3で説明されているMPLS GCACアルゴリズムを複数のドメイン/エリア/ ASに実装できます。ただし、ネットワークプロバイダーは、完全なトポロジおよび容量使用状況の情報を他のプロバイダーに明かすことに消極的である場合があります。さらに、[BGP-TE]は、ASBR全体に完全なTEトポロジを配布することを意図したものではありませんでした。このようなメカニズムは安定しておらず、スケーラブルでもありません。
3. Use individual AS control and MPLS crankback [RFC4920] to retain originating GEF control. For example, in Figure 1, if a connection crosses the two ASes shown (call them AS1 and AS2), the source GEF1 applies the GCAC algorithm described in Section 3 to the links in AS1, that is, between PE1 and PE2/ASBR in Figure 1. Then, in AS2, the GCF in PE3/ASBR applies the MPLS GCAC algorithm to the links in AS2, that is, between PE3 and PE4 in Figure 1. If the flow is rejected in AS2, crankback signaling is used to inform GEF1. In routing a connection across multiple ASes, e.g., across AS1-->AS2-->AS3, if the flow is rejected, say in AS2, the originating GEF1 can seek an alternate route, perhaps AS1-->AS4-->AS3. This option does not achieve full originating GEF control with the desired full topology visibility across ASes but avoids possible issues with obtaining full topology visibility across ASes.
3. 個別のAS制御とMPLSクランクバック[RFC4920]を使用して、元のGEF制御を保持します。たとえば、図1では、接続が図示の2つのASと交差する場合（AS1とAS2と呼びます）、ソースGEF1はセクション3で説明されているGCACアルゴリズムをAS1のリンクに適用します。つまり、PE1とPE2 / ASBRの間で図1.次に、AS2では、PE3 / ASBRのGCFがMPLS GCACアルゴリズムをAS2のリンク、つまり図1のPE3とPE4の間のリンクに適用します。フローがAS2で拒否された場合、クランクバックシグナリングを使用して通知します。 GEF1。 AS1-> AS2-> AS3のように複数のAS間で接続をルーティングする際に、フローが拒否された場合（AS2など）、発信元のGEF1は代替ルート（おそらくAS1-> AS4-> AS3）を探すことができます。 。このオプションでは、AS全体でトポロジを完全に可視化して完全に元のGEF制御を実現することはできませんが、AS全体でトポロジを完全に可視化することで起こり得る問題は回避されます。
4. Use Path Computation Elements (PCEs) [RFC4655] across multiple ASes. PCEs could potentially execute the GCAC algorithm within each AS and communicate/interwork across domains to determine which high-level path can supply the requested bandwidth.
4. 複数のASでパス計算要素（PCE）[RFC4655]を使用します。 PCEは各AS内でGCACアルゴリズムを実行し、ドメイン間で通信/インターワークして、要求された帯域幅を提供できる高レベルのパスを特定する可能性があります。
In the reference model, the GEFs implement RSVP aggregation [RFC4804] for scalability. The GEF RSVP aggregator keeps a running total of bandwidth usage on the DS-TE tunnel, adding the bandwidth requirements during connection setup and subtracting during connection teardown. The aggregator determines whether or not there is sufficient bandwidth for the connection from that originating GEF to the destination GEF. The destination GEF also checks whether there is enough bandwidth on the DS-TE tunnel from the destination GEF to the originating GEF. The aggregate bandwidth usage on the DS-TE tunnel is also available to the DS-TE bandwidth constraints model. If the available bandwidth is insufficient, then the GEF sends a PATH message through the tunnel to the other end, requesting bandwidth using GCFs, and if successful, the source would then complete a new explicit route with a PATH message along the path with increased bandwidth, again invoking GCFs on the path. If the size of the DS-TE tunnel cannot be increased on the primary and alternate LSPs, then when the DS-TE tunnel bandwidth is exhausted, the GEF aggregator sends a message to the endpoint denying the reservation. If the DS-TE tunnels are underutilized, the tunnel bandwidth may be reduced periodically to an appropriate level. In the case of a basic single class TE scenario, there is a single TE tunnel rather than multiple-CT DS-TE tunnels; otherwise, the above GCAC functions remain the same.
参照モデルでは、GEFはスケーラビリティのためにRSVP集約[RFC4804]を実装しています。 GEF RSVPアグリゲーターは、DS-TEトンネル上で実行中の合計帯域幅使用量を維持し、接続セットアップ中に帯域幅要件を追加し、接続ティアダウン中に減算します。アグリゲーターは、発信元GEFから宛先GEFへの接続に十分な帯域幅があるかどうかを判別します。宛先GEFは、宛先GEFから発信GEFへのDS-TEトンネルに十分な帯域幅があるかどうかもチェックします。 DS-TEトンネルでの総帯域幅使用量は、DS-TE帯域幅制約モデルでも利用できます。利用可能な帯域幅が不十分な場合、GEFはPATHメッセージをトンネルを介して相手側に送信し、GCFを使用して帯域幅を要求します。成功した場合、ソースは、帯域幅が増加したパスに沿ってPATHメッセージを含む新しい明示的なルートを完了します、再びパス上のGCFを呼び出します。プライマリLSPと代替LSPでDS-TEトンネルのサイズを大きくできない場合、DS-TEトンネルの帯域幅が使い果たされると、GEFアグリゲーターが予約を拒否するメッセージをエンドポイントに送信します。 DS-TEトンネルが十分に活用されていない場合、トンネルの帯域幅が定期的に適切なレベルに減少することがあります。基本的な単一クラスTEシナリオの場合、複数のCT DS-TEトンネルではなく、単一のTEトンネルがあります。それ以外の場合、上記のGCAC関数は同じままです。
Optionally, the reference model implements separate queues with Diffserv based on Traffic Class (TC) bits [RFC5462]. For example, these queues may include two Expedited Forwarding (EF) priority queues, with the highest priority assigned to Emergency Telecommunications Service (ETS) traffic and the second priority assigned to normal-priority real-time traffic (alternatively, there could be a single EF queue with dual policers [RFC5865]). Several Assured Forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic and premium public data traffic. A separate best-effort queue may be used for the best-effort traffic. Several DS-TE tunnels may share the same physical link and therefore share the same queue.
オプションで、参照モデルは、トラフィッククラス（TC）ビット[RFC5462]に基づくDiffservを使用して個別のキューを実装します。たとえば、これらのキューには2つの緊急転送（EF）優先度キューが含まれ、最も高い優先度が緊急通信サービス（ETS）トラフィックに割り当てられ、2番目の優先度が通常優先度のリアルタイムトラフィックに割り当てられます（または、単一の優先度デュアルポリサーを備えたEFキュー[RFC5865]）。プレミアムプライベートデータトラフィックやプレミアムパブリックデータトラフィックなど、さまざまなデータトラフィックにいくつかのAssured Forwarding（AF）キューを使用できます。別のベストエフォートキューをベストエフォートトラフィックに使用できます。複数のDS-TEトンネルが同じ物理リンクを共有し、したがって同じキューを共有する場合があります。
The MPLS GCAC algorithm increases the likelihood that the route selected by the GEF will succeed, even when the LSP traverses multiple service provider networks.
MPLS GCACアルゴリズムは、LSPが複数のサービスプロバイダーネットワークを通過する場合でも、GEFによって選択されたルートが成功する可能性を高めます。
Path computation is not part of the GCAC algorithm; rather, it is considered as a vendor proprietary function, although standard IP/MPLS functions may be included in path computation, such as the following:
パス計算はGCACアルゴリズムの一部ではありません。むしろ、これはベンダー独自の機能と見なされますが、次のような標準IP / MPLS機能がパス計算に含まれる場合があります。
a) Path Computation Element (PCE) [RFC4655][RFC4657][RFC5440] to implement inter-area/inter-AS/inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering.
a) パス計算要素（PCE）[RFC4655] [RFC4657] [RFC5440]は、エリア間/ AS間/ SP間パス選択アルゴリズム（DS-TEトンネルを保護するための代替パス選択、パス再最適化、バックアップパス計算など）を実装します。そして、エリア間/ AS間/ SP間トラフィックエンジニアリング。
b) Backward-Recursive PCE-Based Computation (BRPC) [RFC5441].
b) 後方再帰PCEベースの計算（BRPC）[RFC5441]。
c) Per-Domain Path Computation [RFC5152].
c) ドメインごとのパス計算[RFC5152]。
d) MPLS fast reroute [RFC4090] to protect DS-TE LSPs against failure.
d) MPLS高速リルート[RFC4090]により、DS-TE LSPを障害から保護します。
e) MPLS crankback [RFC4920] to trigger alternate path selection and enable explicit source routing.
e) MPLSクランクバック[RFC4920]により、代替パスの選択がトリガーされ、明示的なソースルーティングが可能になります。
MPLS GCAC is performed at the GEF during the connection setup attempt phase to determine if a connection request can be accepted without violating existing connections' QoS and throughput requirements. To enable routing to produce paths that will likely be accepted, it is necessary for nodes to advertise some information about their internal CAC states. Such advertisements should not require nodes to expose detailed and up-to-date CAC information, which may result in an unacceptably high rate of routing updates. MPLS GCAC advertises CAC information that is generic (e.g., independent of the actual path selection algorithms used) and rich enough to support any CAC.
MPLS GCACは、接続セットアップ試行フェーズ中にGEFで実行され、既存の接続のQoSおよびスループット要件に違反することなく接続要求を受け入れることができるかどうかを判断します。ルーティングが有効になりそうなパスを生成できるようにするには、ノードが内部のCAC状態に関するいくつかの情報を通知する必要があります。そのようなアドバタイズメントでは、ノードが詳細で最新のCAC情報を公開する必要はないはずです。これにより、ルーティングの更新が受け入れられないほど高率になる可能性があります。 MPLS GCACは、一般的な（たとえば、使用される実際のパス選択アルゴリズムに依存しない）CAC情報をアドバタイズし、CACをサポートするのに十分な情報を提供します。
MPLS GCAC defines a set of parameters to be advertised and a common admission interpretation of these parameters. This common interpretation is in the form of an MPLS GCAC algorithm to be performed during MPLS LSP path selection to determine if a link or node can be included for consideration. The algorithm uses the advertised MPLS GCAC parameters (available from the topology database) and the characteristics of the connection being requested (available from QoS signaling) to determine if a link/node will likely accept or reject the connection. A link/node is included if the MPLS GCAC algorithm determines that it will likely accept the connection and excluded otherwise.
MPLS GCACは、アドバタイズされる一連のパラメータと、これらのパラメータの一般的なアドミッション解釈を定義します。この一般的な解釈は、MPLS LSPパス選択中に実行されるMPLS GCACアルゴリズムの形式であり、リンクまたはノードを考慮に入れることができるかどうかを判断します。アルゴリズムは、アドバタイズされたMPLS GCACパラメータ（トポロジデータベースから利用可能）と要求されている接続の特性（QoSシグナリングから利用可能）を使用して、リンク/ノードが接続を受け入れるか拒否するかを判断します。 MPLS GCACアルゴリズムが接続を受け入れる可能性が高いと判断した場合はリンク/ノードが含まれ、そうでない場合は除外されます。
MPLS GCAC bandwidth allocation parameters for each DS-TE CT are as defined within DS-TE [RFC4126], OSPF-TE extensions [RFC4203], and IS-IS-TE extensions [RFC5307]. The following parameters are available from DS-TE/TE extensions, advertised by the IGP, and available to the GEF and GCF [RFC4124]. Note that the approach presented in this section is adapted from [PNNI], Appendix B.
各DS-TE CTのMPLS GCAC帯域幅割り当てパラメーターは、DS-TE [RFC4126]、OSPF-TE拡張[RFC4203]、およびIS-IS-TE拡張[RFC5307]で定義されています。以下のパラメーターは、DS-TE / TE拡張機能から利用可能で、IGPによってアドバタイズされ、GEFおよびGCF [RFC4124]で利用可能です。このセクションで説明するアプローチは、[PNNI]の付録Bから採用されていることに注意してください。
MRBk Maximum reservable bandwidth on link k specifies the maximum bandwidth that may be reserved; this may be greater than the maximum link bandwidth, in which case the link may be oversubscribed.
MRBkリンクkで予約可能な最大帯域幅は、予約できる最大帯域幅を指定します。これは、最大リンク帯域幅よりも大きい場合があります。その場合、リンクがオーバーサブスクライブされる可能性があります。
BWCck Bandwidth constraint for CTc on link k = allocated (minimum guaranteed) bandwidth for CTc on link k.
リンクkのCTcのBWCck帯域幅制約=リンクkのCTcに割り当てられた（最低保証）帯域幅。
ULBCck Unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc.
リンクk上のCTcのULBCck未予約リンク帯域幅は、CTc用にまだ予約されていない帯域幅の量を指定します。
Note that BWCck and ULBCck are the only DS-TE parameters flooded by the IGP [RFC4124][RFC4203][RFC5307]. For example, when bandwidth reservation is used [RFC4126], ULBCck is calculated and flooded by the IGP as follows:
BWCckおよびULBCckは、IGP [RFC4124] [RFC4203] [RFC5307]によってフラッディングされる唯一のDS-TEパラメータであることに注意してください。たとえば、帯域幅予約が使用される場合[RFC4126]、ULBCckは次のように計算され、IGPによってフラッディングされます。
RBTk Reservation bandwidth threshold for link k.
RBTkリンクkの予約帯域幅しきい値。
ULBCck Unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc, taking RBTk into account,
リンクk上のCTcのULBCck未予約リンク帯域幅は、RBTkを考慮して、CTc用にまだ予約されていない帯域幅の量を指定します。
ULBCck = ULBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
Also derivable at the GEF and GCF is MRBCck, the maximum reservable link bandwidth for CTc. For example, when bandwidth reservation is used [RFC4126], MRBCck is calculated as follows:
GEFおよびGCFで導出可能なのはMRBCckです。これは、CTcの予約可能な最大リンク帯域幅です。たとえば、帯域幅予約が使用される場合[RFC4126]、MRBCckは次のように計算されます。
MRBCck Maximum reservable link bandwidth for CTc on link k specifies the amount of bandwidth not yet reserved for CTc.
MRBCckリンクk上のCTcの予約可能な最大リンク帯域幅は、CTc用にまだ予約されていない帯域幅の量を指定します。
MRBCck = MRBk - delta0/1(CTck) * RBTk
where
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck >= BWCck
Note that these bandwidth parameters must be configured in a consistent way within domains and across domains. GEF routing of LSPs is based on ULBCck, where ULBk is available and RBTk can be accounted for by configuration, e.g., RBTk typically = .05 * MRBk.
これらの帯域幅パラメーターは、ドメイン内およびドメイン間で一貫した方法で構成する必要があることに注意してください。 LSPのGEFルーティングはULBCckに基づいており、ULBkが利用可能であり、RBTkは構成によって説明できます。たとえば、RBTkは通常= .05 * MRBkです。
Also available are administrative weight (denoted as "link cost" in [RFC2328]), TE metric [RFC3630], and administrative group (also called color) 4-octet mask [RFC3630].
また、管理上の重み（[RFC2328]では「リンクコスト」と表記）、TEメトリック[RFC3630]、および管理グループ（カラーとも呼ばれます）4オクテットマスク[RFC3630]も利用できます。
The following quantities can be derived from information advertised by the IGP and otherwise available to the GEF and GCF:
以下の量は、IGPによってアドバタイズされ、そうでなければGEFおよびGCFが利用できる情報から導出できます。
RBWck Reserved bandwidth on CTc on link k (0 <= c <= MaxCT-1).
RBWckリンクkのCTcで予約されている帯域幅（0 <= c <= MaxCT-1）。
RBWck = total amount of bandwidth reserved by all established LSPs that belong to CTc RBWck = BWCck - ULBCck.
RBWck = CTcに属するすべての確立されたLSPによって予約された帯域幅の総量RBWck = BWCck-ULBCck。
ULBk Unreserved link bandwidth on link k specifies the amount of bandwidth not yet reserved for any CT.
リンクkのULBk未予約リンク帯域幅は、CTにまだ予約されていない帯域幅の量を指定します。
ULBk = MRBk - sum [RBWck (0 <= c <= MaxCT-1)].
ULBk = MRBk-合計[RBWck（0 <= c <= MaxCT-1）]。
The GCAC algorithm assumes that a DS-TE bandwidth constraints model is used uniformly within each domain (e.g., MAR [RFC4126], MAM [RFC4125], or RDM [RFC4127]). European Advanced Networking Test Center (EANTC) testing [EANTC] has shown that interoperability is problematic when different DS-TE bandwidth constraints models are used by different network elements within a domain. Specific testing of MAM and RDM across different vendor equipment showed the incompatibility. However, while the characteristics of the 3 DS-TE bandwidth constraints models are quite different, it is necessary to specify interworking between them even though it could be complex.
GCACアルゴリズムは、DS-TE帯域幅制約モデルが各ドメイン内で均一に使用されることを前提としています（たとえば、MAR [RFC4126]、MAM [RFC4125]、またはRDM [RFC4127]）。 European Advanced Networking Test Center（EANTC）テスト[EANTC]は、ドメイン内のさまざまなネットワーク要素によってさまざまなDS-TE帯域幅制約モデルが使用されている場合、相互運用性に問題があることを示しています。異なるベンダーの機器にわたるMAMおよびRDMの特定のテストでは、非互換性が示されました。ただし、3つのDS-TE帯域幅制約モデルの特性はまったく異なりますが、複雑な場合でも、モデル間の相互作用を指定する必要があります。
The following parameters are also defined and available to GCF and are assumed to be locally configured to be a consistent value across all nodes and domain(s):
次のパラメータも定義されており、GCFで使用できます。また、すべてのノードとドメインで一貫した値になるようにローカルで設定されていると想定されています。
SBWck Sustained bandwidth for CTc on link k (aggregate of existing connections).
SBWckリンクkのCTcの持続帯域幅（既存の接続の集約）。
SBWck = factor * RBWck where factor is configured based on standard 'demand overbooking' factors.
SBWck =係数* RBWckここで、係数は標準の「デマンドオーバーブッキング」係数に基づいて設定されます。
VFck Variance factor for CTc on link k; VFck is BWMck normalized by variance of SBWck. VFck is configured based on typical traffic variability statistics.
リンクkのCTcのVFck分散係数。 VFckは、SBWckの分散によって正規化されたBWMckです。 VFckは、一般的なトラフィック変動統計に基づいて構成されます。
In many implementations of the Private Network-Network Interface (PNNI) GCAC algorithm, the variance factor is not included, or equivalently, VFck is assumed to be zero. A simplified MPLS GCAC algorithm is also derived assuming VFck = 0.
Private Network-Network Interface（PNNI）GCACアルゴリズムの多くの実装では、分散係数が含まれていないか、同等に、VFckがゼロであると想定されます。簡略化されたMPLS GCACアルゴリズムも、VFck = 0と仮定して導出されます。
Note that different demand overbooking factors can be specified for each CT, e.g., no overbooking might be used for constant bitrate services, while a large overbooking factor might be used for bursty variable bitrate services. We specify demand overbooking rather than link overbooking for the GCAC algorithm; one advantage is the demand overbooking is compatible with source routing used by the GCAC algorithm.
CTごとに異なるデマンドオーバーブッキング係数を指定できることに注意してください。たとえば、オーバーブッキングは一定のビットレートサービスに使用されない場合があり、大きなオーバーブッキング係数はバースト性の可変ビットレートサービスに使用される場合があります。 GCACアルゴリズムのリンクオーバーブッキングではなく、デマンドオーバーブッキングを指定します。 1つの利点は、需要のオーバーブッキングがGCACアルゴリズムで使用されるソースルーティングと互換性があることです。
Also defined is
また、定義されています
BWMck bandwidth margin for CTc on link k; BWMck = RBWck - SBWck
GEF uses BWCck, RBWck, ULBCck, SBWck, BWMck, and VFck for LSP/IGP routing. GEF also needs to track per-CT LSP bandwidth allocation and reserved bandwidth parameters, which are defined as follows:
GEFは、LSC / IGPルーティングにBWCck、RBWck、ULBCck、SBWck、BWMck、およびVFckを使用します。 GEFは、CTごとのLSP帯域幅割り当てと予約済み帯域幅パラメーターを追跡する必要もあります。これらのパラメーターは次のように定義されています。
RBWLcl reserved bandwidth for CTc on LSP l
LSP l上のCTcのRBWLcl予約帯域幅
UBWLcl unreserved bandwidth for CTc on LSP l
LSP lのCTc用に予約されていない帯域幅
The assumption behind the MPLS GCAC is that the ratio between the bandwidth margin that the node is putting above the sustained bandwidth and the standard deviation of the sustained bandwidth does not change significantly as one new aggregate flow is added on the link. Any ingress node doing path selection can then compute the new standard deviation of the aggregate rate (from the old value and the aggregate flow's traffic descriptors) and an estimate of the new BWMck. From this, the increase in bandwidth required to carry the new aggregate flow can be computed and compared to BWCck.
MPLS GCACの背後にある想定は、ノードが維持帯域幅を上回っている帯域幅マージンと維持帯域幅の標準偏差との比率は、リンクに新しい集約フローが1つ追加されても大幅に変化しないことです。次に、パス選択を行うすべての入口ノードは、（古い値と集約フローのトラフィック記述子からの）集約レートの新しい標準偏差と新しいBWMckの推定値を計算できます。これから、新しい集約フローを伝送するために必要な帯域幅の増加を計算し、BWCckと比較できます。
To expand on the discussion above, let RBWck denote the reserved bandwidth capacity, i.e., the amount of bandwidth that has been allocated to existing aggregate flows for CTc on link k by the actual CAC used in the node. BWMck is the difference between RBWck and the aggregate sustained bandwidth (SBWck) of the existing aggregate flows. SBWck can be either the sum of existing aggregate flows' declared sustainable bandwidth (SBWi for aggregate flow i) or a smaller (possibly measured or estimated) value. Let MRBCck denote the maximum reservable bandwidth that is usable by aggregate flows for CTc on link k. The following diagram illustrates the relationship among MRBCck, RBWck, BWMck, SBWck, and ULBCck:
上記の説明をさらに詳しく説明するため、RBWckで予約済みの帯域幅容量、つまりノードで使用されている実際のCACによってリンクkのCTcの既存の集約フローに割り当てられている帯域幅の量を示します。 BWMckは、RBWckと既存の集約フローの集約持続帯域幅（SBWck）の違いです。 SBWckは、既存の集約フローの宣言された持続可能な帯域幅（集約フローiのSBWi）の合計か、またはより小さな（おそらく測定または推定された）値のいずれかです。 MRBCckが、リンクk上のCTcの集約フローによって使用可能な予約可能な最大帯域幅を示すものとします。次の図は、MRBCck、RBWck、BWMck、SBWck、ULBCckの関係を示しています。
|<-- BWMck-->|<----- ULBCck ----->|
|---------------|------------|--------------------|
0 SBWck RBWck MRBCck
The assumption is that BWMck is proportional to some measure of the burstiness of the traffic generated by the existing aggregate flows, this measure being the standard deviation of the aggregate traffic rate defined as the square root of the sum of SBWi(PBWi - SBWi) over all existing aggregate flows, where SBWi and PBWi are declared sustainable and peak bandwidth for aggregate flow i, respectively. This assumption is based on the simple argument that RBWck needs to be some multiple of the standard deviation above the mean aggregate traffic rate to guarantee some level of packet loss ratio and packet queuing time. Depending on the actual CAC used, the BWMck-to-standard-deviation ratio may vary as aggregate flows are established and taken down. It is reasonable to assume, however, that with a sufficiently large value of RBWck, this ratio will not vary significantly. What this means is a link can advertise its current BWMck-to-standard-deviation ratio (actually in the form of VF, which is the square of this number), and the MPLS GCAC algorithm can use this number to estimate how much bandwidth is required to carry an additional aggregate flow.
BWMckは、既存の集約フローによって生成されたトラフィックのバースト性の測定値に比例するという仮定です。この測定値は、SBWi（PBWi-SBWi）の合計の平方根として定義された集約トラフィックレートの標準偏差です。既存のすべての集約フロー。SBWiおよびPBWiは、それぞれ集約フローiの持続可能な帯域幅とピーク帯域幅として宣言されています。この仮定は、あるレベルのパケット損失率とパケットキューイング時間を保証するために、RBWckは平均総トラフィックレートを超える標準偏差の倍数である必要があるという単純な議論に基づいています。使用される実際のCACに応じて、BWMckと標準偏差の比率は、集約フローが確立および削除されるときに変化する可能性があります。ただし、RBWckの値が十分に大きければ、この比率は大きく変化しないと想定するのが妥当です。これが意味することは、リンクが現在のBWMckと標準偏差の比率（実際にはこの数値の2乗であるVFの形式）をアドバタイズでき、MPLS GCACアルゴリズムがこの数値を使用して帯域幅の量を推定できることです追加の集約フローを実行する必要があります。
Following the derivation given in [PNNI], Appendix B, the MPLS GCAC algorithm is derived as follows. Consider an aggregate flow bandwidth change request DBWi with peak bandwidth PBWi and sustainable bandwidth SBWi and a link with the following MPLS GCAC parameters: ULBCck, BWMck, and VFck for CTc and link k. Denote the variance (i.e., square of standard deviation) of the aggregate traffic rate by VARk (not advertised). Denote other unadvertised MPLS GCAC quantities by RBWck and SBWck. Then,
[PNNI]の付録Bに記載されている導出に従って、MPLS GCACアルゴリズムは次のように導出されます。ピーク帯域幅PBWiと持続可能な帯域幅SBWiを備えた集約フロー帯域幅変更要求DBWi、およびMPLS GCACパラメーターがULBCck、BWMck、およびCTcとリンクkのVFckを備えたリンクを検討してください。 VARk（アドバタイズされていない）による総トラフィックレートの分散（つまり、標準偏差の2乗）を示します。アドバタイズされていない他のMPLS GCAC量をRBWckおよびSBWckで示します。そして、
VARk = SUM SBWi*(PBWi-SBWi) (1) over existing aggregate flows i
VARk = SUM SBWi *（PBWi-SBWi）（1）既存の集約フローi
and
そして
BWMck**2
VFck = ---------- (2)
VARk
Using the above equation, VARk can be computed from the advertised VFck and BWMck as:
上記の方程式を使用して、VARkは、アドバタイズされたVFckおよびBWMckから次のように計算できます。
VARk = (BWMck**2)/VFck.
Let DBWi be the additional bandwidth capacity needed to carry the flow within aggregate sustainable bandwidth SBWi. The MPLS GCAC algorithm basically computes DBWi from the advertised MPLS GCAC parameters and the new aggregate flow's traffic descriptors, and compares it with ULBCck. If ULBCck >= DBWi, then the link is included for path selection consideration; otherwise, it is excluded, i.e.,
総持続可能な帯域幅SBWi内でフローを伝送するために必要な追加の帯域幅容量をDBWiとします。 MPLS GCACアルゴリズムは基本的に、アドバタイズされたMPLS GCACパラメータと新しい集約フローのトラフィック記述子からDBWiを計算し、ULBCckと比較します。 ULBCck> = DBWiの場合、リンクはパス選択の考慮に含まれます。それ以外の場合は除外されます。
If (ULBCck >= DBWi), then include link k; else exclude link k (3) Let BWMcknew denote the bandwidth margin if the new aggregate flow were accepted. Denote other 'new' quantities by RBWcknew, SBWcknew, and VARnew. Then,
（ULBCck> = DBWi）の場合、リンクkを含めます。 else exclude link k（3）新しい集約フローが受け入れられた場合、帯域幅マージンをBWMcknewに表示させます。 RBWcknew、SBWcknew、およびVARnewによって他の「新しい」数量を示します。そして、
DBWi = BWMcknew - BWMck + SBWi (4)
since BWMcknew = RBWcknew - SBWcknew, BWMck = RBWck - SBWck, and SBWcknew - SBWck = SBWi. Substituting (4) into (3), rearranging terms, and squaring both sides yield:
BWMcknew = RBWcknew-SBWcknew、BWMck = RBWck-SBWck、およびSBWcknew-SBWck = SBWiであるため。 （4）を（3）に代入し、用語を並べ替え、両側を二乗すると、次のようになります。
If ((ULBCck+BWMck-SBWck)**2 >= BWMcknew**2), then include link k;
else exclude link k (5)
Using the MPLS GCAC assumption made earlier, BWMcknew**2 can be computed as:
前に作成したMPLS GCACの仮定を使用して、BWMcknew ** 2は次のように計算できます。
BWMcknew**2 = VFck * VARnew, (6)
Where
ただし
VARnew = VARk + SBWck * (PBWi-SBWi). (7)
Substituting (2), (6) and (7) into (5) yields:
（2）、（6）、（7）を（5）に代入すると、次のようになります。
If ((ULBCck+BWMck-SBWi)**2 >= BWMck**2 + VFck*SBWi(PBWi-SBWi)),
then include link k;
else exclude link k (8)
and moving BWMck**2 to the left-hand side and rearranging terms yield
そしてBWMck ** 2を左側に移動し、項を並べ替えると、yield
If ((ULBCck-SBWi) * (ULBCck-SBWi+2*BWMck) >= VFck*SBWi(PBWi-SBWi),
then include link k;
else exclude link k (9)
Equation (9) represents the Constrained Shortest Path First (CSPF) method implemented by most vendors and deployed by most service providers in MPLS networks. In general, DBWi is between SBWi and PBWi. So, the above test is not necessary for the cases ULBCck >= PBWi and ULBCck < SBWi. In the former case, the link is included; in the latter case, the link is excluded.
式（9）は、ほとんどのベンダーによって実装され、MPLSネットワーク内のほとんどのサービスプロバイダーによって展開された制約付き最短パス優先（CSPF）メソッドを表します。一般に、DBWiはSBWiとPBWiの間にあります。したがって、上記のテストは、ULBCck> = PBWiおよびULBCck <SBWiの場合には必要ありません。前者の場合、リンクは含まれています。後者の場合、リンクは除外されます。
Exclude Include
|<--- link ---->|<-- Test (9)-->|<--- link ----->|
|---------------|---------------|----------------| ULBCck
SBWi PBWi
Note that VF and BWM are frequently not implemented; equivalently, these quantities are assumed to be zero, in which case Equation (9) becomes
VFとBWMはしばしば実装されていないことに注意してください。同様に、これらの量はゼロであると仮定されます。その場合、式（9）は次のようになります。
If (ULBCck >= SBWi), then include link k; else exclude link k (10)
Exclude Include
|<--- link ---->|<--- link ----->|
|---------------|----------------| ULBCck
SBWi PBWi
PNNI GCAC implementations often do not incorporate the variance factor VF, in which case Equation (10) is used.
PNNI GCACの実装には、分散係数VFが組み込まれていないことがよくあります。この場合、式（10）が使用されます。
MPLS GCAC must not reject a best-effort (BE, unassigned bandwidth) aggregate flow request based on bandwidth availability, but it may reject based on other reasons such as the number of BE flows exceeding a chosen threshold. MPLS GCAC defines only one parameter for the BE service category -- maximum bandwidth (MBW) -- to advertise how much capacity is usable for BE flows. The purpose of advertising this parameter is twofold: MBW can be used for path optimization, and MBW = 0 is used to indicate that a link is not accepting any (additional) BE flows.
MPLS GCACは、帯域幅の可用性に基づいてベストエフォート（BE、未割り当ての帯域幅）集約フロー要求を拒否することはできませんが、BEフローの数が選択したしきい値を超えるなど、他の理由に基づいて拒否する場合があります。 MPLS GCACは、BEサービスカテゴリの1つのパラメータ（最大帯域幅（MBW））のみを定義して、BEフローに使用可能な容量を通知します。このパラメータをアドバタイズする目的は2つあります。MBWはパスの最適化に使用でき、MBW = 0はリンクが（追加の）BEフローを受け入れないことを示すために使用されます。
Demand overbooking of LSP bandwidth is employed and must be compliant with [RFC4124] and [RFC3270] to over-/undersubscribe requested capacity. It is simplest to use only one oversubscription method, i.e., the GCAC algorithm assumes oversubscription of demands per CT, both within domains and for interworking between domains. The motivation is that interworking may be infeasible between domains if different overbooking models are used. Note that the same assumption was made for DS-TE bandwidth constraints models, in that the GCAC algorithm assumes a consistent DS-TE bandwidth constraints model is used within each domain and interoperability of bandwidth constraints models across domains.
LSP帯域幅のデマンドオーバーブッキングが採用されており、[RFC4124]および[RFC3270]に準拠して、要求された容量をオーバーサブスクライブ/アンダーサブスクライブする必要があります。オーバーサブスクリプション方式を1つだけ使用するのが最も簡単です。つまり、GCACアルゴリズムは、ドメイン内とドメイン間のインターワークの両方で、CTごとのデマンドのオーバーサブスクリプションを想定しています。動機は、異なるオーバーブッキングモデルが使用されている場合、ドメイン間でのインターワーキングが実行できない可能性があることです。同じ前提がDS-TE帯域幅制約モデルに対しても行われたことに注意してください。GCACアルゴリズムは、一貫したDS-TE帯域幅制約モデルが各ドメイン内で使用され、ドメイン間での帯域幅制約モデルの相互運用性を前提としています。
It needs to be clearly understood that all routers contain local and implementation-specific rules (or algorithms) to help them determine what to do with traffic that exceeds capacity and how to admit new flows. If these rules are poorly designed or implemented with defects, then problems may be observed in the network. Furthermore, the implementation of such algorithms provides a mechanism for attacking the delivery of traffic within the network. In view of this, routers and their software are usually extensively tested before deployment, router vendors are extended a degree of trust, and a "compromised router" (i.e., one on which an attacker has installed their own code) is considered a weak spot in the system. Note that if a router is compromised, it can be made to do substantially more problematic things than simply modifying the admission control algorithm. Implementers are RECOMMENDED to ensure that software modifications to routers are fully secured, and operators are RECOMMENDED to apply security measures (that are outside the scope of this document) to prevent unauthorized updates to router software. Nothing in this document suggests any change to normal software security practices.
すべてのルーターにはローカルおよび実装固有のルール（またはアルゴリズム）が含まれており、容量を超えるトラフィックをどう処理するか、および新しいフローを許可する方法を決定するのに役立つことを明確に理解する必要があります。これらのルールの設計または実装に欠陥があると、ネットワークで問題が発生する可能性があります。さらに、そのようなアルゴリズムの実装は、ネットワーク内のトラフィックの配信を攻撃するメカニズムを提供します。これを考慮して、ルーターとそのソフトウェアは通常、展開前に広範囲にテストされ、ルーターベンダーはある程度の信頼を拡大し、「侵害されたルーター」（つまり、攻撃者が独自のコードをインストールしたルーター）は弱点と見なされますシステム内。ルーターが危険にさらされている場合、アドミッションコントロールアルゴリズムを単に変更するよりも、実質的に問題の多いことを行うようにできることに注意してください。ルーターへのソフトウェア変更が完全に保護されていることを確認するために実装者は推奨されます。また、ルーターソフトウェアへの不正な更新を防ぐためにセキュリティ対策（このドキュメントの範囲外）を適用することをオペレーターに推奨します。このドキュメントでは、通常のソフトウェアセキュリティ慣行の変更を示唆するものはありません。
The use of a GCAC priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such user attacks at the interface to the user, for example:
GCAC優先度パラメーターを使用すると、ユーザーが実際の必要なしにフローの緊急優先度を要求できるため、サービスの盗難攻撃の可能性が高まり、深刻な緊急通話の通過を効果的に防止できます。ユーザーへのインターフェースで、このようなユーザー攻撃に対抗するためのいくつかのオプションが存在します。次に例を示します。
- Only some user groups (e.g., police) are authorized to set the emergency priority bit using a policy applied to RSVP-TE signaling.
- RSVP-TEシグナリングに適用されるポリシーを使用して緊急優先ビットを設定する権限があるのは、一部のユーザーグループ（警察など）だけです。
- Any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police) using a policy applied to RSVP-TE signaling.
- すべてのユーザーは、RSVP-TEシグナリングに適用されるポリシーを使用して、特定の宛先アドレス（たとえば、警察）に緊急優先ビットを使用することを許可されます。
- If an attack occurs, the user/group and actions taken should be logged to trace the attack.
- 攻撃が発生した場合、攻撃を追跡するために、ユーザー/グループと実行されたアクションをログに記録する必要があります。
- [RFC5069] identifies a number of security threats against emergency call marking and mapping. Section 6 of [RFC5069] lists security requirements to counter these threats, and those requirements should be followed by implementations of this document.
- [RFC5069]は、緊急コールのマーキングとマッピングに対するセキュリティ上の脅威をいくつか特定しています。 [RFC5069]のセクション6には、これらの脅威に対抗するためのセキュリティ要件がリストされており、これらの要件の後にこのドキュメントの実装が続く必要があります。
- The security requirements listed in Section 11 of [RFC4412] should be followed. These requirements apply to use of the Communications Resource Priority Header for the Session Initiation Protocol (SIP) and concern aspects of authentication and authorization, confidentiality and privacy requirements, protection against denial-of-service attacks, and anonymity.
- [RFC4412]のセクション11に記載されているセキュリティ要件に従う必要があります。これらの要件は、Session Initiation Protocol（SIP）のCommunications Resource Priority Headerの使用に適用され、認証と承認、機密性とプライバシーの要件、サービス拒否攻撃に対する保護、および匿名性の側面に関係します。
Within the network, the policy and integrity mechanisms already present in RSVP-TE [RFC3209] can be used to ensure that the MPLS LSP has the right policy and security credentials to assume the signaled priority and bandwidth. Further discussion of this topic for the signaling of priority levels using RSVP can be found in [RFC6401]. Some similarities may also be drawn to the security issues surrounding the placement of emergency calls in Internet multimedia systems [RFC5069] although the concepts are only comparable at the highest levels.
ネットワーク内では、RSVP-TE [RFC3209]にすでに存在するポリシーと整合性のメカニズムを使用して、MPLS LSPに、通知された優先度と帯域幅を想定するための適切なポリシーとセキュリティ資格情報があることを確認できます。 RSVPを使用した優先度レベルのシグナリングに関するこのトピックの詳細については、[RFC6401]を参照してください。概念は最高レベルでのみ比較可能ですが、インターネットマルチメディアシステム[RFC5069]での緊急通話の配置を取り巻くセキュリティの問題にもいくつかの類似点が引き出される可能性があります。
Like any algorithm, the algorithm specified in this document operates on data that is supplied as input parameters. That data is assumed to be collected and stored locally (i.e., on the router performing the algorithm). It is a fundamental assumption of the secure operation of any router that the data stored on that router cannot be externally modified. In this particular case, it is important that the input parameters to the algorithm cannot be influenced by an outside party. Thus, as with all configuration parameters on a router, the implementer MUST supply and the operator is RECOMMENDED to use security mechanisms to protect writing of the configuration parameters for this algorithm.
他のアルゴリズムと同様に、このドキュメントで指定されているアルゴリズムは、入力パラメーターとして提供されるデータを操作します。そのデータは、ローカルで（つまり、アルゴリズムを実行するルーターで）収集および保存されると想定されています。ルーターに保存されているデータを外部から変更できないことは、ルーターが安全に動作することを前提としています。この特定のケースでは、アルゴリズムへの入力パラメーターが外部のパーティーの影響を受けないことが重要です。したがって、ルーターのすべての構成パラメーターと同様に、実装者はこのアルゴリズムの構成パラメーターの書き込みを保護するためにセキュリティメカニズムを使用することを提供しなければならず（MUST）、オペレーターは推奨されます。
The authors greatly appreciate Adrian Farrel's support in serving as the sponsoring Area Director for this document and for his valuable comments and suggestions on the document. The authors also greatly appreciate Young Lee serving as the document shepherd and his valuable comments and suggestions. Finally, Robert Sparks' thorough review and helpful suggestions are sincerely appreciated.
著者は、このドキュメントのスポンサーであるエリアディレクターとしての役目を果たし、このドキュメントに対する彼の貴重なコメントと提案を提供してくれたAdrian Farrelのサポートに非常に感謝しています。著者はまた、文書の羊飼いと彼の貴重なコメントや提案としての役目を果たしているヤング・リーを高く評価しています。最後に、ロバート・スパークスの徹底的なレビューと役立つ提案は心から感謝しています。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J. Heinanen、 "マルチプロトコルラベルスイッチング（MPLS）Support of Differentiated Services」、RFC 3270、2002年5月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F。、編、「Diffserv対応のMPLSトラフィックエンジニアリングをサポートするためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K。、編、およびY. Rekhter、編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、2005年10月。
[RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804] Le Faucheur、F。、編、「MPLS TE / DS-TEトンネルを介したResource ReSerVation Protocol（RSVP）予約の集約」、RFC 4804、2007年2月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920] Farrel、A.、Ed。、Satyanarayana、A.、Iwata、A.、Fujita、N。、およびG. Ash、「Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE」、RFC 4920、2007年7月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K。、編、およびY. Rekhter、編、「IS-IS Extensions in Supporting of Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 5307、2008年10月。
[BGP-TE] Gredler, H., Farrel, A., Medved, J., and S. Previdi, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, March 2012.
[BGP-TE] Gredler、H.、Farrel、A.、Medved、J。、およびS. Previdi、「BGPを使用したリンクステートおよびTE情報の北限定分布」、Work in Progress、2012年3月。
[EANTC] "Multi-vendor Carrier Ethernet Interoperability Event", Carrier Ethernet World Congress 2006, Madrid Spain, September 2006.
[EANTC]「マルチベンダーキャリアイーサネット相互運用イベント」、キャリアイーサネットワールドコングレス2006、マドリードスペイン、2006年9月。
[FEEDBACK] Ashwood-Smith, P., Jamoussi, B., Fedyk, D., and D. Skalecki, "Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol", Work in Progress, June 2003.
[フィードバック] Ashwood-Smith、P.、Jamoussi、B.、Fedyk、D。、およびD. Skalecki、「制約ベースのラベル配布プロトコルでのラベルスイッチドパスフィードバックによるトポロジデータベースの精度の向上」、作業中、2003年6月。
[OIF-E-NNI] Optical Interworking Forum (OIF), "External Network-Network Interface (E-NNI) OSPFv2-based Routing - 2.0 (Intra-Carrier) Implementation Agreement", IA # OIF-ENNI-OSPF-02.0, July 13, 2011.
[OIF-E-NNI]光インターワーキングフォーラム（OIF）、「外部ネットワークネットワークインターフェース（E-NNI）OSPFv2ベースルーティング-2.0（キャリア内）実装契約」、IA＃OIF-ENNI-OSPF-02.0、 2011年7月13日。
[PNNI] ATM Forum Technical Committee, "Private Network-Network Interface Specification Version 1.1 (PNNI 1.1)", af-pnni-0055.002, April 2002.
[PNNI] ATMフォーラム技術委員会、「Private Network-Network Interface Specification Version 1.1（PNNI 1.1）」、af-pnni-0055.002、2002年4月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、RFC 3246、2002年3月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、編、スワロー、G。、編、およびA.アトラス、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[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対応MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、2005年6月。
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005.
[RFC4126] Ash、J。、「Diffserv対応のMPLSトラフィックエンジニアリングとパフォーマンス比較のための予約帯域幅制約モデルを使用した最大割り当て」、RFC 4126、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。、編、「Diffserv対応のMPLSトラフィックエンジニアリングのためのロシアの人形の帯域幅制約モデル」、RFC 4127、2005年6月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinne、H.およびJ. Polk、「Communications Resource Priority for the Session Initiation Protocol（SIP）」、RFC 4412、2006年2月。
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、JP。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、Ed。、およびJL。 Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、2006年9月。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069] Taylor、T.、Ed。、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「セキュリティ上の脅威と緊急通話のマーキングとマッピングの要件」、RFC 5069、2008年1月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、2008年2月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、2009年2月。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010.
[RFC5865]ベイカー、F。、ポーク、J。、およびM.ドリー、「Capacity-Admitted TrafficのDiffServコードポイント（DSCP）」、RFC 5865、2010年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling 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] Manner、J.、Karagiannis、G。、およびA. McDonald、「Quality-of-Service SignalingのためのNSIS Signaling Layer Protocol（NSLP）」、RFC 5974、2010年10月。
[RFC5975] Ash, G., Ed., Bader, A., Ed., Kappler, C., Ed., and D. Oran, Ed., "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、編、「Quality-of-Service NSISシグナリング層プロトコル（ NSLP）」、RFC 5975、2010年10月。
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010.
[RFC5976] Ash、G.、Morton、A.、Dolly、M.、Tarapore、P.、Dvorak、C。、およびY. El Mghazli、「Y.1541-QOSM：Y.1541品質を使用するネットワークのモデル- of-Service Classes」、RFC 5976、2010年10月。
[RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP Extensions for Admission Priority", RFC 6401, October 2011.
[RFC6401] Le Faucheur、F.、Polk、J。、およびK. Carlberg、「RSVP Extensions for Admission Priority」、RFC 6401、2011年10月。
[TQO] Ash, G., "Traffic Engineering and QoS Optimization of Integrated Voice and Data Networks", Elsevier, 2006.
[TQO] Ash、G。、「統合された音声およびデータネットワークのトラフィックエンジニアリングとQoS最適化」、Elsevier、2006年。
Appendix A: Example MPLS GCAC Implementation Including Path Selection, Bandwidth Management, QoS Signaling, and Queuing
付録A：パス選択、帯域幅管理、QoSシグナリング、およびキューイングを含むMPLS GCAC実装の例
Figure 2 illustrates an example of the integrated voice/data MPLS GCAC method in which bandwidth is allocated on an aggregated basis to the individual DS-TE CTs. In the example method, CTs have different priorities including high-priority, normal-priority, and best-effort-priority services CTs. Bandwidth allocated to each CT is protected by bandwidth reservation methods, as needed, but bandwidth is otherwise shared among CTs. Each originating GEF monitors CT bandwidth use on each MPLS LSP [RFC3031] for each CT, and determines when CT LSP bandwidth needs to be increased or decreased. In Figure 2, changes in CT bandwidth capacity are determined by GEFs based on an overall aggregated bandwidth demand for CT capacity (not on a per-connection/per-flow demand basis). Based on the aggregated bandwidth demand, GEFs make periodic discrete changes in bandwidth allocation, that is, they either increase or decrease bandwidth on the LSPs constituting the CT bandwidth capacity. For example, if aggregate flow requests are made for CT LSP bandwidth that exceeds the current DS-TE tunnel bandwidth allocation, the GEF initiates a bandwidth modification request on the appropriate LSP(s). This may entail increasing the current LSP bandwidth allocation by a discrete increment of bandwidth denoted here as DBW, where DBW is the additional amount needed by the current aggregate flow request. The bandwidth admission control for each link in the path is performed by the GCF based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the different parameters (such as the reserved bandwidth threshold RBT shown in Figure 2) in the admission control procedure. Also, the GEF periodically monitors LSP bandwidth use, and if bandwidth use falls below the current LSP allocation, the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation to the current level of bandwidth utilization.
図2は、統合された音声/データMPLS GCAC方式の例を示しています。この方式では、帯域幅が集約ベースで個々のDS-TE CTに割り当てられます。方法の例では、CTには、高優先度、通常優先度、ベストエフォート優先度のサービスCTなど、さまざまな優先度があります。各CTに割り当てられた帯域幅は、必要に応じて帯域幅予約方式によって保護されますが、帯域幅はCT間で共有されます。各発信GEFは、各CTの各MPLS LSP [RFC3031]でのCT帯域幅の使用を監視し、CT LSP帯域幅を増減する必要がある時期を決定します。図2では、CT帯域幅容量の変化は、CT容量の全体的な総帯域幅需要に基づいて（接続ごと/フローごとの需要ベースではなく）、GEFによって決定されます。集約された帯域幅の需要に基づいて、GEFは帯域幅の割り当てを定期的に個別に変更します。つまり、CT帯域幅容量を構成するLSPの帯域幅を増減します。たとえば、現在のDS-TEトンネル帯域幅割り当てを超えるCT LSP帯域幅に対して集約フロー要求が行われた場合、GEFは適切なLSPで帯域幅変更要求を開始します。これには、ここでDBWとして示される帯域幅の離散的な増分によって、現在のLSP帯域幅割り当てを増やす必要がある場合があります。ここで、DBWは、現在の集約フロー要求に必要な追加の量です。パス内の各リンクの帯域幅アドミッション制御は、以下に説明する帯域幅割り当て手順を使用してリンクのステータスに基づいてGCFによって実行されます。ここで、さまざまなパラメーターの役割を説明します（予約済み帯域幅しきい値RBTなど）図2）アドミッションコントロール手順。また、GEFは定期的にLSP帯域幅の使用を監視し、帯域幅の使用が現在のLSP割り当てを下回った場合、GEFは帯域幅変更要求を開始して、LSP帯域幅の割り当てを現在の帯域幅使用率のレベルに減らします。
HIGH-PRIORITY-CT LSP
+----+======================+----+======================+----+
|GEF1|NORMAL-PRIORITY-CT LSP| VN | |GEF2|
| |======================| |======================| |
| |LOW-PRIORITY/BE-CT LSP| | | |
+----+======================+----+======================+----+
LEGEND
------
BE - Best Effort
CT - Class Type
GEF - GCAC Edge Function
LSP - Label Switched Path
VN - Via Node
o Distributed bandwidth allocation method applied on a per-class-type (CT) LSP basis
o クラスタイプ（CT）LSPベースで適用される分散帯域幅割り当て方法
o GEF allocates bandwidth to each CTc LSP based on demand
o GEFは、需要に基づいて各CTc LSPに帯域幅を割り当てます
- GEF decides CTc LSP bandwidth increase based on
- GEFは、以下に基づいてCTc LSP帯域幅の増加を決定します
+ aggregate flow sustained bandwidth (SBWi) and variance factor VFck
+ 総フロー持続帯域幅（SBWi）と分散係数VFck
+ routing priority (high, normal, best effort)
+ ルーティング優先度（高、通常、ベストエフォート）
+ CTc reserved bandwidth (RBWck) and bandwidth constraint (BWCck)
+ CTc予約帯域幅（RBWck）および帯域幅制約（BWCck）
+ link reserved bandwidth threshold (RBTk) and unreserved bandwidth (ULBk)
+ リンク予約帯域幅しきい値（RBTk）および予約されていない帯域幅（ULBk）
- GEF periodically decreases CTc LSP bandwidth allocation based on bandwidth use
- GEFは、帯域幅の使用に基づいてCTc LSP帯域幅の割り当てを定期的に減らします
o VNs send crankback messages to GEF if DS-TE/MAR bandwidth allocation rules not met
o DS-TE / MAR帯域幅割り当てルールが満たされない場合、VNはクランクバックメッセージをGETに送信します
o Link(s) not meeting request excluded from TE topology database before attempting another explicit route computation
o 別の明示的なルート計算を試行する前に、TEトポロジデータベースから除外された要求を満たさないリンク
Figure 2: Per-Class-Type (CT) LSP Bandwidth Management
図2：クラスごとのタイプ（CT）LSP帯域幅管理
GEF uses SBWi, VFck, RBWck, BWCck, RBTk, and ULBk for LSP bandwidth allocation decisions and IGP routing and uses RBWcl and UBWcl to track per-CT LSP bandwidth allocation and reserved bandwidth. In making a CT bandwidth allocation modification, the GEF determines the CT priority (high, normal, or best effort), CT bandwidth-in-use, and CT bandwidth allocation thresholds. These parameters are used to determine whether network capacity can be allocated for the CT bandwidth modification request.
GEFはLSP帯域幅割り当ての決定とIGPルーティングにSBWi、VFck、RBWck、BWCck、RBTk、およびULBkを使用し、RBWclおよびUBWclを使用してCTごとのLSP帯域幅割り当てと予約済み帯域幅を追跡します。 GEFは、CT帯域幅割り当ての変更を行う際に、CT優先度（高、通常、またはベストエフォート）、CT使用中帯域幅、およびCT帯域幅割り当てのしきい値を決定します。これらのパラメーターは、CT帯域幅変更要求にネットワーク容量を割り当てることができるかどうかを決定するために使用されます。
In OSPF, link-state flooding is used to make status updates. This is a state-dependent routing (SDR) method where CSPF is typically used to alter LSP routing according to the state of the network. In general, SDR methods calculate a path cost for each connection request based on various factors such as the load state or congestion state of the links in the network. In contrast, the example MPLS GCAC algorithm uses event-dependent routing (EDR), where LSP routing is updated locally on the basis of whether connections succeed or fail on a given path choice. In the EDR learning approaches, the path that was last tried successfully is tried again until congested, at which time another path is selected at random and tried on the next connection request. EDR path choices can also be changed with time in accordance with changes in traffic load patterns. Success-to-the-top (STT) EDR path selection, illustrated in Figure 3, uses a simplified decentralized learning method to achieve flexible adaptive routing. The primary path (path-p) is used first if available, and a currently successful alternate path (path-s) is used until it is congested. In the case that path-s is congested (e.g., bandwidth is not available on one or more links), a new alternate path (path-n) is selected at random as the alternate path choice for the next connection request overflow from the primary path. Bandwidth reservation is used under congestion conditions to protect traffic on the primary path. STT-EDR uses crankback when an alternate path is congested at a via node, and the connection request advances to a new random path choice. In STT-EDR, many path choices can be tried by a given connection request before the request is rejected.
OSPFでは、リンクステートフラッディングを使用してステータスを更新します。これは状態依存ルーティング（SDR）方式であり、CSPFは通常、ネットワークの状態に応じてLSPルーティングを変更するために使用されます。一般に、SDRメソッドは、ネットワーク内のリンクの負荷状態や輻輳状態などのさまざまな要因に基づいて、各接続要求のパスコストを計算します。対照的に、MPLS GCACアルゴリズムの例では、イベント依存型ルーティング（EDR）を使用しています。LSPルーティングは、特定のパス選択で接続が成功するか失敗するかに基づいてローカルで更新されます。 EDR学習アプローチでは、最後に正常に試行されたパスが輻輳するまで再試行されます。このとき、別のパスがランダムに選択され、次の接続要求で試行されます。 EDRパスの選択は、トラフィック負荷パターンの変化に応じて時間とともに変更することもできます。図3に示す成功からトップ（STT）までのEDRパス選択では、簡素化された分散型学習手法を使用して、柔軟な適応ルーティングを実現します。プライマリパス（path-p）が使用可能な場合は最初に使用され、現在成功している代替パス（path-s）が輻輳するまで使用されます。 path-sが混雑している（たとえば、1つ以上のリンクで帯域幅が利用できない）場合、新しい代替パス（path-n）がランダムに選択され、プライマリからの次の接続要求オーバーフローの代替パスの選択肢として道。帯域幅予約は、プライマリパス上のトラフィックを保護するために輻輳状態で使用されます。 STT-EDRは、代替パスが経由ノードで輻輳しているときにクランクバックを使用し、接続要求は新しいランダムパスの選択に進みます。 STT-EDRでは、要求が拒否される前に、特定の接続要求で多くのパスの選択を試行できます。
Figure 3 illustrates the example MPLS GCAC operation of STT-EDR path selection and admission control combined with per-CT bandwidth allocation. GEF A monitors CT bandwidth use on each CT LSP and determines when CT LSP bandwidth needs to be increased or decreased. Based on the bandwidth demand, GEF A makes periodic discrete changes in bandwidth allocation, that is, either increases or decreases bandwidth on the LSPs constituting the CT bandwidth capacity. If aggregate flow requests are made for CT LSP bandwidth that exceeds the current LSP bandwidth allocation, GEF A initiates a bandwidth modification request on the appropriate LSP(s).
図3は、CTごとの帯域幅割り当てと組み合わせたSTT-EDRパス選択とアドミッション制御のMPLS GCAC動作の例を示しています。 GEF Aは、各CT LSPでのCT帯域幅の使用を監視し、CT LSP帯域幅を増減する必要がある時期を決定します。帯域幅の需要に基づいて、GEF Aは帯域幅の割り当てを定期的に個別に変更します。つまり、CT帯域幅容量を構成するLSPの帯域幅を増減します。現在のLSP帯域幅割り当てを超えるCT LSP帯域幅に対して集約フロー要求が行われた場合、GEF Aは適切なLSPで帯域幅変更要求を開始します。
|<----- ULBk <= RBTk ---->|
LSP-p |------------------------|-------------------------|
A B E
|<-- ULBk <= RBTk -->|
LSP-s |---------------|--------------------|-------------|
A C D E
Example of STT-EDR routing method:
STT-EDRルーティング方法の例：
1. If node A to node E bandwidth needs to be modified (say increased by DBW), primary LSP-p (e.g., LSP A-B-E) is tried first.
1. ノードAからノードEの帯域幅を変更する必要がある場合（たとえば、DBWによって増加）、プライマリLSP-p（たとえば、LSP A-B-E）が最初に試行されます。
2. Available bandwidth is tested locally on each link in LSP-p. If bandwidth not available (e.g., unreserved bandwidth on link BE is less than the reserved bandwidth threshold and this CT is above its bandwidth allocation), crankback to node A.
2. 使用可能な帯域幅は、LSP-pの各リンクでローカルにテストされます。帯域幅が利用できない場合（たとえば、リンクBEの予約されていない帯域幅が予約済みの帯域幅のしきい値よりも低く、このCTが帯域幅の割り当てを超えている場合）、ノードAにクランクバックします。
3. If DBW is not available on one or more links of LSP-p, then the currently successful LSP-s (e.g., LSP A-C-D-E) is tried next.
3. LSP-pの1つ以上のリンクでDBWが利用できない場合は、次に現在成功しているLSP-s（LSP A-C-D-Eなど）が試されます。
4. If DBW is not available on one or more links of LSP-s, then a new LSP is searched by trying additional candidate paths until a new successful LSP-n is found or the candidate paths are exhausted.
4. LSP-sの1つ以上のリンクでDBWが利用できない場合、新しい成功したLSP-nが見つかるか、候補パスが使い果たされるまで、追加の候補パスを試行することにより、新しいLSPが検索されます。
5. LSP-n is then marked as the currently successful path for the next time bandwidth needs to be modified.
5. LSP-nは、次に帯域幅を変更する必要があるときに、現在成功しているパスとしてマークされます。
Figure 3: STT-EDR Path Selection and Per-CT Bandwidth Allocation
図3：STT-EDRパスの選択とCTごとの帯域幅の割り当て
For example, in Figure 3, if the LSR-A to LSR-E bandwidth needs to be modified, say increased by DBW, the primary LSP-p (A-B-E) is tried first. The bandwidth admission control for each link in the path is performed based on the status of the link using the bandwidth allocation procedure described below, where we further describe the role of the reserved bandwidth RBWck shown in Figure 3 in the admission control procedure. If the first choice LSP cannot admit the bandwidth change, node A may then try an alternate LSP. If DBW is not available on one or more links of LSP-p, then the currently successful LSP-s A-C-D-E (the 'STT path') is tried next. If DBW is not available on one or more links of LSP-s, then a new LSP is searched by trying additional candidate paths (not shown) until a new successful LSP-n is found or all of the candidate paths held in the cache are exhausted. LSP-n is then marked as the currently successful path for the next time bandwidth needs to be modified. DBW is set to the additional amount of bandwidth required by the aggregate flow request.
たとえば、図3で、LSR-AからLSR-Eへの帯域幅を変更する必要がある場合、たとえばDBWを増やす場合、プライマリLSP-p（A-B-E）が最初に試行されます。パス内の各リンクの帯域幅アドミッション制御は、以下で説明する帯域幅割り当て手順を使用してリンクのステータスに基づいて実行されます。ここで、アドミッション制御手順における図3に示す予約済み帯域幅RBWckの役割についてさらに説明します。最初の選択肢のLSPが帯域幅の変更を許可できない場合、ノードAは代替のLSPを試行できます。 LSP-pの1つ以上のリンクでDBWが使用できない場合、次に現在成功しているLSP-s A-C-D-E（「STTパス」）が試行されます。 LSP-sの1つ以上のリンクでDBWが利用できない場合、新しい成功したLSP-nが見つかるか、キャッシュに保持されているすべての候補パスが見つかるまで、追加の候補パス（図示せず）を試して新しいLSPを検索します。疲れきった。 LSP-nは、次に帯域幅を変更する必要があるときに、現在成功しているパスとしてマークされます。 DBWは、集約フロー要求に必要な追加の帯域幅に設定されます。
If all cached candidate paths are tried without success, the search then generates a new CSPF path. If a new CSPF calculation succeeds in finding a new path, that path is made the stored path, and the bottom cached path falls off the list. If all cached paths fail and a new CSPF path cannot be found, then the original stored LSP is retained. New requests go through the same routing algorithm again, since available bandwidth, etc., has changed and new requests might be admitted. Also, GEF A periodically monitors LSP bandwidth use (e.g., once each 2-minute interval), and if bandwidth use falls below the current LSP allocation, the GEF initiates a bandwidth modification request to decrease the LSP bandwidth allocation to the currently used bandwidth level. Bandwidth reservation occurs in STT-EDR with PATH/RESV messages per application of [RFC4804].
キャッシュされたすべての候補パスが試行されても成功しない場合、検索は新しいCSPFパスを生成します。新しいCSPF計算が新しいパスの検索に成功した場合、そのパスは保存されたパスになり、キャッシュされた最後のパスはリストから外れます。キャッシュされたパスがすべて失敗し、新しいCSPFパスが見つからない場合、元の保存されたLSPが保持されます。利用可能な帯域幅などが変更され、新しい要求が許可される可能性があるため、新しい要求は同じルーティングアルゴリズムを再度通過します。また、GEF AはLSP帯域幅の使用を定期的に監視し（たとえば、2分間隔で1回）、帯域幅の使用量が現在のLSP割り当てを下回ると、GEFは帯域幅変更要求を開始して、LSP帯域幅割り当てを現在使用されている帯域幅レベルに減らします。帯域幅予約は、[RFC4804]のアプリケーションごとにPATH / RESVメッセージを使用してSTT-EDRで発生します。
In the STT-EDR computation, most of the time the primary path and stored path will succeed, and no CSPF calculation needs to be done. Therefore, the STT-EDR algorithm achieves good throughput performance while significantly reducing link-state flooding control load [TQO]. An analogous method was proposed in the MPLS working group [FEEDBACK], where feedback based on failed path routing attempts is kept by the TE database and used when running CSPF.
STT-EDR計算では、ほとんどの場合、プライマリパスと保存されたパスは成功し、CSPF計算を実行する必要はありません。したがって、STT-EDRアルゴリズムは、リンク状態のフラッディング制御負荷[TQO]を大幅に削減しながら、優れたスループットパフォーマンスを実現します。類似の方法がMPLSワーキンググループ[FEEDBACK]で提案されました。失敗したパスルーティング試行に基づくフィードバックはTEデータベースによって保持され、CSPFの実行時に使用されます。
In the example GCAC method, bandwidth allocation to the primary and alternate LSPs uses the MAR bandwidth allocation procedure, as described below. Path selection uses a topology database that includes available bandwidth on each link. From the topology database pruned of links that do not meet the bandwidth constraint, the GEF determines a list of shortest paths by using a shortest path algorithm (e.g., Bellman-Ford or Dijkstra methods). This path list is determined based on administrative weights of each link, which are communicated to all nodes within the routing domain (e.g., administrative weight = 1 + e x distance, where e is a factor giving a relatively smaller weight to the distance in comparison to the hop count). Analysis and simulation studies of a large national network model show that 6 or more primary and alternate cached paths provide the best overall performance.
GCACメソッドの例では、プライマリLSPと代替LSPへの帯域幅割り当ては、以下で説明するように、MAR帯域幅割り当て手順を使用します。パスの選択では、各リンクで使用可能な帯域幅を含むトポロジデータベースを使用します。帯域幅の制約を満たさないリンクを取り除いたトポロジデータベースから、GEFは最短パスアルゴリズム（Bellman-FordやDijkstraメソッドなど）を使用して最短パスのリストを決定します。このパスリストは、ルーティングドメイン内のすべてのノードに通信される各リンクの管理上の重みに基づいて決定されます（たとえば、管理上の重み= 1 + ex距離。ここで、eは、ホップ数）。大規模な全国ネットワークモデルの分析とシミュレーションの調査では、6つ以上のプライマリキャッシュパスと代替キャッシュパスが全体的なパフォーマンスが最高であることが示されています。
PCE [RFC4655][RFC4657][RFC5440] is used to implement inter-area/inter-AS/ inter-SP path selection algorithms, including alternate path selection, path reoptimization, backup path computation to protect DS-TE tunnels, and inter-area/inter-AS/inter-SP traffic engineering. The DS-TE tunnels are protected against failure by using MPLS Fast Reroute [RFC4090]. OSPF TE extensions [RFC4203] are used to support the TE database (TED) required for implementation of the above PCE path selection methods.
PCE [RFC4655] [RFC4657] [RFC5440]は、エリア間/ AS間/ SP間パス選択アルゴリズムを実装するために使用されます。これには、代替パス選択、パス再最適化、DS-TEトンネルを保護するためのバックアップパス計算、およびエリア/ AS間/ SP間トラフィックエンジニアリング。 DS-TEトンネルは、MPLS Fast Reroute [RFC4090]を使用することにより、障害から保護されています。 OSPF TE拡張[RFC4203]は、上記のPCEパス選択方法の実装に必要なTEデータベース（TED）をサポートするために使用されます。
The example MPLS GCAC method incorporates the MAR bandwidth constraint model [RFC4126] incorporated within DS-TE [RFC4124]. In DS-TE/MAR, a small amount of reserved bandwidth RBTk governs the admission control on link k. Associated with each CTc on link k are the allocated bandwidth constraints BWCck to govern bandwidth allocation and protection. The reservation bandwidth on a link, RBTk, can be accessed when a given CTc has reserved bandwidth RBWck below its allocated bandwidth constraint BWCck. However, if RBWck exceeds its allocated bandwidth constraint BWCck, then the reservation bandwidth threshold RBTk cannot be accessed. In this way, bandwidth can be fully shared among CTs if available but is otherwise protected by bandwidth reservation methods. Therefore, bandwidth can be accessed for a bandwidth request = DBW for CTc on a given link k based on the following rules:
MPLS GCACメソッドの例には、DS-TE [RFC4124]に組み込まれているMAR帯域幅制約モデル[RFC4126]が組み込まれています。 DS-TE / MARでは、少量の予約済み帯域幅RBTkがリンクkのアドミッション制御を管理します。リンクkの各CTcには、帯域幅の割り当てと保護を管理するために割り当てられた帯域幅制約BWCckが関連付けられています。リンク上の予約帯域幅RBTkは、特定のCTcが割り当てられた帯域幅制約BWCck未満の帯域幅RBWckを予約したときにアクセスできます。ただし、RBWckが割り当てられた帯域幅制約BWCckを超えると、予約帯域幅しきい値RBTkにアクセスできません。このようにして、帯域幅は、利用可能な場合はCT間で完全に共有できますが、それ以外の場合は帯域幅予約方法によって保護されます。したがって、次のルールに基づいて、特定のリンクk上のCTcの帯域幅要求= DBWに対して帯域幅にアクセスできます。
For an LSP on a high-priority or normal-priority CTc:
高優先度または通常優先度のCTc上のLSPの場合：
If RBWck = BWCc, admit if DBW = ULBk
If RBWck > BWCc, admit if DBW = ULBk - RBTk;
or, equivalently:
または、同等に：
If DBW = ULBCck, admit the LSP.
DBW = ULBCckの場合、LSPを許可します。
where
ただし
ULBCck = idle link bandwidth on link k for CTc = ULBk -
delta0/1(CTck) x RBWk
delta0/1(CTck) = 0 if RBWck < BWCck
delta0/1(CTck) = 1 if RBWck = BWCck
For an LSP on a best-effort-priority CTc:
ベストエフォート優先のCTcのLSPの場合：
allocated bandwidth BWCc = 0; Diffserv queuing serves best-effort packets only if there is available link bandwidth.
割り当てられた帯域幅BWCc = 0; Diffservキューイングは、使用可能なリンク帯域幅がある場合にのみ、ベストエフォートパケットを提供します。
In setting the bandwidth constraints for CTck, for a normal-priority CTc, the bandwidth constraints (BWCck) on link k are set by allocating the maximum reservable link bandwidth (MRBk) in proportion to the forecast or measured traffic load bandwidth TRAF_LOAD_BWck for CTc on link k. That is: PROPORTIONAL_ BWck = TRAF_LOAD_ BWck/[S (c) {TRAF_LOAD_ BWck, c=0, MaxCT-1}] x MRBk
CTckの帯域幅制約を設定する際、通常優先度CTcの場合、リンクkの帯域幅制約（BWCck）は、予測または測定されたトラフィック負荷帯域幅TRAF_LOAD_BWckに比例して最大予約可能リンク帯域幅（MRBk）を割り当てることにより設定されます。リンクk。つまり、PROPORTIONAL_ BWck = TRAF_LOAD_ BWck / [S（c）{TRAF_LOAD_ BWck、c = 0、MaxCT-1}] x MRBk
For a normal-priority CTc: BWCck = PROPORTIONAL_ BWck
通常優先度のCTcの場合：BAck = PROPORTIONAL BAck
For a high-priority CT, the bandwidth constraint BWCck is set to a multiple of the proportional bandwidth. That is:
高優先度CTの場合、帯域幅制約BWCckは比例帯域幅の倍数に設定されます。あれは：
For high-priority CTc: BWCck = FACTOR * PROPORTIONAL_ BWck
優先度の高いCTcの場合：BWCc = FACTOR * PROPORTIONAL BAck
where FACTOR is set to a multiple of the proportional bandwidth (e.g., FACTOR = 2 or 3 is typical). This results in some over-allocation ('overbooking') of the link bandwidth and gives priority to the high-priority CTs. Normally, the bandwidth allocated to high-priority CTs should be a relatively small fraction of the total link bandwidth, a maximum of 10-15 percent being a reasonable guideline.
ここで、FACTORは比例帯域幅の倍数に設定されています（たとえば、FACTOR = 2または3が一般的です）。これにより、リンク帯域幅が過剰に割り当てられ（「オーバーブッキング」）、優先度の高いCTが優先されます。通常、優先度の高いCTに割り当てられる帯域幅は、合計リンク帯域幅の比較的小さな割合である必要があり、最大10〜15％が妥当なガイドラインです。
As stated above, the bandwidth allocated to a best-effort-priority CTc is set to zero. That is:
上記のように、ベストエフォート優先のCTcに割り当てられる帯域幅はゼロに設定されます。あれは：
For a best-effort-priority CTc: BWCck = 0
ベストエフォート優先のCTcの場合：BWCck = 0
Analysis and simulation studies show that the level of reserved capacity RBTk in the range of 3-5% of link capacity provides the best overall performance.
分析とシミュレーションの調査では、リンク容量の3〜5％の範囲の予約容量RBTkのレベルが全体的なパフォーマンスで最高であることが示されています。
We give a simple example of the MAR bandwidth allocation method. Assume that there are two class types, CT0 and CT1, and a particular link with
MAR帯域幅割り当て方法の簡単な例を示します。 CT0とCT1の2つのクラスタイプがあり、特定のリンクが
MRB = 100
with the allocated bandwidth constraints set as follows:
割り当てられた帯域幅の制約を次のように設定します。
BWC0 = 30 BWC1 = 50
BWC0 = 30 BWC1 = 50
These bandwidth constraints are based on the forecasted traffic loads, as discussed above. Either CT is allowed to exceed its bandwidth constraint BWCc as long a there is at least RBW units of spare bandwidth remaining. Assume RBT = 10. So under overload, if
これらの帯域幅の制約は、前述のように、予測されるトラフィック負荷に基づいています。予備の帯域幅が少なくともRBWユニット残っている限り、どちらのCTも帯域幅制約BWCcを超えることができます。 RBT = 10と仮定します。
RBW0 = 20 RBW1 = 70 Then, for this loading
RBW0 = 20 RBW1 = 70次に、この負荷に対して
UBW = 100 - 20 - 70 = 10
If a bandwidth increase request = 5 = DBW arrives for Class Type 0 (CT0), then accept for CT0 since RBW0 < BWC0 and DBW (= 5) < ILBW (= 10).
帯域幅増加要求= 5 = DBWがクラスタイプ0（CT0）に到着した場合、RBW0 <BWC0およびDBW（= 5）<ILBW（= 10）であるため、CT0を受け入れます。
If a bandwidth increase request = 5 = DBW arrives for Class Type 1 (CT1), then reject for CT1 since RBW1 > BC1 and DBW (= 5) > ILBW - RBT = 10 - 10 = 0.
帯域幅増加要求= 5 = DBWがクラスタイプ1（CT1）に到着した場合、RBW1> BC1およびDBW（= 5）> ILBW-RBT = 10-10 = 0であるため、CT1を拒否します。
Therefore, CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC value. CT1, however, can no longer increase its bandwidth on the link, since it is above its BWC value and there is only RBT=10 units of idle bandwidth left on the link. If best effort traffic is present, it can always seize whatever idle bandwidth is available on the link at the moment but is subject to being lost at the queues in favor of the higher-priority traffic.
したがって、CT0はBWC値を下回っているため、要求が到着すると追加の帯域幅（最大10ユニット）を取ることができます。ただし、CT1はBWC値を上回り、リンクに残っているアイドル帯域幅はRBT = 10ユニットしかないため、リンク上の帯域幅を増やすことはできません。ベストエフォートトラフィックが存在する場合、リンクで現在使用可能なアイドル帯域幅を常に捕捉できますが、優先度の高いトラフィックのためにキューで失われる可能性があります。
On the other hand, if a request arrives to increase bandwidth for CT1 by 5 units of bandwidth (i.e., DBW = 5), we need to decide whether or not to admit this request. Since for CT1,
一方、CT1の帯域幅を5単位増加する要求が到着した場合（つまり、DBW = 5）、この要求を許可するかどうかを決定する必要があります。 CT1以来、
RBW1 > BWC1 (70 > 50), and
DBW > UBW - RBT (i.e., 5 > 10 - 10)
the bandwidth request is rejected by the bandwidth allocation rules given above. Now let's say a request arrives to increase bandwidth for CT0 by 5 units of bandwidth (i.e., DBW = 5). We need to decide whether or not to admit this request. Since for CT0
帯域幅要求は、上記の帯域幅割り当てルールによって拒否されます。ここで、CT0の帯域幅を5単位の帯域幅（つまり、DBW = 5）増やす要求が到着したとしましょう。このリクエストを受け入れるかどうかを決定する必要があります。 CT0以来
RBW0 < BWC0 (20 < 30), and
DBW < UBW (i.e., 5 < 10)
The example illustrates that with the current state of the link and the current CT loading, CT1 can no longer increase its bandwidth on the link, since it is above its BWC1 value and there is only RBW=10 units of spare bandwidth left on the link. But CT0 can take the additional bandwidth (up to 10 units) if the demand arrives, since it is below its BWC0 value.
この例は、リンクの現在の状態と現在のCT負荷により、CT1がBWC1値を超えており、リンクにRBW = 10ユニットの予備帯域幅しか残っていないため、リンク上の帯域幅をこれ以上増やすことができないことを示しています。 。ただし、CT0はBWC0値を下回っているため、要求が到着すると追加の帯域幅（最大10ユニット）を取ることができます。
For the example GCAC, the method for bandwidth additions and deletions to LSPs in is as follows. The bandwidth constraint parameters defined in the MAR method [RFC4126] do not change based on traffic conditions. In particular, these parameters defined in [RFC4126], as described above, are configured and do not change until reconfigured: MRBk, BWCck, and RBTk. However, the reserved bandwidth variables change based on traffic: RBWck, ULBk, and ULBCck. The RBWck and bandwidth allocated to each DS-TE/MAR tunnel is dynamically changed based on traffic: it is increased when the traffic demand increases (using RSVP aggregation), and it is periodically decreased when the traffic demand decreases. Furthermore, if tunnel bandwidth cannot be increased on the primary path, an alternate LSP path is tried. When LSP tunnel bandwidth needs to be increased to accommodate a given aggregate flow request, the bandwidth is increased by the amount of the needed additional bandwidth, if possible. The tunnel bandwidth quickly rises to the currently needed maximum bandwidth level, wherein no further requests are made to increase bandwidth, since departing flows leave a constant amount of available or spare bandwidth in the tunnel to use for new requests. Tunnel bandwidth is reduced every 120 seconds by 0.5 times the difference between the allocated tunnel bandwidth and the current level of the actually utilized bandwidth (i.e., the current level of spare bandwidth). Analysis and simulation modeling results show that these parameters provide the best performance across a number of overload and failure scenarios.
GCACの例では、でのLSPへの帯域幅の追加と削除の方法は次のとおりです。 MAR方式[RFC4126]で定義されている帯域幅制約パラメータは、トラフィック条件に基づいて変化しません。特に、上記のように[RFC4126]で定義されているこれらのパラメーターは、MRBk、BWCck、およびRBTkのように構成され、再構成されるまで変更されません。ただし、予約済みの帯域幅変数は、RBWck、ULBk、およびULBCckのトラフィックに基づいて変化します。各DS-TE / MARトンネルに割り当てられたRBWckと帯域幅は、トラフィックに基づいて動的に変更されます。これらは、トラフィック要求が増加すると（RSVP集約を使用して）増加し、トラフィック要求が減少すると定期的に減少します。さらに、トンネル帯域幅をプライマリパスで増加できない場合は、代替LSPパスが試行されます。特定の集約フロー要求に対応するためにLSPトンネル帯域幅を増やす必要がある場合、可能であれば、必要な追加帯域幅の分だけ帯域幅が増加します。トンネルの帯域幅は、現在必要な最大帯域幅レベルまで急速に上昇します。ここで、帯域幅を増やすための追加の要求は行われません。これは、出発するフローがトンネルに一定量の利用可能な帯域幅または予備の帯域幅を残して、新しい要求に使用するためです。トンネル帯域幅は、120秒ごとに、割り当てられたトンネル帯域幅と実際に使用されている帯域幅の現在のレベル（つまり、予備の帯域幅の現在のレベル）の差の0.5倍減少します。分析およびシミュレーションモデリングの結果は、これらのパラメーターが多数の過負荷および障害シナリオにわたって最高のパフォーマンスを提供することを示しています。
The example GCAC method uses Next Steps in Signaling (NSIS) algorithms for signaling MPLS GCAC QoS requirements of individual flows. NSIS QoS signaling has been specified by the IETF NSIS working group and extends RSVP signaling by defining a two-layer QoS signaling model:
GCACメソッドの例では、個々のフローのMPLS GCAC QoS要件をシグナリングするために、シグナリング（NSIS）アルゴリズムの次のステップを使用します。 NSIS QoSシグナリングは、IETF NSISワーキンググループによって指定されており、2層QoSシグナリングモデルを定義することでRSVPシグナリングを拡張しています。
o NSIS Transport Layer Protocol (NTLP) [RFC5971]
o NSISトランスポート層プロトコル（NTLP）[RFC5971]
o NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling [RFC5974]
o サービス品質のシグナリングのためのNSISシグナリングレイヤープロトコル（NSLP）[RFC5974]
[RFC5975] defines a QoS specification (QSPEC) object, which contains the QoS parameters required by a QoS model (QOSM) [RFC5976]. A QOSM specifies the QoS parameters and procedures that govern the resource management functions in a QoS-aware router. Multiple QOSMs can be supported by the QoS-NSLP, and the QoS-NSLP allows stacking of QSPEC parameters to accommodate different QOSMs being used in different domains. As such, NSIS provides a mechanism for interdomain QoS signaling and interworking.
[RFC5975]は、QoSモデル（QOSM）[RFC5976]に必要なQoSパラメータを含むQoS仕様（QSPEC）オブジェクトを定義します。 QOSMは、QoS対応ルーターのリソース管理機能を管理するQoSパラメーターと手順を指定します。 QoS-NSLPは複数のQOSMをサポートできます。QoS-NSLPを使用すると、QSPECパラメータをスタックして、さまざまなドメインで使用されているさまざまなQOSMに対応できます。そのため、NSISはドメイン間QoSシグナリングとインターワーキングのメカニズムを提供します。
The QSPEC parameters defined in [RFC5975] include, among others:
[RFC5975]で定義されているQSPECパラメータには、特に次のものが含まれます。
TRAFFIC DESCRIPTION Parameters:
トラフィックの説明パラメータ：
o <Traffic Model> Parameters
o <トラフィックモデル>パラメータ
CONSTRAINTS Parameters:
CONSTRAINTSパラメータ：
o <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER>
Parameters
o <PHB Class> Parameter
o <PHBクラス>パラメータ
o <DSTE Class Type> Parameter
o <DSTEクラスタイプ>パラメータ
o <Y.1541 QoS Class> Parameter
o <Y.1541 QoSクラス>パラメータ
o <Reservation Priority> Parameter
o <予約優先>パラメータ
o <Preemption Priority> and <Defending Priority> Parameters
The ability to achieve end-to-end QoS through multiple Internet domains is also an important requirement. MPLS GCAC end-to-end QoS signaling ensures that end-to-end QoS is met by applying the Y.1541-QOSM [RFC5976], as now illustrated.
複数のインターネットドメインを介してエンドツーエンドのQoSを実現する機能も重要な要件です。 MPLS GCACエンドツーエンドQoSシグナリングは、次に示すように、Y.1541-QOSM [RFC5976]を適用することにより、エンドツーエンドQoSが確実に満たされるようにします。
The QoS GEF initiates an end-to-end, inter-domain QoS RESERVE message containing the QoS parameters, including for example, <Traffic Model>, <Y.1541 QoS Class>, <Reservation Priority>, and perhaps other parameters for the flow. The RESERVE message may cross multiple domains; each node on the data path checks the availability of resources and accumulating the delay, delay variation, and loss ratio parameters, as described below. If an intermediate node cannot accommodate the new request, the reservation is denied. If no intermediate node has denied the reservation, the RESERVE message is forwarded to the next domain. If any node cannot meet the requirements designated by the RESERVE message to support a QoS parameter, for example, it cannot support the accumulation of end-to-end delay with the <Path Latency> parameter, the node sets a flag that will deny the reservation. Also, parameter negotiation can be done, for example, by setting the <Y.1541 QoS Class> to a lower class than specified in the RESERVE message. When the available <Y.1541 QoS Class> must be reduced from the desired <Y.1541 QoS Class>, say because the delay objective has been exceeded, then there is an incentive to respond to the GEF with an available value for delay in the <Path Latency> parameter. For example, if the available <Path Latency> is 150 ms (still useful for many applications) and the desired QoS is 100 ms (according to the desired <Y.1541 QoS Class> Class 0), then the response would be that Class 0 cannot be achieved and Class 1 is available (with its 400 ms objective). In addition, the response includes an available <Path Latency> = 150 ms, making acceptance of the available <Y.1541 QoS Class> more likely.
QoS GEFは、<Traffic Model>、<Y.1541 QoS Class>、<Reservation Priority>などのQoSパラメータを含むエンドツーエンドのドメイン間QoS RESERVEメッセージを開始します。フロー。 RESERVEメッセージは複数のドメインにまたがることがあります。以下で説明するように、データパス上の各ノードは、リソースの可用性をチェックし、遅延、遅延変動、および損失率パラメーターを蓄積します。中間ノードが新しい要求に対応できない場合、予約は拒否されます。予約を拒否した中間ノードがない場合、RESERVEメッセージは次のドメインに転送されます。 RESERVEメッセージで指定された要件を満たせずにQoSパラメータをサポートできないノードがある場合、たとえば、<Path Latency>パラメータを使用したエンドツーエンドの遅延の蓄積をサポートできない場合、ノードはフラグを設定して、予約。また、パラメータのネゴシエーションは、たとえば、<Y.1541 QoSクラス>をRESERVEメッセージで指定されたものよりも低いクラスに設定することで実行できます。利用可能な<Y.1541 QoSクラス>を目的の<Y.1541 QoSクラス>から減らす必要がある場合、たとえば、遅延の目標を超えたために、GEFに遅延の利用可能な値で応答するインセンティブがあります。 <Path Latency>パラメータ。たとえば、利用可能な<Path Latency>が150ミリ秒（多くのアプリケーションで依然として有用）であり、望ましいQoSが100ミリ秒（望ましい<Y.1541 QoSクラス>クラス0による）である場合、応答はそのクラスになります。 0は達成できず、クラス1が使用可能です（400 msの目標を使用）。さらに、応答には利用可能な<Path Latency> = 150 msが含まれるため、利用可能な<Y.1541 QoS Class>を受け入れる可能性が高くなります。
In this MPLS GCAC example, queuing behaviors for the CT traffic priorities incorporates Diffserv mechanisms and assumes separate queues based on Traffic Class (TC)/CoS bits. The queuing implementation assumes 3 levels of priority: high, normal, and best effort. These queues include two EF priority queues [RFC3246][RFC5865], with the highest priority assigned to emergency traffic (GETS/ETS/E911) and the second priority assigned to normal-priority real-time (e.g., VoIP) traffic. Separate AF queues [RFC2597] are used for data services, such as premium private data and premium public data traffic, and a separate best-effort queue is assumed for the best-effort traffic. All queues have static bandwidth allocation limits applied based on the level of forecast traffic on each link, such that the bandwidth limits will not be exceeded under normal conditions, allowing for some traffic overload. In the MPLS GCAC method, high-priority, normal-priority, and best-effort traffic share the same network; under congestion, the Diffserv priority-queuing mechanisms push out the best-effort-priority traffic at the queues so that the normal-priority and high-priority traffic can get through on the MPLS-allocated LSP bandwidth.
このMPLS GCACの例では、CTトラフィックの優先度のキューイング動作にDiffservメカニズムが組み込まれており、トラフィッククラス（TC）/ CoSビットに基づいて個別のキューを想定しています。キューイングの実装では、高、通常、ベストエフォートの3つの優先度を想定しています。これらのキューには、2つのEF優先度キュー[RFC3246] [RFC5865]が含まれ、最も高い優先度が緊急トラフィック（GETS / ETS / E911）に割り当てられ、2番目の優先度が通常優先度のリアルタイム（VoIPなど）トラフィックに割り当てられます。個別のAFキュー[RFC2597]は、プレミアムプライベートデータやプレミアムパブリックデータトラフィックなどのデータサービスに使用され、ベストエフォートトラフィックには個別のベストエフォートキューが想定されます。すべてのキューには、各リンクの予測トラフィックのレベルに基づいて適用される静的な帯域幅割り当て制限があり、通常の状態では帯域幅制限を超えないため、トラフィックの過負荷が許容されます。 MPLS GCAC方式では、高優先度、通常優先度、ベストエフォートのトラフィックが同じネットワークを共有します。輻輳下では、Diffservプライオリティキューイングメカニズムがキューでベストエフォートプライオリティトラフィックを押し出すので、通常のプライオリティとハイプライオリティのトラフィックは、MPLSが割り当てたLSP帯域幅を通過できます。
Authors' Addresses
著者のアドレス
Gerald Ash (editor) AT&T
ジェラルド・アッシュ（編集者）AT＆T
EMail: gash5107@yahoo.com
Dave McDysan Verizon 22001 Loudoun County Pkwy Ashburn, VA 20147
Dave McDysan Verizon 22001 Loudoun County Pkwy Ashburn、VA 20147
EMail: dave.mcdysan@verizon.com