RFC5339 日本語訳
5339 Evaluation of Existing GMPLS Protocols against Multi-Layer andMulti-Region Networks (MLN/MRN). JL. Le Roux, Ed., D. Papadimitriou,Ed.. September 2008. (Format: TXT=53998 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group JL. Le Roux, Ed.
Request for Comments: 5339 France Telecom
Category: Informational D. Papadimitriou, Ed.
Alcatel-Lucent
September 2008
ワーキンググループJLをネットワークでつないでください。 エドル・ルー、コメントを求める要求: 5339年のフランス電子通信カテゴリ: エド情報のD.Papadimitriou、アルカテル透明な2008年9月
Evaluation of Existing GMPLS Protocols
against Multi-Layer and Multi-Region Networks (MLN/MRN)
マルチ層の、そして、マルチ領域のネットワークに対する既存のGMPLSプロトコルの評価(百万/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.
このドキュメントはMulti-層のNetworks(MLNs)とMulti-領域Networks(MRNs)のための要件に対してGeneralized Multiprotocol Label Switching(GMPLS)プロトコルとメカニズムの評価を提供します。 さらに、このドキュメントは、追加議定書拡大か手順がこれらの要件を満たすのに必要である領域を特定して、潜在的拡大のためのガイドラインを提供します。
Le Roux & Papadimitriou Informational [Page 1] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[1ページ]のRFC5339評価
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. 百万/MRN要件概観…4 3. 分析…5 3.1. マルチ層のネットワークの局面…5 3.1.1. 仮想ネットワークトポロジー再構成のために、支持します。5 3.1.1.1. ファ-LSPsセットアップ/リリースのコントロール…5 3.1.1.2. 仮想のTeはリンクされます…6 3.1.1.3. ファリリースの間の交通分裂最小化…8 3.1.1.4. 安定性…8 3.1.2. ファ-LSP属性には、遺産を支持してください…9 3.1.3. ファ-LSP接続性検証…9 3.1.4. スケーラビリティ…9 3.1.5. 百万/MRNの操作と管理…10 3.1.5.1. MIBモジュール…10 3.1.5.2. OAM…11 3.2. マルチ領域ネットワークの特定の局面…12 3.2.1. マルチ領域シグナリングのために、支持します。12 3.2.2. 調整能力の広告…13 4. 評価結論…16 4.1. 要件の追随性…16 5. セキュリティ問題…20 6. 承認…20 7. 参照…21 7.1. 標準の参照…21 7.2. 有益な参照…21 8. 貢献者のアドレス…23
Le Roux & Papadimitriou Informational [Page 2] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[2ページ]のRFC5339評価
1. Introduction
1. 序論
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(時間事業部Multiplexing)の切り換え、波長の切り換え、およびファイバーの切り換え([RFC3945]を見ます)。 Interface Switching Capability(ISC)概念は、これらの切り換え技術のために紹介されて、以下の通り指定されます: PSC(パケットSwitch Capable)、L2SC(層-2Switch Capable)、できるTDM、LSC(λSwitch Capable)、およびFSC(ファイバーSwitch Capable)。 表現であり、aと呼ばれた領域[RFC4206]が切り換え技術ドメインのGMPLS制御飛行機に、あります。 切り換えタイプは、ノードが特定のデータ飛行機技術に関するデータを転送する能力について説明して、唯一ネットワーク領域を特定します。
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]は、ただ一つのGMPLSコントロール飛行機例によって同じISC(例えば、TDM)か異なったISC(例えば、TDMとPSC)の複数のデータ飛行機切り換え層を包括して、制御されたTraffic Engineering(TE)ドメインになるようにNetwork(MLN)Multi-層を定義します。 [RFC5212]はさらにMLNsの特定のケースを定義します。 Multi-領域Network(MRN)は少なくとも2つの異なった切り換えタイプ(例えば、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.
このドキュメントの目的はメカニズムとプロトコル[RFC3945]、[RFC4202][RFC3471]MLNsとMRNsのための要件に対する[RFC3473)が[RFC5212]で定義した既存のGMPLSを評価することです。 この評価から、私たちは追加議定書拡大と変更がこれらの必要条件を満たすのに必要であるいくつかの領域を特定します、そして、潜在的拡大のためのガイドラインを提供します。
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コントロール飛行機の機能性を記述することに注意してください。 今後の研究には別々の層が異なった運営管理コントロールの下にある制御飛行機のパーティションがあります。
Le Roux & Papadimitriou Informational [Page 3] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[3ページ]のRFC5339評価
This document uses terminologies defined in [RFC3945], [RFC4206], and [RFC5212].
このドキュメントは[RFC3945]、[RFC4206]、および[RFC5212]で定義された用語を使用します。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. MLN/MRN Requirements Overview
2. 百万/MRN要件概観
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はMulti-層/領域Networks(MLN/MRN)のための1セットの機能条件書をリストアップします。 これらの要件を以下へまとめます、そして、[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:
- 強健なVirtual Network Topology(VNT)のために、再構成を支持してください。 これは以下の要件を含意します:
- Optimal control of Forwarding Adjacency Label Switched Path
(FA-LSP) setup and release (Section 5.8.1 of [RFC5212]);
- Forwarding Adjacency Label Switched Path(FA-LSP)セットアップとリリース(.1セクション5.8[RFC5212])の最適制御。
- Support for virtual TE links (Section 5.8.2 of [RFC5212]);
- 仮想のTEには、リンク(.2セクション5.8[RFC5212])を支えてください。
- 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]);
- 百万スケーラビリティ([RFC5212]のセクション5.3)。
- MLN Operations and Management (OAM) (Section 5.10 of [RFC5212]);
- 百万操作と管理(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]);
- Multi-領域シグナリングには、([RFC5212]のセクション5.7)を支持してください。
- Advertisement of the adjustment capacity (Section 5.2 of
[RFC5212]);
- 調整容量([RFC5212]のセクション5.2)の広告。
Le Roux & Papadimitriou Informational [Page 4] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[4ページ]のRFC5339評価
3. Analysis
3. 分析
3.1. Aspects of Multi-Layer Networks
3.1. マルチ層のネットワークの局面
3.1.1. Support for Virtual Network Topology Reconfiguration
3.1.1. 仮想ネットワークトポロジー再構成のサポート
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-LSPsの1セットは[RFC5212]上側の層にVirtual Network Topology(VNT)を供給します。 ソースと目的地ノード組の間の交通需要に従って層の中でVNT(FA-LSPセットアップ/リリース)を再構成することによって、ネットワーク性能要素(ネットワークの最大のリンク利用や残りの容量などの)を最適化できます。 そのような最適のVNT再構成は以下のセクションで分析される数個のメカニズムを含意します。
Note that the VNT approach is just one possible approach to performing inter-layer Traffic Engineering.
VNTアプローチが相互層のTraffic Engineeringを実行することへのちょうど1つの可能なアプローチであることに注意してください。
3.1.1.1. Control of FA-LSPs Setup/Release
3.1.1.1. ファ-LSPsセットアップ/リリースのコントロール
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.
Network Multi-層の中では、入って来る交通需要の変化に従って、FA-LSPsは上側の層から定期的に作成されて、変更されて、リリースされます。
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.
これは要求マトリクス、TEトポロジー、および潜在的に現在のVNTを考慮に入れるTEメカニズムを含意します、新しいVNTを計算して、セットアップするために。
Several functional building blocks are required to support such a TE mechanism:
いくつかの機能本位の建物ブロックがそのようなTEメカニズムをサポートするのに必要です:
- 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-LSPsをセットアップするか、またはリリースするという決定)に関して取り締まって計画となっています。 この機能担当の機能部品は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]).
- 変化を最小にするために潜在的に古い(存在している)VNTを考慮に入れるTEトポロジーに従ったVNT Path Computation。 VNT計算担当の機能部品は、ネットワーク要素の上で分配されるか、または外部要素(Path Computation Element(PCE)、[RFC4655]などの)に実行されるかもしれません。
- FA-LSP setup/release.
- FA-LSPセットアップ/リリース。
Le Roux & Papadimitriou Informational [Page 5] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[5ページ]のRFC5339評価
GMPLS routing protocols provide TE topology discovery. GMPLS signaling protocols allow setting up/releasing FA-LSPs.
GMPLSルーティング・プロトコルはトポロジー発見をTEに供給します。 GMPLSシグナリングプロトコルで、FA-LSPsをセットアップするか、またはリリースします。
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].
GMPLSプロトコルの範囲の外にVNTM機能(リソース取り締まり/スケジューリング、FA-LSPs、FA-LSP構成をセットアップするか、または解放するという決定)があります。 層境界Label Switching Routers(LSRs)の直接上、または、1個以上の外部のツールを通してそのような機能性を達成できます。 外部のツールが使用されているとき、インタフェースが、FA-LSPsをセットアップするか、またはリリースするのに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-LSPsに決定を取らなければなりません。 そのような交通需要は満足している要求を含んでいます、どの1上側の層のLSPが首尾よくそうかがセットアップされるので、満たされていない要求と今後の要求と同様に。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.
最終的に、直接層境界LSRs、または、外部要素(Path Computation Element(PCE)、[RFC4655]などの)にVNTを形成するFA-LSPsの計算を実行できます、そして、これはVNTMの位置から独立しています。
Hence, to summarize, no GMPLS protocol extensions are required to control FA-LSP setup/release.
したがって、まとめるのに必要である、GMPLSプロトコル拡張子は、全くFA-LSPセットアップ/リリースを制御するのに必要ではありません。
3.1.1.2. Virtual TE Links
3.1.1.2. 仮想のTeリンク
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つの上側の層のノードの間の実際に下層における完全に食糧を供給されたFA-LSPに関連づけられないTEリンクです。 仮想のTEリンクは、広告に掲載されているTEリンクを支えるように下層におけるFA-LSPにセットアップするために可能性を表します。 どんなTEもリンクするとき、仮想のTEリンクの広告を出します、完全に食糧を供給されたTEリンクと定義された[RFC4206]で約束を守って。 IGP領域の中に特に、仮想のTEリンクの氾濫範囲があります、どんなTEリンクへのケースのようにも。
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はすぐに、合図されて、食糧を供給されます(下層に利用可能資源があれば)。
Le Roux & Papadimitriou Informational [Page 6] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[6ページ]のRFC5339評価
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.
GMPLSプロトコルの範囲の外に仮想のTEリンクのダイナミックな変更を引き金となるか、または取り締まるのに原因となるTEメカニズムがあります。
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.
- Soft FAアプローチは制御飛行機で実際にデータ飛行機で交差接続を起動しないでFA-LSPをセットアップするのから成ります。 一方では、すべてのトランジットLSRs(N正方形問題)のときに州の維持を必要としますが、他方では、これは何らかの入場コントロールを考慮するかもしれません。 本当に、Soft FAが活性であるときに、リソースはもう普通リンクを持っている他のSoft FAsによる使用に利用可能でないかもしれません。 これらのSoft FAはダイナミックにリリースされるでしょう、そして、対応する仮想のTEリンクは削除されるでしょう。 Soft FA LSPsは二次LSPsをセットアップするために[RFC4872]で説明されたものと同様の手順を用いるセットアップであるかもしれません。
Le Roux & Papadimitriou Informational [Page 7] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[7ページ]のRFC5339評価
- 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とパラメタを交換するのから単に成ります。 これは、トランジットLSRsのときに州の維持を必要としませんが、入場コントロール能力を減少させます。 仮想のTEリンクエンドポイントの間のそのような協会はResource予約プロトコルに拡大に依存するかもしれません--自動的にEngineering(RSVP-TE)を取引してください。Switched Optical Network(ASON)は、手順を[RFC4974]と呼びます。
Note that the support of virtual TE links does not require any GMPLS routing extension.
仮想のTEリンクのサポートが少しのGMPLSルーティング拡張子も必要としないことに注意してください。
3.1.1.3. Traffic Disruption Minimization during FA Release
3.1.1.3. ファリリースの間の交通分裂最小化
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を削除する前に、すべての入れ子にされたLSPsが、交通分裂を避けるためにFA-LSPから別ルートで送られて、取り外されなければなりません。 ここで必要であったメカニズムはTEリンクの優雅な削除に必要であるものと同様です。 削除メカニズムがTE-LSPsの交通を中断することのないTEリンクの削除のためにそれを許容するGraceful TEリンクは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リンクにおける帯域幅を引き下がらせるので、それは新しいLSPsに使用されません。
3.1.1.4. Stability
3.1.1.4. 安定性
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
下層LSPsの完全なメッシュが上下の層の間ですべての組の境界ノードの間で作成されるかもしれないことに注意してください。 下層LSPsの完全なメッシュの長所は上側の層のルーティングに安定性を提供するということです。 VNTが移り変わるなら、すなわち、上側の層の中で使用された推進テーブルは影響を与えられません。 さらに、上側の層の中でLSPsを支持するために、完全な可到達性と帯域幅への即座のアクセスがいつもあります。 しかし、また、それはそうします。
Le Roux & Papadimitriou Informational [Page 8] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[8ページ]のRFC5339評価
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.
全くCPUとメモリ消費であるかもしれない(スケーラビリティ衝撃)n^2つのRSVP-TEセッション(nが境界ノードの数であるところ)の維持を必要として以来の重要な欠点。 また、これは重要な帯域幅消耗に通じるかもしれません。 仮想のTEリンクの使用が帯域幅消耗問題を解決して、コントロール飛行機オーバーロードを減少させるかもしれないことに注意してください。
3.1.2. Support for FA-LSP Attribute Inheritance
3.1.2. ファ-LSP属性遺産のサポート
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 Linkが広告に掲載されているとき、パラメタは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の末端の両方が同じ方針で運転されるのを必要とすることに注意してください。
3.1.3. FA-LSP Connectivity Verification
3.1.3. ファ-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接続性検証が技術特有のメカニズムを当てにする、(例えば、G.707とG.783を使用するSDH、Bidrectional Forwarding Detection(BFD)を使用するMPLSのために;、など) いかなる他の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プロトコルはデータ・リンクが下層LSPsである上側の層のネットワークにおける、データ・リンク検証のコーディネートにメカニズムを提供するべきです。
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]に入れられるのを許容します。○Link Managementプロトコル[RFC4204]は、下層LSPsの向こう側の走行の終わりから狙っているプロトコルであり、終わりであるかもしれません。異なった層の試験手順のo Coordinationは操作上の問題です。
3.1.4. Scalability
3.1.4. スケーラビリティ
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ルーティングメカニズムを設計しなければなりません: - ノードの数--TEリンク(FA-LSPsを含んでいる)の数 - LSPsの数--領域と層の数--1TEあたりのInterface Switching Capability Descriptors(ISCDs)の数はリンクされます。
Le Roux & Papadimitriou Informational [Page 9] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[9ページ]のRFC5339評価
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によって設計されたIGPsに基づいています。 これらがノードとリンクの数で比較的よく比例するのが知られています。 複数の領域か層があるところに、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情報の量の潜在的増加はリンク単位で広告を出しました。 これは切り換えタイプあたり1つの比較的わずかな情報量(例えば、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リンクがルーティングのスケーリングに影響を与えるとき広告に掲載されるLSPsの数は議定書を作ります。 下層におけるFA- LSPsの完全なメッシュはn^2個のTEリンクに通じるでしょう。そこでは、nが層境界LSRsの数です。 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とメモリ消費であるかもしれない)の維持を必要とするので、下層におけるLSPsの完全なメッシュはGMPLSシグナリングのスケーラビリティに影響を与えるかもしれません。 セクション3.1を見てください。仮想のTEリンクの使用がコントロール飛行機オーバーロードを減少させるかもしれない、(.1 .2)。
3.1.5. Operations and Management of the MLN/MRN
3.1.5. 百万/MRNの操作と管理
[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プロトコルセットの中に既に存在していて、いくつかの要件が、現在、記述されないで、それらを支持するために新開発仕事を必要とするでしょう。
3.1.5.1. MIB Modules
3.1.5.1. MIBモジュール
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.
シグナリングプロトコル[RFC4802]の操作に関してGMPLSスイッチ[RFC4803]をモデル化して、制御して、制御して、報告するためにMIBモジュールを開発してあります。 これらは、複数の層の向こう側に作動する規制飛行機プロトコルのただ一つの例の操作を管理するのに首尾よく使用されるかもしれません。
Le Roux & Papadimitriou Informational [Page 10] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[10ページ]のRFC5339評価
[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モジュールを提供します、そして、これは、TEが、より高い層の中でリンクするとき下層におけるLSPsを利用可能にするので、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.
既存のMIBモジュールだけを使用するMLNを管理するのが可能でしょうが、[RFC5212]で観測されるように、ただ一つのMLN実体を構成するために別々のネットワーク層の管理を調整するためにさらなるMIBモジュールを作成できました。 事実上、そのようなMIBモジュールは既に参照をつけられたMIBモジュールでエントリーを結びつけるでしょう。
3.1.5.2. OAM
3.1.5.2. OAM
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機能がクライアント層から特に、制御可能でなければならなく、クライアント層制御飛行機メカニズムは、サーバ層の中で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.
これは通常、技術がバンドにおけるOAM(例えば、Wavelength事業部Multiplexing(WDM)ネットワーク)を支持できないからGMPLSによって制御された技術がそれ自身のOAM手順を含んでいないところのです。 これらの場合には、制御飛行機の存在はデータ飛行機の物理的な特性に少しも効果があるはずがないので、制御飛行機がOAM機能に加えることができないほとんどがあります。 しかしながら、既存のGMPLSプロトコル群は制御飛行機を通してデータ飛行機について確かめるのを助けることができる1セットのツールを提供します。 これらのツールは等しくそれら自身のOAMを含むネットワーク技術に適切です。
Le Roux & Papadimitriou Informational [Page 11] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[11ページ]のRFC5339評価
- 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.
- GMPLSルーティング・プロトコル[RFC4203]と[RFC4205]は、LSPがセットアップされるときネットワークで利用可能資源における変化を検出するのを可能にしながら、TEリンクの状態をあふれさせます。
- 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.
- Link Managementプロトコル[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]はネットワークの向こう側に欠点と問題を報告するのに使用できるNotifyメッセージを提供します。 メッセージは、複数のLSPsの失敗を報告する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の経路に沿って集められて、分配されるのを可能にします。
3.2. Specific Aspects of Multi-Region Networks
3.2. マルチ領域ネットワークの特定の局面
3.2.1. Support for Multi-Region Signaling
3.2.1. マルチ領域シグナリングのサポート
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:
実際に数個のケースがトランジットノードが複数のSwitching Capabilities(SCs)の間で下側の領域FA-LSPに使用されるのを選ぶことができたところにあります:
- 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.
- ゆるいホップがある明白なRoute Object(ERO)拡大: トランジットノードは、経路を広げるために持って、下側の領域SCsの1セットの中で選択しなければならないかもしれません。
- 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はリンクします: 領域境界ノードは、これらのSCsの中で高層地帯LSPのEROに含まれていたFA LSPのEROがいつマルチ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シグナリング手順で、与えられた経路に沿って使用されるかもしれないサウスカロライナのこのあいまいな選択を解決しません。
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シグナリングへの拡大は、使用できるサウスカロライナと経路に沿って使用できないサウスカロライナを示すために定義されなければなりません。
Le Roux & Papadimitriou Informational [Page 12] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[12ページ]のRFC5339評価
3.2.2. Advertisement of Adjustment Capacities
3.2.2. 調整能力の広告
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つのインタフェースの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]を通して提供する異なったスイッチング能力とインタコネクトするためにハイブリッドノードの特性を示します。 この情報で、経路計算は終わりから端へのマルチ領域リンクの間の信号を適合させることができるLSRsによって接合される異なったスイッチング能力のリンクを含んでいる経路を選択できます。
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はハイブリッドノードに関する例を示しています。 ハイブリッドノードには2個のスイッチング素子(マトリクス)とそれぞれ切り替わるPSCがあります。(スイッチング素子はTDMを支持します)。 ノードには、2PSCと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交通の調整を提供できます。 2つの方法がPSC LSPs(Port1かPort2)をセットアップするのにおいて可能です。 利用可能資源広告(例えば、UnreservedとMin/マックスLSP Bandwidth)は両方の道をカバーするべきです。
Network element
.............................
: -------- :
PSC : | PSC | :
Port1-------------<->---|#a | :
: +--<->---|#b | :
: | -------- :
: | ---------- :
TDM : +--<->--|#c TDM | :
Port2 ------------<->--|#d | :
: ---------- :
:............................
要素をネットワークでつないでください… : -------- : PSC: | PSC| : Port1-------------<->、-、--、|#a| : : +--<->。---|#b| : : | -------- : : | ---------- : TDM: +(<->)|#c TDM| : Port2------------<->--、|#d| : : ---------- : :............................
Figure 1a. Hybrid node.
図1a。 ハイブリッドノード。
Le Roux & Papadimitriou Informational [Page 13] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[13ページ]のRFC5339評価
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.
内部のDense Wavelength事業部Multiplexing(DWDM)のおかげで単一のインタフェースをもたらすためにPort1とPort2を一緒に分類できます: Link1。 これは以下の図1bで例証されます。
Network element
.............................
: -------- :
: | PSC | :
: | | :
: --|#a | :
: | | #b | :
: | -------- :
: | | :
: | ---------- :
: /| | | #c | :
: | |-- | | :
Link1 ========| | | TDM | :
: | |----|#d | :
: \| ---------- :
:............................
要素をネットワークでつないでください… : -------- : : | 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と)であると仮定しましょう。 ポート#、とdポート#bを通して数個のTDM LSPsをポート#aと、セットアップして、終えることを通した数個のPSC LSPsをセットアップした後に、155Mbだけの容量はポート#bでまだ有効です。 しかしながら、622Mbの容量はポート#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のために経路を計算するとき、このノードがこのLSPを終えることができないのを知らなければなりません、まだTDM-PSC調整に有効な155Mbの容量しかないとき。 したがって、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]で、リンクバンドリングが使用されていなくて、2個のTEリンクがLink1のために広告に掲載されるなら、この広告は可能です。
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(Port1)をリンクします: - ISCDサブTLV: マックスLSP帯域幅があるPSCは622Mbと等しいです--無遠慮な帯域幅は622Mbと等しいです。
Le Roux & Papadimitriou Informational [Page 14] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[14ページ]のRFC5339評価
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サブTLV: マックスLSP帯域幅があるTDM=VC4-4c--ISCD#2サブTLV: 155マックスLSP帯域幅があるPSC=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:
しかしながら、明白なスケーラビリティ理由でリンクバンドリングをするなら、現在のGMPLSルーティングに調整容量情報を失います、私たちが以下のTEに広告をリンクさせるとき:
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サブTLV: マックスLSP帯域幅があるTDM=VC4-4c--ISCD#2サブTLV: 622マックスLSP帯域幅があるPSC=Mb--無遠慮な帯域幅(同等な): 1399Mb。
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リンク属性として調整能力の広告に依存するかもしれません(それはInterface Switching Capability Descriptor 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がただ一つのスイッチング能力に関連しているかもしれません。 そのスイッチング能力のために各層(または、層のセット)に関連づけられたMin/マックスLSP Bandwidthを提供する(例えば、TDMインタフェースに)ためにこれを実行できます。 例えば、TDMスイッチング能力に関連づけられたインタフェース、VC-12を支持して、およびVC-4の切り換えを1ISCDサブTLVか2ISCDサブTLVsに関連づけることができます。 前者の場合、Min LSP BandwidthはVC-12とVC-4へのマックスLSP Bandwidthに用意ができています。 2番目の場合では、Min LSP BandwidthはVC-12とVC-12へのマックスLSP Bandwidthに用意ができています、最初のISCDサブTLVで。 そして、Min LSP BandwidthはVC-4とVC-4へのマックスLSP Bandwidthに用意ができています、第2ISCDサブTLVで。 したがって、前者の場合、Min LSP BandwidthがVC-12(そして、VC-4でない)に用意ができている限り、最初のISCDサブTLVの広告を出す限り、VC-12 LSPをセットアップするために、2番目の場合には、十分な容量がそのインタフェースのむこうにあります。
Le Roux & Papadimitriou Informational [Page 15] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[15ページ]のRFC5339評価
4. Evaluation Conclusion
4. 評価結論
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.
あいさつVirtual Network Topology(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);
- 強制的なマルチ領域シグナリング(サウスカロライナの包含/除外)のための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.
- 技術特有のOAMのコントロールと構成のための拡大に合図するGMPLSが処理します。
4.1. Traceability of Requirements
4.1. 要件の追随性
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)のどんな組み合わせからも成るtopologiesを扱うことができるはずです。プロトコル仕様の範囲、およびこのドキュメントのための範囲の外にo Path計算メカニズムがあります。
Le Roux & Papadimitriou Informational [Page 16] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[16ページ]のRFC5339評価
- 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 Thisは実現要件であり、プロトコル仕様の範囲を超えています、そして、このドキュメントのための範囲の外にそれはあります。
- 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 Path計算メカニズムがあります。
- 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.
- 下側の領域LSPsを終えて、高層地帯(調整能力)の交通を進めるノードの性能の広告が必要であり[RFC5212]、セクション5.2) . o Seeセクション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 Path計算メカニズムがあります。
- 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-LSPsを含んでいる)の数--LSPsの数--領域と層の数--1TEあたりのISCDsの数はリンクされます。 ([RFC5212]、セクション5.3) . この.4通のo Seeセクション3.1ドキュメント。
- 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)o Allに基づいて広告を出している情報をフィルターにかけるとISCDが運ばれるので受信ノードが必要に応じてフィルターにかけるかもしれないというTE情報を防いではいけません。
- 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 Path計算メカニズムがあります。
Le Roux & Papadimitriou Informational [Page 17] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[17ページ]のRFC5339評価
- 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)で引き起こされたLSPsの創造、削除、および変更を可能にするためにプロトコルメカニズムを提供しなければなりません。o Suchメカニズムは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 Suchメカニズムは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.
- 交通需要や、トポロジーや、ネットワーク失敗などの変化への適合を可能にするためにプロトコルメカニズムを提供するかもしれません。 セクション5.4) . それらの変化[RFC5212]、この.1通のo Seeセクション3.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の再構成は、できるだけ非破壊的でなければならなく、セクション5.5) . オペレータ[RFC5212]によって構成された方針、この.3が記録するo Seeセクション3.1.1のコントロールの下にあるに違いありません。
- 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のパラメタから引き継がれるべきです。セクション5.6) . オペレータ[RFC5212]、この.2通のo Seeセクション3.1ドキュメントによって構成されて、取り締まります。
- 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]上側の層(GMPLSシグナリング[RFC3473]のためのセクション5.7) . o Standard)にホップだけを含んでいるEROを含むかもしれません。 また、セクション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)o StandardをGMPLSシグナリング[RFC3473]に指定するEROを含むかもしれません。 また、セクション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の再最適化の一部として、下層がFA-LSPであると別ルートで送るのは対応するTEリンクに関するインタフェース識別子を変わりがなく保って、より高い層の交通([RFC5212]、セクション5.8.1)○ Seeセクション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.
- 解決策は不安定化が下側の層のLSPsセクション5.8 交通需要が敷居[RFC5212]の近くで異なるので.1と5.8の急速なセットアップと分解で.2を引き起こしたネットワーク) . oに対してSeeセクション3.1.1.4を保護する測定を含まなければなりません。
Le Roux & Papadimitriou Informational [Page 18] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[18ページ]のRFC5339評価
- 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.
- 下層LSPsのシグナリングはTEリンクとして上側の層の中に急速にLSPの広告を出すためにメカニズムを含むべきです、そして、どのルーティング例にTEリンクを調整するかの広告を出すべきです([RFC5212]、セクション5.8.1)。o Thisを[RFC4206]は提供して、[HIER-BIS]は高めます。 また、.2にセクション3.1.1を見てください。
- 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に合図しなければならない基本的さでは、より低く. ○ Seeセクション3.1.1.2を層にしてください([RFC5212]、セクション5.8.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.
- 解決策は仮想のTEリンクの強化を容易にする操作、予測上側の層の交通需要を考慮に入れて、および下層([RFC5212]、セクション5.8.2)における利用可能なリソースに. ○ この.2通のSeeセクション3.1.1ドキュメントを提供するべきです。
- 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プロトコルはLSPs([RFC5212]、セクション5.9)この.3通のo Seeセクション3.1ドキュメントを上側の層のネットワークにおける、データ・リンク検証のコーディネートのためのデータ・リンクが下層であるメカニズムに供給するべきです。
- 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)○ Seeセクション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 Thisは運用政策を条件とした実現問題です。
- 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を有効にするのは可能であるに違いありません。 下層、操作がサーバ層のOAM操作([RFC5212]、セクション5.10)o Seeセクション3.1.5に写像される必要があるかもしれないクライアント層OAM.2にかかるのに使用されるテクニックによって、この機能は、正常なLSPベースのOAM[GMPLS-OAM]としてイングレスLSPにおいて現れますが、層の境界に現れます。
- 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.
- サーバ[RFC5212]層の制御飛行機メカニズムが写像して、可能にしなければならないクライアント層OAM、セクション5.10) . o Seeセクション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)Seeセクション3.1.5.2の全長に沿って作動しなければなりません。
Le Roux & Papadimitriou Informational [Page 19] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[19ページ]のRFC5339評価
- 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 Thisは実現問題です。
- 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 Thisは実現問題です。
- Implementations may use standardized techniques (such as MIB
modules) to convey status information between layers.
o This is an implementation matter.
- 実現は、状態情報を層の間に伝えるのに、標準化されたテクニック(MIBモジュールなどの)を使用するかもしれません。o Thisは実現問題です。
5. Security Considerations
5. セキュリティ問題
[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]で有名であることで、解決策ドキュメントがどんなプロトコル拡大も紹介する安全保障問題の完全な分析を含むと予想されます。
6. Acknowledgments
6. 承認
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のStudy Group15のQuestion14をありがとうございます。
Le Roux & Papadimitriou Informational [Page 20] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[20ページ]のRFC5339評価
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたマルチプロトコルラベルは(GMPLS)構造を切り換えること」での10月2004日
[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)をラベルします」、RFC4202、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)、ビグルー、M.、およびD.Brungard、「GMPLSを拠点とするマルチ領域の、そして、マルチ層のネットワーク(MRN/百万)のための要件」RFC5212(2008年7月)。
7.2. Informative References
7.2. 有益な参照
[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.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[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(エド)、「一般化されたマルチプロトコルを支持したOSPF拡張子は切り換え(GMPLS)をラベルします」、RFC4203、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[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)をラベルする、」、RFC4205(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)を階層構造とラベルします」、RFC4206、2005年10月。
Le Roux & Papadimitriou Informational [Page 21] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[21ページ]のRFC5339評価
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
Link Management Information Base", RFC 4220, November
2005.
[RFC4220] ドュバックとM.とナドー、T.とJ.ラング、「交通工学リンク管理情報ベース」、RFC4220、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)ベースの構造」、RFC4655、2006年8月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm
Information", RFC 4783, December 2006.
[RFC4783] バーガー、L.、エド、「GMPLS--、アラーム情報に関するコミュニケーション、」、RFC4783、12月2006日
[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.ファレル(エド))は、「Multiprotocolラベルの切り換え(GMPLS)交通技術管理部会を一般化しました」、RFC4802、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.ファレル(エド))は、「Multiprotocolラベルの切り換え(GMPLS)ラベル切り換えルータ(LSR)管理情報ベースを一般化しました」、RFC4803、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)回復を一般化しました」、RFC4872、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」、RFC4974、2007年8月。
[ETH-OAM] Takacs, A., Gero, B., and D. Mohan, "GMPLS RSVP-TE
Extensions to Control Ethernet OAM", Work in Progress,
July 2008.
A.、下呂、B.、およびD.モハン、「イーサネットOAMを制御するGMPLS RSVP-Te拡大」という[ETH-OAM]Takacsは進歩、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]ナドー、T.、オータニ、D.、およびA.ファレル、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)ネットワークのためのOAM要件」というT.Brungardは進行中(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が閉まる]のアリ、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.
K.、Rabbat、R.、Ayyangar、A.、ファレル、A.、およびZ.アリ、「ダイナミックに合図された階層的なラベル切り換えられた経路への手順」という[HIER-BIS]Shiomotoは進行中(2008年2月)で働いています。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2008.
[MPLS-SEC] 牙、L.、エド、7月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
Le Roux & Papadimitriou Informational [Page 22] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[22ページ]のRFC5339評価
[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間の] Oki、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.
Progress(2008年7月)の[TED-MIB]宮沢とM.とオータニとT.とナドー、T.とK.Kunaki、「MPLS-TE/GMPLSを支持した交通Engineering Database Management Information基地」Work。
8. Contributors' Addresses
8. 貢献者のアドレス
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秒間ローレルAve。 ミドルタウン、ニュージャージー、07748米国メール: dbrungard@att.com
Eiji Oki NTT 3-9-11 Midori-Cho Musashino, Tokyo 180-8585, Japan EMail: oki.eiji@lab.ntt.co.jp
3 9-11テロのEiji Oki NTT美土里町武蔵野、東京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
3 9-11テロのKohei Shiomoto NTT美土里町武蔵野、東京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.のビグルーのアルカテル透明なフランスRoute de Villejust91620NozayフランスEMail: martin.vigoureux@alcatel-lucent.fr
Le Roux & Papadimitriou Informational [Page 23] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[23ページ]のRFC5339評価
Editors' Addresses
エディタのアドレス
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン・ルイル・ルーフランステレコム2、Lannion Cedex、大通りピアー-Marzin22307フランスEMail: jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリのPapadimitriouのアルカテル透明なフランシスWellensplein1、B-2018アントウェルペン(ベルギー)メール: dimitri.papadimitriou@alcatel-lucent.be
Le Roux & Papadimitriou Informational [Page 24] RFC 5339 Evaluation of GMPLS against MLN/MRN Reqs September 2008
百万/MRN Reqs2008年9月に対するGMPLSのル・ルーとPapadimitriouの情報[24ページ]のRFC5339評価
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Le Roux & Papadimitriou Informational [Page 25]
ル・ルーとPapadimitriou情報です。[25ページ]
一覧
スポンサーリンク
