RFC5212 日本語訳
5212 Requirements for GMPLS-Based Multi-Region and Multi-LayerNetworks (MRN/MLN). K. Shiomoto, D. Papadimitriou, JL. Le Roux, M.Vigoureux, D. Brungard. July 2008. (Format: TXT=70286 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Shiomoto
Request for Comments: 5212 NTT
Category: Informational D. Papadimitriou
Alcatel-Lucent
JL. Le Roux
France Telecom
M. Vigoureux
Alcatel-Lucent
D. Brungard
AT&T
July 2008
Shiomotoがコメントのために要求するワーキンググループK.をネットワークでつないでください: 5212年のNTTカテゴリ: 情報のD.Papadimitriouアルカテル透明なJL。 D.Brungard AT&T2008年7月にアルカテル透明なル・ルー・フランステレコムのM.ビグルー
Requirements for GMPLS-Based
Multi-Region and Multi-Layer Networks (MRN/MLN)
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
要約
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.
Generalized MPLS(GMPLS)を利用する初期の取り組みの大部分は、ただ一つのスイッチング能力でデバイスを接待しながら、環境に関連しました。 そのようなデータ飛行機のコントロールで上げられた複雑さは古典的なIP/MPLSネットワークで見られたそれと同様です。 複数の切り換え技術をサポートするためにMPLSを広げることによって、GMPLSはただ一つの切り換え技術か複数の切り換え技術のどちらかの多層性のネットワークのコントロールに包括的なフレームワークを提供します。
In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi- layer networks and lists a set of functional requirements.
GMPLSでは、切り換え技術ドメインは領域を定義します、そして、複数の切り換えタイプのネットワークは本書ではマルチ領域ネットワーク(MRN)と呼ばれます。 一般に、階層型ネットワーク(単一であるか複数の領域から成るかもしれない)を示すとき、このドキュメントは用語マルチネットワーク(MLN)層を使用します。 このドキュメントは、マルチGMPLSのベースのマルチ領域/層のネットワークのためにフレームワークを定義して、1セットの機能条件書をリストアップします。
Shiomoto, et al. Informational [Page 1] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [1ページ]情報のRFC5212MRN/百万要件2008年7月
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................4
2. Conventions Used in This Document ...............................5
2.1. List of Acronyms ...........................................6
3. Positioning .....................................................6
3.1. Data Plane Layers and Control Plane Regions ................6
3.2. Service Layer Networks .....................................7
3.3. Vertical and Horizontal Interaction and Integration ........8
3.4. Motivation .................................................9
4. Key Concepts of GMPLS-Based MLNs and MRNs ......................10
4.1. Interface Switching Capability ............................10
4.2. Multiple Interface Switching Capabilities .................11
4.2.1. Networks with Multi-Switching-Type-Capable
Hybrid Nodes .......................................12
4.3. Integrated Traffic Engineering (TE) and Resource Control ..12
4.3.1. Triggered Signaling ................................13
4.3.2. FA-LSPs ............................................13
4.3.3. Virtual Network Topology (VNT) .....................14
5. Requirements ...................................................15
5.1. Handling Single-Switching and
Multi-Switching-Type-Capable Nodes ........................15
5.2. Advertisement of the Available Adjustment Resources .......15
5.3. Scalability ...............................................16
5.4. Stability .................................................17
5.5. Disruption Minimization ...................................17
5.6. LSP Attribute Inheritance .................................17
5.7. Computing Paths with and without Nested Signaling .........18
5.8. LSP Resource Utilization ..................................19
5.8.1. FA-LSP Release and Setup ...........................19
5.8.2. Virtual TE Links ...................................20
5.9. Verification of the LSPs ..................................21
5.10. Management ...............................................22
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
9. Contributors' Addresses ........................................26
1. 序論…3 1.1. 範囲…4 2. このドキュメントで中古のコンベンション…5 2.1. 頭文字語のリスト…6 3. 置きます。6 3.1. データ飛行機層とコントロール飛行機地方…6 3.2. 層のネットワークにサービスを提供してください…7 3.3. 垂直で水平な相互作用と統合…8 3.4. 動機…9 4. GMPLSベースのMLNsとMRNsに関する重要な考え…10 4.1. スイッチング能力を連結してください…10 4.2. 複数のインタフェーススイッチング能力…11 4.2.1. できるマルチ切り替わっているタイプのハイブリッドノードのネットワーク…12 4.3. 統合交通工学(Te)とリソースは制御されます。12 4.3.1. シグナリングの引き金となります…13 4.3.2. ファ-LSPs…13 4.3.3. 仮想ネットワークトポロジー(VNT)…14 5. 要件…15 5.1. 取り扱い単一の切り換えとできるマルチ切り替わっているタイプノード…15 5.2. 利用可能な調整リソースの広告…15 5.3. スケーラビリティ…16 5.4. 安定性…17 5.5. 分裂最小化…17 5.6. LSPは継承を結果と考えます…17 5.7. 入れ子にされたシグナリングのあるなしにかかわらず経路を計算します…18 5.8. LSPリソース利用…19 5.8.1. ファ-LSPリリースとセットアップ…19 5.8.2. 仮想のTeはリンクされます…20 5.9. LSPsの検証…21 5.10. 管理…22 6. セキュリティ問題…24 7. 承認…24 8. 参照…25 8.1. 標準の参照…25 8.2. 有益な参照…25 9. 貢献者のアドレス…26
Shiomoto, et al. Informational [Page 2] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [2ページ]情報のRFC5212MRN/百万要件2008年7月
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).
一般化されたMPLS(GMPLS)は複数の切り換え技術を扱うためにMPLSを広げています: パケット交換、Layer-2の切り換え、TDM(時間事業部Multiplexing)の切り換え、波長の切り換え、およびファイバーの切り換え([RFC3945]を見ます)。 Interface Switching Capability(ISC)概念は、これらの切り換え技術のために紹介されて、以下の通り指定されます: PSC(できるパケット交換機)、L2SC(できる層-2スイッチ)、できるTDM、LSC(できるλスイッチ)、およびFSC(できるファイバースイッチ)。
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. A layer describes a data plane switching granularity level (e.g., VC4, VC-12). A data plane layer is associated with a region in the control plane (e.g., VC4 is associated with TDM, MPLS is associated with PSC). However, more than one data plane layer can be associated with the same region (e.g., both VC4 and VC12 are associated with TDM). Thus, a control plane region, identified by its switching type value (e.g., TDM), can be sub-divided into smaller-granularity component networks based on "data plane switching layers". The Interface Switching Capability Descriptor (ISCD) [RFC4202], identifying the interface switching capability (ISC), the encoding type, and the switching bandwidth granularity, enables the characterization of the associated layers.
表現であり、aと呼ばれた領域[RFC4206]が切り換え技術ドメインのGMPLS制御飛行機に、あります。 切り換えタイプは、ノードが特定のデータ飛行機技術に関するデータを転送する能力について説明して、唯一ネットワーク領域を特定します。 層はデータ飛行機切り換え粒状レベル(例えば、VC4、VC-12)について説明します。 データ飛行機層は制御飛行機の領域に関連しています(例えば、VC4がTDMに関連している、MPLSはPSCに関連しています)。 しかしながら、1つ以上のデータ飛行機層を同じ領域に関連づけることができます(例えば、VC4とVC12の両方がTDMに関連しています)。 したがって、「データ飛行機切り換え層」に基づくより小さい粒状コンポーネントネットワークに切り換えタイプ価値(例えば、TDM)によって特定されたコントロール飛行機領域は分筆できます。 Interface Switching Capability Descriptor(ISCD)[RFC4202](インタフェーススイッチング能力(ISC)を特定する、コード化しているタイプ、および切り換え帯域幅粒状)は関連層の特殊化を可能にします。
In this document, we define 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. We further define 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.
本書では、私たちは、ただ一つのGMPLSコントロール飛行機インスタンスによって同じISC(例えば、TDM)か異なったISC(例えば、TDMとPSC)の複数のデータ飛行機切り換え層を包括して、制御されたTraffic Engineering(TE)ドメインになるようにマルチネットワーク(MLN)層を定義します。 私たちはさらにMLNsの特定のケースを定義します。 マルチ領域ネットワーク(MRN)は同じデバイスで接待されるか、異なったもののどちらかと、ただ一つのGMPLSコントロール飛行機インスタンスのコントロールの下で少なくとも2つの異なった切り換えタイプが(例えば、PSCとTDM)であるとサポートするTEドメインと定義されます。
MLNs can be further categorized according to the distribution of the ISCs among the Label Switching Routers (LSRs):
ISCsの分配に従って、Label Switching Routers(LSRs)の中でMLNsをさらに分類できます:
- Each LSR may support just one ISC.
Such LSRs are known as single-switching-type-capable LSRs. The MLN
may comprise a set of single-switching-type-capable LSRs some of
which support different ISCs.
- 各LSRはちょうど1ISCをサポートするかもしれません。 そのようなLSRsはできる単独の切り換えタイプLSRsとして知られています。 MLNはそれの或るものが異なったISCsをサポートするできる単独の切り換えタイプLSRsの1セットを包括するかもしれません。
Shiomoto, et al. Informational [Page 3] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [3ページ]情報のRFC5212MRN/百万要件2008年7月
- Each LSR may support more than one ISC at the same time.
Such LSRs are known as multi-switching-type-capable LSRs, and can
be further classified as either "simplex" or "hybrid" nodes as
defined in Section 4.2.
- 各LSRは同時に、1ISCをサポートするかもしれません。 そのようなLSRsをできるマルチ切り替わっているタイプLSRsとして知っていて、セクション4.2で定義される「シンプレクス」か「ハイブリッド」のノードのどちらかとしてさらに分類できます。
- The MLN may be constructed from any combination of single-
switching-type-capable LSRs and multi-switching-type-capable LSRs.
- MLNは独身のできる切り換えタイプLSRsとできるマルチ切り替わっているタイプLSRsのどんな組み合わせからも組み立てられるかもしれません。
Since GMPLS provides a comprehensive framework for the control of different switching capabilities, a single GMPLS instance may be used to control the MLN/MRN. This enables rapid service provisioning and efficient traffic engineering across all switching capabilities. In such networks, TE links are consolidated into a single Traffic Engineering Database (TED). Since this TED contains the information relative to all the different regions and layers existing in the network, a path across multiple regions or layers can be computed using this TED. Thus, optimization of network resources can be achieved across the whole MLN/MRN.
GMPLSが異なったスイッチング能力のコントロールに包括的なフレームワークを提供するので、ただ一つのGMPLSインスタンスはMLN/MRNを制御するのに使用されるかもしれません。 これはすべてのスイッチング能力の向こう側に迅速なサービスの食糧を供給していて効率的な交通工学を可能にします。 そのようなネットワークでは、TEリンクは独身のTraffic Engineering Database(TED)に統合されます。 このTEDがネットワークで存在するすべての異なった領域と層に比例して情報を含んでいるので、このTEDを使用することで複数の領域か層の向こう側の経路を計算できます。 したがって、全体のMLN/MRNの向こう側にネットワーク資源の最適化を達成できます。
Consider, for example, a MRN consisting of packet-switch-capable routers and TDM cross-connects. Assume that a packet Label Switched Path (LSP) is routed between source and destination packet-switch- capable routers, and that the LSP can be routed across the PSC region (i.e., utilizing only resources of the packet region topology). If the performance objective for the packet LSP is not satisfied, new TE links may be created between the packet-switch-capable routers across the TDM-region (for example, VC-12 links) and the LSP can be routed over those TE links. Furthermore, even if the LSP can be successfully established across the PSC-region, TDM hierarchical LSPs (across the TDM region between the packet-switch capable routers) may be established and used if doing so is necessary to meet the operator's objectives for network resource availability (e.g., link bandwidth). The same considerations hold when VC4 LSPs are provisioned to provide extra flexibility for the VC12 and/or VC11 layers in an MLN.
例えば、できるパケットスイッチルータから成るMRNとTDMが十字接続であると考えてください。 ソースと目的地パケットスイッチできるルータの間にパケットLabel Switched Path(LSP)を発送して、PSC領域(すなわち、パケット領域トポロジーに関するリソースだけを利用する)の向こう側にLSPを発送できると仮定してください。 パケットLSPのためのパフォーマンス目標が満たされていないなら、TDM-領域の向こう側にできるパケットスイッチルータの間で新しいTEリンクを作成するかもしれません、そして、(例えば、VC-12はリンクします)それらのTEリンクの上にLSPを発送できます。 その上、PSC-領域の向こう側に首尾よくLSPを設立できても、そうするのがネットワーク資源の有用性のためにオペレータの目的を満たすのに必要であるなら(例えば、帯域幅をリンクしてください)、TDMの階層的なLSPs(パケット交換機のできるルータの間のTDM領域の向こう側の)は設立されて、使用されるかもしれません。 VC4 LSPsがMLNのVC12、そして/または、VC11層に付加的な柔軟性を供給するために食糧を供給されるとき、同じ問題は成立します。
Sections 3 and 4 of this document provide further background information of the concepts and motivation behind multi-region and multi-layer networks. Section 5 presents detailed requirements for protocols used to implement such networks.
このドキュメントのセクション3と4はマルチ領域の、そして、マルチ層のネットワークの後ろに概念と動機に関するさらなる基礎的な情報を提供します。 セクション5はそのようなネットワークを実装するのに使用されるプロトコルのための詳細な要件を提示します。
1.1. Scope
1.1. 範囲
Early sections of this document describe the motivations and reasoning that require the development and deployment of MRN/MLN. Later sections of this document set out the required features that the GMPLS control plane must offer to support MRN/MLN. There is no intention to specify solution-specific and/or protocol elements in
このドキュメントの早めのセクションはMRN/MLNの開発と展開を必要とする動機と推理について説明します。 このドキュメントの後のセクションはサポートするGMPLS制御飛行機がMRN/MLNを申し出でなければならない必要な特徴を出します。 ソリューション特有である、そして/または、プロトコル要素を指定する意志が全くありません。
Shiomoto, et al. Informational [Page 4] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [4ページ]情報のRFC5212MRN/百万要件2008年7月
this document. The applicability of existing GMPLS protocols and any protocol extensions to the MRN/MLN is addressed in separate documents [MRN-EVAL].
このドキュメント。 既存のGMPLSプロトコルとMRN/MLNへのどんなプロトコル拡大の適用性も別々のドキュメント[MRN-EVAL]で扱われます。
This document covers the elements of a single GMPLS control plane instance controlling multiple layers within a given TE domain. A control plane instance can serve one, two, or more layers. Other possible approaches such as having multiple control plane instances serving disjoint sets of layers are outside the scope of this document. It is most probable that such a MLN or MRN would be operated by a single service provider, but this document does not exclude the possibility of two layers (or regions) being under different administrative control (for example, by different Service Providers that share a single control plane instance) where the administrative domains are prepared to share a limited amount of information.
このドキュメントは与えられたTEドメインの中の複数の層を制御するただ一つのGMPLSコントロール飛行機インスタンスの要素をカバーしています。 コントロール飛行機インスタンスは1、2つ以上の層に役立つことができます。 このドキュメントの範囲の外に複合管理飛行機インスタンス給仕に層のセットをばらばらにならせることなどの他の可能なアプローチがあります。 そのようなMLNかMRNがただ一つのサービスプロバイダーによって運用されるのが、最もありえそうですが、このドキュメントは、管理ドメインが情報の数量限定を共有するように準備されるところに異なった運営管理コントロール(例えば単一管理飛行機インスタンスを共有する異なったService Providers)の下にありながら、2つの層(または、領域)の可能性を除きません。
For such a TE domain to interoperate with edge nodes/domains supporting non-GMPLS interfaces (such as those defined by other standards development organizations (SDOs)), an interworking function may be needed. Location and specification of this function are outside the scope of this document (because interworking aspects are strictly under the responsibility of the interworking function).
縁のノード/ドメインが、非GMPLSがインタフェース(他の規格開発組織(SDOs)によって定義されたものなどの)であるとサポートしていてそのようなTEドメインが共同利用するために、織り込む機能が必要であるかもしれません。 このドキュメントの範囲の外にこの機能の位置と仕様があります(織り込む局面が厳密に織り込む機能の責任の下にあるので)。
This document assumes that the interconnection of adjacent MRN/MLN TE domains makes use of [RFC4726] when their edges also support inter- domain GMPLS RSVP-TE extensions.
このドキュメントは、また、それらの縁が相互ドメインGMPLS RSVP-TE拡張子をサポートすると隣接しているMRN/MLN TEドメインのインタコネクトが[RFC4726]を利用すると仮定します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
Although this is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in this document to highlight requirements, and are to be interpreted as described in RFC 2119 [RFC2119].
これはプロトコル仕様ではありませんが、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは要件を強調するのに本書では使用されて、RFC2119[RFC2119]で説明されるように解釈されることであるべきですか?
In the context of this document, an end-to-end LSP is defined as an LSP that starts in some client layer, ends in the same layer, and may cross one or more lower layers. In terms of switching capabilities, this means that if the outgoing interface on the head-end LSR has interface switching capability X, then the incoming interface on the tail-end LSR also has switching capability X. Further, for any interface traversed by the LSP at any intermediate LSR, the switching capability of that interface, Y, is such that Y >= X.
このドキュメントの文脈では、終わりから終わりへのLSPは何らかのクライアント層の中で始まって、同じ層に終わって、1つ以上の下層に交差するかもしれないLSPと定義されます。 スイッチング能力に関して、これは、また、ギヤエンドLSRの上の外向的なインタフェースにインタフェーススイッチング能力Xがあるなら末端LSRの上の入って来るインタフェースにはスイッチング能力X.Furtherがあることを意味します、Y>がどんな中間的LSRでもLSPによって横断されたどんなインタフェース、そのインタフェースのスイッチング能力(Y)がそのようなものであるのでもXと等しいので。
Shiomoto, et al. Informational [Page 5] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [5ページ]情報のRFC5212MRN/百万要件2008年7月
2.1. List of Acronyms
2.1. 頭文字語のリスト
ERO: Explicit Route Object FA: Forwarding Adjacency FA-LSP: Forwarding Adjacency Label Switched Path FSC: Fiber Switching Capable ISC: Interface Switching Capability ISCD: Interface Switching Capability Descriptor L2SC: Layer-2 Switching Capable LSC: Lambda Switching Capable LSP: Label Switched Path LSR: Label Switching Router MLN: Multi-Layer Network MRN: Multi-Region Network PSC: Packet Switching Capable SRLG: Shared Risk Link Group TDM: Time-Division Multiplexing TE: Traffic Engineering TED: Traffic Engineering Database VNT: Virtual Network Topology
ERO: 明白なルートオブジェクトファ: 推進隣接番組ファ-LSP: 推進隣接番組ラベルは経路FSCを切り換えました: ファイバーの切り換えのできるISC: スイッチング能力ISCDを連結してください: スイッチング能力記述子L2SCを連結してください: 層-2の切り換えのできるLSC: λ切り換えのできるLSP: ラベルは経路LSRを切り換えました: 切り換えルータ百万をラベルしてください: マルチ層のネットワークMRN: マルチ領域ネットワークPSC: パケット交換のできるSRLG: リスクリンク群TDMは共有しました: 時分割多重化Te: 交通工学TED: 交通工学データベースVNT: 仮想ネットワークトポロジー
3. Positioning
3. 位置決め
A multi-region network (MRN) is always a multi-layer network (MLN) since the network devices on region boundaries bring together different ISCs. A MLN, however, is not necessarily a MRN since multiple layers could be fully contained within a single region. For example, VC12, VC4, and VC4-4c are different layers of the TDM region.
領域境界のネットワークデバイスが異なったISCsを集めるので、いつもマルチ領域ネットワーク(MRN)はマルチネットワーク(MLN)層です。 ただ一つの領域の中に複数の層を完全に保管できたので、しかしながら、MLNは必ずMRNであるというわけではありません。 例えば、VC12、VC4、およびVC4-4cはTDM領域の異なった層です。
3.1. Data Plane Layers and Control Plane Regions
3.1. データ飛行機層とコントロール飛行機地方
A data plane layer is a collection of network resources capable of terminating and/or switching data traffic of a particular format [RFC4397]. These resources can be used for establishing LSPs for traffic delivery. For example, VC-11 and VC4-64c represent two different layers.
データ飛行機層は特定の形式[RFC4397]のデータ通信量を終える、そして/または、切り換えることができるネットワーク資源の収集です。 トラフィック配送のためにLSPsを設立するのにこれらのリソースを使用できます。 例えば、VC-11とVC4-64cは2つの異なった層を表します。
From the control plane viewpoint, an LSP region is defined as a set of one or more data plane layers that share the same type of switching technology, that is, the same switching type. For example, VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. Hence, an LSP region is a technology domain (identified by the ISC type) for which data plane resources (i.e., data links) are represented into the control plane as an aggregate of TE information
コントロール飛行機観点から、LSP領域は同じタイプについて技術を切り換えるすなわち、同じ切り換えタイプを共有する1つ以上のデータ飛行機層のセットと定義されます。 例えば、VC-11、VC-4、およびVC-4-7v層は同じTDM領域の一部です。 現在定義される領域は以下の通りです。 PSC、L2SC、TDM、LSC、およびFSC。 したがって、LSP領域はデータ飛行機リソース(すなわち、データ・リンク)がTE情報の集合として制御飛行機に表される技術ドメイン(ISCタイプによって特定される)です。
Shiomoto, et al. Informational [Page 6] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [6ページ]情報のRFC5212MRN/百万要件2008年7月
associated with a set of links (i.e., TE links). For example, VC-11 and VC4-64c capable TE links are part of the same TDM region. Multiple layers can thus exist in a single region network.
1セットのリンク(すなわち、TEリンク)に関連しています。 例えば、VC-11とVC4-64cのできるTEリンクは同じTDM領域の一部です。 その結果、複数の層がただ一つの領域ネットワークで存在できます。
Note also that the region may produce a distinction within the control plane. Layers of the same region share the same switching technology and, therefore, use the same set of technology-specific signaling objects and technology-specific value setting of TE link attributes within the control plane, but layers from different regions may use different technology-specific objects and TE attribute values. This means that it may not be possible to simply forward the signaling message between LSRs that host different switching technologies. This is due to changes in some of the signaling objects (for example, the traffic parameters) when crossing a region boundary even if a single control plane instance is used to manage the whole MRN. We may solve this issue by using triggered signaling (see Section 4.3.1).
また、領域が制御飛行機の中に区別を起こすかもしれないことに注意してください。 同じ領域の層は、同じ切り換え技術を共有して、したがって、制御飛行機の中に同じセットの技術特有のシグナリングオブジェクトとTEリンク属性の技術特有の値の設定を使用しますが、異なった領域からの層は異なった技術特有のオブジェクトとTE属性値を使用するかもしれません。 これは、単に異なった切り換え技術をホスティングするLSRsの間にシグナリングメッセージを転送するのが可能でないかもしれないことを意味します。 単一管理飛行機インスタンスが全体のMRNを管理するのに使用されても領域境界に交差するとき、これはいくつかのシグナリングオブジェクト(例えば、トラフィックパラメタ)における変化のためです。 私たちは、引き起こされたシグナリングを使用することによって、この問題を解決するかもしれません(セクション4.3.1を見てください)。
3.2. Service Layer Networks
3.2. サービス層のネットワーク
A service provider's network may be divided into different service layers. The customer's network is considered from the provider's perspective as the highest service layer. It interfaces to the highest service layer of the service provider's network. Connectivity across the highest service layer of the service provider's network may be provided with support from successively lower service layers. Service layers are realized via a hierarchy of network layers located generally in several regions and commonly arranged according to the switching capabilities of network devices.
サービスプロバイダーのネットワークは異なったサービス層に分割されるかもしれません。 顧客のネットワークはプロバイダーの見解から最も高いサービス層と考えられます。 それは最も高いサービス層のサービスプロバイダーのネットワークに連結します。 サポートを相次ぎ低級なサービス層から最も高いサービス層のサービスプロバイダーのネットワークの向こう側の接続性に提供するかもしれません。 サービス層は一般に、いくつかの領域に位置していて、ネットワークデバイスのスイッチング能力に従って一般的に配置されたネットワーク層の階層構造で実現されます。
For instance, some customers purchase Layer-1 (i.e., transport) services from the service provider, some Layer 2 (e.g., ATM), while others purchase Layer-3 (IP/MPLS) services. The service provider realizes the services by a stack of network layers located within one or more network regions. The network layers are commonly arranged according to the switching capabilities of the devices in the networks. Thus, a customer network may be provided on top of the GMPLS-based multi-region/multi-layer network. For example, a Layer-1 service (realized via the network layers of TDM, and/or LSC, and/or FSC regions) may support a Layer-2 network (realized via ATM Virtual Path / Virtual Circuit (VP/VC)), which may itself support a Layer-3 network (IP/MPLS region). The supported data plane relationship is a data plane client-server relationship where the lower layer provides a service for the higher layer using the data links realized in the lower layer.
例えば、何人かの顧客がサービスプロバイダー、何らかのLayer2(例えば、ATM)からLayer-1(すなわち、輸送)サービスを購入します、他のものはLayer-3(IP/MPLS)サービスを購入しますが。 サービスプロバイダーは1つ以上のネットワーク領域の中に位置したネットワーク層のスタックでサービスがわかります。 デバイスのスイッチング能力に応じて、ネットワーク層はネットワークで一般的にアレンジされます。 したがって、マルチGMPLSベースのマルチ領域/層のネットワークの上で顧客ネットワークを提供するかもしれません。 サービス(TDM、そして/または、LSCのネットワーク層、そして/または、FSC領域を通って、実感される)がLayer-2ネットワーク(ATM Virtual Path/仮想のCircuit(VP/VC)を通して、実感される)をサポートするかもしれないa Layer-1、例えば、サポートa Layer-3自身はどれをネットワークでつなぐかもしれないか(IP/MPLS領域)。 サポートしているデータ飛行機関係は下層が下層で実感されたデータ・リンクを使用することで、より高い層のためのサービスを提供するデータ飛行機クライアント/サーバー関係です。
Shiomoto, et al. Informational [Page 7] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [7ページ]情報のRFC5212MRN/百万要件2008年7月
Services provided by a GMPLS-based multi-region/multi-layer network are referred to as "multi-region/multi-layer network services". For example, legacy IP and IP/MPLS networks can be supported on top of multi-region/multi-layer networks. It has to be emphasized that delivery of such diverse services is a strong motivator for the deployment of multi-region/multi-layer networks.
マルチGMPLSベースのマルチ領域/層のネットワークによって提供されたサービスは「マルチマルチ領域/層のネットワーク・サービス」と呼ばれます。 例えば、マルチマルチ領域/層のネットワークの上でレガシーIPとIP/MPLSネットワークをサポートできます。 さまざまにそのようなサービスの配送がマルチマルチ領域/層のネットワークの展開のための強い動機付け要因であると強調されなければなりません。
A customer network may be provided on top of a server GMPLS-based MRN/MLN which is operated by a service provider. For example, a pure IP and/or an IP/MPLS network can be provided on top of GMPLS-based packet-over-optical networks [RFC5146]. The relationship between the networks is a client/server relationship and, such services are referred to as "MRN/MLN services". In this case, the customer network may form part of the MRN/MLN or may be partially separated, for example, to maintain separate routing information but retain common signaling.
サービスプロバイダーによって運用されるサーバの上のGMPLSベースのMRN/MLNを顧客ネットワークに提供するかもしれません。 例えば、GMPLSベースの上にa純粋なIP、そして/または、IP/MPLSネットワークを提供できる、パケット、過剰光学、ネットワーク[RFC5146]。 ネットワークの間の関係はクライアント/サーバ関係です、そして、そのようなサービスは「MRN/MLNサービス」と呼ばれます。 この場合、顧客ネットワークは、MRN/MLNの一部を形成するか、または例えば、別々のルーティング情報を保守しますが、一般的なシグナリングを保有するために部分的に切り離されるかもしれません。
3.3. Vertical and Horizontal Interaction and Integration
3.3. 垂直で水平な相互作用と統合
Vertical interaction is defined as the collaborative mechanisms within a network element that is capable of supporting more than one layer or region and of realizing the client/server relationships between the layers or regions. Protocol exchanges between two network controllers managing different regions or layers are also a vertical interaction. Integration of these interactions as part of the control plane is referred to as vertical integration. Thus, this refers to the collaborative mechanisms within a single control plane instance driving multiple network layers that are part of the same region or not. Such a concept is useful in order to construct a framework that facilitates efficient network resource usage and rapid service provisioning in carrier networks that are based on multiple layers, switching technologies, or ISCs.
垂直相互作用は1つ以上の層か領域を支えて、層か領域の間のクライアント/サーバ関係をわかることができるネットワーク要素の中で協力的なメカニズムと定義されます。 また、異なった領域か層を管理する2人のネットワーク制御装置の間のプロトコル交換は垂直相互作用です。 制御飛行機の一部としてのこれらの相互作用の統合は垂直統合と呼ばれます。 したがって、これは、同じ領域の一部である複数のネットワーク層であるか否かに関係なく、運転しながら、単一管理飛行機インスタンスの中に協力的なメカニズムを示します。 そのような概念は効率的なネットワーク資源用法を容易にするフレームワークとキャリヤーで複数の層に基づいているネットワークに食糧を供給する迅速なサービスを構成するために役に立ちます、技術、またはISCsを切り換えて。
Horizontal interaction is defined as the protocol exchange between network controllers that manage transport nodes within a given layer or region. For instance, the control plane interaction between two TDM network elements switching at OC-48 is an example of horizontal interaction. GMPLS protocol operations handle horizontal interactions within the same routing area. The case where the interaction takes place across a domain boundary, such as between two routing areas within the same network layer, is evaluated as part of the inter-domain work [RFC4726], and is referred to as horizontal integration. Thus, horizontal integration refers to the collaborative mechanisms between network partitions and/or administrative divisions such as routing areas or autonomous systems.
水平な相互作用は与えられた層か領域の中で輸送ノードを管理するネットワーク制御装置の間のプロトコル交換と定義されます。 例えば、OC-48で切り替わる2つのTDMネットワーク要素の間のコントロール飛行機相互作用は水平な相互作用に関する例です。 GMPLSプロトコル操作は同じルーティング領域の中で水平な相互作用を扱います。 相互作用がドメイン境界の向こう側に起こるケースは、同じネットワーク層の中の2つのルーティング領域などのように相互ドメイン仕事[RFC4726]の一部として評価されて、水平的統合と呼ばれます。 したがって、水平的統合はネットワークパーティションの間の協力的なメカニズム、そして/または、ルーティング領域か自律システムなどの管理部門について言及します。
Shiomoto, et al. Informational [Page 8] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [8ページ]情報のRFC5212MRN/百万要件2008年7月
This distinction needs further clarification when administrative domains match layer/region boundaries. Horizontal interaction is extended to cover such cases. For example, the collaborative mechanisms in place between two LSC areas relate to horizontal integration. On the other hand, the collaborative mechanisms in place between a PSC (e.g., IP/MPLS) domain and a separate TDM capable (e.g., VC4 Synchronous Digital Hierarchy (SDH)) domain over which it operates are part of the horizontal integration, while it can also be seen as a first step towards vertical integration.
管理ドメインが層/領域境界に合うと、この区別はさらなる明確化を必要とします。 水平な相互作用は、そのような場合をカバーするために広げられます。 例えば、2つのLSC領域の間に適所にある協力的なメカニズムは水平的統合に関連します。 他方では、PSC(例えば、IP/MPLS)ドメインと別々のTDMできる(例えば、VC4同期デジタルハイアラーキ(SDH))ドメインに間それが作動する適所にある協力的なメカニズムは水平的統合の一部です、また、垂直統合に向かってそれを第一歩と考えることができますが。
3.4. Motivation
3.4. 動機
The applicability of GMPLS to multiple switching technologies provides a unified control and management approach for both LSP provisioning and recovery. Indeed, one of the main motivations for unifying the capabilities and operations of the GMPLS control plane is the desire to support multi-LSP-region [RFC4206] routing and TE capabilities. For instance, this enables effective network resource utilization of both the Packet/Layer2 LSP regions and the TDM or Lambda LSP regions in high-capacity networks.
複数の切り換え技術へのGMPLSの適用性はLSPの食糧を供給するのと回復の両方のための統一されたコントロールとマネージメント・アプローチを提供します。 本当に、能力を統一することに関する主な動機の1つとGMPLS制御飛行機の操作はマルチLSPの領域[RFC4206]ルーティングとTEが能力であるとサポートする願望です。 例えば、これは高容量ネットワークにおける、Packet/Layer2 LSP領域とTDMかLambda LSP領域の両方の有効なネットワーク資源利用を可能にします。
The rationales for GMPLS-controlled multi-layer/multi-region networks are summarized below:
マルチGMPLSによって制御されたマルチ層/領域ネットワークのための原理は以下へまとめられます:
- The maintenance of multiple instances of the control plane on
devices hosting more than one switching capability not only
increases the complexity of the interactions between control plane
instances, but also increases the total amount of processing each
individual control plane instance must handle.
- 1つ以上のスイッチング能力を接待するデバイスにおける制御飛行機の複数のインスタンスのメインテナンスはコントロール飛行機インスタンスの間の相互作用の複雑さを増強するだけではなく、それぞれの個々のコントロール飛行機インスタンスが扱わなければならない処理の総量を増強もします。
- The unification of the addressing spaces helps in avoiding multiple
identifiers for the same object (a link, for instance, or more
generally, any network resource). On the other hand such
aggregation does not impact the separation between the control
plane and the data plane.
- アドレシング空間の統一は、同じオブジェクトのための複数の識別子を避けるのを手伝います(例えば、より一般に、aがリンクされます、どんなネットワーク資源も)。 他方では、そのような集合は制御飛行機とデータ飛行機の間に分離に影響を与えません。
- By maintaining a single routing protocol instance and a single TE
database per LSR, a unified control plane model removes the
requirement to maintain a dedicated routing topology per layer and
therefore does not mandate a full mesh of routing adjacencies as is
the case with overlaid control planes.
- ただ一つのルーティング・プロトコルインスタンスと1LSRあたり1つのただ一つのTEデータベースを維持することによって、統一された規制飛行機モデルは、1層あたり1つのひたむきなルーティングトポロジーを維持するという要件を取り除いて、したがって、かぶせられた制御飛行機に関してそうであるようにルーティング隣接番組の完全なメッシュを強制しません。
- The collaboration between technology layers where the control
channel is associated with the data channel (e.g., packet/framed
data planes) and technology layers where the control channel is not
directly associated with the data channel (SONET/SDH, G.709, etc.)
- 制御チャンネルがデータ・チャンネル(例えば、パケット/縁どられたデータ飛行機)に関連している技術層と制御チャンネルが直接データ・チャンネルに関連づけられない技術層の間との共同(Sonet/SDH、G.709など)
Shiomoto, et al. Informational [Page 9] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [9ページ]情報のRFC5212MRN/百万要件2008年7月
is facilitated by the capability within GMPLS to associate in-band
control plane signaling to the IP terminating interfaces of the
control plane.
制御飛行機のインタフェースを終えるIPにバンドにおけるコントロール飛行機シグナリングを関連づけるGMPLSの中の能力で、容易にされます。
- Resource management and policies to be applied at the edges of such
an MRN/MLN are made more simple (fewer control-to-management
interactions) and more scalable (through the use of aggregated
information).
- そのようなMRN/MLNの縁で適用されるべき資源管理と方針をより簡単(コントロールから管理への、より少ない相互作用)でよりスケーラブルに(集められた情報の使用による)します。
- Multi-region/multi-layer traffic engineering is facilitated as TE
links from distinct regions/layers are stored within the same TE
Database.
- 異なる領域/層からのTEリンクが同じTE Databaseの中に保存されるとき、マルチマルチ領域/層の交通工学は容易にされます。
4. Key Concepts of GMPLS-Based MLNs and MRNs
4. GMPLSベースのMLNsとMRNsに関する重要な考え
A network comprising transport nodes with multiple data plane layers of either the same ISC or different ISCs, controlled by a single GMPLS control plane instance, is called a multi-layer network (MLN). A subset of MLNs consists of networks supporting LSPs of different switching technologies (ISCs). A network supporting more than one switching technology is called a multi-region network (MRN).
ただ一つのGMPLSコントロール飛行機インスタンスによって制御された同じISCか異なったISCsのどちらかの複数のデータ飛行機層で輸送ノードを包括するネットワークはマルチネットワーク(MLN)層と呼ばれます。 MLNsの部分集合は異なった切り換え技術(ISCs)のLSPsをサポートするネットワークから成ります。 1つ以上の切り換え技術をサポートするネットワークはマルチ領域ネットワーク(MRN)と呼ばれます。
4.1. Interface Switching Capability
4.1. Interface Switching Capability
The Interface Switching Capability (ISC) is introduced in GMPLS to support various kinds of switching technology in a unified way [RFC4202]. An ISC is identified via a switching type.
The Interface Switching Capability (ISC) is introduced in GMPLS to support various kinds of switching technology in a unified way [RFC4202]. An ISC is identified via a switching type.
A switching type (also referred to as the switching capability type) describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a network region. The following ISC types (and, hence, regions) are defined: PSC, L2SC, TDM capable, LSC, and FSC. Each end of a data link (more precisely, each interface connecting a data link to a node) in a GMPLS network is associated with an ISC.
A switching type (also referred to as the switching capability type) describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a network region. The following ISC types (and, hence, regions) are defined: PSC, L2SC, TDM capable, LSC, and FSC. Each end of a data link (more precisely, each interface connecting a data link to a node) in a GMPLS network is associated with an ISC.
The ISC value is advertised as a part of the Interface Switching Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end associated with a particular link interface [RFC4202]. Apart from the ISC, the ISCD contains information including the encoding type, the bandwidth granularity, and the unreserved bandwidth on each of eight priorities at which LSPs can be established. The ISCD does not "identify" network layers, it uniquely characterizes information associated to one or more network layers.
The ISC value is advertised as a part of the Interface Switching Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end associated with a particular link interface [RFC4202]. Apart from the ISC, the ISCD contains information including the encoding type, the bandwidth granularity, and the unreserved bandwidth on each of eight priorities at which LSPs can be established. The ISCD does not "identify" network layers, it uniquely characterizes information associated to one or more network layers.
Shiomoto, et al. Informational [Page 10] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 10] RFC 5212 MRN/MLN Requirements July 2008
TE link end advertisements may contain multiple ISCDs. This can be interpreted as advertising a multi-layer (or multi-switching- capable) TE link end. That is, the TE link end (and therefore the TE link) is present in multiple layers.
TE link end advertisements may contain multiple ISCDs. This can be interpreted as advertising a multi-layer (or multi-switching- capable) TE link end. That is, the TE link end (and therefore the TE link) is present in multiple layers.
4.2. Multiple Interface Switching Capabilities
4.2. Multiple Interface Switching Capabilities
In an MLN, network elements may be single-switching-type-capable or multi-switching-type-capable nodes. Single-switching-type-capable nodes advertise the same ISC value as part of their ISCD sub-TLV(s) to describe the termination capabilities of each of their TE link(s). This case is described in [RFC4202].
In an MLN, network elements may be single-switching-type-capable or multi-switching-type-capable nodes. Single-switching-type-capable nodes advertise the same ISC value as part of their ISCD sub-TLV(s) to describe the termination capabilities of each of their TE link(s). This case is described in [RFC4202].
Multi-switching-type-capable LSRs are classified as "simplex" or "hybrid" nodes. Simplex and hybrid nodes are categorized according to the way they advertise these multiple ISCs:
Multi-switching-type-capable LSRs are classified as "simplex" or "hybrid" nodes. Simplex and hybrid nodes are categorized according to the way they advertise these multiple ISCs:
- A simplex node can terminate data links with different switching
capabilities where each data link is connected to the node by a
separate link interface. So, it advertises several TE links each
with a single ISC value carried in its ISCD sub-TLV (following the
rules defined in [RFC4206]). An example is an LSR with PSC and TDM
links each of which is connected to the LSR via a separate
interface.
- A simplex node can terminate data links with different switching capabilities where each data link is connected to the node by a separate link interface. So, it advertises several TE links each with a single ISC value carried in its ISCD sub-TLV (following the rules defined in [RFC4206]). An example is an LSR with PSC and TDM links each of which is connected to the LSR via a separate interface.
- A hybrid node can terminate data links with different switching
capabilities where the data links are connected to the node by the
same interface. So, it advertises a single TE link containing more
than one ISCD each with a different ISC value. For example, a node
may terminate PSC and TDM data links and interconnect those
external data links via internal links. The external interfaces
connected to the node have both PSC and TDM capabilities.
- A hybrid node can terminate data links with different switching capabilities where the data links are connected to the node by the same interface. So, it advertises a single TE link containing more than one ISCD each with a different ISC value. For example, a node may terminate PSC and TDM data links and interconnect those external data links via internal links. The external interfaces connected to the node have both PSC and TDM capabilities.
Additionally, TE link advertisements issued by a simplex or a hybrid node may need to provide information about the node's internal adjustment capabilities between the switching technologies supported. The term "adjustment" refers to the property of a hybrid node to interconnect the different switching capabilities that it provides through its external interfaces. The information about the adjustment capabilities of the nodes in the network allows the path computation process to select an end-to-end multi-layer or multi- region path that includes links with different switching capabilities joined by LSRs that can adapt (i.e., adjust) the signal between the links.
Additionally, TE link advertisements issued by a simplex or a hybrid node may need to provide information about the node's internal adjustment capabilities between the switching technologies supported. The term "adjustment" refers to the property of a hybrid node to interconnect the different switching capabilities that it provides through its external interfaces. The information about the adjustment capabilities of the nodes in the network allows the path computation process to select an end-to-end multi-layer or multi- region path that includes links with different switching capabilities joined by LSRs that can adapt (i.e., adjust) the signal between the links.
Shiomoto, et al. Informational [Page 11] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 11] RFC 5212 MRN/MLN Requirements July 2008
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes
This type of network contains at least one hybrid node, zero or more simplex nodes, and a set of single-switching-type-capable nodes.
This type of network contains at least one hybrid node, zero or more simplex nodes, and a set of single-switching-type-capable nodes.
Figure 1 shows an example hybrid node. The hybrid node has two switching elements (matrices), which support, for instance, TDM and PSC switching, respectively. The node terminates a PSC and a TDM link (Link1 and Link2, respectively). It also has an internal link connecting the two switching elements.
Figure 1 shows an example hybrid node. The hybrid node has two switching elements (matrices), which support, for instance, TDM and PSC switching, respectively. The node terminates a PSC and a TDM link (Link1 and Link2, respectively). It also has an internal link connecting the two switching elements.
The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of, say, Link2 and provide adjustment for PSC traffic received/sent over the PSC interface (#b). This situation is modeled in GMPLS by connecting the local end of Link2 to the TDM switching element via an additional interface realizing the termination/adjustment function. There are two possible ways to set up PSC LSPs through the hybrid node. Available resource advertisement (i.e., Unreserved and Min/Max LSP Bandwidth) should cover both of these methods.
The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of, say, Link2 and provide adjustment for PSC traffic received/sent over the PSC interface (#b). This situation is modeled in GMPLS by connecting the local end of Link2 to the TDM switching element via an additional interface realizing the termination/adjustment function. There are two possible ways to set up PSC LSPs through the hybrid node. Available resource advertisement (i.e., Unreserved and Min/Max LSP Bandwidth) should cover both of these methods.
.............................
: Network element :
: -------- :
: | PSC | :
Link1 -------------<->--|#a | :
: | | :
: +--<->---|#b | :
: | -------- :
: | ---------- :
TDM : +--<->--|#c TDM | :
+PSC : | | :
Link2 ------------<->--|#d | :
: ---------- :
:............................
............................. : Network element : : -------- : : | PSC | : Link1 -------------<->--|#a | : : | | : : +--<->---|#b | : : | -------- : : | ---------- : TDM : +--<->--|#c TDM | : +PSC : | | : Link2 ------------<->--|#d | : : ---------- : :............................
Figure 1. Hybrid node.
Figure 1. Hybrid node.
4.3. Integrated Traffic Engineering (TE) and Resource Control
4.3. Integrated Traffic Engineering (TE) and Resource Control
In GMPLS-based multi-region/multi-layer networks, TE links may be consolidated into a single Traffic Engineering Database (TED) for use by the single control plane instance. Since this TED contains the information relative to all the layers of all regions in the network, a path across multiple layers (possibly crossing multiple regions) can be computed using the information in this TED. Thus, optimization of network resources across the multiple layers of the same region and across multiple regions can be achieved.
In GMPLS-based multi-region/multi-layer networks, TE links may be consolidated into a single Traffic Engineering Database (TED) for use by the single control plane instance. Since this TED contains the information relative to all the layers of all regions in the network, a path across multiple layers (possibly crossing multiple regions) can be computed using the information in this TED. Thus, optimization of network resources across the multiple layers of the same region and across multiple regions can be achieved.
Shiomoto, et al. Informational [Page 12] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 12] RFC 5212 MRN/MLN Requirements July 2008
These concepts allow for the operation of one network layer over the topology (that is, TE links) provided by other network layers (for example, the use of a lower-layer LSC LSP carrying PSC LSPs). In turn, a greater degree of control and interworking can be achieved, including (but not limited to):
These concepts allow for the operation of one network layer over the topology (that is, TE links) provided by other network layers (for example, the use of a lower-layer LSC LSP carrying PSC LSPs). In turn, a greater degree of control and interworking can be achieved, including (but not limited to):
- Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206]
(see Sections 4.3.2 and 4.3.3).
- Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206] (see Sections 4.3.2 and 4.3.3).
- Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs.
- Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs.
Note that in a multi-layer/multi-region network that includes multi- switching-type-capable nodes, an explicit route used to establish an end-to-end LSP can specify nodes that belong to different layers or regions. In this case, a mechanism to control the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 and 4.3.3).
Note that in a multi-layer/multi-region network that includes multi- switching-type-capable nodes, an explicit route used to establish an end-to-end LSP can specify nodes that belong to different layers or regions. In this case, a mechanism to control the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 and 4.3.3).
There is a full spectrum of options to control how FA-LSPs are dynamically established. The process can be subject to the control of a policy, which may be set by a management component and which may require that the management plane is consulted at the time that the FA-LSP is established. Alternatively, the FA-LSP can be established at the request of the control plane without any management control.
There is a full spectrum of options to control how FA-LSPs are dynamically established. The process can be subject to the control of a policy, which may be set by a management component and which may require that the management plane is consulted at the time that the FA-LSP is established. Alternatively, the FA-LSP can be established at the request of the control plane without any management control.
4.3.1. Triggered Signaling
4.3.1. Triggered Signaling
When an LSP crosses the boundary from an upper to a lower layer, it may be nested into a lower-layer FA-LSP that crosses the lower layer. From a signaling perspective, there are two alternatives to establish the lower-layer FA-LSP: static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may be initiated either by the operator or automatically using features like TE auto-mesh [RFC4972]. If such a lower-layer LSP does not already exist, the LSP may be established dynamically. Such a mechanism is referred to as "triggered signaling".
When an LSP crosses the boundary from an upper to a lower layer, it may be nested into a lower-layer FA-LSP that crosses the lower layer. From a signaling perspective, there are two alternatives to establish the lower-layer FA-LSP: static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may be initiated either by the operator or automatically using features like TE auto-mesh [RFC4972]. If such a lower-layer LSP does not already exist, the LSP may be established dynamically. Such a mechanism is referred to as "triggered signaling".
4.3.2. FA-LSPs
4.3.2. FA-LSPs
Once an LSP is created across a layer from one layer border node to another, it can be used as a data link in an upper layer.
Once an LSP is created across a layer from one layer border node to another, it can be used as a data link in an upper layer.
Furthermore, it can be advertised as a TE link, allowing other nodes to consider the LSP as a TE link for their path computation [RFC4206]. An LSP created either statically or dynamically by one instance of the control plane and advertised as a TE link into the same instance of the control plane is called a Forwarding Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link is called a Forwarding Adjacency (FA). An FA has the special
Furthermore, it can be advertised as a TE link, allowing other nodes to consider the LSP as a TE link for their path computation [RFC4206]. An LSP created either statically or dynamically by one instance of the control plane and advertised as a TE link into the same instance of the control plane is called a Forwarding Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link is called a Forwarding Adjacency (FA). An FA has the special
Shiomoto, et al. Informational [Page 13] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 13] RFC 5212 MRN/MLN Requirements July 2008
characteristic of not requiring a routing adjacency (peering) between its end points yet still guaranteeing control plane connectivity between the FA-LSP end points based on a signaling adjacency. An FA is a useful and powerful tool for improving the scalability of GMPLS-TE capable networks since multiple higher-layer LSPs may be nested (aggregated) over a single FA-LSP.
characteristic of not requiring a routing adjacency (peering) between its end points yet still guaranteeing control plane connectivity between the FA-LSP end points based on a signaling adjacency. An FA is a useful and powerful tool for improving the scalability of GMPLS-TE capable networks since multiple higher-layer LSPs may be nested (aggregated) over a single FA-LSP.
The aggregation of LSPs enables the creation of a vertical (nested) LSP hierarchy. A set of FA-LSPs across or within a lower layer can be used during path selection by a higher-layer LSP. Likewise, the higher-layer LSPs may be carried over dynamic data links realized via LSPs (just as they are carried over any "regular" static data links). This process requires the nesting of LSPs through a hierarchical process [RFC4206]. The TED contains a set of LSP advertisements from different layers that are identified by the ISCD contained within the TE link advertisement associated with the LSP [RFC4202].
The aggregation of LSPs enables the creation of a vertical (nested) LSP hierarchy. A set of FA-LSPs across or within a lower layer can be used during path selection by a higher-layer LSP. Likewise, the higher-layer LSPs may be carried over dynamic data links realized via LSPs (just as they are carried over any "regular" static data links). This process requires the nesting of LSPs through a hierarchical process [RFC4206]. The TED contains a set of LSP advertisements from different layers that are identified by the ISCD contained within the TE link advertisement associated with the LSP [RFC4202].
If a lower-layer LSP is not advertised as an FA, it can still be used to carry higher-layer LSPs across the lower layer. For example, if the LSP is set up using triggered signaling, it will be used to carry the higher-layer LSP that caused the trigger. Further, the lower layer remains available for use by other higher-layer LSPs arriving at the boundary.
If a lower-layer LSP is not advertised as an FA, it can still be used to carry higher-layer LSPs across the lower layer. For example, if the LSP is set up using triggered signaling, it will be used to carry the higher-layer LSP that caused the trigger. Further, the lower layer remains available for use by other higher-layer LSPs arriving at the boundary.
Under some circumstances, it may be useful to control the advertisement of LSPs as FAs during the signaling establishment of the LSPs [DYN-HIER].
Under some circumstances, it may be useful to control the advertisement of LSPs as FAs during the signaling establishment of the LSPs [DYN-HIER].
4.3.3. Virtual Network Topology (VNT)
4.3.3. Virtual Network Topology (VNT)
A set of one or more lower-layer LSPs provides information for efficient path handling in upper layer(s) of the MLN, or, in other words, provides a virtual network topology (VNT) to the upper layers. For instance, a set of LSPs, each of which is supported by an LSC LSP, provides a VNT to the layers of a PSC region, assuming that the PSC region is connected to the LSC region. Note that a single lower-layer LSP is a special case of the VNT. The VNT is configured by setting up or tearing down the lower-layer LSPs. By using GMPLS signaling and routing protocols, the VNT can be adapted to traffic demands.
A set of one or more lower-layer LSPs provides information for efficient path handling in upper layer(s) of the MLN, or, in other words, provides a virtual network topology (VNT) to the upper layers. For instance, a set of LSPs, each of which is supported by an LSC LSP, provides a VNT to the layers of a PSC region, assuming that the PSC region is connected to the LSC region. Note that a single lower-layer LSP is a special case of the VNT. The VNT is configured by setting up or tearing down the lower-layer LSPs. By using GMPLS signaling and routing protocols, the VNT can be adapted to traffic demands.
A lower-layer LSP appears as a TE link in the VNT. Whether the diversely-routed lower-layer LSPs are used or not, the routes of lower-layer LSPs are hidden from the upper layer in the VNT. Thus, the VNT simplifies the upper-layer routing and traffic engineering decisions by hiding the routes taken by the lower-layer LSPs. However, hiding the routes of the lower-layer LSPs may lose important information that is needed to make the higher-layer LSPs reliable.
A lower-layer LSP appears as a TE link in the VNT. Whether the diversely-routed lower-layer LSPs are used or not, the routes of lower-layer LSPs are hidden from the upper layer in the VNT. Thus, the VNT simplifies the upper-layer routing and traffic engineering decisions by hiding the routes taken by the lower-layer LSPs. However, hiding the routes of the lower-layer LSPs may lose important information that is needed to make the higher-layer LSPs reliable.
Shiomoto, et al. Informational [Page 14] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 14] RFC 5212 MRN/MLN Requirements July 2008
For instance, the routing and traffic engineering in the IP/MPLS layer does not usually consider how the IP/MPLS TE links are formed from optical paths that are routed in the fiber layer. Two optical paths may share the same fiber link in the lower-layer and therefore they may both fail if the fiber link is cut. Thus the shared risk properties of the TE links in the VNT must be made available to the higher layer during path computation. Further, the topology of the VNT should be designed so that any single fiber cut does not bisect the VNT. These issues are addressed later in this document.
For instance, the routing and traffic engineering in the IP/MPLS layer does not usually consider how the IP/MPLS TE links are formed from optical paths that are routed in the fiber layer. Two optical paths may share the same fiber link in the lower-layer and therefore they may both fail if the fiber link is cut. Thus the shared risk properties of the TE links in the VNT must be made available to the higher layer during path computation. Further, the topology of the VNT should be designed so that any single fiber cut does not bisect the VNT. These issues are addressed later in this document.
Reconfiguration of the VNT may be triggered by traffic demand changes, topology configuration changes, signaling requests from the upper layer, and network failures. For instance, by reconfiguring the VNT according to the traffic demand between source and destination node pairs, network performance factors, such as maximum link utilization and residual capacity of the network, can be optimized. Reconfiguration is performed by computing the new VNT from the traffic demand matrix and optionally from the current VNT. Exact details are outside the scope of this document. However, this method may be tailored according to the service provider's policy regarding network performance and quality of service (delay, loss/disruption, utilization, residual capacity, reliability).
Reconfiguration of the VNT may be triggered by traffic demand changes, topology configuration changes, signaling requests from the upper layer, and network failures. For instance, by reconfiguring the VNT according to the traffic demand between source and destination node pairs, network performance factors, such as maximum link utilization and residual capacity of the network, can be optimized. Reconfiguration is performed by computing the new VNT from the traffic demand matrix and optionally from the current VNT. Exact details are outside the scope of this document. However, this method may be tailored according to the service provider's policy regarding network performance and quality of service (delay, loss/disruption, utilization, residual capacity, reliability).
5. Requirements
5. Requirements
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes
The MRN/MLN can consist of single-switching-type-capable and multi- switching-type-capable nodes. The path computation mechanism in the MLN should be able to compute paths consisting of any combination of such nodes.
The MRN/MLN can consist of single-switching-type-capable and multi- switching-type-capable nodes. The path computation mechanism in the MLN should be able to compute paths consisting of any combination of such nodes.
Both single-switching-type-capable and multi-switching-type-capable (simplex or hybrid) nodes could play the role of layer boundary. MRN/MLN path computation should handle TE topologies built of any combination of nodes.
Both single-switching-type-capable and multi-switching-type-capable (simplex or hybrid) nodes could play the role of layer boundary. MRN/MLN path computation should handle TE topologies built of any combination of nodes.
5.2. Advertisement of the Available Adjustment Resources
5.2. Advertisement of the Available Adjustment Resources
A hybrid node should maintain resources on its internal links (the links required for vertical integration between layers). Likewise, path computation elements should be prepared to use information about the availability of termination and adjustment resources as a constraint in MRN/MLN path computations. This would reduce the probability that the setup of the higher-layer LSP will be blocked by the lack of necessary termination/adjustment resources in the lower layers.
A hybrid node should maintain resources on its internal links (the links required for vertical integration between layers). Likewise, path computation elements should be prepared to use information about the availability of termination and adjustment resources as a constraint in MRN/MLN path computations. This would reduce the probability that the setup of the higher-layer LSP will be blocked by the lack of necessary termination/adjustment resources in the lower layers.
Shiomoto, et al. Informational [Page 15] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 15] RFC 5212 MRN/MLN Requirements July 2008
The advertisement of a node's MRN adjustment capabilities (the ability to terminate LSPs of lower regions and forward the traffic in upper regions) is REQUIRED, as it provides critical information when performing multi-region path computation.
The advertisement of a node's MRN adjustment capabilities (the ability to terminate LSPs of lower regions and forward the traffic in upper regions) is REQUIRED, as it provides critical information when performing multi-region path computation.
The path computation mechanism should cover the case where the upper-layer links that are directly connected to upper-layer switching elements and the ones that are connected through internal links between upper-layer element and lower-layer element coexist (see Section 4.2.1).
The path computation mechanism should cover the case where the upper-layer links that are directly connected to upper-layer switching elements and the ones that are connected through internal links between upper-layer element and lower-layer element coexist (see Section 4.2.1).
5.3. Scalability
5.3. Scalability
The MRN/MLN relies on unified routing and traffic engineering models.
The MRN/MLN relies on unified routing and traffic engineering models.
- Unified routing model: By maintaining a single routing protocol
instance and a single TE database per LSR, a unified control plane
model removes the requirement to maintain a dedicated routing
topology per layer, and therefore does not mandate a full mesh of
routing adjacencies per layer.
- Unified routing model: By maintaining a single routing protocol instance and a single TE database per LSR, a unified control plane model removes the requirement to maintain a dedicated routing topology per layer, and therefore does not mandate a full mesh of routing adjacencies per layer.
- Unified TE model: The TED in each LSR is populated with TE links
from all layers of all regions (TE link interfaces on multiple-
switching-type-capable LSRs can be advertised with multiple ISCDs).
This may lead to an increase in the amount of information that has
to be flooded and stored within the network.
- Unified TE model: The TED in each LSR is populated with TE links from all layers of all regions (TE link interfaces on multiple- switching-type-capable LSRs can be advertised with multiple ISCDs). This may lead to an increase in the amount of information that has to be flooded and stored within the network.
Furthermore, path computation times, which may be of great importance during restoration, will depend on the size of the TED.
Furthermore, path computation times, which may be of great importance during restoration, will depend on the size of the TED.
Thus, MRN/MLN routing mechanisms MUST be designed to scale well with an increase of any of the following:
Thus, 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.
- Number of nodes - Number of TE links (including FA-LSPs) - Number of LSPs - Number of regions and layers - Number of ISCDs per TE link.
Further, design of the routing protocols MUST NOT prevent TE information filtering based on ISCDs. The path computation mechanism and the signaling protocol SHOULD be able to operate on partial TE information.
Further, design of the routing protocols MUST NOT prevent TE information filtering based on ISCDs. The path computation mechanism and the signaling protocol SHOULD be able to operate on partial TE information.
Since TE links can advertise multiple Interface Switching Capabilities (ISCs), the number of links can be limited (by combination) by using specific topological maps referred to as VNTs
Since TE links can advertise multiple Interface Switching Capabilities (ISCs), the number of links can be limited (by combination) by using specific topological maps referred to as VNTs
Shiomoto, et al. Informational [Page 16] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 16] RFC 5212 MRN/MLN Requirements July 2008
(Virtual Network Topologies). The introduction of virtual topological maps leads us to consider the concept of emulation of data plane overlays.
(Virtual Network Topologies). The introduction of virtual topological maps leads us to consider the concept of emulation of data plane overlays.
5.4. Stability
5.4. Stability
Path computation is dependent on the network topology and associated link state. The path computation stability of an upper layer may be impaired if the VNT changes frequently and/or if the status and TE parameters (the TE metric, for instance) of links in the VNT changes frequently. In this context, robustness of the VNT is defined as the capability to smooth changes that may occur and avoid their propagation into higher layers. Changes to the VNT may be caused by the creation, deletion, or modification of LSPs.
Path computation is dependent on the network topology and associated link state. The path computation stability of an upper layer may be impaired if the VNT changes frequently and/or if the status and TE parameters (the TE metric, for instance) of links in the VNT changes frequently. In this context, robustness of the VNT is defined as the capability to smooth changes that may occur and avoid their propagation into higher layers. Changes to the VNT may be caused by the creation, deletion, or modification of LSPs.
Protocol mechanisms MUST be provided to enable creation, deletion, and modification of LSPs triggered through operational actions. Protocol mechanisms SHOULD be provided to enable similar functions triggered by adjacent layers. Protocol mechanisms MAY be provided to enable similar functions to adapt to the environment changes such as traffic demand changes, topology changes, and network failures. Routing robustness should be traded with adaptability of those changes.
Protocol mechanisms MUST be provided to enable creation, deletion, and modification of LSPs triggered through operational actions. Protocol mechanisms SHOULD be provided to enable similar functions triggered by adjacent layers. Protocol mechanisms MAY be provided to enable similar functions to adapt to the environment changes such as traffic demand changes, topology changes, and network failures. Routing robustness should be traded with adaptability of those changes.
5.5. Disruption Minimization
5.5. Disruption Minimization
When reconfiguring the VNT according to a change in traffic demand, the upper-layer LSP might be disrupted. Such disruption to the upper layers must be minimized.
When reconfiguring the VNT according to a change in traffic demand, the upper-layer LSP might be disrupted. Such disruption to the upper layers must be minimized.
When residual resource decreases to a certain level, some lower-layer LSPs may be released according to local or network policies. There is a trade-off between minimizing the amount of resource reserved in the lower layer and disrupting higher-layer traffic (i.e., moving the traffic to other TE-LSPs so that some LSPs can be released). Such traffic disruption may be allowed, but MUST be under the control of policy that can be configured by the operator. Any repositioning of traffic MUST be as non-disruptive as possible (for example, using make-before-break).
When residual resource decreases to a certain level, some lower-layer LSPs may be released according to local or network policies. There is a trade-off between minimizing the amount of resource reserved in the lower layer and disrupting higher-layer traffic (i.e., moving the traffic to other TE-LSPs so that some LSPs can be released). Such traffic disruption may be allowed, but MUST be under the control of policy that can be configured by the operator. Any repositioning of traffic MUST be as non-disruptive as possible (for example, using make-before-break).
5.6. LSP Attribute Inheritance
5.6. LSP Attribute Inheritance
TE link parameters should be inherited from the parameters of the LSP that provides the TE link, and so from the TE links in the lower layer that are traversed by the LSP.
TE link parameters should be inherited from the parameters of the LSP that provides the TE link, and so from the TE links in the lower layer that are traversed by the LSP.
Shiomoto, et al. Informational [Page 17] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 17] RFC 5212 MRN/MLN Requirements July 2008
These include:
These include:
- Interface Switching Capability
- TE metric
- Maximum LSP bandwidth per priority level
- Unreserved bandwidth for all priority levels
- Maximum reservable bandwidth
- Protection attribute
- Minimum LSP bandwidth (depending on the switching capability)
- SRLG
- Interface Switching Capability - TE metric - Maximum LSP bandwidth per priority level - Unreserved bandwidth for all priority levels - Maximum reservable bandwidth - Protection attribute - Minimum LSP bandwidth (depending on the switching capability) - SRLG
Inheritance rules must be applied based on specific policies. Particular attention should be given to the inheritance of the TE metric (which may be other than a strict sum of the metrics of the component TE links at the lower layer), protection attributes, and SRLG.
Inheritance rules must be applied based on specific policies. Particular attention should be given to the inheritance of the TE metric (which may be other than a strict sum of the metrics of the component TE links at the lower layer), protection attributes, and SRLG.
As described earlier, hiding the routes of the lower-layer LSPs may lose important information necessary to make LSPs in the higher-layer network reliable. SRLGs may be used to identify which lower-layer LSPs share the same failure risk so that the potential risk of the VNT becoming disjoint can be minimized, and so that resource-disjoint protection paths can be set up in the higher layer. How to inherit the SRLG information from the lower layer to the upper layer needs more discussion and is out of scope of this document.
As described earlier, hiding the routes of the lower-layer LSPs may lose important information necessary to make LSPs in the higher-layer network reliable. SRLGs may be used to identify which lower-layer LSPs share the same failure risk so that the potential risk of the VNT becoming disjoint can be minimized, and so that resource-disjoint protection paths can be set up in the higher layer. How to inherit the SRLG information from the lower layer to the upper layer needs more discussion and is out of scope of this document.
5.7. Computing Paths with and without Nested Signaling
5.7. Computing Paths with and without Nested Signaling
Path computation can take into account LSP region and layer boundaries when computing a path for an LSP. Path computation may restrict the path taken by an LSP to only the links whose interface switching capability is PSC. For example, suppose that a TDM-LSP is routed over the topology composed of TE links of the same TDM layer. In calculating the path for the LSP, the TED may be filtered to include only links where both end include requested LSP switching type. In this way hierarchical routing is done by using a TED filtered with respect to switching capability (that is, with respect to particular layer).
Path computation can take into account LSP region and layer boundaries when computing a path for an LSP. Path computation may restrict the path taken by an LSP to only the links whose interface switching capability is PSC. For example, suppose that a TDM-LSP is routed over the topology composed of TE links of the same TDM layer. In calculating the path for the LSP, the TED may be filtered to include only links where both end include requested LSP switching type. In this way hierarchical routing is done by using a TED filtered with respect to switching capability (that is, with respect to particular layer).
If triggered signaling is allowed, the path computation mechanism may produce a route containing multiple layers/regions. The path is computed over the multiple layers/regions even if the path is not "connected" in the same layer as where the endpoints of the path exist. Note that here we assume that triggered signaling will be invoked to make the path "connected", when the upper-layer signaling request arrives at the boundary node.
If triggered signaling is allowed, the path computation mechanism may produce a route containing multiple layers/regions. The path is computed over the multiple layers/regions even if the path is not "connected" in the same layer as where the endpoints of the path exist. Note that here we assume that triggered signaling will be invoked to make the path "connected", when the upper-layer signaling request arrives at the boundary node.
Shiomoto, et al. Informational [Page 18] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 18] RFC 5212 MRN/MLN Requirements July 2008
The upper-layer signaling request MAY contain an ERO (Explicit Route Object) that includes only hops in the upper layer; in which case, the boundary node is responsible for triggered creation of the lower-layer FA-LSP using a path of its choice, or for the selection of any available lower-layer LSP as a data link for the higher layer. This mechanism is appropriate for environments where the TED is filtered in the higher layer, where separate routing instances are used per layer, or where administrative policies prevent the higher layer from specifying paths through the lower layer.
The upper-layer signaling request MAY contain an ERO (Explicit Route Object) that includes only hops in the upper layer; in which case, the boundary node is responsible for triggered creation of the lower-layer FA-LSP using a path of its choice, or for the selection of any available lower-layer LSP as a data link for the higher layer. This mechanism is appropriate for environments where the TED is filtered in the higher layer, where separate routing instances are used per layer, or where administrative policies prevent the higher layer from specifying paths through the lower layer.
Obviously, if the lower-layer LSP has been advertised as a TE link (virtual or real) into the higher layer, then the higher-layer signaling request MAY contain the TE link identifier and so indicate the lower-layer resources to be used. But in this case, the path of the lower-layer LSP can be dynamically changed by the lower layer at any time.
Obviously, if the lower-layer LSP has been advertised as a TE link (virtual or real) into the higher layer, then the higher-layer signaling request MAY contain the TE link identifier and so indicate the lower-layer resources to be used. But in this case, the path of the lower-layer LSP can be dynamically changed by the lower layer at any time.
Alternatively, the upper-layer signaling request MAY contain an ERO specifying the lower-layer FA-LSP route. In this case, the boundary node MAY decide whether it should use the path contained in the strict ERO or re-compute the path within the lower layer.
Alternatively, the upper-layer signaling request MAY contain an ERO specifying the lower-layer FA-LSP route. In this case, the boundary node MAY decide whether it should use the path contained in the strict ERO or re-compute the path within the lower layer.
Even in the case that the lower-layer FA-LSPs are already established, a signaling request may also be encoded as a loose ERO. In this situation, it is up to the boundary node to decide whether it should create a new lower-layer FA-LSP or it should use an existing lower-layer FA-LSP.
Even in the case that the lower-layer FA-LSPs are already established, a signaling request may also be encoded as a loose ERO. In this situation, it is up to the boundary node to decide whether it should create a new lower-layer FA-LSP or it should use an existing lower-layer FA-LSP.
The lower-layer FA-LSP can be advertised just as an FA-LSP in the upper layer or an IGP adjacency can be brought up on the lower-layer FA-LSP.
The lower-layer FA-LSP can be advertised just as an FA-LSP in the upper layer or an IGP adjacency can be brought up on the lower-layer FA-LSP.
5.8. LSP Resource Utilization
5.8. LSP Resource Utilization
Resource usage in all layers should be optimized as a whole (i.e., across all layers), in a coordinated manner (i.e., taking all layers into account). The number of lower-layer LSPs carrying upper-layer LSPs should be minimized (note that multiple LSPs may be used for load balancing). Lower-layer LSPs that could have their traffic re-routed onto other LSPs are unnecessary and should be avoided.
Resource usage in all layers should be optimized as a whole (i.e., across all layers), in a coordinated manner (i.e., taking all layers into account). The number of lower-layer LSPs carrying upper-layer LSPs should be minimized (note that multiple LSPs may be used for load balancing). Lower-layer LSPs that could have their traffic re-routed onto other LSPs are unnecessary and should be avoided.
5.8.1. FA-LSP Release and Setup
5.8.1. FA-LSP Release and Setup
If there is low traffic demand, some FA-LSPs that do not carry any higher-layer LSP may be released so that lower-layer resources are released and can be assigned to other uses. Note that if a small fraction of the available bandwidth of an FA-LSP is still in use, the nested LSPs can also be re-routed to other FA-LSPs (optionally using
If there is low traffic demand, some FA-LSPs that do not carry any higher-layer LSP may be released so that lower-layer resources are released and can be assigned to other uses. Note that if a small fraction of the available bandwidth of an FA-LSP is still in use, the nested LSPs can also be re-routed to other FA-LSPs (optionally using
Shiomoto, et al. Informational [Page 19] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto, et al. Informational [Page 19] RFC 5212 MRN/MLN Requirements July 2008
the make-before-break technique) to completely free up the FA-LSP. Alternatively, unused FA-LSPs may be retained for future use. Release or retention of underutilized FA-LSPs is a policy decision.
以前開閉しているテクニック) FA-LSPを完全に開けるために。 あるいはまた、未使用のFA-LSPsは今後の使用のために保有されるかもしれません。 underutilized FA-LSPsのリリースか保有が政策決定です。
As part of the re-optimization process, the solution MUST allow rerouting of an FA-LSP while keeping interface identifiers of corresponding TE links unchanged. Further, this process MUST be possible while the FA-LSP is carrying traffic (higher-layer LSPs) with minimal disruption to the traffic.
再最適化の過程の一部として、解決策で、対応するTEリンクに関するインタフェース識別子を変わりがなく保っている間、FA-LSPのコースを変更しなければなりません。 さらに、FA-LSPが交通の最小量の分裂による交通(より高い層のLSPs)を運ぶ間、この過程は可能でなければなりません。
Additional FA-LSPs may also be created based on policy, which might consider residual resources and the change of traffic demand across the region. By creating the new FA-LSPs, the network performance such as maximum residual capacity may increase.
また、追加FA-LSPsは方針に基づいて作成されるかもしれません。方針は領域の向こう側に残りのリソースと交通需要の変化を考えるかもしれません。 新しいFA-LSPsを作成することによって、最大の残りの容量などのネットワーク性能は増えるかもしれません。
As the number of FA-LSPs grows, the residual resources may decrease. In this case, re-optimization of FA-LSPs may be invoked according to policy.
FA-LSPsの数が成長するのに従って、残りのリソースは減少するかもしれません。 この場合、方針によると、FA-LSPsの再最適化は呼び出されるかもしれません。
Any solution MUST include measures to protect against network destabilization caused by the rapid setup and teardown of LSPs as traffic demand varies near a threshold.
どんな解決策も交通需要が敷居の近くで異なるのでLSPsの急速なセットアップと分解によって引き起こされたネットワーク不安定化から守る測定を含まなければなりません。
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly advertise the LSP as a TE link and to coordinate into which routing instances the TE link should be advertised.
下層LSPs SHOULDのシグナリングはTEリンクとして急速にLSPの広告を出すためにメカニズムを含んでいます、そして、どのルーティング例にTEリンクを調整するかの広告を出すべきです。
5.8.2. Virtual TE Links
5.8.2. 仮想のTeリンク
It may be considered disadvantageous to fully instantiate (i.e., pre-provision) the set of lower-layer LSPs that provide the VNT since this might reserve bandwidth that could be used for other LSPs in the absence of upper-layer traffic.
それはこれが上側の層の交通がないとき他のLSPsに使用できた帯域幅を控えるかもしれないのでVNTを提供する下層LSPsのセットを完全に例示する(すなわち、プレ支給)ために不利であると考えられるかもしれません。
However, in order to allow path computation of upper-layer LSPs across the lower layer, the lower-layer LSPs may be advertised into the upper layer as though they had been fully established, but without actually establishing them. Such TE links that represent the possibility of an underlying LSP are termed "virtual TE links". It is an implementation choice at a layer boundary node whether to create real or virtual TE links, and the choice (if available in an implementation) MUST be under the control of operator policy. Note that there is no requirement to support the creation of virtual TE links, since real TE links (with established LSPs) may be used. Even if there are no TE links (virtual or real) advertised to the higher layer, it is possible to route a higher-layer LSP into a lower layer on the assumption that proper hierarchical LSPs in the lower layer will be dynamically created (triggered) as needed.
しかしながら、実際に彼らを設立しないで、下層LSPsは、下層の向こう側に上側の層のLSPsの経路計算を許すためにまるで彼らが完全に設立されたかのように上側の層の中に広告を出しますが、広告を出すかもしれません。 基本的なLSPの可能性を表すそのようなTEリンクが「仮想のTEリンク」と呼ばれます。 本当の、または、仮想のTEを作成するのがリンクされるか否かに関係なく、それは層の境界ノードでの実現選択です、そして、選択(実現で利用可能であるなら)がオペレータ方針のコントロールの下にあるに違いありません。 仮想のTEリンクの創造を支持するという要件が全くないことに注意してください、本当のTEリンク(確立したLSPsと)が使用されるかもしれないので。 より高い層に広告に掲載されたTEリンク(仮想の、または、本当の)が全くなくても、LSPの、より高い層を下層に下層における適切な階層的なLSPsが必要に応じてダイナミックに作成されるという(引き起こされます)前提で発送するのは可能です。
Shiomoto, et al. Informational [Page 20] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [20ページ]情報のRFC5212MRN/百万要件2008年7月
If an upper-layer LSP that makes use of a virtual TE link is set up, the underlying LSP MUST be immediately signaled in the lower layer.
仮想のTEリンクを利用するLSPの上側の層がセットアップされるなら、下層で合図されて、基本的なLSP MUSTはすぐに、セットアップされます。
If virtual TE links are used in place of pre-established LSPs, the TE links across the upper layer can remain stable using pre-computed paths while wastage of bandwidth within the lower layer and unnecessary reservation of adaptation resources at the border nodes can be avoided.
仮想のTEリンクがプレ確立したLSPsに代わって使用されるなら、上側の層の向こう側のTEリンクは、境界ノードの適合リソースの下層と不要な予約の中の帯域幅の消耗を避けることができる間、あらかじめ計算された経路を使用することで安定した状態を保つことができます。
The solution SHOULD provide operations to facilitate the build-up of such virtual TE links, taking into account the (forecast) traffic demand and available resources in the lower layer.
解決策SHOULDはそのような仮想のTEリンクの強化を容易にするために操作を提供します、下層における(予測)交通需要と利用可能資源を考慮に入れて。
Virtual TE links can be added, removed, or modified dynamically (by changing their capacity) according to the change of the (forecast) traffic demand and the available resources in the lower layer. It MUST be possible to add, remove, and modify virtual TE links in a dynamic way.
(予測)交通需要の変化と下層における利用可能資源によると、ダイナミック(それらの容量を変えることによって)に仮想のTEリンクを加えるか、取り外されるか、または変更できます。 ダイナミックな方法で仮想のTEリンクを加えて、取り外して、変更するのは可能であるに違いありません。
Any solution MUST include measures to protect against network destabilization caused by the rapid changes in the VNT as traffic demand varies near a threshold.
どんな解決策も交通需要が敷居の近くで異なるのでVNTにおける急激な変化によって引き起こされたネットワーク不安定化から守る測定を含まなければなりません。
The concept of the VNT can be extended to allow the virtual TE links to form part of the VNT. The combination of the fully provisioned TE links and the virtual TE links defines the VNT provided by the lower layer. The VNT can be changed by setting up and/or tearing down virtual TE links as well as by modifying real links (i.e., the fully provisioned LSPs). How to design the VNT and how to manage it are out of scope of this document.
仮想のTEリンクがVNTの一部を形成するのを許容するためにVNTの概念について敷衍できます。 完全に食糧を供給されたTEリンクと仮想のTEリンクの組み合わせは下層によって提供されたVNTを定義します。 仮想のTEリンクをセットアップする、そして/または、取りこわして、本当のリンク(すなわち、完全に食糧を供給されたLSPs)を変更することによって、VNTを変えることができます。 このドキュメントの範囲の外にどうVNTを設計するか、そして、どうそれを管理するかがあります。
In some situations, selective advertisement of the preferred connectivity among a set of border nodes between layers may be appropriate. Further decreasing the number of advertisements of the virtual connectivity can be achieved by abstracting the topology (between border nodes) using models similar to those detailed in [RFC4847].
いくつかの状況で、層の間の1セットの境界ノードの中の都合のよい接続性の選択している広告は適切であるかもしれません。 [RFC4847]で詳しく述べられたものと同様のモデルを使用することでトポロジー(境界ノードの間の)を抜き取ることによって、仮想の接続性の広告の数をさらに減少させるのを達成できます。
5.9. Verification of the LSPs
5.9. LSPsの検証
When a lower-layer LSP is established for use as a data link by a higher layer, the LSP may be verified for correct connectivity and data integrity before it is made available for use. Such mechanisms are data-technology-specific and are beyond the scope of this document, but the GMPLS protocols SHOULD provide mechanisms for the coordination of data link verification.
使用のために、より高い層でデータ・リンクと下層LSPを書き立てるとき、それを使用に利用可能にする前に正しい接続性とデータ保全のためにLSPについて確かめるかもしれません。 そのようなメカニズムは、データ技術詳細であり、このドキュメントの範囲を超えていますが、GMPLSプロトコルSHOULDはデータ・リンク検証のコーディネートにメカニズムを提供します。
Shiomoto, et al. Informational [Page 21] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [21ページ]情報のRFC5212MRN/百万要件2008年7月
5.10. Management
5.10. 管理
An MRN/MLN requires management capabilities. Operators need to have the same level of control and management for switches and links in the network that they would have in a single-layer or single-region network.
MRN/MLNは管理能力を必要とします。 オペレータはそれらが単一層かただ一つの領域ネットワークで持っているネットワークで同じ管理水準と管理をスイッチとリンクに必要とします。
We can consider two different operational models: (1) per-layer management entities and (2) cross-layer management entities.
私たちは2人の異なったオペレーショナル・モデルを考えることができます: (1) 1層あたりの経営体と(2)交差している層の経営体。
Regarding per-layer management entities, it is possible for the MLN to be managed entirely as separate layers, although that somewhat defeats the objective of defining a single multi-layer network. In this case, separate management systems would be operated for each layer, and those systems would be unaware of the fact that the layers were closely coupled in the control plane. In such a deployment, as LSPs were automatically set up as the result of control plane requests from other layers (for example, triggered signaling), the management applications would need to register the creation of the new LSPs and the depletion of network resources. Emphasis would be placed on the layer boundary nodes to report the activity to the management applications.
1層あたりの経営体に関して、MLNが完全に別々の層として管理されるのは、可能です、それがただ一つのマルチ層のネットワークを定義する目的をいくらかくつがえしますが。 この場合、別々のマネージメントシステムは各層のために操作されるでしょう、そして、それらのシステムは層が制御飛行機で密接に結合されたという事実に気づかないでしょう。 そのような展開では、LSPsが他の層からのコントロール飛行機要求の結果として自動的にセットアップされたとき(例えば、引き起こされたシグナリング)、管理アプリケーションは、新しいLSPsの創造とネットワーク資源の減少を登録する必要があるでしょう。 強調は、管理アプリケーションに活動を報告するために層の境界ノードに置かれるでしょう。
A more likely scenario is to apply a closer coupling of layer management systems with cross-layer management entities. This might be achieved through a unified management system capable of operating multiple layers, or by a meta-management system that coordinates the operation of separate management systems each responsible for individual layers. The former case might only be possible with the development of new management systems, while the latter is feasible through the coordination of existing network management tools.
よりありそうなシナリオは交差している層の経営体で層のマネージメント系の、より近いカップリングを適用することです。 これは複数の層を操作できる統一されたマネージメントシステムを通して、または、個々の層のそれぞれ原因となる別々のマネージメントシステムの操作を調整するメタマネージメントシステムで達成されるかもしれません。 前のケースは新しいマネージメントシステムの開発で可能であるだけであるかもしれません、後者が既存のネットワークマネージメントツールのコーディネートで可能ですが。
Note that when a layer boundary also forms an administrative boundary, it is highly unlikely that there will be unified multi- layer management. In this case, the layers will be separately managed by the separate administrative entities, but there may be some "leakage" of information between the administrations in order to facilitate the operation of the MLN. For example, the management system in the lower-layer network might automatically issue reports on resource availability (coincident with TE routing information) and alarm events.
また、層の境界が管理境界を形成するとき、マルチ層の管理が統一されるのが、非常にありそうもないことに注意してください。 この場合、層は別々に別々の管理実体によって管理されるでしょうが、政権の間には、情報のいくつかの「漏出」が、MLNの操作を容易にするためにあるかもしれません。 例えば、下層ネットワークにおけるマネージメントシステムは自動的にリソースの有用性(TEルーティング情報があるコインシデンス)とアラームイベントに関するレポートを発行するかもしれません。
This discussion comes close to an examination of how a VNT might be managed and operated. As noted in Section 5.8, issues of how to design and manage a VNT are out of scope for this document, but it should be understood that the VNT is a client-layer construct built from server-layer resources. This means that the operation of a VNT
この議論はVNTがどう管理されて、操作されるかもしれないかに関する試験に近づきます。 セクション5.8に述べられるように、このドキュメントのための範囲の外にVNTを設計して、どう管理するかに関する問題がありますが、VNTがサーバ層のリソースから建てられたクライアント層構造物であることが理解されるべきです。 これがそれを意味する、VNTの操作
Shiomoto, et al. Informational [Page 22] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [22ページ]情報のRFC5212MRN/百万要件2008年7月
is a collaborative activity between layers. This activity is possible even if the layers are from separate administrations, but in this case the activity may also have commercial implications.
層の間には、共同作業がありますか? 層が別々の政権から来ても、この活動は可能ですが、この場合、活動には、また、商業意味があるかもしれません。
MIB modules exist for the modeling and management of GMPLS networks [RFC4802] [RFC4803]. Some deployments of GMPLS networks may choose to use MIB modules to operate individual network layers. In these cases, operators may desire to coordinate layers through a further MIB module that could be developed. Multi-layer protocol solutions (that is, solutions where a single control plane instance operates in more than one layer) SHOULD be manageable through MIB modules. A further MIB module to coordinate multiple network layers with this control plane MIB module may be produced.
MIBモジュールはGMPLSネットワーク[RFC4802][RFC4803]のモデルと経営のために存在しています。 GMPLSネットワークのいくつかの展開が、個々のネットワーク層を操作するのにMIBモジュールを使用するのを選ぶかもしれません。 これらの場合では、オペレータは、開発できたさらなるMIBモジュールで層を調整することを望むかもしれません。 マルチ層は解決策(すなわち、単一管理飛行機例が1つ以上の層の中で作動する解決策)SHOULDについて議定書の中で述べます。MIBモジュールで、処理しやすくいてください。 このコントロール飛行機MIBモジュールで複数のネットワーク層を調整するさらなるMIBモジュールは作成されるかもしれません。
Operations and Management (OAM) tools are important to the successful deployment of all networks.
操作とManagement(OAM)ツールはすべてのネットワークのうまくいっている展開に重要です。
OAM requirements for GMPLS networks are described in [GMPLS-OAM]. That document points out that protocol solutions for individual network layers should include mechanisms for OAM or make use of OAM features inherent in the physical media of the layers. Further discussion of individual-layer OAM is out of scope of this document.
GMPLSネットワークのためのOAM要件は[GMPLS-OAM]で説明されます。 そのドキュメントは、個々のネットワーク層のプロトコルソリューションがOAMのためのメカニズムを含むべきであるか、または層の物理的なメディアに固有のOAMの特徴を利用するべきであると指摘します。 このドキュメントの範囲の外に個々の層のOAMのさらなる議論があります。
When operating OAM in a MLN, consideration must be given to how to provide OAM for end-to-end LSPs that cross layer boundaries (that may also be administrative boundaries) and how to coordinate errors and alarms detected in a server layer that need to be reported to the client layer. These operational choices MUST be left open to the service provider and so MLN protocol solutions MUST include the following features:
MLNでOAMを操作するとき、どのように終わりから終わりへの層の境界(また、それは管理境界であるかもしれない)に交差するLSPsにOAMを供給するか、そして、どのように誤りを調整するかに対して考慮を払わなければなりません、そして、サーバで検出されたアラームはクライアント層に報告されるべきその必要性を層にします。 これらの操作上の選択をサービスプロバイダーに開かれているままにしなければならないので、MLNプロトコルソリューションは以下の特徴を含まなければなりません:
- Within the context and technology capabilities of the highest
technology layer of an LSP (i.e., the technology layer of the first
hop), it MUST be possible to enable end-to-end OAM on a MLN 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 mapped to server-layer OAM operations. Most such requirements
are highly dependent on the OAM facilities of the data plane
technologies of client and server layers. However, control plane
mechanisms used in the client layer per [GMPLS-OAM] MUST map and
enable OAM in the server layer.
- LSP(すなわち、最初のホップの技術層)の最も高い技術層の文脈と技術能力の中では、MLN LSPの上の終わりから終わりへのOAMを有効にするのは可能であるに違いありません。 下層(OAM操作がサーバ層のOAM操作に写像されるのに必要とするかもしれないクライアント層)にかかるのに使用されるテクニックによって、この機能は、正常なLSPベースのOAM[GMPLS-OAM]としてイングレスLSPにおいて現れますが、層の境界に現れます。 そのようなほとんどの要件がクライアントとサーバ層のデータ飛行機技術のOAM施設に非常に依存しています。 しかしながら、[GMPLS-OAM]あたりのクライアント層の中で使用された制御飛行機メカニズムは、サーバ層の中でOAMを写像して、有効にしなければなりません。
- OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP
MUST operate for that LSP along its entire length. This means that
if an LSP crosses a domain of a lower-layer technology, the
client-layer OAM operation must operate seamlessly within the
client layer at both ends of the client-layer LSP.
- LSP MUSTのためにクライアント層の中で[GMPLS-OAM]単位で可能にされたOAM操作はそのLSPのために全長に沿って作動します。 これは、LSPが下層技術のドメインに交差しているなら、クライアント層OAM操作がLSPクライアント層の両端におけるクライアント層の中で継ぎ目なく作動しなければならないことを意味します。
Shiomoto, et al. Informational [Page 23] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [23ページ]情報のRFC5212MRN/百万要件2008年7月
- OAM functions operating within a server layer MUST be controllable
from the client layer such that the server-layer LSP(s) that
support a client-layer LSP have OAM enabled at the request of the
client layer. Such control SHOULD be subject to policy at the
layer boundary, just as automatic provisioning and LSP requests to
the server layer are subject to policy.
- サーバ層の中で作動するOAM機能がクライアント層から制御可能であるに違いないので、LSPクライアント層を支えるサーバ層のLSP(s)がクライアント層の依頼でOAMを有効にさせます。 そのようなものは層の境界の方針を同じくらい受けることがあって、ちょうど同じくらい自動である食糧を供給するのとサーバ層への要求を条件としていたLSPが方針であったならSHOULDを制御します。
- The status including errors and alarms applicable to 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 so that the
server layer may filter or hide information supplied to the client
layer. Furthermore, the client layer SHOULD be able to select to
not receive any or all such information.
- aに適切な誤りとアラームを含む状態はLSP MUSTをサーバで層にします。クライアント層に利用可能にしてください。 この情報SHOULD、方針への対象がサーバ層がフィルターにかけるかもしれないそうであったなら自動的に境界とSHOULD層のクライアント層に通知されるか、またはクライアント層に提供された情報を隠すのにおいて、構成可能であってください。 その上、クライアントはSHOULDを層にします。いずれも受けないのを選択できてそのようなすべての情報になってください。
Note that the interface between layers lies within network nodes and is, therefore, not necessarily the subject of a protocol specification. Implementations MAY use standardized techniques (such as MIB modules) to convey status information (such as errors and alarms) between layers, but that is out of scope for this document.
層の間のインタフェースがネットワーク・ノードに属して、したがって、必ずプロトコル仕様の対象であるというわけではないことに注意してください。 実現5月の使用は状態情報(誤りやアラームなどの)を層の間に伝えるために、テクニック(MIBモジュールなどの)を標準化しましたが、このドキュメントのための範囲の外にそれはいます。
6. Security Considerations
6. セキュリティ問題
The MLN/MRN architecture does not introduce any new security requirements over the general GMPLS architecture described in [RFC3945]. Additional security considerations form MPLS and GMPLS networks are described in [MPLS-SEC].
MLN/MRN構造は[RFC3945]で説明された一般的なGMPLS構造にどんな新しいセキュリティ要件も取り入れません。 追加担保問題フォームMPLSとGMPLSネットワークは[MPLS-SEC]で説明されます。
However, where the separate layers of an MLN/MRN network are operated as different administrative domains, additional security considerations may be given to the mechanisms for allowing LSP setup crossing one or more layer boundaries, for triggering lower-layer LSPs, or for VNT management. Similarly, consideration may be given to the amount of information shared between administrative domains, and the trade-off between multi-layer TE and confidentiality of information belonging to each administrative domain.
しかしながら、MLN/MRNネットワークの別々の層が異なった管理ドメインとして操作されるところでは、1つ以上の層の境界に交差するセットアップをLSPに許すか、下層LSPsの引き金となるか、またはVNT管理のためのメカニズムに追加担保問題を与えるかもしれません。 同様に、マルチ層のTEとそれぞれの管理ドメインに属す守秘義務の間で管理ドメインの間で共有された情報量、およびトレードオフに対して考慮を払うかもしれません。
It is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce.
解決策ドキュメントがどんなプロトコル拡大も紹介する安全保障問題の完全な分析を含むと予想されます。
7. Acknowledgements
7. 承認
The authors would like to thank Adrian Farrel and the participants of ITU-T Study Group 15, Question 14 for their careful review. The authors would like to thank the IESG review team for rigorous review: special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu, and Dave Ward.
作者はITU-T Study Group15(彼らの慎重なレビューのためのQuestion14)のエードリアン・ファレルと関係者に感謝したがっています。 作者は厳密なレビューについてIESGレビューチームに感謝したがっています: ティム・ポーク、ミゲル・ガルシア、ヤリArkko、ダンRomascanu、およびデーヴ・ウォードおかげでは、特別です。
Shiomoto, et al. Informational [Page 24] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [24ページ]情報のRFC5212MRN/百万要件2008年7月
8. References
8. 参照
8.1. Normative References
8.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月。
[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月。
[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月。
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006.
[RFC4397] Bryskin、I.、およびA.ファレル、「ITU-Tの文脈の中の一般化されたMultiprotocolラベルの切り換え(GMPLS)用語の解釈のための辞書編集は自動的に光学ネットワーク(ASON)構造を切り換えました」、RFC4397、2006年2月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC4726] ファレル、A.、Vasseur、J.-P.、およびA.Ayyangar、「相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み」、RFC4726(2006年11月)。
8.2. Informative References
8.2. 有益な参照
[DYN-HIER] 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] 「ダイナミックに合図された階層的なラベル切り換えられた経路への手順」というShiomoto、K.、Rabbat、R.、Ayyangar、A.、ファレル、A.、およびZ.アリは進行中(2008年2月)で働いています。
[MRN-EVAL] Le Roux, J.L., Ed., and D. Papadimitriou, Ed.,
"Evaluation of existing GMPLS Protocols against Multi
Layer and Multi Region Networks (MLN/MRN)", Work in
Progress, December 2007.
[MRN-EVAL]ル・ルー、J.L.(エド)、D.Papadimitriou(エド)、および「Multi Layerに対する既存のGMPLSプロトコルの評価とMulti Region Networks(MLN/MRN)」、Progress(2007年12月)のWork
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
March 2008.
[RFC5146] エドKumaki、K.、RFC5146、「GMPLSネットワークの上でMPLS-Teの操作を支持するという要件を織り込む」3月2008日
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, February 2008.
[MPLS-SEC] 牙、L.、エド、2月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
Shiomoto, et al. Informational [Page 25] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [25ページ]情報のRFC5212MRN/百万要件2008年7月
[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月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] 竹田、T.、エド、「仮想の兵士がネットワークでつなぐ層1のための枠組みと要件」、RFC4847、4月2007日
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
Previdi, S., Psenak, P., and P. Mabbey, "Routing
Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, July 2007.
[RFC4972]Vasseur(JP)、エド、ルルー(JL)、エド、Yasukawa、S.、Previdi、S.、Psenak、P.、およびP.Mabbey、「Multiprotocol(MPLS)ラベルスイッチルータ(LSR)交通工学(Te)の発見のためのルート設定拡大は会員資格を網の目にかけます」、RFC4972、7月2007
[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月)で働いています。
9. Contributors' Addresses
9. 貢献者のアドレス
Eiji Oki NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan Phone: +81 422 59 3441 EMail: oki.eiji@lab.ntt.co.jp
研究所の3 9-11テロのEiji Oki NTTネットワーク・サービスシステム美土里町、武蔵野市東京180-8585日本電話: +81 422 59 3441はメールされます: oki.eiji@lab.ntt.co.jp
Ichiro Inoue NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo 180-8585 Japan Phone: +81 422 59 3441 EMail: ichiro.inoue@lab.ntt.co.jp
研究所の3 9-11テロのイチロー井上NTTネットワーク・サービスシステム美土里町、武蔵野市東京180-8585日本電話: +81 422 59 3441はメールされます: ichiro.inoue@lab.ntt.co.jp
Emmanuel Dotaro Alcatel-Lucent Route de Villejust 91620 Nozay France Phone: +33 1 3077 2670 EMail: emmanuel.dotaro@alcatel-lucent.fr
エマニュエルDotaroのアルカテル透明なRoute de Villejust91620NozayフランスPhone: +33 1 3077 2670はメールされます: emmanuel.dotaro@alcatel-lucent.fr
Shiomoto, et al. Informational [Page 26] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [26ページ]情報のRFC5212MRN/百万要件2008年7月
Authors' Addresses
作者のアドレス
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi 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
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouのアルカテル透明なCopernicuslaan50B-2018アントウェルペンベルギーPhone: +32 3 240 8491はメールされます: dimitri.papadimitriou@alcatel-lucent.be
Jean-Louis Le Roux France Telecom R&D Av Pierre Marzin 22300 Lannion France EMail: jeanlouis.leroux@orange-ftgroup.com
ジャン・ルイル・ルーフランステレコム研究開発AvピアーMarzin22300Lannionフランスメール: jeanlouis.leroux@orange-ftgroup.com
Martin Vigoureux Alcatel-Lucent Route de Villejust 91620 Nozay France Phone: +33 1 3077 2669 EMail: martin.vigoureux@alcatel-lucent.fr
マーチンビグルーのアルカテル透明なRoute de Villejust91620NozayフランスPhone: +33 1 3077 2669はメールされます: martin.vigoureux@alcatel-lucent.fr
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA Phone: +1 732 420 1573 EMail: dbrungard@att.com
デボラBrungard AT&T Rm。 D1-3C22--200秒間ローレルAve。 ミドルタウン、ニュージャージー07748米国電話: +1 1573年の732 420メール: dbrungard@att.com
Shiomoto, et al. Informational [Page 27] RFC 5212 MRN/MLN Requirements July 2008
Shiomoto、他 [27ページ]情報のRFC5212MRN/百万要件2008年7月
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に情報を記述してください。
Shiomoto, et al. Informational [Page 28]
Shiomoto、他 情報[28ページ]
一覧
スポンサーリンク
