[要約] RFC 6329は、IEEE 802.1aq最短パスブリッジングをサポートするIS-IS拡張に関するものです。このRFCの目的は、IS-ISプロトコルを使用して最短パスブリッジングを実装するための拡張を提供することです。
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
IS-ISエクステンションは、IEEE 802.1AQ最短パスブリッジングをサポートします
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は、複数の等しいコストパスを使用して、メッシュイーサネットネットワークコンテキストでの真の最短パス転送を許可します。これにより、より速い収束とメッシュトポロジの使用が大幅に改善された、はるかに大きなレイヤー2トポロジーをサポートすることができます。これと組み合わせることで、ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーマルチポイントのバリエーションを含む論理接続メンバーシップの単一ポイントプロビジョニングがあります。このメモは、このIEEEプロトコルをサポートするために必要なISの変更を文書化し、いくつかのコンテキストと例を提供します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................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は、複数の等しいコストパスを使用して、イーサネットメッシュネットワークコンテキストでの真の短いパス転送を許可します。これにより、SPBは、収束を速くし、メッシュトポロジの使用を大幅に改善したはるかに大きなレイヤー2トポロジーをサポートできます。これと組み合わせることで、ポイントツーポイント（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の制御プロトコルは、少数の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のセットが必要です。このドキュメントと[IS-IS]との間で混乱がある場合、[IS-IS]は権威あると見なされるべきです。
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
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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
このドキュメントの初期資本「必須」、「そうでない」、「そうしない」、「そうしない」、「そうでない」、「そうでない」、「可能な」、「5月」、「そうではない」、「そうしない」、「しない」、「そうしない」、小文字はフォームを形成します。で定義された感覚
[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の用語に不慣れな読者にとって、イーサネットの動作の定義は、「転送」（ユニキャストトラフィックの明示的な方向）ではなく、（放送トラフィックの）「フィルタリング」の観点からほぼ完全にあります。このドキュメントでは、一般的な用語「転送」を使用しており、これら2つの用語が同じ動作を表現する異なる方法を単に表していることを理解する必要があります。
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）の最初の2つのモードの場合、ルートは最短のパスであり、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は、SPB VID（SPBV）とSPB MAC（SPBM）の2つのモードをサポートしています。SPBVでは、複数のVLANを使用して、サービスベースで異なる最短パスツリー（それぞれが異なるタイブレークルールで計算された）に負荷を分散させることができます。SPBMでは、サービスインスタンスはI-SIDSによって描写されますが、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は、VLAN、PB（802.1AQ [PB]）、またはPBBを実装するPBネットワークで使用できます
encapsulation. The two modes can co-exist simultaneously in an SPB network.
カプセル化。2つのモードは、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領域でまばらに使用できるため、少数のSPVIDを持つ大規模な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では、各ブリッジには、SYSIDのIS-ISによって宣伝されている少なくとも1つの一意の「既知の」MACアドレスがあります。
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は、IS-ISで宣伝されている1つ以上のB VIDと「既知の」バックボーンMAC（B-MAC）アドレスの組み合わせを使用します。バックボーンという用語は、バックボーンネットワークでよく使用されるカプセル化を単に意味しますが、カプセル化は、C-Macsを隠すことが有用な他のタイプのネットワークで役立ちます。
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.
SPBMフィルタリングデータベース（FDB）は、ユニキャストおよびマルチキャストMACアドレス用に計算およびインストールされますが、SPBVフィルタリングデータベースは計算および単方向VIDS（SPVIDと呼ばれる）用にインストールされます。ユニキャスト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-ALGORITHM（32ビットの世界的な一意の計算定義）を共有する場合、ツリーは同じSPTです。SPBVの場合、（S、G）は、ソース固有のVID（SPVID）と標準グループMACアドレスによってエンコードされます。SPBMの場合、（s、g）は、20ビットのSPBワイドユニークな節点ニックネーム（Spsourceidと呼ばれる）と24ビットI-SIDとB-とともに連結されているため、宛先B-MACアドレスにエンコードされます。ECT-ALGORITHMネットワークワイドに対応する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.
いくつかの高度に接続されたメッシュネットワークは、ノード間で複数の等しいコストの代替品を提供することにより、パスの多様性を提供します。一致と対称性を尊重する必要があるため、単一のツリーはいくつかのリンクを十分に活用しておくことがあります。異なる決定論的なタイブレーカーを使用することにより、任意のノードのペア間で任意の多様性の最短パスが可能になります。これにより、トラフィックが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アルゴリズムの任意の組み合わせを使用する場合があります。拡張可能なフレームワークは、他のプロパティとパラメーター（ECMP、（*、g）など）を使用した追加または代替アルゴリズムを、このドキュメントまたはIEEEドキュメントの変更なしにサポートすることを許可します。
SPB incorporates the multi topology features of [MT] thereby allowing multiple logical SPB instances within a single IS-IS instance.
SPBには、[MT]のマルチトポロジー機能が組み込まれ、単一のIS-ISインスタンス内で複数の論理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にも関連付けられているため、このISに乗っているIPまたは他のNLPIDとは異なるSPB隣接の異なる隣接メトリック（または無限のメトリック）を持つことができます。インスタンスですが、同じIS-ISインスタンスで他のSPBインスタンスで使用されるものとは異なります。
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によって本質的に分離されています。したがって、VLAN（TLVおよびデータプレーンのVIDで表される）は、SPBインスタンス間で（コントロールプレーンの分離方法に関係なく）重複してはなりません。
The [MT] mechanism when applied to SPB allows different routing metrics and topology subsets for different classes of services.
[MT]メカニズムSPBに適用されると、さまざまなクラスのサービス用に異なるルーティングメトリックとトポロジサブセットが可能になります。
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.
[MT]を使用してSPBを他のNLPIDから分離することもオプションです。
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
SPBMのユニキャストフレームは、802.1AH [PBB]に従ってカプセル化されています。バックボーンソースアドレス（B-SA）、バックボーン宛先アドレス（B-DA）、バックボーンVLAN ID（B-VID）、およびIコンポーネントサービスインスタンスID（I-TAG）を使用して、イーサネットフレームをカプセル化します。B-SAは、通常、その橋全体の「既知の」B-MACであるIngress 802.1AQブリッジに関連付けられたB-MACです。B-DAは、出口802.1AQブリッジに関連する「既知の」B-MACの1つです。B-vidおよびi-tagは、物理的または論理的なuniポート（untagged、またはs-tagまたはc-tagのいずれかでタグ付け）に基づいてマッピングされます。通常の学習と
broadcast to unknown C-MACs is applied as per [PBB] at the ingress/egress SPBs only.
未知のC-MACSにブロードキャストは、Ingress/Egress SPBSのみで[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]とは異なり、タンデムノード（NNIからNNI）のB-DA転送は、学習せずに実行されます。代わりに、このドキュメントで指定されたTLVに基づいた802.1AQ計算の出力は、フィルタリングデータベース（FDB）の設定に使用されます。FDBエントリは、発信インターフェイスにマップされ、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.
ヘッドエンドの複製は、関心のあるまばらなコミュニティやマルチキャストトラフィックの可能性が低い例でサポートされています。ヘッドエンドの複製には、コアにマルチキャスト状態が必要ありません。ヘッドエンドレプリケーションを使用したいUNIポートは、送信（T）ビットセットで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）ポートに到着すると、パケットは各レシーバーに対して1回複製され、カプセル化され、ユニキャストフレームとして送信されます。。レシーバーのセットは、Rビットセットで同じI-SIDに関心を登録した他のSPBのIS-ISデータベースを検査することにより決定されます。このRビット / I-SIDペアは、SPBMサービス識別子およびユニキャストアドレス（SPBM-SI）Sub-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.
タンデムレプリケーションでは、最短のパスツリーを使用して、ツリーがフォークし、各ブランチに少なくとも1つのレシーバーがある場合にのみフレームを複製します。タンデムレプリケーションは帯域幅効率的ですが、コアブリッジでマルチキャスト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アドレスは、spsourceid a 'をi-sid m（da = <a'、m>と書かれ、ユニークな識別（）と連結する、よく形成されたマルチキャストグループアドレス（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])
図1：SPBMマルチキャストアドレス形式（SPSRCMSは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 typはspsourceidタイプです。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-INST）Sub-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ネットワークへのIngressで最初にカプセル化された場合、DAオンフレームとして使用されます。DAは、同じI-SIDで受信機の関心を登録しているソースと他のノードの間に対応するSPT上にあるすべてのSPBMノードのFDBにインストールされます。
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を使用して侵入チェックを実行できますが、DAでエンコードされたSPSourceIDと[PBB]のFDBの「ドロップオン」機能は同じことを達成します。効果。
The I-Component at the egress SPBM device has completely standard [PBB] behavior and therefore will:
Egress SPBMデバイスのI成分には完全に標準の[PBB]動作があるため、次のようになります。
1) learn the remote C-SA to B-SA relationship and
1) リモートC-SAからB-SA関係を学びます
2) bridge the original customer frame to the set of local UNI ports that are associated with the I-SID.
2) 元の顧客フレームを、I-SIDに関連付けられているローカルユニポートのセットに橋渡しします。
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ポートに到着すると、このVLANとIngress SPBの対応するSPVIDを使用して、VID翻訳（または未編成フレームのVIDカプセル化）が実行されます。
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にすぎません。その結果、SPBVユニキャストの転送が通常の逆学習ファッションで動作できるように、同じ基本VIDに関連付けられた前方パスと逆パスのSPVIDの間で共有VLAN学習（SVL）が使用されます。
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.
Ingress Checkは、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およびIngressブリッジに対応する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.
Ingressチェックは、以前の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デバイスは、同じC-DAマルチキャストアドレスを宣伝するSPBV UNIポート間のSPFツリー上にあるかどうかを確認し、その場合はマルチキャスト状態をインストールしてSPBV SPFツリーをたどります。
Ingress check is as per the previous two SPBV sections.
Ingressチェックは、以前の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".
図2に示す小さなサンプルネットワークを考えてみましょう。ノードは、B-MACアドレスの最後のニブルが付いたボックスに描かれています。1..：7。B-MACアドレスの残りのニブルは4455-6677-00XXです。リンクは「 - 」と「/」として描画され、インターフェイスインデックスはリンクの横にある数字として描画されます。UNIポートは「<==>」として表示され、UNIポートの終わりに「I1」として表示される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:
最低のブリッジIDで等しいコストパスを選択するデフォルトのECT-ALGORITHM（00-80-C2-01）を使用して、このECT-ALGORITHMはB-VID 100に割り当てられます。すべてのリンクが同じコストを持っている場合、1は1-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 }
{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-macsに向かってルーティングします：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.
ノード：1は、MDTのヘッドにノードを獲得するため、マルチキャストを生み出します：3、：5、および：7はI-SID 1の送信機であり、ノードは次のとおりです。。ノード：1したがって、DAにspsourceid（例のb-macの最後の20ビット）とi-sid 1を含むマルチキャスト転送エントリを生成します。2 b-vid = 100で2。ノード：1のフルユニキャスト（U）およびマルチキャスト（M）テーブルを図3に示します。IN/IF（着信インターフェイス）フィールドはユニキャストトラフィックに指定されていないことに注意してください。ツリーは、ツリーの頭でない限り、その場合は/00のコンベンションを使用します。ノード：1はマルチキャストのトランジットではないため、I-SID = 1用のツリーのルートの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)
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.
ノード：2のマルチキャストは、I-SID = 1の4人のメンバーのトランジットノードであるため、より複雑です。したがって、4つのマルチキャストFDBエントリが必要であり、どのメンバーが転送/複製されているかに応じて必要です。たとえば、ノード：2は、それぞれのノード{：3、：5、：7}と：1の間の最短パス上にあります。したがって、ノードから複製する必要があります：1 I-SID 1インターフェイスで{if/2、if/3およびif/5}（ノード：3、：5、および：7）。したがって、ノードのspsourceidを使用してマルチキャストdaを作成します：1はi-sid = 1と一緒に、インターフェイス/1を受信すると予想され、インターフェイス{if/2、if/3およびif/5}を再現します。これは、図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.
ノード：2は、ノードの間の最短パス上にないことに注意してください：3と：5またはノード間の間に：3と：7;ただし、パケットをノードに転送する必要があります：1ノードから1：3このI-SIDの場合、図4の2番目のマルチキャスト転送エントリになります。同様に、ノードで発生するパケット：5または：7、ノード：22回だけ複製する必要があるため、図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モード転送用に生成されたFDBを調べます。ノード：1、：5、：3、および：7は、マルチキャストアドレス0300-0000-000Fを使用して同じマルチキャストMacトラフィックを送信および受信したいと同時に、合同および対称ユニキャスト転送を必要とします。SPBVモードでは、唯一のカプセル化はCタグまたはSタグで、MACアドレスは従来のブリッジングのように逆パスが学習されます。
+----+ +----+
| :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.
同じECT-ALGORITHM（00-80-C2-01）を仮定して、最低のブリッジIDで等しいコストパスを選択すると、このECT-ALGORITHMはベースVID 100に割り当てられ、各ノードに対してSPVID = Base VIDノードID（すなわち、101、102..107）。すべてのリンクに同じコストがある場合、1ホップの最短パスはすべて直接的であり、2ホップの最短パス（もちろん対称）は、図2で以前に示されています。
Node :1's SPT for this ECT-ALGORITHM is therefore (described as a sequence of unidirectional paths):
ノード：このECT-ALGORITHMの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.
したがって、FDBには、ノード：1から発生するパケット用に予約されたSPVIDのエントリが必要です。この場合はVID = 101です。
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.
ノード：2したがって、図6のように見えるFDBがあります。特に、インターフェイス/01でVID 101からパケットを取得し、ノードに送信します：3、：5、および：7 vyif/2、if/3、およびif if/5。他のノード（：4および：6）にノードから直接SPTによって到達されるため、他の場所では複製しません。FDBユニキャストエントリの残りの部分は、同様のパターンに従います。4と：6の間の最短パスはノード：1を介して、IF/4とIF/6の2つのインターフェイスのみに複製を説明することを思い出してください。宛先アドレスはワイルドカードであり、これらはすべてベースVID = 100に関連付けられているため、これらのSPVIDの間にSVLが存在することに注意してください。
+-------+-------------------+------+-----------------+
| 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計算の一部とは見なされず、物理トポロジに存在する場合は回避されます。他のNLPIDは、もちろん通常のようにそれらを使用する場合があります。
IS-IS for SPB Must use the IS-IS three-way handshake for IS-IS point-to-point adjacencies described in RFC 5303.
SPBのIS-ISは、RFC 5303で説明されているIS-I-I-ISポイントツーポイント隣接にIS-I-IS 3ウェイハンドシェイクを使用する必要があります。
The default behavior of 802.1aq is to use the normal IS-IS Ethernet multicast addresses for IS-IS.
802.1AQのデフォルトの動作は、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
ただし、特別なユースケースのために802.1AQに割り当てられた追加のイーサネットマルチキャストアドレスがあります。これらは、IS-ISの状態機械やパケット形式を決して変更しませんが、単に
recommend and reserve different multicast addresses. Refer to [802.1aq] for additional details.
さまざまなマルチキャストアドレスを推奨し、予約します。詳細については、[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のみをサポート）は、IS-ISエリアアドレス値0を使用する必要があり、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.
非スタンドアロンの実装（他のNLPIDをサポート）は、レベル1ドメインの確立に通常のIS-I-ISルールを使用する必要があります（つまり、即時隣接が共通エリアアドレスを共有する場合にのみ、複数の領域アドレスが許可されます）。もちろん、レベル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で伝播する場合があります。IS-IS SPB実装はレベル1をサポートする必要があり、レベル2の操作をサポートする場合があります。階層SPBはさらなる研究のためです。したがって、これらのTLVは、レベル1とレベル2の間に漏れてはなりません。
The default algorithm is ECT-Algorithm = 00-80-c2-01.
デフォルトのアルゴリズムはECT-ALGORITHM = 00-80-C2-01です。
Two mechanisms are used to ensure symmetry and determinism in the shortest path calculations.
最短経路計算で対称性と決定論を確保するために2つのメカニズムが使用されます。
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.
最初のメカニズムは、隣接する異なる端（ノード）がSPBリンクメトリックの異なる値を宣伝する場合の問題に対処します。これを解決するには、SPBの最短パス計算では、（サブ）パスコストを蓄積して最小化する際に、2つのノードの宣伝されたSPB-Link-Metricsの最大値を使用する必要があります。
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番目のメカニズムは、2つの等しいリンクメトリック（サブ）パスが見つかった場合の問題に対処します。これを解決するには、フォーク/結合ポイントの間に最も少ないホップを持つ（サブ）パスがネクタイを獲得する必要があります。ただし、両方の（サブ）パスがフォークと結合ポイントの間に同じ数のホップ数がある場合、デフォルトのタイブレークは、下部ブリッジIDを使用して中間ノードを横断するパスを選択する必要があります。BridgeIDは8バイトの量であり、その上部2バイトはノードのブリッジプリオリティであり、6バイトの下部はノードのシステムです。
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.
たとえば、ノードから最短パス計算が行われている場合は、図2のネットワークを検討してください：1。ノードに到達すると、7、2つの競合するサブパスフォークがノード：1に参加し、ノード：7、最初のvia：2、2番目のvia：6に参加します。すべてのノードがブリッジの優先度0を宣伝すると仮定すると、デフォルトのタイブレークルールは、ノード：6 {0よりも低いブリッジ{0 ...：2}を持つため、パスを通過するノードを通過します。2を選択します。。：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-01から00-80-C2-10があります。これらの指定は、IEEE 802.1 OUI（組織的に一意の識別子）値00-80-C2で構成されています。これらの個々のアルゴリズムは、次の値を最低の（サブ）パスを選択することにより実装されます。
XOR BYTE BY BYTE(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
xor byte by byte -xors bridgeid bytes with 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}は、すべてのZerosとXorsであるため、上記のデフォルトのアルゴリズム（00-80-C2-01）を生成します。ect-mask {2}は、すべてのマスクを備えたxorsであるため、ブリッジIDを反転させ、本質的に最大のブリッジIDを横断するパスを選択します。他のECTマスクは、多様な代替品を生成します。すべての場合において、ブリッジの範囲は、それがブリッジIDの最も重要な部分であるため、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.
将来、他の多くのタイブレイクメカニズムをサポートするために、2つの不透明なエクト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-ALGORITHMSはVIDSにマッピングされ、サービスをそれらの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には、NLPID値0xc1 [RFC6328]が割り当てられています。これは、このNLPID値をIS-IS IIH PDUプロトコルサポートTLVに含めることによって行われます（タイプ129）。802.1AQフレームは、このNLPIDをIIH PDUの両方向に宣伝する隣接する隣接にのみ流れる必要があります。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と同様に、3つの新しいTLVを使用して正常なIIH PDUを増強し、マルチトポロジー[MT] TLV内で移動するため、単一のISプロトコルインスタンス内でSPBの複数の論理インスタンスを許可します。
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は、一般的でコンパクトなエンコーディングを使用するSPB-MCID TLVと呼ばれるすべての使用されているVID（NNI）のダイジェストを運びます。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の近隣は、トポロジデータベースの内容が同期されていることを確認するメカニズムをサポートする場合があります（ループ予防の目的で）。これは、SPBトポロジー情報のダイジェストを交換し（すべてのMT IDで計算）、ダイジェストがトポロジの不一致を示している場合に特定のアクションを実行することによって行われます。このダイジェストは、オプションのSPB-Digest Sub-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-ALGORITHMSで定義されている）がどのVIDSで使用されているかを知る必要があり、これはベースVLAN識別子（SPB-B-VID）Sub-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はIIH PDUに追加され、複数のスパニングツリー構成のダイジェストを示します。このTLVは、どのVIDがどのプロトコルを実行しているかのローカル構成のダイジェストです。（情報は、SPBの場合の特定のアルゴリズムのレベルではありません。）この情報は、IS-ISインスタンスによって制御されるSPT領域のすべてのブリッジで同じでなければなりません。MCIDを生成するために使用されるデータは構成によって入力され、さまざまなプロトコルに割り当てられたVIDのダイジェストです。変更が非批判的である場合、構成間の非破壊的な遷移を可能にするために、2つの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バイト）：IEEE 802.1Qで定義された完全なMCID。これは、レジーム（XSTP、SPBV、SPBMなど）を制御するためのVIDの一致する割り当てに基づいてSPT領域を識別します。簡単に言えば、MCIDは、1バイト形式のセレクター、32バイト構成名、2バイトの改訂レベル、最後に、最終的には、識別子の識別子を含む4096要素の配列上のタイプHMAC-MD5の16バイトの署名で構成されています。対応するVIDの使用。[802.1AQ]のセクション13.8を参照してください。正確な形式と手順を参照してください。VIDの使用には、特定のSPB ECT-ALGORITHMの仕様は含まれていないことに注意してください。むしろ、それは粗い穀物です。
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 AUX MCID（51バイト）：IEEE 802.1Qで定義された完全なMCIDは、SPT領域を識別します。AUX MCIDにより、SPT領域は、既存のトラフィックを中断することなく、新しいVLANのFDBマッピングへの割り当てによって移行できます。
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 SUB-TLVは、MT-Port-CAP TLV [RFC6165]内でMT ID値が0で、IIH PDUで運ばれます。
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にオプションで追加されます。MT ID値0のMT-Port-Cap TLV [RFC6165]で常に携帯されています。一致するダイジェストは、2つのSPB間のトポロジービューが同期されていることを（非常に高い確率で）示しています。この一致（または一致の欠如）は、転送情報の更新を制御するために使用されます。SPB Asmartion Digestは、すべての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.
o A（2ビット）：BPDUの契約番号コンセプト[802.1AQ]と一致する合意番号0-3。このノードの合意が変化すると、この数は増加します。次に、ノードは合意ダイジェストマッチをチェックします（以下のように）。新しいローカル契約番号と更新されたローカル廃棄された契約番号は、Hello PDUのNodeのNeighborsに新しい契約ダイジェストで送信されます。契約番号が送信されると、隣人から一致するまたは最近の廃棄された契約番号が受信されるまで未解決と見なされます。
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ビット）：廃棄された契約番号0-3。これは、BPDUの契約番号の概念と一致します。近隣から契約ダイジェストを受け取った場合、この番号は受信した契約番号に設定され、このノードがこの新しい契約を受け取り、以前の契約を破棄したことを示します。次に、ノードは、ローカルおよび受信した契約ダイジェストが一致するかどうかを確認します。もしそうなら、このノードは次のように設定します。
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-Digest Sub-TLVは、MT-PORT-CAP TLV [RFC6165]（MT ID値0）内で運ばれ、IIH PDUで運ばれます。
When supported, this sub-TLV MUST be carried on every IIH between SPB neighbors, not just when a Digest changes.
サポートされる場合、このサブTLVは、ダイジェストが変化したときだけでなく、SPB近隣のすべてのIIHに携帯する必要があります。
When one peer supports this TLV and the other does not, loop prevention by Agreement Digest Must Not be done by either side.
1つのピアがこのTLVをサポートし、もう1つのピアが合意によるループ予防をサポートしない場合、どちらの側でもループ防止を行う必要はありません。
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はIIH PDUに追加されて、ECTアルゴリズムとベースVIDS間のマッピングを示します（および含意により、ベースVIDによって識別されるVLANセットの各SPTセットの転送パスで使用されるVID（s）があります）使用する。安定した動作条件下では、この情報は、MT-Port-CAP 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-ALGORITHM（4バイト）：ECT-ALGORITHMは、ブリッジが特定のベースVIDで特定のECTアルゴリズム（OUI/インデックス）をサポートするときに宣伝されます。インデックス値0x00..0x10が低い8ビットを占めるSPBには17の事前定義されたIEEEアルゴリズムがあり、IEEE OUI = 00-80-C2はECTアルゴリズムの上位24ビットを占めています。
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-Flag（1ビット）：このブリッジ、またはLSDBのブリッジが現在このECTアルゴリズムとベースVIDを使用している場合、使用フラグは設定されています。リモート使用は、他のSPBブリッジのSPB-INSTサブ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ビット）：Mビットは、このベースVIDがSPBM（M = 1）またはSPBV（M = 0）モードで動作するかどうかを示します。
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は、MT-Port-CAP TLV [RFC6165]内に運ばれ、IIH PDUで運ばれます。
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-INST SUB-TLVは、このノード/トポロジインスタンスのSPSourceIDを提供します。これは、このノード/インスタンスから発信されるフレームのマルチキャストDASの形成に使用される20ビット値です。Spsourceidは、マルチキャストDAの上部20ビットと4つの他のビットを占めています（SPBM 802.1AHマルチキャストDAアドレス形式セクションを参照）。このサブTLVは、フラグメントゼロLSPのMT能力TLV内で運ばれる必要があります。追加のSPBインスタンスがある場合、それ
MUST be declared under a separate MT-Capability TLV and also carried in the fragment ZERO LSP.
個別のMTキャピールTLVの下で宣言し、フラグメントゼロ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.
o CISTルート識別子（64ビット）：CISTルート識別子は、SPT領域の境界でのRapid 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は、ブリッジの優先度とシステムIDを組み合わせて8バイトブリッジ識別子を形成することにより、リンク状態を使用して互換性のあるスパニングツリーを構築できます。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]で定義されています。SPBMを実行しているブリッジは、明示的なspsourceidで構成されていない場合、spsourceidを割り当てます。Vビットにより、近隣のブリッジは自動配分が有効かどうかを判断できます。Spsourceid割り当ての衝突の可能性はまれに、最優先ブリッジ識別子が最も高い橋が競合に勝ちます。優先度の低いブリッジが再割り当てされます。または、優先度の低いブリッジが構成されている場合、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ノード）に由来するマルチキャストフレームについて、以下で説明するマルチキャストDASを構築するために使用される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-algorithm、base vid plusフラグ}タプルの数に設定されます。各ECT-ALGORITHMには、以下で説明するベースVID、SPVID、およびフラグがあります。これには、少なくとも1つのECTアルゴリズム（00-80-C2-01）が含まれている必要があります。
Each VID Tuple consists of:
各ビデオタプルは次のとおりです。
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-sids ITソースまたはシンクにこのECTアルゴリズムを使用している場合、Uビットが設定されています。これは厳密にローカルな兆候です。セマンティクスは、Helloで見つかったユースフラグとは異なります。これにより、他のNodal Uビットが設定されているか、ソースまたはシンクが表示されている場合に使用フラグが設定されます。
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ビット）：mビットは、これがSPBMモードかSPBVモードかを示します。クリアされると、モードは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 bit（spb）、設定すると、これは自動配分を伴うspvidであると宣言します。VID割り当てロジックの詳細はIEEE [802.1AQ]にあります。SPVIDは12ビットリソースの小さなプールから割り当てられているため、衝突の可能性は高くなっています。自動配分中の衝突を最小限に抑えるために、LSPは最初にSPVIDを0に設定する発信ブリッジで宣伝されます。これにより、衝突の可能性は最小限に抑えられますが、排除されません。衝突が発生した場合、最高のブリッジ識別子を使用して勝者を選択しますが、下部ブリッジ識別子の敗者はSPVID割り当てを引き出し、別の試験の代替候補を選択する必要があります。SPVIDも設定される場合があります。Aが自動配分を指定しないように少し設定され、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-ALGORITHM（4バイト）：ECT-ALGORITHMは、ブリッジが特定のVIDで特定のECTアルゴリズム（OUI/インデックス）をサポートするときに宣伝されます。この宣言は、同じブリッジから発信されるHello PDUの宣言と一致する必要があります。ECT-ALGORITHMとBASE VIDは、同じノードのIIHSで生成されたものと一致する必要があります。ただし、ECT-ALGORITHMであるベースVIDタプルは、任意の順序で提供できます。現在、値00-80-C2-00から00-80-C2-10で与えられた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-ALGORITHMを介して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.
o SPVID（12ビット）：SPVIDは、SPBVモードを使用するときにこのノードにベースVIDに割り当てられた最短パスVIDです。SPBMモードでは定義されておらず、SPBMモードB-VIDSでは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を使用して、新しいアルゴリズムパラメトリックデータを定義します。タイブレイクパラメーターには、2つの広範なクラスにはアルゴリズムがあります。1つは結び目を破るためにノードデータを使用し、1つはリンクデータを使用してタイを破ることです。このサブTLVは、不透明なタイブレークデータをノードに関連付けるために使用されます。このサブTLVは、存在する場合、MT能力TLV内に（有効なSPB-INST SUB-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-ALGORITHM：ECT-ALGORITHMは、ブリッジが特定のVIDで特定のECTアルゴリズム（OUI/インデックス）をサポートするときに宣伝されます。
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情報：必要に応じてIANA番号スペースを使用してサブTLV形式である必要がある可変長さのECT-ALGORITHM情報。
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-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-Metric：このリンクを24ビットの署名数字として使用する管理コストまたは重量。このメトリックは、SPBトラフィックのみにこのリンクを使用することに適用されます。数字が少ないことを示しており、SPBトラフィックを運ぶ可能性が高くなります。リンクごとにSPBインスタンスごとに許可されるメトリックは1つだけです。複数のメトリックが必要な場合は、IS-IS内またはいくつかの独立したIS-ISインスタンス内で、複数のSPBインスタンスを使用する必要があります。このメトリックがリンクの各端で異なる場合、このリンクの重みのすべてのSPB計算で2つの値の最大値を使用する必要があります。最大SPB-Link-Metric値2^24-1には特別な意味があります。この値は、IS-IS隣接性が形成されているが、SPB自体（異なる領域など）内で構成されたパラメーターで互換性のない値が検出され、リンクをSPBトラフィックの運搬に使用してはならないことを示しています。詳細については、[802.1aq]に記載されています。
o Num of Ports: the number of ports associated with this link.
o ポートの数：このリンクに関連するポートの数。
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の複数のコピーは、この隣接に関連するさまざまな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-ALGORITHM：ECT-ALGORITHMは、ブリッジが特定のVIDで特定のECTアルゴリズム（OUI/インデックス）をサポートするときに宣伝されます。
o ECT Information: ECT-ALGORITHM Information of variable length in sub-TLV format using new IANA type values as appropriate.
o ECT情報：必要に応じて、新しいIANAタイプ値を使用したサブTLV形式の変数長のECT-アルゴリズム情報。
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 Sub-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アドレスが1つしかない場合、これはノードの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-Inst Sub-TLVで定義されたECT-ALGORITHMおよび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.
B-MAC単一のサブTLVに収まるよりも、このサブ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 sub-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 Sub-TLVは、IS-IS SUB-TLVタイプ4です。SPBVモードのグループMACアドレスの広告に使用する必要があります。ユニキャスト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 長さ：値フィールドに含まれるバイトの総数。SPVIDに関連付けられたMACアドレスの数は、（長さ-2）/7で計算されます。
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
o SRビット（2ビット）：SRビットは、MMRPのサービス要件パラメーターです。サービス要件パラメーターには、値0（すべてのグループを転送）と1（すべての未登録のグループを転送する）が定義されています。ただし、この属性も欠落している可能性があります。したがって、SRビットは、宣言されていない0、1つのすべてのグループ、2つの未登録グループを転送する2つとして定義されます。2つの「R」予約ビット
immediately preceding these SR bits Shall be set to zero when originating this sub-TLV and Shall be ignored on receipt.
これらのSRビットの直前に、このサブTLVを発信する場合はゼロに設定され、受領時に無視されます。
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およびAssociation Base VIDおよびECT-ALGORITHMとSPTセット以下に定義されているMACアドレスが使用されます。SPVIDが割り当てられていない場合、SPVID値は0です。使用中のECTアルゴリズムがスパニングツリーアルゴリズムである場合、この値にベース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にインストールする必要があることを示しています。このMacをtビットセットとこのグループ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-ALGORITHMの対応する最短パスにツリーを計算するときに、受信機としてMACアドレスを入力および設置する必要があることを示しています。トランジットブリッジがFDBにマルチキャスト転送状態をインストールしてはならないため、グループMACアドレスにこのビットセットがこのグループ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エントリを入力することにより、宛先用に効率的に構築できます。これは、SPTSの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 Sub-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.
ただし、このプロトコルは、ゼロ構成環境で使用できます。ゼロ構成は、IS-IS隣接（NNIポートを形成する）の自動検出と形成に適用される場合があります。同様に、ゼロ構成は、VLANタグ付きトラフィックの自動検出とUNIポートの形成に適用される場合があり、結果としてI-SID広告が表示されます。
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.
ゼロ構成メソッドがNNISまたはUNISを自動構成するために使用される場合、上記のケースの認証手順で緩和される本質的なセキュリティ上の懸念があります。このような手順は、このドキュメントの範囲を超えており、まだ定義されていません。
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 PDUSで使用されている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は適切なMT TLVのコンテキストで発生する必要があります（SPBメトリックサブTLVを除き、MT 22で移動する可能性があります。IDは特定されていませんが、0であると暗示されています。IANAは、802.1AQあたり3つのマルチトポロジーTLVにサブTLVを割り当てました。これらは、IIHで使用されるMT-PORT-CAP TLV [RFC6165]、LSP内で使用されるMT容量TLV（新しい）、そして最後にLSP内の隣接情報を含めるために使用されるMT-ISN TLV [MT]です。
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.
このドキュメントでは、以下に説明するように、IIHおよびLSP PDUS MT TLV内に次のTLVとSUB-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です。タイプ値144が割り当てられており、Start Sub-TLV値は1で、Expert Reviewで管理されています。
+-----+----+-----------------+--------+------+-------------+
| 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
MT-ISN 222
or Extended IS Reachability 22
* SPB-Metric 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、第2版、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システムへの中間システム内領域内領域内ルーティング交換プロトコル」、2002。
[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.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）中間システムのルーティング（IS-IS）」、RFC 5120、2008年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「レイヤー2システムのIS-ISへの拡張」、RFC 6165、2011年4月。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328] EastLake 3rd、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] Handley、M.、Ed。、Rescorla、E.、ed。、および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.
著者は、Ayan Banerjee、Mick Seaman、Janos Farkas、Les Ginsberg、Stewart Bryant、Donald Eastlake、Matthew Bocci、Mike Shandに貢献や詳細なレビューに感謝します。
Authors' Addresses
著者のアドレス
Don Fedyk (editor) Alcatel-Lucent Groton, MA 01450 USA EMail: Donald.Fedyk@alcatel-lucent.com
Don Fedyk（編集者）Alcatel-Lucent Groton、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
Peter Ashwood-Smith（編集者）Huawei Technologies Canada Ltd. 303 Terry Fox Drive、Suite 400 Kanata、Ontario、K2K 3J1 Canada：peter.ashwoodsmith@huawei.com
Dave Allan Ericsson 300 Holger Way San Jose, CA 95134 USA EMail: david.i.allan@ericsson.com
Dave Allan Ericsson 300 Holger Way San Jose、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
Nigel Bragg Ciena Limited Ciena House 43-51 Worshing Street London EC2A 2DX UKメール：nbragg@ciena.com
Paul Unbehagen Avaya 8742 Lucent Boulevard Highlands Ranch, CO 80129 USA EMail: unbehagen@avaya.com
Paul Unbehagen Avaya 8742 Lucent Boulevard Highlands Ranch、Co 80129 USAメール：unbehagen@avaya.com