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)
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.
この文書では、マルチレイヤネットワーク（MLNS）とマルチリージョンネットワークの要件（MRNs）に対する一般化マルチプロトコルラベルスイッチング（GMPLS）プロトコルとメカニズムの評価を提供します。また、この文書は、追加のプロトコルの拡張や手順がこれらの要件を満たすために必要な領域を特定し、潜在的な拡張のためのガイドラインを提供します。
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.
パケット交換、レイヤ2スイッチング、TDM（時分割多重）スイッチング、波長の切り替え、及び繊維スイッチング（[RFC3945]を参照のこと）：一般MPLS（GMPLS）は、複数のスイッチング技術を処理するためにMPLSを拡張します。次のようにインターフェイスのスイッチング能力（ISC）の概念は、これらのスイッチング技術のために導入され、指定された：PSC（パケットが対応スイッチ）、L2SC（レイヤ2スイッチ対応）、TDM対応は、LSC（ラムダは対応スイッチ）、およびFSC（ファイバー）対応スイッチ。 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三つの異なる層です。 [RFC5212]はマルチレイヤネットワーク（MLN）の層を切り替える複数のデータ・プレーンを含むトラフィックエンジニアリング（TE）ドメインであると定義し、同じISC（例えば、TDM）または異なるISC（例えば、TDMとPSC）とによって制御されるのいずれか単一のGMPLS制御プレーンインスタンス。 [RFC5212]はさらにMLNSの特定のケースを定義します。マルチリージョンネットワーク（MRN）は、少なくとも二つの異なるスイッチング型（例えば、PSCおよびTDM）をサポートTEドメインとして定義され、いずれかの同じデバイスまたは異なるものであり、単一のGMPLS制御プレーンの制御下でホストされていますインスタンス。
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機構と[RFC5212]で定義さMLNSとMRNsの要件に対するプロトコル（[RFC3945]、[RFC4202]、[RFC3471]、[RFC3473]）を評価することです。この評価から、我々は追加のプロトコル拡張や修正がこれらの要件を満たすために必要とされるいくつかの領域を特定し、我々は潜在的な拡張のためのガイドラインを提供します。
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要件の概要は、第3節は、現在のGMPLSプロトコルと機構は、これらの各要件を満たしているかどうかを評価次にセクション2に設けられています。要件は、既存のプロトコルによって満たされていない場合は、文書が必要なメカニズムは、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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):
ここで（したがってMRNへ）MLNに適用される要件のリストは、次のとおりです。
- 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]);
- 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のアプローチは、層間トラフィックエンジニアリングを実行するだけで一つの可能なアプローチであることに注意してください。
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:
いくつかの機能ビルディング・ブロックは、TEメカニズムをサポートしている必要があります。
- Discovery of TE topology and available resources.
- トポロジや利用可能な資源の発見。
- 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-LSPを、FA-LSPの設定に決定）はGMPLSプロトコルの範囲外です。このような機能は、レイヤーボーダーラベルスイッチングルータ（LSRの）上の、または1つ以上の外部ツールを介して直接達成することができます。外部ツールを使用する場合、インターフェイスはVNTMとネットワーク要素設定するようにとの間に必要とされる/ FA-LSPを解放します。これは、[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.
上層の交通需要のセットは、セットアップ/リリースFA-のLSPに意思決定を取るためにVNTマネージャのために必要とされます。そのようなトラフィック需要には、上位レイヤ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の計算は、層境界のLSRまたは外部要素（例えば、経路計算要素（PCE）、[RFC4655]）上で直接行うことができ、これは、の位置から独立していますVNTM。
Hence, to summarize, no GMPLS protocol extensions are required to control FA-LSP setup/release.
したがって、要約すると、何のGMPLSプロトコル拡張は、FA-LSPの設定/解除を制御するために必要とされません。
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リンクは、実際の下層に完全にプロビジョニングされたFA-LSPに関連付けられていない2つの上部層のノード間のTEリンクです。仮想のTEリンクがセットアップアドバタイズされたTEリンクをサポートするために、下層のFA-LSPの可能性を表します。仮想のTEリンクが完全にプロビジョニングされた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;
- 柔軟性：LSPパスの計算を考慮に下位レイヤの対応するFA-LSPの実際のプロビジョニング状態を取るすることなくTEリンクを使用可能にします。
- 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リンクを解放することはできません。このため、GMPLSシグナリングは、仮想のTEリンクをサポートするように拡張されなければなりません。
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乗問題）の状態の維持が必要ですが、一方で、これは一部のアドミッション制御を可能にすることができます。ソフト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）の自動交換光ネットワーク（ASON）の呼び出し手順[RFC4974]。
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.
したがって、GMPLSルーティングおよび/またはシグナリング拡張はTEリンクの優雅な削除をサポートするために必要とされます。これは、に記載された手順を利用してもよい[GR-SHUTは]：トランジットLSRは、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をサポートするための完全な到達性と帯域幅への即時アクセスが常にあります。それは非常にCPU-とメモリを消費する（スケーラビリティの影響）であってもよい、（nは境界ノードの数である）、N ^ 2 RSVP-TEセッションの維持を必要とするので、それはまた、重大な欠点を有しています。また、これはかなりの帯域幅の浪費につながる可能性があります。仮想の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.
他のLSPと同様に（等; Bidrectionalフォワーディング検出（BFD）を使用してMPLSのためにG.707およびG.783を使用してSDHため、例えば）FA-LSPの接続性検証は、技術固有のメカニズムに依存しています。従って、この要件は、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]に入れることを可能にします。リンク管理プロトコル[RFC4204] oを対象プロトコルであり、エンド・ツー・エンドの下位層の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ルーティングメカニズムは、以下のいずれかの増加によく比例するように設計されなければならない： - ノードの数 - FA-LSPを含むTEリンク（）の数 - LSPの数 - 数領域、層 - TEリンクあたりインタフェーススイッチング能力記述子（ISCDs）の数。
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における36バイト[RFC4203]）であり、各インターフェースは、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は層境界のLSRの数であり、N ^ 2つのTEリンク、につながります。これは、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).
それは下層のLSPのフルメッシュは、GMPLSシグナリングのスケーラビリティに影響を与えることができる、（非常にCPU-とメモリを消費することができる）、N ^ 2 RSVP-TEセッションの維持を必要とするからです。仮想の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モジュールは[RFC4803] GMPLSスイッチをモデル化し、制御するために開発されており、制御およびシグナリングプロトコル[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を管理することが可能であろうが、さらにMIBモジュールは、単一のMLNエンティティを構築するために別のネットワーク層の管理を調整するように製造することができました。このような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プロセスを開発する必要はないが、GMPLS手順は、これらのOAM処理の動作及び構成を調整することが望ましい場合があります。
[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機能は、クライアント層から制御可能でなければならず、クライアント層制御プレーン機構は、MAPとサーバ層内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.
- ルート記録することにより、予想ルートに対して、制御プレーンによって報告された経路を確認すること、プロトコル[RFC3473]をGMPLSシグナリングを介して利用可能です。この機構はまた、その経路の各ホップで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.
- プロトコル[RFC3473]をGMPLSシグナリングは、（例えば、電力レベルなど）エンド・ツー・エンドの特性をサンプリングし、修正することができるように、「テスト」モードに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シグナリング[RFC3473]は、ネットワーク全体の障害や問題を報告するために使用することができる通知メッセージを提供します。メッセージは一つのメッセージが複数のLSPの失敗を報告できるようにする機能をスケーリング含まれています。
- 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.
- [RFC4783]をGMPLSシグナリングの拡張は、より簡単に調整および相関のための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リンク：FA LSPのEROが、上部領域LSPのEROに含まれる、領域の境界ノードは、これらのSCの中から選択しなければならないマルチSC TEリンクを含みます。
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（S）及び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]を介して提供する異なるスイッチング機能を相互接続するために、ハイブリッドノードのプロパティを指します。この情報は、リンク間の信号を適合させることができるの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つのスイッチング素子（マトリックス）を有します。ノードは、二つのPSC及びTDMポート（ポート1とポート2、それぞれ）を有しています。また、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ポート2のリソースの一部を終了することが可能であるような方法で相互接続されています。また、それらは、受信/内部PSCインタフェース（#B）を介して送信されるPSCトラフィックの調整を提供することができます。二つの方法は、PSCのLSP（ポート1またはポート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.
リンク1：ポート1とポート2は、単一のインターフェースをもたらすために、一緒に内部の高密度波長分割多重（DWDM）のおかげでグループ化することができます。これは、以下の図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.
すべてのインターフェイスは、（最大LSPの帯域幅などの可能VC4-16cと）STM16であると仮定しましょう。ポート#Aを介していくつかのPSC LSPを設定し、設定およびポート#Dとポート#Bを介していくつかのTDMのLSPを終了した後、唯一の155メガビットの容量は、ポート#Bに依然として利用可能です。しかし、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メガビットの容量があるので、このノードは、この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.
リンクバンドリングを使用しない場合と2つのTEリンクがリンク1のために宣伝されている場合は、現在のGMPLSルーティング[RFC4202]を使用すると、この広告が可能です。
We would have the following TE link advertisements:
我々は、次のTEリンクの広告を持っています：
TE link 1 (Port1): - ISCD sub-TLV: PSC with Max LSP bandwidth = 622 Mb - Unreserved bandwidth = 622 Mb.
TEリンク1（ポート1）： - ISCDサブTLV：最大LSP帯域幅= 622 MBのPSC - 非予約帯域幅= 622メガビット。
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（ポート2）： - ISCD＃1のサブTLV：最大LSP帯域幅のTDM = VC4-4cで、 - ISCD＃2サブTLV：最大LSP帯域幅を有するPSC = 155メガビット、 - 未予約帯域幅（等価）：777 MB。
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（ポート1 +ポート2）： - ISCD＃1サブTLV：最大LSP帯域幅= VC4-4cで、とTDM - ISCD＃2サブTLV：最大LSP帯域幅= 622 MBのPSC、 - 未予約帯域幅（等価） ：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.
そのようなTEリンク広告では、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.
注：複数のISCDsは、単一のスイッチング機能を関連付けることができます。これは、そのスイッチング機能のために（例えば、TDMインターフェイスの）最小/最大LSP帯域幅は、各レイヤに関連する（又は層のセット）を提供するために行うことができます。例えば、TDMスイッチング機能に関連し、VC-12およびVC-4のスイッチングをサポートするインタフェースは、一つISCDサブTLV又は二ISCDサブTLVのに関連付けることができます。最初のケースでは、最小LSP帯域幅は、VC-4にVC-12およびマックスLSP帯域幅に設定されています。第二の場合では、最小LSP帯域幅は、第ISCDサブTLVに、VC-12およびVC-12マックスLSP帯域幅に設定されています。そして、Min LSP帯域幅は第ISCDサブTLVに、VC-4にVC-4およびマックスLSP帯域幅に設定されています。従って、第1の場合に限り最小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）計算および再構成に関して、特定のTEメカニズムを定義する必要があるが、これらのメカニズムは、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;
- 優雅なTEリンクの削除の拡張子をGMPLSシグナリング。
- GMPLS signaling extension for constrained multi-region signaling (SC inclusion/exclusion);
- 制約マルチリージョンシグナリング（SC包含/除外）の拡張シグナリングGMPLS。
- 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.
- GMPLS技術固有のOAMプロセスの制御や設定のための拡張機能を知らせます。
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ルーティングメカニズムは、以下のいずれかの増加によく比例するように設計されなければならない： - ノードの数 - （FA-LSPを含む）、TEリンクの数 - LSPの数 - 領域及び層の数 - ISCDs数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.
- ルーティングプロトコルの設計ISCDs（[RFC5212]、セクション5.3）に基づいてフィルタリングTE情報を妨げてはなりません。 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].
- プロトコルメカニズムは、運用アクション（[RFC5212]、セクション5.4）を介してトリガの作成、削除、およびLSPの変更を可能にするために提供されなければなりません。 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リンクのパラメータは、オペレータによって設定ポリシーに基づいて、TEリンクを提供下層LSPのパラメータから継承されるべきである（[RFC5212]、セクション5.6）。 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.
- 上位レイヤのシグナリング要求は、上位レイヤ（[RFC5212]、セクション5.7）においてホップを含むEROを含んでいてもよいです。 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リンクのインタフェース識別子を維持し、上位層のトラフィック（[RFC5212]にのみ最小限の中断をせながら下層FA-LSPを再ルーティングすることが可能でなければなりません、 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.
- 急速に上層のTEリンクとしてLSPをアドバタイズするためのメカニズムを含むべきであり、TEリンクがアドバタイズされるべきルーティングインスタンスに調整するために下位レイヤLSPのシグナリング（[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.
- 上位レイヤLSPは、仮想のTEリンクを利用して設定されている場合、基礎となる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.
- クライアントレイヤの制御プレーンメカニズムは、MAPとサーバ層で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の動作は、その全長（[RFC5212]、セクション5.10）に沿って、そのLSPのために動作しなければなりません。 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.
私たちは彼らの有益なコメントをジュリアンMeuric、イゴールBryskin、およびエードリアンファレルに感謝したいと思います。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（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.、ルルー、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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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.、エド。、およびY. Rekhter、エド。、 "中間システム（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、ナドー、T.、およびJ.ラング、 "トラフィックエンジニアリングリンク管理情報ベース"、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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]バーガー、L.、エド、 "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]ナドー、T.、エド。、およびA.ファレル、エド。、 "一般化マルチプロトコルラベルスイッチング（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]ナドー、T.、エド。、およびA.ファレル、エド。、 "ルータ（LSR）管理情報ベーススイッチング汎用マルチプロトコルラベルスイッチング（GMPLS）ラベル"、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]ラング、J.、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、「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.ファレル、 "一般化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.
、進歩、2008年7月に仕事[ETH-OAM]タカーチ、A.、下呂、B.、およびD.モハン、 "コントロールイーサネットOAMへのGMPLS RSVP-TE拡張機能"。
[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]ナドー、T.、大谷、T. Brungard、D.、およびA.ファレル、 "（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]アリ、Z.、Zamfir、A.、およびJ.ニュートン、 "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.、ファレル、A.、およびZ.アリ、進歩、2008年2月に仕事を "動的ための手順は、階層的なラベルはパスの交換合図"。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[MPLS-SEC]牙、L.、エド。、 "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]沖、E.、ル・ルー、J-L。、およびA.ファレル、 "PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのための枠組み"、進歩、2008年6月に作業。
[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]宮沢、M.、大谷、T.、ナドー、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
デボラBrungard AT＆T Rmの。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ、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
えいじ おき んっｔ ３ー９ー１１ みどりーちょ むさしの、 ときょ １８０ー８５８５、 じゃぱん えまいｌ： おき。えいじ＠ぁｂ。んっｔ。こ。ｊｐ
Kohei Shiomoto NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan EMail: shiomoto.kohei@lab.ntt.co.jp
こへい しおもと んっｔ ３ー９ー１１ みどりーちょ むさしの、 ときょ １８０ー８５８５、 じゃぱん えまいｌ： しおもと。こへい＠ぁｂ。んっｔ。こ。ｊｐ
M. Vigoureux Alcatel-Lucent France Route de Villejust 91620 Nozay FRANCE EMail: martin.vigoureux@alcatel-lucent.fr
氏ヘイルアルカテル・ルーセントフランスルートヴィルジュNozay FRANCE 91620 Eメール：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
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンセデックス、フランスEメール：jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルLykentフランシスVellensplein 1 B-2018アントワープ、Velgiom電子メール：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。