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
        
                     Requirements for GMPLS-Based
            Multi-Region and Multi-Layer Networks (MRN/MLN)
        

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.

一般化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のためのフレームワークを定義し、機能要件のセットを示しています。

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. 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).

パケット交換、レイヤ2スイッチング、TDM(時分割多重)スイッチング、波長の切り替え、及び繊維スイッチング([RFC3945]を参照のこと):一般MPLS(GMPLS)は、複数のスイッチング技術を処理するためにMPLSを拡張します。次のようにインターフェーススイッチング能力(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.

GMPLS制御プレーンにおいて、スイッチング技術のドメインの表現は、領域[RFC4206]と呼ぶことにします。スイッチング方式は、特定のデータプレーン技術のデータを転送するノードの能力を記述し、一意のネットワーク領域を特定します。層は、粒度レベル(例えば、VC4、VC-12)を切り替えるデータプレーンを記述する。データプレーン層は、制御プレーン内の領域に関連付けられている(例えば、VC4はTDMに関連付けられている、MPLSは、PSCに関連付けられています)。しかし、複数のデータ・プレーン層(例えば、VC4とVC12の両方がTDMに関連付けられている)は、同じ領域に関連することができます。したがって、(例えば、TDM)そのスイッチングタイプ値によって識別される制御プレーン領域は、「レイヤスイッチングデータプレーン」に基づいて、より小さな粒度のコンポーネントネットワークに細分することができます。インタフェーススイッチング能力(ISC)、符号化タイプ、およびスイッチング帯域幅粒度を識別するインタフェーススイッチング能力記述子(ISCD)[RFC4202]は、関連する層の特徴付けを可能にします。

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.

この文書では、我々は、マルチレイヤネットワーク(MLN)が同じISC(例えば、TDM)または異なるISC(例えば、TDMおよびPSC)の層のいずれかを切り替えるトラフィックエンジニアリング(TE)ドメインを含む複数のデータプレーンであると定義し単一のGMPLS制御プレーンインスタンスによって制御されます。私たちは、さらにMLNSの特定のケースを定義します。マルチ領域ネットワーク(MRN)は、少なくとも二つの異なるスイッチング型(例えば、PSCおよびTDM)をサポートTEドメインとして定義され、いずれかの同じデバイスまたは異なるものであり、単一のGMPLS制御プレーンの制御下でホストされていますインスタンス。

MLNs can be further categorized according to the distribution of the ISCs among the Label Switching Routers (LSRs):

MLNSはさらにラベルスイッチングルータ(LSRの)間のISCの分布に応じて分類することができます。

- 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は、ちょうど1 ISCをサポートすることができます。そのようなのLSRは、単一のスイッチング型対応のLSRとして知られています。 MLNは別のISCをサポートするいくつかの単一スイッチング型対応のLSRのセットを含んでもよいです。

- 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は、同時に複数のISCをサポートすることができます。そのようなのLSRは、マルチ切替型対応のLSRとして知られており、セクション4.2で定義されるようにさらに「シンプレックス」または「ハイブリッド」ノードのいずれかとして分類することができます。

- The MLN may be constructed from any combination of single-switching-type-capable LSRs and multi-switching-type-capable LSRs.

- MLNは、単一のスイッチング型対応のLSRとマルチ切替型対応のLSRの任意の組み合わせから構成することができます。

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リンクは、単一のトラフィックエンジニアリングデータベース(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.

例えば、パケットスイッチ対応ルータとTDMクロスコネクトから成るMRNを考えます。パケットラベルスイッチパス(LSP)は、送信元および宛先パケットスイッチ対応ルータ間でルーティングされること、およびLSPが(すなわち、パケット領域トポロジーのリソースのみを利用)PSC領域を横切ってルーティングすることができると仮定する。パケットLSPの性能目標を満たしていない場合、新しいTEリンクはTDM-領域にわたってパケットスイッチ対応ルータとの間に作成されてもよい(例えば、VC-12は、リンク)とLSPは、これらのTEリンクを介してルーティングすることができます。また、LSPが正常PSC-領域を横切って確立することができる場合であっても、(パケット交換可能なルータ間TDM領域を横切って)TDM階層のLSPを確立し、使用することができるようにすることは、ネットワークリソースのための操作者の目標を達成する必要がある場合可用性(例えば、リンク帯域幅)。 VC4のLSPが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 this document. The applicability of existing GMPLS protocols and any protocol extensions to the MRN/MLN is addressed in separate documents [MRN-EVAL].

このドキュメントの初期のセクションでは、MRN / MLNの開発と展開を必要と動機や推論を述べます。このドキュメントの後のセクションでは、GMPLS制御プレーンは、MRN / MLNをサポートするために提供しなければならない必要な機能を設定します。このドキュメントのソリューション固有および/またはプロトコル要素を指定する意図はありません。既存の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は、単一のサービスプロバイダによって操作されることが最も確からしいことであるが、この文書は、二つの層(または領域)の可能性を排除するものではない(例えば、共有異なるサービスプロバイダによって異なる管理制御下にあります管理ドメイン情報の限られた量を共有するように調製される単一の制御プレーンインスタンス)。

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).

(そのような他の規格開発組織(のSDO)によって定義されたもののような)非GMPLSインタフェースをサポートするエッジノード/ドメインと相互運用するような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.

この文書では、隣接するMRN / MLN TEドメインの相互接続は、[RFC4726]その辺もサポートしてドメイン間GMPLS RSVP-TEの拡張機能を使用することを想定しています。

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" ではありません "MUST NOT"、 "REQUIRED" はあるが、 "NOT SHALL"、 "べきではない" "べきである"、 "推奨" "ものとし"、 "MAY"、そして「OPTIONAL」は[RFC2119]の要件を強調するために、この文書で使用され、RFC 2119に記載されるように解釈されるべきであるれています。

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は、いくつかのクライアント層で開始LSPが同一層で終わるように定義され、一つ以上の下位層を横断してもよいです。機能を切り替える点で、このことは、ヘッドエンドの発信インタフェースがLSRは、LSPによって横断任意インターフェイスのインターフェイスのスイッチング能力X、LSRはさらに能力Xを切り替えたテールエンドに着信インターフェイスを有する場合任意の中間LSR、そのインタフェースのスイッチング能力で、Y、このようなY> = X.ことです

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:明示的なルートは、FAオブジェクト:転送隣接FA-LSPを:転送隣接ラベルスイッチパスのFSCを:能力ISCDスイッチングインタフェース:ファイバーは可能ISCスイッチングインターフェイスは、能力記述子L2SCスイッチング:レイヤ2スイッチングを可能LSC:ラベルは交換:ラムダができるが、LSPの切り替えパスLSR:ラベルルータMLNを切り替える:マルチレイヤネットワークMRN:マルチリージョンネットワークPSC:共有リスクリンクグループのTDM:パケットができるSRLGを切り替える時分割多重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.

マルチ領域ネットワーク(MRN)は領域境界上のネットワークデバイスが互いに異なるのISCをもたらすので、常にマルチレイヤネットワーク(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]のデータトラフィックを終端及び/又は切換可能なネットワーク資源の集合です。これらのリソースは、トラフィックの配信のためのLSPを確立するために使用することができます。例えば、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 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.

制御プレーンの観点から、LSP領域は、スイッチング技術の同じタイプを共有する1つの以上のデータプレーン層、つまり、同じスイッチングタイプの集合として定義されます。例えば、VC-11、VC-4、VC-4-7v層は、同じTDM領域の一部です。現在定義されている領域である:PSC、L2SC、TDM、LSC、及びFSC。したがって、LSP領域は、データプレーンリソース(すなわち、データリンク)はリンクの集合(すなわち、TEリンクに関連付けられたTE情報の集合体としての制御プレーンに表されている(ISCタイプで識別)技術ドメインであります)。例えば、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属性値。単に異なるスイッチング技術をホストのLSR間のシグナリングメッセージを転送することは可能ではないかもしれないことを意味します。単一の制御プレーンインスタンスが全体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.

例えば、一部の顧客は、サービスプロバイダからレイヤ1(すなわち、輸送)サービスを購入するいくつかのレイヤ2(例えば、ATM)、その他はレイヤ3(IP / MPLS)サービスを購入します。サービス・プロバイダは、1つまたは複数のネットワーク領域内に位置するネットワーク層のスタックによってサービスを実現します。ネットワーク層は、一般的にネットワーク内のデバイスのスイッチング機能に応じて配置されています。これにより、顧客ネットワークは、GMPLSベースのマルチ領域/マルチレイヤネットワークの上部に設けられていてもよいです。例えば、レイヤ1(TDMのネットワーク層を介して実現する、及び/又はLSC、及び/又はFSC領域)サービスは、(ATM仮想パス/仮想回線(VP / VC)を介して実現される)レイヤ2ネットワークをサポートすることができます、それ自体は、レイヤ3ネットワーク(IP / MPLS領域)をサポートすることができます。サポートされるデータプレーンの関係は、下位層が下層に実現データリンクを使用して、より高い層のサービスを提供するデータプレーンクライアント - サーバの関係です。

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の上部に設けられていてもよいです。例えば、純粋なIPおよび/またはIP / MPLSネットワークは、GMPLSベースのパケット・オーバー・光ネットワーク[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.

垂直相互作用は、複数の層または領域を支持する、層または領域との間のクライアント/サーバ関係を実現することが可能なネットワーク要素内の協調メカニズムとして定義されます。異なる領域または層を管理する2つのネットワークコントローラとの間のプロトコル交換は、垂直の相互作用です。制御プレーンの一部として、これらの相互作用の統合は、垂直統合と呼ばれます。したがって、これは、同じ領域かどうかの一部である複数のネットワーク層を駆動する単一の制御プレーンインスタンス内の協調メカニズムを指します。そのような概念は、効率的なネットワークリソースの使用及び技術、またはのISC切り替え、複数の層に基づいてキャリアネットワークの急速なサービスのプロビジョニングを容易にフレームワークを構築するために有用です。

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]の一部として評価され、水平統合と呼ばれています。したがって、水平統合は、ルーティング領域または自律システムなど、ネットワークパーティション及び/又は管理部門間の協調メカニズムを指します。

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.

管理ドメインは、層/領域境界と一致したときに、この区別は、さらに明確にする必要があります。水平方向の相互作用は、このようなケースをカバーするように拡張されます。例えば、二つの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のプロビジョニングと回復の両方のための統合制御および管理アプローチを提供します。実際に、GMPLS制御プレーンの機能と動作を統一するための主な動機の一つは、マルチLSP領域[RFC4206]ルーティングとTE機能をサポートする要望です。例えば、これは、大容量ネットワークにおけるパケット/レイヤ2 LSP領域とTDMまたはラムダ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.

- 複数のスイッチング能力をホストデバイス上の制御プレーンの複数のインスタンスのメンテナンスだけでなく、制御プレーンインスタンス間の相互作用の複雑さを増大させるだけでなく、処理する必要があり、各個別制御プレーンインスタンスを処理の総量を増加させます。

- 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.

- アドレッシングスペースの統合は、同じオブジェクト(例えばリンク、またはより一般的には、任意のネットワークリソース)のための複数の識別子を回避するのに役立ちます。一方、このような凝集は、制御プレーンとデータプレーンとの間の間隔に影響を与えません。

- 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.

- オーバレイ制御と同様に、単一のルーティングプロトコルインスタンスとLSRごとに単一のTEデータベースを維持することにより、統合制御プレーンモデルは、ルーティング隣接のフルメッシュを強制しない、したがって層ごとに専用ルーティングトポロジを維持する必要性を除去し飛行機。

- 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.) is facilitated by the capability within GMPLS to associate in-band control plane signaling to the IP terminating interfaces of the control plane.

- 制御チャネルは制御チャネルが直接データ・チャネルに関連付けられていないデータ・チャネル(例えば、パケット/フレームデータプレーン)と技術層に関連付けられている技術の層(SONET / SDH、G.709などのコラボレーション。)制御プレーンの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データベース内に格納されます。

4. Key Concepts of GMPLS-Based MLNs and MRNs
GMPLSベースMLNSとMRNsの4主要な概念

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又は異なるのISCのいずれかの複数のデータ・プレーン層とトランスポートノードを含むネットワークは、マルチレイヤネットワーク(MLN)と呼ばれます。 MLNSのサブセットは、異なるスイッチング技術(のISC)のLSPをサポートするネットワークで構成されています。複数のスイッチング技術をサポートするネットワークは、マルチ領域ネットワーク(MRN)と呼ばれます。

4.1. Interface Switching Capability
4.1. インターフェイスのスイッチング機能

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.

インターフェーススイッチング能力(ISC)は、統一された方法[RFC4202]にスイッチング技術の様々な種類をサポートするために、GMPLSに導入されます。 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.

(また、スイッチング能力の種類と呼ばれる)スイッチング方式は、特定のデータプレーン技術のデータを転送するノードの能力を記述し、一意のネットワーク領域を特定します。以下ISCタイプ(および、したがって、領域)が定義される:PSC、L2SC、可能なTDM、LSC、及びFSC。データリンクの各端部は、(より正確には、ノードへのデータ・リンク接続する各インタフェース)GMPLSネットワークでは、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.

ISCの値は、特定のリンクインターフェース[RFC4202]に関連付けられたTEリンク端のインタフェーススイッチング能力記述子(ISCD)属性(サブTLV)の一部として宣伝されています。離れISCから、ISCDは、符号化タイプ、帯域幅粒度、及びLSPを確立することが可能で8つの優先順位のそれぞれに予約されていない帯域を含む情報を含みます。 ISCDは、ネットワーク層の「識別」しない、それが一意に1つ以上のネットワーク層に関連する情報を特徴付けます。

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リンク端の広告は、複数のISCDsが含まれていてもよいです。これは、マルチレイヤ(またはマルチ切替可能)TEリンク端を広告として解釈することができます。つまり、TEリンク端(したがってTEリンク)は複数の層に存在する、です。

4.2. Multiple Interface Switching Capabilities
4.2. 複数インターフェーススイッチング機能

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].

MLNにおいて、ネットワーク要素は、単一のスイッチング型対応またはマルチ切替型の対応ノードとすることができます。単一スイッチング型対応ノードは、それらのTEリンク(単数または複数)のそれぞれの終端機能を記述するためにそれらのISCDサブTLV(S)の一部として同じISC値をアドバタイズ。この場合は、[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:

マルチ切替型対応のLSRsは「シンプレックス」または「ハイブリッド」ノードとして分類されます。シンプレックスハイブリッドノードが、彼らはこれらの複数のISCを宣伝方法に応じて分類されます。

- 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.

- 単純ノードは、各データリンクは別個リンクインタフェースによってノードに接続されている異なるスイッチング機能を持つデータリンクを終了することができます。だから、それは([RFC4206]で定義された規則に従って)そのISCDサブTLVで搬送単一ISC値を有するいくつかのTEリンクそれぞれをアドバタイズ。例では、別のインタフェースを介してLSRに接続されてそれぞれがPSCとTDMリンクがLSRです。

- 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.

- ハイブリッドノードは、データリンクが同じインタフェースでノードに接続された異なるスイッチング機能を有するデータリンクを終了することができます。だから、それは別のISCの値を持つ複数のISCDそれぞれを含む単一のTEリンクをアドバタイズします。例えば、ノードは、PSCとTDMデータ・リンクを終了し、内部リンクを介してこれらの外部データ・リンクを相互接続することができます。ノードに接続された外部インターフェイスの両方PSCとTDM機能を有しています。

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.

さらに、シンプレックスまたはハイブリッドノードによって発行されたTEリンクアドバタイズメントは、サポートされているスイッチング技術との間のノードの内部調整機能に関する情報を提供する必要があるかもしれません。用語「調整」は、その外部インターフェースを介して提供する異なるスイッチング機能を相互接続するために、ハイブリッドノードの特性を指します。ネットワーク内のノードの調整機能に関する情報を適合させることができるのLSRによって接合された異なるスイッチング機能を備えたリンクを含む、エンドツーエンドの多層またはマルチリージョン経路を選択する経路計算処理を可能にする(すなわち、調整リンク間の)信号。

4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes
4.2.1. マルチスイッチング方式対応のハイブリッドノードとネットワーク

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.

図1は、例えばハイブリッドノードを示しています。ハイブリッド・ノードは、それぞれ、例えば、TDMとPSCスイッチングをサポートする2つのスイッチング素子(マトリックス)を有します。ノードは、PSCとTDMリンク(リンク1とリンク2、それぞれ)を終了します。また、2つのスイッチング素子を接続する内部リンクを持っています。

The two switching elements are internally interconnected in such a way that it is possible to terminate some of the resources of, 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.

2つのスイッチング素子は、内部がリンク2、たとえば、のリソースの一部を終了し、PSCトラフィック受信/ PSCインタフェースを介して送信される(#B)の調整を提供することが可能であるような方法で相互接続されています。この状況は、終結/調整機能を実現する追加のインタフェースを介してTDMスイッチング素子へのリンク2のローカル側に接続することにより、GMPLSでモデル化されます。ハイブリッドノードを介してPSC LSPを設定するには2つの方法があります。利用可能なリソースの広告(すなわち、未予約及び最小/最大LSP帯域幅)は、これらの方法の両方をカバーすべきです。

                         .............................
                         : Network element           :
                         :            --------       :
                         :           |  PSC   |      :
             Link1 -------------<->--|#a      |      :
                         :           |        |      :
                         :  +--<->---|#b      |      :
                         :  |         --------       :
                         :  |        ----------      :
             TDM         :  +--<->--|#c  TDM   |     :
              +PSC       :          |          |     :
             Link2 ------------<->--|#d        |     :
                         :           ----------      :
                         :............................
        

Figure 1. Hybrid node.

1.ハイブリッドノード図。

4.3. Integrated Traffic Engineering (TE) and Resource Control
4.3. 統合されたトラフィックエンジニアリング(TE)と資源制御

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.

GMPLSベースのマルチ領域/マルチレイヤネットワークでは、TEリンクは、単一の制御プレーンインスタンスで使用するための単一のトラフィックエンジニアリングデータベース(TED)に統合されてもよいです。このTEDは、ネットワーク内の全ての領域の全ての層に関連する情報が含まれているので、複数の層(おそらくは複数の領域を横切る)を横切る経路は、このTEDの情報を使用して計算することができます。したがって、同じ領域の複数の層を横切って複数の領域を横切ってネットワークリソースの最適化を図ることができます。

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):

これらの概念は、他のネットワーク層によって提供される(すなわち、TEリンクである)トポロジー上のネットワーク層の動作を可能にする(例えば、PSC LSPを運ぶ下層LSC LSPを使用します)。今度は、制御及びインターワーキングのより大きな程度を達成することができる、など(これらに限定されません)。

- Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206] (see Sections 4.3.2 and 4.3.3).

- 転送隣接の動的確立(FA)のLSP [RFC4206](セクション4.3.2および4.3.3を参照されたいです)。

- Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs.

- FA LSPの動的トリガとエンドツーエンドのLSPのプロビジョニング。

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).

マルチ切替型対応ノード、異なる層または領域に属するノードを指定することができ、エンドツーエンドのLSPを確立するために使用される明示的経路を含む多層/多領域ネットワーク内ことに留意されたいです。この場合、FA-LSPの動的生成を制御するための機構(セクション4.3.2および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.

FA-LSPをが動的に確立されている方法を制御するオプションの完全なスペクトルがあります。プロセスは、管理コンポーネントによって設定することができ、管理プレーンは、FA-LSPが確立された時点で参照されることを必要とする可能性があるポリシーの制御の対象とすることができます。代替的に、FA-LSPは、任意の管理制御を行うことなく制御プレーンの要求に応じて確立することができます。

4.3.1. Triggered Signaling
4.3.1. トリガシグナリング

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".

LSPは、下層に上層から境界を横切る場合には、下層を横切る下層FA-LSPに入れ子にすることができます。静的(事前プロビジョニング)および動的(トリガー):シグナリングの観点から、下層FA-LSPを確立するための2つの選択肢があります。事前プロビジョニングさFA-LSPは、TE自動メッシュ[RFC4972]などの機能を使用してオペレータによってまたは自動的に開始することができます。このような下層LSPが存在しない場合、LSPは、動的に確立することができます。そのようなメカニズムは、「トリガ信号」と呼ばれます。

4.3.2. FA-LSPs
4.3.2. FA-LSPを

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.

LSPは、別の層の境界ノードから層を横切って作成されると、それは、上位層のデータリンクとして使用することができます。

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 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.

また、他のノードがその経路計算[RFC4206]のためのTEリンクとしてLSPを考慮することができるように、TEリンクとして広告することができます。 LSPは、制御プレーンの1つのインスタンスによって静的または動的に作成され、制御プレーンの同じインスタンスにTEリンクとして広告を転送隣接LSP(FA-LSP)と呼ばれます。 FA-LSPは、TEリンクとしてアドバタイズされ、そのTEリンクが転送隣接(FA)と呼ばれています。 FAは、依然としてシグナリング隣接関係に基づいてFA-LSPのエンドポイント間の制御プレーンの接続性を保証するそのエンドポイント間のルーティング隣接(ピアリング)を必要としない特殊な特性を有しています。 FAは、複数の上位層のLSPは、単一FA-LSP上(集約)ネストすることができるので、GMPLS-TE可能なネットワークのスケーラビリティを向上させるための便利で強力なツールです。

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].

LSPの集合は、垂直(ネスト)LSP階層の作成を可能にします。下層間または内のFA-LSPのセットは、上位層のLSPによって経路選択の際に使用することができます。同様に、上位層LSPは(それらは、任意の「通常の」静的データリンクを介して運ばれるのと同様)LSPを介して実現する動的なデータリンクを介して行うことができます。このプロセスは、階層的なプロセス[RFC4206]を通じてLSPのネスティングを必要とします。 TEDは、LSP [RFC4202]に関連付けられたTEリンク広告内に含まISCDによって識別される異なる層からのLSPの広告のセットを含みます。

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.

下層LSPをFAとしてアドバタイズされていない場合、さらに低い層を横切って上位レイヤLSPを運ぶために使用することができます。 LSPがトリガ信号を使用して設定されている場合、例えば、トリガーを発生させた上位層のLSPを運ぶために使用されます。さらに、下層は、境界に到達する他の上位レイヤのLSPによって使用可能なままです。

Under some circumstances, it may be useful to control the advertisement of LSPs as FAs during the signaling establishment of the LSPs [DYN-HIER].

いくつかの状況下では、[DYN-HIER] LSPのシグナリング確立中のFAとしてのLSPの広告を制御するのに有用であり得ます。

4.3.3. Virtual Network Topology (VNT)
4.3.3. 仮想ネットワークトポロジ(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.

一つ以上の下位層LSPのセットは、MLNの上部層(単数または複数)で処理する効率的なパスの情報を提供し、又は、換言すれば、上位レイヤに仮想ネットワーク・トポロジ(VNT)を提供します。例えば、LSC LSPによって支持されてそれぞれがLSPのセットは、PSC領域がLSC領域に接続されていると仮定すると、PSC領域の層にVNTを提供します。単下層LSPは、VNTの特殊なケースであることに留意されたいです。 VNTは、セットアップまたは下層のLSPを切断することによって構成されています。 GMPLSシグナリングおよびルーティングプロトコルを使用することにより、VNTは、トラフィック需要に適合させることができます。

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.

下層LSPは、VNTのTEリンクとして表示されます。多様ルーティング下層のLSPを使用しているか否か、下層LSPの経路はVNTにおける上位層から隠されています。したがって、VNTは、下層のLSPによって撮影されたルートを隠すことによって上層ルーティング及びトラフィックエンジニアリングの決定を単純化します。しかし、下位層のLSPのルートを非表示にすると、上位層のLSPを信頼できるようにするために必要な重要な情報を失う可能性があります。

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.

例えば、IP / MPLSレイヤにおけるルーティングとトラフィックエンジニアリングは、通常、IP / MPLS TEリンクが繊維層に配線されている光路から形成されている方法を考慮していません。二つの光路は、下位層において同じファイバリンクを共有してもよいし、ファイバリンクが切断されている場合、したがって、それらは両方とも失敗する可能性があります。したがってVNTのTEリンクの共有リスク特性は、経路計算中に上位層に利用可能にされなければなりません。任意の単一のファイバカットVNTを二分しないように、さらに、VNTのトポロジーを設計しなければなりません。これらの問題は、このドキュメントの後半で対処しています。

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).

VNTの再構成は、トラフィック需要の変化、トポロジー構成の変更、上位層からの要求をシグナリング、およびネットワーク障害によってトリガされてもよいです。例えば、送信元と宛先ノード対の間のトラフィックの需要に応じてVNTを再構成することによって、そのような最大リンク利用率とネットワークの残容量などのネットワークパフォーマンス要因は、最適化することができます。再構成は、トラフィック需要行列から、および必要に応じて現在のVNTから新しいVNTを計算することによって行われます。正確な詳細は、このドキュメントの範囲外です。しかし、この方法は、サービスのサービスプロバイダのポリシーに関するネットワーク性能と品質(遅延、損失/破壊、利用率、残容量、信頼性)に応じて調整することができます。

5. Requirements
5.要件
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes
5.1. シングルスイッチングおよびマルチスイッチング方式対応のノードの処理

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.

MRN / MLNは、単一のスイッチング型対応マルチ切替型対応のノードから構成することができます。 MLNにおける経路計算機構は、ノードの任意の組み合わせからなる経路を計算することができなければなりません。

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.

単切替型対応のマルチ切替型対応(シンプレックスまたはハイブリッド)ノードの両方が層境界の役割を果たし得ます。 MRN / MLNの経路計算は、ノードの任意の組み合わせで構築されたTEトポロジを処理する必要があります。

5.2. Advertisement of the Available Adjustment Resources
5.2. 利用可能な調整リソースの広告

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.

ハイブリッドノードは、その内部リンク(層間の垂直統合のために必要なリンク)上のリソースを維持しなければなりません。同様に、経路計算要素は、MRN / MLN経路計算における制約として終端と調整リソースの可用性に関する情報を使用するために準備されるべきです。これは、上位層のLSPの設定が下位層に必要な終結/調整リソースの不足によってブロックされる確率を減少させるであろう。

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.

マルチリージョン経路計算を実行するときに重要な情報を提供するように、ノードのMRN調整能力の広告(下部領域のLSPを終了し、上部領域にトラフィックを転送する機能)は、必要とされます。

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).

経路計算機構は、直接上位レイヤスイッチング素子と上層要素と下位要素が混在間の内部リンクを介して接続されているものに接続される上層リンク(セクション4.2.1を参照のケースをカバーしなければなりません)。

5.3. Scalability
5.3. スケーラビリティ

The MRN/MLN relies on unified routing and traffic engineering models.

MRN / MLNは、統一されたルーティングおよびトラフィック・エンジニアリングモデルに依存しています。

- 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.

- 統合ルーティングモデル:単一のルーティングプロトコルインスタンスとLSRごとに単一のTEデータベース、統合制御プレーンモデルは、層ごとに専用ルーティングトポロジを維持する必要がなくなり、したがって、層ごとのルーティング隣接のフルメッシュを強制しないを維持することにより。

- 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.

- 統合TEモデル:各LSRにおけるTEDは、すべての領域のすべての層からTEリンク(複数のスイッチング型対応のLSRにTEリンクインターフェイスは複数ISCDsでアドバタイズすることができる)が取り込まれます。これは、ネットワーク内に浸水して保存されなければならない情報量の増加につながる可能性があります。

Furthermore, path computation times, which may be of great importance during restoration, will depend on the size of the TED.

また、復元時に非常に重要であり得る経路計算時間は、TEDの大きさに依存するであろう。

Thus, MRN/MLN routing mechanisms MUST be designed to scale well with an increase of any of the following:

したがって、MRN / MLNルーティングメカニズムは、以下のいずれかの増加によく比例するように設計されなければなりません。

- Number of nodes - Number of TE links (including FA-LSPs) - Number of LSPs - Number of regions and layers - Number of ISCDs per TE link.

- ノードの数 - (FA-LSPを含む)、TEリンクの数 - LSPの数 - 領域及び層の数 - TEリンクあたりISCDs数。

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.

さらに、ルーティングプロトコルの設計はISCDsに基づいてフィルタリングTE情報を妨げてはなりません。経路計算機構とシグナリングプロトコルは、部分的なTE情報で動作することができるべきです。

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 (Virtual Network Topologies). The introduction of virtual topological maps leads us to consider the concept of emulation of data plane overlays.

TEリンクは、複数のインタフェーススイッチング機能(のISC)を宣伝することができますので、リンクの数がVNTs(仮想ネットワークトポロジ)と呼ばれる特定のトポロジカルマップを使用して(組み合わせによる)制限することができます。仮想トポロジカルマップの導入は、データプレーンオーバーレイのエミュレーションの概念を考慮することが私たちをリード。

5.4. Stability
5.4. 安定

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.

経路計算は、ネットワークトポロジと関連するリンク状態に依存しています。 VNTが頻繁におよび/またはステータスとVNTのリンクのTEパラメータ(例えば、TEメトリックは、)頻繁に変化する場合に変化した場合、上層の経路計算の安定性が損なわれることがあります。この文脈において、VNTのロバスト性が発生し、上位層にその伝搬を回避することができる変化を滑らかにする能力として定義されます。 VNTへの変更は、LSPの作成、削除、または変更によって引き起こされることがあります。

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.

プロトコルメカニズムは、作成、削除、および運用の行動を通じてトリガーLSPの変更を可能にするために提供されなければなりません。プロトコルメカニズムは、隣接する層によってトリガ同様の機能を可能にするために提供されるべきです。プロトコルメカニズムは、このような交通需要の変化、トポロジの変更、およびネットワーク障害などの環境変化に適応するために同様の機能を有効にするために設けられてもよいです。ルーティング堅牢性は、それらの変更の適応性と取引する必要があります。

5.5. Disruption Minimization
5.5. 破壊の最小化

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.

交通需要の変化に応じてVNTを再構成する場合、上位レイヤのLSPが中断される可能性があります。上位層へのそのような破壊は最小にしなければなりません。

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).

残留リソースがあるレベルまで低下すると、いくつかの下層のLSPは、ローカルまたはネットワークポリシーに応じて放出されてもよいです。トレードオフ上位レイヤトラフィックを下層の予約リソースの量を最小と破壊との間(すなわち、他のTE-のLSPにトラフィックを移動するいくつかのLSPを解放することができるように)があります。そのようなトラフィックの中断を許容することができるが、オペレータによって設定することができ、ポリシーの制御下になければなりません。トラフィックの任意の再配置は、(メークビフォア・ブレークを使用して、例えば)可能な限り無停止でなければなりません。

5.6. LSP Attribute Inheritance
5.6. 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.

TEリンクパラメータは、TEリンクを提供するLSPのパラメータから継承などLSPによって横断される下層のTEリンクかられるべきです。

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

- インタフェーススイッチング能力 - TEメトリック - 優先度レベルごとの最大のLSP帯域幅 - すべての優先レベルのための未予約帯域幅 - 最大予約可能帯域幅 - 保護属性 - 最小LSP帯域幅(スイッチング能力に依存) - 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.

継承ルールは、特定のポリシーに基づいて適用されなければなりません。特定の注意が、保護属性、及びSRLG(下層の部品TEリンクのメトリクスの厳密和以外のものであってもよい)TEメトリックの継承に与えられるべきです。

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.

前述したように、下位レイヤLSPの経路を非表示にする信頼性の高い上位層ネットワークにおいてLSPを作るために必要な重要な情報を失う可能性があります。 SRLGsはVNTの潜在的なリスクが互いに素を最小限に抑えることができ、そしてその結果、リソースの互いに素な保護パスが上位層で設定することが可能になってきように下層のLSPが同一の故障リスクを共有する識別するために使用され得ます。下層から上層へSRLG情報を継承する方法より多くの議論が必要であり、この文書の範囲外です。

5.7. Computing Paths with and without Nested Signaling
5.7. ネストされたシグナリングとないコンピューティングのパス

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).

LSPのためのパスを計算するときの経路計算は、アカウントLSP領域と層の境界にとることができます。経路計算は、そのインタフェーススイッチング能力がPSCにのみリンクにLSPによって取られる経路を制限することができます。例えば、TDM-LSPは、同じTDM層のTEリンクで構成されるトポロジを介してルーティングされているものとします。 LSPのためのパスを計算する際に、TEDは、両端が要求されたLSPのスイッチング方式を含むリンクのみを含むようにフィルタリングすることができます。このように階層的なルーティングは、機能を切り替えるに対して濾過TED(すなわち特定の層に対して、である)を使用することによって行われます。

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.

トリガ信号が許可された場合に、経路計算機構は、複数の層/領域を含む経路を生成することができます。パスは、パスがパスのエンドポイントが存在する場合と同じ層に「接続」されていなくても、複数の層/領域にわたって計算されます。ここでは、上位レイヤのシグナリング要求は境界ノードに到着したとき、トリガシグナリングは、「接続」のパスを作るために呼び出されることを前提としています。

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.

上位レイヤのシグナリング要求は、上層のホップを含むERO(明示的経路オブジェクト)を含んでいてもよいです。その場合、境界ノードは、その選択したパスを使用して下層FA-LSPのトリガーを作成するため、またはより高い層のデータリンクのような任意の利用可能な下位層LSPを選択する責任があります。このメカニズムは、TEDは、管理ポリシーが下位層を介してパスを指定するから上位レイヤを防ぐ高い個別のルーティングインスタンスが層ごとに使用される層、または濾過された環境に適しています。

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.

下層LSPを上位層に(仮想または実際の)TEリンクとして宣伝されている場合、明らかに、より高い層のシグナリング要求は、TEリンク識別子を含んでいてもよく、そのように使用される下位層リソースを示します。この場合には、下層のLSPの経路を動的にいつでも下位層によって変更することができます。

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.

あるいは、上位層シグナリング要求は、下位層FA-LSPの経路を指定するEROを含むかもしれません。この場合、境界ノードは、厳密EROに含まれるパスを使用するか、下位層内経路を再計算する必要があるかどうかを決定することができます。

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.

下層FA-のLSPが既に確立されている場合には、シグナリング要求も緩いEROとして符号化することができます。このような状況では、それが新しい下層FA-LSPを作成する必要がありますか、それは既存の下層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.

FA-LSP上層又はIGP隣接わずかFA-LSPとしてアドバタイズすることができ、下層は、下層FA-LSP上にもたらすことができます。

5.8. LSP Resource Utilization
5.8. LSPリソース使用率

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.

全ての層におけるリソース使用量は、全体(すなわち、すべての層を横切って)、協調的に(すなわち、アカウントに全ての層を取る)ように最適化されるべきです。上層LSPを担持下層LSPの数は、(複数のLSPは、負荷分散のために使用されてもよいことに注意)が最小化されるべきです。彼らの交通他のLSPに再ルーティングされている可能性が下位レイヤLSPは不要であり、避けるべきです。

5.8.1. FA-LSP Release and Setup
5.8.1. FA-LSPリリースとセットアップ

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 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.

低トラフィックの需要がある場合は、下位層のリソースが解放され、他の用途に割り当てることができるように、任意の上位層のLSPを運ばないいくつかのFA-LSPは解放されてもよいです。 FA-LSPの利用可能な帯域幅のごく一部が使用中である場合には、ネストされたLSPのは、他のFA-のLSPに再ルーティングすることができることに注意してください(必要に応じてメイク・ビフォア・ブレークの技術を使用して)まで完全に無料にFA-LSP。あるいは、未使用FA-LSPは、将来の使用のために保持することができます。リリースまたは十分に利用されていないFA-LSPの保持は政策決定です。

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のトラフィックに最小限の中断でトラフィック(上位レイヤのLSP)を担持しながらさらに、このプロセスは、可能でなければなりません。

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-LSPは、残留資源と地域全体の交通需要の変動を検討するかもしれない方針に基づいて作成することができます。新しいFA-LSPを作成することによって、そのような最大残容量などのネットワークパフォーマンスが増加することができます。

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-LSPの数が増えるにつれ、残留リソースが低下することがあります。この場合、FA-LSPの再最適化は、ポリシーに応じて呼び出すことができます。

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.

すべてのソリューションは、トラフィック需要がしきい値付近で変動してLSPの迅速なセットアップとティアダウンに起因するネットワークの不安定化から保護するための措置を含まなければなりません。

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.

下層LSPのシグナリングが急速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.

それが完全にインスタンス化に不利と考えることができる(すなわち、事前準備)上層トラフィックの不在下で他のLSPを使用することができる帯域幅を予約するかもしれない。このためVNTを提供下層LSPのセット。

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.

しかし、下位層を介して上層のLSPの経路計算を可能にするために、下層のLSPは、それらが完全に確立されていたかのように上部層にアドバタイズが、実際にそれらを確立することなくすることができます。基礎となるLSPの可能性を表すようなTEリンクは、「仮想のTEリンク」と呼ばれています。これは、実際または仮想のTEリンクを作成するかどうかを層境界ノードでの実装上の選択であり、かつ選択(実装で使用可能な場合は)オペレータポリシーの制御下でなければなりません。 (設立のLSP付き)本物のTEリンクを使用することができるため、仮想のTEリンクの作成をサポートする必要がないことに注意してください。上位層に通知(仮想または実際の)はTEリンクが存在しない場合でも、それが経路に下層の適切な階層のLSPが動的に作成されることを想定して下層に上位レイヤLSP可能(トリガ)必要に応じて。

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はすぐ下層にシグナリングされなければなりません。

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リンクが予め確立されたLSPの代わりに使用される場合、下部層との境界ノードにおける適応リソースの不必要な予約内の帯域幅の浪費を避けることができるが、上層を横切る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.

解決策を考慮に入れ、下層の(予想)交通需要や利用可能なリソースを取って、そのような仮想の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.

VNTのコンセプトは、VNTの一部を形成するために、仮想のTEリンクを許可するように拡張することができます。完全にプロビジョニングされたTEリンクおよび仮想TEリンクの組み合わせは、下位層によって提供VNTを定義します。 VNTは、設定および/または仮想のTEリンクを切断ならびにによって実際のリンク(すなわち、完全にプロビジョニングされたLSP)を変更することによって変更することができます。どのように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].

いくつかの状況では、層の間の境界ノードの集合の中の好ましい接続を選択的に広告が適切であり得ます。さらに、[RFC4847]に詳述されたものと同様のモデルを使用して(ボーダーノード間の)トポロジーを抽象化することによって達成することができる仮想接続の広告の数を減少させます。

5.9. Verification of the LSPs
5.9. LSPの検証

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プロトコルはデータリンク検証のコーディネートのためのメカニズムを提供する必要があります。

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.

(1)単位の層管理エンティティ及び(2)クロスレイヤ管理エンティティ:我々は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.

それは幾分単一のマルチレイヤネットワークを定義する目的を敗北がMLNは、別個の層として完全に管理するための単位の層管理エンティティについて、それが可能です。この場合には、個別の管理システムは、それぞれの層のために操作されるであろう、そしてそれらのシステムは、層が緊密に制御プレーンに接続されたという事実に気づかないであろう。 LSPを自動的に他の層からの制御プレーン要求の結果として設定されたこのような展開では、管理アプリケーションは、新しいLSPの作成およびネットワーク資源の枯渇を登録する必要がある(例えば、シグナル伝達をトリガー)。重点は、管理アプリケーションへの活動を報告する層境界ノードに配置されることになります。

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 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.

この議論は、VNTが管理・運営するかもしれない方法の検討に近づきます。第5.8節で述べたように、VNTを設計し、管理する方法の問題は、このドキュメントの範囲外ですが、VNTは、サーバー層のリソースから作成されたクライアント層構造であることを理解すべきです。これは、VNTの動作は層の間の共同活動であることを意味します。この活動は、層が別々の投与からであっても可能ですが、この場合には活動は、商業的意味を有することができます。

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モジュールは、[RFC4802]、[RFC4803] GMPLSネットワークのモデリングおよび管理のために存在します。 GMPLSネットワークのいくつかの展開は、個々のネットワーク層を動作させるためにMIBモジュールを使用することもできます。これらの場合、オペレータは、開発することができ、さらに、MIBモジュールを介して層を調整することを望むかもしれません。多層プロトコル・ソリューション(つまり、単一の制御プレーンインスタンスが複数の層で動作するソリューション)MIBモジュールを介して管理可能であるべきです。この制御プレーンMIBモジュールと複数のネットワーク層を調整する更なるMIBモジュールを製造することができます。

Operations and Management (OAM) tools are important to the successful deployment of all networks.

運用及び管理(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を操作する場合、考慮事項は、層の境界を越えるエンドツーエンドのLSPのための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をイネーブルにすることができなければなりません。この関数は、通常のLSPベースOAM [GMPLS-OAM]として入力LSPに見えるが、層の境界で、下位層にまたがるように使用される技術に応じて、クライアント層OAM操作はサーバレイヤOAMオペレーションにマッピングする必要があるかもしれません。ほとんどのこのような要件は、クライアントとサーバー層のデータプレーン技術のOAM施設に大きく依存しています。しかし、[GMPLS-OAM]あたりのクライアント層に使用される制御プレーン機構は、MAPとサーバ層内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のクライアント層に[GMPLS-OAM]当たりの有効OAM動作は、その全長に沿って、そのLSPのために動作しなければなりません。これは、LSPは下層技術のドメインを横切る場合、クライアント層OAM動作は、クライアント層のLSPの両端クライアント層内にシームレスに動作しなければならないことを意味します。

- 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要求ポリシーに従うべきです。

- 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.

- サーバー層LSPに適用エラーやアラームなどのステータスがクライアント層に使用可能でなければなりません。この情報は、自動的に層境界でのクライアント層に通知するように構成されるべきであり、サーバ層は、クライアント層に供給された情報をフィルタリング又は隠すことができるようにポリシーを受けるべきです。さらに、クライアント層は、いずれかまたは全てのそのような情報を受信しないように選択することができるべきです。

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.

層の間のインターフェースは、ネットワーク・ノード内にあるとされ、プロトコル仕様のため、必ずしも被写体ことに留意されたいです。実装は、層の間(例えば、エラーやアラームなど)のステータス情報を伝達するために(例えば、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ネットワークの別の層が異なる管理ドメインとして動作している場合しかし、追加のセキュリティの考慮事項は、LSPセットアップは、1つまたは複数の層境界を交差させるため、下層LSPをトリガするため、または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研究グループ15、問14の参加者に感謝したいと思います。ティムポーク、ミゲル・ガルシア、ヤリArkko、ダンRomascanu、およびデイブ・ワードに特別な感謝:著者は、厳格な審査のためにIESGレビューチームに感謝したいと思います。

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.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング(GMPLS)アーキテクチャ"、RFC 3945、2004年10月。

[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.

[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング(GMPLS)のサポートで"、RFC 4202、2005年10月。

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

[RFC4206] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス(LSP)の階層は、一般マルチプロトコルラベルスイッチング(GMPLS)トラフィックエンジニアリング(TE)との交換しました"。

[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.ファレル、「スイッチング一般マルチプロトコルラベルの解釈のための辞書編集(GMPLS)ITU-Tさんの自動交換光ネットワーク(ASON)アーキテクチャのコンテキスト内で用語」2006 RFC 4397、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、RFC 4726、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.

[DYN-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、エド。、 "マルチレイヤーとマルチリージョンネットワークに対する既存のGMPLSプロトコルの評価(MLN / MRN)"、進歩、2007年12月に作業が。

[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.

[RFC5146]熊木、K.、エド。、RFC 5146、2008年3月 "GMPLSネットワークの上にMPLS-TEの動作をサポートするための要件をインターワーキング"。

[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.

[MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年2月に作業。

[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.

[RFC4802]ナドー、T.、エド。、およびA.ファレル、エド。、 "一般化マルチプロトコルラベルスイッチング(GMPLS)トラフィックエンジニアリング管理情報ベース"、RFC 4802、2007年2月。

[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.

[RFC4803]ナドー、T.、エド。、およびA.ファレル、エド。、 "ルータ(LSR)管理情報ベーススイッチング汎用マルチプロトコルラベルスイッチング(GMPLS)ラベル"、RFC 4803、2007年2月。

[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.

[RFC4847]武田、T.、エド。、 "フレームワークおよびレイヤ1つの仮想プライベートネットワークの要件"、RFC 4847、2007年4月。

[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。、編、安川、S.、Previdi、S.、Psenak、P.、およびP. Mabbey、「マルチプロトコルの発見のためのルーティング拡張(MPLS)ラベルルータ(LSR)トラフィックエンジニアリング(TE)メッシュメンバーシップ」、RFC 4972、2007年7月を切り替えます。

[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks", Work in Progress, October 2007.

[GMPLS-OAM]ナドー、T.、大谷、T. Brungard、D.、およびA.ファレル、 "(GMPLS)ネットワークの切り替え一般マルチプロトコルラベルのためのOAM要件"、進歩、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

えいじ おき んっt ねとぉrk せrゔぃせ Sysてms ぁぼらとりえs 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん Pほね: +81 422 59 3441 えまいl: おき。えいじ@ぁb。んっt。こ。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

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

Emmanuel Dotaro Alcatel-Lucent Route de Villejust 91620 Nozay France Phone: +33 1 3077 2670 EMail: emmanuel.dotaro@alcatel-lucent.fr

エマニュエルDotaroアルカテル・ルーセントルートドゥヴィルジュ91620 Nozayフランス電話:+33 1 3077 2670 Eメール:emmanuel.dotaro@alcatel-lucent.fr

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

こへい しおもと んっt ねとぉrk せrゔぃせ Sysてms ぁぼらとりえs 3ー9ー11 みどりーちょ、 むさしのーし ときょ 180ー8585 じゃぱん えまいl: しおもと。こへい@ぁb。んっt。こ。jp

Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be

ディミトリPapadimitriouアルカテルLykent Kopernikoslaan 50 B-2018アントワープ、ベルギー電話:+ X2 3 240 8491 Eメール:δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε

Jean-Louis Le Roux France Telecom R&D Av Pierre Marzin 22300 Lannion France EMail: jeanlouis.leroux@orange-ftgroup.com

ジャン=ルイ・ルーフランステレコムR&DのAvピエールMarzin 22300ラニオンフランスEメール: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

マーティン・ヘイルアルカテル・ルーセントルートNozay 91620 Villejustのフランス電話:+33 1 3077 2669 Eメール: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 S.ローレルアベニュー。ミドルタウン、NJ 07748 USA電話:+1 732 420 1573 Eメール:dbrungard@att.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(C)IETFトラスト(2008)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。