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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
複数の組織には、トランスポートネットワークをサポートするために、イーサネット技術の延長で活躍しています。電気通信標準化部門（ITU-T）およびメトロ・イーサネット・フォーラム（MEF） - この活動は、電気電子学会（IEEE）802.1ワーキンググループの研究所、国際電気通信連合で行われました。これらのグループは、イーサネット転送、イーサネット管理プレーン拡張、およびイーサネットスパニングツリーコントロールプレーン上ではなく、明示的にルーティングされ、制約ベースのコントロールプレーンに焦点を当ててきました。
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イーサネットプロトコルラベルスイッチング（ゲル）のためのフレームワークを提供します。ゲルはおそらく異なるモデルをサポートするために、複数のスイッチング方式が必要になりますし、拡張する必要があります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）と呼ばれ、サービスTAG（S-TAG）で行われます。プロバイダ内バックボーンブリッジ（PBB類）[802.1ahの]、サービスインスタンス（I-TAG）を有するバックボーンVID（B-VID）と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規格では、用語プロバイダーバックボーンブリッジ（PBB類）とプロバイダーバックボーンブリッジネットワーク（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）プロバイダーのイーサネットサービスを有効にするように拡張されているもう一つの重要な領域です。関連の拡張機能は、[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]は、トランスポートネットワーク内のイーサネット・サービスのネットワーク指向の特性を定義するための平行なフレームワークを提供します。これらのフレームワークの文書は、一般的なイーサネット接続性を議論するイーサネットユーザ・ネットワーク・インタフェース（UNIの）、およびイーサネットネットワーク - ネットワークインタフェース（NNIに）。 [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]で指定されています。 GMPLSに指定されたプロトコルは、「トランスポートネットワーク」技術、例えば、光学的及び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.
この文書では、「輸送」は、イーサネット・ラベルは（ETH-LSPを）パスをスイッチ制御するGMPLSを使用するためのフレームワークを提供します。交通イーサネットは、GMPLSのために以前に指定された技術と区別するためにそれを必要とする新しい制約が追加されます。 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
このドキュメントの目的は、再利用することであり、可能な限りGMPLSプロトコルの限りで整列します。例えば、アドレッシングのIPコントロールプレーンを再利用する既存のシグナリング、ルーティング、リンクを可能にします
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.
管理プロトコル（LMP）、及び指定として使用する経路計算。 GMPLSプロトコルは、階層のLSPだけでなく、連続したLSPをサポートしています。また、GMPLSプロトコルメカニズムは、のUNIからの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
双方向LSP一致O
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
または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 VLAN内で動作していると一対一VLANの境界にマッピングされ、それぞれが複数のETH-のLSPから形成されます。ステッチ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ベースの制御メッセージから構成されています。同じ物理リンク上の専用VIDを使用する論理リンクは、インバンドシグナリングと考えられます。
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又は二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.
共有の転送は、単一の転送エントリ（VID +宛先MACアドレス）が、複数のソース（送信元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
CCM継続メッセージCFM接続障害管理DMACの宛先MACは、I-TAG I-TAG IEEE 802.1ahの規格[802.1ahの]で定義されたバックボーンサービスインスタンスタグで運ばれたI-SIDバックボーンサービス識別子をETH-LSPイーサネットラベルスイッチパスを住所チェックインNMSネットワーク管理システムOAM運用、管理、およびメンテナンスを対多LMPリンク管理プロトコルMACメディアアクセス制御MP2MPマルチポイント
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
PBBプロバイダーバックボーンブリッジ[802.1ahの] PBB-TEプロバイダーバックボーンブリッジトラフィックエンジニアリング[802.1Qay] P2Pポイントは、IEEE 802.1規格で定義されたS-TAGサービスタグサービスSMAC送信元MACアドレスのQoSの品質対多P2MPをポイントする[802.1 TAGのヘッダータグヘッダーQ] TEトラフィックエンジニアリングTAGアンイーサネットショートフォーム優先順位およびその他の情報TSpecのトラフィック仕様VID VLAN識別子VLAN仮想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）識別子（VIDの）とデスティネーションメディアアクセス制御（DMAC）住所：ブリッジリレーは、イーサネットヘッダフィールドに基づいてフレームを転送します。 PBB [802.1ahのは】また、サービスインスタンスタグ（I-TAG）を導入しました。すべてのイーサネット拡張（既に導入部で参照される）、複数の転送機能、またはサービス・インターフェースを横切って、のVID、のDMAC、およびI-TAGの組み合わせを使用して定義されています。 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]で定義されるイーサネットサービスはまた、新たにI-タグ付けされた定義を除いて（図1で定義されたタイプに分類しますサービスの種類）。
[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タグサービスタイプを定義するが、具体的には、また図1に示されている[MEF.6]のコンテキストと[G.8011]で定義されるイーサネットサービスを、定義していません。
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アドレスベースの切り替えなし。
o S-tagged
O Sタグ付き
There are multiple S-TAG-aware services, including:
：を含む複数のS-TAG対応のサービスがありますが、
+ one-to-one
+一対一
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
*多対1
In this frame-based service, multiple VIDs are mapped into the same service.
このフレームベースのサービスでは、複数のVIDが同じサービスにマッピングされます。
* all-to-one
*全対1
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-TAGは、サービス識別子（24ビットのI-SID）と優先マーキングだけでなく、いくつかの他のフィールドを含んでいます。 IタグサービスはPBBNのエッジとの間に、典型的には、サービスは、多くの場合、エッジを除いて表示されないように、顧客のポートと対向I成分上の各エッジで終端。 I成分リレーは異なるリレーを含むので、B成分のリレーからI成分リレーを分離することにより、可視Iタグサービスを有することが可能です。それがこれを行うには理にかなっている二つの例は、2 PBBNsの間、顧客のプロバイダインスタンスポートへの添付ファイルとして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とのDMAC、転送/スイッチング機能で使用されるイーサネットヘッダフィールドのかを決定します。スイッチングタイプは、追加のイーサネットヘッダまたはフィールドの使用を必要とし得ます。 UNIのために定義されたサービスは、サービス（サービスデリミタ）を要求するためのヘッダーを使用する傾向があり、顧客のサイトとネットワークエッジの間で関連しています。
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：テスト - 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クライアントデータのタイプは、典型的には、「イーサタイプ」の値によって識別されます。これは、明示的な型の表示ですが、イーサネットはまた、暗黙の型表示をサポートしています。
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制御プレーンは、データプレーンを制御し、その技術の特性を切り替えることにより、技術を適用することができます。 GMPLSアーキテクチャは、[RFC3945]あたり、イーサネット・ブリッジと種類を切り替えることが可能なレイヤ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:
GMPLS、即ち、アドレッシング、シグナリング、ルーティング、リンク管理の全ての態様は、イーサネットスイッチングに適用することができます。 GMPLSはトラフィックエンジニアリングおよび保護されたイーサネットサービスパスのコントロールを提供することができます。この文書では、用語「ETH-LSP」はGMPLSを介して制御されるイーサネットサービスのパスを参照するように定義します。すべての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の経路に沿って一定になり、そして他では、それらはホップホップによってのみパスに沿って特定のインターフェースに変化してもよいです。 「ラベル」はそのまま転送されなければならない場合には、このようなラムダラベルなどのいくつかの他の技術に類似しているラベル割り当てには、いくつかの制約があります。
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をチェックして、ブロードキャストイーサネットの学習をサポートしています。 VIDを効果的P2P転送制約をもたらすつのブリッジ上の2つだけのポートに定義されている場合、特殊なケースです。この場合には、その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.
スイッチングタイプとインターフェイススイッチング能力記述子を共有値の共通の組とは、べき（[RFC3471]）とすることができる（[RFC4202]、その切り替えのタイプの指標として[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.
説明のために、我々は、ルーティング、シグナリング、リンク管理、およびパス選択の機能にGMPLSを適用する問題を分解する。単独で、または部分的に組み合わせてGMPLSの一部の機能を使用することが可能です。ほとんどの場合、GMPLSのすべての機能を使用すると、部分的な組み合わせ未満運用オーバーヘッドにつながります。
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-LSPのためのGMPLS制御は[RFC3945]に記載されたルーティングおよびアドレス指定モデルを使用します。最も顕著なのは、これはIPの使用はインターフェイスとLSPエンドポイントを識別するためのアドレスを含みます。また、番号と無数の両方のインターフェースをサポートしています。
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
[RFC4202]で定義されるようにルーティングGMPLS情報をGMPLS関連TE（ルータとリンク）配信のために不透明なTLV拡張とIPルーティングプロトコルを使用します。常にGMPLSと同様に、TE情報は、LMPまたは構成情報から取得したリソース情報に基づいて移入されます。 ETH-のLSPが設定されているとして、リンクの帯域幅リソースが追跡されます。 ETH-LSPの切り替えをサポートするインタフェースは、適切なを使用して同定され
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.
インタフェーススイッチング機能（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ルーティングネットワークです。換言すれば、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.
（[RFC3471]及び[RFC3473]）をGMPLSシグナリングは、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,
GMPLSシグナリングは双方向と単方向データ経路の確立および制御をサポートします。イーサネットは本質的に双方向であるとCFMは、これを活用するために構築されています。 CFM前に、物理的な配線や学習の要件のエミュレーションも双方向接続を義務付け。このことを考えると、
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].
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の各方向に異なる帯域幅をサポートしていないことに留意されたいです。非対称な帯域幅の双方向のLSPが必要な場合、[RFC5467]、実験文書は、手順を提供します。
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上のイーサネットパラメータのシグナリングのサポートを可能にします。その意図は、ピア・ツー・ピアモデルは、UNI、およびNNIはのサポートのために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セキュリティフレームワーク[SECURITY]を参照してください。暗号化は、[SECURITY]に記載されている多くの攻撃から保護するために使用することができます。 「輸送」イーサネットを保護するための1つのオプションは、暗号化と認証を提供し802.1AEメディアアクセス制御のセキュリティ[802.1AE]、の使用です。ソリューションのドキュメントがどのプロトコルの拡張機能が導入したセキュリティ上の問題の完全な分析が含まれることが期待されます。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[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 802.1Q-2005、2006年5月 "仮想ブリッジローカルエリアネットワークのためのIEEE標準"。
[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]メトロ・イーサネット・フォーラムMEF 6、 "イーサネットサービスの定義 - フェーズI"、2004。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ラング、J.、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、「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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]バーガー、L.、タカーチ、A.、Caviglia、D.、Fedyk、D.、およびJ. Meuric、2009年3月、RFC 5467 "をGMPLS非対称帯域幅双方向ラベル（のLSP）パスの交換しました"。
[SECURITY] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SECURITY]牙、L.、エド。、 "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枠組み文書とPBB-TEの拡張文書は形を助け、この仕事を正当化する二つの文書でした。ディミトリPapadimitriou、Nurit Sprecher、Jaihyungチョー、デイブ・アラン、ピーターBusschbach、アッティラタカーチ、トーマス・エリクソン、ディエゴ・Caviglia、ヒマンシュシャー、グレッグSunderwood、アラン・マクガイア、およびナビルビタール：私たちは、これらの初期の文書の作者の作品を認めます。
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
ドン・ルブランアルカテル・ルーセント、グロトン、MA 01450電話：+ 1-978-467-5645 Eメール：donald.fedyk@alcatel-lucent.com
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、L.L.C.電話：+ 1-301-468-9228 Eメール：lberger@labn.net
Loa Andersson Ericsson Phone: +46 10 717 52 13 EMail: loa.andersson@ericsson.com
Andersnエリクソンの携帯電話で：+46 10 717 52 13 Eメール：loandersneriksankam