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)
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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].
一般化されたMPLS（GMPLS）[RFC3945]は、接続指向及びトラフィックエンジニアリング輸送ネットワークで動作するように設計された制御プレーンプロトコルのファミリーです。 GMPLSはL2SCネットワーク（レイヤ2スイッチング可能）を含むネットワーク技術の範囲に適用可能です。このドキュメントの目的は、PBB-TE明示的にルーティングされたトラフィックエンジニアリングパスを管理するためのGMPLSベースのコントロールプレーン用の拡張子を指定することです。この仕様は、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
デビッド・アラン・エリクソンEメール：david.i.allan@ericsson.com
Diego Caviglia Ericsson Via Negrone 1/A Genoa, Italy 16153 EMail: diego.caviglia@ericsson.com
ディエゴ・Cavigliaエリクソン経由Negrone 1 / Aジェノア、イタリア16153 Eメール：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
アラン・マクガイアBTグループPLC OP6ポラリスハウス、Adastral公園、Martleshamヒース、サフォーク州イプスウィッチ、IP5 3RE、英国Eメール：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
nurit.sprecher@nsn.com：Nuritのスポークスマンノキアシーメンスネットワークス社＆株式会社KG COO RTP IEは3 HanagarセントネーヴNe'eman B、45241ホッドHasharon、イスラエルメールを修正しました
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
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の宛先MACアドレス - ESP-VID ESP VLAN ID - ETH-LSPイーサネットラベルスイッチドパス - I-とB-両方のコンポーネントで構成IB-BEB A BEB - タイプと値を持つタグアンイーサネットヘッダーフィールド - - 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トラフィックエンジニアリングサービスインスタンス - 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の用語に翻訳するために、拡張コンテキストでここにこれらを繰り返します。用語「ブリッジ」と「スイッチ」は、本文書で交換可能に使用されます。ここで説明するシグナリング拡張は、シグナリングまたはイーサネットPBB-TE転送をサポートするGMPLS対応スイッチにGMPLSを支持PBB-TE対応ブリッジにも同様に当てはまります。
- 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）に及ぶ二つ以上の顧客バックボーンポート（のCBP）との間に単方向の接続パスを設計しました。パスが3タプル<ESP-MAC DA、ESP-MAC SA、ESP-VID>によって識別されます。 ESPは、ポイントツーポイント（P2P）またはポイントツーマルチポイント（P2MP）です。 ESPは、（一方向）に類似しているポイントツーポイントまたはポイントツーマルチポイントLSP。私たちは、ESPのを確立GMPLSのための用語イーサネット-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の間でESPとn葉のCBP。 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.
ESPのエンドポイントが同じCBP MACアドレスを持つ2つのポイント・ツー・ポイントのESPでサポートされているサービスインスタンス。 2つの単方向のESPは、双方向サービスを形成しています。等TEサービス監視診断、運用の簡素化に関連する理由のために、IEEE PBB-TE標準は、ポイント・ツー・ポイントのESPは、ポイント・ツーに関連付けられていることを前提として：PBB-TE標準[IEEE802.1Qay]は、次のノート - ポイントTESIは共同でルーティングされます。非共同ルーティングの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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イーサネットフォワーディングエントリの簡単な構成で（スイッチによって、またはスイッチ）ブリッジによりブリッジを作成しています。この文書では、ESPのとTESISのセットアップ、ティアダウン、保護、および回復のための有効な制御プレーンとしてのGMPLSを使用することを記載し、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-BEBsが、これは図1のA-B成分に示され、IおよびB成分から構成されているプロバイダ・バックボーン・ブリッジにバックボーンのVLANによって識別されたフレームの中継をサポートする構造およびメカニズムを指します。 I成分は、プロバイダ・バックボーン・ブリッジのサービスインスタンス（I-SID）をによって識別フレームの中継をサポートする構造およびメカニズムを指します。 B成分に加えI成分におけるI成分タグとVLANタグとPBBとPBB-TE中継フレーム。 VLANタグ内のVLAN IDに基づいてPBBとPBB-TEフォワードフレーム（PBBケースにおけるB-VID）宛先MACアドレスは、このブリッジでB成分によってローカルにサポートされるまで、先に到達したことを示します。その時点で、B-VLANタグを除去し、処理、または次のタグの転送は、I-SIDにより識別されるI成分に到達するまで（PBBケースI-componentタグで）始まります。 I成分で、I-コンポーネントタグが除去され、次のイーサネットタイプ等、TAGを識別します
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
PBB-TE TESIでサポートされているイーサネットサービスは、常にI成分のカスタマーネットワークポート（CNP）に取り付けられています。サービスインスタンス識別子（I-SID）はサービスのために割り当てられます。 I-SIDは唯一のソースとデスティネーション（エッジ）ブリッジによって見たされるので、I-SIDがパス操作に透明であり、シグナリングすることができます。 IおよびB-コンポーネントが内部LANを介して接続された内部ポートを有します。これらの内部ポートは、プロバイダインスタンスのポート（ピップ）であり、
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.
顧客バックボーンポート（のCBP）。 PIPとのCBPは、IB-BEB外見えません。 ESPは常に起源とCBPポートで終了し、そのポートのMACアドレスを使用しています。 I成分は、I-SIDおよびESP-MAC DAおよびESP-MAC SAとの完全なイーサネット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.
この文書では、ESPのとTESISを確立するために、GMPLSへの拡張を定義します。上記から分かるように、これは、I-とのESPによって接続されたIB-BEBsのB成分の両方の設定が必要です。
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-BEBs及びバックボーンコアブリッジ（のBCB）を識別するために使用され、TEリンクは、このPNPとCNPSに接続されたリンクを記述する。 TEリンクはのCBPまたはのPIPに関連付けられていません。
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が存在する可能性があるため、PATHメッセージを受信したIB-BEBはETH-LSPの終端点である適切なCBPを決定できなければならないことに留意されたいです。この目的のために、IB-BEBsはGMPLS制御プレーンでCNP TEリンクを広告すべきであり、RSVP-TEシグナリングはETH-LSPの終端点を識別するために、CNP TEリンクを使用すべきです。そのCNPSのいずれかを指定するPATHメッセージを受信するIB-BEBは、局所的に、所与のCNPを支持するI成分への内部接続を有するのCBPを決定することができます。場合には、複数の適しCBPがあること、そして何のI-SID情報は、その後、IB-BEBは、CBPが要求された接続に割り当てるためにどの自由に決めることができPATHメッセージまたは以前に関連したコールセットアップ中に提供されていません。一方サービス（I-SID）に関する情報がある場合、指定されたESPをサポートすること、次いで、IB-BEBは、第I-SIDで構成されており、CBPへの割り当てる必要がPIPと関連する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専用のVIDの数が少ないから来ています。 ESP-VIDのは、ESPの間で再利用することができます。 P2P TESIが同じで形成する二つの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で制御される他の技術に典型的であるように、データプレーン受信機は、その使用可能なラベルプールからラベルを受け入れ、通常割り当てられなければなりません。これ、一緒に上記のラベルの不変性の要件と、各PBB-TEイーサネットラベルはドメイン全体のユニークなラベルであることになり、独自のESP-VID + ESP-MAC DAと、それぞれの方向について。
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)
GMPLS上流ラベル：<：MAC2（DA）、VID2 ESP>（60ビット）上流PBB-TE ESP 3タプル<ESP：MAC1、MAC2、VID1 <ESP MAC1（DA）、VID1>（60ビット）ダウンストリームラベルGMPLS >（108ビット）下流PBB-TE ESP 3タプル<ESP：MAC2、MAC1、VID2>（108ビット）
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.
コネクションレスイーサネットデータプレーンの能力は、目的地までの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>タプルによって識別される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）を示す優先度をドロップするために使用されるかもしれません。このように、複数のCOSからトラフィック（すなわち、E-のLSPに類似）およびキューイング同じETH-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がPATHメッセージに含まれていない場合、単方向のESPを設定するには、RSVP-TEを使用することも可能であること、しかし、注意してください。
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を開始するために、PATHメッセージのイニシエータは、以下の仕様と[RFC3473]に概説された手順を使用する必要があります。
1) it MUST set the LSP encoding type to Ethernet (2) [RFC3471].
1）それは、イーサネット（2）[RFC3471]にLSP符号化タイプを設定しなければなりません。
2) it MUST set the LSP switching type to "802_1 PBB-TE", value 40.
2）それは "802_1 PBB-TE"、値40にLSP切替タイプを設定しなければなりません。
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.
MAC1：4）それはESP-VID1がローカルMACアドレスのために局所的に投与されるESP-VID1 / ESP-MAC1タプルにUPSTREAM_LABELを設定しなければなりません。
5) it SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA.
それはESP-VID / ESP-MAC DAの選択に影響を与えることを選択した場合5）それはLABEL_SETまたはSUGGESTED_LABELを設定する必要があります。
6) it MAY carry an I-SID via Call/Connection ID [RFC4974].
6）それは呼/接続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オブジェクトとESP-VID1及びESP-MAC1由来するポートは、静的エントリを構成するPBB-TEイーサネットラベルに含まれます。
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メッセージ内のラベルオブジェクトに渡されます。 PATHメッセージと同様に、中間ブリッジ処理は[RFC3473]単位であり、そしてラベルオブジェクトは、不変の上流に渡さなければなりません。 LABELオブジェクトに含まれているESP-VID2 / ESP-MAC2タプルは、各ホップで静的転送エントリとして転送テーブルにインストールされています。 PATHと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
メイク前にブレーク手順は、P2P ETH-LSPの特性を変更するために使用することができます。 [RFC3209]に記載されているように新しいパスが通知されると、送信者テンプレートのLSP IDが更新されます。 （共有の転送のためのものを含む）の手順は、拡張されたトンネルで、新しいLSPを確立するのに用いたものと同一であります
ID in the signaling exchange ensuring that double booking of an associated resource does not occur.
関連するリソースの二重予約が発生しないことを保証するシグナリングエクスチェンジで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つの共通のエンドポイント間に設定されているときに動作することができる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のLSPをシグナリングするために適合させることができます。 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と、ユニキャスト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]とASSOCIATIONと保護オブジェクトを使用して、[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-BEBsでは、バックボーン・サービスインスタンスの表は、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シグナリングは、ESPへのマッピングI-SIDを自動化するために使用されるかもしれません。シグナリングに依存することによって、同じI-SIDがサービスに割り当てられ、同じESPにマッピングされていることが保証されます。注、ESPに関連したI-SIDをシグナリングすることによって、一つはIB-BEBsは、適切な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]はETH-LSPは、LSPの確立に先立ってエンドポイント間の関連付けを作成するために使用され得ます。 [RFC4974]に記載されているようにCALL_ATTRIBUTESオブジェクトは、コールの特性を示すため、呼シグナリングの間に使用することができます。サービスID TLVは、以下に定義される、CALLに対応付けて設定されるETH-LSPのためのI-SID ESPへのマッピングを示すためにCALL_ATTRIBUTESオブジェクトで行うことができます。
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 PATHメッセージは、ETH-LSPシグナリング時LSP_ATTRIBUTESオブジェクト[RFC5420]にサービスID TLVを使用してI-SIDの関連付けを運ぶことができます。このメカニズムを使用して、パスが設定したり、後でPATHリフレッシュを使用しているいずれかのとき、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オブジェクトで運ばとLSP_ATTRIBUTESオブジェクトで運ばときタイプ値が2のときタイプ値は3です。フォーマットは以下に示されています。
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セットオブジェクトが存在することができます。少なくとも一つのI-SID Setオブジェクトが存在しなければなりません。ほとんどの場合、単一のI-SID値を持つ単一のI-SIDの設定オブジェクトが使用されます。 I-SID Setオブジェクトは、I-SIDのリストまたは範囲を定義するために使用されます。 I-SID Setオブジェクトのフォーマットは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 Setオブジェクト
- 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の終わりに続く2つだけI-SIDがあります。リストが定義されている場合、I-SIDの数が定義されてもよいです。
- Length: 16 bits
- 長さ：16ビット
This indicates the length of the I-SID Set object.
これは、I-SID Setオブジェクトの長さを示します。
- 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のセットが構成されなければなりません。したがって、ブリッジの構成は他のブリッジと同じではないいくつかの状況で可能です。様々なブリッジのESP-VIDのが一般的で、いくつかのESP-VIDのを持っている場合、いくつかのパスは問題に遭遇する前にセットアップすることができる可能です。これは、すべてのブリッジが同じ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].
ブリッジは、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.
発信ブリッジは、異なるソースまたは宛先B-MACアドレスとESP-VIDを再利用できることに留意されたいです。 B-MACの数およびESP-のVIDの数を割り当てることによって、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.
宛先ブリッジは、PATHメッセージを受信した後、一緒にそのMACアドレスを持つ、PBB-TEイーサネット・ラベルを構成する、VIDを割り当てなければなりません。共有転送が使用されるか、または全く経路の競合が存在しない場合にされたときに既存のVIDを再利用することができます。そうでない場合、ブリッジは、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-0Fに01-80-C2-00-00-00から予約済み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の制御に適用した場合、イーサネットサービス拒否（DoS）攻撃の軽減のために一般的に知られている技術は、UNIポートで必要とされ得ます。 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]に記載されているように、それらは、-TEをRSVPに適用可能なセキュリティ技術を継承します。 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オブジェクト（クラス= 197、C-タイプ= 1）[RFC5420]で運ばれます。次のようにこの新しいタイプが登録されています：
Type: 2 Name: Service ID TLV Allowed on LSP_ATTRIBUTES: Yes Allowed on LSP_REQUIRED_ATTRIBUTES: No
タイプ：2名：サービスID TLV LSP_ATTRIBUTESに可：はいLSP_REQUIRED_ATTRIBUTESに使用：不可
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オブジェクト（クラス= 202、C-タイプ= 1）に搬入されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Swicthing (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベル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]バーガー、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月。
[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月。
[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.ファレル、 "一般化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]ファレル、A.編、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。ル・ルー、 "マルチレイヤおよびマルチリージョンネットワークのための一般化MPLS（GMPLS）プロトコルの拡張機能（MLN / MRN）"、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 802.1Q STD-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] "ローカルおよびメトロポリタンエリアネットワークメディアアクセス制御（MAC）セキュリティのためのIEEE規格"、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]アガルワルは、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月。
[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.、バーガー、L.、およびL.アンダーソン、 "一般化マルチプロトコルラベルスイッチング（GMPLS）、イーサネットプロトコルラベルスイッチングアーキテクチャとフレームワーク"、RFC 5828、2010月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "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.
作者はこのドキュメントへの貢献のためにディネッシュモハン、ナイジェル・ブラッグ、スティーブン供え、デイブ・マーティンとサンドラBallarteに感謝したいと思います。作者はこのドキュメントへの彼らのレビューと提案のためのデボラBrungardとエードリアンファレルに感謝します。
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
Himanshu Shah Ciena 1741 Technology Dr, #400 San Jose, CA 95110 Phone: 508-435-0448 EMail: hshah@ciena.com
ヒマンシュシャーシエナ1741テクノロジー博士、＃400サンノゼ、CA 95110電話：508-435-0448 Eメール：hshah@ciena.com
Nabil Bitar Verizon 40 Sylvan Rd. Waltham, MA 02451 EMail: nabil.n.bitar@verizon.com
ナビル・ビタールベライゾン40シルバンRdを。ウォルサム、MA 02451 Eメール：nabil.n.bitar@verizon.com
Attila Takacs Ericsson 1. Laborc u. Budapest, HUNGARY 1037 EMail: attila.takacs@ericsson.com
1.アッティラタカーチエリクソンLaborc U。ブダペスト、ハンガリー1037 Eメール：attila.takacs@ericsson.com