[要約] 要約:RFC 5212は、GMPLSベースの多地域および多層ネットワーク(MRN / MLN)の要件について説明しています。 目的:このRFCの目的は、異なる地域や階層で構成されるネットワークにおいて、GMPLSを使用して効果的な通信を実現するための要件を定義することです。

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)

GMPLSベースのマルチリージョンおよびマルチレイヤーネットワークの要件(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.

一般化されたMPL(GMPL)を利用する最初の取り組みのほとんどは、単一の切り替え機能を備えた環境ホストデバイスに関連しています。このようなデータプレーンの制御によって提起された複雑さは、古典的な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).

一般化されたMPLS(GMPLS)は、MPLSを拡張して複数のスイッチング技術を処理するために拡張します:パケットスイッチング、レイヤー2スイッチング、TDM(時間分割多重化)スイッチング、波長スイッチング、およびファイバースイッチング([RFC3945を参照])。インターフェイススイッチング機能(ISC)の概念は、これらのスイッチングテクノロジーに導入され、次のように指定されています:PSC(パケットスイッチ対応)、L2SC(レイヤー2スイッチ対応)、TDM対応、LSC(Lambdaスイッチ対応)、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.

SwitchingテクノロジードメインのGMPLSコントロールプレーンでの表現は、領域[RFC4206]と呼ばれます。スイッチングタイプは、特定のデータプレーンテクノロジーのデータを転送するノードの能力を説明し、ネットワーク領域を一意に識別します。レイヤーは、データプレーンの粒度レベルを切り替える(VC4、VC-12など)を記述します。データプレーン層は、制御面の領域に関連付けられています(たとえば、VC4はTDMに関連付けられ、MPLSはPSCに関連付けられています)。ただし、複数のデータプレーンレイヤーを同じ領域に関連付けることができます(たとえば、VC4とVC12の両方がTDMに関連付けられています)。したがって、スイッチングタイプ値(TDMなど)で識別される制御面領域は、「データプレーンスイッチングレイヤー」に基づいて、より小さな粒度コンポーネントネットワークに細分化できます。インターフェイススイッチング機能記述子(ISCD)[RFC4202] [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.

このドキュメントでは、複数のデータプレーンスイッチングレイヤーを含むトラフィックエンジニアリング(TE)ドメインと同じISC(TDMなど)または異なるISC(TDMおよびPSCなど)および、およびTDMおよびPSCなどのトラフィックエンジニアリング(TE)ドメインであると定義しています。単一のGMPLSコントロールプレーンインスタンスによって制御されます。さらに、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):

MLNは、ラベルスイッチングルーター(LSRS)の間の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は、マルチスイッチタイプ対応LSRSとして知られており、セクション4.2で定義されているように、「シンプレックス」または「ハイブリッド」ノードのいずれかとしてさらに分類できます。

- The MLN may be constructed from any combination of single-switching-type-capable LSRs and multi-switching-type-capable 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リンクは単一のトラフィックエンジニアリングデータベース(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.

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が単一のサービスプロバイダーによって運用される可能性が最も高いですが、このドキュメントでは、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インターフェイス(他の標準開発組織(SDO)によって定義されているものなど)をサポートするエッジノード/ドメインと相互運用するために、インターワーキング機能が必要になる場合があります。この関数の位置と仕様は、このドキュメントの範囲外です(インターワーキングの側面は厳密にインターワーキング関数の責任の下にあるためです)。

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

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の着信インターフェイスには、LSPによってトラバースされるインターフェイスについてさらに、スイッチング機能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:ファイバースイッチング有能ISC:インターフェイススイッチング機能ISCD:インターフェイススイッチング機能記述子L2SC:レイヤー-2スイッチング有能なLSC:ラムダスイッチング有能LSP:ラベルスイッチングスイッチングPATH LSR:ラベルスイッチングルーターMLN:マルチレイヤーネットワーク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.

マルチリージョンネットワーク(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.

たとえば、一部の顧客はサービスプロバイダー、一部のレイヤー2(ATMなど)からレイヤー1(つまり、輸送)サービスを購入し、レイヤー3(IP/MPLS)サービスを購入する顧客もいます。サービスプロバイダーは、1つ以上のネットワーク領域内にあるネットワークレイヤーのスタックでサービスを実現します。ネットワークレイヤーは、一般にネットワーク内のデバイスのスイッチング機能に従って配置されます。したがって、GMPLSベースのマルチリージョン/マルチレイヤーネットワークの上に顧客ネットワークが提供される場合があります。たとえば、レイヤー-1サービス(TDMおよび/またはLSCのネットワークレイヤーを介して実現されたレイヤー、および/またはFSC領域)は、レイヤー2ネットワーク(ATM仮想パス/仮想回路(VP/VC)を介して実現)をサポートできます。、それ自体がレイヤー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の上にカスタマーネットワークが提供される場合があります。これは、サービスプロバイダーによって運営されています。たとえば、GMPLSベースのパケットオーバーオプティカルネットワーク[RFC5146]の上に純粋なIPおよび/またはIP/MPLSネットワークを提供できます。ネットワーク間の関係はクライアント/サーバーの関係であり、そのようなサービスは「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.

この区別には、管理ドメインがレイヤー/領域の境界を一致させる場合、さらに明確にする必要があります。水平相互作用は、そのようなケースをカバーするために拡張されます。たとえば、2つのLSC領域の間にある共同メカニズムは、水平統合に関連しています。一方、PSC(例:IP/MPLS)ドメインと個別のTDM対応(例:VC4同期デジタル階層(SDH))ドメインが動作する別のTDMの間で存在する共同メカニズムは、水平統合の一部ですが、また、垂直統合に向けた最初のステップと見なすこともできます。

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コントロールプレーンの機能と操作を統合する主な動機の1つは、マルチLSP-Region [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.

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

- 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など。)GMPLS内の機能により、コントロールプレーンのIP終端インターフェイスにバンド内コントロールプレーンの信号を関連付ける機能によって促進されます。

- 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
4. GMPLSベースのMLNおよびMRNの重要な概念

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

同じISCまたは異なるISCのいずれかの複数のデータプレーンレイヤーを持つ輸送ノードを含むネットワークは、単一のGMPLSコントロールプレーンインスタンスによって制御され、マルチ層ネットワーク(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)はGMPLSに導入され、さまざまな種類のスイッチングテクノロジーを統一された方法でサポートします[RFC4202]。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 Capable、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)属性(SUB-TLV)の一部として宣伝されます。ISCとは別に、ISCDには、Encodingタイプ、帯域幅の粒度、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リンクの終了広告には、複数のISCDが含まれる場合があります。これは、マルチレイヤー(またはマルチスイッチ対応)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では、ネットワーク要素は、シングルスイッチ型タイプ対応またはマルチスイッチ型型習慣ノードである場合があります。シングルスイッチタイプ対応ノードは、ISCD Sub-TLVの一部と同じISC値を宣伝し、各TEリンクの終了機能を説明します。このケースは[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:

マルチスイッチタイプ対応LSRは、「シンプレックス」または「ハイブリッド」ノードに分類されます。シンプレックスノードとハイブリッドノードは、これらの複数の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.

- シンプレックスノードは、各データリンクが個別のリンクインターフェイスによってノードに接続されている異なるスイッチング機能を持つデータリンクを終了できます。したがって、ISCD Sub-TLV([RFC4206]で定義されているルールに従って)に搭載された単一のISC値を持つ、それぞれそれぞれいくつかのTEリンクを宣伝しています。例は、PSCとTDMリンクを備えたLSRで、それぞれが個別のインターフェイスを介して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.

- ハイブリッドノードは、データリンクが同じインターフェイスによってノードに接続されている異なるスイッチング機能を持つデータリンクを終了できます。そのため、複数のISCDを含む単一のTEリンクをそれぞれ異なるISC値を宣伝しています。たとえば、ノードは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.

このタイプのネットワークには、少なくとも1つのハイブリッドノード、ゼロ以上のシンプレックスノード、および一連のシングルスイッチタイプ対応ノードが含まれています。

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リンク(それぞれlink1とlink2)を終了します。また、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つのスイッチング要素は、たとえばLink2のリソースの一部を終了し、PSCインターフェイス(#B)で受信/送信されたPSCトラフィックの調整を提供することができるように内部的に相互接続されています。この状況は、link2のローカル端を、終端/調整関数を実現する追加のインターフェイスを介してTDMスイッチング要素に接続することにより、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):

これらの概念により、他のネットワークレイヤー(たとえば、PSC LSPを運ぶ低層LSC LSPの使用)が提供するトポロジ(つまり、TEリンク)に1つのネットワークレイヤーを動作させることができます。次に、より多くの制御とインターワーキングを実現できます。

- 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 Auto-Mesh [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が1つのレイヤー境界ノードから別のレイヤーノードにレイヤーを越えて作成されると、上層のデータリンクとして使用できます。

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.

さらに、TEリンクとして宣伝することができ、他のノードがLSPをパス計算のTEリンクと見なすことができます[RFC4206]。制御プレーンの1つのインスタンスによって静的または動的に作成され、制御プレーンの同じインスタンスへのTEリンクとして宣伝されたLSPは、転送隣接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].

状況によっては、LSP [Dyn-Hier]の信号設定中にLSPの広告をFASとして制御することが有用かもしれません。

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.

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リンクがどのように形成されるかを考慮しません。2つの光学パスは、低層で同じファイバーリンクを共有する可能性があるため、ファイバーリンクがカットされている場合、両方が故障する可能性があります。したがって、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.

ハイブリッドノードは、内部リンク(レイヤー間の垂直統合に必要なリンク)にリソースを維持する必要があります。同様に、PATH計算要素は、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リンクインターフェイスは、複数のISCDで宣伝できます)。これにより、ネットワーク内に浸水して保存する必要がある情報の量が増加する可能性があります。

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.

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

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.

さらに、ルーティングプロトコルの設計は、ISCDに基づいて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リンクは複数のインターフェイススイッチング機能(ISCS)を宣伝できるため、VNT(仮想ネットワークトポロジ)と呼ばれる特定のトポロジマップを使用して、リンクの数を(組み合わせて)制限できます。仮想トポロジカルマップの導入により、データプレーンオーバーレイのエミュレーションの概念を検討することができます。

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.

継承ルールは、特定のポリシーに基づいて適用する必要があります。TEメトリックの継承に特に注意を払う必要があります(これは、下層のコンポーネントTEリンクのメトリックの厳密な合計以外の場合があります)、保護属性、および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.

前述のように、低層LSPのルートを隠すと、高層ネットワーク内のLSPを信頼できるようにするために必要な重要な情報が失われる可能性があります。SRLGSを使用して、どの低層LSPが同じ障害リスクを共有しているかを特定するために、VNTが馬鹿になる潜在的なリスクを最小限に抑えることができ、リソースダイジョイント保護パスを高層に設定できるようにすることができます。下層から上層まで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).

PATH計算は、LSPのパスを計算するときにLSP領域と層の境界を考慮することができます。パス計算では、LSPがとるパスを、インターフェイススイッチング機能がPSCであるリンクのみに制限される場合があります。たとえば、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は、上層のFA-LSPまたは下層層FA-LSPでIGP隣接を育てることができるように宣伝することができます。

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)を最小限に抑えてトラフィック(高層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のシグナル伝達には、LSPをTEリンクとして迅速に宣伝し、どのルーティングインスタンスがTEリンクを宣伝するかを調整するメカニズムを含める必要があります。

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リンクを作成するかどうかにかかわらず、レイヤー境界ノードでの実装の選択であり、選択(実装で利用可能な場合)は、オペレーターポリシーの管理下にある必要があります。実際のTEリンク(確立されたLSPを含む)が使用される可能性があるため、仮想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.

事前に確立されたLSPの代わりに仮想TEリンクが使用されている場合、上層の帯域幅の無駄と境界ノードでの適応リソースの不必要な予約を使用しながら、上層層全体の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の概念を拡張して、仮想TEリンクがVNTの一部を形成できるようにすることができます。完全にプロビジョニングされた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.

2つの異なる運用モデルを検討できます。(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.

層ごとの管理エンティティに関しては、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.

GMPLSネットワークのモデリングと管理にはMIBモジュールが存在します[RFC4802] [RFC4803]。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]ごとにクライアントレイヤーで使用される制御プレーンメカニズムは、サーバーレイヤーに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が低層技術のドメインを通過する場合、クライアント層LSPの両端でクライアントレイヤー内でクライアントレイヤーOAM操作をシームレスに動作する必要があることを意味します。

- 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がクライアントレイヤーの要求に応じて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.

著者は、Adrian FarrelとITU-T研究グループ15の参加者、質問14の慎重なレビューに感謝したいと思います。著者は、厳密なレビューについて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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)アーキテクチャ」、RFC 3945、2004年10月。

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

[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)をサポートするルーティング拡張機能」、RFC 4202、2005年10月。

[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)階層」、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. Farrel、「ITU-Tの自動切り替え光ネットワーク(ASON)アーキテクチャのコンテキスト内の一般化マルチプロトコルラベルスイッチング(GMPLS)の用語の解釈のための辞書誌」、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] Farrel、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.、Farrel、A.およびZ. Ali、「動的に信号階層ラベルの切り替えパスの手順」、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] Le Roux、J.L.、ed。、およびD. Papadimitriou、ed。、「マルチレイヤーおよびマルチリージョンネットワーク(MLN/MRN)に対する既存のGMPLSプロトコルの評価」、2007年12月の作業。

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

[RFC5146] Kumaki、K.、ed。、「GMPLSネットワークを介したMPLS-TEの運用をサポートするためのインターワーキング要件」、RFC 5146、2008年3月。

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

[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年2月、Work in Progress。

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

[RFC4802] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。

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

[RFC4803] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)ラベルスイッチングルーター(LSR)管理情報ベース」、RFC 4803、2007年2月。

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

[RFC4847] Takeda、T.、ed。、「レイヤー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。、ed。、Leroux、JL。、Ed。、Yasukawa、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] Nadeau、T.、Otani、T。Brungard、D。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチング(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

eiji oki nttネットワークサービスシステム研究所研究所3-9-11 Midori-cho、Musashino-Shi Tokyo 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

ICHIRO INOUE NTTネットワークサービスシステム研究所3-9-11 Midori-Cho、Musashino-Shi Tokyo 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

エマニュエル・ドタロ・アルカテル・ルーセント・ルート・デ・ヴィルジャスト91620ノザ・フランス電話:33 1 3077 2670メール: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

Kohei shiomoto nttネットワークサービスシステム研究所3-9-11 Midori-cho、Musashino-Shi Tokyo 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

Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen Belgium電話: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

Jean-Louis Le Roux France Telecom R&D AV Pierre Marzin 22300 Lannion France Email: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

Martin Vigoureux Alcatel-Lucent Route de Villejust 91620 Nozay France電話: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

デボラ・ブランガードAT&T RM。D1-3C22-200 S.ローレルアベニュー、ニュージャージー州ミドルタウン07748 USA電話:1 732 420 1573メール:dbrungard@att.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(c)The IETF Trust(2008)。

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

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織(もしあれば)、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

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

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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

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

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

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。