[要約] RFC 6060は、Ethernet Provider Backbone Traffic Engineering (PBB-TE)のGMPLS制御に関する標準です。このRFCの目的は、PBB-TEネットワークでのGMPLS制御の仕組みを提供し、効率的なトラフィックエンジニアリングを実現することです。
Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 6060 Alcatel-Lucent
Category: Standards Track H. Shah
ISSN: 2070-1721 Ciena
N. Bitar
Verizon
A. Takacs
Ericsson
March 2011
Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
一般化されたマルチプロトコルラベルスイッチング（GMPLS）イーサネットプロバイダーバックボーントラフィックエンジニアリング（PBB-TE）の制御
Abstract
概要
This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane.
この仕様は、GMPLSイーサネットラベルスイッチングアーキテクチャとフレームワークを補完し、プロバイダーバックボーンブリッジトラフィックエンジニアリング（PBB-TE）のGMPLS制御の技術固有の側面を説明しています。必要なGMPLS拡張とメカニズムは、イーサネットPBB-TEポイントツーポイント（P2P）およびポイントツーマルチポイント（P2MP）接続を確立するために説明されています。このドキュメントは、標準のIEEEデータプレーンをサポートしますが、変更しません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6060.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6060で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Co-Authors .................................................3
2. Terminology .....................................................4
2.1. PBB-TE and GMPLS Terminology ...............................5
2.2. Conventions Used in This Document ..........................6
3. Creation and Maintenance of PBB-TE Paths Using GMPLS ............6
3.1. Shared Forwarding ..........................................9
3.2. P2P Connections Procedures for Shared Forwarding ..........10
4. Specific Procedures ............................................10
4.1. P2P Ethernet LSPs .........................................10
4.1.1. P2P Path Maintenance ...............................11
4.2. P2MP Ethernet-LSPs ........................................12
4.3. PBB-TE Ethernet Label .....................................12
4.4. Protection Paths ..........................................13
4.5. Service Instance Identification ...........................13
5. Error Conditions ...............................................15
5.1. ESP-VID-Related Errors ....................................15
5.1.1. Invalid ESP-VID Value in the PBB-TE
Ethernet Label .....................................15
5.1.2. Allocated ESP-VID Range is Exhausted ...............16
5.2. Invalid MAC Address .......................................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................19
9. Acknowledgments ................................................19
The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE802.1Qay] standard supports the establishment of explicitly routed traffic engineered paths within Provider Backbone Bridged (PBB) networks. PBB-TE allows the disabling of:
IEEE 802.1プロバイダーバックボーンブリッジトラフィックエンジニアリング（PBB-TE）[IEEE802.1QAY]標準は、プロバイダーバックボーンブリッジ（PBB）ネットワーク内の明示的にルーティングされたトラフィックエンジニアリングパスの確立をサポートしています。PBB-TEは、次のことを無効にします
- the Spanning Tree Protocol - unknown destination address forwarding - source address learning
- スパニングツリープロトコル - 不明な宛先アドレス転送 - ソースアドレス学習
for administratively selected VLAN Identifiers. With PBB-TE an external provisioning system or control plane can be used to configure static entries in the managed objects of bridges and so establish traffic engineered paths in the network.
管理上選択されたVLAN識別子用。PBB-TEを使用すると、外部プロビジョニングシステムまたは制御プレーンを使用して、ブリッジの管理されたオブジェクトに静的エントリを構成し、ネットワーク内のトラフィックエンジニアリングパスを確立できます。
Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including L2SC networks (Layer 2 Switching Capable). The purpose of this document is to specify extensions for a GMPLS-based control plane to manage PBB-TE explicitly routed traffic engineered paths. This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework document [RFC5828].
Generalized MPLS（GMPLS）[RFC3945]は、接続志向および交通工学の輸送ネットワークで動作するように設計された制御プレーンプロトコルのファミリーです。GMPLSは、L2SCネットワークを含むさまざまなネットワークテクノロジーに適用できます（レイヤー2スイッチング対応）。このドキュメントの目的は、GMPLSベースのコントロールプレーンの拡張機能を指定して、PBB-TEが明示的にルーティングされたトラフィックエンジニアリングパスを管理することです。この仕様は、GMPLSイーサネットラベルスイッチングアーキテクチャおよびフレームワークドキュメント[RFC5828]を補完します。
This document is the result of a large team of authors and contributors. The following is a list of the co-authors:
この文書は、著者と貢献者の大規模なチームの結果です。以下は、共著者のリストです。
David Allan Ericsson EMail: david.i.allan@ericsson.com
David Allan Ericssonメール：David.i.allan@ericsson.com
Diego Caviglia Ericsson Via Negrone 1/A Genoa, Italy 16153 EMail: diego.caviglia@ericsson.com
ディエゴ・カビリア・エリクソンはネグロン1/Aジェノヴァ、イタリア16153メールでメール：diego.caviglia@ericsson.com
Alan McGuire BT Group PLC OP6 Polaris House, Adastral Park, Martlesham Heath, Ipswich, Suffolk, IP5 3RE, UK EMail: alan.mcguire@bt.com Nurit Sprecher Nokia Siemens Networks, GmbH & Co. KG COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel EMail: nurit.sprecher@nsn.com
Alan McGuire BT Group PLC OP6 Polaris House、Adastral Park、Martlesham Heath、Ipswich、Suffolk、IP5 3RE、UKメール：alan.mcguire@bt.com nurit Sprecher nokia siemens Networks、Gmbh＆Co. kg coo rtp ie sixed 3 Hanagar St。NeveNe'emanB、45241 Hod Hasharon、Israel Email：nurit.sprecher@nsn.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
In addition to well-understood GMPLS terms, this memo uses the following terminology from IEEE 802.1 [IEEE802.1ah] [IEEE802.1Qay]:
よく理解されているGMPLS用語に加えて、このメモはIEEE 802.1 [IEEE802.1AH] [IEEE802.1QAY]の次の用語を使用しています。
- BCB Backbone Core Bridge - BEB Backbone Edge Bridge - B-MAC Backbone MAC - B-VID Backbone VLAN ID - B-VLAN Backbone VLAN - CBP Customer Backbone Port - CCM Continuity Check Message - CNP Customer Network Port - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - ESP Ethernet Switched Path - ESP-MAC SA ESP Source MAC Address - ESP-MAC DA ESP Destination MAC Address - ESP-VID ESP VLAN ID - Eth-LSP Ethernet Label Switched Path - IB-BEB A BEB comprised of both I- and B-components - I-SID Ethernet Service Instance Identifier - TAG An Ethernet Header Field with Type and Values - MAC Media Access Control - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - PNP Provider Network Port - PS Protection Switching - P2P Point-to-Point - P2MP Point-to-Multipoint - SVL Shared VLAN Learning
- BCBバックボーンコアブリッジ-BEBバックボーンエッジブリッジ-B -MACバックボーンMAC -B -VIDバックボーンVLAN ID -B -VLANバックボーンVLAN -CBPカスタマーバックボーンポート-CCM継続性チェックメッセージ-CNPカスタマーネットワークポート-C -MACカスタマーMAC-c -vidカスタマーVLAN ID -c -vlanカスタマーVLAN -espイーサネットスイッチ付きパス-ESP -MAC SA ESPソースMACアドレス-ESP -MAC DA ESP Destination Macアドレス-ESP -VID ESP VLAN ID -ETH -LSPイーサネットラベルスイッチ付きパス-IB -BEB A BEBは、I-およびBコンポーネントとBコンポーネントの両方で構成されています-I -SIDイーサネットサービスインスタンス識別子 - タイプと値を持つイーサネットヘッダーフィールドにタグ-MACメディアアクセス制御-PBBプロバイダーバックボーンブリッジ-PBB -TEプロバイダーバックボーンブリッジトラフィックエンジニアリング - PIPプロバイダーインスタンスポート-PNPプロバイダーネットワークポート-PS保護スイッチング-P2Pポイントツーポイント-P2MPポイントツーマルチポイント-SVL共有VLAN学習
- TESI Traffic Engineering Service Instance - VID VLAN ID - VIP Virtual Instance Port - VLAN Virtual LAN
- Tesi Traffic Engineering Serviceインスタンス-VID VLAN ID -VIP仮想インスタンスポート-VLAN仮想LAN
The PBB-TE specification [IEEE802.1Qay] defines some additional terminology to clarify the PBB-TE functions. We repeat these here in expanded context to translate from IEEE to GMPLS terminology. The terms "bridge" and "switch" are used interchangeably in this document. The signaling extensions described here apply equally well to a PBB-TE-capable bridge supporting GMPLS signaling or to a GMPLS-capable switch supporting Ethernet PBB-TE forwarding.
PBB-TE仕様[IEEE802.1QAY]は、PBB-TE関数を明確にするためのいくつかの追加の用語を定義します。ここでは、IEEEからGMPLS用語に翻訳するために、拡張されたコンテキストでこれらを繰り返します。このドキュメントでは、「ブリッジ」と「スイッチ」という用語が同じ意味で使用されます。ここで説明するシグナル伝達拡張は、GMPLSシグナリングをサポートするPBB-TE対応ブリッジまたはイーサネットPBB-TE転送をサポートするGMPLS対応スイッチに等しく適用します。
- Ethernet Switched Path (ESP):
- イーサネットの切り替えパス（ESP）：
A provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) that extends over a Provider Backbone Bridge Network (PBBN). The path is identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID>. An ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP is analogous to a (unidirectional) point-to-point or point-to-multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS established ESPs.
プロバイダーのバックボーンブリッジネットワーク（PBBN）に拡張される2つ以上の顧客バックボーンポート（CBP）間のプロビジョニングされたトラフィックエンジニアリングユニディレクション接続パス。パスは、3タプル<esp-mac da、esp-mac sa、esp-vid>によって識別されます。ESPは、ポイントツーポイント（P2P）またはポイントツーマルチポイント（P2MP）です。ESPは、（単方向の）ポイントツーポイントまたはポイントツーマルチポイントLSPに類似しています。ESPSを確立したGMPLSには、Ethernet-LSP（ETH-LSP）という用語を使用します。
- Point-to-Point ESP:
- ポイントツーポイントESP：
An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 3-tuple identifier are the individual MAC addresses of the two CBPs.
2つのCBPの間のESP。ESPの3タプル識別子のESP-DAとESP-SAは、2つのCBPの個々のMACアドレスです。
- Point-to-Multipoint ESP:
- ポイントツーマルチポイントESP：
An ESP among one root CBP and n leaf CBPs. The ESP-DA in the ESP's 3-tuple identifier is a group MAC address identifying the n leaf CBPs, and the ESP-SA is the individual MAC address of the root.
1つのルートCBPおよびNリーフCBPの中のESP。ESPの3タプル識別子のESP-DAは、NリーフCBPを識別するグループMACアドレスであり、ESP-SAはルートの個々のMACアドレスです。
- Point-to-Point PBB-TE Service Instance (P2P TESI):
- ポイントツーポイントPBB-TEサービスインスタンス（P2P TESI）：
A service instance supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. The two unidirectional ESPs are forming a bidirectional service. The PBB-TE standard [IEEE802.1Qay] notes the following: for reasons relating to TE service monitoring diagnostics, operational simplicity, etc., the IEEE PBB-TE standard assumes that the point-to-point ESPs associated with a point-to-point TESI are co-routed. Support for a point-to-point TE services that comprises non-co-routed ESPs is problematic, and is not defined in this standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P TE Service Instance. We use the term "bidirectional Ethernet-LSP" for GMPLS-established P2P PBB-TE Service Instances.
ESPSのエンドポイントが同じCBP MACアドレスを持っている2つのポイントツーポイントESPによってサポートされるサービスインスタンス。2つの単方向ESPは、双方向サービスを形成しています。PBB-TE標準[IEEE802.1QAY]は、次のように注目しています。TEサービス監視診断、運用のシンプルさなどに関連する理由で、IEEE PBB-TE標準は、ポイントツーポイントに関連するポイントツーポイントESPが想定しています。-point tesiは共同ルーティングされています。非COでルーティングされたESPを含むポイントツーポイントTEサービスのサポートには問題があり、この標準では定義されていません。したがって、GMPLS双方向LSPは、P2P TEサービスインスタンスに類似しています。GMPLSが確立したP2P PBB-TEサービスインスタンスに「双方向イーサネットLSP」という用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
IEEE PBB-TE is a connection-oriented Ethernet technology. PBB-TE ESPs are created bridge by bridge (or switch by switch) by simple configuration of Ethernet forwarding entries. This document describes the use of GMPLS as a valid control plane for the setup, teardown, protection, and recovery of ESPs and TESIs and specifies the required RSVP-TE extensions for the control of PBB-TE Service Instances.
IEEE PBB-TEは、接続指向のイーサネットテクノロジーです。PBB-TE ESPは、イーサネット転送エントリの単純な構成によってブリッジ別（またはスイッチごとにスイッチ）によって作成されます。このドキュメントでは、GMPLSの使用をセットアップ、分解、保護、およびESPSおよびTESISの回復に有効な制御プレーンとして説明し、PBB-TEサービスインスタンスの制御に必要なRSVP-TE拡張機能を指定します。
PBB-TE ESP and services are always originated and terminated on IB-Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B components, this is illustrated in Figure 1. A B-component refers to the structure and mechanisms that support the relaying of frames identified by Backbone VLANs in a Provider Backbone Bridge. An I-component refers to the structure and mechanisms that support the relaying of frames identified by service instances (I-SIDs) in a Provider Backbone Bridge. PBB and PBB-TE relay frames with added I-Component TAGs in the I-component and VLAN TAGs in the B-component. PBB and PBB-TE forward frames based on VLAN ID in the VLAN TAG (in the PBB case a B-VID) until the destination MAC address is supported locally by a B-component on this bridge indicating the destination has been reached. At that point, the B-VLAN tag is removed and processing or forwarding on the next TAG begins (in the PBB case an I-Component TAG) until the I-component identified by the I-SID is reached. At the I-component, the I-Component TAG is removed and the next Ethernet type identifies the TAG, etc.
PBB-TE ESPおよびサービスは、常にIBバックボーンエッジブリッジ（IB-BEBS）で発信され、終了します。IBベブはIおよびB成分で構成されています。これは図1に示されています。B成分は、プロバイダーバックボーンブリッジのバックボーンVLANによって識別されるフレームの中継をサポートする構造とメカニズムを指します。Iコンポーネントとは、プロバイダーバックボーンブリッジのサービスインスタンス（I-SID）によって識別されたフレームの中継をサポートする構造とメカニズムを指します。IコンポーネントにIコンポーネントタグが追加されたPBBおよびPBB-TEリレーフレームは、BコンポーネントのVLANタグを備えています。VLANタグのVLAN IDに基づくPBBおよびPBB-TEフォワードフレーム（PBBケースA B-VID）は、宛先MACアドレスがこのブリッジのBコンポーネントによってローカルでサポートされるまで、目的地に到達したことを示しています。その時点で、B-VLANタグが削除され、次のタグでの処理または転送が（PBBの場合）i-SIDによって識別されるI成分に到達するまで開始されます（Iコンポーネントタグ）。iコンポーネントでは、i-componentタグが削除され、次のイーサネットタイプがタグなどを識別します。
An Ethernet service supported by a PBB-TE TESI is always attached to a Customer Network Port (CNP) of the I-component. A Service Instance Identifier (I-SID) is assigned for the service. I-SIDs are only looked at by source and destination (edge) bridges, so I-SIDs are transparent to path operations and MAY be signaled. The I- and B-components have internal ports that are connected via an internal LAN. These internal ports are the Provider Instance Ports (PIPs) and Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside the IB-BEB. ESPs are always originated and terminated on CBP ports and use the MAC address of that port. The I-component encapsulates the service frames arriving from the CNP by adding an I-SID and a complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The B-component adds the ESP-VID.
PBB-TETESIによってサポートされているイーサネットサービスは、常にiコンポーネントの顧客ネットワークポート（CNP）に接続されます。サービスにサービスインスタンス識別子（I-SID）が割り当てられます。I-SIDは、ソースと宛先（エッジ）ブリッジのみで見られるため、I-SIDはパス操作に対して透明であり、シグナルを受ける可能性があります。IおよびBコンポーネントには、内部LANを介して接続された内部ポートがあります。これらの内部ポートは、プロバイダーインスタンスポート（PIPS）と顧客バックボーンポート（CBPS）です。PIPSとCBPはIBベブの外には見えません。ESPは常にCBPポートで発信および終了され、そのポートのMACアドレスを使用します。Iコンポーネントは、ESP-MAC DAとESP-MAC SAを備えたI-SIDと完全なイーサネットMACヘッダーを追加することにより、CNPから到着するサービスフレームをカプセル化します。B成分はESP-VIDを追加します。
This document defines extensions to GMPLS to establish ESPs and TESIs. As can be seen from the above, this requires configuration of both the I- and B-components of the IB-BEBs connected by the ESPs.
このドキュメントでは、拡張機能をGMPLSに定義して、ESPとテーシスを確立します。上記からわかるように、これにはESPで接続されたIBベブのib-bebsの両方の構成が必要です。
In the GMPLS control plane, TE Router IDs are used to identify the IB-BEBs and Backbone Core Bridges (BCBs), and TE Links describe links connected to PNPs and CNPs. TE Links are not associated with CBPs or PIPs.
GMPLSコントロールプレーンでは、TEルーターIDを使用してIBベブスとバックボーンコアブリッジ（BCB）を識別し、TEリンクはPNPとCNPに接続されたリンクを説明します。TEリンクは、CBPやPIPSに関連付けられていません。
Note that since multiple internal CBPs may exist, an IB-BEB receiving a PATH message MUST be able to determine the appropriate CBP that is the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD advertise the CNP TE Links in the GMPLS control plane and RSVP-TE signaling SHOULD use the CNP TE Links to identify the termination point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP. In the case that there is more than one suitable CBP, and no I-SID information is provided in the PATH message or previously in the associated Call setup, then the IB-BEB can decide freely which CBP to assign to the requested connection. On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and associated CBP is configured with the I-SID and MUST assign that CBP to the ESP.
複数の内部CBPが存在する可能性があるため、パスメッセージを受信するIBベブは、ETH-LSPの終了点である適切なCBPを決定できる必要があることに注意してください。この目的のために、IB-BEBSはGMPLSコントロールプレーンのCNP TEリンクを宣伝する必要があり、RSVP-TEシグナルはCNP TEリンクを使用してETH-LSPの終了点を識別する必要があります。CNPのいずれかを指定するパスメッセージを受信するIBベブは、特定のCNPをサポートするIコンポーネントへの内部接続を局所的に決定できます。適切なCBPが複数ある場合、パスメッセージまたは以前に関連するコールセットアップでI-SID情報が提供されていない場合、IB-BEBは要求された接続に割り当てるためにどのCBPを割り当てるかを自由に決定できます。一方、指定されたESPがサポートするサービス（I-SID）がある場合、IB-BEBは最初にどのPIPと関連するCBPがI-SIDで構成され、そのCBPをに割り当てる必要があります。esp。
Backbone Edge Bridge (BEB)
+------------------------------------------------------+
| <TE - Router ID > |
| |
| I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|CBP| |PNP|------
| | | | | +---+ +---+ | |
| | +---+ +---+ | | | | |
------|CNP| |PIP|----+ | | |
| | +---+ +---+ | | | |
| +-----------------------+ +---------------------+ |
| |
| PBB Edge Bridge |
+------------------------------------------------------+
^--------Configured--------------^
^-----------GMPLS or Configured------^
Figure 1: IB-BEBs and GMPLS Identifiers
図1：IB-BEBSおよびGMPLS識別子
Control TE Router ID TE Router ID
Plane | (TE Link) |
V | V
+----+ | +-----+
Data | | | | |
Plane | | V label=ESP:VID/MAC DA | |
-----N N----------------------------N N----------
| | PBB-TE | | \ Network
| | / | Or
+----+ /+-----+ Customer
BCB ESP:MAC IB-BEB Facing
Ethernet
Ports
Figure 2: Ethernet/GMPLS Addressing and Label Space
図2：イーサネット/GMPLSアドレス指定とラベルスペース
PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection identifier in the data plane, but the forwarding operation only uses the ESP-MAC DA and the ESP-VID in each direction. The ESP-VID typically comes from a small number of VIDs dedicated to PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement that ESP-VIDs for two ESPs that form a P2P TESI be the same.
PBB-TEは、<esp-mac da、esp-mac sa、esp-vid>のタプルをデータプレーンの一意の接続識別子として定義しますが、転送操作はそれぞれのesp-mac daとesp-vidのみを使用します。方向。ESP-VIDは通常、PBB-TE専用の少数のビデオから来ています。ESP-VIDはESPで再利用できます。p2p tesiを形成する2つのESPのESP-vidが同じであるという要件はありません。
When configuring an ESP with GMPLS, the ESP-MAC DA and ESP-VID are carried in a generalized label object and are assigned hop by hop, but are invariant within a domain. This invariance is similar to GMPLS operation in transparent optical networks. As is typical with other technologies controlled by GMPLS, the data plane receiver MUST accept, and usually assigns, labels from its available label pool. This, together with the label invariance requirement mentioned above, result in each PBB-TE Ethernet Label being a domain-wide unique label, with a unique ESP-VID + ESP-MAC DA, for each direction.
GMPLSでESPを構成する場合、ESP-MAC DAとESP-VIDは一般化されたラベルオブジェクトで運ばれ、ホップによってホップが割り当てられますが、ドメイン内で不変です。この不変性は、透明な光学ネットワークでのGMPLS動作に似ています。GMPLSによって制御される他のテクノロジーと典型的なように、データプレーンレシーバーは、利用可能なラベルプールからラベルを受け入れ、通常は割り当てなければなりません。これは、上記のラベル不変性要件とともに、各方向に対してユニークなESP-VID ESP-MAC DAを備えた各PBB-TEイーサネットラベルがドメイン全体のユニークなラベルであることになります。
The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P TESI.
以下は、P2P TesiのPBB-TEイーサネットラベルとESPを示しています。
GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
Table 1: Labels and ESPs
表1：ラベルとESP
One capability of a connectionless Ethernet data plane is to reuse destination forwarding entries for packets from any source within a VLAN to a destination. When setting up P2P PBB-TE connections for multiple sources sharing a common destination, this capability MAY be preserved provided certain requirements are met. We refer to this capability as "shared forwarding". Shared forwarding is invoked based on policy when conditions are met. It is a local decision by label allocation at each end plus the path constraints. Shared forwarding has no impact on the actual paths that are set up, but it allows the reduction of forwarding entries. Shared forwarding paths are identical in function to independently routed paths that share a path from an intersecting bridge or link except they share a single forwarding entry.
コネクションレスイーサネットデータプレーンの1つの機能は、VLAN内の任意のソースから宛先までのパケットの宛先転送エントリを再利用することです。共通の目的地を共有する複数のソースのP2P PBB-TE接続をセットアップする場合、特定の要件が満たされている場合、この機能は保存される場合があります。この機能を「共有転送」と呼びます。条件が満たされた場合、共有転送はポリシーに基づいて呼び出されます。これは、各端でのラベル割り当てとパスの制約によるローカルな決定です。共有転送は、設定されている実際のパスには影響しませんが、転送エントリの削減を可能にします。共有された転送パスは、単一の転送エントリを共有している場合を除き、交差するブリッジまたはリンクからパスを共有する独立したルーティングパスと機能が同一です。
The forwarding memory savings from shared forwarding can be quite dramatic in some topologies where a high degree of meshing is required; however, it is typically easier to achieve when the connectivity is known in advance. Normally, the originating GMPLS switch will not have knowledge of the set of shared forwarding paths rooted on the source or destination switch.
共有された転送による転送メモリの節約は、高度なメッシュが必要ないくつかのトポロジでは非常に劇的なものです。ただし、通常、接続性が事前にわかっている場合に達成する方が簡単です。通常、発信元のGMPLSスイッチには、ソースまたは宛先スイッチに根付いた共有転送パスのセットに関する知識がありません。
Use of a Path Computation Element [RFC4655] or other planning style of tool with more complete knowledge of the network configuration is a way to impose pre-selection of shared forwarding with multiple paths using a single forwarding entry and optimizing for both directions. In this scenario, the originating bridge uses the LABEL_SET and UPSTREAM_LABEL objects to indicate the selection of the shared forwarding labels at both ends.
パス計算要素[RFC4655]またはネットワーク構成のより完全な知識を持つ他の計画スタイルのツールの使用は、単一の転送エントリを使用して両方方向に最適化する複数のパスで共有転送の事前選択を課す方法です。このシナリオでは、起源のブリッジでは、label_setとupstream_labelオブジェクトを使用して、両端で共有転送ラベルの選択を示します。
The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding identifier or label consisting of some number of P2P connections distinctly identified by the <ESP-MAC DA, ESP-MAC SA, ESP-VID> tuple. This is analogous to an LDP label merge, but in the shared forwarding case, the ESP header contains sufficient information to identify the flow to which a packet belongs. Resources can continue to be allocated per LSP with shared forwarding.
esp-vid/esp-mac daは、<esp-mac da、esp-mac sa、esp-vid> tupleによって明確に識別されるいくつかのp2p接続で構成される共有転送識別子またはラベルと見なすことができます。これはLDPラベルマージに類似していますが、共有された転送ケースでは、ESPヘッダーにはパケットが属するフローを識別するのに十分な情報が含まれています。リソースは、共有転送でLSPごとに引き続き割り当てられます。
VLAN-tagged Ethernet packets include priority marking. Priority bits MAY be used to indicate Class of Service (COS) and drop priority. Thus, traffic from multiple COSs could be multiplexed on the same Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are made based on the p-bits. This means that the queue selection can be done based on a per-flow basis (i.e., Eth-LSP + priority) and is decoupled from the actual steering of the packet at any given bridge.
VLANタグ付きイーサネットパケットには、優先マーキングが含まれます。優先ビットを使用して、サービスのクラス（COS）を示し、優先度を落とすことができます。したがって、複数のコスからのトラフィックは、同じETH-LSP（つまり、E-LSPと同様）で多重化される可能性があり、キューとドロップの決定はPビットに基づいて行われます。つまり、キューの選択は、流量ごと（つまり、ETH-LSPの優先度）に基づいて実行でき、特定のブリッジのパケットの実際のステアリングから分離されることを意味します。
A bridge terminating an Eth-LSP will frequently have more than one suitable candidate for sharing a forwarding entry (common ESP-VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how this is performed but a good choice is a path that reduces the requirement for new forwarding entries by reusing common existing paths.
ETH-LSPを終了するブリッジには、転送エントリを共有するのに適した候補が複数あることがよくあります（一般的なESP-VID/ESP-MAC DA、ユニークなESP-MAC SA）。これはこれがどのように実行されるかの地域の決定ですが、良い選択は、一般的な既存のパスを再利用することにより、新しい転送エントリの要件を減らすパスです。
The concept of bandwidth management still applies equally well with shared forwarding.
帯域幅管理の概念は、共有された転送にも同様に適切に適用されます。
PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In this section, we discuss the establishment of bidirectional Eth-LSPs.
PBB-TEは、双方向であり、イーサネットと同じように対称的にルーティングされるように設計されています。つまり、イーサネットプロトコルの完全かつ適切な機能は、双方向のETH-LSPに対してのみ保証されています。このセクションでは、双方向のETH-LSPの確立について説明します。
Note, however, that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message.
ただし、upstream_labelがパスメッセージに含まれていない場合、RSVP-TEを使用して単方向ESPを構成することも可能であることに注意してください。
To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics:
双方向のETH-LSPを開始するには、パスメッセージの開始者は、次の詳細を使用して[RFC3473]で概説されている手順を使用する必要があります。
1) it MUST set the LSP encoding type to Ethernet (2) [RFC3471].
1) LSPエンコードタイプをイーサネット（2）[RFC3471]に設定する必要があります。
2) it MUST set the LSP switching type to "802_1 PBB-TE", value 40.
2) LSPスイッチングタイプを「802_1 PBB-TE」、値40に設定する必要があります。
3) it SHOULD set the Generalized Payload Identifier (G-PID) to Ethernet (33) [RFC3471].
3) 一般化されたペイロード識別子（G-PID）をイーサネット（33）[RFC3471]に設定する必要があります。
4) it MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the ESP-VID1 is administered locally for the local MAC address: MAC1.
4) UpStream_LabelをESP-VID1/ESP-MAC1タプルに設定する必要があります。ESP-VID1は、ローカルMACアドレスのローカルでローカルに管理されます：Mac1。
5) it SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA.
5) ESP-VID/ESP-MAC DAの選択に影響を与えることを選択した場合、label_setまたはprossismed_labelを設定する必要があります。
6) it MAY carry an I-SID via Call/Connection ID [RFC4974].
6) Call/Connection ID [RFC4974]を介してI-SIDを運ぶ場合があります。
Intermediate and egress bridge processing is not modified by this document, i.e., is per [RFC3473]. However, as previously stated, intermediate bridges supporting the 802_1 PBB-TE switching type MUST NOT modify LABEL values.
中間および出口ブリッジ処理は、このドキュメントによって変更されていません。つまり、[RFC3473]ごとです。ただし、前述のように、802_1 PBB-TEスイッチングタイプをサポートする中間ブリッジは、ラベル値を変更してはなりません。
The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is inferred from the switching type, which is 802_1 PBB-TE. The port derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1 included in the PBB-TE Ethernet Label constitute the static entry.
upstream_labelに含まれるESP-VID1/ESP-MAC1タプルは、各ホップのブリッジのフィルタリングデータベースに静的転送エントリを作成して、上流方向に向けます。この動作は、802_1 PBB-TEであるスイッチングタイプから推測されます。RSVP_HOPオブジェクトとPBB-TEイーサネットラベルに含まれるESP-VID1およびESP-MAC1から派生したポートは、静的エントリを構成します。
At the destination, an ESP-VID (ESP-VID2) is allocated for the local MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message. As with the PATH message, intermediate bridge processing is per [RFC3473], and the LABEL object MUST be passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the LABEL object is installed in the forwarding table as a static forwarding entry at each hop. This creates a bidirectional Eth-LSP as the PATH and RESV messages follow the same path.
目的地では、ESP-VID（ESP-VID2）がローカルMACアドレスに割り当てられます：MAC2、ESP-VID2/ESP-MAC2タプルはRESVメッセージのラベルオブジェクトに渡されます。パスメッセージと同様に、中間ブリッジ処理は[RFC3473]ごとに行われ、ラベルオブジェクトは変更されていない上流に渡す必要があります。ラベルオブジェクトに含まれるESP-VID2/ESP-MAC2タプルは、各ホップの静的転送エントリとして転送テーブルにインストールされます。これにより、パスとRESVメッセージが同じパスに従うと、双方向のETH-LSPが作成されます。
Make-before-break procedures can be employed to modify the characteristics of a P2P Eth-LSP. As described in [RFC3209], the LSP ID in the sender template is updated as the new path is signaled. The procedures (including those for shared forwarding) are identical to those employed in establishing a new LSP, with the extended tunnel ID in the signaling exchange ensuring that double booking of an associated resource does not occur.
ブレイク前の手順を使用して、P2P ETH-LSPの特性を変更できます。[RFC3209]で説明されているように、送信者テンプレートのLSP IDは、新しいパスがシグナルになると更新されます。手順（共有転送用の手順を含む）は、新しいLSPの確立に採用された手順と同じであり、シグナリング交換の拡張トンネルIDは、関連するリソースの二重予約が発生しないことを保証します。
Where individual paths in a protection group are modified, signaling procedures MAY be combined with Protection Switching (PS) coordination to administratively force PS operations such that modification is only ever performed on the protection path. PS is a native capability of PBB-TE [IEEE802.1Qay] that can operate when two paths are set up between two common endpoints.
保護グループ内の個々のパスが変更されている場合、シグナル伝達手順は、保護パスでのみ修正が実行されるように、管理上のPS操作に対する保護スイッチング（PS）調整と組み合わせることができます。PSは、2つの一般的なエンドポイントの間に2つのパスが設定されている場合に動作できるPBB-TE [IEEE802.1QAY]のネイティブ機能です。
PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this case, the PBB-TE Ethernet Label consists of a VID and a Group MAC address. The procedures outlined in [RFC3473] and [RFC4875] could be adapted to signal P2MP LSPs for the source (point) to destination (multipoint) direction. Each one of the branches of the P2MP Eth-LSP would be associated with a reverse-path symmetric and congruent P2P Eth-LSP.
PBB-TEは、P2MP VID/マルチキャストMAC（MMAC）転送をサポートしています。この場合、PBB-TEイーサネットラベルは、VIDとグループMACアドレスで構成されています。[RFC3473]および[RFC4875]で概説されている手順は、ソース（ポイント）のP2MP LSPSを宛先（マルチポイント）方向に合図するように適合させることができます。P2MP ETH-LSPの各分岐は、逆パス対称P2P ETH-LSPに関連付けられています。
Complete procedures for signaling bidirectional P2MP E-LSPs are out of scope for this document.
このドキュメントの双方向P2MP E-LSPをシグナル伝達するための完全な手順は範囲外です。
The PBB-TE Ethernet Label is a new generalized label with the following format:
PBB-TEイーサネットラベルは、次の形式を備えた新しい一般化ラベルです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PBB-TE Ethernet Label
図3：PBB-TEイーサネットラベル
This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-LSPs, the fields specify a VID and a unicast MAC address; whereas, for P2MP Eth-LSPs, a VID and a group MAC address is carried in the label. The PBB-TE Ethernet Label is a domain-wide unique label and MUST be passed unchanged at each hop. This has similarity to the way in which a wavelength label is handled at an intermediate bridge that cannot perform wavelength conversion, and is described in [RFC3473].
この形式は、P2PとP2MP ETH-LSPの両方に使用する必要があります。P2P ETH-LSPの場合、フィールドはVIDおよびUnicast MACアドレスを指定します。一方、P2MP ETH-LSPの場合、VIDおよびグループMACアドレスがラベルに掲載されています。PBB-TEイーサネットラベルは、ドメイン全体のユニークなラベルであり、各ホップで変更されずに渡す必要があります。これは、波長変換を実行できない中間ブリッジで波長ラベルを処理する方法と類似しており、[RFC3473]で説明されています。
When protection is used for path recovery, it is required to associate the working and protection paths into a protection group. This is achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION and PROTECTION objects.
パスの回復に保護が使用される場合、作業および保護パスを保護グループに関連付ける必要があります。これは、関連性と保護オブジェクトを使用して[RFC4872]および[RFC4873]で定義されているように達成されます。
The I-SID is used to uniquely identify services within the network. Unambiguous identification is achieved by ensuring global uniqueness of the I-SIDs within the network or at least between any pair of edge bridges. On IB-BEBs, the Backbone Service Instance Table is used to configure the mapping between I-SIDs and ESPs. This configuration can be either manual or semi-automated by signaling described here.
I-SIDは、ネットワーク内のサービスを一意に識別するために使用されます。ネットワーク内または少なくともエッジブリッジのペア間でI-SIDのグローバルな一意性を確保することにより、明確な識別が達成されます。IBベブでは、Backbone Service Instanceテーブルを使用して、I-SIDとESP間のマッピングを構成します。この構成は、ここで説明するシグナリングによって手動であるか、半自動化することができます。
RSVP-TE Signaling MAY be used to automate I-SID to ESP mapping. By relying on signaling, it is ensured that the same I-SID is assigned to the service and mapped to the same ESP. Note, by signaling the I-SID associated to the ESP, one can ensure that IB-BEBs select the appropriate CBP port.
RSVP-TEシグナル伝達は、I-SIDからESPマッピングを自動化するために使用できます。シグナリングに依存することにより、同じI-SIDがサービスに割り当てられ、同じESPにマッピングされることが保証されます。ESPに関連付けられたI-SIDを信号することにより、IB-BEBが適切なCBPポートを選択することを確認できます。
CALL signaling [RFC4974] MAY be used to create an association between the Eth-LSP endpoints prior to establishment of the LSP. The CALL_ATTRIBUTES object can be used during CALL signaling, as described in [RFC4974], to indicate properties of the CALL. The Service ID TLV, defined below, can be carried in the CALL_ATTRIBUTES object to indicate the I-SID to ESP mapping for the Eth-LSP that will be set up in association with the CALL.
コールシグナル伝達[RFC4974]を使用して、LSPを確立する前にETH-LSPエンドポイント間の関連を作成できます。[rfc4974]で説明されているように、コールシグナリング中にcall_attributesオブジェクトを使用して、コールのプロパティを示すことができます。以下に定義されているサービスID TLVは、CALL_ATTRIBUTESオブジェクトに携帯して、コールに関連して設定されるETH-LSPのI-SIDからESPマッピングを示すことができます。
Alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID association using the Service ID TLV in the LSP_ATTRIBUTES object [RFC5420] at the time of Eth-LSP signaling. Using this mechanism, it is possible to create the I-SID association, either when the path is set up or at a later time using a PATH refresh.
あるいは、GMPLS RSVP-TEパスメッセージは、ETH-LSPシグナル伝達時にLSP_ATTRIBUTESオブジェクト[RFC5420]のサービスID TLVを使用してI-SID Associationを運ぶことができます。このメカニズムを使用して、パスがセットアップされているとき、またはパスリフレッシュを使用して後で使用するときに、I-SIDアソシエーションを作成することが可能です。
A new Service ID TLV is defined for the CALL_ATTRIBUTES and LSP_ATTRIBUTES objects. The type value is 3 when carried in the CALL_ATTRIBUTES object and the type value is 2 when carried in the LSP_ATTRIBUTES object. The format is depicted below.
新しいサービスID TLVは、call_attributesおよびlsp_attributesオブジェクトに対して定義されています。型値は、call_attributesオブジェクトに携帯される場合は3で、lsp_attributesオブジェクトに携帯すると、タイプ値は2です。形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service ID TLV
図4：サービスID TLV
- I-SID Set Object: is used to define a list or range of I-SIDs. Multiple I-SID Set Objects can be present. At least one I-SID Set Object MUST be present. In most of the cases, a single I-SID Set Object with a single I-SID value is used. The I-SID Set Object is used to define a list or range of I-SIDs. The format of the I-SID Set Object is based on the LABEL_SET Object:
- I-SIDセットオブジェクト：I-SIDのリストまたは範囲を定義するために使用されます。複数のI-SIDセットオブジェクトが存在する可能性があります。少なくとも1つのI-SIDセットオブジェクトが存在する必要があります。ほとんどの場合、単一のI-SID値を持つ単一のI-SIDセットオブジェクトが使用されます。I-SIDセットオブジェクトは、I-SIDのリストまたは範囲を定義するために使用されます。i-sidセットオブジェクトの形式は、label_setオブジェクトに基づいています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: I-SID Set Object
図5：I-SIDセットオブジェクト
- Action: 8 bits
- アクション：8ビット
The following actions are defined: list (0), range (1). When a range is defined, there are only two I-SIDs that follow the beginning I-SID and the end of the range I-SID. When list is defined, a number of I-SIDs may be defined.
次のアクションが定義されています：リスト（0）、範囲（1）。範囲が定義されている場合、最初のI-SIDと範囲I-SIDの終わりに続くI-SIDは2つしかありません。リストが定義されると、多くのI-SIDが定義される場合があります。
- Length: 16 bits
- 長さ：16ビット
This indicates the length of the I-SID Set object.
これは、I-SIDセットオブジェクトの長さを示します。
- I-SID: 24 bits
- i-sid：24ビット
The I-SID value identifies a particular backbone service instance.
I-SID値は、特定のバックボーンサービスインスタンスを識別します。
The following errors identify Eth-LSP-specific problems.
次のエラーは、ETH-LSP固有の問題を特定します。
In PBB-TE, a set of ESP-VIDs allocated to PBB-TE must be configured. Therefore, it is possible in some situations that the configuration of a bridge is not the same as other bridges. If the ESP-VIDs of various bridges have some ESP-VIDs in common, it is possible some paths may be set up before encountering issues. This is a management issue since all bridges should have the same ESP-VID range. Configuration should be consistent.
PBB-TEでは、PBB-TEに割り当てられたESP-VIDのセットを構成する必要があります。したがって、状況によっては、ブリッジの構成が他の橋と同じではないことが可能です。さまざまな橋のESPVIDに共通のESPVIDがいくつかある場合、問題に遭遇する前にいくつかのパスが設定される可能性があります。これは、すべての橋が同じESP VID範囲を持つ必要があるため、管理上の問題です。構成は一貫している必要があります。
The network operator administratively selects a set of VLAN Identifiers that can be used to set up ESPs. Consequently, any VID outside the allocated range is invalid, and an error MUST be generated where the mismatch is discovered. The Error indication is carried in the PathErr message from any intermediate bridge that does not support the signaled source VID or optionally the destination VID. The Error MAY be indicated in the ResvErr if the allocation error happens on the RESV message. In this case, a bridge that does not support the signaled destination VID MUST signal the error.
ネットワークオペレーターは、ESPのセットアップに使用できるVLAN識別子のセットを管理上選択します。したがって、割り当てられた範囲外のVIDは無効であり、不一致が発見されている場合はエラーを生成する必要があります。エラーの表示は、信号付きソースVIDまたはオプションで宛先VIDをサポートしていない中間ブリッジからのPatherrメッセージに掲載されます。RESVメッセージで割り当てエラーが発生した場合、resverrでエラーが示される場合があります。この場合、信号された宛先VIDをサポートしていないブリッジは、エラーを通知する必要があります。
If a bridge is not configured to use the ESP-VID value, carried in the Label object, for PBB-TE ESPs, it MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209].
BridgeがPBB-TE ESPの場合、ラベルオブジェクトに搭載されているESP-VID値を使用するように構成されていない場合、すぐにエラーを生成する必要があります。ルーティング問題（24） /容認できないラベル値（6）。このエラーの処理は[RFC3209]に従っています。
Note that an originating bridge can reuse an ESP-VID with a different source or destination B-MAC address. By allocating a number of B-MACs and a number of ESP-VIDs, a large number of PBB-TE connections may be supported.
発生するブリッジは、ESP-VIDを別のソースまたは宛先B-MACアドレスで再利用できることに注意してください。多くのB-MACと多くのESPVIDを割り当てることにより、多数のPBB-TE接続がサポートされる場合があります。
Note, this error may be originated by any bridge along the path.
注意してください、このエラーは、パスに沿った任意のブリッジによって発信される場合があります。
The destination bridge, after receiving the PATH message, has to assign a VID, which, together with its MAC address, will constitute the PBB-TE Ethernet Label. An existing VID may be reused when shared forwarding is used or when there are no path conflicts; otherwise, the bridge has to allocate a VID.
宛先ブリッジは、パスメッセージを受信した後、VIDを割り当てる必要があります。VIDは、MACアドレスとともにPBB-TEイーサネットラベルを構成します。共有転送が使用されている場合、またはパス競合がない場合、既存のVIDが再利用される場合があります。それ以外の場合、橋はビデオを割り当てる必要があります。
Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted; hence, no PBB-TE Ethernet Label can be allocated. In this case, the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9).
割り当てられたVLAN範囲のサイズと特定のブリッジで終了したETH-LSPの数に応じて、利用可能なVIDが使い果たされる可能性があります。したがって、PBB-TEイーサネットラベルを割り当てることはできません。この場合、宛先ブリッジは、エラーコード：ルーティング問題（24）とエラー値：MPLSラベル割り当て障害（9）を使用してPatherRメッセージを生成する必要があります。
IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00 to 01-80-C2-00-00-0F as explained in [IEEE802.1Q] that have special meaning, processing, and follow specific forwarding rules. These addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE Ethernet Label refers to such a MAC address, a bridge encountering the mismatch MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209].
IEEEは、[IEEE802.1Q]で説明されているように、01-80-C2-00-00-00-00から01-80-C2-00-00-0Fまでの予約されたMACアドレスのセットを定義します。転送ルール。これらのアドレスは、PBB-TE ESPに使用することはできません。PBB-TEイーサネットラベルがそのようなMACアドレスを指す場合、不一致に遭遇するブリッジはすぐにエラーを生成する必要があります：ルーティング問題（24） /容認できないラベル値（6）。このエラーの処理は[RFC3209]に従っています。
This document does not introduce new security issues; the considerations in [RFC4872] and [RFC4873] apply.
このドキュメントでは、新しいセキュリティの問題は導入されていません。[RFC4872]および[RFC4873]の考慮事項が適用されます。
A GMPLS-controlled Ethernet PBB-TE system assumes that users and devices attached to User-to-Network Interfaces (UNIs) may behave maliciously, negligently, or incorrectly. Intra-provider control traffic is trusted not to 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 Network-to-Network Interface (NNI) or through protected management interfaces.
GMPLS制御イーサネットPBB-TEシステムは、ユーザーからネットワークへのインターフェイス（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; 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 (DoS) attacks may be required on UNI ports. PBB-TE has been designed to interwork with legacy VLANs and the VLANs provide isolation from Ethernet legacy control planes.
GMPLSがVLANのみの制御に適用される場合、UNIポートではイーサネット拒否（DOS）攻撃の緩和のための一般的に既知の手法が必要になる場合があります。PBB-TEは、レガシーVLANとインターワークするように設計されており、VLANはイーサネットレガシーコントロールプレーンからの分離を提供します。
Where control-plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably be determined that no further security measures are used. In other cases, it is appropriate to use control-plane security where it is deemed necessary to secure the signaling messages. GMPLS signaling security measures are described in [RFC3471] and [RFC3473], and they inherit security techniques applicable to RSVP-TE, as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques, see [RFC5920].
802.1AEメディアアクセス制御セキュリティ[MACSEC]を使用するリンクを超えるコントロール通信がポイントツーポイントである場合、それ以上のセキュリティ対策が使用されていないことが合理的に判断される場合があります。それ以外の場合は、シグナリングメッセージを保護するために必要とみなされるコントロールプレーンセキュリティを使用することが適切です。GMPLSシグナリングセキュリティ対策は[RFC3471]および[RFC3473]で説明されており、[RFC3209]および[RFC2205]に記載されているように、RSVP-TEに適用されるセキュリティ手法を継承します。GMPLSセキュリティ手法の概要については、[RFC5920]を参照してください。
A new Switching Type, "802_1 PBB-TE" (40), has been assigned in the Switching Types registry of the GMPLS Signaling Parameters registry.
新しいスイッチングタイプ「802_1 PBB-TE」（40）は、GMPLSシグナリングパラメータレジストリのスイッチングタイプレジストリに割り当てられています。
The Service ID TLV has been assigned in the Attributes TLV Space in the RSVP-TE Parameters registry. It is carried in the LSP_ATTRIBUTES object (class = 197, C-Type = 1) [RFC5420]. This new type has been registered as follows:
サービスID TLVは、RSVP-TEパラメーターレジストリの属性TLVスペースに割り当てられています。lsp_attributesオブジェクト（class = 197、c-type = 1）[rfc5420]で運ばれます。この新しいタイプは、次のように登録されています。
Type: 2 Name: Service ID TLV Allowed on LSP_ATTRIBUTES: Yes Allowed on LSP_REQUIRED_ATTRIBUTES: No
タイプ：2名：LSP_ATTRIBUTESで許可されるサービスIDTLV：はいlsp_required_attributes：no
The Service ID TLV has been assigned value 3 in the Call Attributes TLV registry in the RSVP Parameters registry. It is carried in the CALL_ATTRIBUTES object (class = 202, C-Type = 1) defined by [RFC6001].
サービスID TLVには、RSVPパラメーターレジストリの呼び出し属性TLVレジストリに値3が割り当てられています。[rfc6001]で定義されたcall_attributesオブジェクト（class = 202、c-type = 1）で運ばれます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Swicthing (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルSwicthing（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月。
[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月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974] Papadimitriou、D。およびA. Farrel、「一般化されたMPLS（GMPLS）RSVP-TEシグナル伝達拡張機能」、RFC 4974、2007年8月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420] Farrel、A.、ed。、ed。、Papadimitriou、D.、Vasseur、Jp。、およびA. Ayyangarps、「リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）を使用したMPLS LSP確立の属性のエンコード」、RFC 5420、2009年2月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Shiomoto、K.、Brungard、D。、およびJl。Le Roux、「マルチレイヤーおよびマルチリージョンネットワーク（MLN/MRN）の一般化MPLS（GMPLS）プロトコル拡張」、RFC 6001、2010年10月。
[IEEE802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008)
[IEEE802.1AH]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク - 修正6：プロバイダーバックボーンブリッジ」、（2008）
[IEEE802.1Q] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2005, May 19, 2006.
[IEEE802.1Q]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク」、IEEE STD 802.1Q -2005、2006年5月19日。
[IEEE802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering", 2009.
[IEEE802.1QAY]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク - 修正：プロバイダーバックボーンブリッジトラフィックエンジニアリング」、2009。
[MACSEC] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, August 18, 2006.
[MacSec]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準メディアアクセス制御（MAC）セキュリティ」、IEEE 802.1AE-2006、2006年8月18日。
[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月。
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
[RFC5828] Fedyk、D.、Berger、L。、およびL. Andersson、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）イーサネットラベルスイッチングアーキテクチャとフレームワーク」、RFC 5828、2010年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew, Dave Martin and Sandra Ballarte for their contributions to this document. The authors thank Deborah Brungard and Adrian Farrel for their review and suggestions to this document.
著者は、この文書への貢献について、Dinesh Mohan、Nigel Bragg、Stephen Shew、Dave Martin、Sandra Ballarteに感謝したいと思います。著者は、この文書のレビューと提案について、デボラ・ブルガードとエイドリアン・ファレルに感謝します。
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
Himanshu Shah Ciena 1741 Technology Dr, #400 San Jose, CA 95110 Phone: 508-435-0448 EMail: hshah@ciena.com
Himanshu Shah Ciena 1741 Technology DR、＃400 San Jose、CA 95110電話：508-435-0448メール：hshah@ciena.com
Nabil Bitar Verizon 40 Sylvan Rd. Waltham, MA 02451 EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon 40 Sylvan Rd。マサチューセッツ州ウォルサム02451メール：nabil.n.bitar@verizon.com
Attila Takacs Ericsson 1. Laborc u. Budapest, HUNGARY 1037 EMail: attila.takacs@ericsson.com
Attila Takacs Ericsson 1. Laborc u。ハンガリー、ブダペスト1037メール：attila.takacs@ericsson.com