Internet Engineering Task Force (IETF) D. Fedyk, Ed.
Request for Comments: 6329 Alcatel-Lucent
Category: Standards Track P. Ashwood-Smith, Ed.
ISSN: 2070-1721 Huawei
D. Allan
Ericsson
N. Bragg
Ciena Limited
P. Unbehagen
Avaya
April 2012
IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
Abstract
抽象
802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples.
802.1aq最短パスブリッジング（SPB）は、種々のスパニングツリー、登録プロトコルの進化の次のステップとして、IEEEによって標準化されています。 802.1aqは、複数の等コスト・パスを利用してメッシュEthernetネットワークコンテキストにおける真の最短パスの転送を可能にします。これは、より速い収束、およびメッシュトポロジーを大幅に改善使用して、はるかに大きいレイヤ2つのトポロジをサポートすることが可能となります。この組み合わせるポイントツーポイント、ポイントツーマルチポイント、および多対多のバリエーションを含む論理接続会員用の単一ポイント・プロビジョニングです。このメモは、IS-ISは、変更はこの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/rfc6329.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6329で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Conventions Used in This Document ...............................5
4. 802.1aq Overview ................................................6
4.1. Multi-Topology Support .....................................8
4.2. Data Path SPBM - Unicast ...................................8
4.3. Data Path SPBM - Multicast (Head-End Replication) ..........9
4.4. Data Path SPBM - Multicast (Tandem Replication) ............9
4.5. Data Path SPBV Broadcast ..................................11
4.6. Data Path SPBV Unicast ....................................11
4.7. Data Path SPBV Multicast ..................................12
5. SPBM Example ...................................................12
6. SPBV Example ...................................................14
7. SPB Supported Adjacency types ..................................16
8. SPB IS-IS Adjacency Addressing .................................16
9. IS-IS Area Address and SYSID ...................................17
10. Level 1/2 Adjacency ...........................................17
11. Shortest Path Default Tie-Breaking ............................17
12. Shortest Path ECT .............................................18
13. Hello (IIH) Protocol Extensions ...............................19
13.1. SPB-MCID Sub-TLV .........................................20
13.2. SPB-Digest Sub-TLV .......................................21
13.3. SPB Base VLAN Identifiers (SPB-B-VID) Sub-TLV ............23
14. Node Information Extensions ...................................24
14.1. SPB Instance (SPB-Inst) Sub-TLV ..........................24
14.1.1. SPB Instance Opaque ECT-ALGORITHM
(SPB-I-OALG) Sub-TLV ..............................28
15. Adjacency Information Extensions ..............................29
15.1. SPB Link Metric (SPB-Metric) Sub-TLV .....................29
15.1.1. SPB Adjacency Opaque ECT-ALGORITHM
(SPB-A-OALG) Sub-TLV ..............................30
16. Service Information Extensions ................................30
16.1. SPBM Service Identifier and Unicast Address
(SPBM-SI) Sub-TLV ........................................30
16.2. SPBV MAC Address (SPBV-ADDR) Sub-TLV .....................32
17. Security Considerations .......................................34
18. IANA Considerations ...........................................34
19. References ....................................................35
19.1. Normative References .....................................35
19.2. Informative References ...................................36
20. Acknowledgments ...............................................36
802.1aq Shortest Path Bridging (SPB) [802.1aq] has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in an Ethernet mesh network context utilizing multiple equal cost paths. This permits SPB to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point (E-LINE), point-to-multipoint (E-TREE), and multipoint-to-multipoint (E-LAN) variations.
802.1aq最短パスブリッジング（SPB）[802.1aqは様々なスパニングツリー、登録プロトコルの進化の次のステップとして、IEEEによって標準化されています。 802.1aqは、複数の等コスト・パスを利用してイーサネット（登録商標）メッシュネットワークのコンテキストにおいて真の最短パスの転送を可能にします。これは、より速い収束、およびメッシュトポロジーを大幅に改善使用して、はるかに大きいレイヤ2つのトポロジをサポートするために、SPBを可能にします。組み合わせるこれは、ポイントツーポイント（E-LINE）、ポイント・ツー・マルチポイント（E-TREE）、および多対多（E-LAN）のバリエーションを含む論理接続会員のための単一ポイント・プロビジョニング、です。
The control protocol for 802.1aq is IS-IS [IS-IS] augmented with a small number of TLVs and sub-TLVs. This supports two Ethernet encapsulating data paths, 802.1ad (Provider Bridges) [PB] and 802.1ah (Provider Backbone Bridges) [PBB]. This memo documents those TLVs while providing some overview.
802.1aqの制御プロトコルは、IS-ISでのTLVサブTLVの少数の拡張[ - です]。これは、2つのイーサネットカプセル化データ経路、802.1ad（プロバイダブリッジ）[PB]と802.1ahの（プロバイダバックボーンブリッジ）[PBB]をサポートしています。いくつかの概要を提供しながら、このメモは、これらのTLVを説明します。
Note that 802.1aq requires no state machine or other substantive changes to [IS-IS]. 802.1aq simply requires a new Network Layer Protocol Identifier (NLPID) and set of TLVs. In the event of confusion between this document and [IS-IS], [IS-IS] should be taken as authoritative.
802.1aqは[IS-IS]にない状態機械または他の実質的な変更を必要としないことに留意されたいです。 802.1aqは、単に新しいネットワーク層プロトコル識別子（NLPID）とのTLVのセットが必要です。本文書との間で混乱が発生した場合に[ - である]、[ - である]権威として解釈されるべきです。
In addition to well-understood IS-IS terms, this memo uses terminology from IEEE 802.1 and introduces a few terms:
十分に理解に加えて、IS-ISの用語、このメモは、IEEE 802.1からの用語を使用して、いくつかの用語が導入されています。
802.1ad Provider Bridges (PBs) - Q-in-Q encapsulation 802.1ah Provider Backbone Bridges (PBBs), MAC-IN-MAC encapsulation 802.1aq Shortest Path Bridging (SPB) Base VID VID used to identify a VLAN in management operations B-DA Backbone Destination Address 802.1ah PBB B-MAC Backbone MAC Address B-SA Backbone Source Address in 802.1ah PBB header B-VID Backbone VLAN ID in 802.1ah PBB header B-VLAN Backbone Virtual LAN BPDU Bridge PDU BridgeID 64-bit quantity = (Bridge Priority:16)<<48 | SYSID:48 BridgePriority 16-bit relative priority of a node for tie-breaking C-MAC Customer MAC. Inner MAC in 802.1ah PBB header C-VID Customer VLAN ID ECT-ALGORITHM 32-bit unique ID of an SPF tie-breaking set of rules ECT-MASK 64-bit mask XORed with BridgeID during tie-breaking E-LAN Bidirectional Logical Connectivity between >2 UNIs
802.1adプロバイダブリッジ（PBS） - Q-で-Qカプセル化802.1ahのプロバイダバックボーンブリッジ（PBB類）、MAC-IN-MACカプセル化802.1aq最短パスブリッジング（SPB）は、ベースVID VIDは、管理操作にVLANを識別するために使用されますB- 802.1ahののPBBヘッダB-VIDバックボーンVLAN IDでDAバックボーン宛先アドレス802.1ahのPBB B-MACバックボーンMACアドレスB-SAバックボーンソースアドレス802.1ahののPBBヘッダB-VLANバックボーンにおける仮想LAN BPDUブリッジPDUは= 64ビット量をBridgeID （ブリッジプライオリティ：16）<< 48 | SYSID：48 BridgePriorityタイブレークC-MAC顧客のノードの16ビットの相対的優先MAC。 802.1ahのPBBヘッダC-VIDタイブレークE-LAN双方向論理接続中BridgeIDとXORカスタマVLAN ID ECTアルゴリズム32ビットルールのSPFのタイブレークセットの一意のID ECT-MASK 64ビットマスクの内側MAC > 2つのUNI間
E-LINE Bidirectional Logical Connectivity between two UNIs E-TREE Asymmetric Logical Connectivity between UNIs FDB Filtering Database: {DA/VID}->{next hops} I-SID Ethernet Services Instance Identifier used for Logical Grouping for E-LAN/LINE/TREE UNIs LAN Local Area Network LSDB Link State Database LSP Link State PDU MAC Media Access Control MAC-IN-MAC Ethernet in Ethernet framing as per 802.1ah [PBB] MDT Multicast Distribution Tree MMRP Multiple MAC Registration Protocol 802.1ak [MMRP] MT Multi-Topology. As used in [MT] MT ID Multi-Topology Identifier (12 bits). As used in [MT] NLPID Network Layer Protocol Identifier: IEEE 802.1aq= 0xC1 NNI Network-Network Interface Q-in-Q Additional S-VID after a C-VID (802.1ad) [PB] PBB Provider Backbone Bridge - forwards using PBB Ingress Check Source Forwarding Check - drops misdirected frames (S,G) Source & Group - identity of a source-specific tree (*,G) Any Source & Group - identity of a shared tree S-VID Service VLAN ID SA Source Address SPB Shortest Path Bridging - generally all of 802.1aq SPB Shortest Path Bridge - device implementing 802.1aq SPB-instance Logical SPB instance correlated by MT ID SPBM Device implementing SPB MAC mode SPBV Device implementing SPB VID mode SPSourceID 20-bit identifier of the source of multicast frames SPT Shortest Path Tree computed by one ECT-ALGORITHM SPT Region A set of SPBs with identical VID usage on their NNIs SPVID Shortest Path VLAN ID: a C-VID or S-VID that identifies the source STP Spanning Tree Protocol UNI User-Network Interface: customer-to-SPB attach point VID VLAN ID: 12-bit logical identifier after MAC header VLAN Virtual LAN: a logical network in the control plane
UNI FDBフィルタリングデータベースとの間に2つのUNI E-TREE非対称論理接続の間にE-LINE双方向論理接続：{DA / VID} - > {次回ホップ}はI-SIDイーサネットサービスインスタンス識別子/ E-LAN / LINEために論理的にグループ化するために使用しました[PBB] MDTマルチキャスト配信ツリーMMRP複数のMAC登録プロトコル802.1ak [MMRP] MTマルチ802.1ahのあたりなど、イーサネットフレーム内TREEのUNI LANローカルエリアネットワークLSDBリンクステートデータベースLSPリンクステートPDU MACメディアアクセス制御MAC-IN-MACイーサネット-トポロジー。 [MT] MT IDマルチトポロジ識別子（12ビット）で使用されるように。 - 使用して転送C-VID（802.1ad）[PB] PBBプロバイダーバックボーンブリッジの後にIEEE 802.1aq = 0xC1 NNIネットワーク - ネットワークインターフェイスQ-で-Qの追加S-VID：[MT] NLPIDネットワーク層プロトコル識別子で使用されるようにPBBイングレスは、ソース転送チェックをチェック - ソース特有ツリー（*、G）どれソース＆グループのアイデンティティ - - （S、G）ソース＆グループ見当違いのフレームをドロップし、共有ツリーのS-VIDサービスVLAN ID SAの送信元アドレスのアイデンティティをSPB最短パスブリッジ - 一般すべて802.1aq SPB最短パスブリッジの - デバイスはSPB VIDモードを実装SPB MACモードSPBVデバイスを実装MT ID SPBM装置により相関802.1aq SPB-インスタンスの論理SPBインスタンスを実装するソースの20ビットの識別子をSPSourceID C-VIDまたはS-VIDソースSTPスパニングツリープロトコルUNI USER-を識別する一ECTアルゴリズムSPT領域によりそれらのNNI SPVID最短パスVLAN IDに同じVIDの使用とのSPBのセットを計算マルチキャストフレームSPT最短経路ツリーネットワークインターフェース：顧客ツーSPB取り付けポイントVID VLAN ID：MACヘッダVLAN仮想LAN後の12ビットの論理識別子：制御プレーン内の論理ネットワーク
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]に記載されているように解釈されます。
The lowercase forms with an initial capital "Must", "Must Not", "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" in this document are to be interpreted in the sense defined in
初期投資と小文字の形、「してはならない」「必要」、「シャル」、「SHALL NOT」、「SHOULD」、この文書では、「べきではない」「月」、および「任意の」で解釈されるべきですで定義された意味
[RFC2119], but are used where the normative behavior is defined in documents published by SDOs other than the IETF.
[RFC2119]が、規範的な行動がIETF以外のSDOによって公開された文書で定義されている場合に使用されています。
This section provides an overview of the behavior of [802.1aq] and is not intended to be interpreted as normative text. For the definitive behavior, the reader should consult [802.1aq]. Nonetheless, lowercase forms with initial capitalization of the conventions in RFC 2119 are used in this section to give the reader an indication of the intended normative behaviors as above.
このセクションでは、[802.1aq]の動作の概要を提供し、規範的なテキストとして解釈されるものではありません。決定的な行動のために、読者は[802.1aq]を相談してください。それにもかかわらず、RFC 2119における規則の最初の大文字と小文字の形態は、読者に、上記のように意図規範行動の指標を与えるために、このセクションで使用されています。
802.1aq utilizes 802.1Q-based Ethernet bridging. The filtering database (FDB) is populated as a consequence of the topology computed from the IS-IS database. For the reader unfamiliar with IEEE terminology, the definition of Ethernet behavior is almost entirely in terms of "filtering" (of broadcast traffic) rather than "forwarding" (the explicit direction of unicast traffic). This document uses the generic term "forwarding", and it has to be understood that these two terms simply represent different ways of expressing the same behaviors.
802.1aqは、802.1Qベースのイーサネットブリッジングを利用しています。フィルタリングデータベース（FDB）がIS-ISデータベースから計算されたトポロジーの結果として取り込まれます。 IEEE用語に慣れていない読者のために、イーサネット（登録商標）動作の定義は、（ブロードキャストトラフィックの）「フィルタリング」ではなく「転送」（ユニキャストトラフィックの明示的な方向）の点でほぼ完全です。この文書では、一般的な用語「転送」を使用し、それはこれら二つの用語は、単に同じ振る舞いを表現するさまざまな方法を表していることを理解すべきです。
802.1aq supports multiple modes of operation depending on the type of data plane and the desired behavior. For the initial two modes of 802.1aq (SPBV and SPBM), routes are shortest path, are forward- and reverse-path symmetric with respect to any source/destination pair within the SPB domain, and are congruent with respect to unicast and multicast. Hence, the shortest path tree (SPT) to a given node is congruent with the multicast distribution tree (MDT) from a given node. The MDT for a given VLAN is a pruned subset of the complete MDT for a given node that is identical to its SPT. Symmetry and congruency preserve packet ordering and proper fate sharing of Operations, Administration, and Maintenance (OAM) flows by the forwarding path. Such modes are fully supported by existing [802.1ag] and [Y.1731] OAM mechanisms.
802.1aqは、データプレーンの種類及び所望の動作に応じて複数の動作モードをサポートします。 802.1aqの最初の二つのモード（SPBVとSPBM）のために、ルートは、最短経路である順方向であり、逆パスSPBドメイン内の任意のソース/宛先ペアに対して対称に、ユニキャストおよびマルチキャストに対して合同です。したがって、所与のノードへの最短経路ツリー（SPT）は、所与のノードからマルチキャスト配信ツリー（MDT）と合同です。特定のVLANのためのMDTは、SPTと同一である所与のノードのための完全なMDTの剪定サブセットです。対称性と合同パケット順序や業務の適切な運命の共有を維持、管理、および保守（OAM）は、転送パスで流れています。そのようなモードは完全に現存802.1ag]及び[Y.1731] OAMメカニズムによってサポートされています。
VLANs provide a natural delineation of service instances. 802.1aq supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV, multiple VLANS can be used to distribute load on different shortest path trees (each computed by a different tie-breaking rule) on a service basis. In SPBM, service instances are delineated by I-SIDs but VLANs again can be used to distribute load on different shortest path trees.
VLANは、サービスインスタンスの自然な描写を提供しています。 802.1aqは、2つのモード、SPB VID（SPBV）とSPB MAC（SPBM）をサポートします。 SPBVでは、複数のVLANは、サービスごとに異なる最短経路ツリー（それぞれ異なるタイブレーク規則により計算）の負荷を分散するために使用することができます。 SPBMでは、サービスインスタンスは、I-SIDがで区切られているが、VLANはまた違った最短経路木に負荷を分散するために使用することができます。
There are two encapsulation methods supported. SPBM can be used in a PBB network implementing PBB (802.1ah [PBB]) encapsulation. SPBV can be used in PB networks implementing VLANs, PB (802.1aq [PB]), or PBB
サポートされている2つのカプセル化の方法があります。 SPBMは、PBB（802.1ahの[PBB]）カプセル化を実現PBBネットワークで使用することができます。 SPBVは、PB（802.1aq [PB]）、又はPBB、VLANを実装PBネットワークで使用することができます
encapsulation. The two modes can co-exist simultaneously in an SPB network.
カプセル化。二つのモードは、SPBネットワークに同時に共存することができます。
The practical design goals for SPBV and SPBM in the current 802.1aq specification are networks of size 100 nodes and 1000 nodes respectively. However, since SPBV can be sparsely used in an SPB region it can simply span a large SPB region with a small number of SPVIDs.
現在802.1aq仕様のSPBVとSPBMための実用的な設計目標は、それぞれサイズ100のノード1000個のノードのネットワークです。 SPBVがまばらSPB領域で使用することができるので、それは単にSPVIDs少数の大型SPB領域にまたがることができます。
In SPBM and SPBV each bridge has at least one unique "known" MAC address which is advertised by IS-IS in the SYSID.
SPBMとSPBVに各ブリッジは、によってアドバタイズされたMACアドレスがSYSIDに-IS「既知」のユニークな少なくとも一つを有しています。
In the forwarding plane, SPBM uses the combination of one or more B-VIDs and "known" Backbone-MAC (B-MAC) addresses that have been advertised in IS-IS. The term Backbone simply implies an encapsulation that is often used in the backbone networks, but the encapsulation is useful in other types of networks where hiding C-MACs is useful.
転送プレーンにおいて、SPBMは、一つ以上のB-VIDのとIS-ISでアドバタイズされた「既知」のバックボーンMAC（B-MAC）アドレスの組み合わせを使用します。用語骨格は、単に多くの場合、バックボーンネットワークにおいて使用されるカプセル化を意味するが、カプセル化は、隠蔽C-MACが有用である他のタイプのネットワークにも有用です。
The SPBM filtering database (FDB) is computed and installed for unicast and multicast MAC addresses, while the SPBV filtering database is computed and installed for unidirectional VIDs (referred to as SPVIDs), after which MAC reachability is learned (exactly as in bridged Ethernet) for unicast MACs.
SPBVフィルタリングデータベースはMACの到達可能性を（正確にブリッジイーサネットのように）学習した後、一方向のVID（SPVIDsと称する）について計算され、インストールされている間SPBMフィルタリングデータベース（FDB）は、ユニキャストおよびマルチキャストMACアドレスについて計算し、インストールされていますユニキャストMACのため。
Both SPBV and SPBM use source-specific multicast trees. If they share the same ECT-ALGORITHM (32-bit worldwide unique definition of the computation), the tree is the same SPT. For SPBV, (S,G) is encoded by a source-specific VID (the SPVID) and a standard Group MAC address. For SPBM, (S,G) is encoded in the destination B-MAC address as the concatenation of a 20-bit SPB wide unique nodal nickname (referred to as the SPSourceID) and the 24-bit I-SID together with the B-VID that corresponds to the ECT-ALGORITHM network wide.
両方SPBVとSPBM利用ソース固有マルチキャストツリー。彼らは同じECT-アルゴリズム（計算の32ビットの世界的にユニークな定義を）共有している場合、ツリーは同じSPTです。 SPBVため、（S、G）は、ソース固有のVID（SPVID）および標準グループMACアドレスによってコードされます。 SPBMため、（S、G）はB-と共にワイド20ビットSPB（SPSourceIDと呼ばれる）一意のノードニックネーム、24ビットI-SIDの連結として宛先B-MACアドレスに符号化されますワイドECTアルゴリズムネットワークに対応VID。
802.1aq supports membership attributes that are advertised with the I-SID (SPBM) or Group Address (SPBV) that defines the group. Individual members can be transmitters (T) and/or receivers (R) within the group, and the multicast state is appropriately sized to these requests. Multicast group membership is possible even without transmit membership by performing head-end replication to the receivers thereby eliminating transit multicast state entirely.
802.1aqは、グループを定義するI-SID（SPBM）またはグループアドレス（SPBV）でアドバタイズされている会員の属性をサポートしています。個々のメンバーは、グループ内の送信機（T）及び/又は受信機（R）であってもよく、マルチキャスト状態は適宜これらの要求に寸法決めされています。マルチキャストグループメンバーシップ、それによって完全トランジットマルチキャスト状態を排除する受信機にヘッドエンドレプリケーションを実行することによっても送信メンバーシップなしに可能です。
Some highly connected mesh networks provide for path diversity by offering multiple equal cost alternatives between nodes. Since congruency and symmetry Must be honored, a single tree may leave some links under-utilized. By using different deterministic tie-breakers, up to 16 shortest paths of arbitrary diversity are possible between any pair of nodes. This distributes the traffic on a VLAN basis.
いくつかの非常に接続されたメッシュネットワークは、ノード間の複数の等コストの代替を提供することにより、パスダイバーシチを提供します。合同と対称性が尊重されなければならないため、単一のツリーには、十分に利用いくつかのリンクを残すことができます。異なる決定論タイブレーカを使用することにより、任意の多様性の最大16の最短経路は、ノードの任意の対の間で可能です。これは、VLANごとにトラフィックを分散します。
SPBV and SPBM May share a single SPT with a single ECT-ALGORITHM or use any combination of the 16 ECT-ALGORITHMs. An extensible framework permits additional or alternative algorithms with other properties and parameters (e.g., ECMP, (*,G)) to also be supported without any changes in this or the IEEE documents.
SPBVとSPBMは単一ECT-アルゴリズムで単一SPTを共有したり、16 ECT-アルゴリズムの任意の組み合わせを使用することができます。拡張可能なフレームワークはまた、この内の任意の変更またはIEEEドキュメントなしでサポートされる他の特性及びパラメータ（例えば、ECMP、（*、G））を用いて、追加のまたは代替のアルゴリズムを可能にします。
SPB incorporates the multi topology features of [MT] thereby allowing multiple logical SPB instances within a single IS-IS instance.
SPBは、単一であるインスタンス内[MT]それによって可能に複数の論理SPBインスタンスのマルチトポロジ機能を組み込んでいます。
To accomplish this, all SPB-related information is either explicitly or implicitly associated with a Multi-Topology Identifier (MT ID). SPB information related to a given MT ID thus forms a single logical SPB instance.
これを達成するために、すべてのSPB関連情報は、明示的または暗黙的にマルチトポロジ識別子（MT ID）に関連付けられたいずれかです。所与MT IDに関連SPB情報は、このように単一の論理SPBインスタンスを形成します。
Since SPB has its own adjacency metrics and those metrics are also associated with an MT ID, it is possible to have different adjacency metrics (or infinite metrics) for SPB adjacencies that are not only distinct from IP or other NLPIDs riding in this IS-IS instance, but also distinct from those used by other SPB instances in the same IS-IS instance.
SPBは、自身の隣接指標を有し、それらのメトリックはまた、MT IDに関連付けられている、それだけでなく、IPまたは本に乗って他のNLPIDs区別されるSPBの隣接に対して異なる隣接メトリクス（または無限のメトリック）を有することが可能であるので、IS-IS例えば、も同様に他のSPBインスタンスによって使用されるものとは異なるインスタンスIS-IS。
Data plane traffic for a given MT ID is intrinsically isolated by the VLANs assigned to the SPB instance in question. Therefore, VLANs (represented by VIDs in TLVs and in the data plane) Must Not overlap between SPB instances (regardless of how the control planes are isolated).
与えられたMT IDのデータプレーントラフィックは、本質的に問題のSPBのインスタンスに割り当てられたVLANによって隔離されています。したがって、（のTLVおよびデータプレーン内のVIDで表される）VLANは（関係なく制御プレーンが分離されている方法の）SPBインスタンス間で重複してはなりません。
The [MT] mechanism when applied to SPB allows different routing metrics and topology subsets for different classes of services.
SPBに印加[MT]メカニズムは、サービスの異なるクラスに対して異なるルーティングメトリックとトポロジのサブセットを可能にします。
The use of [MT] other than the default MT ID #0 is completely OPTIONAL.
デフォルトMT ID＃0以外の[MT]の使用は完全にオプションです。
The use of [MT] to separate SPB from other NLPIDs is also OPTIONAL.
他のNLPIDsからSPBを分離する[MT]の使用も任意です。
Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A Backbone Source Address (B-SA), Backbone Destination Address (B-DA), Backbone VLAN ID (B-VID), and an I-Component Service Instance ID (I-TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC associated with the ingress 802.1aq bridge, usually the "known" B-MAC of that entire bridge. The B-DA is one of the "known" B-MACs associated with the egress 802.1aq bridge. The B-VID and I-TAG are mapped based on the physical or logical UNI port (untagged, or tagged either by S-TAG or C-TAG) being bridged. Normal learning and broadcast to unknown C-MACs is applied as per [PBB] at the ingress/egress SPBs only.
SPBMにおけるユニキャストフレームは、802.1ahの[PBB]に従ってカプセル化されます。バックボーンソースアドレス（B-SA）、バックボーン送信先アドレス（B-DA）、バックボーンVLAN ID（B-VID）、及びI-コンポーネントサービス・インスタンスID（I-TAG）は、イーサネットフレームをカプセル化するために使用されます。 B-SAは入力802.1aqブリッジに関連付けられたB-MAC、その全体ブリッジの通常「既知」のB-MACです。 B-DAは、出口802.1aqブリッジに関連付けられた「既知」のB-MACの一つです。 B-VID及びI-TAGがマッピングされた物理または論理UNIポートに基づいている（タグなし、またはS-TAG又はC-TAGのいずれかによってタグ付けされた）がブリッジされます。未知のC-MACのに通常の学習と放送が唯一の入口/出口のSPBで[PBB]ごとに適用されます。
Unlike [PBB] on a (*,G) tree, the B-DA forwarding on tandem nodes (NNI to NNI) is performed without learning. Instead, the output of 802.1aq computations, based on the TLVs specified in this document, is used to populate the filtering databases (FDBs). The FDB entries map {B-DA, B-VID} to an outgoing interface and are only populated from the IS-IS database and computations.
（*、G）ツリーの[PBB]とは異なり、タンデムノード上のB-DA転送（NNIのNNI）を学習することなく行われます。代わりに、この文書で指定されたTLVに基づく802.1aq計算の出力は、フィルタリングデータベース（FDBs）を移入するために使用されます。 FDBマップ発信インターフェイスに{B-DA、B-VIDを}エントリのみIS-ISデータベースとの計算から移入されます。
The B-SA/B-VID is checked on tandem nodes against the ingress port. If the B-SA/B-VID (as a destination) entry in the FDB does not point to the port on which the packet arrived, the packet is discarded. This is referred to as an ingress check and serves as a very powerful loop mitigation mechanism.
B-SA / B-VIDは、入力ポートに対するタンデムノードでチェックされます。 FDBのエントリ（宛先など）B-SA / B-VIDは、パケットが到着したポートを指していない場合、パケットは破棄されます。これは、入口チェックと呼ばれ、非常に強力なループ緩和機構として機能します。
Head-end replication is supported for instances where there is a sparse community of interest or a low likelihood of multicast traffic. Head-end replication requires no multicast state in the core. A UNI port wishing to use head-end replication Must Not advertise its I-SID membership with the Transmit (T) bit set but instead Must locally and dynamically construct the appropriate unicast serial replication to all the other receivers (Receive (R) bit set) of the same I-SID.
ヘッドエンドレプリケーションは関心のまばらな地域社会やマルチキャストトラフィックの低い可能性があるインスタンスに対してサポートされています。ヘッドエンドのレプリケーションは、コアには、マルチキャスト状態を必要としません。送信（T）がセットではなく、ローカルおよび動的に他のすべてのレシーバ（受信（R）ビットセットに適切なユニキャストシリアルレプリケーションを構築する必要がありますビットとヘッドエンドレプリケーションを使用したいUNIポートは、I-SIDメンバーシップを宣伝していない必要があります）同じI-SIDの。
When an unknown customer unicast or a multicast frame arrives at an SPBM User-Network Interface (UNI) port that has been configured to replicate only at the head end, the packet is replicated once for each receiver, encapsulated, and sent as a unicast frame. The set of receivers is determined by inspecting the IS-IS database for other SPBs that have registered interest in the same I-SID with the R bit set. This R bit / I-SID pair is found in the SPBM Service Identifier and Unicast Address (SPBM-SI) sub-TLV. The packets are encapsulated as per the SPBM unicast forwarding above.
未知の顧客のユニキャストまたはマルチキャストフレームのみをヘッドエンドに複製するように構成されているSPBMのユーザネットワークインタフェース（UNI）ポートに到着すると、パケットは、各受信機に対して一度複製カプセル化、およびユニキャストフレームとして送信されます。受信機のセットは、IS-IS Rと同じI-SIDへの関心を登録している他のSPBのデータベースは、ビットセット検査することによって決定されます。このRビット/ I-SID対はSPBMサービス識別子とユニキャストアドレス（SPBM-SI）サブTLVに見出されます。パケットは、上記SPBMユニキャスト転送ごとにカプセル化されます。
Tandem replication uses the shortest path tree to replicate frames only where the tree forks and there is at least one receiver on each branch. Tandem replication is bandwidth efficient but uses multicast FDB entries (state) in core bridges, which might be unnecessary if there is little multicast traffic demand. The head-end replication mode is best suited for the case where there is little or no true multicast traffic for an I-SID. Tandem replication is triggered on transit nodes when the I-SID is advertised with the T bit set.
タンデム複製はどこツリーフォークフレームを複製する最短経路木を使用し、各ブランチ上の少なくとも一つの受信機があります。タンデム複製は、帯域幅が効率的ですが、少しマルチキャストトラフィックの需要がある場合は、不要であるかもしれないコアブリッジでのマルチキャストFDBエントリ（状態）を、使用しています。ヘッドエンドレプリケーションモードは、I-SIDのためにほとんど、あるいはまったく真のマルチキャストトラフィックがある場合に最適です。 I-SIDは、Tビットセットでアドバタイズされたときにタンデム複製は、トランジットノードにトリガされます。
Broadcast, unknown unicast, or multicast frames arriving at an SPBM UNI port are encapsulated with a B-DA multicast address that uniquely identifies the encapsulating node (the root of the Multicast Distribution Tree) and the I-SID scoping this multicast.
ブロードキャスト、未知のユニキャスト、またはSPBM UNIポートに到着したマルチキャストフレームを一意にカプセル化ノード（マルチキャスト配信ツリーのルート）とI-SIDスコープこのマルチキャストを識別するB-DAマルチキャストアドレスでカプセル化されています。
This B-DA address is a well-formed multicast group address (as per 802.1Q and 802.1ah) that concatenates the SPSourceID A' with the I-SID M (written as DA=<A',M> and uniquely identifying the (S,G) tree). This exact format is given in Figure 1 below:
このB-DAアドレスは '<、Mおよび一意の識別（I-SID M（DA = A>のように書くと' SPSourceID Aを連結（802.1Qおよび802.1ahのあたりなど）だけでなく、形成されたマルチキャストグループアドレスでありますS、G）木）。この正確な形式は、以下の図1に示されています。
M L TYP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0|SPSrcMS| SPSrc [8:15] | SPSrc [0:7] | I-SID [16:23] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID [8:15] | I-SID [0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SPBM Multicast Address Format
(SPSrcMS represents SPSrc [16:19])
Note: In Figure 1, the index numbering from less significant bit to more significant bit within a byte or field within a byte gives the wire order of the bits in the address consistent with the IETF format in the rest of this document. (The IEEE convention for number representation reverses the bits within an octet compared with IETF practice.)
注：図1では、下位ビットからのインデックス番号は、バイト内のバイトまたはフィールド内のより上位のビットは、この文書の残りのIETF形式と一致アドレスのビット線の順序を与えるために。 （数表現のためのIEEE規則は、IETFの練習に比べオクテット内のビットを反転させます。）
o M is the multicast bit, always set to 1 for a multicast DA. (It is the lowest bit in the most significant byte.)
O Mは常にマルチキャストDAのために1に設定され、マルチキャストビットです。 （これは、最上位バイトの最下位ビットです。）
o L is the local bit, always set to 1 for an SPBM-constructed multicast DA.
O Lは常にSPBMに構成マルチキャストDAのために1に設定され、ローカルビットです。
o TYP is the SPSourceID type. 00 is the only type supported at this time.
Oタイプは、SPのSourceIDタイプです。 00はこの時点でサポートされる唯一のタイプです。
o SPSrc (SPSourceID) is a 20-bit quantity that uniquely identifies a SPBM node for all B-VIDs allocated to SPBM operation. This is just the SPSourceID advertised in the SPB Instance (SPB-Inst) sub-TLV. The value SPSourceID = 0 has special significance; it is advertised by an SPBM node that has been configured to assign its SPSourceID dynamically, which requires LSDB synchronization, but where the SPSourceID assignment has not yet completed.
O SPSrc（SPSourceID）が一意SPBM動作に割り当てられたすべてのB-VIDのためSPBMノードを識別する20ビットの量です。これは単にSPBインスタンス（SPB-工大）サブTLVでアドバタイズSPSourceIDあります。値SPSourceID = 0は特別な意味を持っています。これは、LSDBの同期を必要とする、動的にSPSourceIDを割り当てるように構成されているが、SPSourceID割り当てがまだ完了していない場合SPBMノードによって通知されます。
o I-SID is the 24-bit I-Component Service ID advertised in the SPBM Service Identifier TLV. It occupies the lower 24 bits of the SPBM multicast DA. The I-SID value 0xfff is reserved for SPBM control traffic (refer to the default I-SID in [802.1aq]).
O I-SIDはSPBMサービス識別子TLVでアドバタイズ24ビットI成分サービスIDです。これはSPBMマルチキャストDAの下位24ビットを占有します。 I-SID値0xfffをSPBM制御トラフィックのために予約されている（[802.1aq]のデフォルトI-SIDを参照）。
This multicast address format is used as the DA on frames when they are first encapsulated at ingress to the SPBM network. The DA is also installed into the FDBs on all SPBM nodes that are on the corresponding SPT between the source and other nodes that have registered receiver interest in the same I-SID.
それらは最初SPBMネットワークへの入口でカプセル化される場合、このマルチキャストアドレスフォーマットは、フレーム上のDAとして使用されます。 DAは、同じI-SIDに受信対象として登録しているソースと他のノードとの間に対応するSPTにある全てSPBMノードにFDBsにインストールされています。
Just as with unicast forwarding, the B-SA/B-VID May be used to perform an ingress check, but the SPSourceID encoded in the DA and the "drop-on-unknown" functionality of the FDB in [PBB] achieve the same effect.
単にユニキャスト転送と同様に、B-SA / B-VIDは入力チェックを実行するために使用することができるが、SPSourceIDはDAと同じを達成[PBB]におけるFDBの「ドロップ・オン・不明」機能でエンコード効果。
The I-Component at the egress SPBM device has completely standard [PBB] behavior and therefore will:
出口SPBM装置におけるI成分は、完全に標準[PBB]挙動及び従って意志を持っています。
1) learn the remote C-SA to B-SA relationship and
1）B-SA関係リモートC-SAを習得と
2) bridge the original customer frame to the set of local UNI ports that are associated with the I-SID.
2）I-SIDに関連付けられているローカルUNIポートのセットに元の顧客のフレームを埋めます。
When a packet for an unknown DA arrives at an SPBV UNI port, VID translation (or VID encapsulation for untagged Frames) with the corresponding SPVID for this VLAN and ingress SPB is performed.
未知DAのためのパケットがSPBV UNIポートに到着すると、VID変換（またはタグなしフレームのためのVIDカプセル化）このVLANのための対応するSPVID有すると進入SPBが行われます。
SPVID forwarding is simply an SPT that follows normal VLAN forwarding behavior, with the exception that the SPVID is unidirectional. As a result, shared VLAN learning (SVL) is used between the forward- and reverse-path SPVIDs associated with the same Base VID to allow SPBV unicast forwarding to operate in the normal reverse learning fashion.
SPVID転送は単にSPVIDが単方向であることを除いて、通常のVLANの転送動作を以下SPTです。結果として、VLAN学習（SVL）はSPBVユニキャスト転送が正常逆学習方式で動作できるようにするために同じベースVIDに関連したフォワードおよびリバースパスSPVIDsの間で使用される共有。
Ingress check is done by simply verifying that the bridge to which the SPVID has been assigned is indeed "shortest path" reachable over the link over which the packet tagged with that SPVID arrived. This is computed from the IS-IS database and is implied when the SPVID is associated with a specific incoming port.
イングレスのチェックが簡単にSPVIDが割り当てられているブリッジが実際にそのSPVIDでタグ付けされたパケットが到着した上でリンク上で到達可能な「最短経路」であることを確認することによって行われます。これは、IS-ISデータベースから計算され、SPVIDが特定の着信ポートに関連付けられている場合暗示されます。
When a packet for a known DA arrives at an SPBV UNI port, VID translation (or VID encapsulation for untagged Frames) with the corresponding SPVID for this VLAN and ingress bridge is performed.
既知のDAのためのパケットがSPBV UNIポートに到着すると、このVLANおよび入力ブリッジの対応SPVIDとVID変換（またはタグなしフレームのためのVIDカプセル化）が行われます。
Since the SPVID will have been configured to follow a source-specific SPT and the DA is known, the packet will follow the source-specific path towards the destination C-MAC.
SPVIDソース固有SPTに追従するように構成されているであろうとDAが知られているので、パケットは、宛先C-MACに向かってソース固有の経路をたどります。
Ingress check is as per the previous SPBV section.
イングレスチェックは、前のSPBV区間ごとの通りです。
C-DA multicast addresses May be advertised from SPBV UNI ports. These may be configured or learned through the Multiple MAC Registration Protocol (MMRP). MMRP is terminated at the edge of the SPBV network and IS-IS carries the multicast addresses. Tandem SPBV devices will check to see if they are on the SPF tree between SPBV UNI ports advertising the same C-DA multicast address, and if so will install multicast state to follow the SPBV SPF trees.
C-DAマルチキャストアドレスはSPBV UNIポートから公示することができます。これらは、設定されるか、または複数のMAC登録プロトコル（MMRP）を通じて学習することができます。 MMRPはSPBVネットワークのエッジで終端され、IS-ISは、マルチキャストアドレスを運びます。そのSPBV SPFツリーに従うマルチキャストステートをインストールする場合はタンデムSPBVデバイスは、同じC-DAマルチキャストアドレスを広告するSPBV UNIポート間のSPFツリー上にあるかどうかをチェックし、かつます。
Ingress check is as per the previous two SPBV sections.
イングレスチェックは、前の2つのSPBVセクションごとの通りです。
Consider the small example network shown in Figure 2. Nodes are drawn in boxes with the last nibble of their B-MAC address :1..:7. The rest of the B-MAC address nibbles are 4455-6677-00xx. Links are drawn as "--" and "/", while the interface indexes are drawn as numbers next to the links. UNI ports are shown as "<==>" with the desired I-SID shown at the end of the UNI ports as "i1".
1 ..：2ノードは、そのB-MACアドレスの最後のニブルのボックスに描かれている図に示されている小さなネットワーク例を考える7。 B-MACアドレスニブルの残りの部分は4455-6677-00xxです。インターフェイスインデックスはリンクの横の数字として描かれている間、および「/」 - 「」のリンクは次のように描かれています。 UNIポートは「I1」としてUNIポートの端部に示され、所望のI-SIDと「<==>」として示されています。
+----+ +----+
| :4 | 2 ------1 | :5 | <==> i1
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1
+----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> i1
+----+ +----+
Figure 2: SPBM Example 7-Node Network
図2：SPBM例7ノードネットワーク
Using the default ECT-ALGORITHM (00-80-C2-01), which picks the equal cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned to B-VID 100. When all links have the same cost, then the 1-hop shortest paths are all direct and the 2-hop shortest paths (which are of course symmetric) are as follows:
次いで、1最低BridgeIDと同等のコストパスを選ぶデフォルトECTアルゴリズム（00から80-C2-01）を使用して、すべてのリンクが同じコストを有する場合、このECT-アルゴリズムはB-VID 100に割り当てられています-hop最短経路は、すべて直接的であり、次のように（もちろん対称である）2ホップの最短経路です。
{ 1-2-3, 1-2-5, 1-2-7, 6-2-5, 4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 }
｛ １ー２ー３、 １ー２ー５、 １ー２ー７、 ６ー２ー５、 ４ー２ー７、 ４ー１ー６、 ５ー２ー７、 ６ー２ー３、 ４ー２ー３ ｝
Node :1's unicast forwarding table therefore routes toward B-MACs :7, :3, and :5 via interface/2, while its single-hop paths are all direct as can be seen from its FDB given in Figure 3.
ノード：1のユニキャスト転送テーブルしたがって、B-MACを向けて経路：7：3、および：5インターフェース/ 2を介して、図3に示すそのFDBから分かるように、そのシングルホップ経路が全て直接されています。
Node :1 originates multicast since it is at the head of the MDT to nodes :3, :5, and :7 and is a transmitter of I-SID 1, which nodes :3, :5, and :7 all wish to receive. Node :1 therefore produces a multicast forwarding entry whose DA contains its SPSourceID (which is the last 20 bits of the B-MAC in the example) and the I-SID 1. Node :1 thereafter sends packets matching this entry to interface if/2 with B-VID=100. Node :1's full unicast (U) and multicast (M) table is shown in Figure 3. Note that the IN/IF (incoming interface) field is not specified for unicast traffic, and for multicast traffic has to point back to the root of the tree, unless it is the head of the tree -- in which case, we use the convention if/00. Since node :1 is not transit for any multicast, it only has a single entry for the root of its tree for I-SID=1.
ノード：すべてが受信したい7：3：1は、それがノードにMDTの先頭にあるので、マルチキャストを発信5、及び7とノードI-SID 1の送信機である：3：5、及び。ノード1は、したがってDAその（B-MACの例での最後の20ビット）SPSourceIDとI-SID 1ノードを含むマルチキャスト転送エントリを生成する：1その後/ IFインターフェースするように、このエントリに一致するパケットを送信します。 B-VID = 100を持つ2。ノード：1のフルユニキャスト（U）及びマルチキャスト（M）テーブルは、IN / IF（着信インターフェイス）フィールドは、ユニキャストトラフィックのために指定され、マルチキャストトラフィックの背面のルートを指すように有していないことを図3（注）に示されています木、それは木の頭でなければ - / 00場合、我々は規則を使用している場合には。ノード以来：1は、任意のマルチキャストのための通過ではない、それだけI-SID = 1のためにそのツリーのルートのための単一のエントリを有します。
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0002 | 0100 | {if/2 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/1 }
U| if/** | 4455-6677-0005 | 0100 | {if/2 }
U| if/** | 4455-6677-0006 | 0100 | {if/3 }
U| if/** | 4455-6677-0007 | 0100 | {if/2 }
M| if/00 | 7300-0100-0001 | 0100 | {if/2 }
Figure 3: SPBM Node :1 FDB - Unicast (U) and Multicast (M)
図3：SPBMノード：1 FDB - ユニキャスト（U）及びマルチキャスト（M）
Node :2, being at the center of the network, has direct 1-hop paths to all other nodes; therefore, its unicast FDB simply sends packets with the given B-MAC/B-VID=100 to the interface directly to the addressed node. This can be seen by looking at the unicast entries (the first 6) shown in Figure 4.
ノード2は、ネットワークの中心にある、他のすべてのノードに直接1ホップ経路を有します。従って、そのユニキャストFDBは単に宛先ノードに直接インターフェースに与えられるB-MAC / B-VID = 100を持つパケットを送信します。これは、図4に示されているユニキャストエントリ（第6）を見て見ることができます。
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0001 | 0100 | {if/1 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/4 }
U| if/** | 4455-6677-0005 | 0100 | {if/3 }
U| if/** | 4455-6677-0006 | 0100 | {if/6 }
U| if/** | 4455-6677-0007 | 0100 | {if/5 }
M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 }
M| if/02 | 7300-0300-0001 | 0100 | {if/1 }
M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 }
M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 }
Figure 4: SPBM Node :2 FDB Unicast (U) and Multicast (M)
図4：SPBMノード：2 FDBユニキャスト（U）及びマルチキャスト（M）
Node :2's multicast is more complicated since it is a transit node for the 4 members of I-SID=1; therefore, it requires 4 multicast FDB entries depending on which member it is forwarding/replicating on behalf of. For example, node :2 is on the shortest path between each of nodes {:3, :5, :7} and :1. So it must replicate from node :1 I-SID 1 out on interfaces { if/2, if/3 and if/5 } (to reach nodes :3, :5, and :7). It therefore creates a multicast DA with the SPSourceID of node :1 together with I-SID=1, which it expects to receive over interface/1 and will replicate out interfaces { if/2, if/3 and if/5 }. This can be seen in the first multicast entry in Figure 4.
ノードは：それはI-SID = 1の4人のメンバーのトランジットノードであるので、2のマルチキャストは、より複雑です。従って、それは代わって複製/転送される部材に応じて4つのマルチキャストFDBエントリを必要とします。例えば、ノード：及び{7：、5：、3}：2は、各ノード間の最短パス上にある1。 {/ 3の場合、IF / 2/5あれば}インターフェイス上で1つのI-SID 1（ノード到達する：3：5、及び7）ので、ノードから複製しなければなりません。それはインタフェース/ 1上で受信することを期待するとインターフェースを複製するI-SID = 1、と一緒に1 {/ 3と、/ 2の場合とIF / 5}：したがって、ノードのSPSourceIDとマルチキャストDAを作成します。これは、図4における第一のマルチキャストエントリに見ることができます。
Note that node :2 is not on the shortest path between nodes :3 and :5 nor between nodes :3 and :7; however, it still has to forward packets to node :1 from node :3 for this I-SID, which results in the second multicast forwarding entry in Figure 4. Likewise, for packets originating at nodes :5 or :7, node :2 only has to replicate twice, which results in the last two multicast forwarding entries in Figure 4.
そのノードに注意してください：3と：5もノード間：3：2ノード間の最短経路上にない7。しかし、それはまだノードにパケットを転送しなければならない：1ノードから：5または：7、ノード：ノードから発信するパケットのために、同様に図4の第2のマルチキャスト転送エントリになるこのI-SID、3 2のみ図4の最後の2つのマルチキャスト転送エントリで、その結果、二回複製しなければなりません。
Using the same example network as Figure 2, we will look at the FDBs produced for SPBV mode forwarding. Nodes :1, :5, :3, and :7 wish to transmit and receive the same multicast MAC traffic using multicast address 0300-0000-000f and at the same time require congruent and symmetric unicast forwarding. In SPBV mode, the only encapsulation is the C-TAG or S-TAG, and the MAC addresses SA and DA are reverse-path learned, as in traditional bridging.
図2と同一のネットワーク例を使用して、我々はSPBVモード転送のために作らFDBsを見ていきます。ノード：1：5：3、及び7願い送受信同じマルチキャストMACトラフィックをマルチキャストアドレス0300-0000-000fを使用して、同時に合同対称ユニキャスト転送を要求します。 SPBVモードでは、唯一のカプセル化は、C-TAG又はS-TAGであり、MACはSAおよびDAは、従来のブリッジのように、逆経路学習されるアドレス。
+----+ +----+
| :4 | 2 ------1 | :5 | <==> MMAC ..:f
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f
..:f +----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> MMAC ..:f
+----+ +----+
Figure 5: SPBV Example 7-Node Network
図5：SPBV例7ノードネットワーク
Assuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned to Base VID 100, and for each node the SPVID = Base VID + Node ID (i.e., 101, 102..107). When all links have the same cost, then the 1-hop shortest paths are all direct, and the 2-hop shortest paths (which are of course symmetric) are as previously given for Figure 2.
SPVID =ベースVID +ノードID最低BridgeIDと同等のコストパスを選ぶ同じECTアルゴリズム（00から80-C2-01）を仮定すると、このECTアルゴリズムがベースVID 100に割り当てられ、各ノードの（すなわち、101、102..107）。すべてのリンクが同じコストを有するときに、その後1ホップ最短経路は全て直接であり、（もちろん対称である）2ホップ最短経路は、先に図2について説明されています。
Node :1's SPT for this ECT-ALGORITHM is therefore (described as a sequence of unidirectional paths):
ノード：このECTアルゴリズム1のSPTは、したがって、（一方向パスのシーケンスとして説明されます）。
{ 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 }
｛ １ー＞４、 １ー＞６、 １ー＞２ー＞３、 １ー＞２ー＞５、 １ー＞２ー＞７ ｝
The FDBs therefore must have entries for the SPVID reserved for packets originating from node :1, which in this case is VID=101.
この場合、VID = 101である1：FDBsしたがってノードから発信するパケットのために予約さSPVIDのエントリを有していなければなりません。
Node :2 therefore has an FDB that looks like Figure 6. In particular, it takes packets from VID 101 on interface/01 and sends to nodes :3, :5, and :7 via if/2, if/3, and if/5. It does not replicate anywhere else because the other nodes (:4 and :6) are reached by the SPT directly from node :1. The rest of the FDB unicast entries follow a similar pattern; recall that the shortest path between :4 and :6 is via node :1, which explains replication onto only two interfaces from if/4 and if/6. Note that the destination addresses are wild cards, and SVL exists between these SPVIDs because they are all associated with Base VID = 100, which defines the VLAN being bridged.
ノード：/ 3の場合、及び場合、IF / 2を介し7：具体的には、図6のようになり、そのFDBを有している2は、したがって、それがインターフェイス/ 01にVID 101からパケットを受け取り、ノードに送信：3：5、及び/ 5。それはどこにも複製しない他のノード理由（：4および6）を直接ノードからSPTによって達成される：1。 FDBユニキャストエントリの残りの部分は、同様のパターンに従います。 4と：6ノードを介してである：1、4 / IF及び6 / IFから2つだけのインターフェイス上の複製を説明している間の最短経路は、そのリコール。宛先アドレスがワイルドカードであることに注意してください、そして、それらはすべてのVLANがブリッジされる定義ベースVID = 100、関連付けられているので、SVLは、これらSPVIDs間に存在します。
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/01 | ************** | 0101 | {if/2,if/3,if/5 }
U| if/02 | ************** | 0103 | {if/1,if/4,if/6 }
U| if/04 | ************** | 0104 | {if/2,if/5 }
U| if/03 | ************** | 0105 | {if/1,if/5,if/6 }
U| if/06 | ************** | 0106 | {if/2,if/3 }
U| if/05 | ************** | 0107 | {if/1,if/3,if/4 }
Figure 6: SPBV Node :2 FDB Unicast
図6：SPBVノード：2 FDBユニ
Now, since nodes :5, :3, :7 and :1 are advertising membership in the same multicast group address :f, Node 2 requires additional entries to replicate just to these specific nodes for the given multicast group address. These additional multicast entries are given below in Figure 7.
さて、ノード以降：5：3：7と：1が同一のマルチキャストグループアドレスのメンバシップを宣伝している：F、ノード2は、単に特定のマルチキャストグループアドレスのためのこれらの特定のノードに複製するために追加のエントリが必要です。これらの追加のマルチキャストエントリを図7に以下に与えられます。
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 }
M| if/02 | 0300-0000-000f | 0103 | {if/1 }
M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 }
M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 }
Figure 7: SPBV Node :2 FDB Multicast (M)
図7：SPBVノード：2 FDBマルチキャスト（M）
IS-IS for SPB currently only supports peer-to-peer adjacencies. Other link types are for future study. As a result, pseudonodes and links to/from pseudonodes are not considered as part of the IS-IS SPF computations and will be avoided if present in the physical topology. Other NLPIDs MAY of course use them as per normal.
SPBのためのIS-ISは、現在唯一のピア・ツー・ピアの隣接関係をサポートしています。その他のリンクタイプは、将来の検討課題です。その結果、擬似ノードへ/からの擬似ノード及びリンクはIS-IS SPF計算の一部として考慮されておらず、物理トポロジ内に存在する場合に回避されます。もちろん、他のNLPIDs MAYは通常通りそれらを使用しています。
IS-IS for SPB Must use the IS-IS three-way handshake for IS-IS point-to-point adjacencies described in RFC 5303.
SPBは、RFC 5303で説明IS-ISポイントツーポイント隣接関係のためのIS-ISスリーウェイハンドシェイクを使用する必要がありますするためにIS-IS。
The default behavior of 802.1aq is to use the normal IS-IS Ethernet multicast addresses for IS-IS.
802.1aqのデフォルトの動作は、IS-ISのために、通常のIS-ISイーサネットマルチキャストアドレスを使用することです。
There are however additional Ethernet multicast addresses that have been assigned for 802.1aq for special use cases. These do not in any way change the state machinery or packet formats of IS-IS but simply recommend and reserve different multicast addresses. Refer to [802.1aq] for additional details.
特殊なユースケースのために802.1aqのために割り当てられている。しかし、追加のイーサネットマルチキャストアドレスがあります。これらは、どのような方法でIS-ISの状態機械またはパケットフォーマットを変更するが、単に別のマルチキャストアドレスを推奨し、予約しません。詳細については[802.1aq]を参照してください。
A stand-alone implementation (supporting ONLY the single NLPID=0xC1) of SPB Must use an IS-IS area address value of 0, and the SYSID Must be the well-known MAC address of the SPB device.
SPBのスタンドアロン実装（単一NLPID = 0xC1を支持する）が0のIS-IS領域のアドレス値を使用しなければならず、SYSIDはSPB装置のよく知られたMACアドレスである必要があります。
Non-stand-alone implementations (supporting other NLPIDs) MUST use the normal IS-IS rules for the establishment of a level 1 domain (i.e., multiple area addresses are allowed only where immediate adjacencies share a common area address). Level 2 operations of course place no such restriction on adjacent area addresses.
（他のNLPIDsを支持する）非スタンドアロンの実装が使用しなければならない通常のIS-ISレベル1ドメインの確立のための規則（即時隣接関係が共通領域のアドレスを共有する場合、すなわち、複数の領域のアドレスのみ許可されています）。もちろん、レベル2の操作は、隣接する領域のアドレスにそのような制限を置きません。
SPBV and SPBM will operate within either an IS-IS level 1 or level 2. As a result, the TLVs specified here MAY propagate in either level 1 or level 2 LSPs. IS-IS SPB implementations Must support level 1 and May support level 2 operations. Hierarchical SPB is for further study; therefore, these TLVs Should Not be leaked between level 1 and level 2.
SPBVとSPBMが結果IS-ISレベル1またはレベル2のいずれかの中に動作する、のTLVは、ここで指定されたレベル1又はレベル2のいずれかのLSPに伝搬することができます。 SPBの実装はレベル1をサポートしている必要がありますし、レベル2の操作をサポートすることが可能でIS-IS。階層SPBは、今後の検討課題です。そのため、これらのTLVは、レベル1とレベル2の間で漏れたべきではありません。
The default algorithm is ECT-Algorithm = 00-80-c2-01.
デフォルトのアルゴリズムは、ECT-アルゴリズム= 00から80-c2-01です。
Two mechanisms are used to ensure symmetry and determinism in the shortest path calculations.
二つの機構が最短経路計算の対称性と確定性を確保するために使用されます。
The first mechanism addresses the problem when different ends (nodes) of an adjacency advertise different values for the SPB-LINK-METRIC. To solve this, SPB shortest path calculations Must use the maximum value of the two nodes' advertised SPB-LINK-METRICs when accumulating and minimizing the (sub)path costs.
第1の機構は、隣接の異なる端部（ノード）SPB-LINK-メトリックの異なる値をアドバタイズする問題に対処します。これを解決するために、SPB最短パス計算は、2つのノードの最大値を使用する必要がありますアドバタイズSPB-LINK-メトリック蓄積及び（副）経路コストを最小限に抑えます。
The second mechanism addresses the problem when two equal sums of link metrics (sub)paths are found. To solve this, the (sub)path with the fewest hops between the fork/join points Must win the tie. However, if both (sub)paths have the same number of hops between the fork and join points, then the default tie-breaking Must pick the path traversing the intermediate node with the lower BridgeID. The BridgeID is an 8-byte quantity whose upper 2 bytes are the node's BridgePriority and lower 6 bytes are the node's SYSID.
第2のメカニズムは、リンク・メトリックの二つの等しい和（サブ）パスが見つかった問題に対処します。これを解決するために、フォーク/ジョインポイント間の最も少ないホップを有する（サブ）パスがネクタイを勝たなければなりません。両方（サブ）経路がフォーク間のホップ数が同じと点を結ぶ場合は、デフォルトのタイブレークは、より低いBridgeID有する中間ノードを通過するパスを選択する必要があります。 BridgeIDは、その上位2バイトであるノードのBridgePriorityと下位6つのバイトはノードのSYSIDである8バイトの量です。
For example, consider the network in Figure 2 when a shortest path computation is being done from node :1. Upon reaching node :7, two competing sub-paths fork at node :1 and join at node :7, the first via :2 and the second via :6. Assuming that all the nodes advertise a Bridge Priority of 0, the default tie-breaking rule causes the path traversing node :2 to be selected since it has a lower BridgeID {0...:2} than node :6 {0...:6}. Note that the operator may cause the tie-breaking logic to pick the alternate path by raising the Bridge Priority of node :2 above that of node :6.
1：例えば、最短経路計算ノードから行われている図2のネットワークを考えます。ノード到達時：7を、2ノードでサブパスフォーク競合：1ノードに参加：7、第一経由：2及び第介し：6。ノードより：それは低いBridgeID {2 0 ...}有するので選択される2：すべてのノードが0のブリッジプライオリティをアドバタイズすると仮定すると、デフォルトのタイブレーク規則はパス横断ノードを引き起こす{0 6 .. 。：6}。オペレータは、ノードのブリッジプライオリティを上げることによって、代替パスを選択するタイブレークロジックを引き起こし得ることに注意：ノードと上記2：6。
The above algorithm guarantees symmetric and deterministic results in addition to having the critical property of transitivity (shortest path is made up of sub-shortest paths).
上記のアルゴリズムは、推移の重要な特性を（最短経路は、サブ最短パスで構成されている）を有することに加えて、対称と決定論的結果を保証します。
Standard ECT Algorithms initially have been proposed ranging from 00-80-c2-01 to 00-80-c2-10.
標準ECTアルゴリズムは、最初は00から80-c2-01 00から80-C2-10に至るまで提案されています。
To create diversity in routing, SPB defines 16 variations on the above default tie-breaking algorithm; these have worldwide unique designations 00-80-C2-01 through 00-80-C2-10. These designations consist of the IEEE 802.1 OUI (Organizationally Unique Identifier) value 00-80-C2 concatenated with indexes 0X01..0X10. These individual algorithms are implemented by selecting the (sub)path with the lowest value of:
ルーティングの多様性を作成するために、SPBは、上記のデフォルトタイブレークアルゴリズム上の16部の変形を定義します。これらは、世界的にユニークな名称00から80-C2-10て00から80-C2-01を持っています。これらの指定は、インデックス0X01..0X10と連結IEEE 802.1 OUI（組織固有識別子）値00から80-C2から成ります。これらの個々のアルゴリズムは、の最小値（サブ）パスを選択することによって実現されます。
XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID)
バイトでXORバイト（ECT-MASK {ECT-ALGORITHM.index}、BridgeID）
Where:
どこ：
ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88,
0x77, 0x44, 0x33, 0xCC,
0xBB, 0x22, 0x11, 0x66,
0x55, 0xAA, 0x99, 0xDD,
0xEE };
XOR BYTE BY BYTE - XORs BridgeID bytes with ECT-MASK
BYTE BY XORのBYTE - のXOR BridgeIDはECT-MASKでバイト
ECT-MASK{1}, since it XORs with all zeros, yields the default algorithm described above (00-80-C2-01); while ECT-MASK{2}, since it XORs with a mask of all ones, will invert the BridgeID, essentially picking the path traversing the largest Bridge ID. The other ECT-MASKs produce diverse alternatives. In all cases, the BridgePriority, since it is the most significant part of the BridgeID, permits overriding the SYSID as the selection criteria and gives the operator a degree of control on the chosen ECT paths.
ECT-MASK {1}、それが全てゼロで排他的論理和演算するので、（00から80-C2-01）上述のデフォルトのアルゴリズムをもたらします。それはすべてのもののマスクを用いて排他的論理和演算ので、ECT-MASK {2}、BridgeIDを反転する一方、実質的に最大のブリッジIDを横切るパスを選びます。他のECT-マスクは多様な選択肢を作ります。それはBridgeIDの最も重要な部分であるので、すべての場合において、BridgePriorityは、選択基準としてSYSIDをオーバーライド可能にし、オペレータに選択されたECT経路上のコントロールの程度を与えます。
To support many other tie-breaking mechanisms in the future, two opaque ECT TLVs are defined, which may be used to provide parameters to ECT-ALGORITHMs outside of the currently defined space.
将来的には他の多くのタイブレークのメカニズムをサポートするために、二つの不透明ECTのTLVは、現在定義された空間の外部ECT-アルゴリズムにパラメータを提供するために使用することができる、定義されています。
ECT-ALGORITHMs are mapped to VIDs, and then services can be assigned to those VIDs. This permits a degree of traffic engineering since service assignment to VID is consistent end to end through the network.
ECT-アルゴリズムは、VIDのにマッピングされ、その後、サービスはこれらのVIDに割り当てることができます。 VIDへのサービスの割り当ては、ネットワークを介して、エンドツーエンド一貫性があるので、これはトラフィックエンジニアリングの学位を可能にします。
IEEE 802.1aq can run in parallel with other network layer protocols such as IPv4 and IPv6; therefore, failure of two SPB nodes to establish an adjacency MUST NOT cause rejection of an adjacency for the purposes of other network layer protocols.
IEEE 802.1aqは、IPv4とIPv6のような他のネットワーク層プロトコルと並行して実行することができます。そのため、隣接関係を確立するための2つのSPBノードの障害が他のネットワーク層プロトコルの目的のために隣接の拒絶反応を引き起こしてはなりません。
IEEE 802.1aq has been assigned the NLPID value 0xC1 [RFC6328], which MUST be used by Shortest Path Bridges (SPBs) to indicate their ability to run 802.1aq. This is done by including this NLPID value in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq frames MUST only flow on adjacencies that advertise this NLPID in both directions of the IIH PDUs. 802.1aq computations MUST consider an adjacency that has not advertised 0xC1 NLPID in both directions as non-existent (infinite link metric) and MUST ignore any IIH SPB TLVs they receive over such adjacencies.
IEEE 802.1aqは802.1aqを実行する能力を示すために、最短パスブリッジ（のSPB）によって使用されなければならない、NLPID値0xC1 [RFC6328]を割り当てられています。これは、IS-IS IIH PDUプロトコルにおけるこのNLPID値を含むことによって行われるTLV（タイプ129）サポートされています。 802.1aqフレームのみがIIH PDUの両方向にこのNLPIDを宣伝隣接に流れなければなりません。 802.1aq計算は存在しない（無限のリンクメトリック）として両方向に0xC1 NLPIDをアドバタイズしていない隣接関係を考慮する必要があり、彼らはそのような隣接上受け取る任意IIH SPB TLVを無視しなければなりません。
IEEE 802.1aq augments the normal IIH PDU with three new TLVs, which like all other SPB TLVs, travel within Multi-Topology [MT] TLVs, therefore allowing multiple logical instances of SPB within a single IS-IS protocol instance.
IEEE 802.1aqは、他のすべてのSPBのTLV、マルチトポロジ[MT]のTLV内の旅行のよう従って単一IS-ISプロトコルインスタンス内SPBの複数の論理インスタンスを可能つの新しいTLVを、法線IIH PDUを増強します。
Since SPB can use many VIDs and Must agree on which VIDs are used for which purposes, the IIH PDUs carry a digest of all the used VIDs (on the NNIs) referred to as the SPB-MCID TLV, which uses a common and compact encoding reused from 802.1Q.
SPBは、多くのVIDを使用することができるとのVIDがその目的のために使用されている同意しなければならないので、IIH PDUが（NNI上）全く使用のVIDのダイジェストと呼ば運ぶ一般的でコンパクトなエンコーディングを使用SPB-MCID TLVとして802.1Qから再利用。
SPB neighbors May support a mechanism to verify that the contents of their topology databases are synchronized (for the purposes of loop prevention). This is done by exchanging a digest of SPB topology information (computed over all MT IDs) and taking specific actions on forwarding entries when the digests indicate a mismatch in topology. This digest is carried in the Optional SPB-Digest sub-TLV.
SPBの隣人は彼らのトポロジーデータベースの内容は、（ループ防止のために）同期していることを検証するメカニズムをサポートすることができます。これは、（すべてのMTのIDにわたって計算）ダイジェストSPBのトポロジー情報を交換し、ダイジェストがトポロジーの不一致を示す場合の転送エントリに特定のアクションを取ることによって行われます。このダイジェストは、オプションのSPB-ダイジェストサブTLVで運ばれます。
Finally, SPB needs to know which SPT Sets (defined by ECT-ALGORITHMs) are being used by which VIDs, and this is carried in the Base VLAN Identifiers (SPB-B-VID) sub-TLV.
最後に、SPBは、SPTセットが（ECT-アルゴリズムによって定義される）はのVIDによって使用されているかを知る必要があり、これはベースVLAN識別子（SPB-B-VID）サブTLVで搬送されます。
This sub-TLV is added to an IIH PDU to indicate the digest for the multiple spanning tree configuration a.k.a. MCID. This TLV is a digest of local configuration of which VIDs are running which protocols. (The information is not to the level of a specific algorithm in the case of SPB.) This information Must be the same on all bridges in the SPT Region controlled by an IS-IS instance. The data used to generate the MCID is populated by configuration and is a digest of the VIDs allocated to various protocols. Two MCIDs are carried to allow non-disruptive transitions between configurations when the changes are non-critical.
このサブTLVは、MCID別名マルチプルスパニングツリー構成のダイジェストを示すためにIIH PDUに追加されます。このTLVはのVIDがどのプロトコルを実行しているのローカル設定のダイジェストです。 （情報は、SPBの場合に特定のアルゴリズムのレベルではない。）この情報は、IS-ISインスタンスによって制御SPT地域内のすべてのブリッジで同じでなければなりません。 MCIDを生成するために使用されるデータは、コンフィギュレーションによって移入し、様々なプロトコルに割り当てられたのVIDのダイジェストです。二つするMCIDは変化が非決定的であるとき、コンフィギュレーションの間で無停止移行を可能にするために実施されています。
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=SPB-MCID | = 4
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCID (51 Bytes) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aux MCID (51 Bytes) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 4.
O型：サブTLVのタイプ4。
o Length: The size of the value defined below (102).
O長さ（102）の下に定義された値の大きさ。
o MCID (51 bytes): The complete MCID defined in IEEE 802.1Q, which identifies an SPT Region on the basis of matching assignments of VIDs to control regimes (xSTP, SPBV, SPBM, etc.). Briefly, the MCID consists of a 1-byte format selector, a 32-byte configuration name, a 2-byte revision level, and finally a 16-byte signature of type HMAC-MD5 over an array of 4096 elements that contain identifiers of the use of the corresponding VID. Refer to Section 13.8 of [802.1aq] for the exact format and procedure. Note that the use of the VID does not include specification of a specific SPB ECT-ALGORITHM; rather, it is coarser grain.
O MCID（51バイト）：レジーム（XSTP、SPBV、SPBM、等）を制御するためのVIDの割り当てを一致に基づいて、SPT領域を特定するIEEE 802.1Qで定義された完全MCID、。簡潔には、MCIDは、1バイトのフォーマットセレクタで構成され、32バイトのコンフィギュレーション名、2バイトのリビジョンレベル、および識別子を含む4096個の素子のアレイ上型HMAC-MD5の最後に16バイトの署名対応するVIDを使用します。正確な形式および手順について[802.1aq]のセクション13.8を参照。 VIDの使用は、特定のSPB ECT-アルゴリズムの仕様が含まれていないことに注意してください。むしろ、それは粗い木目です。
o Aux MCID (51 bytes): The complete MCID defined in IEEE 802.1Q, which identifies an SPT Region. The aux MCID allows SPT Regions to be migrated by the allocation of new VLAN to FDB Mappings without interruption to existing traffic.
O補助MCID（51バイト）：SPT領域を特定するIEEE 802.1Qで定義完全MCID。 AUX MCIDは、SPTの地域は、既存のトラフィックに中断することなく、FDBのマッピングに新しいVLANの割り当てによって移行することができます。
The SPB-MCID sub-TLV is carried within the MT-Port-Cap TLV [RFC6165] with the MT ID value of 0, which in turn is carried in an IIH PDU.
SPB-MCIDサブTLVは、順番にIIH PDUで運ばれる0のMT ID値を持つMT-ポートキャップTLV [RFC6165]内で実施されます。
This sub-TLV is Optionally added to an IIH PDU to indicate the current SPB topology digest value. It is always carried in an MT-Port-Cap TLV [RFC6165] with an MT ID value of 0. This information should settle to be the same on all bridges in an unchanging topology. Matching digests indicate (with extremely high probability) that the topology view between two SPBs is synchronized; this match (or lack of match) is used to control the updating of forwarding information. The SPB Agreement Digest is computed based on contributions derived from the current topologies of all SPB MT instances and is designed to change when significant topology changes occur within any SPB instance.
このサブTLVは、必要に応じて、現在のSPBトポロジはダイジェスト値を示すためにIIH PDUに追加されます。常にこの情報は不変のトポロジ内のすべてのブリッジで同じになるように落ち着くはずです0のMT ID値でMT-ポートキャップTLV [RFC6165]で運ばれます。一致するダイジェストは、二つのSPBの間でトポロジビューが同期されていることを（非常に高い確率で）を示します。この一致（または一致の欠如）が転送情報の更新を制御するために使用されます。 SPB契約ダイジェストは、すべてのSPB MTインスタンスの現在のトポロジに由来する寄与に基づいて計算され、有意なトポロジの変更は、任意のSPBインスタンス内で発生したときに変化するように設計されています。
During the propagation of LSPs, the Agreement Digest may vary between neighbors until the key topology information in the LSPs is common. The digest is therefore a summarized means of determining agreement between nodes on database commonality, and hence of inferring agreement on the distance to all multicast roots. When present, it is used for loop prevention as follows: for each shortest path tree where it has been determined the distance to the root has changed, "unsafe" multicast forwarding is blocked until the exchanged Agreement Digests match, while "safe" multicast forwarding is allowed to continue despite the disagreement in digests and hence topology views. Section 28.2 of [802.1aq] defines in detail what constitutes "safe" vs. "unsafe".
LSPにおける鍵トポロジ情報が共通になるまでのLSPの伝播中に、契約ダイジェストは、ネイバー間で変化してもよいです。ダイジェストは、したがって、データベースの共通のノードとの間の一致を決定するまとめ手段であるため、すべてのマルチキャストルートまでの距離に合意を推定します。次のように存在する場合、それはループ防止のために使用される：変更されたルートまでの距離を決定された各最短パス木のために、「安全でない」マルチキャスト転送は、一方「安全な」マルチキャスト転送、交換契約ダイジェストが一致するまでブロックされていますダイジェストので、トポロジビューの不一致にもかかわらず、継続することができます。 [802.1aq]のセクション28.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=SPB-Digest| = 5
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-----+-+---+---+
| Res |V| A | D | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreement Digest (Length - 1) |
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 5.
O型：サブTLVのタイプ5。
o Length: The size of the value.
Oの長さ：値のサイズ。
o V bit: Agreed digest valid bit. See Section 28.2 of [802.1aq].
OのVビット：合意の有効ビットを消化。 [802.1aq]のセクション28.2を参照してください。
o A (2 bits): The Agreement Number 0-3, which aligns with the BPDU's Agreement Number concept [802.1aq]. When the Agreement Digest for this node changes, this number is incremented. The node then checks for Agreement Digest match (as below). The new local Agreement Number and the updated local Discarded Agreement Number are then transmitted with the new Agreement Digest to the node's neighbors in the Hello PDU. Once an Agreement Number has been sent, it is considered outstanding until a matching or more recent Discarded Agreement Number is received from the neighbor.
BPDUの契約番号の概念[802.1aq]と整列契約番号0-3、（2ビット）O。契約ダイジェストは、このノードの変化のために、この番号はインクリメントされた場合。ノードは、（以下のような）契約ダイジェストの一致をチェックします。新しいローカル契約番号及び更新されたローカル廃棄契約番号は、その後のHello PDU内のノードの近隣に新しい契約ダイジェストで送信されます。契約番号が送信されると、一致またはより最近の廃棄契約番号は、ネイバーから受信されるまで、それが優れたと考えられています。
o D (2 bits): The Discarded Agreement Number 0-3, which aligns with BPDU's Agreement Number concept. When an Agreement Digest is received from a neighbor, this number is set to the received Agreement Number to signify that this node has received this new agreement and discarded any previous ones. The node then checks whether the local and received Agreement Digests match. If they do, this node then sets:
O D（2ビット）：BPDUの契約数の概念と整合廃棄契約番号0-3、。契約ダイジェストがネイバーから受信した場合、この数は、このノードは、この新たな合意を受け、任意の前のものを廃棄したことを意味するために、受信した契約番号に設定されています。ノードは、ローカルおよび契約ダイジェストの一致を受信したかどうかをチェックします。彼らが行う場合は、このノードは、設定しています。
the local Discarded Agreement Number = received Agreement Number + 1
ローカル廃棄契約番号=契約番号+ 1を受信しました
If the Agreement Digests match, AND received Discarded Agreement Number == local Agreement Number + N (N = 0 || 1)
契約が一致し、受信した廃棄契約番号を消化した場合==ローカル契約番号+ N（N = 0 || 1）
then the node has a topology matched to its neighbor.
その後、ノードは、その隣人にマッチしたトポロジーを有します。
Whenever the local Discarded Agreement Number relating to a neighbor changes, the local Agreement Digest, Agreement Number, and Discarded Agreement Number are transmitted.
たび隣人の変化に関連するローカル廃棄契約番号は、地元の契約ダイジェスト、契約数、および廃棄契約番号が送信されます。
o Agreement Digest. This digest is used to determine when SPB is synchronized between neighbors for all SPB instances. The Agreement Digest is a hash computed over the set of all SPB adjacencies in all SPB instances. In other words, the digest includes all VIDs and all adjacencies for all MT instances of SPB (but not other network layer protocols). This reflects the fact that all SPB nodes in a region Must have identical VID allocations (see Section 13.1), and so all SPB instances will contain the same set of nodes. The exact procedure for computing the Agreement Digest and its size are defined in Section 28.2 of [802.1aq].
契約ダイジェストO。このダイジェストは、SPBはすべてのSPBインスタンスのネイバー間で同期されるときを決定するために使用されます。契約ダイジェストは、すべてのSPBインスタンス内のすべてのSPBの隣接のセットに対して計算されたハッシュです。換言すれば、ダイジェストは、SPB（ただし、他のネットワーク層プロトコル）の全てのMTインスタンスのすべてのVID及びすべての隣接を含みます。これは、地域のすべてのSPBのノードが同じVIDの割り当てを（13.1節を参照）を持っている必要があり、そのため、すべてのSPBのインスタンスが同じノードセットが含まれているという事実を反映しています。契約ダイジェストとその大きさを計算するための正確な手順は、[802.1aq]のセクション28.2で定義されています。
The SPB-Digest sub-TLV is carried within the MT-Port-Cap TLV [RFC6165] (with the MT ID value 0), which in turn is carried in an IIH PDU.
SPB-ダイジェストサブTLVは、順番にIIH PDUで運ばれる、（MT ID値0を有する）MTポートキャップTLV [RFC6165]内で実施されます。
When supported, this sub-TLV MUST be carried on every IIH between SPB neighbors, not just when a Digest changes.
サポートされている場合は、このサブTLVは、ダイジェストが変わるときだけでなく、すべてのIIH SPB間の隣人に実施しなければなりません。
When one peer supports this TLV and the other does not, loop prevention by Agreement Digest Must Not be done by either side.
一方のピアはこのTLVをサポートしており、他にはない場合は、契約書のダイジェストにより、ループ防止は、どちらの側で行われてはなりません。
This sub-TLV is added to an IIH PDU to indicate the mappings between ECT algorithms and Base VIDs (and by implication the VID(s) used on the forwarding path for each SPT Set for a VLAN identified by a Base VID) that are in use. Under stable operational conditions, this information should be the same on all bridges in the topology identified by the MT-Port-Cap TLV [RFC6165] it is being carried within.
このサブTLVはECTアルゴリズムとベースのVIDとの間のマッピングを示すためにIIH PDUに追加される（そして含意によってベースVIDによって識別VLAN各SPTセットの転送経路上で使用されるVID（S））であることつかいます。安定した動作条件の下では、この情報は、それが中に実施されているMT-ポートキャップTLV [RFC6165]で識別されるトポロジ内のすべてのブリッジで同じである必要があります。
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= SPB-B-VID| = 68
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-----------------------------------------------+
| ECT-VID Tuple (1) (6 bytes) |
+---------------------------------+-----------------------------+
| ... | ECT-VID Tuple(2) (6 bytes) |
+---------------------------------+-----------------------------+
| ..... |
+---------------------------------------------------------------+
| ..... |
| ..... |
+---------------------------------------------------------------+
o Type: sub-TLV type 6.
O型：サブTLVのタイプ6。
o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6-byte part of the ECT-VID tuple is formatted as follows:
O長さ：値の大きさは、ECT-VIDタプル* 6バイトです。次のようにECT-VIDタプルの各6バイトの部分がフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT-ALGORITHM (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) |U|M|RES|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o ECT-ALGORITHM (4 bytes): The ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given Base VID. There are 17 predefined IEEE algorithms for SPB with index values 0X00..0X10 occupying the low 8 bits and the IEEE OUI=00-80-C2 occupying the top 24 bits of the ECT-ALGORITHM.
O ECTアルゴリズム（4バイト）：ブリッジ（OUI /インデックスによって）指定されたECTアルゴリズムをサポートしているときにECT-アルゴリズムは、所与の基地VIDで宣伝されています。 ECTアルゴリズムのトップ24ビットを占有下位8ビット、IEEE OUI = 00から80-C2を占有するインデックス値0X00..0X10とSPB 17の事前定義されたIEEEアルゴリズムがあります。
o Base VID (12 bits): The Base VID that is associated with the SPT Set.
OベースVID（12ビット）：SPTセットに関連付けられている基地VID。
o Use-Flag (1 bit): The Use-Flag is set if this bridge, or any bridge in the LSDB, is currently using this ECT-ALGORITHM and Base VID. Remote usage is discovered by inspection of the U bit in the SPB-Inst sub-TLV of other SPB bridges (see Section 14.1)
O USEフラグ（1ビット）：このブリッジ、またはLSDB内の任意のブリッジが、現在このECT-アルゴリズムとベースVIDを使用している場合USEフラグが設定されています。リモート使用が他のSPBブリッジのSPB-工大サブTLVにおけるUビットの検査によって発見された（セクション14.1を参照のこと）
o M bit (1 bit): The M bit indicates if this Base VID operates in SPBM (M = 1) or SPBV (M = 0) mode.
O Mビット（1ビット）：このベースVIDはSPBM（M = 1）またはSPBV（M = 0）モードで動作する場合はMビットは示します。
The SPB-B-VID sub-TLV is carried within the MT-Port-Cap TLV [RFC6165], which in turn is carried in an IIH PDU.
SPB-B-VIDサブTLVは、順番にIIH PDUで運ばれるMT-ポートキャップTLV [RFC6165]内で実施されます。
All SPB nodal information extensions travel within a new multi-topology capability TLV MT-Capability (type 144).
すべてのSPBノード情報の拡張機能は、新しいマルチトポロジ機能TLV MT-機能（タイプ144）内を移動します。
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 = MT-CAP | = 144
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O R R R| MT ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(sub-TLVs ... )
The format of this TLV is identical in its first 2 bytes to all current MT TLVs and carries the MT ID as defined in [MT].
このTLVのフォーマットは、現在のすべてのMTのTLVの最初の2バイトに同一であり、[MT]で定義されるMT IDを運びます。
The O (overload) bit carried in bit 16 has the same semantics as specified in [MT], but in the context of SPB adjacencies only.
ビット16で運ばO（オーバーロード）ビットは、[MT]に指定したものと同じ意味を有するが、SPBの隣接関係のみに関連しています。
There can be multiple MT-Capability TLVs present, depending on the amount of information that needs to be carried.
実施する必要のある情報の量に応じて、複数のMT-機能のTLVが存在することができます。
The SPB-Inst sub-TLV gives the SPSourceID for this node/topology instance. This is the 20-bit value that is used in the formation of multicast DAs for frames originating from this node/instance. The SPSourceID occupies the upper 20 bits of the multicast DA together with 4 other bits (see the SPBM 802.1ah multicast DA address format section). This sub-TLV MUST be carried within the MT-Capability TLV in the fragment ZERO LSP. If there is an additional SPB instance, it
SPB-工大サブTLVは、このノード/トポロジ例えばSPSourceIDを与えます。これは、このノード/インスタンスに由来するフレームのマルチキャストのDAの形成に使用される20ビット値です。 SPSourceID 4他のビット（SPBMの802.1ahのマルチキャストDAアドレス形式の項を参照）と一緒にマルチキャストDAの上位20ビットを占有します。このサブTLVは、断片ZERO LSPにMT-能力TLV内で実施しなければなりません。追加のSPBのインスタンスが存在する場合、それ
MUST be declared under a separate MT-Capability TLV and also carried in the fragment ZERO LSP.
別MT-能力TLV下で宣言され、また、断片ZERO LSPで実施しなければなりません。
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 = SPB-Inst| = 1
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (cont) (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST External Root Path Cost (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bridge Priority | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R R R R R R R R|V| SPSourceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Trees | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (1) Tuples (8 bytes) |
| ........................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...........................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (N) Tuples (8 bytes) |
| ........................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where VLAN-ID tuples have the format as:
どこVLAN-IDタプルがような形式になります。
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
+-+-+-+-+-+-+-+-+
|U|M|A| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT-ALGORITHM (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) | SPVID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 1.
O型：サブTLVのタイプ1。
o Length: Total number of bytes contained in the value field.
Oの長さ：値フィールドに含まれるバイト数の合計。
o CIST Root Identifier (64 bits): The CIST Root Identifier is for SPB interworking with Rapid STP (RSTP) and Multiple STP (MSTP) at SPT Region boundaries. This is an imported value from a spanning tree.
CISTルート識別子（64ビット）○：CISTルート識別子は、SPT領域境界でラピッドSTP（RSTP）及び複数のSTP（MSTP）とSPBインターワーキングのためのものです。これは、スパニングツリーからインポートした値です。
o CIST External Root Path Cost (32 bits): The CIST External Root Path Cost is the cost to root, derived from the spanning tree algorithm.
O CIST外部ルートパスコスト（32ビット）：CIST外部ルートパスコストは、スパニングツリーアルゴリズムに由来する、ルートのコストです。
o Bridge Priority (16 bits): Bridge priority is the 16 bits that together with the 6 bytes of the System ID form the Bridge Identifier. This allows SPB to build a compatible spanning tree using link state by combining the Bridge Priority and the System ID to form the 8-byte Bridge Identifier. The 8-byte Bridge Identifier is also the input to the 16 predefined ECT tie-breaker algorithms.
Oブリッジプライオリティ（16ビット）：ブリッジ優先度は共にシステムIDの6バイトとブリッジ識別子を形成する16ビットです。これは、SPBは8バイトブリッジIDを形成するために、ブリッジプライオリティおよびシステムIDを組み合わせることにより、リンク状態を使用して互換性のスパニングツリーを構築することができます。 8バイトのブリッジ識別子は、16事前定義されたECTタイブレーカーアルゴリズムに入力されます。
o V bit (1 bit): The V bit (SPBM) indicates this SPSourceID is auto-allocated (Section 27.11 of [802.1aq]). If the V bit is clear, the SPSourceID has been configured and Must be unique. Allocation of SPSourceID is defined in IEEE [802.1aq]. Bridges running SPBM will allocate an SPSourceID if they are not configured with an explicit SPSourceID. The V bit allows neighbor bridges to determine if the auto-allocation was enabled. In the rare chance of a collision of SPsourceID allocation, the bridge with the highest priority Bridge Identifier will win conflicts. The lower priority bridge will be re-allocated; or, if the lower priority bridge is configured, it will not be allowed to join the SPT Region.
O Vビット（1ビット）：Vビット（SPBM）このSPSourceID自動割り当て（[802.1aq]のセクション27.11）であることを示します。 Vビットがクリアされている場合、SPSourceIDが構成されており、ユニークでなければなりません。 SPSourceIDの割り当ては、IEEE [802.1aq]で定義されています。彼らは、明示的なSPSourceIDで構成されていない場合はSPBMを実行しているブリッジはSPSourceIDを割り当てます。 Vビットは、自動割り当てが有効になっていた場合、隣接ブリッジが決定することを可能にします。 SPsourceID割り当ての衝突のまれな機会では、最も優先度の高いブリッジIDを持つブリッジが競合に勝つだろう。優先度の低いブリッジを再割り当てします。優先順位の低いブリッジが設定されている場合は、SPT地域への参加を許可されることはありません。
o SPSourceID: a 20-bit value used to construct multicast DAs as described below for multicast frames originating from the origin (SPB node) of the Link State Packet (LSP) that contains this TLV. More details are in IEEE [802.1aq].
O SPSourceID：このTLVが含まれているリンク状態パケット（LSP）の原点（SPBノード）に由来するマルチキャストフレームについて以下に説明するように、マルチキャストDAを構築するために使用される20ビット値。詳細は、IEEE [802.1aq]です。
o Number of Trees (8 bits): The Number of Trees is set to the number of {ECT-ALGORITHM, Base VID plus flags} tuples that follow. Each ECT-ALGORITHM has a Base VID, an SPVID, and flags described below. This Must contain at least the one ECT-ALGORITHM (00-80-C2-01).
O木の数（8ビット）：木の数は、以下の{ECTアルゴリズム、ベースVIDプラスフラグ}タプルの数に設定されています。各ECTアルゴリズムは、以下に記載の塩基VID、SPVID、およびフラグを有しています。これは、含まれている必要があり、少なくとも1 ECT-アルゴリズム（00から80-C2-01）。
Each VID Tuple consists of:
各VIDタプルの構成は次のとおりです。
o U bit (1 bit): The U bit is set if this bridge is currently using this ECT-ALGORITHM for I-SIDs it sources or sinks. This is a strictly local indication; the semantics differ from the Use-Flag found in the Hello, which will set the Use-Flag if it sees other nodal U bits are set OR it sources or sinks itself.
O Uビット（1ビット）：このブリッジは、現在、それはソースまたはシンクI-SIDのためのこのECT-アルゴリズムを使用している場合、Uビットが設定されています。これは厳密には地元の徴候です。セマンティクスは、USEフラグとは異なり、それは他の節点Uビットが設定されて見ているか、自分自身をソースまたはシンクした場合にUSEフラグを設定しますこんにちは、で見つかりました。
o M bit (1 bit): The M bit indicates if this is SPBM or SPBV mode. When cleared, the mode is SPBV; when set, the mode is SPBM.
O Mビット（1ビット）：これはSPBM又はSPBVモードである場合にMビットが示しています。クリアすると、モードがSPBVです。設定すると、モードがSPBMです。
o A bit (1 bit): The A bit (SPB), when set, declares this is an SPVID with auto-allocation. The VID allocation logic details are in IEEE [802.1aq]. Since SPVIDs are allocated from a small pool of 12-bit resources, the chances of collision are high. To minimize collisions during auto-allocation, LSPs are initially advertised with the originating bridge setting the SPVID to 0. Only after learning the other bridges' SPVID allocations does this bridge re-advertise this sub-TLV with a non-zero SPVID. This will minimize but not eliminate the chance of a clash. In the event of a clash, the highest Bridge Identifier is used to select the winner, while the loser(s) with lower Bridge Identifier(s) Must withdraw their SPVID allocation(s) and select an alternative candidate for another trial. SPVID May also be configured. When the A bit is set to not specify auto-allocation and the SPVID is set to 0, this SPBV bridge is used for transit only within the SPB region. If a port is configured with the Base VID as a neighbor using RSTP or MSTP, the bridge will act as an ingress filter for that VID.
Oビット（1ビット）：Aビット（SPB）、セットは、この自動割り当てとSPVIDある宣言する。 VID割当ロジックの詳細は、IEEE [802.1aq]です。 SPVIDsは、12ビットのリソースの小さなプールから割り当てられているので、衝突の可能性が高いです。自動割り当て時の衝突を最小限にするために、LSPは最初にのみ、このブリッジが非ゼロSPVIDでこのサブTLVを再広告しない他のブリッジSPVID配分を学習した後、0にSPVIDを設定し、元のブリッジと宣伝されています。これは、最小化ではなく、衝突の可能性を排除します。衝突の場合に、最も高いブリッジ識別子は、下部ブリッジ識別子（複数）と敗者（単数または複数）が、それらのSPVID割り当て（複数可）を撤回し、別の試験のための代替候補を選択しなければならないが、勝者を選択するために使用されます。 SPVIDも構成することができます。ビットは、自動割り当てを指定しないように設定され、SPVIDが0に設定されている場合、このSPBVブリッジは、SPB領域内輸送のために使用されます。ポートは、RSTPまたはMSTPを使用して隣接の基地VIDで構成されている場合、ブリッジは、そのVIDのための入力フィルタとして作用します。
o ECT-ALGORITHM (4 bytes): ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. This declaration Must match the declaration in the Hello PDU originating from the same bridge. The ECT-ALGORITHM and Base VID Must match what is generated in the IIHs of the same node. The ECT-ALGORITHM, Base VID tuples can come in any order, however. There are currently 17 worldwide unique 802.1aq defined ECT-ALGORITHMs given by values 00-80-C2-00 through 00-80-C2-10.
O ECTアルゴリズム（4バイト）：ブリッジが所定のVIDに（OUI /インデックスによって）所与のECTアルゴリズムをサポートしているときにECT-アルゴリズムがアドバタイズされます。この宣言は、同じブリッジから発信こんにちはPDU内の宣言と一致する必要があります。 ECT-アルゴリズムとベースVIDは、同じノードのIIHSで生成されたものと一致しなければなりません。 ECT-アルゴリズムは、基本VIDタプルは、しかし、任意の順序で来ることができます。 00から80-C2-10を通じて値00から80-C2-00によって与えられた17世界的にユニークな802.1aq定義されたECT-アルゴリズムは現在ありません。
o Base VID (12 bits): The Base VID that associated the SPT Set via the ECT-ALGORITHM.
OベースVID（12ビット）：ECT-アルゴリズムによってSPTセットの関連するベースVID。
o SPVID (12 bits): The SPVID is the Shortest Path VID assigned for the Base VID to this node when using SPBV mode. It is not defined for SPBM mode and Must be 0 for SPBM mode B-VIDs.
SPVID（12ビット）○：SPVIDはSPBVモードを使用する場合、このノードにベースVIDのために割り当てられた最短パスVIDです。それはSPBMモード用に定義されていないとSPBMモードB-VIDのために0にする必要があります。
There are multiple ECT algorithms defined for SPB; however, for the future, additional algorithms may be defined including but not limited to ECMP- or hash-based behaviors and (*,G) multicast trees. These algorithms will use this Optional TLV to define new algorithm parametric data. For tie-breaking parameters, there are two broad classes of algorithm, one that uses nodal data to break ties and one that uses link data to break ties. This sub-TLV is used to associate opaque tie-breaking data with a node. This sub-TLV, when present, MUST be carried within the MT-Capability TLV (along with a valid SPB-Inst sub-TLV). Multiple copies of this sub-TLV MAY be carried for different ECT-ALGORITHMs relating to this node.
SPBのために定義された複数のECTのアルゴリズムがあります。しかし、将来のために、追加のアルゴリズムはECMP-またはハッシュベースの行動や（*、G）マルチキャストツリーに限定されるものではないが定義されてもよいです。これらのアルゴリズムは、新しいアルゴリズムのパラメトリックデータを定義するには、このオプションのTLVを使用します。タイブレークのパラメータについては、アルゴリズムの二つの広いクラス、ネクタイやネクタイを破るためにリンクデータを使用するものを破るために節点データを使用して1があります。このサブTLVは、ノードに不透明なタイブレークデータを関連付けるために使用されます。このサブTLVは、存在する場合、（有効SPB-工大サブTLVと共に）MT-能力TLV内で実施しなければなりません。このサブTLVの複数のコピーは、このノードに関連する異なるECT-アルゴリズムの実行されてもよいです。
There are of course many other uses of this opaque data that have yet to be defined.
定義されてまだ持っているこの不透明なデータの多くの他の用途はもちろんあります。
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=SPB-I-OALG| = 2
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT-ALGORITHM (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
| ....................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 2.
O型：サブTLVのタイプ2。
o Length: Total number of bytes contained in the value field.
Oの長さ：値フィールドに含まれるバイト数の合計。
o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.
O ECT-アルゴリズム：ブリッジは（OUI / Indexで）与えられたECT-アルゴリズムをサポートしているとき、ECT-アルゴリズムが与えられたVIDにアドバタイズされます。
o ECT Information: ECT-ALGORITHM Information of variable length which SHOULD be in sub-TLV format with an IANA numbering space where appropriate.
O ECT情報：可変長のECTアルゴリズム情報適切なIANA番号空間とサブTLV形式であるべきです。
The SPB-Metric sub-TLV (type 29) occurs within the Multi-Topology Intermediate System Neighbor (MT-ISN) TLV (type 222) or within the Extended IS Reachability TLV (type 22). If this sub-TLV is not present for an IS-IS adjacency, then that adjacency Must not carry SPB traffic for the given topology instance.
SPB-メトリックサブTLV（タイプ29）は、マルチトポロジ中間システム近隣内（MT-ISN）TLV（タイプ222）または到達可能性TLVがIS拡張（タイプ22）内で起こります。このサブTLVは、IS-IS隣接関係のために存在していない場合は、その隣接が与えられたトポロジインスタンスのSPBのトラフィックを運ぶいけません。
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=SPB-Metric| = 29
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPB-LINK-METRIC | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Ports | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Identifier | ( 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 29.
Oタイプ：サブTLVタイプ29。
o Length: Total number of bytes contained in the value field.
Oの長さ：値フィールドに含まれるバイト数の合計。
o SPB-LINK-METRIC: the administrative cost or weight of using this link as a 24-bit unsigned number. This metric applies to the use of this link for SPB traffic only. Smaller numbers indicate lower weights and are more likely to carry SPB traffic. Only one metric is allowed per SPB instance per link. If multiple metrics are required, multiple SPB instances Must be used, either within IS-IS or within several independent IS-IS instances. If this metric is different at each end of a link, the maximum of the two values Must be used in all SPB calculations for the weight of this link. The maximum SPB-LINK-METRIC value 2^24 - 1 has a special significance; this value indicates that although the IS-IS adjacency has formed, incompatible values have been detected in parameters configured within SPB itself (for example, different regions), and the link Must Not be used for carrying SPB traffic. Full details are found in [802.1aq].
O SPB-LINKメトリック：24ビットの符号なし数値として、このリンクを使用しての管理コストや重量。このメトリックは、SPBのトラフィックだけのために、このリンクの使用に適用されます。小さい数字が小さい重みを示し、SPBトラフィックを伝送する可能性が高くなります。唯一のメトリックは、リンクごとにSPBインスタンスごとに許可されます。複数のメトリックが必要な場合は、複数のSPBインスタンスは、どちらかのIS-IS内または複数の独立したIS-ISインスタンスの中に、使用する必要があります。このメトリックは、リンクの各端に異なる場合、2つの値の最大値は、このリンクの重みのすべてのSPBの計算に使用されなければなりません。最大SPB-LINKメトリック値2 ^ 24から1には特別な意味を持っています。この値は、IS-IS隣接関係を形成しているが、互換性のない値がSPB自体（例えば、異なる領域）内に設定されたパラメータで検出されており、リンクがSPBのトラフィックを伝送するために使用してはならないことを示しています。完全な詳細は[802.1aq]に記載されています。
o Num of Ports: the number of ports associated with this link.
ポートの入出力数：このリンクに関連付けられているポートの数。
o Port Identifier: the standard IEEE port identifier used to build a spanning tree associated with this link.
Oポート識別子：このリンクに関連付けられているスパニングツリーを構築するために使用される標準のIEEEポート識別子。
There are multiple ECT algorithms defined for SPB; however, for the future, additional algorithms may be defined. The SPB-A-OALG sub-TLV occurs within the Multi-Topology Intermediate System TLV (type 222) or the Extended IS Reachability TLV (type 22). Multiple copies of this sub-TLV MAY be carried for different ECT-ALGORITHMs related to this adjacency.
SPBのために定義された複数のECTのアルゴリズムがあります。しかし、将来のために、追加的なアルゴリズムを定義することができます。 SPB-A-OALGサブTLVは、マルチトポロジ中間システムTLV（タイプ222）内で発生または拡張到達可能性TLV（タイプ22）です。このサブTLVの複数のコピーは、この隣接に関する異なるECT-アルゴリズムのために行うことができます。
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=SPB-A-OALG| = 30
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
| ......................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 30.
O型：サブTLVのタイプ30。
o Length: Total number of bytes contained in the value field.
Oの長さ：値フィールドに含まれるバイト数の合計。
o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.
O ECT-アルゴリズム：ブリッジは（OUI / Indexで）与えられたECT-アルゴリズムをサポートしているとき、ECT-アルゴリズムが与えられたVIDにアドバタイズされます。
o ECT Information: ECT-ALGORITHM Information of variable length in sub-TLV format using new IANA type values as appropriate.
O ECT情報：可変長のECTアルゴリズム情報サブTLV形式で適宜新しいIANAタイプの値を使用。
The SPBM-SI sub-TLV (type 3) is used to introduce service group membership on the originating node and/or to advertise an additional B-MAC unicast address present on, or reachable by the node.
SPBM-SIサブTLV（タイプ3）は、発信元ノードにサービスグループのメンバーシップを導入すること、および/または追加のB-MACユニキャストアドレスは、ノードが上の提示、または到達可能な宣伝するために使用されます。
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 = SPBM-SI | = 3
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS (6 bytes) | Res. | Base VID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 3.
O型：サブTLVのタイプ3。
o Length: Total number of bytes contained in the value field.
Oの長さ：値フィールドに含まれるバイト数の合計。
o B-MAC ADDRESS: a unicast address of this node. It may be the single nodal address, or it may address a port or any other level of granularity relative to the node. In the case where the node only has one B-MAC address, this Should be the same as the SYSID of the node. To add multiple B-MACs this TLV MUST be repeated per additional B-MAC.
O B-MACアドレス：このノードのユニキャストアドレス。これは、単一ノードのアドレスであってもよいし、ポートまたはノードに対する粒度の任意の他のレベルに対処することができます。ノードは唯一のB-MACアドレスを持っている場合、これは、ノードのSYSIDと同じでなければなりません。複数のB-MACを追加するには、このTLVは、追加のB-MACごとに繰り返さなければなりません。
o Base VID (12 bits): The Base VID associated with the B-BMAC allows the linkage to the ECT-ALGORITHM and SPT Set defined in the SPB-Inst sub-TLV.
OベースVID（12ビット）：B-BMACと関連する基地VIDは、SPB-工大サブTLVで定義されてECT-アルゴリズムとSPTセットへの結合を可能にします。
o I-SID #1 .. #n: 24-bit service group membership identifiers. If two nodes have an I-SID in common, intermediate nodes on the unique shortest path between them will create forwarding state for the related B-MAC addresses and will also construct multicast forwarding state using the I-SID and the node's SPSourceID to construct a multicast DA as described in IEEE 802.1aq LSB. Each I-SID has a Transmit (T) and Receive (R) bit that indicates if the membership is as a transmitter, a receiver, or both (with both bits set). In the case where the Transmit (T) and Receive (R) bits are both zero, the I-SID instance is ignored for the purposes of distributed multicast computation, but the unicast B-MAC address Must be processed and installed at nodes providing transit to that address. If more I-SIDs are associated with a particular
O I-SID＃1 ...＃N：24ビットサービスグループメンバーシップ識別子。 2つのノードが共通のI-SIDを持っている場合は、それらの間の一意の最短経路上の中間ノードは、関連するB-MACアドレスの転送状態を作成し、また、構成するためにI-SIDおよびノードのSPSourceIDを使用して、マルチキャスト転送状態を構築しますIEEE 802.1aq LSBで説明したように、マルチキャストDA。各I-SIDは、（両方のビットがセットで）メンバーシップは、送信機、受信機、または両方としてであるかどうかを示す送信（T）及び受信（R）ビットを有しています。送信（T）及び受信（R）ビットが両方ともゼロである場合には、I-SIDインスタンスは、分散マルチキャスト計算の目的のために無視されるが、ユニキャストB-MACアドレスはトランジットを提供するノードで処理してインストールする必要がありますそのアドレスへ。より多くのI-SIDが特定の関連付けられている場合
B-MAC than can fit in a single sub-TLV, this sub-TLV can be repeated with the same B-MAC but with different I-SID values.
単一のサブTLVに収まるよりもB-MAC、このサブTLVは、同一のB-MACとが異なるI-SID値を使用して繰り返すことができます。
o Note: When the T bit is not set, an SPB May still multicast to all the other receiving members of this I-SID (those advertising with their R bits set), by configuring edge replication and serial unicast to each member locally.
O注：Tビットが設定されていない場合、SPBは依然としてローカル各部材にエッジ複製およびシリアルユニキャストを構成することにより、このI-SID（設定それらのRビットを有するそれらの広告）の他のすべての受信メンバーにマルチキャストすることができます。
The SPBM-SI sub-TLV, when present, MUST be carried within the MT-Capability TLV and can occur multiple times in any LSP fragment.
SPBM-SIサブTLVは、存在する場合、MT-能力TLV内で実施しなければならないし、任意のLSPフラグメントに複数回発生する可能性があります。
The SPBV-ADDR sub-TLV is IS-IS sub-TLV type 4. It Should be used for advertisement of Group MAC addresses in SPBV mode. Unicast MAC addresses will normally be distributed by reverse-path learning, but carrying them in this TLV is not precluded. It has the following format:
SPBV-ADDRサブTLVは、IS-ISそれはSPBVモードでは、グループMACアドレスの広告のためのサブTLVタイプ4.使用する必要があります。ユニキャストMACアドレスは、通常、リバースパス学習によって配布されますが、このTLVでそれらを運ぶことは除外されません。これは、次の形式になります。
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=SPBV-ADDR| = 4 (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R| SR| SPVID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC 1 Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC N Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type 4.
O型：サブTLVのタイプ4。
o Length: Total number of bytes contained in the value field. The number of MAC address associated with the SPVID is computed by (Length - 2)/7.
Oの長さ：値フィールドに含まれるバイト数の合計。 / 7 - SPVIDに関連付けられたMACアドレスの数（2の長さ）によって計算されます。
o SR bits (2 bits): The SR bits are the service requirement parameter from MMRP. The service requirement parameters have the value 0 (Forward all Groups) and 1 (Forward All Unregistered Groups) defined. However, this attribute May also be missing. So the SR bits are defined as 0 not declared, 1 Forward all Groups, and 2 Forward All Unregistered Groups. The two 'R' reserved bits immediately preceding these SR bits Shall be set to zero when originating this sub-TLV and Shall be ignored on receipt.
SRビット（2ビット）（O）SRビットはMMRPからサービス要求パラメータです。サービス要求パラメータは、値0（フォワードすべてのグループ）および1（フォワードすべて未登録グループ）定義を有します。しかし、この属性もないことがあります。だから、SRビットは0として定義され、1つのフォワードすべてのグループ、および2つのフォワードすべて未登録のグループを宣言していません。 2つの「R」は、このサブTLVを発信し、受信時には無視されなければならないときに直ちにこれらSRビットに先行するビットがゼロに設定される予約済み。
o SPVID (12 bits): The SPVID and by association Base VID and the ECT-ALGORITHM and SPT Set that the MAC addresses defined below will use. If the SPVID is not allocated the SPVID Value is 0. Note that if the ECT-ALGORITHM in use is spanning tree algorithm this value Must be populated with the Base VID and the MAC Must be populated.
O SPVID（12ビット）：SPVID及び以下に定義されるMACアドレスが使用する関連基地VID及びECTアルゴリズム及びSPTセットによって。 SPVIDが割り当てられていない場合SPVID値は0です。注意使用中のECT-アルゴリズムがツリーアルゴリズムスパニングされた場合は、この値は、Base VIDが取り込まれなければならず、MACは、移入されなければならないこと。
o T bit (1 bit): This is the Transmit allowed bit for a following group MAC address. This is an indication that the Group MAC address in the context of the SPVID of the bridge advertising this Group MAC Must be installed in the FDB of transit bridges, when the bridge computing the trees is on the corresponding ECT-ALGORITHM shortest path between the bridge advertising this MAC with the T bit set and any receiver of this Group MAC address. A bridge that does not advertise this bit set for a MAC address Must Not cause multicast forwarding state to be installed on other transit bridges in the network for traffic originating from that bridge.
O Tビット（1ビット）：これは、以下のグループMACアドレスのビットを許容送信です。これは、ブリッジ広告このグループMACのSPVIDの文脈において、グループMACアドレスが木を計算するブリッジは、ブリッジ間の対応ECTアルゴリズム最短パス上にある場合、トランジットブリッジのFDBに設置されなければならないことの指標でありますTビットのセットと、このグループのMACアドレスのいずれかの受信機との広告このMAC。 MACアドレスのため、このビットセットを広告しないブリッジは、トラフィックがその橋から発信するために、ネットワーク内の他のトランジットブリッジにインストールするマルチキャスト転送状態を引き起こしてはなりません。
o R bit (1 bit): This is the Receive allowed bit for the following MAC address. This is an indication that MAC addresses as the receiver Must be populated and installed when the bridge computing the trees lies on the corresponding shortest path for this ECT-ALGORITHM between this receiver and any transmitter to this MAC address. An entry that does not have this bit set for a Group MAC address is prevented from receiving on this Group MAC address because transit bridges Must Not install multicast forwarding state towards it in their FDBs.
O Rビット（1ビット）：これは、以下のMACアドレスの許容受信ビットです。木を計算するブリッジは、この受信し、このMACアドレスへの送信との間のこのECTアルゴリズムに対応する最短経路上にあるとき、これは受信機としてMACアドレスが読み込まれ、インストールされなければならないことを示すものです。グループMACアドレスのため、このビットがセットされていないエントリはトランジットブリッジがそのFDBsでそれに向かってマルチキャスト転送状態をインストールすることはできませんので、このグループのMACアドレスを受信することが防止されます。
o MAC Address (48 bits): The MAC address declares this bridge as part of the multicast interest for this destination MAC address. Multicast trees can be efficiently constructed for destination by populating FDB entries for the subset of the shortest path tree that connects the bridges supporting the MAC address. This replaces the function of MMRP for SPTs. The T and R bits above have meaning as specified above.
O MACは、（48ビット）アドレス：MACアドレスは、この宛先MACアドレスのマルチキャスト関心の一部としてこの橋を宣言する。マルチキャストツリーを効率的にMACアドレスをサポートするブリッジとを接続する最短経路ツリーのサブセットのFDBエントリを投入することによって目的地を構築することができます。これはSPTは用MMRPの機能を置き換えます。上記指定されたように、TとRビットが上記意味を有します。
The SPBV-ADDR sub-TLV, when present, MUST be carried within the MT-Capability TLV and can occur multiple times in any LSP fragment.
SPBV-ADDRサブTLVは、存在する場合、MT-能力TLV内で実施しなければならないし、任意のLSPフラグメントに複数回発生する可能性があります。
This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS when used in a configured environment or a single-operator domain such as a data center.
この文書では、IS-ISへの追加的なセキュリティリスクを追加していない、またそれは、このようなデータセンターとしてIS-IS構成された環境または単一のオペレータドメインで使用する場合のための追加のセキュリティを提供しません。
However, this protocol may be used in a zero-configuration environment. Zero configuration may apply to the automatic detection and formation of an IS-IS adjacency (forming an NNI port). Likewise, zero configuration may apply to the automatic detection of VLAN-tagged traffic and the formation of a UNI port, with resultant I-SID advertisements.
しかしながら、このプロトコルは、ゼロコンフィギュレーション環境で使用することができます。ゼロコンフィギュレーションは、（NNIポートを形成する）IS-IS隣接の自動検出および形成に適用することができます。同様に、ゼロコンフィギュレーションは、得られたI-SIDの広告と、VLANタグ付きトラフィックの自動検出とUNIポートの形成に適用することができます。
If zero configuration methods are used to autoconfigure NNIs or UNIs, there are intrinsic security concerns that should be mitigated with authentication procedures for the above cases. Such procedures are beyond the scope of this document and are yet to be defined.
ゼロ設定方法はのNNIまたはのUNIを自動設定するために使用される場合、上記の場合の認証手順を軽減しなければならない固有のセキュリティ上の懸念があります。このような手順は、このドキュメントの範囲を超えて、まだ定義されています。
In addition, this protocol can create significant amounts of multicast state when an I-SID is advertised with the T bit set. Extra care should be taken to ensure that this cannot be used in a denial-of-service attack [RFC4732] in a zero-configuration environment.
また、このプロトコルは、I-SIDがTビットセットでアドバタイズされるマルチキャスト状態のかなりの量を作成することができます。エクストラケアは、これがゼロコンフィギュレーション環境におけるサービス拒否攻撃[RFC4732]で使用することができないように注意しなければなりません。
Note that the NLPID value 0xC1 [RFC6328] used in the IIH PDUs has already been assigned by IANA for the purpose of 802.1aq; therefore, no further action is required for this code point.
IIHのPDUで使用NLPID値0xC1 [RFC6328]は既に802.1aqの目的のためにIANAによって割り当てられていることに注意してください。従って、更なるアクションは、このコードポイントのために必要とされません。
Since 802.1aq operates within the IS-IS Multi-Topology framework, every sub-TLV MUST occur in the context of the proper MT TLV (with the exception of the SPB-Metric sub-TLV, which MAY travel in TLV 22 where its MT ID is unspecified but implied to be 0). IANA has allocated sub-TLVs for three Multi-Topology TLVs per 802.1aq. These are the MT-Port-Cap TLV [RFC6165] used in the IIH, the MT-Capability TLV (new) used within the LSP, and finally the MT-ISN TLV [MT] used to contain adjacency information within the LSP.
802.1aqがIS-ISマルチトポロジフレームワーク内で動作するため、すべてのサブTLVは、TLV 22のMTに移動することがSPB-メトリックサブTLVを除いて適切なMT TLV（、のコンテキストで発生しなければなりませんID）が指定されていないが、0であることを暗示しています。 IANAは802.1aqごとに3つのマルチトポロジのTLVのためのサブTLVを割り当てています。これらは、IIHで使用されるMT-ポートキャップTLV [RFC6165]、LSP内で使用されるMT-機能TLV（新）、そして最後にMT-ISN TLV [MT]はLSP内の隣接情報を格納するために使用されています。
This document creates the following TLVs and sub-TLVs within the IIH and LSP PDUs MT TLVs as described below. The '*' indicates new IANA assignments (per this document). Other entries are shown to provide context only.
以下に説明するように、このドキュメントは、次のTLVとIIHとLSPのPDU MTのTLV内のサブTLVを作成します。 「*」を（このドキュメントあたり）新しいIANAの割り当てを示します。他のエントリは、唯一のコンテキストを提供することが示されています。
The MT-Capability TLV is the only TLV that required a new sub-registry. Type value 144 has been assigned, with a starting sub-TLV value of 1, and managed by Expert Review.
MT-機能TLVは、新しいサブレジストリを必要なだけTLVです。 Type値144は、1の開始サブTLV値で、割り当てられた、と専門家レビューによって管理されています。
+-----+----+-----------------+--------+------+-------------+
| PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE |
+-----+----+-----------------+--------+------+-------------+
IIH
MT-Port-Cap 143
* SPB-MCID 4 1
* SPB-Digest 5 >=0
* SPB-B-VID 6 1
LSP * MT-Capability 144 >=1 * SPB-Inst 1 1 * SPB-I-OALG 2 >=0 * SPBM-SI 3 >=0 * SPBV-ADDR 4 >=0
LSP * MT-機能144> = 1×SPB-工大1 * SPB-I-OALG 2> = 0 * SPBM-SI 3> = 0 * SPBV-ADDR 4> = 0
MT-ISN 222 or Extended IS Reachability 22 * SPB-Metric 29 1 * SPB-A-OALG 30 >=0
MT-ISN 222または拡張は、到達可能性22 IS * SPB-メトリック29 1 * SPB-A-OALG 30> = 0
[802.1aq] "Standard for Local and Metropolitan Area Networks: Virtual Bridges and Virtual Bridged Local Area Networks - Amendment 9: Shortest Path Bridging", IEEE P802.1aq, Draft 4.6, 2012.
[802.1aq]「ローカルおよびメトロポリタンエリアネットワークの標準：仮想ブリッジと仮想ブリッジローカルエリアネットワーク - 修正9：最短パスブリッジング」、IEEE P802.1aq、ドラフト4.6、2012。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
[IS-IS] ISO / IEC 10589：2002「コネクションレスモードネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムイントラドメインルーティング交換プロトコルへの中間システム」2002年、第2版、。
[MT] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[MT] Przygienda、T.、シェン、N.、およびN. Shethは、 "M-ISIS：中間システムへの中間システムにおけるマルチトポロジー（MT）ルーティング（IS-ISS）"、RFC 5120、2008年2月。
[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月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165]バネルジー、A.、およびD.区、RFC 6165、2011年4月 "の拡張レイヤ2のシステムのためのIS-ISは、"。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328]イーストレイク3日、D.、 "ネットワーク層プロトコル識別子のためのIANAの考慮事項"、BCP 164、RFC 6328、2011年7月。
[802.1ag] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 5: Connectivity Fault Management", IEEE STD 802.1ag, 2007.
[802.1ag]「標準ローカルおよびメトロポリタンエリアネットワークのための/仮想ブリッジローカルエリアネットワーク/修正5：接続障害管理」、IEEE STDの802.1ag、2007。
[MMRP] "Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 07: Multiple Registration Protocol", IEEE STD 802.1ak, 2007.
[MMRP]「ローカルのための標準とメトロポリタンエリアネットワーク仮想ブリッジローカルエリアネットワーク - 修正07：複数登録プロトコル」、IEEE STDの802.1ak、2007。
[PB] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 4: Provider Bridges", IEEE STD 802.1ad, 2005.
[PB]「ローカルおよびメトロポリタンエリアネットワーク/仮想ブリッジローカルエリアネットワーク/修正4のための標準：プロバイダブリッジ」、IEEE STDの802.1ad、2005。
[PBB] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 7: Provider Backbone Bridges", IEEE STD 802.1ah, 2008.
[PBB]「ローカルおよびメトロポリタンエリアネットワークの標準/仮想ブリッジローカルエリアネットワーク/修正7：プロバイダ・バックボーン・ブリッジ」、IEEE STDの802.1ahの2008年。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[Y.1731] ITU-T, "OAM Functions and Mechanisms for Ethernet based networks", ITU-T Y.1731, 2006.
[Y.1731] ITU-T、 "イーサネットベースのネットワークのためのOAM機能とメカニズム"、ITU-T Y.1731、2006。
The authors would like to thank Ayan Banerjee, Mick Seaman, Janos Farkas, Les Ginsberg, Stewart Bryant , Donald Eastlake, Matthew Bocci and Mike Shand for contributions and/or detailed review.
著者は、寄付および/または詳細なレビューのためにアヤンバネルジー、ミック・シーマン、ヤーノシュ・ファーカス、レ・ギンズバーグ、スチュワートブライアント、ドナルドイーストレイク、マシューボッチとマイクシャンドに感謝したいと思います。
Authors' Addresses
著者のアドレス
Don Fedyk (editor) Alcatel-Lucent Groton, MA 01450 USA EMail: Donald.Fedyk@alcatel-lucent.com
ドン・ルブラン（編集者）、アルカテル・ルーセント、グロトン、MA 01450 USA電子メール：Donald.Fedyk@alcatel-lucent.com
Peter Ashwood-Smith (editor) Huawei Technologies Canada Ltd. 303 Terry Fox Drive, Suite 400 Kanata, Ontario, K2K 3J1 CANADA EMail: Peter.AshwoodSmith@huawei.com
ピーター・アッシュウッド・スミス（エディタ）華為技術カナダ社303テリー・フォックス・ドライブ、スイート400カナタ、オンタリオ、K2K 3J1 CANADA Eメール：Peter.AshwoodSmith@huawei.com
Dave Allan Ericsson 300 Holger Way San Jose, CA 95134 USA EMail: david.i.allan@ericsson.com
デイブ・アラン・エリクソン300ホルガー・ウェイサンノゼ、CA 95134 USA電子メール：david.i.allan@ericsson.com
Nigel Bragg Ciena Limited Ciena House 43-51 Worship Street London EC2A 2DX UK EMail: nbragg@ciena.com
ナイジェル・ブラッグシエナリミテッドシエナハウス43-51崇拝ストリートロンドンEC2A 2DXイギリスのEメール：nbragg@ciena.com
Paul Unbehagen Avaya 8742 Lucent Boulevard Highlands Ranch, CO 80129 USA EMail: unbehagen@avaya.com
ポール・不快感のAvaya 8742ルーセント大通りハイランズランチ、CO 80129 USA Eメール：unbehagen@avaya.com