[要約] 要約：RFC 7727は、スパニングツリープロトコル（STP）のインターチャシス通信プロトコル（ICCP）への適用に関するものである。 目的：ICCPを使用してSTPを複数のシャーシ間で通信するための標準化とガイドラインを提供する。
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 7727 H. Wen
Category: Standards Track Huawei
ISSN: 2070-1721 J. Hu
China Telecom
January 2016
Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
シャーシ間通信プロトコル（ICCP）のスパニングツリープロトコル（STP）アプリケーション
Abstract
概要
The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.
シャーシ間通信プロトコル（ICCP）は、高いネットワーク可用性をサポートするために使用されるシャーシ間冗長メカニズムをサポートしています。
In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.
このドキュメントでは、ICCPを実行している冗長グループ（RG）のプロバイダーエッジ（PE）デバイスを使用して、スパニングツリープロトコル（STP）ネットワークへのマルチホーム接続を提供し、STPネットワークの可用性を向上させます。 ICCP TLVとICCP STPアプリケーションの使用法が定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7727.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7727で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Use Case ........................................................5
3. Spanning Tree Protocol Application TLVs .........................6
3.1. STP Connect TLV ............................................6
3.2. STP Disconnect TLV .........................................7
3.2.1. STP Disconnect Cause Sub-TLV ........................8
3.3. STP Configuration TLVs .....................................8
3.3.1. STP System Config ...................................9
3.3.2. STP Region Name ....................................10
3.3.3. STP Revision Level .................................10
3.3.4. STP Instance Priority ..............................11
3.3.5. STP Configuration Digest ...........................12
3.4. STP State TLVs ............................................12
3.4.1. STP Topology Changed Instances .....................12
3.4.2. STP CIST Root Time Parameters ......................14
3.4.3. STP MSTI Root Time Parameter .......................15
3.5. STP Synchronization Request TLV ...........................16
3.6. STP Synchronization Data TLV ..............................17
4. Operations .....................................................18
4.1. Common AC Procedures ......................................18
4.1.1. Remote PE Node Failure or Isolation ................19
4.1.2. Local PE Isolation .................................19
4.2. ICCP STP Application Procedures ...........................19
4.2.1. Initial Setup ......................................19
4.2.2. Configuration Synchronization ......................20
4.2.3. State Synchronization ..............................21
4.2.4. Failure and Recovery ...............................22
5. Security Considerations ........................................22
6. IANA Considerations ............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
Acknowledgements ................................................. 24
Authors' Addresses ............................................... 25
Inter-Chassis Communication Protocol (ICCP [RFC7275]) specifies a multi-chassis redundancy mechanism that enables Provider Edge (PE) devices located in a multi-chassis arrangement to act as a single Redundancy Group (RG).
シャーシ間通信プロトコル（ICCP [RFC7275]）は、マルチシャーシ構成にあるプロバイダーエッジ（PE）デバイスが単一の冗長グループ（RG）として機能できるようにするマルチシャーシ冗長メカニズムを指定します。
With the Spanning Tree Protocol (STP), a spanning tree will be formed over connected bridges by blocking some links between these bridges so that forwarding loops are avoided. This document introduces support of STP as a new application of ICCP. When a bridged STP network is connected to an RG, this STP application of ICCP enables the RG members to act as a single root bridge participating in the operations of STP.
スパニングツリープロトコル（STP）を使用すると、接続されたブリッジ上で、これらのブリッジ間のリンクをブロックすることによってスパニングツリーが形成され、転送ループが回避されます。このドキュメントでは、ICCPの新しいアプリケーションとしてSTPのサポートを紹介します。ブリッジングされたSTPネットワークがRGに接続されている場合、このICCPのSTPアプリケーションにより、RGメンバーはSTPの操作に参加する単一のルートブリッジとして機能できます。
STP-relevant information needs to be exchanged and synchronized among the RG members. New ICCP TLVs for the ICCP STP application are specified for this purpose.
STP関連の情報は、RGメンバー間で交換および同期する必要があります。 ICCP STPアプリケーションの新しいICCP TLVは、この目的のために指定されています。
From the point of view of the customer, the Service Provider is providing a Virtual Private LAN Service (VPLS) [RFC4762].
顧客の観点から、サービスプロバイダーは仮想プライベートLANサービス（VPLS）[RFC4762]を提供しています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
ICCP: Inter-Chassis Communication Protocol VPLS: Virtual Private LAN Service STP: Spanning Tree Protocol MSTP: Multiple Spanning Tree Protocol MST: Multiple Spanning Trees CIST: Common and Internal Spanning Tree ([802.1q], Section 3.27) MSTI: Multiple Spanning Tree Instance ([802.1q], Section 3.138) BPDU: Bridge Protocol Data Unit
ICCP：シャーシ間通信プロトコルVPLS：仮想プライベートLANサービスSTP：スパニングツリープロトコルMSTP：マルチスパニングツリープロトコルMST：マルチスパニングツリーCIST：共通および内部スパニングツリー（[802.1q]、セクション3.27）MSTI：マルチスパニングツリーインスタンス（[802.1q]、セクション3.138）BPDU：ブリッジプロトコルデータユニット
In this document, unless otherwise explicitly noted, the term "STP" also covers MSTP.
このドキュメントでは、特に明記されていない限り、「STP」という用語はMSTPもカバーしています。
Customers widely use Ethernet as an access technology [RFC4762]. It's common that one customer's Local Area Network (LAN) has multiple bridges connected to a carrier's network at different locations for reliability purposes. Requirements for this use case are listed as follows.
顧客はイーサネットをアクセステクノロジーとして広く使用しています[RFC4762]。 1人の顧客のローカルエリアネットワーク（LAN）には、信頼性を確保するために、さまざまな場所でキャリアのネットワークに接続された複数のブリッジがあることが一般的です。このユースケースの要件は次のとおりです。
o Customers desire to balance the load among their available connections to the carrier's network; therefore, all the connections need to be active.
o 顧客は、キャリアのネットワークへの利用可能な接続間で負荷のバランスをとることを望んでいます。したがって、すべての接続がアクティブである必要があります。
o When one connection to the carrier network fails, customers require a connection in another location to continue to work after the reconvergence of the STP rather than compromising the whole STP network. The failure of the connection may be due to the failure of the PE, the attachment circuit (AC), or even the Customer Edge (CE) device itself.
o キャリアネットワークへの1つの接続が失敗した場合、STPネットワーク全体を危険にさらすのではなく、STPの再コンバージェンス後も引き続き機能するには、別の場所に接続する必要があります。接続の失敗は、PE、接続回路（AC）、またはカスタマーエッジ（CE）デバイス自体の障害が原因である可能性があります。
In order to meet these requirements, the 'ICCP-STP' model is proposed. It introduces STP as a new application of ICCP.
これらの要件を満たすために、「ICCP-STP」モデルが提案されています。 ICCPの新しいアプリケーションとしてSTPを紹介します。
+--------------+ +=============+
| | | |
| | | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE1+<6>-------<5>+ PE1 || | |
| <1> +---+ | | +-----+|<--|--Pseudowire-->|
| +-+-+ | | || |
| |CE3| | | ||ICCP |--> Towards the Core
| +-+-+ | | || |
| <2> +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE2+<3>-------<4>+ PE2 || | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| | | |
| Multihomed | | Redundancy |
| STP Network | | Group |
+--------------+ +=============+
Figure 1: A STP network is multihomed to an RG running ICCP
図1：STPネットワークはICCPを実行しているRGにマルチホーム化されています
Figure 1 shows an example topology of this model. With ICCP, the whole RG will be virtualized to be a single bridge. Each RG member has its BridgeIdentifier (the MAC address). The numerically lowest one is used as the BridgeIdentifier of the 'virtualized root bridge'. The RG acts as if the ports connected to the STP network (ports <4> and <5>) are for the same root bridge. All these ports send the configuration BPDU with the highest root priority to trigger the construction of the spanning tree. The link between the peering PEs is not visible to the bridge domains of the STP network. In this way, the STP will always break a possible loop within the multihomed STP network by breaking the whole network into separate islands so that each is attached to one PE. That forces all PEs in the RG to be active. This is different from a generic VPLS [RFC4762] where the root bridge resides in the customer network and the multihomed PEs act in the active-standby mode. Note that the specification of VPLS remains unchanged other than for this operation. For instance, a full-mesh of pseudowires (PWs) is established between PEs, and the "split horizon" rule is still used to perform the loop-breaking through the core.
図1に、このモデルのトポロジーの例を示します。 ICCPでは、RG全体が仮想化されて単一のブリッジになります。各RGメンバーには、BridgeIdentifier（MACアドレス）があります。数値的に最小のものが、「仮想化ルートブリッジ」のBridgeIdentifierとして使用されます。 RGは、STPネットワークに接続されているポート（ポート<4>と<5>）が同じルートブリッジ用であるかのように動作します。これらのポートはすべて、ルートプライオリティが最も高い設定BPDUを送信して、スパニングツリーの構築をトリガーします。ピアリングPE間のリンクは、STPネットワークのブリッジドメインからは見えません。このように、STPは、ネットワーク全体を個別のアイランドに分割してそれぞれが1つのPEに接続されるようにすることで、マルチホームSTPネットワーク内のループを常に解消します。これにより、RG内のすべてのPEが強制的にアクティブになります。これは、ルートブリッジがカスタマーネットワークに存在し、マルチホームPEがアクティブスタンバイモードで動作する一般的なVPLS [RFC4762]とは異なります。 VPLSの仕様は、この操作以外は変更されないことに注意してください。たとえば、PE間で疑似配線（PW）のフルメッシュが確立され、コアを通るループ切断を実行するために「スプリットホライズン」ルールが引き続き使用されます。
This section specifies the ICCP TLVs for the ICCP STP application. The Unknown TLV bit (U-bit) and the Forward unknown TLV bit (F-bit) of the following TLVs MUST be sent as cleared and processed on receipt as specified in [RFC7275].
このセクションでは、ICCP STPアプリケーションのICCP TLVを指定します。 [RFC7275]で指定されているように、次のTLVの不明TLVビット（Uビット）と転送不明TLVビット（Fビット）は、クリアされた状態で送信され、受信時に処理される必要があります。
This TLV is included in the RG Connect Message to signal the initiation of an ICCP STP application connection.
このTLVは、RGCメッセージに含まれており、ICCP STPアプリケーション接続の開始を通知します。
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|F| Type=0x2000 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2000 for "STP Connect TLV"
「STP Connect TLV」の場合は0x2000に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- Protocol Version
- プロトコルバージョン
The version of ICCP STP application protocol. This document defines version 0x0001.
ICCP STPアプリケーションプロトコルのバージョン。このドキュメントでは、バージョン0x0001を定義しています。
- A bit
- 少し
Acknowledgement Bit. Set to 1 if the sender has received a STP Connect TLV from the recipient. Otherwise, set to 0.
確認ビット。送信者が受信者からSTP接続TLVを受信した場合は、1に設定します。それ以外の場合は0に設定します。
- Reserved
- 予約済み
Reserved for future use. These bits MUST be sent as 0 and ignored on receipt.
将来の使用のために予約されています。これらのビットは0として送信され、受信時に無視される必要があります。
- Optional Sub-TLVs
- オプションのサブTLV
There are no optional Sub-TLVs defined for this version of the protocol.
このバージョンのプロトコルには、オプションのSub-TLVが定義されていません。
This TLV is used in the RG Disconnect Message to indicate that the connection for the ICCP STP application is to be terminated.
このTLVは、RG切断メッセージで使用され、ICCP STPアプリケーションの接続が終了されることを示します。
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|F| Type=0x2001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2001 for "STP Disconnect TLV"
「STP Disconnect TLV」の場合は0x2001に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- Optional Sub-TLVs
- オプションのサブTLV
The only optional Sub-TLV defined for this version of the protocol is the "STP Disconnect Cause" sub-TLV, defined below:
このバージョンのプロトコルに定義されている唯一のオプションのサブTLVは、以下に定義されている「STP切断原因」サブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x200C for "STP Disconnect Cause TLV"
「STP切断原因TLV」の0x200Cに設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- Disconnect Cause String
- 切断原因文字列
Variable-length string specifying the reason for the disconnect, encoded in UTF-8 [RFC3629] format. Used for operational purposes.
切断の理由を指定する可変長文字列。UTF-8[RFC3629]形式でエンコードされます。運用目的で使用されます。
The STP Configuration TLVs are sent in the RG Application Data Message. When an STP Config TLV is received by a peer RG member, the member MUST synchronize with the configuration information contained in the TLV. TLVs specified in Sections 3.3.1 to 3.3.5 define specific configuration information.
STP構成TLVは、RGアプリケーションデータメッセージで送信されます。 STP Config TLVがピアRGメンバーによって受信されると、メンバーはTLVに含まれている構成情報と同期する必要があります。セクション3.3.1から3.3.5で指定されたTLVは、特定の構成情報を定義します。
This TLV announces the local node's STP System Parameters to the RG peers.
このTLVは、ローカルノードのSTPシステムパラメータをRGピアに通知します。
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|F| Type=0x2002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2002 for "STP System Config TLV"
「STP System Config TLV」の場合は0x2002に設定
- Length
- 長さ
Length of the ROID plus the MAC address in octets. Always set to 14.
ROIDとMACアドレスのオクテット単位の長さ。常に14に設定します。
- ROID
- ROID
Redundant Object Identifier; format defined in Section 6.1.3 of [RFC7275].
冗長オブジェクト識別子。 [RFC7275]のセクション6.1.3で定義されている形式。
- MAC Address
- Macアドレス
The MAC address of the sender. This MAC address is set to the BridgeIdentifier of the sender, as defined in [802.1q], Section 13.26.2. The numerically lowest 48-bit unsigned value of BridgeIdentifier is used as the MAC address of the Virtual Root Bridge mentioned in Section 2.
送信者のMACアドレス。このMACアドレスは、[802.1q]、セクション13.26.2で定義されているように、送信者のBridgeIdentifierに設定されます。 BridgeIdentifierの数値的に最小の48ビット符号なし値は、セクション2で説明した仮想ルートブリッジのMACアドレスとして使用されます。
This TLV carries the value of Region Name.
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2003 for "STP Region Name TLV"
「STPリージョン名TLV」の場合は0x2003に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- Region Name
- 地域名
The Name of the MST Region as specified in [802.1q], Section 3.142.
[802.1q]、セクション3.142で指定されているMSTリージョンの名前。
This TLV carries the value of Revision Level.
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revision Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2004 for "STP Revision Level TLV".
「STPリビジョンレベルTLV」の場合は0x2004に設定します。
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 2.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。常に2に設定します。
- Revision Level
- 改訂レベル
The Revision Level as specified in [802.1q], Section 13.8, item c.
[802.1q]、セクション13.8、アイテムcで指定されているリビジョンレベル。
This TLV carries the value of Instance Priority to other members in the RG.
このTLVは、インスタンスプライオリティの値をRGの他のメンバーに伝えます。
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|F| Type=0x2005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2005 for "STP Instance Priority TLV"
「STPインスタンスプライオリティTLV」の0x2005に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- Pri
- プリ
The Instance Priority. It is interpreted as unsigned integer with higher value indicating a higher priority.
インスタンスの優先度。値が大きく、優先度が高いことを示す、符号なし整数として解釈されます。
- InstanceID
- InstanceID
The 12-bit Instance Identifier of the CIST or MSTI. This parameter takes a value in the range 1 through 4094 for MSTI (as defined in [802.1q], Section 12.8.1.2.2) and takes value of 0 for CIST.
CISTまたはMSTIの12ビットのインスタンスID。このパラメーターは、MSTI（[802.1q]、セクション12.8.1.2.2で定義）に対して1から4094の範囲の値を取り、CISTに対して0の値を取ります。
This TLV carries the value of STP VLAN Instance Mapping.
このTLVには、STP VLANインスタンスマッピングの値が含まれています。
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|F| Type=0x2006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configuration Digest |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2006 for "STP Configuration Digest TLV"
「STP構成ダイジェストTLV」の場合は0x2006に設定
- Length
- 長さ
Length of the STP Configuration Digest in octets. Always set to 16.
オクテット単位のSTP構成ダイジェストの長さ。常に16に設定します。
- Configuration Digest
- 構成ダイジェスト
As specified in [802.1q], Section 13.8, item d.
[802.1q]、セクション13.8、アイテムdで指定されています。
The STP State TLVs are sent in the RG Application Data Message. They are used by a PE device to report its STP status to other members in the RG. Such TLVs are specified in the following subsections.
STP状態TLVは、RGアプリケーションデータメッセージで送信されます。それらは、RGの他のメンバーにSTPステータスを報告するためにPEデバイスによって使用されます。このようなTLVは、次のサブセクションで指定されています。
This TLV is used to report the Topology Changed Instances to other members of the RG. The sender monitors Topology Change Notification (TCN) messages and generates this list. The receiving RG member MUST initiate the Topology Change event, including sending BPDU with the Topology Change flag set to 1 out of the designated port(s) of the Topology Changed bridge domains of the STP network, and flushing out MAC addresses relevant to the instances listed in this TLV.
このTLVは、トポロジ変更インスタンスをRGの他のメンバーに報告するために使用されます。送信者はトポロジ変更通知（TCN）メッセージを監視し、このリストを生成します。受信側のRGメンバーは、トポロジ変更イベントを開始する必要があります。これには、STPネットワークのトポロジ変更ブリッジドメインの指定ポートからトポロジ変更フラグを1に設定してBPDUを送信し、インスタンスに関連するMACアドレスをフラッシュすることが含まれます。このTLVにリストされています。
If the PE device supports MAC Address Withdrawal (see Section 6.2 of [RFC4762]), it SHOULD send a Label Distribution Protocol (LDP) Address Withdraw Message with the list of MAC addresses towards the core over the corresponding LDP sessions. It is not necessary to send such a message to PEs of the same RG since the flushing of their MAC address tables should have been performed upon receipt of the STP Topology Changed Instances TLV.
PEデバイスがMACアドレス撤回をサポートしている場合（[RFC4762]のセクション6.2を参照）、対応するLDPセッションを介してコアに向けてMACアドレスのリストを含むラベル配布プロトコル（LDP）アドレス撤回メッセージを送信する必要があります（SHOULD）。 MACアドレステーブルのフラッシュはSTPトポロジ変更インスタンスTLVの受信時に実行されているはずなので、同じRGのPEにそのようなメッセージを送信する必要はありません。
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|F| Type=0x2007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2007 for "STP Topology Changed Instances TLV"
「STPトポロジ変更インスタンスTLV」の0x2007に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。
- InstanceID List
- InstanceIDリスト
The list of the InstanceIDs of the CIST or MSTIs whose topologies have changed as indicated by the TCN messages as specified in [802.1q], Section 13.14. The list is formatted by padding each InstanceID value to the 16-bit boundary as follows, where the bits in the "R" fields MUST be sent as 0 and ignored on receipt.
[802.1q]、セクション13.14で指定されているTCNメッセージによって示されるようにトポロジが変更されたCISTまたはMSTIのInstanceIDのリスト。リストは、各InstanceID値を次のように16ビット境界にパディングすることによってフォーマットされます。「R」フィールドのビットは0として送信され、受信時に無視される必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R| InstanceID#1 |R|R|R|R| InstanceID#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to report the Value of CIST Root Time Parameters ([802.1q], Section 13.26.7) to other members of the RG. All time parameter values are in seconds with a granularity of 1. For ranges and default values of these parameter values, refer to [802.1d1998], Section 8.10.2, Table 8-3; [802.1d2004] Section 17.14, Table 17-1; and [802.1q], Section 13.26.7.
このTLVは、RGの他のメンバーにCISTルート時間パラメーター（[802.1q]、セクション13.26.7）の値を報告するために使用されます。すべての時間パラメータ値は秒単位であり、粒度は1です。これらのパラメータ値の範囲とデフォルト値については、[802.1d1998]、セクション8.10.2、表8-3を参照してください。 [802.1d2004]セクション17.14、表17-1; [802.1q]、セクション13.26.7。
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|F| Type=0x2008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxAge | MessageAge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdDelay | HelloTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RemainingHops |
+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2008 for "STP CIST Root Time TLV"
「STP CIST Root Time TLV」の場合は0x2008に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 9.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。常に9に設定します。
- MaxAge
- MaxAge
The Max Age of the CIST. It is the maximum age of the information transmitted by the bridge when it is the Root Bridge ([802.1d2004], Section 17.13.8).
CISTの最大年齢。これは、ブリッジがルートブリッジの場合に送信される情報の最大経過時間です（[802.1d2004]、セクション17.13.8）。
- MessageAge
- MessageAge
The Message Age of the CIST (see [802.1q], Section 13.26.7).
CISTのメッセージエージ（[802.1q]、セクション13.26.7を参照）。
- FwdDelay
- FwdDelay
The Forward Delay of the CIST. It is the delay used by STP Bridges to transition Root and Designated Ports to Forwarding ([802.1d2004], Section 17.13.5).
CISTの転送遅延。これは、ルートおよび指定ポートを転送に移行するためにSTPブリッジが使用する遅延です（[802.1d2004]、セクション17.13.5）。
- HelloTime
- HelloTime
The Hello Time of the CIST. It is the interval between periodic transmissions of Configuration Messages by Designated Ports ([802.1d2004], Section 17.13.6).
CISTのハロータイム。これは、指定ポートによる構成メッセージの定期的な送信の間隔です（[802.1d2004]、セクション17.13.6）。
- RemainingHops
- RemainingHops
The remainingHops of the CIST ([802.1q], Section 13.26.7).
CISTの残りのホップ（[802.1q]、セクション13.26.7）。
This TLV is used to report the parameter value of MSTI Root Time to other members of the RG. As defined in [802.1q], Section 13.26.7, it is the value of remainingHops for the given MSTI.
このTLVは、MSTIルート時間のパラメーター値をRGの他のメンバーに報告するために使用されます。 [802.1q]のセクション13.26.7で定義されているように、これは特定のMSTIの残りのホップの値です。
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|F| Type=0x2009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID | RemainingHops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x2009 for "STP MSTI Root Time TLV"
「STP MSTI Root Time TLV」の場合は0x2009に設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 3.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。常に3に設定します。
- Pri
- プリ
The Instance Priority. It is interpreted as an unsigned integer with higher value indicating a higher priority.
インスタンスの優先度。これは、より高い優先度を示すより高い値を持つ符号なし整数として解釈されます。
- InstanceID
- InstanceID
The 12-bit Instance Identifier of the Multiple Spanning Tree Instance (MSTID). As defined in [802.1q], Section 12.8.1.2.2, this parameter takes a value in the range 1 through 4094.
多重スパニングツリーインスタンス（MSTID）の12ビットインスタンス識別子。 [802.1q]、セクション12.8.1.2.2で定義されているように、このパラメーターは1から4094の範囲の値を取ります。
- RemainingHops
- RemainingHops
The remainingHops of the MSTI. It is encoded in the same way as in [802.1q], Section 14.4.1, item f.
MSTIの残りのホップ。 [802.1q]、セクション14.4.1、アイテムfと同じ方法でエンコードされます。
The STP Synchronization Request TLV is used in the RG Application Data Message. This TLV is used by a device to request that its peer retransmit configuration or operational state. The following information can be requested:
STP同期要求TLVは、RGアプリケーションデータメッセージで使用されます。このTLVは、ピアが構成または動作状態を再送信することを要求するためにデバイスによって使用されます。以下の情報を要求できます。
- configuration and/or state of the STP system, - configuration and/or state for a given list of instances.
- STPシステムの構成および/または状態-インスタンスの特定のリストの構成および/または状態。
The format of the TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x200A for "STP Synchronization Request TLV"
「STP同期要求TLV」の場合は0x200Aに設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 4.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。常に4に設定します。
- Request Number
- 要求番号
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a corresponding response. The value of 0 is reserved for unsolicited synchronization, and it MUST NOT be used in the STP Synchronization Request TLV. As indicated in [RFC7275], given the use of TCP, there are no issues associated with the wrap-around of the Request Number.
2オクテット。リクエストを一意に識別する符号なし整数。要求を対応する応答と照合するために使用されます。値0は非送信請求同期用に予約されており、STP同期要求TLVで使用してはなりません（MUST NOT）。 [RFC7275]に示されているように、TCPを使用すると、リクエスト番号のラップアラウンドに関連する問題はありません。
- C-bit
- Cビット
Set to 1 if the request is for configuration data. Otherwise, set to 0.
要求が構成データに対するものである場合は、1に設定します。それ以外の場合は0に設定します。
- S-bit
- Sビット
Set to 1 if the request is for running state data. Otherwise, set to 0.
要求が実行状態データ用である場合は、1に設定します。それ以外の場合は0に設定します。
- Request Type
- リクエストの種類
14 bits specifying the request type, encoded as follows:
次のようにエンコードされた、要求タイプを指定する14ビット：
0x00 Request System Data 0x01 Request data of the listed instances 0x3FFF Request System Data and data of all instances
0x00システムデータの要求0x01リストされたインスタンスのデータの要求0x3FFFシステムデータとすべてのインスタンスのデータの要求
- InstanceID List
- InstanceIDリスト
The InstanceIDs of the CIST or MSTIs; format specified in Section 3.4.1.
CISTまたはMSTIのInstanceID。セクション3.4.1で指定された形式。
The pair of STP Synchronization Data TLVs are used by the sender to delimit a set of TLVs that are being transmitted in response to an STP Synchronization Request TLV. The delimiting TLVs signal the start and end of the synchronization data, and they associate the response with its corresponding request via the Request Number field. It's REQUIRED that each pair of STP Synchronization Data TLVs occur in the same fragment. When the total size of the TLVs to be transmitted exceeds the maximal size of a fragment, these TLVs MUST be divided into multiple sets, delimited by multiple pairs of STP Synchronization Data TLVs, and filled into multiple fragments. With the Request Number, lost fragments can be identified and re-requested.
STP同期データTLVのペアは、STP同期要求TLVに応答して送信されるTLVのセットを区切るために送信者によって使用されます。デリミタ付きTLVは同期データの開始と終了を知らせ、リクエスト番号フィールドを介して応答を対応するリクエストに関連付けます。 STP同期データTLVの各ペアは、同じフラグメントで発生する必要があります。送信されるTLVの合計サイズがフラグメントの最大サイズを超える場合、これらのTLVを複数のセットに分割し、STP同期データTLVの複数のペアで区切って、複数のフラグメントに埋める必要があります。リクエスト番号を使用すると、失われたフラグメントを識別して再リクエストできます。
The STP Synchronization Data TLVs are also used for unsolicited advertisements of complete STP configuration and operational state data. The Request Number field MUST be set to 0 in this case.
STP同期データTLVは、完全なSTP構成および動作状態データの一方的な通知にも使用されます。この場合、リクエスト番号フィールドは0に設定する必要があります。
STP Synchronization Data TLV has the following format:
STP同期データ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
set to 0x200B for "STP Synchronization Data TLV"
「STP同期データTLV」の場合は0x200Bに設定
- Length
- 長さ
Length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Always set to 4.
Uビット、Fビット、タイプ、および長さフィールドを除く、オクテット単位のTLVの長さ。常に4に設定します。
- Request Number
- 要求番号
2 octets. Unsigned integer identifying the Request Number of the "STP Synchronization Request TLV" that initiated this synchronization data response.
2オクテット。この同期データ応答を開始した「STP同期要求TLV」の要求番号を識別する符号なし整数。
- Reserved
- 予約済み
Reserved bits for future use. These MUST be sent as 0 and ignored on receipt.
将来使用するための予約済みビット。これらは0として送信され、受信時に無視される必要があります。
- S
- S
S = 0: Synchronization Data Start
S = 1: Synchronization Data End
Operational procedures for AC redundancy applications have been specified in Section 9.2 of [RFC7275]. The operational procedures of the ICCP STP application should follow those procedures, with the changes presented in this section.
AC冗長性アプリケーションの運用手順は、[RFC7275]のセクション9.2で指定されています。 ICCP STPアプリケーションの運用手順は、これらの手順に従う必要がありますが、このセクションで変更点を示します。
The following changes are introduced to the generic procedures of AC redundancy applications defined in Section 9.2.1 of [RFC7275].
[RFC7275]のセクション9.2.1で定義されているAC冗長性アプリケーションの一般的な手順に以下の変更が導入されました。
When a local PE device detects that a remote PE device that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5 of [RFC7275]), the local PE device checks if it has redundancy ACs for the affected services. If redundant ACs are present, and if the local PE device has the new highest bridge priority, the local PE device becomes the virtual root bridge for corresponding ACs.
ローカルPEデバイスが同じRGのメンバーであるリモートPEデバイスに到達できないことを検出すると（[RFC7275]のセクション5で説明されているメカニズムを使用して）、ローカルPEデバイスは、影響を受けるための冗長ACがあるかどうかを確認しますサービス。冗長ACが存在し、ローカルPEデバイスが新しい最高のブリッジ優先度を持つ場合、ローカルPEデバイスは対応するACの仮想ルートブリッジになります。
When a PE device detects that it has been isolated from the core network, then it needs to ensure that its AC redundancy mechanism will change the status of all active ACs to standby. The AC redundancy application SHOULD then send an RG Application Data Message in order to trigger failover to another active PE device in the RG. Note that this works only in the case of dedicated interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have the path to the peer, even though the PE device is isolated from the MPLS core network.
PEデバイスは、コアネットワークから隔離されていることを検出すると、そのAC冗長メカニズムがすべてのアクティブなACのステータスをスタンバイに変更することを確認する必要があります。 AC冗長性アプリケーションは、RG内の別のアクティブなPEデバイスへのフェイルオーバーをトリガーするために、RGアプリケーションデータメッセージを送信する必要があります（SHOULD）。 PEデバイスがMPLSコアネットワークから分離されている場合でも、ICPはピアへのパスを保持するため、これは専用インターコネクト（セクション3.2.1および3.2.3）の場合にのみ機能することに注意してください。
This section defines the procedures of the ICCP STP application that are applicable for Ethernet ACs.
このセクションでは、イーサネットACに適用可能なICCP STPアプリケーションの手順を定義します。
When an RG is configured on a system that supports the ICCP STP application, such systems MUST send an RG Connect Message with an STP Connect TLV to each PE device that is a member of the RG. The sending PE device MUST set the A bit to 1 in that TLV if it has received a corresponding STP Connect TLV from its peer PE; otherwise, the sending PE device MUST set the A bit to 0. If a PE device receives an STP Connect TLV from its peer after sending its own TLV with the A bit set to 0, it MUST resend the TLV with the A bit set to 1. A system considers the ICCP STP application connection to be operational when it has both sent and received STP Connect TLVs with the A bit set to 1. When the ICCP STP application connection between a pair of PEs is operational, the two devices can start exchanging RG Application Data Messages for the ICCP STP application. This involves having each PE device advertise its STP configuration and operational state in an unsolicited manner. A PE device SHOULD follow the order below when advertising its STP state upon initial application connection setup:
ICCP STPアプリケーションをサポートするシステムでRGが構成されている場合、そのようなシステムは、RGのメンバーである各PEデバイスにSTP接続TLVを含むRG接続メッセージを送信する必要があります。送信側PEデバイスは、対応するSTP接続TLVをピアPEから受信した場合、そのTLVでAビットを1に設定する必要があります。それ以外の場合、送信側PEデバイスはAビットを0に設定する必要があります。PEデバイスが、Aビットを0に設定して独自のTLVを送信した後にピアからSTP接続TLVを受信した場合、Aビットを設定してTLVを再送信する必要があります。 1.システムは、Aビットが1に設定されたSTP接続TLVを送信および受信したときに、ICCP STPアプリケーション接続が動作していると見なします。PEのペア間のICCP STPアプリケーション接続が動作している場合、2つのデバイスを開始できます。 ICCP STPアプリケーションのRGアプリケーションデータメッセージを交換します。これには、各PEデバイスにSTP設定および動作状態を非請求方法でアドバタイズさせることが含まれます。 PEデバイスは、最初のアプリケーション接続のセットアップ時にSTP状態をアドバタイズするとき、以下の順序に従う必要があります。
- Advertise the STP System Config TLV - Advertise remaining Configuration TLVs - Advertise State TLVs
- STPシステム構成TLVをアドバタイズする-残りの構成TLVをアドバタイズする-状態TLVをアドバタイズする
The update of the information contained in the State TLVs depends on that in the Configuration TLVs. By sending the TLVs in the above order, the two peers may begin to update STP state as early as possible in the middle of exchanging these TLVs.
状態TLVに含まれる情報の更新は、構成TLVの更新に依存します。 TLVを上記の順序で送信することにより、2つのピアは、これらのTLVを交換する最中、できるだけ早くSTP状態の更新を開始できます。
A PE device MUST use a pair of STP Synchronization Data TLVs to delimit the entire set of TLVs that are being sent as part of this unsolicited advertisement.
PEデバイスは、STP同期データTLVのペアを使用して、この非送信請求アドバタイズの一部として送信されるTLVのセット全体を区切る必要があります。
If a system receives an RG Connect Message with an STP Connect TLV that has a differing Protocol Version, it MUST follow the procedures outlined in the Section 4.4.1 ("Application Versioning") of [RFC7275].
システムが、プロトコルバージョンが異なるSTP接続TLVを含むRG接続メッセージを受信する場合、[RFC7275]のセクション4.4.1（「アプリケーションのバージョン管理」）で概説されている手順に従う必要があります。
After the ICCP STP application connection has been established, every PE device MUST communicate its system-level configuration to its peers via the use of STP System Config TLV.
ICCP STPアプリケーション接続が確立された後、すべてのPEデバイスは、STP System Config TLVを使用してシステムレベルの構成をピアに通信する必要があります。
When the ICCP STP application is administratively disabled on the PE, or on the particular RG, the system MUST send an RG Disconnect Message containing STP Disconnect TLV.
ICCP STPアプリケーションがPEまたは特定のRGで管理上無効になっている場合、システムはSTP切断TLVを含むRG切断メッセージを送信する必要があります。
A system that supports ICCP STP application MUST synchronize the configuration with other RG members. This is achieved via the use of STP Configuration TLVs. The PEs in the RG MUST all agree on the common MAC address to be associated with the virtual root bridge. It is possible to achieve this via consistent configuration on member PEs. However, in order to protect against possible misconfigurations, a virtual root bridge identifier MUST be set to the MAC address advertised by the PE device with the numerically lowest BridgeIdentifier (i.e., the MAC address of the bridge) in the RG.
ICCP STPアプリケーションをサポートするシステムは、他のRGメンバーと構成を同期する必要があります。これは、STP構成TLVを使用して実現されます。 RG内のPEはすべて、仮想ルートブリッジに関連付けられる共通MACアドレスに同意する必要があります。これは、メンバーPEでの一貫した構成によって実現できます。ただし、誤設定の可能性から保護するために、仮想ルートブリッジ識別子は、RG内で数値的に最小のBridgeIdentifier（つまり、ブリッジのMACアドレス）を持つPEデバイスによってアドバタイズされるMACアドレスに設定する必要があります。
Furthermore, for a given ICCP STP application, an implementation MUST advertise the configuration prior to advertising its corresponding state. If a PE device receives any STP State TLV that it had not learned of before via an appropriate STP Configuration TLV, then the PE device MUST request synchronization of the configuration and state from its peer. If during such synchronization a PE device receives a State TLV that it has not learned before, then the PE device MUST send a NAK TLV for that particular TLV. The PE device MUST NOT request resynchronization in this case.
さらに、特定のICCP STPアプリケーションの場合、実装は対応する状態を通知する前に構成を通知する必要があります。 PEデバイスが適切なSTP構成TLVを介して以前に学習しなかったSTP状態TLVを受信した場合、PEデバイスはそのピアから構成と状態の同期を要求する必要があります。そのような同期中に、PEデバイスが以前に学習していない状態TLVを受信した場合、PEデバイスはその特定のTLVのNAK TLVを送信する必要があります。この場合、PEデバイスは再同期を要求してはなりません。
PEs within the RG need to synchronize their state for proper STP operation. This is achieved by having each system advertise its running state in STP State TLVs. Whenever any STP parameter either on the CE or PE side is changed, the system MUST transmit an updated TLV for the affected STP instances. Moreover, when the administrative or operational state changes, the system MUST transmit an updated State TLV to its peers.
RG内のPEは、適切なSTP動作のために状態を同期する必要があります。これは、各システムにSTP状態TLVの実行状態を通知させることで実現されます。 CE側またはPE側のいずれかのSTPパラメータが変更されるたびに、システムは影響を受けるSTPインスタンスの更新されたTLVを送信する必要があります。さらに、管理または運用状態が変化した場合、システムは更新された状態TLVをそのピアに送信する必要があります。
A PE device MAY request its peer to retransmit previously advertised state. This is useful in case the PE device is recovering from a soft failure and attempting to relearn state. To request such retransmissions, a PE device MUST send a set of one or more STP Synchronization Request TLVs.
PEデバイスは、以前にアドバタイズされた状態を再送信するようにピアに要求する場合があります。これは、PEデバイスがソフト障害から回復し、状態の再学習を試みている場合に役立ちます。そのような再送信を要求するには、PEデバイスは1つ以上のSTP同期要求TLVのセットを送信する必要があります。
A PE device MUST respond to a STP Synchronization Request TLV by sending the requested data in a set of one or more STP Configuration or State TLVs delimited by a pair of STP Synchronization Data TLVs.
PEデバイスは、STP同期データTLVのペアで区切られた1つ以上のSTP構成または状態TLVのセットで要求されたデータを送信することにより、STP同期要求TLVに応答する必要があります。
Note that the response may span across multiple RG Application Data Messages, for example, when MTU limits are exceeded; however, the above ordering MUST be retained across messages, and only a single pair of Synchronization Data TLVs MUST be used to delimit the response across all RG Application Data Messages.
たとえば、MTU制限を超えた場合など、応答が複数のRGアプリケーションデータメッセージにまたがることがあることに注意してください。ただし、上記の順序はメッセージ全体で保持される必要があり、すべてのRGアプリケーションデータメッセージ全体で応答を区切るために、同期データTLVの1つのペアのみを使用する必要があります。
A PE device MAY readvertise its STP state in an unsolicited manner. This is done by sending the appropriate State TLVs delimited by a pair of STP Synchronization Data TLVs and using a Request Number of 0.
PEデバイスは、自発的な方法でSTP状態を再アドバタイズしてもよい（MAY）。これは、STP同期データTLVのペアで区切られた適切な状態TLVを送信し、リクエスト番号0を使用して行われます。
While a PE device has sent out a synchronization request for a particular PE device, it SHOULD silently ignore all TLVs that are from that node, are received prior to the synchronization response, and carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other systems should continue to be processed normally.
PEデバイスが特定のPEデバイスの同期要求を送信している間、そのノードからのすべてのTLVを黙って無視し、同期応答の前に受信し、要求されている同じタイプの情報を伝達する必要があります（SHOULD）。これにより、最終的に同期応答によって上書きされる状態を更新する負担からシステムが節約されます。他のシステムに関連するTLVは引き続き正常に処理されることに注意してください。
If a PE device receives a synchronization request for an instance that doesn't exist or is not known to the PE, then it MUST trigger the unsolicited synchronization of all information by restarting the initialization.
PEデバイスが存在しない、またはPEに認識されていないインスタンスの同期要求を受信した場合、初期化を再開することにより、すべての情報の一方的な同期をトリガーする必要があります。
If during the synchronization operation a PE device receives an advertisement of a Node ID value that is different from the value previously advertised, then the PE device MUST purge all state data previously received from that peer prior to the last synchronization.
同期操作中に、PEデバイスが以前にアドバタイズされた値とは異なるノードID値のアドバタイズを受信した場合、PEデバイスは、最後の同期の前にそのピアから以前に受信したすべての状態データを削除する必要があります。
When a PE device that is active for the ICCP STP application encounters a core isolation fault [RFC7275], it SHOULD attempt to fail over to a peer PE device that hosts the same RG. The default failover procedure is to have the failed PE device bring down the link(s) towards the multihomed STP network. This will cause the STP network to reconverge and to use the other links that are connected to the other PE devices in the RG. Other procedures for triggering failover are possible and are outside the scope of this document.
ICCP STPアプリケーションに対してアクティブなPEデバイスがコア分離障害[RFC7275]に遭遇すると、同じRGをホストするピアPEデバイスへのフェイルオーバーを試行する必要があります（SHOULD）。デフォルトのフェイルオーバー手順では、障害が発生したPEデバイスがリンクをマルチホームSTPネットワークに向けてダウンさせます。これにより、STPネットワークが再収束し、RG内の他のPEデバイスに接続されている他のリンクを使用します。フェイルオーバーをトリガーする他の手順も可能であり、このドキュメントの範囲外です。
If the isolated PE device is the one that has the numerically lowest BridgeIdentifier, PEs in the RG MUST synchronize STP Configuration and State TLVs and determine a new virtual root bridge as specified in Section 4.2.2.
分離されたPEデバイスが数値的に最小のBridgeIdentifierを持つデバイスである場合、RG内のPEはSTP構成と状態TLVを同期し、セクション4.2.2で指定されている新しい仮想ルートブリッジを決定する必要があります。
Upon recovery from a previous fault, a PE device SHOULD NOT reclaim the role of the virtual root for the STP network even if it has the numerically lowest BridgeIdentifier among the RG. This minimizes traffic disruption.
以前の障害から回復すると、PEデバイスは、RGの中でBridgeIdentifierが数値的に最小であっても、STPネットワークの仮想ルートの役割を取り戻すべきではありません（SHOULD NOT）。これにより、トラフィックの中断が最小限に抑えられます。
Whenever the virtual root bridge changes, the STP Topology Changed Instances TLV lists the instances that are affected by the change. These instances MUST undergo a STP reconvergence procedure when this TLV is received as defined in Section 3.4.1.
仮想ルートブリッジが変更されるたびに、STPトポロジ変更インスタンスTLVは、変更の影響を受けるインスタンスをリストします。これらのインスタンスは、セクション3.4.1で定義されているように、このTLVが受信されたときにSTP再収束手順を実行する必要があります。
This document specifies an application running on the channel provided by ICCP [RFC7275]. The security considerations on ICCP apply in this document as well.
このドキュメントは、ICCP [RFC7275]によって提供されるチャネルで実行されるアプリケーションを指定します。 ICCPのセキュリティに関する考慮事項は、このドキュメントにも適用されます。
For the ICCP STP application, an attack on a channel (running in the provider's network) can break not only the ability to deliver traffic across the provider's network, but also the ability to route traffic within the customer's network. That is, a careful attack on a channel (such as the DoS attacks as described in [RFC7275]) can break STP within the customer network. Implementations need to provide mechanisms to mitigate these types of attacks. For example, the port between the PE device and the malicious CE device may be blocked.
ICCP STPアプリケーションの場合、（プロバイダーのネットワークで実行されている）チャネルに対する攻撃は、プロバイダーのネットワーク全体にトラフィックを配信する機能だけでなく、顧客のネットワーク内でトラフィックをルーティングする機能も破壊する可能性があります。つまり、チャネルへの注意深い攻撃（[RFC7275]で説明されているDoS攻撃など）は、顧客ネットワーク内のSTPを破壊する可能性があります。実装では、これらのタイプの攻撃を軽減するメカニズムを提供する必要があります。たとえば、PEデバイスと悪意のあるCEデバイスの間のポートがブロックされている可能性があります。
The IANA maintains a top-level registry called "Pseudowire Name Spaces (PWE3)". It has a subregistry called "ICC RG Parameter Types".
IANAは、「疑似配線名前空間（PWE3）」と呼ばれるトップレベルのレジストリを維持しています。 「ICC RGパラメータタイプ」と呼ばれるサブレジストリがあります。
IANA has made 13 allocations from this registry as shown below. IANA has allocated the codepoints from the range marked for assignment by IETF Review (0x2000-0x2FFF) [RFC5226]. Each assignment references this document.
IANAは、以下に示すように、このレジストリから13の割り当てを行いました。 IANAは、IETFレビュー（0x2000-0x2FFF）[RFC5226]によって割り当て用にマークされた範囲からコードポイントを割り当てました。各割り当てはこのドキュメントを参照します。
Parameter Type Description
-------------- ---------------------------------
0x2000 STP Connect TLV
0x2001 STP Disconnect TLV
0x2002 STP System Config TLV
0x2003 STP Region Name TLV
0x2004 STP Revision Level TLV
0x2005 STP Instance Priority TLV
0x2006 STP Configuration Digest TLV
0x2007 STP Topology Changed Instances TLV
0x2008 STP CIST Root Time TLV
0x2009 STP MSTI Root Time TLV
0x200A STP Synchronization Request TLV
0x200B STP Synchronization Data TLV
0x200C STP Disconnect Cause TLV
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<http ：//www.rfc-editor.org/info/rfc4762>。
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, DOI 10.17487/RFC7275, June 2014, <http://www.rfc-editor.org/info/rfc7275>.
[RFC7275] Martini、L.、Salam、S.、Sajassi、A.、Bocci、M.、Matsushima、S。、およびT. Nadeau、「レイヤー2仮想プライベートネットワーク（L2VPN）プロバイダーエッジのシャーシ間通信プロトコル」 （PE）Redundancy」、RFC 7275、DOI 10.17487 / RFC7275、2014年6月、<http://www.rfc-editor.org/info/rfc7275>。
[802.1q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014.
[802.1q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014。
[802.1d1998] IEEE, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specifications -- Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D-1998, DOI 10.1109/IEEESTD.1998.95619, 1998.
[802.1d1998] IEEE, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specifications -- Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D-1998, DOI 10.1109/IEEESTD.1998.95619, 1998.
[802.1d2004] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, DOI 10.1109/ieeestd.2004.94569, 2004.
[802.1d2004] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges」、IEEE Std 802.1D-2004、DOI 10.1109 / ieeestd.2004.94569、2004。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
Acknowledgements
謝辞
The authors would like to thank the comments and suggestions from Ignas Bagdonas, Adrian Farrel, Andrew G. Malis, Gregory Mirsky, and Alexander Vainshtein.
著者は、Ignas Bagdonas、Adrian Farrel、Andrew G. Malis、Gregory Mirsky、およびAlexander Vainshteinからのコメントと提案に感謝します。
Authors' Addresses
著者のアドレス
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 China
min鬼Zhang hu Aはテクノロジーno。156 be i青RDです。
Email: zhangmingui@huawei.com
Huafeng Wen Huawei Technologies 101 Software Avenue, Nanjing 210012 China
hu A逢wen hu Aはテクノロジー101ソフトウェアアベニュー、南京210012中国
Email: wenhuafeng@huawei.com
Jie Hu China Telecom Beijing Information Science & Technology Innovation Park Beiqijia Town Changping District, Beijing 102209 China
J IE胡中国電信北京情報科学技術革新公園B EI期間価格町北京昌平区102209中国
Email: hujie@ctbri.com.cn