[要約] RFC 5339は、既存のGMPLSプロトコルをMLN/MRNに対して評価するためのガイドラインです。その目的は、異なるレイヤーや地域を持つネットワークにおいて、GMPLSプロトコルの適用性と性能を評価することです。
Network Working Group JL. Le Roux, Ed.
Request for Comments: 5339 France Telecom
Category: Informational D. Papadimitriou, Ed.
Alcatel-Lucent
September 2008
Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)
マルチレイヤーおよびマルチリージョンネットワーク（MLN/MRN）に対する既存のGMPLSプロトコルの評価
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions.
このドキュメントは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）プロトコルの評価と、マルチレイヤーネットワーク（MLNS）およびマルチリージョンネットワーク（MRN）の要件に対するメカニズムを提供します。さらに、このドキュメントは、これらの要件を満たすために追加のプロトコル拡張または手順が必要な領域を特定し、潜在的な拡張のガイドラインを提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. MLN/MRN Requirements Overview ...................................4
3. Analysis ........................................................5
3.1. Aspects of Multi-Layer Networks ............................5
3.1.1. Support for Virtual Network Topology
Reconfiguration .....................................5
3.1.1.1. Control of FA-LSPs Setup/Release ...........5
3.1.1.2. Virtual TE Links ...........................6
3.1.1.3. Traffic Disruption Minimization
during FA Release ..........................8
3.1.1.4. Stability ..................................8
3.1.2. Support for FA-LSP Attribute Inheritance ............9
3.1.3. FA-LSP Connectivity Verification ....................9
3.1.4. Scalability .........................................9
3.1.5. Operations and Management of the MLN/MRN ...........10
3.1.5.1. MIB Modules ...............................10
3.1.5.2. OAM .......................................11
3.2. Specific Aspects of Multi-Region Networks .................12
3.2.1. Support for Multi-Region Signaling .................12
3.2.2. Advertisement of Adjustment Capacities .............13
4. Evaluation Conclusion ..........................................16
4.1. Traceability of Requirements ..............................16
5. Security Considerations ........................................20
6. Acknowledgments ................................................20
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................21
8. Contributors' Addresses ........................................23
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: packet switching, layer-2 switching, TDM (Time Division Multiplexing) switching, wavelength switching, and fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) concept is introduced for these switching technologies and is designated as follows: PSC (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM capable, LSC (Lambda Switch Capable), and FSC (Fiber Switch Capable). The representation, in a GMPLS control plane, of a switching technology domain is referred to as a region [RFC4206]. A switching type describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a network region.
一般化されたMPLS（GMPLS）は、MPLSを拡張して複数のスイッチング技術を処理するために拡張します：パケットスイッチング、レイヤー2スイッチング、TDM（時間除算マルチプレックス）スイッチング、波長スイッチング、およびファイバースイッチング（[RFC3945を参照]）。インターフェイススイッチング機能（ISC）の概念は、これらのスイッチングテクノロジーに導入され、次のように指定されています：PSC（パケットスイッチ対応）、L2SC（レイヤー2スイッチ対応）、TDM対応、LSC（Lambdaスイッチ対応）、FSC（ファイバースイッチ対応）。SwitchingテクノロジードメインのGMPLSコントロールプレーンでの表現は、領域[RFC4206]と呼ばれます。スイッチングタイプは、特定のデータプレーンテクノロジーのデータを転送するノードの能力を説明し、ネットワーク領域を一意に識別します。
A data plane switching layer describes a data plane switching granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are three different layers. [RFC5212] defines a Multi-Layer Network (MLN) to be a Traffic Engineering (TE) domain comprising multiple data plane switching layers either of the same ISC (e.g., TDM) or different ISC (e.g., TDM and PSC) and controlled by a single GMPLS control plane instance. [RFC5212] further defines a particular case of MLNs. A Multi-Region Network (MRN) is defined as a TE domain supporting at least two different switching types (e.g., PSC and TDM), either hosted on the same device or on different ones, and under the control of a single GMPLS control plane instance.
データプレーンスイッチングレイヤーは、データプレーンの切り替え粒度レベルを記述します。たとえば、LSC、TDM VC-11、TDM VC-4-64Cは3つの異なる層です。[RFC5212]は、同じISC（TDMなど）または異なるISC（TDMおよびPSCなど）のいずれかの複数のデータプレーンスイッチングレイヤーを含むトラフィックエンジニアリング（TE）ドメインであるマルチ層ネットワーク（MLN）を定義します。単一のGMPLSコントロールプレーンインスタンス。[RFC5212]は、MLNSの特定のケースをさらに定義します。マルチリージョンネットワーク（MRN）は、同じデバイスでホストされ、単一のGMPLSコントロールプレーンの制御下で、少なくとも2つの異なるスイッチングタイプ（PSCおよびTDMなど）をサポートするTEドメインとして定義されます。実例。
The objectives of this document are to evaluate existing GMPLS mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471], [RFC3473]) against the requirements for MLNs and MRNs, defined in [RFC5212]. From this evaluation, we identify several areas where additional protocol extensions and modifications are required in order to meet these requirements, and we provide guidelines for potential extensions.
このドキュメントの目的は、既存のGMPLSメカニズムとプロトコル（[RFC3945]、[RFC4202]、[RFC3471]、[RFC3473]）をMLNおよびMRNの要件に対して評価することです。この評価から、これらの要件を満たすために追加のプロトコル拡張と変更が必要ないくつかの領域を特定し、潜在的な拡張のガイドラインを提供します。
A summary of MLN/MRN requirements is provided in Section 2. Then Section 3 evaluates whether current GMPLS protocols and mechanisms meet each of these requirements. When the requirements are not met by existing protocols, the document identifies whether the required mechanisms could rely on GMPLS protocols and procedure extensions, or whether it is entirely out of the scope of GMPLS protocols.
MLN/MRN要件の概要はセクション2に記載されています。次に、セクション3では、現在のGMPLSプロトコルとメカニズムがこれらの各要件を満たしているかどうかを評価します。要件が既存のプロトコルによって満たされない場合、ドキュメントは、必要なメカニズムがGMPLSプロトコルと手順拡張に依存できるかどうか、またはGMPLSプロトコルの範囲外であるかどうかを特定します。
Note that this document specifically addresses GMPLS control plane functionality for MLN/MRN in the context of a single administrative control plane partition. Partitions of the control plane where separate layers are under distinct administrative control are for future study.
このドキュメントは、単一の管理制御プレーンパーティションのコンテキストで、MLN/MRNのGMPLS制御プレーン機能を特別に対処していることに注意してください。別々の層が明確な管理下にある制御プレーンのパーティションは、将来の研究のためです。
This document uses terminologies defined in [RFC3945], [RFC4206], and [RFC5212].
このドキュメントでは、[RFC3945]、[RFC4206]、および[RFC5212]で定義された用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Section 5 of [RFC5212] lists a set of functional requirements for Multi-Layer/Region Networks (MLN/MRN). These requirements are summarized below, and a mapping with sub-sections of [RFC5212] is provided.
[RFC5212]のセクション5には、多層/地域ネットワーク（MLN/MRN）の一連の機能要件がリストされています。これらの要件を以下に要約し、[RFC5212]のサブセクションを使用したマッピングを提供します。
Here is the list of requirements that apply to MLN (and thus to MRN):
MLN（したがってmRNに）に適用される要件のリストは次のとおりです。
- Support for robust Virtual Network Topology (VNT) reconfiguration. This implies the following requirements:
- 堅牢な仮想ネットワークトポロジ（VNT）再構成のサポート。これは、次の要件を意味します。
- Optimal control of Forwarding Adjacency Label Switched Path (FA-LSP) setup and release (Section 5.8.1 of [RFC5212]);
- 転送隣接ラベルスイッチ付きパス（FA-LSP）のセットアップとリリースの最適な制御（[RFC5212]のセクション5.8.1）;
- Support for virtual TE links (Section 5.8.2 of [RFC5212]);
- 仮想TEリンクのサポート（[RFC5212]のセクション5.8.2）;
- Minimization of traffic disruption during FA-LSP release (Section 5.5 of [RFC5212]);
- FA-LSPリリース中の交通破壊の最小化（[RFC5212]のセクション5.5）;
- Stability (Section 5.4 of [RFC5212]);
- 安定性（[RFC5212]のセクション5.4）;
- Support for FA-LSP attribute inheritance (Section 5.6 of [RFC5212]);
- FA-LSP属性継承のサポート（[RFC5212]のセクション5.6）;
- Support for FA-LSP data plane connectivity verification (Section 5.9 of [RFC5212]);
- FA-LSPデータプレーン接続検証のサポート（[RFC5212]のセクション5.9）;
- MLN Scalability (Section 5.3 of [RFC5212]);
- MLNスケーラビリティ（[RFC5212]のセクション5.3）;
- MLN Operations and Management (OAM) (Section 5.10 of [RFC5212]);
- MLNオペレーションと管理（OAM）（[RFC5212]のセクション5.10）;
Here is the list of requirements that apply to MRN only:
MRNのみに適用される要件のリストは次のとおりです。
- Support for Multi-Region signaling (Section 5.7 of [RFC5212]);
- マルチリージョンシグナル伝達のサポート（[RFC5212]のセクション5.7）;
- Advertisement of the adjustment capacity (Section 5.2 of [RFC5212]);
- 調整能力の広告（[RFC5212]のセクション5.2）;
A set of lower-layer FA-LSPs provides a Virtual Network Topology (VNT) to the upper-layer [RFC5212]. By reconfiguring the VNT (FA-LSP setup/release) according to traffic demands between source and destination node pairs within a layer, network performance factors (such as maximum link utilization and residual capacity of the network) can be optimized. Such optimal VNT reconfiguration implies several mechanisms that are analyzed in the following sections.
下層のFA-LSPのセットは、上層層[RFC5212]に仮想ネットワークトポロジ（VNT）を提供します。レイヤー内のソースと宛先ノードのペア間のトラフィック要求に応じてVNT（FA-LSPセットアップ/リリース）を再構成することにより、ネットワークパフォーマンス係数（ネットワークの最大リンク利用や残差容量など）を最適化できます。このような最適なVNT再構成は、次のセクションで分析されるいくつかのメカニズムを意味します。
Note that the VNT approach is just one possible approach to performing inter-layer Traffic Engineering.
VNTアプローチは、層間トラフィックエンジニアリングを実行するための1つの可能なアプローチにすぎないことに注意してください。
In a Multi-Layer Network, FA-LSPs are created, modified, and released periodically according to the change of incoming traffic demands from the upper layer.
多層ネットワークでは、FA-LSPが上部層からの着信トラフィックの要求の変更に応じて定期的に作成、変更、およびリリースされます。
This implies a TE mechanism that takes into account the demands matrix, the TE topology, and potentially the current VNT, in order to compute and setup a new VNT.
これは、新しいVNTを計算してセットアップするために、要求マトリックス、TEトポロジ、および潜在的に現在のVNTを考慮したTEメカニズムを意味します。
Several functional building blocks are required to support such a TE mechanism:
このようなメカニズムをサポートするには、いくつかの機能的な構成要素が必要です。
- Discovery of TE topology and available resources.
- TEトポロジと利用可能なリソースの発見。
- Collection of upper-layer traffic demands.
- 上層層の交通需要のコレクション。
- Policing and scheduling of VNT resources with regard to traffic demands and usage (that is, decision to setup/release FA-LSPs). The functional component in charge of this function is called a VNT Manager (VNTM) [PCE-INTER].
- トラフィックの要求と使用に関するVNTリソースのポリシングとスケジューリング（つまり、FA-LSPをセットアップ/リリースする決定）。この関数を担当する機能成分は、VNTマネージャー（VNTM）[PCE-INTER]と呼ばれます。
- VNT Path Computation according to TE topology, potentially taking into account the old (existing) VNT in order to minimize changes. The functional component in charge of VNT computation may be distributed on network elements or may be performed on an external element (such as a Path Computation Element (PCE), [RFC4655]).
- TEトポロジーによると、VNTパス計算は、変更を最小限に抑えるために、古い（既存の）VNTを考慮に入れる可能性があります。VNT計算を担当する関数コンポーネントは、ネットワーク要素に分布するか、外部要素（パス計算要素（PCE）、[RFC4655]など）で実行される場合があります。
- FA-LSP setup/release.
- FA-LSPセットアップ/リリース。
GMPLS routing protocols provide TE topology discovery. GMPLS signaling protocols allow setting up/releasing FA-LSPs.
GMPLSルーティングプロトコルは、TEトポロジの発見を提供します。GMPLSシグナリングプロトコルにより、FA-LSPのセットアップ/リリースが可能になります。
VNTM functions (resources policing/scheduling, decision to setup/release FA-LSPs, FA-LSP configuration) are out of the scope of GMPLS protocols. Such functionalities can be achieved directly on layer-border Label Switching Routers (LSRs), or through one or more external tools. When an external tool is used, an interface is required between the VNTM and the network elements so as to setup/release FA-LSPs. This could use standard management interfaces such as [RFC4802].
VNTM関数（リソースポリシング/スケジューリング、FA-LSPSのセットアップ/リリースの決定、FA-LSP構成の決定）は、GMPLSプロトコルの範囲外です。このような機能は、レイヤーボーダーラベルスイッチングルーター（LSR）、または1つ以上の外部ツールで直接実現できます。外部ツールを使用する場合、FA-LSPをセットアップ/リリースするために、VNTMとネットワーク要素の間にインターフェイスが必要です。これは、[RFC4802]などの標準管理インターフェイスを使用できます。
The set of traffic demands of the upper layer is required for the VNT Manager to take decisions to setup/release FA-LSPs. Such traffic demands include satisfied demands, for which one or more upper-layer LSP have been successfully setup, as well as unsatisfied demands and future demands, for which no upper layer LSP has been setup yet. The collection of such information is beyond the scope of GMPLS protocols. Note that it may be partially inferred from parameters carried in GMPLS signaling or advertised in GMPLS routing.
VNTマネージャーがFA-LSPをセットアップ/解放する決定を下すには、上層層のトラフィック要求のセットが必要です。このような交通需要には、1つ以上の上層LSPが正常にセットアップされた満足した要求、および不満の要求と将来の要求が含まれます。このような情報の収集は、GMPLSプロトコルの範囲を超えています。GMPLSシグナル伝達で運ばれるパラメーターから部分的に推測されるか、GMPLSルーティングで宣伝される可能性があることに注意してください。
Finally, the computation of FA-LSPs that form the VNT can be performed directly on layer-border LSRs or on an external element (such as a Path Computation Element (PCE), [RFC4655]), and this is independent of the location of the VNTM.
最後に、VNTを形成するFA-LSPの計算は、レイヤーボーダーLSRSまたは外部要素（パス計算要素（PCE）、[RFC4655]など）で直接実行できます。vntm。
Hence, to summarize, no GMPLS protocol extensions are required to control FA-LSP setup/release.
したがって、要約すると、FA-LSPのセットアップ/リリースを制御するためにGMPLSプロトコル拡張は必要ありません。
A virtual TE link is a TE link between two upper layer nodes that is not actually associated with a fully provisioned FA-LSP in a lower layer. A virtual TE link represents the potentiality to setup an FA-LSP in the lower layer to support the TE link that has been advertised. A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. In particular, the flooding scope of a virtual TE link is within an IGP area, as is the case for any TE link.
仮想TEリンクは、2つの上層ノード間のTEリンクであり、実際には下層の完全なプロビジョニングFA-LSPに関連付けられていません。仮想TEリンクは、宣伝されているTEリンクをサポートするために、下層にFA-LSPをセットアップする可能性を表しています。完全にプロビジョニングされたTEリンクに対して定義された[RFC4206]のルールに従って、仮想TEリンクが任意のリンクとして宣伝されます。特に、仮想TEリンクの洪水範囲は、TEリンクの場合のように、IGPエリア内にあります。
If an upper-layer LSP attempts (through a signaling message) to make use of a virtual TE link, the underlying FA-LSP is immediately signaled and provisioned (provided there are available resources in the lower layer) in the process known as triggered signaling.
上層層LSPが（シグナルメッセージを介して）仮想TEリンクを使用しようとする場合、基礎となるFA-LSPは、トリガーされたシグナル伝達として知られるプロセスで、すぐに信号とプロビジョニング（下層に利用可能なリソースがある）をすぐに指示およびプロビジョニングします（。
The use of virtual TE links has two main advantages:
仮想TEリンクの使用には、2つの主な利点があります。
- Flexibility: allows the computation of an LSP path using TE links without needing to take into account the actual provisioning status of the corresponding FA-LSP in the lower layer;
- 柔軟性：下層の対応するFA-LSPの実際のプロビジョニングステータスを考慮する必要なく、TEリンクを使用してLSPパスの計算を可能にします。
- Stability: allows stability of TE links in the upper layer, while avoiding wastage of bandwidth in the lower layer, as data plane connections are not established until they are actually needed.
- 安定性：データプレーンの接続が実際に必要になるまで確立されないため、下層の帯域幅の無駄を避けながら、上層のTEリンクの安定性を可能にします。
Virtual TE links are setup/deleted/modified dynamically, according to the change of the (forecast) traffic demand, operator's policies for capacity utilization, and the available resources in the lower layer.
仮想TEリンクは、（予測）トラフィックの需要の変更、容量利用に関するオペレーターのポリシー、および下層の利用可能なリソースに応じて、動的にセットアップ/削除/削除/変更されます。
The support of virtual TE links requires two main building blocks:
仮想TEリンクのサポートには、2つのメインブロックが必要です。
- A TE mechanism for dynamic modification of virtual TE link topology;
- 仮想TEリンクトポロジの動的修正のためのTEメカニズム。
- A signaling mechanism for the dynamic setup and deletion of virtual TE links. Setting up a virtual TE link requires a signaling mechanism that allows an end-to-end association between virtual TE link end points with the purpose of exchanging link identifiers as well as some TE parameters.
- 仮想TEリンクの動的セットアップと削除のシグナルメカニズム。仮想TEリンクを設定するには、リンク識別子を交換する目的と、いくつかのTEパラメーターを交換する目的と、仮想TEリンクのエンドポイント間のエンドツーエンドの関連性を可能にするシグナリングメカニズムが必要です。
The TE mechanism responsible for triggering/policing dynamic modification of virtual TE links is out of the scope of GMPLS protocols.
仮想TEリンクの動的な変更のトリガー/ポリシングの原因となるTEメカニズムは、GMPLSプロトコルの範囲外です。
Current GMPLS signaling does not allow setting up and releasing virtual TE links. Hence, GMPLS signaling must be extended to support virtual TE links.
現在のGMPLSシグナリングは、仮想TEリンクのセットアップとリリースを許可しません。したがって、仮想TEリンクをサポートするためにGMPLSシグナリングを拡張する必要があります。
We can distinguish two options for setting up virtual TE links:
仮想TEリンクを設定するための2つのオプションを区別できます。
- The Soft FA approach consists of setting up the FA-LSP in the control plane without actually activating cross connections in the data plane. On the one hand, this requires state maintenance on all transit LSRs (N square issue), but on the other hand, this may allow for some admission control. Indeed, when a Soft FA is activated, the resources may no longer be available for use by other Soft FAs that have common links. These Soft FA will be dynamically released, and corresponding virtual TE links will be deleted. The Soft FA LSPs may be setup using procedures similar to those described in [RFC4872] for setting up secondary LSPs.
- ソフトFAアプローチは、データプレーン内のクロス接続を実際にアクティブにすることなく、制御プレーンにFA-LSPをセットアップすることで構成されています。一方では、これにはすべてのトランジットLSR（N Square Issue）の状態メンテナンスが必要ですが、一方では、ある程度の入場制御が可能になる場合があります。実際、ソフトFAがアクティブ化されると、リソースが共通のリンクを持つ他のソフトFAが使用できなくなる場合があります。これらのソフトFAは動的にリリースされ、対応する仮想TEリンクが削除されます。ソフトFA LSPは、二次LSPをセットアップするために[RFC4872]に記載されている手順と同様の手順を使用してセットアップできます。
- The remote association approach simply consists of exchanging virtual TE link IDs and parameters directly between TE link end points. This does not require state maintenance on transit LSRs, but reduces admission control capabilities. Such an association between virtual TE link end points may rely on extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Automatically Switched Optical Network (ASON) call procedure [RFC4974].
- リモートアソシエーションアプローチは、TEリンクエンドポイント間で仮想TEリンクIDとパラメーターを直接交換することで構成されています。これには、輸送LSRの州のメンテナンスは必要ありませんが、入場制御機能を削減します。仮想TEリンクのエンドポイント間のこのような関連性は、リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の拡張機能に依存している場合があります。
Note that the support of virtual TE links does not require any GMPLS routing extension.
仮想TEリンクのサポートには、GMPLSルーティング拡張機能が必要ないことに注意してください。
Before deleting a given FA-LSP, all nested LSPs have to be rerouted and removed from the FA-LSP to avoid traffic disruption. The mechanisms required here are similar to those required for graceful deletion of a TE link. A Graceful TE link deletion mechanism allows for the deletion of a TE link without disrupting traffic of TE-LSPs that were using the TE link.
特定のFA-LSPを削除する前に、すべてのネストされたLSPを再ルーティングしてFA-LSPから削除する必要があります。ここで必要なメカニズムは、TEリンクの優雅な削除に必要なメカニズムに似ています。優雅なTEリンク削除メカニズムにより、TEリンクを使用していたTE-LSPのトラフィックを混乱させることなく、TEリンクの削除が可能になります。
Hence, GMPLS routing and/or signaling extensions are required to support graceful deletion of TE links. This may utilize the procedures described in [GR-SHUT]: a transit LSR notifies a head-end LSR that a TE link along the path of an LSP is going to be torn down, and also withdraws the bandwidth on the TE link so that it is not used for new LSPs.
したがって、TEリンクの優雅な削除をサポートするには、GMPLSルーティングおよび/またはシグナリング拡張機能が必要です。これは、[Gr-Shut]に記載されている手順を利用する場合があります。TransitLSRは、LSPの経路に沿ったTEリンクが取り壊されることをヘッドエンドLSRに通知し、TEリンクの帯域幅を引き出して、新しいLSPには使用されません。
The stability of upper-layer LSP may be impaired if the VNT undergoes frequent changes. In this context, robustness of the VNT is defined as the capability to smooth the impact of these changes and avoid their subsequent propagation.
VNTが頻繁に変化する場合、上層LSPの安定性が損なわれる可能性があります。これに関連して、VNTの堅牢性は、これらの変化の影響を滑らかにし、その後の伝播を回避する能力として定義されます。
Guaranteeing VNT stability is out of the scope of GMPLS protocols and relies entirely on the capability of the TE and VNT management algorithms to minimize routing perturbations. This requires that the algorithms take into account the old VNT when computing a new VNT, and try to minimize the perturbation.
VNTの安定性の保証は、GMPLSプロトコルの範囲外であり、ルーティングの摂動を最小限に抑えるためにTEおよびVNT管理アルゴリズムの機能に完全に依存しています。これには、新しいVNTを計算する際にアルゴリズムが古いVNTを考慮し、摂動を最小限に抑える必要があります。
Note that a full mesh of lower-layer LSPs may be created between every pair of border nodes between the upper and lower layers. The merit of a full mesh of lower-layer LSPs is that it provides stability to the upper-layer routing. That is, the forwarding table used in the upper layer is not impacted if the VNT undergoes changes. Further, there is always full reachability and immediate access to bandwidth to support LSPs in the upper layer. But it also has significant drawbacks, since it requires the maintenance of n^2 RSVP-TE sessions (where n is the number of border nodes), which may be quite CPU- and memory-consuming (scalability impact). Also, this may lead to significant bandwidth wastage. Note that the use of virtual TE links solves the bandwidth wastage issue, and may reduce the control plane overload.
上層層と下層の間の境界ノードのすべてのペアの間に、下層LSPの完全なメッシュが作成される可能性があることに注意してください。低層LSPの完全なメッシュのメリットは、上層層ルーティングに安定性を提供することです。つまり、VNTが変更された場合、上層で使用される転送テーブルは影響を受けません。さらに、上層のLSPをサポートするために、常に完全な到達可能性と帯域幅への即時アクセスがあります。しかし、n^2 rsvp-teセッション（nは境界ノードの数）のメンテナンスが必要であるため、重要な欠点もあります。また、これは重大な帯域幅の浪費につながる可能性があります。仮想TEリンクの使用は、帯域幅の浪費の問題を解決し、コントロールプレーンの過負荷を減らす可能性があることに注意してください。
When an FA TE Link is advertised, its parameters are inherited from the parameters of the FA-LSP, and specific inheritance rules are applied.
FA TEリンクが宣伝されると、そのパラメーターはFA-LSPのパラメーターから継承され、特定の継承ルールが適用されます。
This relies on local procedures and policies and is out of the scope of GMPLS protocols. Note that this requires that both head-end and tail-end of the FA-LSP are driven by same policies.
これはローカルの手順とポリシーに依存しており、GMPLSプロトコルの範囲外です。これには、FA-LSPのヘッドエンドとテールエンドの両方が同じポリシーによって駆動されることが必要であることに注意してください。
Once fully provisioned, FA-LSP liveliness may be achieved by verifying its data plane connectivity.
完全にプロビジョニングされると、データプレーンの接続性を確認することにより、FA-LSPの活気が実現できます。
FA-LSP connectivity verification relies on technology-specific mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using Bidrectional Forwarding Detection (BFD); etc.) as for any other LSP. Hence, this requirement is out of the scope of GMPLS protocols.
FA-LSP接続の検証は、他のLSPのように、入札転送検出（BFD）;などを使用して、G.707およびG.783を使用したSDHの場合、技術固有のメカニズムに依存しています。したがって、この要件はGMPLSプロトコルの範囲外です。
The GMPLS protocols should provide mechanisms for the coordination of data link verification in the upper-layer network where data links are lower-layer LSPs.
GMPLSプロトコルは、データリンクが低層LSPである上層ネットワークでのデータリンク検証の調整のメカニズムを提供する必要があります。
o GMPLS signaling allows an LSP to be put into 'test' mode [RFC3473]. o The Link Management Protocol [RFC4204] is a targeted protocol and can be run end-to-end across lower-layer LSPs. o Coordination of testing procedures in different layers is an operational matter.
o GMPLSシグナル伝達により、LSPを「テスト」モード[RFC3473]に入れることができます。oリンク管理プロトコル[RFC4204]はターゲットを絞ったプロトコルであり、低層LSPでエンドツーエンドで実行できます。o異なる層でのテスト手順の調整は、運用上の問題です。
As discussed in [RFC5212]), MRN/MLN routing mechanisms must be designed to scale well with an increase of any of the following: - Number of nodes - Number of TE links (including FA-LSPs) - Number of LSPs - Number of regions and layers - Number of Interface Switching Capability Descriptors (ISCDs) per TE link.
[RFC5212]で説明したように、MRN/MLNルーティングメカニズムは、次のいずれかの増加とともに十分にスケーリングするように設計する必要があります。領域とレイヤー - リンクごとにインターフェイススイッチング機能記述子（ISCD）の数。
GMPLS routing provides the necessary advertisement functions and is based on IETF-designed IGPs. These are known to scale relatively well with the number of nodes and links. Where there are multiple regions or layers, there are two possibilities.
GMPLSルーティングは、必要な広告関数を提供し、IETFが設計したIGPに基づいています。これらは、ノードとリンクの数と比較的よくスケーリングすることが知られています。複数の領域またはレイヤーがある場合、2つの可能性があります。
1. If a single routing instance distributes information about multiple network layers, the effect is no more than to increase the number of nodes and links in the network.
1. 単一のルーティングインスタンスが複数のネットワークレイヤーに関する情報を配布する場合、効果はネットワーク内のノードとリンクの数を増やすことにすぎません。
2. If the MLN is fully integrated (i.e., constructed from hybrid nodes), there is an increase in the number of nodes and links (as just mentioned), and also a potential increase in the amount of ISCD information advertised per link. This is a relatively small amount of information (e.g., 36 bytes in OSPF [RFC4203]) per switching type, and each interface is unlikely to have more than two or three switching types.
2. MLNが完全に統合されている場合（つまり、ハイブリッドノードから構成されています）、ノードとリンクの数が増加し（前述のように）、リンクごとに宣伝されているISCD情報の量の潜在的な増加もあります。これは、スイッチングタイプごとに比較的少量の情報（OSPF [RFC4203]の36バイト）であり、各インターフェイスには2つまたは3つのスイッチングタイプがありそうにありません。
The number of LSPs in a lower layer that are advertised as TE links may impact the scaling of the routing protocol. A full mesh of FA-LSPs in the lower layer would lead to n^2 TE links, where n is the number of layer-border LSRs. This must be taken into consideration in the VNT management process. This is an operational matter beyond the scope of GMPLS protocols.
TEリンクとして宣伝されている下層のLSPの数は、ルーティングプロトコルのスケーリングに影響を与える可能性があります。下層のFA-LSPの完全なメッシュは、n^2 TEリンクにつながります。ここで、nは層のLSRの数です。これは、VNT管理プロセスで考慮する必要があります。これは、GMPLSプロトコルの範囲を超えた運用上の問題です。
Since it requires the maintenance of n^2 RSVP-TE sessions (which may be quite CPU- and memory-consuming), a full mesh of LSPs in the lower layer may impact the scalability of GMPLS signaling. The use of virtual TE links may reduce the control plane overload (see Section 3.1.1.2).
n^2 rsvp-teセッションのメンテナンスが必要なため（これは非常にcpuおよびメモリが消費される可能性があります）、下層のLSPの完全なメッシュは、GMPLSシグナル伝達のスケーラビリティに影響を与える可能性があります。仮想TEリンクを使用すると、コントロールプレーンの過負荷が減少する場合があります（セクション3.1.1.2を参照）。
[RFC5212] identifies various requirements for effective management and operation of the MLN. Some features already exist within the GMPLS protocol set, some more are under development, and some requirements are not currently addressed and will need new development work in order to support them.
[RFC5212]は、MLNの効果的な管理と運用に関するさまざまな要件を特定します。GMPLSプロトコルセット内にはすでにいくつかの機能が存在し、さらにいくつかは開発中であり、一部の要件は現在対処されておらず、それらをサポートするために新しい開発作業が必要になります。
MIB modules have been developed to model and control GMPLS switches [RFC4803] and to control and report on the operation of the signaling protocol [RFC4802]. These may be successfully used to manage the operation of a single instance of the control plane protocols that operate across multiple layers.
MIBモジュールは、GMPLSスイッチをモデル化および制御し[RFC4803]、シグナル伝達プロトコル[RFC4802]の操作を制御および報告するために開発されています。これらは、複数のレイヤーで動作する制御プレーンプロトコルの単一インスタンスの動作を管理するために正常に使用できます。
[RFC4220] provides a MIB module for managing TE links, and this may be particularly useful in the context of the MLN because LSPs in the lower layers are made available as TE links in the higher layer.
[RFC4220]は、TEリンクを管理するためのMIBモジュールを提供します。これは、下層のLSPが高層のTEリンクとして利用可能になるため、MLNのコンテキストで特に役立つ場合があります。
The traffic engineering database provides a repository for all information about the existence and current status of TE links within a network. This information is typically flooded by the routing protocol operating within the network, and is used when LSP routes are computed. [TED-MIB] provides a way to inspect the TED to view the TE links at the different layers of the MLN.
トラフィックエンジニアリングデータベースは、ネットワーク内のTEリンクの存在と現在のステータスに関するすべての情報のリポジトリを提供します。この情報は通常、ネットワーク内で動作するルーティングプロトコルによって浸水し、LSPルートが計算されると使用されます。[Ted-Mib]は、MLNの異なる層でTEリンクを表示するためにTEDを検査する方法を提供します。
As observed in [RFC5212], although it would be possible to manage the MLN using only the existing MIB modules, a further MIB module could be produced to coordinate the management of separate network layers in order to construct a single MLN entity. Such a MIB module would effectively link together entries in the MIB modules already referenced.
[RFC5212]で観察されているように、既存のMIBモジュールのみを使用してMLNを管理することは可能ですが、単一のMLNエンティティを構築するために、個別のネットワークレイヤーの管理を調整するためにさらにMIBモジュールを生成できます。このようなMIBモジュールは、すでに参照されているMIBモジュールのエントリを効果的にリンクします。
At the time of writing, the development of OAM tools for GMPLS networks is at an early stage. GMPLS OAM requirements are addressed in [GMPLS-OAM].
執筆時点では、GMPLSネットワーク用のOAMツールの開発は初期段階にあります。GMPLS OAM要件は[GMPLS-OAM]で対処されています。
In general, the lower layer network technologies contain their own technology-specific OAM processes (for example, SDH/SONET, Ethernet, and MPLS). In these cases, it is not necessary to develop additional OAM processes, but GMPLS procedures may be desirable to coordinate the operation and configuration of these OAM processes.
一般に、下層ネットワークテクノロジーには、独自の技術固有のOAMプロセス（SDH/SONET、イーサネット、MPLSなど）が含まれています。これらの場合、追加のOAMプロセスを開発する必要はありませんが、これらのOAMプロセスの操作と構成を調整するには、GMPLS手順が望ましい場合があります。
[ETH-OAM] describes some early ideas for this function, but more work is required to generalize the technique to be applicable to all technologies and to MLN. In particular, an OAM function operating within a server layer must be controllable from the client layer, and client layer control plane mechanisms must map and enable OAM in the server layer.
[eth-oam]は、この機能の初期のアイデアについて説明していますが、すべてのテクノロジーとMLNに適用できる手法を一般化するには、より多くの作業が必要です。特に、サーバーレイヤー内で動作するOAM関数は、クライアントレイヤーから制御可能でなければならず、クライアントレイヤー制御プレーンメカニズムは、サーバーレイヤーにOAMをマッピングおよび有効にする必要があります。
Where a GMPLS-controlled technology does not contain its own OAM procedures, this is usually because the technology cannot support in-band OAM (for example, Wavelength Division Multiplexing (WDM) networks). In these cases, there is very little that a control plane can add to the OAM function since the presence of a control plane cannot make any difference to the physical characteristics of the data plane. However, the existing GMPLS protocol suite does provide a set of tools that can help to verify the data plane through the control plane. These tools are equally applicable to network technologies that do contain their own OAM.
GMPLS制御テクノロジーに独自のOAM手順が含まれていない場合、これは通常、テクノロジーが帯域OAM（たとえば、波長分割多重化（WDM）ネットワーク）をサポートできないためです。これらの場合、コントロールプレーンの存在がデータプレーンの物理的特性に違いをもたらすことができないため、コントロールプレーンがOAM機能に追加できることはほとんどありません。ただし、既存のGMPLSプロトコルスイートは、コントロールプレーンを介してデータプレーンを検証するのに役立つ一連のツールを提供します。これらのツールは、独自のOAMを含むネットワークテクノロジーに等しく適用できます。
- Route recording is available through the GMPLS signaling protocol [RFC3473], making it possible to check the route reported by the control plane against the expected route. This mechanism also includes the ability to record and report the interfaces and labels used for the LSP at each hop of its path.
- ルート録音は、GMPLSシグナル伝達プロトコル[RFC3473]を介して利用でき、予想されるルートに対してコントロールプレーンによって報告されたルートを確認することができます。このメカニズムには、パスの各ホップでLSPに使用されるインターフェイスとラベルを記録および報告する機能も含まれます。
- The status of TE links is flooded by the GMPLS routing protocols [RFC4203] and [RFC4205] making it possible to detect changes in the available resources in the network as an LSP is set up.
- TEリンクのステータスは、GMPLSルーティングプロトコル[RFC4203]および[RFC4205]によってあふれているため、LSPが設定されているため、ネットワーク内の利用可能なリソースの変更を検出できます。
- The GMPLS signaling protocol [RFC3473] provides a technique to place an LSP into a "test" mode so that end-to-end characteristics (such as power levels) may be sampled and modified.
- GMPLSシグナル伝達プロトコル[RFC3473]は、LSPを「テスト」モードに配置する手法を提供し、エンドツーエンドの特性（パワーレベルなど）をサンプリングおよび変更できるようにします。
- The Link Management Protocol [RFC4204] provides a mechanism for fault isolation on an LSP.
- リンク管理プロトコル[RFC4204]は、LSPで断層分離のメカニズムを提供します。
- GMPLS signaling [RFC3473] provides a Notify message that can be used to report faults and issues across the network. The message includes scaling features to allow one message to report the failure of multiple LSPs.
- GMPLS Signaling [RFC3473]は、ネットワーク全体の障害や問題を報告するために使用できる通知メッセージを提供します。メッセージには、複数のLSPの障害を報告できるメッセージが1つのメッセージを許可するスケーリング機能が含まれています。
- Extensions to GMPLS signaling [RFC4783] enable alarm information to be collected and distributed along the path of an LSP for more easy coordination and correlation.
- GMPLSシグナリング[RFC4783]への拡張により、より簡単な調整と相関のために、LSPの経路に沿ってアラーム情報を収集および配布できます。
There are actually several cases where a transit node could choose between multiple Switching Capabilities (SCs) to be used for a lower-region FA-LSP:
実際には、トランジットノードが、低領域FA-LSPに使用する複数のスイッチング機能（SCS）を選択できる場合があります。
- Explicit Route Object (ERO) expansion with loose hops: The transit node has to expand the path, and may have to select among a set of lower-region SCs.
- ルーズホップを備えた明示的なルートオブジェクト（ERO）拡張：トランジットノードはパスを拡張する必要があり、低領域SCのセットから選択する必要がある場合があります。
- Multi-SC TE link: When the ERO of an FA LSP, included in the ERO of an upper-region LSP, comprises a multi-SC TE link, the region border node has to select among these SCs.
- マルチSC TEリンク：上部領域LSPのEROに含まれるFA LSPのEROがマルチSC TEリンクで構成されている場合、領域の境界ノードはこれらのSCから選択する必要があります。
Existing GMPLS signaling procedures do not allow solving this ambiguous choice of the SC that may be used along a given path.
既存のGMPLSシグナリング手順では、特定のパスに沿って使用できるSCのこの曖昧な選択を解決することはできません。
Hence, an extension to GMPLS signaling has to be defined to indicate the SC(s) that can be used and the SC(s) that cannot be used along the path.
したがって、GMPLSシグナル伝達の拡張は、使用できるSCとパスに沿って使用できないSCを示すために定義する必要があります。
In the MRN context, nodes supporting more than one switching capability on at least one interface are called hybrid nodes [RFC5212]. Conceptually, hybrid nodes can be viewed as containing at least two distinct switching elements interconnected by internal links that provide adjustment between the supported switching capabilities. These internal links have finite capacities and must be taken into account when computing the path of a multi-region TE-LSP. The advertisement of the adjustment capacities is required, as it provides critical information when performing multi-region path computation.
MRNコンテキストでは、少なくとも1つのインターフェイスで複数のスイッチング機能をサポートするノードは、ハイブリッドノード[RFC5212]と呼ばれます。概念的には、ハイブリッドノードは、サポートされているスイッチング機能間の調整を提供する内部リンクによって相互接続された少なくとも2つの異なるスイッチング要素を含むと見なすことができます。これらの内部リンクには有限容量があり、マルチリージョンTE-LSPのパスを計算する際に考慮する必要があります。マルチリージョンパス計算を実行する際に重要な情報を提供するため、調整能力の広告が必要です。
The term "adjustment capacity" refers to the property of a hybrid node to interconnect different switching capabilities it provides through its external interfaces [RFC5212]. This information allows path computation to select an end-to-end multi-region path that includes links of different switching capabilities that are joined by LSRs that can adapt the signal between the links.
「調整能力」という用語は、外部インターフェイス[RFC5212]を介して提供するさまざまなスイッチング機能を相互接続するハイブリッドノードのプロパティを指します。この情報により、PATH計算は、リンク間で信号を適応できるLSRが結合するさまざまなスイッチング機能のリンクを含むエンドツーエンドのマルチレジョンパスを選択できます。
Figure 1a below shows an example of a hybrid node. The hybrid node has two switching elements (matrices), which support TDM and PSC switching, respectively. The node has two PSC and TDM ports (Port1 and Port2, respectively). It also has an internal link connecting the two switching elements.
以下の図1aは、ハイブリッドノードの例を示しています。ハイブリッドノードには、TDMとPSCの切り替えをそれぞれサポートする2つのスイッチング要素（マトリックス）があります。ノードには、2つのPSCとTDMポート（それぞれPORT1とPORT2）があります。また、2つのスイッチング要素を接続する内部リンクもあります。
The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of the TDM Port2; also, they can provide adjustment of PSC traffic that is received/sent over the internal PSC interface (#b). Two ways are possible to set up PSC LSPs (Port1 or Port2). Available resources advertisement (e.g., Unreserved and Min/Max LSP Bandwidth) should cover both ways.
2つのスイッチング要素は、TDM PORT2のリソースの一部を終了できるように内部的に相互接続されています。また、内部PSCインターフェイス（＃B）を介して受信/送信されるPSCトラフィックの調整を提供できます。PSC LSP（PORT1またはPORT2）をセットアップする2つの方法が可能です。利用可能なリソースの広告（例：未リザーブ式および最小/最大LSP帯域幅）は、両方の方法をカバーする必要があります。
Network element
.............................
: -------- :
PSC : | PSC | :
Port1-------------<->---|#a | :
: +--<->---|#b | :
: | -------- :
: | ---------- :
TDM : +--<->--|#c TDM | :
Port2 ------------<->--|#d | :
: ---------- :
:............................
Figure 1a. Hybrid node.
図1a。ハイブリッドノード。
Port1 and Port2 can be grouped together thanks to internal Dense Wavelength Division Multiplexing (DWDM), to result in a single interface: Link1. This is illustrated in Figure 1b below.
PORT1とPORT2は、内部密度の高い波長分割多重化（DWDM）のおかげで一緒にグループ化でき、単一のインターフェイス：link1になります。これを以下の図1Bに示します。
Network element
.............................
: -------- :
: | PSC | :
: | | :
: --|#a | :
: | | #b | :
: | -------- :
: | | :
: | ---------- :
: /| | | #c | :
: | |-- | | :
Link1 ========| | | TDM | :
: | |----|#d | :
: \| ---------- :
:............................
Figure 1b. Hybrid node.
図1b。ハイブリッドノード。
Let's assume that all interfaces are STM16 (with VC4-16c capable as Max LSP bandwidth). After setting up several PSC LSPs via port #a and setting up and terminating several TDM LSPs via port #d and port #b, a capacity of only 155 Mb is still available on port #b. However, a 622 Mb capacity remains on port #a, and VC4-5c capacity remains on port #d.
すべてのインターフェイスがSTM16であると仮定しましょう（最大LSP帯域幅としてVC4-16C対応）。ポート＃Aを介していくつかのPSC LSPをセットアップし、ポート＃Dとポート＃Bを介していくつかのTDM LSPをセットアップおよび終了した後、ポート#Bでまだ155 MBの容量が利用可能です。ただし、622 MBの容量はポート＃Aに残り、VC4-5C容量はポート＃Dに残ります。
When computing the path for a new VC4-4c TDM LSP, one must know that this node cannot terminate this LSP, as there is only a 155 Mb capacity still available for TDM-PSC adjustment. Hence, the TDM-PSC adjustment capacity must be advertised.
新しいVC4-4C TDM LSPのパスを計算する場合、TDM-PSC調整にまだ利用可能な155 MBの容量しかないため、このノードはこのLSPを終了できないことを知っている必要があります。したがって、TDM-PSC調整容量を宣伝する必要があります。
With current GMPLS routing [RFC4202], this advertisement is possible if link bundling is not used and if two TE links are advertised for Link1.
現在のGMPLSルーティング[RFC4202]では、リンクバンドリングが使用されていない場合、およびLink1に2つのTEリンクが宣伝されている場合、この広告が可能です。
We would have the following TE link advertisements:
次のリンク広告があります。
TE link 1 (Port1): - ISCD sub-TLV: PSC with Max LSP bandwidth = 622 Mb - Unreserved bandwidth = 622 Mb.
TEリンク1（PORT1）：-ISCD SUB -TLV：MAX LSP帯域幅を備えたPSC = 622 MB -Unshulerved Bandwidth = 622 MB。
TE link 2 (Port2): - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, - Unreserved bandwidth (equivalent): 777 Mb.
TEリンク2（PORT2）：-ISCD＃1 SUB -TLV：MAX LSP BANDWIDTH = VC4-4C、-ISCD＃2 SUB -TLV：MAX LSP帯域幅を備えたPSC = 155 MB、 - 控えめな帯域幅（同等）：777MB。
The ISCD #2 in TE link 2 actually represents the TDM-PSC adjustment capacity.
TEリンク2のISCD＃2は、実際にはTDM-PSC調整容量を表しています。
However, if for obvious scalability reasons, link bundling is done, then the adjustment capacity information is lost with current GMPLS routing, as we have the following TE link advertisement:
ただし、明らかなスケーラビリティの理由でリンクバンドリングが行われる場合、次のTEリンク広告があるため、現在のGMPLSルーティングで調整能力情報が失われます。
TE link 1 (Port1 + Port2): - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, - Unreserved bandwidth (equivalent): 1399 Mb.
TEリンク1（PORT1 PORT2）：-ISCD＃1 SUB -TLV：MAX LSP BANDWIDTH = VC4-4C、-ISCD＃2 SUB -TLV：MAX LSP LSP帯域幅を備えたPSC = 622 MB、 - 予定されていない帯域幅（同等）：1399 MB。
With such a TE link advertisement, an element computing the path of a VC4-4c LSP cannot know that this LSP cannot be terminated on the node.
このようなリンク広告を使用すると、VC4-4C LSPのパスを計算する要素は、このLSPをノードで終了できないことを知ることができません。
Thus, current GMPLS routing can support the advertisement of the adjustment capacities, but this precludes performing link bundling and thus faces significant scalability limitations.
したがって、現在のGMPLSルーティングは、調整能力の広告をサポートできますが、これによりリンクバンドルの実行が妨げられ、したがって大きなスケーラビリティの制限に直面します。
Hence, GMPLS routing must be extended to meet this requirement. This could rely on the advertisement of the adjustment capacities as a new TE link attribute (that would complement the Interface Switching Capability Descriptor TE link attribute).
したがって、この要件を満たすためにGMPLSルーティングを拡張する必要があります。これは、新しいTEリンク属性として調整能力の広告に依存する可能性があります（インターフェイススイッチング機能記述子TEリンク属性を補完します）。
Note: Multiple ISCDs MAY be associated with a single switching capability. This can be performed to provide (e.g., for TDM interfaces) the Min/Max LSP Bandwidth associated to each layer (or set of layers) for that switching capability. For example, an interface associated to TDM switching capability and supporting VC-12 and VC-4 switching can be associated to one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, in the second ISCD sub-TLV. Hence, in the first case, as long as the Min LSP Bandwidth is set to VC-12 (and not VC-4), and in the second case, as long as the first ISCD sub-TLV is advertised, there is sufficient capacity across that interface to setup a VC-12 LSP.
注：複数のISCDは、単一のスイッチング機能に関連付けられている場合があります。これを実行して、そのスイッチング機能に各レイヤー（またはレイヤーのセット）に関連付けられたMin/Max LSP帯域幅を提供する（TDMインターフェイスなど）。たとえば、TDMスイッチング機能に関連付けられ、VC-12およびVC-4スイッチングをサポートするインターフェイスは、1つのISCD Sub-TLVまたは2つのISCD Sub-TLVに関連付けられます。最初のケースでは、最小LSP帯域幅はVC-12に設定され、最大LSP帯域幅はVC-4に設定されます。2番目のケースでは、MIN LSP帯域幅はVC-12に設定され、最大LSP帯域幅は最初のISCD Sub-TLVでVC-12に設定されています。最小LSP帯域幅は、2番目のISCD Sub-TLVでVC-4、最大LSP帯域幅にVC-4に設定されています。したがって、最初のケースでは、最小LSP帯域幅がVC-12（VC-4ではなく）に設定されている限り、2番目のケースでは、最初のISCDサブTLVが宣伝されている限り、十分な容量がありますそのインターフェイス全体でVC-12 LSPをセットアップします。
Most of the required MLN/MRN functions will rely on mechanisms and procedures that are out of the scope of the GMPLS protocols, and thus do not require any GMPLS protocol extensions. They will rely on local procedures and policies, and on specific TE mechanisms and algorithms.
必要なMLN/MRN関数のほとんどは、GMPLSプロトコルの範囲外であるメカニズムと手順に依存するため、GMPLSプロトコル拡張は必要ありません。それらは、ローカルの手順とポリシー、および特定のTEメカニズムとアルゴリズムに依存します。
As regards Virtual Network Topology (VNT) computation and reconfiguration, specific TE mechanisms need to be defined, but these mechanisms are out of the scope of GMPLS protocols.
仮想ネットワークトポロジ（VNT）計算と再構成に関しては、特定のメカニズムを定義する必要がありますが、これらのメカニズムはGMPLSプロトコルの範囲外です。
Six areas for extensions of GMPLS protocols and procedures have been identified:
GMPLSプロトコルと手順の拡張のための6つの領域が特定されています。
- GMPLS signaling extension for the setup/deletion of the virtual TE links;
- 仮想TEリンクのセットアップ/削除のためのGMPLSシグナリング拡張。
- GMPLS signaling extension for graceful TE link deletion;
- GMPLS優雅なTEリンク削除のシグナリング拡張。
- GMPLS signaling extension for constrained multi-region signaling (SC inclusion/exclusion);
- 制約されたマルチリージョンシグナル伝達のGMPLSシグナル拡張（SC包含/除外）;
- GMPLS routing extension for the advertisement of the adjustment capacities of hybrid nodes.
- ハイブリッドノードの調整能力の広告のためのGMPLSルーティング拡張機能。
- A MIB module for coordination of other MIB modules being operated in separate layers.
- 別の層で操作されている他のMIBモジュールの調整のためのMIBモジュール。
- GMPLS signaling extensions for the control and configuration of technology-specific OAM processes.
- 技術固有のOAMプロセスの制御と構成のためのGMPLSシグナリング拡張機能。
This section provides a brief cross-reference to the requirements set out in [RFC5212] so that it is possible to verify that all of the requirements listed in that document have been examined in this document.
このセクションでは、[RFC5212]に記載されている要件に対する簡単な相互参照を提供しているため、そのドキュメントにリストされているすべての要件がこのドキュメントで検討されていることを確認できます。
- Path computation mechanism should be able to compute paths and handle topologies consisting of any combination of (simplex) nodes ([RFC5212], Section 5.1). o Path computation mechanisms are beyond the scope of protocol specifications, and out of scope for this document.
- パス計算メカニズムは、パスを計算し、（単純な）ノード（[RFC5212]、セクション5.1）の任意の組み合わせで構成されるトポロジーを処理できる必要があります。oパス計算メカニズムは、プロトコル仕様の範囲を超えており、このドキュメントの範囲外です。
- A hybrid node should maintain resources on its internal links ([RFC5212], Section 5.2). o This is an implementation requirement and is beyond the scope of protocol specifications, and it is out of scope for this document.
- ハイブリッドノードは、内部リンク（[RFC5212]、セクション5.2）にリソースを維持する必要があります。oこれは実装要件であり、プロトコル仕様の範囲を超えており、このドキュメントの範囲外です。
- Path computation mechanisms should be prepared to use the availability of termination/adjustment resources as a constraint in path computation ([RFC5212], Section 5.2). o Path computation mechanisms are beyond the scope of protocol specifications, and out of scope for this document.
- パス計算メカニズムは、パス計算の制約として終了/調整リソースの可用性を使用するために準備する必要があります（[RFC5212]、セクション5.2）。oパス計算メカニズムは、プロトコル仕様の範囲を超えており、このドキュメントの範囲外です。
- The advertisement of a node's ability to terminate lower-region LSPs and to forward traffic in the upper-region (adjustment capability) is required ([RFC5212], Section 5.2). o See Section 3.2.2 of this document.
- 低領域LSPを終了し、上部地域のトラフィックを転送するノードの能力の広告（調整機能）が必要です（[RFC5212]、セクション5.2）。oこのドキュメントのセクション3.2.2を参照してください。
- The path computation mechanism should support the coexistence of upper-layer links directly connected to upper-layer switching elements, and upper-layer links connected through internal links between upper-layer and lower-layer switching elements ([RFC5212], Section 5.2). o Path computation mechanisms are beyond the scope of protocol specifications, and out of scope for this document.
- パス計算メカニズムは、上層層のスイッチング要素に直接接続された上層層リンクの共存、および上層層と下層スイッチング要素の間の内部リンクを介して接続された上層リンクの共存をサポートする必要があります（[RFC5212]、セクション5.2）。oパス計算メカニズムは、プロトコル仕様の範囲を超えており、このドキュメントの範囲外です。
- MRN/MLN routing mechanisms must be designed to scale well with an increase of any of the following: - Number of nodes - Number of TE links (including FA-LSPs) - Number of LSPs - Number of regions and layers - Number of ISCDs per TE link. ([RFC5212], Section 5.3). o See Section 3.1.4 of this document.
- MRN/MLNルーティングメカニズムは、次のいずれかの増加とともに十分にスケーリングするように設計する必要があります。-ノード数 - TEリンクの数（FA -LSPを含む） - LSPの数 - 領域と層の数 - ISCDの数あたりのISCDの数TEリンク。（[RFC5212]、セクション5.3）。oこのドキュメントのセクション3.1.4を参照してください。
- Design of the routing protocols must not prevent TE information filtering based on ISCDs ([RFC5212], Section 5.3). o All advertised information carries the ISCD, and so a receiving node may filter as required.
- ルーティングプロトコルの設計は、ISCDに基づいたTE情報フィルタリングを防止してはなりません（[RFC5212]、セクション5.3）。o広告されたすべての情報にはISCDが含まれているため、必要に応じて受信ノードがフィルタリングされる場合があります。
- The path computation mechanism and the signaling protocol should be able to operate on partial TE information, ([RFC5212], Section 5.3). o Path computation mechanisms are beyond the scope of protocol specifications, and out of scope for this document.
- パス計算メカニズムとシグナル伝達プロトコルは、部分的なTE情報で動作できるはずです（[RFC5212]、セクション5.3）。oパス計算メカニズムは、プロトコル仕様の範囲を超えており、このドキュメントの範囲外です。
- Protocol mechanisms must be provided to enable creation, deletion, and modification of LSPs triggered through operational actions ([RFC5212], Section 5.4). o Such mechanisms are standard in GMPLS signaling [RFC3473].
- プロトコルメカニズムは、運用アクションを通じてトリガーされるLSPの作成、削除、および変更を可能にするために提供する必要があります（[RFC5212]、セクション5.4）。oこのようなメカニズムは、GMPLSシグナル伝達[RFC3473]で標準です。
- Protocol mechanisms should be provided to enable similar functions triggered by adjacent layers ([RFC5212], Section 5.4). o Such mechanisms are standard in GMPLS signaling [RFC3473].
- 隣接する層によってトリガーされる同様の関数を有効にするために、プロトコルメカニズムを提供する必要があります（[RFC5212]、セクション5.4）。oこのようなメカニズムは、GMPLSシグナル伝達[RFC3473]で標準です。
- Protocol mechanisms may be provided to enable adaptation to changes such as traffic demand, topology, and network failures. Routing robustness should be traded with adaptability of those changes ([RFC5212], Section 5.4). o See Section 3.1.1 of this document.
- トラフィック需要、トポロジ、ネットワークの障害などの変更への適応を可能にするために、プロトコルメカニズムが提供される場合があります。ルーティングの堅牢性は、これらの変更の適応性と取引する必要があります（[RFC5212]、セクション5.4）。oこのドキュメントのセクション3.1.1を参照してください。
- Reconfiguration of the VNT must be as non-disruptive as possible and must be under the control of policy configured by the operator ([RFC5212], Section 5.5). o See Section 3.1.1.3 of this document
- VNTの再構成は、可能な限り破壊的ではなく、オペレーター（[RFC5212]、セクション5.5）によって構成されたポリシーの制御下にある必要があります。oこのドキュメントのセクション3.1.1.3を参照してください
- Parameters of a TE link in an upper layer should be inherited from the parameters of the lower-layer LSP that provides the TE link, based on polices configured by the operator ([RFC5212], Section 5.6). o See Section 3.1.2 of this document.
- 上層層のTEリンクのパラメーターは、演算子（[RFC5212]、セクション5.6）によって構成されたポーリングに基づいて、TEリンクを提供する下層LSPのパラメーターから継承する必要があります。oこのドキュメントのセクション3.1.2を参照してください。
- The upper-layer signaling request may contain an ERO that includes only hops in the upper layer ([RFC5212], Section 5.7). o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1.
- 上層シグナリングリクエストには、上層のホップのみを含むEROが含まれている場合があります（[RFC5212]、セクション5.7）。o GMPLSシグナリングの標準[RFC3473]。セクション3.2.1も参照してください。
- The upper-layer signaling request may contain an ERO specifying the lower layer FA-LSP route ([RFC5212], Section 5.7). o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1.
- 上部層シグナリングリクエストには、下層FA-LSPルート（[RFC5212]、セクション5.7）を指定するEROが含まれている場合があります。o GMPLSシグナリングの標準[RFC3473]。セクション3.2.1も参照してください。
- As part of the re-optimization of the MLN, it must be possible to reroute a lower-layer FA-LSP while keeping interface identifiers of the corresponding TE links unchanged and causing only minimal disruption to higher-layer traffic ([RFC5212], Section 5.8.1). o See Section 3.1.1.3.
- MLNの再最適化の一環として、対応するTEリンクのインターフェイス識別子を変化させず、高層トラフィックへの破壊のみを最小限に抑えながら、低層FA-LSPを再ルーティングすることが可能である必要があります（[RFC5212]、セクションセクション5.8.1）。oセクション3.1.1.3を参照してください。
- The solution must include measures to protect against network destabilization caused by the rapid setup and tear-down of lower-layer LSPs, as traffic demand varies near a threshold ([RFC5212], Sections 5.8.1 and 5.8.2). o See Section 3.1.1.4.
- ソリューションには、トラフィックの需要がしきい値に近く異なるため（[RFC5212]、セクション5.8.1および5.8.2）ため、低層LSPの迅速なセットアップと引き裂きによって引き起こされるネットワークの不安定化から保護するための措置を含める必要があります。oセクション3.1.1.4を参照してください。
- Signaling of lower-layer LSPs should include a mechanism to rapidly advertise the LSP as a TE link in the upper layer, and to coordinate into which routing instances the TE link should be advertised ([RFC5212], Section 5.8.1). o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See also Section 3.1.1.2.
- 低層LSPのシグナル伝達には、LSPを上層のTEリンクとして迅速に宣伝し、どのルーティングインスタンスにTEリンクを宣伝するかを調整するメカニズムを含める必要があります（[RFC5212]、セクション5.8.1）。oこれは[RFC4206]によって提供され、[hier-bis]によって強化されます。セクション3.1.1.2も参照してください。
- If an upper-layer LSP is set up making use of a virtual TE link, the underlying LSP must immediately be signaled in the lower layer ([RFC5212], Section 5.8.2). o See Section 3.1.1.2.
- 仮想TEリンクを使用して上層層LSPがセットアップされている場合、基礎となるLSPはすぐに下層（[RFC5212]、セクション5.8.2）で信号を送信する必要があります。oセクション3.1.1.2を参照してください。
- The solution should provide operations to facilitate the build-up of virtual TE links, taking into account the forecast upper-layer traffic demand, and available resource in the lower layer ([RFC5212], Section 5.8.2). o See Section 3.1.1.2 of this document.
- このソリューションは、予測上層層の交通需要と下層の利用可能なリソース（[RFC5212]、セクション5.8.2）を考慮して、仮想TEリンクの蓄積を促進するための操作を提供する必要があります。oこのドキュメントのセクション3.1.1.2を参照してください。
- The GMPLS protocols should provide mechanisms for the coordination of data link verification in the upper-layer network where data links are lower layer LSPs ([RFC5212], Section 5.9). o See Section 3.1.3 of this document.
- GMPLSプロトコルは、データリンクが下層LSP（[RFC5212]、セクション5.9）である上層ネットワークでのデータリンク検証の調整のメカニズムを提供する必要があります。oこのドキュメントのセクション3.1.3を参照してください。
- Multi-layer protocol solutions should be manageable through MIB modules ([RFC5212], Section 5.10). o See Section 3.1.5.1.
- 多層プロトコルソリューションは、MIBモジュール（[RFC5212]、セクション5.10）を介して管理可能である必要があります。oセクション3.1.5.1を参照してください。
- Choices about how to coordinate errors and alarms, and how to operate OAM across administrative and layer boundaries must be left open for the operator ([RFC5212], Section 5.10). o This is an implementation matter, subject to operational policies.
- エラーとアラームを調整する方法、および管理者とレイヤーの境界を越えてOAMを操作する方法の選択は、オペレーターのために開いたままにする必要があります（[RFC5212]、セクション5.10）。oこれは、運用ポリシーの対象となる実装の問題です。
- It must be possible to enable end-to-end OAM on an upper-layer LSP. This function appears to the ingress LSP as normal LSP-based OAM [GMPLS-OAM], but at layer boundaries, depending on the technique used to span the lower layers, client-layer OAM operations may need to be mapped to server-layer OAM operations ([RFC5212], Section 5.10). o See Section 3.1.5.2.
- 上層LSPでエンドツーエンドのOAMを有効にすることが可能である必要があります。この関数は、通常のLSPベースのOAM [GMPLS-OAM]のように侵入LSPに表示されますが、レイヤー境界では、下層に及ぶために使用される手法によっては、クライアント層のOAM操作をサーバーレイヤーOAMにマッピングする必要がある場合があります。操作（[RFC5212]、セクション5.10）。oセクション3.1.5.2を参照してください。
- Client-layer control plane mechanisms must map and enable OAM in the server layer ([RFC5212], Section 5.10). o See Section 3.1.5.2.
- クライアント層制御プレーンメカニズムは、サーバーレイヤーにOAMをマッピングおよび有効にする必要があります（[RFC5212]、セクション5.10）。oセクション3.1.5.2を参照してください。
- OAM operation enabled for an LSP in a client layer must operate for that LSP along its entire length ([RFC5212], Section 5.10). o See Section 3.1.5.2.
- クライアントレイヤー内のLSPの有効化されたOAM操作は、その全長に沿ってそのLSPに対して動作する必要があります（[RFC5212]、セクション5.10）。oセクション3.1.5.2を参照してください。
- OAM function operating within a server layer must be controllable from the client layer. Such control should be subject to policy at the layer boundary ([RFC5212], Section 5.10). o This is an implementation matter.
- サーバーレイヤー内で動作するOAM関数は、クライアントレイヤーから制御可能でなければなりません。このような制御は、レイヤー境界（[RFC5212]、セクション5.10）でのポリシーの対象となる必要があります。oこれは実装の問題です。
- The status of a server layer LSP must be available to the client layer. This information should be configurable to be automatically notified to the client layer at the layer boundary, and should be subject to policy ([RFC5212], Section 5.10). o This is an implementation matter.
- サーバーレイヤーLSPのステータスは、クライアントレイヤーが使用できる必要があります。この情報は、レイヤー境界のクライアントレイヤーに自動的に通知するように構成可能であり、ポリシー（[RFC5212]、セクション5.10）の対象とする必要があります。oこれは実装の問題です。
- Implementations may use standardized techniques (such as MIB modules) to convey status information between layers. o This is an implementation matter.
- 実装は、標準化された手法（MIBモジュールなど）を使用して、レイヤー間でステータス情報を伝えることができます。oこれは実装の問題です。
[RFC5212] sets out the security requirements for operating a MLN or MRN. These requirements are, in general, no different from the security requirements for operating any GMPLS network. As such, the GMPLS protocols already provide adequate security features. An evaluation of the security features for GMPLS networks may be found in [MPLS-SEC], and where issues or further work is identified by that document, new security features or procedures for the GMPLS protocols will need to be developed.
[RFC5212]は、MLNまたはMRNを操作するためのセキュリティ要件を定めています。これらの要件は、一般に、GMPLSネットワークを操作するためのセキュリティ要件と違いはありません。そのため、GMPLSプロトコルはすでに適切なセキュリティ機能を提供しています。GMPLSネットワークのセキュリティ機能の評価は[MPLS-SEC]に記載されている場合があり、その文書によって問題またはさらなる作業が特定されている場合、GMPLSプロトコルの新しいセキュリティ機能または手順を開発する必要があります。
[RFC5212] also identifies that where the separate layers of a MLN/MRN are operated as different administrative domains, additional security considerations may be given to the mechanisms for allowing inter-layer LSP setup. However, this document is explicitly limited to the case where all layers under GMPLS control are part of the same administrative domain.
[RFC5212]は、MLN/MRNの別々の層が異なる管理ドメインとして動作している場合、層間LSPセットアップを可能にするメカニズムに追加のセキュリティを考慮することができることも特定しています。ただし、このドキュメントは、GMPLS制御下のすべての層が同じ管理ドメインの一部である場合に明示的に制限されています。
Lastly, as noted in [RFC5212], it is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce.
最後に、[RFC5212]に記載されているように、ソリューションドキュメントには、プロトコル拡張が導入するセキュリティ問題の完全な分析が含まれることが予想されます。
We would like to thank Julien Meuric, Igor Bryskin, and Adrian Farrel for their useful comments.
Julien Meuric、Igor Bryskin、およびAdrian Farrelの有用なコメントに感謝します。
Thanks also to Question 14 of Study Group 15 of the ITU-T for their thoughtful review.
ITU-Tの研究グループ15の質問14にも感謝します。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212] Shiomoto、K.、Papadimitriou、D.、Le Roux、Jl。、Vigoureux、M。、およびD. Brungard、「GMPLSベースのマルチレジオンおよびマルチ層ネットワーク（MRN/MLN）の要件」RFC 5212、2008年7月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、Nadeau、T。、およびJ. Lang、「トラフィックエンジニアリングリンク管理情報ベース」、RFC 4220、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783] Berger、L.、ed。、「Gmpls-アラーム情報の通信」、RFC 4783、2006年12月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
[RFC4803] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ラベルスイッチングルーター（LSR）管理情報ベース」、RFC 4803、2007年2月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートする"、RFC 4872、2007年5月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974] Papadimitriou、D。およびA. Farrel、「一般化されたMPLS（GMPLS）RSVP-TEシグナル伝達拡張機能」、RFC 4974、2007年8月。
[ETH-OAM] Takacs, A., Gero, B., and D. Mohan, "GMPLS RSVP-TE Extensions to Control Ethernet OAM", Work in Progress, July 2008.
[Eth-Oam] Takacs、A.、Gero、B。、およびD. Mohan、「GMPLS RSVP-TE拡張機能を制御するイーサネットOAM」、2008年7月、進行中の作業。
[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks", Work in Progress, October 2007.
[GMPLS-OAM] Nadeau、T.、Otani、T。Brungard、D。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークのOAM要件」、2007年10月の作業。
[GR-SHUT] Ali, Z., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Work in Progress, July 2008.
[Gr-shut] Ali、Z.、Zamfir、A。、およびJ. Newton、「MPLSおよび一般化されたMPLSトラフィックエンジニアリングネットワークの優雅なシャットダウン」、2008年7月の作業。
[HIER-BIS] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and Z. Ali, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Work in Progress, February 2008.
[hier-bis] Shiomoto、K.、Rabbat、R.、Ayyangar、A.、Farrel、A.、and Z. Ali、「動的に信号型階層ラベルの切り替えパスの手順」、2008年2月の作業。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年7月、進行中の作業。
[PCE-INTER] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", Work in Progress, June 2008.
[PCE-INTER] Oki、E.、Le Roux、J-L。、およびA. Farrel、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、2008年6月、Work in Progress。
[TED-MIB] Miyazawa, M., Otani, T., Nadeau, T., and K. Kunaki, "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Work in Progress, July 2008.
[Ted-Mib] Miyazawa、M.、Otani、T.、Nadeau、T。、およびK. Kunaki、「MPLS-TE/GMPLSをサポートするトラフィックエンジニアリングデータベース管理情報ベース」、2008年7月の進行中。
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ, 07748 USA EMail: dbrungard@att.com
デボラ・ブランガードAT＆T RM。D1-3C22-200 S.ローレルアベニュー、ニュージャージー州ミドルタウン、07748 USAメール：dbrungard@att.com
Eiji Oki NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan EMail: oki.eiji@lab.ntt.co.jp
eiji oki ntt 3-9-11 Midori-Cho Musashino、東京180-8585、日本メール：oki.eiji@lab.ntt.co.jp
Kohei Shiomoto NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan EMail: shiomoto.kohei@lab.ntt.co.jp
小屋shiomoto ntt 3-9-11 Midori-Cho Musashino、Tokyo 180-8585、日本メール：shiomoto.kohei@lab.ntt.co.jp
M. Vigoureux Alcatel-Lucent France Route de Villejust 91620 Nozay FRANCE EMail: martin.vigoureux@alcatel-lucent.fr
M.ヴィゴールアカテルルーセントフランスルートデヴィルジャスト91620ノザフランスメール：martin.vigoureux@alcatel-lucent.fr
Editors' Addresses
編集者のアドレス
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex、France Email：jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1、B-2018 Antwerpen、ベルギーメール：dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。