[要約] RFC 5828は、GMPLS Ethernet Label Switchingのアーキテクチャとフレームワークに関するものであり、Ethernetネットワークにおけるラベルスイッチングの実装を提供します。このRFCの目的は、GMPLSを使用してEthernetネットワークの効率と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 5828 Alcatel-Lucent
Category: Informational L. Berger
ISSN: 2070-1721 LabN
L. Andersson
Ericsson
March 2010
Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework
一般化されたマルチプロトコルラベルスイッチング（GMPLS）イーサネットラベルスイッチングアーキテクチャとフレームワーク
Abstract
概要
There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized-MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions.
イーサネットスイッチとイーサネット転送モデルの機能を高める上で、最近の重要な作業がありました。結果として、イーサネットの役割は、以前は同期光学ネットワーク（SONET） /同期デジタル階層（SDH）、時間分割マルチプレックス（TDM）、非同期などの他のテクノロジーのドメインであった「輸送ネットワーク」に急速に拡大しています。転送モード（ATM）。このドキュメントは、この「輸送ネットワーク」容量のイーサネットの一般化されたMPLSベースのコントロールプレーンのアーキテクチャとフレームワークを定義します。GMPLSは、同様のテクノロジーに既に指定されています。GMPLSコントロールプレーンへのいくつかの追加の拡張機能が必要であり、このドキュメントはこれらの拡張機能のフレームワークを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5828.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5828で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................5
1.1.1. Concepts ............................................5
1.1.2. Abbreviations and Acronyms ..........................6
2. Background ......................................................7
2.1. Ethernet Switching .........................................7
2.2. Operations, Administration, and Maintenance (OAM) .........10
2.3. Ethernet Switching Characteristics ........................10
3. Framework ......................................................11
4. GMPLS Routing and Addressing Model .............................13
4.1. GMPLS Routing .............................................13
4.2. Control Plane Network .....................................14
5. GMPLS Signaling ................................................14
6. Link Management ................................................15
7. Path Computation and Selection .................................16
8. Multiple VLANs .................................................17
9. Security Considerations ........................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
11. Acknowledgments ...............................................20
There has been significant recent work in increasing the capabilities of Ethernet switches. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH, TDM, and ATM. The evolution and development of Ethernet capabilities in these areas is a very active and ongoing process.
イーサネットスイッチの機能を高める上で、最近の重要な作業がありました。結果として、イーサネットの役割は、以前はSONET/SDH、TDM、ATMなどの他のテクノロジーのドメインであった「輸送ネットワーク」に急速に拡大しています。これらの分野でのイーサネット機能の進化と開発は、非常に活発で進行中のプロセスです。
Multiple organizations have been active in extending Ethernet technology to support transport networks. This activity has taken place in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 Working Group, the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) and the Metro Ethernet Forum (MEF). These groups have been focusing on Ethernet forwarding, Ethernet management plane extensions, and the Ethernet Spanning Tree Control Plane, but not on an explicitly routed, constraint-based control plane.
複数の組織が、輸送ネットワークをサポートするためにイーサネットテクノロジーを拡張する際に積極的に積極的に取り組んできました。この活動は、電気および電子機器エンジニア研究所（IEEE）802.1ワーキンググループ、国際電気通信連合 - 通信標準化セクター（ITU -T）およびMetro Ethernet Forum（MEF）で行われました。これらのグループは、イーサネットの転送、イーサネット管理プレーンの拡張、およびツリー制御プレーンをスパニングするイーサネットに焦点を当てていますが、明示的にルーティングされた制約ベースの制御プレーンには焦点を当てています。
In the forwarding-plane context, extensions have been, or are being, defined to support different transport Ethernet forwarding models, protection modes, and service interfaces. Examples of such extensions include [802.1ah], [802.1Qay], [G.8011], and [MEF.6]. These extensions allow for greater flexibility in the Ethernet forwarding plane and, in some cases, the extensions allow for a departure from forwarding based on a spanning tree. For example, in the [802.1ah] case, greater flexibility in forwarding is achieved through the addition of a "provider" address space. [802.1Qay] supports the use of provisioning systems and network control protocols that explicitly select traffic-engineered paths.
転送面のコンテキストでは、拡張機能が、異なる輸送イーサネット転送モデル、保護モード、およびサービスインターフェイスをサポートするために定義されている、または定義されています。このような拡張の例には、[802.1AH]、[802.1Qay]、[G.8011]、および[Mef.6]が含まれます。これらの拡張機能により、イーサネット転送面の柔軟性が高まり、場合によっては、拡張によりスパニングツリーに基づいて転送を辞めることができます。たとえば、[802.1AH]の場合、「プロバイダー」アドレス空間を追加することにより、転送の柔軟性が向上します。[802.1Qay]は、トラフィックエンジニアリングパスを明示的に選択するプロビジョニングシステムとネットワーク制御プロトコルの使用をサポートしています。
This document provides a framework for GMPLS Ethernet Label Switching (GELS). GELS will likely require more than one switching type to support the different models, and as the GMPLS procedures that will need to be extended are dependent on switching type, these will be covered in the technology-specific documents.
このドキュメントは、GMPLSイーサネットラベルスイッチング（GELS）のフレームワークを提供します。ゲルは、異なるモデルをサポートするために複数のスイッチングタイプを必要とする可能性があり、拡張する必要があるGMPLS手順はスイッチングタイプに依存するため、これらはテクノロジー固有のドキュメントでカバーされます。
In the provider bridge model developed in the IEEE 802.1ad project and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual Local Area Network (VLAN) identifier (VID) is added. This VID is referred to as the Service VID (S-VID) and is carried in a Service TAG (S-TAG). In Provider Backbone Bridges (PBBs) [802.1ah], a Backbone VID (B-VID) and B-MAC header with a service instance (I-TAG) encapsulate a customer Ethernet frame or a service Ethernet frame.
IEEE 802.1ADプロジェクトで開発され、IEEE 802.1Q標準[802.1Q]に修正されたプロバイダーブリッジモデルでは、追加の仮想ローカルエリアネットワーク（VLAN）識別子（VID）が追加されています。このVIDは、サービスVID（S-VID）と呼ばれ、サービスタグ（S-TAG）で運ばれます。プロバイダーバックボーンブリッジ（PBBS）[802.1AH]、バックボーンVID（B-VID）およびサービスインスタンス（I-TAG）を備えたB-MACヘッダーは、顧客イーサネットフレームまたはサービスイーサネットフレームをカプセル化します。
In the IEEE 802.1Q standard, the terms Provider Backbone Bridges (PBBs) and Provider Backbone Bridged Network (PBBN) are used in the context of these extensions.
IEEE 802.1Q規格では、プロバイダーバックボーンブリッジ（PBBS）とプロバイダーのバックボーンブリッジネットワーク（PBBN）がこれらの拡張機能のコンテキストで使用されます。
An example of Ethernet protection extensions can be found in [G.8031]. Ethernet operations, administration, and maintenance (OAM) is another important area that is being extended to enable provider Ethernet services. Related extensions can be found in [802.1ag] and [Y.1731].
イーサネット保護拡張の例は、[G.8031]に記載されています。イーサネット運用、管理、およびメンテナンス（OAM）は、プロバイダーのイーサネットサービスを可能にするために拡張されているもう1つの重要な領域です。関連する拡張機能は[802.1ag]および[Y.1731]にあります。
An Ethernet-based service model is being defined within the context of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel frameworks for defining network-oriented characteristics of Ethernet services in transport networks. These framework documents discuss general Ethernet connection characteristics, Ethernet User-Network Interfaces (UNIs), and Ethernet Network-Network Interfaces (NNIs). [G.8011.1] defines the Ethernet Private Line (EPL) service, and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6] covers both service types. These activities are consistent with the types of Ethernet switching defined in [802.1ah].
イーサネットベースのサービスモデルは、MEFとITU-Tのコンテキスト内で定義されています。[MEF.6]および[G.8011]は、輸送ネットワークにおけるイーサネットサービスのネットワーク指向の特性を定義するための並列フレームワークを提供します。これらのフレームワークドキュメントでは、一般的なイーサネット接続特性、イーサネットユーザーネットワークインターフェイス（UNIS）、およびイーサネットネットワークネットワークインターフェイス（NNIS）について説明します。[G.8011.1]は、イーサネットプライベートライン（EPL）サービスを定義し、[G.8011.2]はイーサネット仮想プライベートライン（EVPL）サービスを定義します。[MEF.6]は両方のサービスタイプをカバーしています。これらのアクティビティは、[802.1AH]で定義されているイーサネットスイッチングのタイプと一致しています。
The Ethernet forwarding-plane and management-plane extensions allow for the disabling of standard Spanning Tree Protocols but do not define an explicitly routed, constraint-based control plane. For example, [802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for traffic engineering of Ethernet forwarding paths.
イーサネットの転送面および管理面面拡張機能は、標準のスパニングツリープロトコルの無効化を可能にしますが、明示的にルーティングされた制約ベースの制御プレーンを定義しません。たとえば、[802.1Qay]は、イーサネット転送パスのトラフィックエンジニアリングを明示的に許可するIEEE 802.1Qの修正です。
The IETF's GMPLS work provides a common control plane for different data-plane technologies for Internet and telecommunication service providers. The GMPLS architecture is specified in RFC 3945 [RFC3945]. The protocols specified for GMPLS can be used to control "Transport Network" technologies, e.g., optical and TDM networks. GMPLS can also be used for packet and Layer 2 Switching (frame/cell-based networks).
IETFのGMPLS作業は、インターネットおよび通信サービスプロバイダー向けのさまざまなデータプレーンテクノロジーに共通の制御プレーンを提供します。GMPLSアーキテクチャは、RFC 3945 [RFC3945]で指定されています。GMPLに指定されたプロトコルは、「輸送ネットワーク」テクノロジー、たとえば光学ネットワークやTDMネットワークを制御するために使用できます。GMPLSは、パケットとレイヤー2スイッチング（フレーム/セルベースのネットワーク）にも使用できます。
This document provides a framework for the use of GMPLS to control "transport" Ethernet Label Switched Paths (Eth-LSPs). Transport Ethernet adds new constraints that require it to be distinguished from the previously specified technologies for GMPLS. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. All extensions to support Eth-LSPs will build on the GMPLS architecture and related specifications.
このドキュメントは、GMPLSを使用して「トランスポート」イーサネットラベルスイッチ付きパス（ETH-LSP）を制御するためのフレームワークを提供します。Transport Ethernetは、GMPLの以前に指定されたテクノロジーと区別する必要がある新しい制約を追加します。GMPLSコントロールプレーンへのいくつかの追加の拡張機能が必要であり、このドキュメントはこれらの拡張機能のフレームワークを提供します。ETH-LSPをサポートするすべての拡張機能は、GMPLSアーキテクチャと関連する仕様に基づいて構築されます。
This document introduces and explains GMPLS control plane use for transport Ethernet and the concept of the Eth-LSP. The data-plane aspects of Eth-LSPs are outside the scope of this document and IETF activities.
このドキュメントでは、輸送イーサネットとETH-LSPの概念にGMPLSコントロールプレーンの使用を紹介および説明します。ETH-LSPのデータ面の側面は、このドキュメントとIETFアクティビティの範囲外です。
The intent of this document is to reuse and be aligned with as much of the GMPLS protocols as possible. For example, reusing the IP control-plane addressing allows existing signaling, routing, Link Management Protocol (LMP), and path computation to be used as specified. The GMPLS protocols support hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol mechanisms support a variety of network reference points from UNIs to NNIs. Additions to existing GMPLS capabilities will only be made to accommodate features unique to transport Ethernet.
このドキュメントの意図は、できるだけ多くのGMPLSプロトコルと再利用し、整合することです。たとえば、IPコントロールプレーンアドレス指定を再利用すると、既存のシグナル伝達、ルーティング、リンク管理プロトコル（LMP）、および指定どおりに使用されるパス計算が可能になります。GMPLSプロトコルは、階層LSPと隣接するLSPをサポートしています。また、GMPLSプロトコルメカニズムは、UNISからNNIへのさまざまなネットワーク参照ポイントをサポートしています。既存のGMPLS機能への追加は、トランスポートイーサネットに固有の機能に対応するためにのみ行われます。
The following are basic Ethernet and GMPLS terms:
以下は、基本的なイーサネットとGMPLSの用語です。
o Asymmetric Bandwidth
o 非対称帯域幅
This term refers to a property of a bidirectional service instance that has differing bandwidth allocation in each direction.
この用語は、各方向に帯域幅の割り当てが異なる双方向サービスインスタンスの特性を指します。
o Bidirectional congruent LSP
o 双方向一致LSP
This term refers to the property of a bidirectional LSP that uses only the same nodes, ports, and links in both directions. Ethernet data planes are normally bidirectional congruent (sometimes known as reverse path congruent).
この用語は、同じノード、ポート、およびリンクのみを両方向に使用する双方向LSPの特性を指します。イーサネットデータプレーンは通常、双方向の合同です（逆パス合同と呼ばれることもあります）。
o Contiguous Eth-LSP
o 隣接するeth-lsp
A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from multiple Eth-LSPs, each of which is operating within a VLAN and is mapped one-to-one at the VLAN boundaries. Stitched LSPs form contiguous LSPs.
隣接するETH-LSPは、複数のETH-LSPから形成されるエンドツーエンドETH-LSPであり、それぞれがVLAN内で動作し、VLAN境界で1対1でマッピングされます。継続的なLSPを継続的に縫い付けたLSP。
o Eth-LSP
o eth-lsp
This term refers to Ethernet Label Switched Paths that may be controlled via GMPLS.
この用語は、GMPLSを介して制御できるイーサネットラベルスイッチ付きパスを指します。
o Hierarchical Eth-LSP
o 階層ETH-LSP
Hierarchical Eth-LSPs create a hierarchy of Eth-LSPs.
階層ETH-LSPは、ETH-LSPの階層を作成します。
o In-band GMPLS signaling
o インバンドGMPLSシグナリング
In-band GMPLS signaling is composed of IP-based control messages that are sent on the native Ethernet links encapsulated by a single-hop Ethernet header. Logical links that use a dedicated VID on the same physical links would be considered in-band signaling.
インバンドGMPLSシグナリングは、シングルホップイーサネットヘッダーによってカプセル化されたネイティブイーサネットリンクで送信されるIPベースの制御メッセージで構成されています。同じ物理リンクで専用のビデオを使用する論理リンクは、帯域内のシグナル伝達と見なされます。
o Out-of-band GMPLS signaling
o バンド外のGMPLSシグナリング
Out-of-band GMPLS signaling is composed of IP-based control messages that are sent between Ethernet switches over links other than the links used by the Ethernet data plane. Out-of-band signaling typically shares a different fate from the data links.
バンド外のGMPLSシグナリングは、イーサネットデータプレーンで使用されるリンク以外のリンク上にイーサネットスイッチ間で送信されるIPベースの制御メッセージで構成されています。通常、帯域外シグナリングは、データリンクとは異なる運命を共有しています。
o Point-to-point (P2P) Traffic Engineering (TE) service instance
o ポイントツーポイント（P2P）トラフィックエンジニアリング（TE）サービスインスタンス
A TE service instance made up of a single bidirectional P2P or two P2P unidirectional Eth-LSPs.
単一の双方向P2Pまたは2つのP2P単方向ETH-LSPで構成されるTEサービスインスタンス。
o Point-to-multipoint (P2MP) Traffic Engineering (TE) service instance
o ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）サービスインスタンス
A TE service instance supported by a set of LSPs that comprises one P2MP LSP from a root to n leaves, plus a bidirectional congruent point-to-point (P2P) LSP from each of the leaves to the root.
ルートからnの葉までの1つのp2MP LSPを含むLSPのセットと、各葉から根までの双方向の合同点（P2P）LSPがサポートされているTEサービスインスタンス。
o Shared forwarding
o 共有転送
Shared forwarding is a property of a data path where a single forwarding entry (VID + Destination MAC address) may be used for frames from multiple sources (Source MAC addresses). Shared forwarding does not change any data-plane behavior. Shared forwarding saves forwarding database (FDB) entries only. Shared forwarding offers similar benefits to merging in the data plane. However, in shared forwarding, the Ethernet data packets are unchanged. With shared forwarding, dedicated control-plane states for all Eth-LSPs are maintained regardless of shared forwarding entries.
共有転送は、複数のソース（ソースMACアドレス）のフレームに単一の転送エントリ（VID宛先MACアドレス）を使用できるデータパスのプロパティです。共有転送は、データプレーンの動作を変更しません。共有転送は、転送データベース（FDB）エントリのみを保存します。共有転送は、データプレーンでのマージに同様の利点を提供します。ただし、共有された転送では、イーサネットデータパケットは変更されていません。共有された転送により、共有転送エントリに関係なく、すべてのETH-LSPの専用コントロールプレーン状態が維持されます。
The following abbreviations and acronyms are used in this document:
このドキュメントでは、次の略語と頭字語が使用されています。
CCM Continuity Check Message
CFM Connectivity Fault Management
DMAC Destination MAC Address
Eth-LSP Ethernet Label Switched Path
I-SID Backbone Service Identifier carried in the I-TAG
I-TAG A Backbone Service Instance TAG defined in the
IEEE 802.1ah Standard [802.1ah]
LMP Link Management Protocol
MAC Media Access Control
MP2MP Multipoint to multipoint
NMS Network Management System
OAM Operations, Administration, and Maintenance
PBB Provider Backbone Bridges [802.1ah]
PBB-TE Provider Backbone Bridges Traffic Engineering
[802.1Qay]
P2P Point to Point
P2MP Point to Multipoint
QoS Quality of Service
SMAC Source MAC Address
S-TAG A Service TAG defined in the IEEE 802.1 Standard
[802.1Q]
TE Traffic Engineering
TAG An Ethernet short form for a TAG Header
TAG Header An extension to an Ethernet frame carrying
priority and other information
TSpec Traffic specification
VID VLAN Identifier
VLAN Virtual LAN
This section provides background to the types of switching and services that are supported within the defined framework. The former is particularly important as it identifies the switching functions that GMPLS will need to represent and control. The intent is for this document to allow for all standard forms of Ethernet switching and services.
このセクションでは、定義されたフレームワーク内でサポートされているスイッチングの種類とサービスの背景を提供します。前者は、GMPLSが表現および制御する必要があるスイッチング機能を識別するため、特に重要です。このドキュメントは、すべての標準形式のイーサネットスイッチングとサービスを許可することです。
The material presented in this section is based on both finished and ongoing work taking place in the IEEE 802.1 Working Group, the ITU-T, and the MEF. This section references and, to some degree, summarizes that work. This section is not a replacement for or an authoritative description of that work.
このセクションで提示されている資料は、IEEE 802.1ワーキンググループ、ITU-T、およびMEFで行われている完成と進行中の両方の作業に基づいています。このセクションは、その作業を参照し、ある程度要約します。このセクションは、その作業の代替または権威ある説明ではありません。
In Ethernet switching terminology, the bridge relay is responsible for forwarding and replicating the frames. Bridge relays forward frames based on the Ethernet header fields: Virtual Local Area Network (VLAN) Identifiers (VIDs) and Destination Media Access Control (DMAC) address. PBB [802.1ah] has also introduced a Service Instance tag (I-TAG). Across all the Ethernet extensions (already referenced in the Introduction), multiple forwarding functions, or service interfaces, have been defined using the combination of VIDs, DMACs, and I-TAGs. PBB [802.1ah] provides a breakdown of the different types of Ethernet switching services. Figure 1 reproduces this breakdown.
イーサネットスイッチング用語では、ブリッジリレーはフレームの転送と複製を担当します。ブリッジは、イーサネットヘッダーフィールドに基づいてフォワードフレームをリレーします：仮想ローカルエリアネットワーク（VLAN）識別子（VIDS）および宛先メディアアクセス制御（DMAC）アドレス。PBB [802.1AH]は、サービスインスタンスタグ（I-TAG）も導入しています。すべてのイーサネット拡張機能（既に参照されている）にわたって、複数の転送機能、またはサービスインターフェイスは、VID、DMAC、およびIタグの組み合わせを使用して定義されています。PBB [802.1AH]は、異なるタイプのイーサネットスイッチングサービスの内訳を提供します。図1はこの故障を再現しています。
PBB Network
Service Types
_,,-' | '--.._
_,.-'' | `'--.._
_,.--' | `'--..
Port based S-tagged I-tagged
_,- -.
_.' `.
_,' `.
one-to-one bundled
_.- =.
_.-' ``-.._
_.-' `-..
many-to-one all-to-one
|
|
|
Transparent
Figure 1: Ethernet Switching Service Types
図1：イーサネットスイッチングサービスタイプ
The switching types are defined in Clause 25 of [802.1ah]. While not specifically described in [802.1ah], the Ethernet services being defined in the context of [MEF.6] and [G.8011] also fall into the types defined in Figure 1 (with the exception of the newly defined I-tagged service type).
スイッチングタイプは、[802.1AH]の条項25で定義されています。[802.1AH]では具体的には説明されていませんが、[MEF.6]および[G.8011]のコンテキストで定義されているイーサネットサービスも図1で定義されたタイプに分類されます（新たに定義されたIタグ付きを除き、サービスの種類）。
[802.1ah] defines a new I-tagged service type but does not specifically define the Ethernet services being defined in the context of [MEF.6] and [G.8011], which are also illustrated in Figure 1.
[802.1AH]は、新しいIタグ付きサービスタイプを定義しますが、[MEF.6]および[G.8011]のコンテキストで定義されているイーサネットサービスを明確に定義していません。これも図1に示されています。
To summarize the definitions:
定義を要約するには：
o Port based
o ポートベース
This is a frame-based service that supports specific frame types; no Service VLAN tagging or MAC-address-based switching.
これは、特定のフレームタイプをサポートするフレームベースのサービスです。サービスVLANタグ付けやMac-Addressベースのスイッチングはありません。
o S-tagged
o sタグ付き
There are multiple S-TAG-aware services, including:
以下を含む複数のSタグ認識サービスがあります
+ one-to-one
+ 1対1
In this service, each VLAN identifier (VID) is mapped into a different service.
このサービスでは、各VLAN識別子（VID）が別のサービスにマッピングされます。
+ bundled
+ バンドル
Bundled S-tagged service supports the mapping of multiple VIDs into a single service and includes:
バンドルされたSタグ付きサービスは、複数のVIDのマッピングを単一のサービスにサポートし、以下を含みます。
* many-to-one
* たくさんのもの
In this frame-based service, multiple VIDs are mapped into the same service.
このフレームベースのサービスでは、複数のVIDが同じサービスにマッピングされます。
* all-to-one
* 一対一
In this frame-based service, all VIDs are mapped into the same service.
このフレームベースのサービスでは、すべてのビデオが同じサービスにマッピングされます。
- transparent
- 透明
This is a special case, all frames are mapped from a single incoming port to a single destination Ethernet port.
これは特別なケースであり、すべてのフレームは単一の着信ポートから単一の宛先イーサネットポートにマッピングされます。
o I-tagged
o iタグ付き
The edge of a PBBN consists of a combined backbone relay (B-component relay) and service instance relay (I-component relay). An I-TAG contains a service identifier (24-bit I-SID) and priority markings as well as some other fields. An I-tagged service is typically between the edges of the PBBN and terminated at each edge on an I-component that faces a customer port so the service is often not visible except at the edges. However, since the I-component relay involves a distinct relay, it is possible to have a visible I-tagged Service by separating the I-component relay from the B-component relay. Two examples where it makes sense to do this are an I-tagged service between two PBBNs and as an attachment to a customer's Provider Instance Port.
PBBNのエッジは、バックボーンリレー（Bコンポーネントリレー）とサービスインスタンスリレー（Iコンポーネントリレー）の組み合わせで構成されています。Iタグには、サービス識別子（24ビットI-SID）と優先度マーキング、および他のフィールドが含まれています。Iタグ付きサービスは通常、PBBNのエッジの間にあり、顧客ポートに面したIコンポーネントの各エッジで終了するため、エッジを除いてサービスが表示されないことがよくあります。ただし、Iコンポーネントリレーには明確なリレーが含まれるため、IコンポーネントリレーをBコンポーネントリレーから分離することにより、目に見えるIタグ付きサービスを受けることができます。これを行うことが理にかなっている2つの例は、2つのPBBNの間のIタグ付きサービスと、顧客のプロバイダーインスタンスポートへの添付ファイルです。
In general, the different switching types determine which of the Ethernet header fields are used in the forwarding/switching function, e.g., VID only or VID and DMACs. The switching type may also require the use of additional Ethernet headers or fields. Services defined for UNIs tend to use the headers for requesting service (service delimiter) and are relevant between the customer site and network edge.
一般に、異なるスイッチングタイプは、フォワーディング/スイッチング関数、たとえばVIDのみまたはVIDおよびDMACSで使用されるイーサネットヘッダーフィールドのどれが使用されるかを決定します。スイッチングタイプには、追加のイーサネットヘッダーまたはフィールドの使用も必要になる場合があります。UNIS向けに定義されているサービスは、ヘッダーを使用してサービスを要求する傾向があり（サービスデリミター）、顧客サイトとネットワークエッジの間に関連しています。
In most bridging cases, the header fields cannot be changed, but some translations of VID field values are permitted, typically at the network edges.
ほとんどのブリッジングの場合、ヘッダーフィールドを変更することはできませんが、通常はネットワークエッジでVIDフィールド値のいくつかの翻訳が許可されています。
Across all service types, the Ethernet data plane is bidirectional congruent. This means that the forward and reverse paths share the exact same set of nodes, ports, and bidirectional links. This property is fundamental. The 802.1 group has maintained this bidirectional congruent property in the definition of Connectivity Fault Management (CFM), which is part of the overall OAM capability.
すべてのサービスタイプにわたって、イーサネットデータプレーンは双方向の合同です。これは、フォワードパスとリバースパスが、まったく同じノード、ポート、双方向リンクを共有することを意味します。このプロパティは基本です。802.1グループは、全体的なOAM機能の一部である接続障害管理（CFM）の定義において、この双方向の合同プロパティを維持しています。
Robustness is enhanced with the addition of data-plane OAM to provide both fault and performance management.
障害とパフォーマンス管理の両方を提供するために、データプレーンOAMを追加することにより、堅牢性が強化されます。
Ethernet OAM messages ([802.1ag] and [Y.1731]) rely on data-plane forwarding for both directions. Determining a broken path or misdirected packet in this case relies on OAM following the Eth-LSP. These OAM message identifiers are dependent on the data plane, so they work equally well for provisioned or GMPLS-controlled paths.
イーサネットOAMメッセージ（[802.1AG]および[Y.1731]）は、両方向のデータ平面転送に依存しています。この場合の壊れた経路または誤ったパケットの決定は、ETH-LSPに続くOAMに依存しています。これらのOAMメッセージ識別子はデータプレーンに依存しているため、プロビジョニングまたはGMPLS制御パスでも同様に機能します。
Ethernet OAM currently consists of:
現在、イーサネットOAMは次のとおりです。
Defined in both [802.1ag] and [Y.1731]: - CCM/RDI: Continuity Check Message / Remote Defect Indication - LBM/LBR: Loopback Message/Reply - LTM/LTR: Link Trace Message/Reply - VSM/VSR: Vendor-Specific Message/Reply
[802.1AG]と[Y.1731]の両方で定義：-CCM/RDI：連続性チェックメッセージ/リモート欠陥表示-LBM/LBR：ループバックメッセージ/返信-LTM/LTR：リンクトレースメッセージ/返信-VSM/VSR：ベンダー固有のメッセージ/返信
Additionally defined in [Y.1731]: - AIS: Alarm Indication Signal - LCK: Locked Signal - TST: Test - LMM/LMR: Loss Measurement Message/Reply - DM: Delay Measurement - DMM/DMR: Delay Measurement Message/Reply - EXM/EXR: Experimental Message/Reply - APS, MCC: Automatic Protection Switching, Maintenance Communication Channel
さらに[Y.1731]で定義されています：-AIS：アラーム表示信号-LCK：ロックされた信号-TST：TEST -LMM/LMR：損失測定メッセージ/返信-DM：測定遅延-DMM/DMR：遅延測定メッセージ/返信 -返信 -EXM/EXR：実験メッセージ/返信-APS、MCC：自動保護スイッチング、メンテナンス通信チャネル
These functions are supported across all the standardized Eth-LSP formats.
これらの関数は、すべての標準化されたETH-LSP形式でサポートされています。
Ethernet is similar to MPLS as it encapsulates different packet and frame types for data transmission. In Ethernet, the encapsulated data is referred to as MAC client data. The encapsulation is an Ethernet MAC frame with a header, a source address, a destination address, and an optional VLAN identifier, type, and length on the front of the MAC client data with optional padding and a Frame Check Sequence at the end of the frame.
イーサネットは、データ送信のために異なるパケットとフレームタイプをカプセル化するため、MPLSに似ています。イーサネットでは、カプセル化されたデータはMacクライアントデータと呼ばれます。カプセル化は、ヘッダー、ソースアドレス、宛先アドレス、およびオプションのパディングを備えたMacクライアントデータの前面にあるオプションのVLAN識別子、タイプ、および長さを備えたイーサネットMacフレームです。フレーム。
The type of MAC client data is typically identified by an "Ethertype" value. This is an explicit type indication, but Ethernet also supports an implicit type indication.
Macクライアントデータのタイプは、通常、「EtherType」値によって識別されます。これは明示的なタイプの表示ですが、イーサネットは暗黙的なタイプの表示もサポートしています。
Ethernet bridging switches based on a frame's destination MAC address and VLAN. The VLAN identifies a virtual active set of bridges and LANs. The address is assumed to be unique and invariant within the VLAN. MAC addresses are often globally unique, but this is not necessary for bridging.
フレームの宛先MACアドレスとVLANに基づいたイーサネットブリッジングスイッチ。VLANは、ブリッジとLANの仮想アクティブセットを識別します。アドレスは、VLAN内のユニークで不変であると想定されています。多くの場合、Macアドレスはグローバルにユニークですが、これはブリッジングには必要ありません。
As defined in the GMPLS architecture [RFC3945], the GMPLS control plane can be applied to a technology by controlling the data-plane and switching characteristics of that technology. The GMPLS architecture, per [RFC3945], allowed for control of Ethernet bridges and other Layer 2 technologies using the Layer-2 Switch Capable (L2SC) switching type. But, the control of Ethernet switching was not explicitly defined in [RFC3471], [RFC4202], or any other subsequent GMPLS reference document.
GMPLSアーキテクチャ[RFC3945]で定義されているように、GMPLSコントロールプレーンは、そのテクノロジーのデータプレーンとスイッチング特性を制御することにより、テクノロジーに適用できます。[RFC3945]ごとにGMPLSアーキテクチャは、レイヤー2スイッチ（L2SC）スイッチングタイプを使用して、イーサネットブリッジおよびその他のレイヤー2テクノロジーの制御を可能にしました。しかし、イーサネットスイッチングの制御は、[RFC3471]、[RFC4202]、またはその他の後続のGMPLS参照文書で明示的に定義されていませんでした。
The GMPLS architecture includes a clear separation between a control plane and a data plane. Control plane and data plane separation allows the GMPLS control plane to remain architecturally and functionally unchanged while controlling different technologies. The architecture also requires IP connectivity for the control plane to exchange information, but does not otherwise require an IP data plane.
GMPLSアーキテクチャには、コントロールプレーンとデータプレーンの明確な分離が含まれています。制御プレーンとデータプレーンの分離により、GMPLS制御プレーンは、さまざまなテクノロジーを制御しながら、建築的および機能的に変化しないようになります。アーキテクチャでは、コントロールプレーンが情報を交換するためのIP接続を必要としますが、それ以外の場合はIPデータプレーンを必要としません。
All aspects of GMPLS, i.e., addressing, signaling, routing and link management, may be applied to Ethernet switching. GMPLS can provide control for traffic-engineered and protected Ethernet service paths. This document defines the term "Eth-LSP" to refer to Ethernet service paths that are controlled via GMPLS. As is the case with all GMPLS controlled services, Eth-LSPs can leverage common traffic engineering attributes such as:
GMPLのすべての側面、つまりアドレス指定、シグナル、ルーティング、リンク管理がイーサネットスイッチングに適用される場合があります。GMPLは、トラフィックエンジニアリングおよび保護されたイーサネットサービスパスを制御できます。このドキュメントでは、GMPLSを介して制御されるイーサネットサービスパスを参照する「ETH-LSP」という用語を定義します。すべてのGMPLS制御サービスの場合と同様に、ETH-LSPは次のような一般的なトラフィックエンジニアリング属性を活用できます。
- bandwidth profile; - forwarding priority level; - connection preemption characteristics; - protection/resiliency capability; - routing policy, such as an explicit route; - bidirectional service;
- 帯域幅プロファイル。 - 優先レベルの転送。 - 接続先制特性。 - 保護/弾力性能力。 - 明示的なルートなどのルーティングポリシー。 - 双方向サービス。
- end-to-end and segment protection; - hierarchy
- エンドツーエンドおよびセグメント保護。 - 階層
The bandwidth profile may be used to set the committed information rate, peak information rate, and policies based on either under-subscription or over-subscription. Services covered by this framework will use a TSpec that follows the Ethernet Traffic parameters defined in [ETH-TSPEC].
帯域幅プロファイルを使用して、コミットされた情報レート、ピーク情報レート、およびサブスクリプション過剰または過剰サブスクリプションに基づいたポリシーを設定できます。このフレームワークでカバーされているサービスは、[Eth-TSPEC]で定義されているイーサネットトラフィックパラメーターに従うTSPECを使用します。
In applying GMPLS to "transport" Ethernet, GMPLS will need to be extended to work with the Ethernet data plane and switching functions. The definition of GMPLS support for Ethernet is multifaceted due to the different forwarding/switching functions inherent in the different service types discussed in Section 2.1. In general, the header fields used in the forwarding/switching function, e.g., VID and DMAC, can be characterized as a data-plane label. In some circumstances, these fields will be constant along the path of the Eth-LSP, and in others they may vary hop-by-hop or at certain interfaces only along the path. In the case where the "labels" must be forwarded unchanged, there are a few constraints on the label allocation that are similar to some other technologies such as lambda labels.
GMPLSを「輸送」イーサネットに適用する際に、GMPLSはイーサネットデータプレーンとスイッチング機能を操作するために拡張する必要があります。イーサネットのGMPLSサポートの定義は、セクション2.1で説明されているさまざまなサービスタイプに内在するさまざまな転送/スイッチング関数のため、多面的です。一般に、転送/スイッチング関数で使用されるヘッダーフィールド、例えばVIDやDMACは、データプレーンラベルとして特徴付けることができます。状況によっては、これらのフィールドはETH-LSPの経路に沿って一定になり、他のフィールドでは、ホップバイホップまたは特定のインターフェイスでのみ変化する場合があります。「ラベル」を変更せずに転送する必要がある場合、Lambdaラベルなどの他のテクノロジーに似たラベル割り当てにいくつかの制約があります。
The characteristics of the "transport" Ethernet data plane are not modified in order to apply GMPLS control. For example, consider the IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter" pointing to a particular forwarding table, and if the DMAC is found in that forwarding table, the forwarding decision is made based on the DMAC. When forwarding using a spanning tree, if the DMAC is not found, the frame is broadcast over all outgoing interfaces for which that VID is defined. This valid MAC checking and broadcast supports Ethernet learning. A special case is when a VID is defined for only two ports on one bridge, effectively resulting in a P2P forwarding constraint. In this case, all frames that are tagged with that VID and received over one of these ports are forwarded over the other port without address learning.
「輸送」イーサネットデータプレーンの特性は、GMPLS制御を適用するために変更されません。たとえば、IEEE 802.1q [802.1q]データプレーンを考慮してください：VIDは特定の転送テーブルを指す「フィルター」として使用され、DMACがその転送テーブルにある場合、転送決定はDMAC。スパニングツリーを使用して転送する場合、DMACが見つからない場合、フレームは、そのVIDが定義されているすべての発信インターフェイスにブロードキャストされます。この有効なMACチェックとブロードキャストは、イーサネット学習をサポートしています。特別なケースは、1つのブリッジに2つのポートのみでVIDが定義され、事実上P2P転送の制約をもたらす場合です。この場合、そのVIDでタグ付けされ、これらのポートのいずれかで受信されたすべてのフレームは、アドレス学習なしで他のポートに転送されます。
[802.1Qay] allows for turning off learning and hence the broadcast mechanism that provides means to create explicitly routed Ethernet connections.
[802.1Qay]により、学習をオフにすることができ、したがって、明示的にルーティングされたイーサネット接続を作成する手段を提供するブロードキャストメカニズムを可能にします。
This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service-specific documents will define any signaling and routing extensions needed to support a specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It is expected that all such extensions will be consistent with this document.
このドキュメントは、ETH-LSPラベルの特定の形式を定義しません。むしろ、サービス固有のドキュメントは、特定のイーサネットサービスをサポートするために必要なシグナリングおよびルーティング拡張機能を定義することが期待されています。サービスの要件に応じて、複数のGMPLSプロトコル拡張と手順を定義する必要がある場合があります。このような拡張機能はすべて、このドキュメントと一致することが期待されています。
It is expected that a key requirement for service-specific documents will be to describe label formats and encodings. It may also be necessary to provide a mechanism to identify the required Ethernet service type in signaling and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms including new, future, and existing paradigms.
サービス固有のドキュメントの重要な要件は、ラベル形式とエンコーディングを説明することであると予想されます。また、シグナリングに必要なイーサネットサービスタイプを特定するためのメカニズムを提供し、ルーティングプロトコルでイーサネットスイッチの機能を宣伝する方法を提供する必要がある場合があります。これらのメカニズムは、新しい、将来、既存のパラダイムを含むさまざまなパラダイムの要求を区別することを可能にする必要があります。
The Switching Type and Interface Switching Capability Descriptor share a common set of values and are defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should ([RFC3471]) and can ([RFC4202]) be performed on a particular link for an LSP. The L2SC switching type may already be used by implementations performing Layer 2 Switching including Ethernet. As such, and to allow the continued use of that switching type and those implementations, and to distinguish the different Ethernet switching paradigms, a new switching type needs to be defined for each new Ethernet switching paradigm that is supported.
スイッチングタイプとインターフェイスのスイッチング機能記述子は、共通の値のセットを共有し、[RFC3945]、[RFC3471]、および[RFC4202]で定義されています。）LSPの特定のリンクで実行されます。L2SCスイッチングタイプは、イーサネットを含むレイヤー2スイッチングを実行する実装で既に使用できます。そのため、そのスイッチングタイプとそれらの実装の継続的な使用を可能にし、異なるイーサネットスイッチングパラダイムを区別するには、サポートされている新しいイーサネットスイッチングパラダイムごとに新しいスイッチングタイプを定義する必要があります。
For discussion purposes, we decompose the problem of applying GMPLS into the functions of routing, signaling, link management, and path selection. It is possible to use some functions of GMPLS alone or in partial combinations. In most cases, using all functions of GMPLS leads to less operational overhead than partial combinations.
ディスカッションの目的で、ルーティング、シグナル、リンク管理、およびパス選択の機能にGMPLを適用する問題を分解します。GMPLの単独または部分的な組み合わせでいくつかの関数を使用することが可能です。ほとんどの場合、GMPLのすべての機能を使用すると、部分的な組み合わせよりも動作のオーバーヘッドが少なくなります。
The GMPLS routing and addressing model is not modified by this document. GMPLS control for Eth-LSPs uses the routing and addressing model described in [RFC3945]. Most notably, this includes the use of IP addresses to identify interfaces and LSP end-points. It also includes support for both numbered and unnumbered interfaces.
GMPLSルーティングおよびアドレス指定モデルは、このドキュメントで変更されません。ETH-LSPSのGMPLSコントロールは、[RFC3945]で説明されているルーティングモデルとアドレス指定モデルを使用します。最も注目すべきは、これには、インターフェイスとLSPエンドポイントを識別するためのIPアドレスの使用が含まれることです。また、番号付きインターフェイスと数字のないインターフェイスの両方のサポートも含まれています。
In the case where another address family or type of identifier is required to support an Ethernet service, extensions may be defined to provide mapping to an IP address. Support of Eth-LSPs is expected to strictly comply to the GMPLS protocol suite addressing as specified in [RFC3471], [RFC3473], and related documents.
イーサネットサービスをサポートするために別のアドレスファミリまたは識別子のタイプが必要な場合、IPアドレスにマッピングを提供するために拡張機能を定義することができます。ETH-LSPのサポートは、[RFC3471]、[RFC3473]、および関連文書で指定されているGMPLSプロトコルスイートアドレス指定に厳密に準拠することが期待されています。
GMPLS routing as defined in [RFC4202] uses IP routing protocols with opaque TLV extensions for the purpose of distributing GMPLS-related TE (router and link) information. As is always the case with GMPLS, TE information is populated based on resource information obtained from LMP or from configured information. The bandwidth resources of the links are tracked as Eth-LSPs are set up. Interfaces supporting the switching of Eth-LSPs are identified using the appropriate Interface Switching Capabilities (ISC) Descriptor. As mentioned in Section 3, the definition of one or more new ISCs to support Eth-LSPs is expected. Again, the L2SC ISCs will not be used to represent interfaces capable of supporting Eth-LSPs defined by this document and subsequent documents in support of the transport Ethernet switching paradigms. In addition, ISC-specific TE information may be defined as needed to support the requirements of a specific Ethernet Switching Service Type.
[RFC4202]で定義されているGMPLSルーティングは、GMPLS関連のTE（ルーターとリンク）情報を配布する目的で、不透明なTLV拡張機能を備えたIPルーティングプロトコルを使用します。GMPLSの場合は常にそうであるように、TE情報は、LMPまたは構成された情報から得られたリソース情報に基づいて入力されます。リンクの帯域幅リソースは、ETH-LSPがセットアップされると追跡されます。ETH-LSPのスイッチングをサポートするインターフェイスは、適切なインターフェイススイッチング機能（ISC）記述子を使用して識別されます。セクション3で述べたように、ETH-LSPをサポートする1つ以上の新しいISCの定義が予想されます。繰り返しますが、L2SC ISCは、このドキュメントで定義されたETH-LSPと、輸送イーサネットスイッチングパラダイムをサポートする後続のドキュメントをサポートできるインターフェイスを表すために使用されません。さらに、ISC固有のTE情報は、特定のイーサネットスイッチングサービスタイプの要件をサポートするために必要に応じて定義できます。
GMPLS routing is an optional functionality but it is highly valuable in maintaining topology and distributing the TE database for path management and dynamic path computation.
GMPLSルーティングはオプションの機能ですが、トポロジを維持し、パス管理と動的パス計算のためにTEデータベースを配布する上で非常に価値があります。
In order for a GMPLS control plane to operate, an IP connectivity network of sufficient capacity to handle the information exchange of the GMPLS routing and signaling protocols is necessary.
GMPLS制御プレーンが動作するためには、GMPLSルーティングとシグナリングプロトコルの情報交換を処理するのに十分な容量のIP接続ネットワークが必要です。
One way to implement this is with an IP-routed network supported by an IGP that views each switch as a terminated IP adjacency. In other words, IP traffic and a simple routing table are available for the control plane, but there is no requirement for a high-performance IP data plane, or for forwarding user traffic over this IP network.
これを実装する1つの方法は、各スイッチを終了したIP隣接と見なすIGPでサポートされているIP-Routedネットワークを使用することです。言い換えれば、IPトラフィックと単純なルーティングテーブルはコントロールプレーンで使用できますが、高性能IPデータプレーン、またはこのIPネットワーク上のユーザートラフィックを転送する必要はありません。
This IP connectivity can be provided as a separate independent network (out-of-band) or integrated with the Ethernet switches (in-band).
このIP接続は、独立した独立したネットワーク（バンド外）として提供するか、イーサネットスイッチ（インバンド）と統合できます。
GMPLS signaling ([RFC3471] and [RFC3473]) is well suited to the control of Eth-LSPs and Ethernet switches. Signaling provides the ability to dynamically establish a path from an ingress node to an egress node. The signaled path may be completely static and not change for the duration of its lifetime. However, signaling also has the capability to dynamically adjust the path in a coordinated fashion after the path has been established. The range of signaling options from static to dynamic are under operator control. Standardized signaling also improves multi-vendor interoperability.
GMPLSシグナル伝達（[RFC3471]および[RFC3473]）は、ETH-LSPおよびイーサネットスイッチの制御に適しています。シグナリングは、侵入ノードから出口ノードへのパスを動的に確立する機能を提供します。信号されたパスは完全に静的であり、その寿命の間は変化しない場合があります。ただし、シグナリングには、パスが確立された後、調整された方法でパスを動的に調整する能力もあります。静的から動的までのシグナリングオプションの範囲は、オペレーター制御下にあります。標準化されたシグナル伝達は、マルチベンダーの相互運用性も向上します。
GMPLS signaling supports the establishment and control of bidirectional and unidirectional data paths. Ethernet is bidirectional by nature and CFM has been built to leverage this. Prior to CFM, the emulation of a physical wire and the learning requirements also mandated bidirectional connections. Given this, Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full and partial LSP protection; see [RFC4872] and [RFC4873].
GMPLSシグナリングは、双方向および単方向のデータパスの確立と制御をサポートします。イーサネットは本質的に双方向であり、CFMはこれを活用するために構築されています。CFMの前に、物理ワイヤのエミュレーションと学習要件は、双方向の接続も義務付けられていました。これを考えると、ETH-LSPは双方向の合同である必要があります。ETH-LSPはP2PまたはP2MPのいずれかである可能性があります（[RFC4875]を参照）。GMPLSシグナリングは、完全および部分的なLSP保護も可能にします。[RFC4872]および[RFC4873]を参照してください。
Note that standard GMPLS does not support different bandwidth in each direction of a bidirectional LSP. [RFC5467], an Experimental document, provides procedures if asymmetric bandwidth bidirectional LSPs are required.
標準GMPLSは、双方向LSPの各方向の異なる帯域幅をサポートしていないことに注意してください。[RFC5467]、実験文書である[RFC5467]は、非対称帯域幅の双方向LSPが必要な場合の手順を提供します。
Link discovery has been specified for links interconnecting IEEE 802.1 bridges in [802.1AB]. The benefits of running link discovery in large systems are significant. Link discovery may reduce configuration and reduce the possibility of undetected errors in configuration as well as exposing misconnections. However, the 802.1AB capability is an optional feature, so it is not necessarily operating before a link is operational, and it primarily supports the management plane.
[802.1ab]のIEEE 802.1ブリッジを相互接続するリンクにリンク発見が指定されています。大規模システムでリンク発見を実行することの利点は重要です。リンクの発見は、構成を削減し、構成の検出されないエラーの可能性を減らすだけでなく、誤った接続を公開する場合があります。ただし、802.1AB機能はオプションの機能であるため、リンクが動作する前に必ずしも動作するわけではなく、主に管理プレーンをサポートします。
In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS control-plane link management and discovery features. LMP also supports the automated creation of unnumbered interfaces for the control plane. If LMP is not used, there is an additional configuration requirement for GMPLS link identifiers. For large-scale implementations, LMP is beneficial. LMP also has optional fault management capabilities, primarily for opaque and transparent network technology. With IEEE's newer CFM [802.1ag] and ITU-T's capabilities [Y.1731], this optional capability may not be needed. It is the goal of the GMPLS Ethernet architecture to allow the selection of the best tool set for the user needs. The full functionality of Ethernet CFM should be supported when using a GMPLS control plane.
GMPLSコンテキストでは、LMP [RFC4204]がGMPLSコントロールプレーンリンク管理と発見機能をサポートするために定義されています。LMPは、コントロールプレーン用の非自由型インターフェイスの自動化された作成もサポートしています。LMPが使用されていない場合、GMPLSリンク識別子に追加の構成要件があります。大規模な実装では、LMPが有益です。LMPには、主に不透明で透明なネットワークテクノロジー向けのオプションの障害管理機能もあります。IEEEの新しいCFM [802.1AG]およびITU-Tの機能[Y.1731]では、このオプションの機能は必要ない場合があります。GMPLSイーサネットアーキテクチャの目標は、ユーザーのニーズに合わせて最適なツールセットを選択できるようにすることです。GMPLSコントロールプレーンを使用する場合、イーサネットCFMの完全な機能をサポートする必要があります。
LMP and 802.1AB are relatively independent. The LMP capability should be sufficient to remove the need for 802.1AB, but 802.1 AB can be run in parallel or independently if desired. Figure 2 provides possible ways of using LMP, 802.1AB, and 802.1ag in combination.
LMPと802.1ABは比較的独立しています。LMP機能は802.1ABの必要性を削除するのに十分でなければなりませんが、802.1 ABは、必要に応じて並列または個別に実行できます。図2は、LMP、802.1AB、および802.1AGを組み合わせて使用する可能性のある方法を示しています。
Figure 2 illustrates the functional relationship of link management and OAM schemes. It is expected that LMP would be used for control-plane functions of link property correlation, but that Ethernet mechanisms for OAM such as CFM, link trace, etc., would be used for data-plane fault management and fault trace.
図2は、リンク管理とOAMスキームの機能的関係を示しています。LMPは、リンクプロパティ相関の制御プレーン関数に使用されることが予想されますが、CFM、リンクトレースなどのOAMのイーサネットメカニズムは、データプレーン障害管理と障害トレースに使用されることが予想されます。
+-------------+ +-------------+
| +---------+ | | +---------+ |
| | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation
| | (opt) | |GMPLS | | (opt) | |
| | | | | | | | Bundling
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |
| | 802.1AB |-|<------>|-| 802.1AB | |P2P
| | (opt) | |Ethernet| | (opt) | |link identifiers
| | | | | | | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | | | | | | |End-to-End
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
| | Y.1731 | |Ethernet| | Y.1731 | |Fault Management
| | (opt) | | | | (opt) | |Performance
| | | | | | | |Management
| +---------+ | | +---------+ |
+-------------+ +-------------+
Switch 1 link Switch 2
Figure 2: Logical Link Management Options
図2：論理リンク管理オプション
GMPLS does not identify a specific method for selecting paths or supporting path computation. GMPLS allows for a wide range of possibilities to be supported, from very simple path computation to very elaborate path coordination where a large number of coordinated paths are required. Path computation can take the form of paths being computed in a fully distributed fashion, on a management station with local computation for rerouting, or on more sophisticated path computation servers.
GMPLSは、パスを選択したり、パス計算をサポートするための特定の方法を特定しません。GMPLSは、非常に単純なパス計算から、多数の調整されたパスが必要な非常に精巧なパス調整まで、幅広い可能性をサポートすることができます。パス計算は、完全に分散された方法で計算されているパスの形式、再ルーティング用のローカル計算を備えた管理ステーション、またはより洗練されたパス計算サーバーで取得できます。
Eth-LSPs may be supported using any path selection or computation mechanism. As is the case with any GMPLS path selection function, and common to all path selection mechanisms, the path selection process should take into consideration Switching Capabilities and Encoding advertised for a particular interface. Eth-LSPs may also make use of the emerging path computation element and selection work; see [RFC4655].
ETH-LSPは、パス選択または計算メカニズムを使用してサポートされる場合があります。GMPLSパス選択関数の場合と同様に、すべてのパス選択メカニズムに共通するように、パス選択プロセスは、特定のインターフェイスに広告されているスイッチング機能とエンコードを考慮に入れる必要があります。ETH-LSPは、新しいパス計算要素と選択作業を使用する場合もあります。[RFC4655]を参照してください。
This document allows for the support of the signaling of Ethernet parameters across multiple VLANs supporting both contiguous Eth-LSP and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS hierarchy for the support of peer-to-peer models, UNIs, and NNIs.
このドキュメントにより、隣接するETH-LSPと階層イーサネットLSPの両方をサポートする複数のVLANにわたるイーサネットパラメーターのシグナル伝達のサポートが可能になります。意図は、ピアツーピアモデル、UNIS、およびNNISのサポートのためにGMPLS階層を再利用することです。
A GMPLS-controlled "transport" Ethernet system should assume that users and devices attached to UNIs may behave maliciously, negligently, or incorrectly. Intra-provider control traffic is trusted to not be malicious. In general, these requirements are no different from the security requirements for operating any GMPLS network. Access to the trusted network will only occur through the protocols defined for the UNI or NNI or through protected management interfaces.
GMPLS制御の「トランスポート」イーサネットシステムは、UNIに接続されているユーザーとデバイスが悪意を持って、怠慢に、または誤って振る舞う可能性があると想定する必要があります。プロバイダー内の制御トラフィックは、悪意がないと信頼されています。一般に、これらの要件は、GMPLSネットワークを操作するためのセキュリティ要件と違いはありません。信頼できるネットワークへのアクセスは、UNIまたはNNIに対して定義されたプロトコルまたは保護された管理インターフェイスを通じてのみ発生します。
When in-band GMPLS signaling is used for the control plane, the security of the control plane and the data plane may affect each other. When out-of-band GMPLS signaling is used for the control plane, the data-plane security is decoupled from the control plane, and therefore the security of the data plane has less impact on overall security.
バンド内のGMPLSシグナリングが制御プレーンに使用されると、制御プレーンとデータプレーンのセキュリティが互いに影響を与える可能性があります。帯域外GMPLSシグナリングが制御プレーンに使用される場合、データプレーンセキュリティは制御プレーンから切り離されているため、データプレーンのセキュリティは全体的なセキュリティへの影響が少なくなります。
Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet denial-of-service attacks may be required on UNI ports.
GMPLSがVLANのみの制御に適用される場合、UNIポートではイーサネット拒否攻撃の緩和のための一般的に既知の手法が必要になる場合があります。
For a more comprehensive discussion on GMPLS security please see the MPLS and GMPLS Security Framework [SECURITY]. Cryptography can be used to protect against many attacks described in [SECURITY]. One option for protecting "transport" Ethernet is the use of 802.1AE Media Access Control Security [802.1AE], which provides encryption and authentication. It is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce.
GMPLSセキュリティに関するより包括的な議論については、MPLSおよびGMPLSセキュリティフレームワーク[セキュリティ]を参照してください。暗号化は、[セキュリティ]に記載されている多くの攻撃から保護するために使用できます。「輸送」イーサネットを保護するための1つのオプションは、暗号化と認証を提供する802.1AEメディアアクセス制御セキュリティ[802.1AE]の使用です。ソリューションドキュメントには、プロトコル拡張が導入するセキュリティ問題の完全な分析が含まれることが期待されています。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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月。
[802.1AB] "IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, 2009.
[802.1AB]「ローカルおよびメトロポリタンエリアネットワーク、ステーションおよびメディアアクセス制御接続の発見のIEEE標準」、IEEE 802.1AB、2009。
[802.1AE] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, August 2006.
[802.1AE]「ローカルおよびメトロポリタンエリアネットワークメディアアクセス制御（MAC）セキュリティのIEEE標準」、IEEE 802.1AE-2006、2006年8月。
[802.1ag] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management", IEEE 802.1ag, 2007.
[802.1AG]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク - 修正5：接続障害管理」、IEEE 802.1AG、2007。
[802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", IEEE Std 802.1ah-2008, August 2008.
[802.1AH]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク - 修正6：プロバイダーバックボーンブリッジ」、IEEE STD 802.1AH -2008、2008年8月。
[802.1Q] "IEEE standard for Virtual Bridged Local Area Networks", IEEE 802.1Q-2005, May 2006.
[802.1Q]「仮想ブリッジ型ローカルエリアネットワークのIEEE標準」、IEEE 802.1Q-2005、2006年5月。
[802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 10: Provider Backbone Bridge Traffic Engineering", IEEE Std 802.1Qay-2009, August 2009.
[802.1Qay]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク - 修正10：プロバイダーバックボーンブリッジトラフィックエンジニアリング」、IEEE STD 802.1QAY -2009、2009年8月。
[ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", Work in Progress, January 2010.
[Eth-Tspec] Papadimitriou、D。、「イーサネットトラフィックパラメーター」、2010年1月の進行中。
[G.8011] ITU-T Recommendation G.8011, "Ethernet over Transport - Ethernet services framework", January 2009.
[G.8011] ITU -T推奨G.8011、「輸送に関するイーサネット - イーサネットサービスフレームワーク」、2009年1月。
[G.8011.1] ITU-T Recommendation G.8011.1/Y.1307.1, "Ethernet private line service", January 2009.
[G.8011.1] ITU-T推奨G.8011.1/Y.1307.1、「イーサネットプライベートラインサービス」、2009年1月。
[G.8011.2] ITU-T Recommendation G.8011.2/Y.1307.2, "Ethernet virtual private line service", January 2009.
[G.8011.2] ITU-T推奨G.8011.2/Y.1307.2、「イーサネット仮想プライベートラインサービス」、2009年1月。
[G.8031] ITU-T Recommendation G.8031, "Ethernet linear protection switching", November 2009.
[G.8031] ITU-T推奨G.8031、「イーサネット線形保護スイッチング」、2009年11月。
[MEF.6] The Metro Ethernet Forum MEF 6, "Ethernet Services Definitions - Phase I", 2004.
[Mef.6] The Metro Ethernet Forum Mef 6、「イーサネットサービス定義 - フェーズI」、2004。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする"、RFC 4872、2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009.
[RFC5467] Berger、L.、Takacs、A.、Caviglia、D.、Fedyk、D。、およびJ. Meuric、「Gmpls非対称帯域幅の双方向ラベルスイッチドパス（LSP）」、RFC 5467、2009年3月。
[SECURITY] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[Security] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2009年10月の作業。
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms for Ethernet based Networks", February 2008.
[Y.1731] ITU-T推奨Y.1731、「イーサネットベースのネットワークのOAM機能とメカニズム」、2008年2月。
There were many people involved in the initiation of this work prior to this document. The GELS framework document and the PBB-TE extensions document were two documents that helped shape and justify this work. We acknowledge the work of the authors of these initial documents: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar.
この文書の前に、この作業の開始に多くの人々が関与していました。Gels FrameworkドキュメントとPBB-TE Extensionsドキュメントは、この作業を形作り正当化するのに役立つ2つのドキュメントでした。これらの最初の文書の著者の仕事を認めています：ディミトリ・パパジミトリウ、ヌリット・スプレチャー、ジャイヒョン・チョー、デイブ・アラン、ピーター・バスバッハ、アッティラ・タカックス、トーマス・エリクソン、ディエゴ・カビリア、ヒマンシュ・シャー、グレッグ・サンダーウッド、アラン・マクガイア、ナビル・ビタル。
George Swallow contributed significantly to this document.
ジョージ・スワローはこの文書に大きく貢献しました。
Authors' Addresses
著者のアドレス
Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
Don Fedyk Alcatel-Lucent Groton、MA、01450電話：1-978-467-5645メール：donald.fedyk@alcatel-lucent.com
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net
Loa Andersson Ericsson Phone: +46 10 717 52 13 EMail: loa.andersson@ericsson.com
Loa Andersson Ericsson電話：46 10 717 52 13メール：loa.andersson@ericsson.com