[要約] RFC 7455は、TRILL（Transparent Interconnection of Lots of Links）の障害管理に関するものであり、TRILLネットワークの障害検出、診断、回復のための手法を提供しています。目的は、TRILLネットワークの信頼性と可用性を向上させることです。
Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 7455 N. Finn
Updates: 6325 S. Salam
Category: Standards Track D. Kumar
ISSN: 2070-1721 Cisco
D. Eastlake 3rd
S. Aldrin
Y. Li
Huawei
March 2015
Transparent Interconnection of Lots of Links (TRILL): Fault Management
多数のリンクの透過的な相互接続（TRILL）：障害管理
Abstract
概要
This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.
このドキュメントでは、リンクの透過的な相互接続（TRILL）操作、管理、および保守（OAM）障害管理について説明します。このドキュメントのメソッドは、IEEE 802.1で定義されたCFM（Connectivity Fault Management）フレームワークに従い、可能な場合はOAMツールを再利用します。追加のメッセージとTLVは、TRILL固有のアプリケーション、またはIEEE 802.1で定義されているCFM以外の異なる情報セットが必要な場合のために定義されています。このドキュメントはRFC 6325を更新します。
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/rfc7455.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7455で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 ....................................................5
2. Conventions Used in This Document ...............................5
3. General Format of TRILL OAM Packets .............................6
3.1. Identification of TRILL OAM Frames .........................8
3.2. Use of TRILL OAM Alert Flag ................................8
3.2.1. Handling of TRILL Frames with the "A" Flag ..........9
3.3. OAM Capability Announcement ................................9
3.4. Identification of the OAM Message .........................10
4. TRILL OAM Layering vs. IEEE Layering ...........................11
4.1. Processing at the ISS Layer ...............................12
4.1.1. Receive Processing .................................12
4.1.2. Transmit Processing ................................12
4.2. End-Station VLAN and Priority Processing ..................12
4.2.1. Receive Processing .................................12
4.2.2. Transmit Processing ................................12
4.3. TRILL Encapsulation and Decapsulation Layer ...............12
4.3.1. Receive Processing for Unicast Packets .............12
4.3.2. Transmit Processing for Unicast Packets ............13
4.3.3. Receive Processing for Multicast Packets ...........14
4.3.4. Transmit Processing of Multicast Packets ...........15
4.4. TRILL OAM Layer Processing ................................16
5. Maintenance Associations (MAs) in TRILL ........................17
6. MEP Addressing .................................................18
6.1. Use of MIP in TRILL .......................................21
7. Continuity Check Message (CCM) .................................22
8. TRILL OAM Message Channel ......................................25
8.1. TRILL OAM Message Header ..................................25
8.2. TRILL-Specific OAM OpCodes ................................26
8.3. Format of TRILL OAM TLV ...................................26
8.4. TRILL OAM TLVs ............................................27
8.4.1. Common TLVs between CFM and TRILL ..................27
8.4.2. TRILL OAM-Specific TLVs ............................27
8.4.3. TRILL OAM Application Identifier TLV ...............28
8.4.4. Out-of-Band Reply Address TLV ......................30
8.4.5. Diagnostic Label TLV ...............................31
8.4.6. Original Data Payload TLV ..........................32
8.4.7. RBridge Scope TLV ..................................32
8.4.8. Previous RBridge Nickname TLV ......................33
8.4.9. Next-Hop RBridge List TLV ..........................34
8.4.10. Multicast Receiver Port Count TLV .................34
8.4.11. Flow Identifier TLV ...............................35
8.4.12. Reflector Entropy TLV .............................36
8.4.13. Authentication TLV ................................37
9. Loopback Message ...............................................38
9.1. Loopback Message Format ...................................38
9.2. Theory of Operation .......................................39
9.2.1. Actions by Originator RBridge ......................39
9.2.2. Intermediate RBridge ...............................39
9.2.3. Destination RBridge ................................40
10. Path Trace Message ............................................40
10.1. Theory of Operation ......................................41
10.1.1. Actions by Originator RBridge .....................41
10.1.2. Intermediate RBridge ..............................42
10.1.3. Destination RBridge ...............................43
11. Multi-Destination Tree Verification Message (MTVM) ............43
11.1. MTVM Format ..............................................44
11.2. Theory of Operation ......................................44
11.2.1. Actions by Originator RBridge .....................44
11.2.2. Receiving RBridge .................................45
11.2.3. In-Scope RBridges .................................45
12. Application of Continuity Check Message (CCM) in TRILL ........46
12.1. CCM Error Notification ...................................47
12.2. Theory of Operation ......................................48
12.2.1. Actions by Originator RBridge .....................48
12.2.2. Intermediate RBridge ..............................49
12.2.3. Destination RBridge ...............................49
13. Fragmented Reply ..............................................50
14. Security Considerations .......................................50
15. IANA Considerations ...........................................52
15.1. OAM Capability Flags .....................................52
15.2. CFM Code Points ..........................................52
15.3. MAC Addresses ............................................53
15.4. Return Codes and Sub-codes ...............................53
15.5. TRILL Nickname Address Family ............................54
16. References ....................................................54
16.1. Normative References .....................................54
16.2. Informative References ...................................55
Appendix A. Backwards Compatibility ...............................57
A.1. Maintenance Point (MEP/MIP) Model ........................57
A.2. Data-Plane Encoding and Frame Identification .............57
Appendix B. Base Mode for TRILL OAM ...............................59
Appendix C. MAC Addresses Request .................................61
Acknowledgments ...................................................62
Authors' Addresses ................................................62
The general structure of TRILL OAM messages is presented in [RFC7174]. TRILL OAM messages consist of six parts: Link Header, TRILL Header, Flow Entropy, OAM Ethertype, OAM Message Channel, and Link Trailer.
TRILL OAMメッセージの一般的な構造は、[RFC7174]に示されています。 TRILL OAMメッセージは、リンクヘッダー、TRILLヘッダー、フローエントロピー、OAM Ethertype、OAMメッセージチャネル、リンクトレーラーの6つの部分で構成されています。
The OAM Message Channel carries various control information and OAM-related data between TRILL switches, also known as RBridges or Routing Bridges.
OAMメッセージチャネルは、RBridgeまたはルーティングブリッジとも呼ばれるTRILLスイッチ間で、さまざまな制御情報とOAM関連のデータを伝送します。
A common OAM Message Channel representation can be shared between different technologies. This consistency between different OAM technologies promotes nested fault monitoring and isolation between technologies that share the same OAM framework.
共通のOAMメッセージチャネル表現は、異なるテクノロジー間で共有できます。異なるOAMテクノロジー間のこの一貫性により、ネストされた障害の監視と、同じOAMフレームワークを共有するテクノロジー間の分離が促進されます。
The TRILL OAM Message Channel is formatted as specified in IEEE Connectivity Fault Management (CFM) [8021Q].
TRILL OAMメッセージチャネルは、IEEE接続障害管理（CFM）[8021Q]で指定された形式になっています。
The ITU-T Y.1731 [Y1731] standard utilizes the same messaging format as [8021Q] OAM messages where applicable. This document takes a similar stance and reuses [8021Q] in TRILL OAM. It is assumed that readers are familiar with [8021Q] and [Y1731]. Readers who are not familiar with these documents are encouraged to review them.
ITU-T Y.1731 [Y1731]標準は、該当する場合、[8021Q] OAMメッセージと同じメッセージング形式を利用します。このドキュメントは同様のスタンスをとり、TRILL OAMで[8021Q]を再利用します。読者は[8021Q]と[Y1731]に精通していることを前提としています。これらのドキュメントに精通していない読者は、レビューすることをお勧めします。
This document specifies TRILL OAM fault management. It updates [RFC6325] as specified in Section 3.1. TRILL performance monitoring is specified in [RFC7456].
このドキュメントでは、TRILL OAM障害管理について説明します。セクション3.1で指定されているように[RFC6325]を更新します。 TRILLパフォーマンス監視は[RFC7456]で指定されています。
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]で説明されているように解釈されます。
Capitalized IANA Considerations terms such as "Standards Action" are to be interpreted as described in [RFC5226].
「標準アクション」などの大文字のIANA考慮事項用語は、[RFC5226]で説明されているように解釈されます。
Acronyms used in the document include the following:
この文書で使用されている頭字語には次のものがあります。
CCM - Continuity Check Message [8021Q]
CCM-導通チェックメッセージ[8021Q]
DA - Destination Address
DA-宛先アドレス
ECMP - Equal-Cost Multipath
ECMP-等コストマルチパス
FGL - Fine-Grained Label ISS - Internal Sub-Layer Service [8021Q]
FGL-細粒度ラベルISS-内部サブレイヤーサービス[8021Q]
LBM - Loopback Message [8021Q]
LBM-ループバックメッセージ[8021Q]
LBR - Loopback Reply [8021Q]
LBR-ループバック応答[8021Q]
MA - Maintenance Association [8021Q] [RFC7174]
MA-メンテナンスアソシエーション[8021Q] [RFC7174]
MAC - Media Access Control (MAC)
MAC-メディアアクセスコントロール（MAC）
MD - Maintenance Domain [8021Q]
MD-メンテナンスドメイン[8021Q]
MEP - Maintenance End Point [RFC7174] [8021Q]
MEP-メンテナンスエンドポイント[RFC7174] [8021Q]
MIP - Maintenance Intermediate Point [RFC7174] [8021Q]
MIP-メンテナンス中間ポイント[RFC7174] [8021Q]
MP - Maintenance Point [RFC7174]
MP-メンテナンスポイント[RFC7174]
MTVM - Multi-destination Tree Verification Message
MTVM-複数宛先ツリー検証メッセージ
MTVR - Multi-destination Tree Verification Reply
MTVR-複数宛先ツリー検証応答
OAM - Operations, Administration, and Maintenance [RFC6291]
OAM-運用、管理、およびメンテナンス[RFC6291]
PRI - Priority of Ethernet Frames [8021Q]
PRI-イーサネットフレームの優先度[8021Q]
PTM - Path Trace Message
PTM-パストレースメッセージ
PTR - Path Trace Reply
PTR-パストレース応答
SA - Source Address
SA-送信元アドレス
SAP - Service Access Point [8021Q]
SAP-サービスアクセスポイント[8021Q]
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-多くのリンクの透過的な相互接続[RFC6325]
The TRILL forwarding paradigm allows an implementation to select a path from a set of equal-cost paths to forward a unicast TRILL Data packet. For multi-destination TRILL Data packets, a distribution tree is chosen by the TRILL switch that ingresses or creates the packet. Selection of the path of choice is implementation dependent at each hop for unicast and at the ingress for multi-destination. However, it is a common practice to utilize Layer 2 through Layer 4 information in the frame payload for path selection.
TRILL転送パラダイムにより、実装は、等コストパスのセットからパスを選択して、ユニキャストTRILLデータパケットを転送できます。複数宛先のTRILLデータパケットの場合、パケットを入力または作成するTRILLスイッチによって配布ツリーが選択されます。選択するパスの選択は、ユニキャストの各ホップおよびマルチ宛先の入口での実装に依存します。ただし、パスの選択には、フレームペイロードでレイヤ2〜4の情報を利用するのが一般的です。
For accurate monitoring and/or diagnostics, OAM messages are required to follow the same path as corresponding data packets. [RFC7174] presents the high-level format of OAM messages. The details of the TRILL OAM frame format are defined in this document.
正確な監視および/または診断のために、OAMメッセージは対応するデータパケットと同じパスをたどる必要があります。 [RFC7174]は、OAMメッセージの高レベルの形式を示します。 TRILL OAMフレーム形式の詳細は、このドキュメントで定義されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 6 or more bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 96 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Trailer | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of TRILL OAM Messages
図1：TRILL OAMメッセージのフォーマット
o Link Header: Media-dependent header. For Ethernet, this includes the Destination MAC, Source MAC, VLAN (optional), and Ethertype fields.
o リンクヘッダー：メディア依存ヘッダー。イーサネットの場合、これには宛先MAC、送信元MAC、VLAN（オプション）、およびEthertypeフィールドが含まれます。
o TRILL Header: Fixed size of 6 bytes when the Extended Header is not included [RFC6325].
o TRILLヘッダー：拡張ヘッダーが含まれない場合の6バイトの固定サイズ[RFC6325]。
o Flow Entropy: A 96-byte, fixed-size field. The rightmost bits of the field MUST be padded with zeros, up to 96 bytes, when the flow-entropy information is less than 96 bytes. Flow Entropy enables emulation of the forwarding behavior of the desired data packets. The Flow Entropy field starts with the Inner.MacDA. The offset of the Inner.MacDA depends on whether extensions are included or not as specified in [RFC7179] and [RFC6325]. Such extensions are not commonly supported in current TRILL implementations.
o フローエントロピー：96バイトの固定サイズフィールド。フローエントロピー情報が96バイト未満の場合は、フィールドの右端のビットに最大96バイトのゼロを埋め込む必要があります。フローエントロピーは、目的のデータパケットの転送動作のエミュレーションを可能にします。 Flow Entropyフィールドは、Inner.MacDAで始まります。 Inner.MacDAのオフセットは、[RFC7179]と[RFC6325]で指定されているように、拡張子が含まれているかどうかによって異なります。このような拡張は、現在のTRILL実装では一般的にサポートされていません。
o OAM Ethertype: A 16-bit Ethertype that identifies the OAM Message Channel that follows. This document specifies using the Ethertype 0x8902 allocated for CFM [8021Q].
o OAM Ethertype：続くOAMメッセージチャネルを識別する16ビットEthertype。このドキュメントでは、CFM [8021Q]に割り当てられたEthertype 0x8902の使用を指定しています。
o OAM Message Channel: A variable-size section that carries OAM-related information. The message format is as specified in [8021Q].
o OAMメッセージチャネル：OAM関連の情報を運ぶ可変サイズのセクション。メッセージフォーマットは[8021Q]で指定されたとおりです。
o Link Trailer: Media-dependent trailer. For Ethernet, this is the FCS (Frame Check Sequence).
o Link Trailer：メディア依存のトレーラー。イーサネットの場合、これはFCS（フレームチェックシーケンス）です。
TRILL, as originally specified in [RFC6325], did not have a specific flag or method to identify OAM frames. This document updates [RFC6325] to include specific methods to identify TRILL OAM frames. Section 3.2 explains the details of the method.
[RFC6325]で最初に指定されたTRILLには、OAMフレームを識別するための特定のフラグまたは方法がありませんでした。このドキュメントは、[RFC6325]を更新して、TRILL OAMフレームを識別する特定の方法を含めます。セクション3.2では、メソッドの詳細について説明します。
The TRILL Header, as defined in [RFC6325], has two reserved bits. This document specifies use of the reserved bit next to the Version field in the TRILL Header as the Alert flag. The Alert flag will be denoted by "A". RBridges MUST NOT use the "A" flag for forwarding decisions such as the selection of which ECMP path or multi-destination tree to select.
[RFC6325]で定義されているTRILLヘッダーには、2つの予約ビットがあります。このドキュメントでは、TRILLヘッダーのVersionフィールドの横にある予約ビットをアラートフラグとして使用することを指定しています。警告フラグは「A」で示されます。 RBridgeは、選択するECMPパスまたはマルチ宛先ツリーの選択などの転送決定に「A」フラグを使用してはなりません（MUST NOT）。
Implementations that comply with this document MUST utilize the "A" flag and CFM Ethertype to identify TRILL OAM frames.
このドキュメントに準拠する実装では、「A」フラグとCFM Ethertypeを使用してTRILL OAMフレームを識別する必要があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|R|M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: TRILL Header with the "A" Flag
図2：「A」フラグの付いたTRILLヘッダー
o A (1 bit): Indicates this is a possible OAM frame and is subject to specific handling as specified in this document.
o A（1ビット）：これが可能なOAMフレームであり、このドキュメントで指定されている特定の処理の対象であることを示します。
All other TRILL Header fields carry the same meaning as defined in [RFC6325].
他のすべてのTRILLヘッダーフィールドは、[RFC6325]で定義されているのと同じ意味を持ちます。
The value "1" in the "A" flag indicates TRILL frames that may qualify as OAM frames. Implementations are further REQUIRED to validate such frames by comparing the value at the OAM Ethertype (Figure 1) location with the CFM Ethertype "0x8902" [8021Q]. If the value matches, such frames are identified as TRILL OAM frames and SHOULD be processed as discussed in Section 4.
「A」フラグの値「1」は、OAMフレームとみなされるTRILLフレームを示します。 OAM Ethertype（図1）の場所の値をCFM Ethertype "0x8902" [8021Q]と比較して、そのようなフレームを検証するための実装がさらに必要です。値が一致する場合、そのようなフレームはTRILL OAMフレームとして識別され、セクション4で説明されているように処理する必要があります（SHOULD）。
Frames with the "A" flag set that do not contain a CFM Ethertype are not considered OAM frames. Such frames MUST be silently discarded.
CFM Ethertypeを含まない「A」フラグが設定されたフレームは、OAMフレームとは見なされません。そのようなフレームは静かに捨てられなければなりません。
OAM-capable RBridges MUST NOT generate OAM frames to an RBridge that is not OAM capable.
OAM対応のRBridgeは、OAM対応でないRBridgeへのOAMフレームを生成してはならない（MUST NOT）。
Intermediate RBridges that are not OAM capable (i.e., do not understand the "A" flag) follow the process defined in Section 3.3 of [RFC6325] and forward OAM frames with the "A" flag unaltered.
OAMに対応していない（つまり、「A」フラグを理解していない）中間RBridgeは、[RFC6325]のセクション3.3で定義されているプロセスに従い、「A」フラグを変更せずにOAMフレームを転送します。
Any given RBridge can be (1) OAM incapable, (2) OAM capable with new extensions, or (3) OAM capable with the backwards-compatibility method. The OAM request originator, prior to origination of the request, is required to identify the OAM capability of the target and generate the appropriate OAM message.
特定のRBridgeは、（1）OAM非対応、（2）新しい拡張機能を備えたOAM、または（3）下位互換性方式を備えたOAMにすることができます。 OAM要求の発信者は、要求の発信前に、ターゲットのOAM機能を識別して適切なOAMメッセージを生成するために必要です。
The capability flags defined in the TRILL Version sub-TLV (TRILL-VER) [RFC7176] will be utilized for announcing OAM capabilities. The following OAM-related capability flags are defined:
TRILLバージョンサブTLV（TRILL-VER）[RFC7176]で定義された機能フラグは、OAM機能のアナウンスに使用されます。以下のOAM関連の機能フラグが定義されています。
O - OAM capable
O-OAM対応
B - Backwards-compatible OAM
B-下位互換性のあるOAM
A capability announcement with the "O" flag set to 1 and the "B" flag set to 1 indicates that the originating RBridge is OAM capable but utilizes the backwards-compatibility method defined in Appendix A. A capability announcement with the "O" flag set to 1 and the "B" flag set to 0 indicates that the originating RBridge is OAM capable and utilizes the method specified in Section 3.2.
「O」フラグが1に設定され、「B」フラグが1に設定された機能アナウンスは、元のRBridgeがOAM対応であることを示しますが、付録Aで定義されている後方互換性メソッドを利用します。「O」フラグ付きの機能アナウンス1に設定し、「B」フラグを0に設定すると、元のRBridgeがOAM対応であり、セクション3.2で指定された方法を利用することを示します。
When the "O" flag is set to 0, the announcing implementation is considered not capable of OAM, and the "B" flag is ignored.
「O」フラグが0に設定されている場合、アナウンスの実装はOAMに対応していないと見なされ、「B」フラグは無視されます。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
|A|F|O|B|Other Capabilities and Header Flags| (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
Figure 3: TRILL-VER Sub-TLV [RFC7176] with "O" and "B" Flags
図3：「O」および「B」フラグを使用したTRILL-VER Sub-TLV [RFC7176]
In Figure 3, "A" is the Affinity sub-TLV support flag as indicated in [RFC7176], and "F" is the FGL-safe flag as indicated in [RFC7172] and [RFC7176]. The "O" and "B" flags are located after the "F" flag in the Capability and Header Flags field of the TRILL-VER sub-TLV, as depicted in Figure 3 above. Usage of the "O" and "B" flags is discussed above.
図3で、「A」は[RFC7176]に示されているアフィニティサブTLVサポートフラグであり、「F」は[RFC7172]および[RFC7176]に示されているFGLセーフフラグです。上記の図3に示すように、「O」および「B」フラグは、TRILL-VERサブTLVの「機能とヘッダーフラグ」フィールドの「F」フラグの後にあります。 「O」および「B」フラグの使用法については、上記で説明しています。
Absence of the TRILL-VER sub-TLV means the announcing RBridge is not OAM capable.
TRILL-VERサブTLVがないということは、発表されたRBridgeがOAMに対応していないことを意味します。
The ingress RBridge nickname allows recipients to identify the origin of the message in most cases. However, when an out-of-band reply is generated, the responding RBridge nickname is not easy to identify.
入力RBridgeニックネームを使用すると、ほとんどの場合、受信者はメッセージの発信元を識別できます。ただし、帯域外応答が生成された場合、応答するRBridgeニックネームは簡単に識別できません。
The [8021Q] Sender ID TLV (1) provides methods to identify the device by including the Chassis ID. The Chassis ID allows different addressing formats such as IANA Address Family enumerations. IANA has allocated Address Family Number 16396 for TRILL nickname. In TRILL OAM, the Chassis ID sub-type of the Sender ID TLV is set to 16396, and the Chassis ID field contains the corresponding TRILL nickname.
[8021Q] Sender ID TLV（1）は、シャーシIDを含めることでデバイスを識別する方法を提供します。シャーシIDでは、IANAアドレスファミリの列挙など、さまざまなアドレス形式を使用できます。 IANAはTRILLニックネームにアドレスファミリー番号16396を割り当てました。 TRILL OAMでは、Sender ID TLVのシャーシIDサブタイプは16396に設定され、シャーシIDフィールドには対応するTRILLニックネームが含まれています。
When the Sender ID TLV is present and the Chassis ID sub-type is set to 16396, the sender RBridge TRILL nickname SHOULD be derived from the nickname embedded in the Chassis ID. Otherwise, the sender RBridge TRILL nickname SHOULD be derived from the ingress RBridge nickname.
送信者ID TLVが存在し、シャーシIDサブタイプが16396に設定されている場合、送信者RBridge TRILLニックネームは、シャーシIDに埋め込まれたニックネームから派生する必要があります（SHOULD）。それ以外の場合、送信者のRBridge TRILLニックネームは、入力RBridgeニックネームから派生する必要があります（SHOULD）。
This section presents the placement of the TRILL OAM shim within the IEEE 802.1 layers. The transmit and receive processing are explained.
このセクションでは、IEEE 802.1レイヤー内でのTRILL OAMシムの配置について説明します。送受信処理について説明します。
+-+-+-+-+-+-+-+-+-+-+
| RBridge Layer |
| Processing |
+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+
| TRILL OAM | UP MEP
| Layer | MIP
+-+-+-+-+-+-+ Down MEP
|
|
+-+-+-+-+-+-+
(3)--------> | TRILL |
| Encap/Decap
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(2)--------> |End-station|
| VLAN & Priority Processing
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(1)--------> |ISS |
|Processing |
+-+-+-+-+-+-+
|
|
|
Figure 4: Placement of TRILL MP within IEEE 802.1
図4：IEEE 802.1内でのTRILL MPの配置
[RFC6325], Section 4.6 as updated by [RFC7180] provides a detailed explanation of frame processing. Please refer to those documents for additional details and for processing scenarios not covered herein.
[RFC6325]、[RFC7180]によって更新されたセクション4.6は、フレーム処理の詳細な説明を提供します。詳細およびここでカバーされていない処理シナリオについては、これらのドキュメントを参照してください。
Sections 4.1 and 4.2 apply to links using a broadcast LAN technology such as Ethernet.
セクション4.1および4.2は、イーサネットなどのブロードキャストLANテクノロジーを使用するリンクに適用されます。
On links using an inherently point-to-point technology, such as PPP [RFC6361], there is no Outer.MacDA, Outer.MacSA, or Outer.VLAN because these are part of the Link Header for Ethernet. Point-to-point links typically have Link Headers without these fields.
PPP [RFC6361]などの本質的にポイントツーポイントの技術を使用するリンクでは、これらはイーサネットのリンクヘッダーの一部であるため、Outer.MacDA、Outer.MacSA、またはOuter.VLANはありません。ポイントツーポイントリンクには通常、これらのフィールドのないリンクヘッダーがあります。
The ISS layer receives an indication from the port. It extracts DA and SA, and it marks the remainder of the payload as M1. The ISS layer passes on (DA, SA, M1) as an indication to the higher layer.
ISSレイヤーは、ポートから指示を受け取ります。 DAとSAを抽出し、ペイロードの残りをM1としてマークします。 ISSレイヤーは、上位レイヤーへの指示として（DA、SA、M1）を渡します。
For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. M1 is the remainder of the packet.
TRILLイーサネットフレームの場合、これはOuter.MacDAおよびOuter.MacSAです。 M1はパケットの残りの部分です。
The ISS layer receives an indication from the higher layer that contains (DA, SA, M1). It constructs an Ethernet frame and passes down to the port.
ISSレイヤーは、（DA、SA、M1）を含む上位レイヤーから指示を受け取ります。イーサネットフレームを構築し、ポートに渡します。
Receive (DA, SA, M1) indication from the ISS layer. Extract the VLAN ID and priority from the M1 part of the received indication (or derive them from the port defaults or other default parameters) and construct (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 maps to M1 in the received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL Encapsulation/Decapsulation layer.
ISSレイヤーから（DA、SA、M1）指示を受信します。受信したインジケーションのM1部分からVLAN IDと優先度を抽出し（またはポートのデフォルトまたは他のデフォルトパラメータからそれらを導き出し）、構成します（DA、SA、VLAN、PRI、M2）。 VLAN + PRI + M2は、受信したインジケーションでM1にマッピングされます。 （DA、SA、VLAN、PRI、M2）をTRILLカプセル化/カプセル化解除レイヤーに渡します。
Receive (DA, SA, VLAN, PRI, M2) indication from the TRILL Encapsulation/Decapsulation layer. Merge VLAN, PRI, M2 to form M1. Pass down (DA, SA, M1) to the ISS layer.
TRILLカプセル化/カプセル化解除レイヤーからの受信（DA、SA、VLAN、PRI、M2）の表示。 VLAN、PRI、M2をマージしてM1を形成します。 （DA、SA、M1）をISSレイヤーに渡します。
o Receive indication (DA, SA, VLAN, PRI, M2) from the End-Station VLAN and Priority Processing layer.
o 端末のVLANおよび優先度処理レイヤーから指示（DA、SA、VLAN、PRI、M2）を受信します。
o If the DA matches the port Local DA and the frame is of TRILL Ethertype:
o DAがポートローカルDAと一致し、フレームがTRILL Ethertypeである場合：
- Discard DA, SA, VLAN, and PRI. From M2, derive (TRILL-HDR, iDA, iSA, i-VL, M3).
- DA、SA、VLAN、およびPRIを破棄します。 M2から派生（TRILL-HDR、iDA、iSA、i-VL、M3）。
- If TRILL nickname is Local and TRILL Header Alert flag is set:
- TRILLニックネームがローカルで、TRILLヘッダーアラートフラグが設定されている場合：
* Pass on to OAM processing.
* OAM処理に渡します。
- Else, pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to the RBridge layer.
- または、RBridgeレイヤーに（TRILL-HDR、iDA、iSA、i-VL、M3）を渡します。
o If the DA matches the port Local DA and the Ethertype is RBridge-Channel [RFC7178]:
o DAがポートローカルDAと一致し、EthertypeがRBridge-Channel [RFC7178]である場合：
- Process as a possible unicast native RBridge Channel packet.
- 可能なユニキャストネイティブRBridgeチャネルパケットとして処理します。
o If the DA matches the port Local DA and the Ethertype is neither TRILL nor RBridge-Channel:
o DAがポートローカルDAと一致し、EthertypeがTRILLでもRBridge-Channelでもない場合：
- Discard packet.
- パケットを破棄します。
o If the DA does not match, the port is Appointed Forwarder for VLAN, and the Ethertype is not TRILL or RBridge-Channel:
o DAが一致しない場合、ポートはVLANのAppointed Forwarderであり、EthertypeはTRILLまたはRBridge-Channelではありません。
- Insert TRILL-HDR and send (TRILL-HDR, iDA, iSA,i-VL, M3) indication to the RBridge layer (this is the TRILL Ingress Function).
- TRILL-HDRを挿入し、（TRILL-HDR、iDA、iSA、i-VL、M3）表示をRBridgeレイヤーに送信します（これはTRILL Ingress Functionです）。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer.
o RBridgeレイヤーから指示（TRILL-HDR、iDA、iSA、iVL、M3）を受け取ります。
o If the egress TRILL nickname is local:
o 出力TRILLニックネームがローカルの場合：
- If the port is Appointed Forwarder for iVL, the port is not configured as a trunk or point-to-point (P2P) port, the TRILL Alert flag is set, and the OAM Ethertype is present, then:
- ポートがAppointed Forwarder for iVLである場合、ポートはトランクポートまたはポイントツーポイント（P2P）ポートとして構成されておらず、TRILL Alertフラグが設定されており、OAM Ethertypeが存在する場合、次のようになります。
* Strip TRILL-HDR and construct (DA, SA, VLAN, M2) (this is the TRILL Egress Function).
* TRILL-HDRを取り除き、構築します（DA、SA、VLAN、M2）（これはTRILL出力関数です）。
- Else:
- そうしないと：
* Discard packet.
* パケットを破棄します。
o If the egress TRILL nickname is not local:
o 出力TRILLニックネームがローカルでない場合：
- Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype, and construct (DA, SA, VLAN, M2) where M2 is (TRILL-HDR, iDA, iSA, iVL, M).
- Outer.MacDA、Outer.MacSA、Outer.VLAN、およびTRILL Ethertypeを挿入し、（DA、SA、VLAN、M2）を構築します。ここで、M2は（TRILL-HDR、iDA、iSA、iVL、M）です。
o Forward (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 端末（DA、SA、V、M2）を端末VLANおよび優先処理レイヤーに転送します。
o Receive (DA, SA, V, M2) from the End-Station VLAN and Priority Processing layer.
o エンドステーションVLANおよび優先度処理レイヤーから受信（DA、SA、V、M2）。
o If the DA is All-RBridges and the Ethertype is TRILL:
o DAがAll-RBridgesで、EthertypeがTRILLの場合：
- Strip DA, SA, and V. From M2, extract (TRILL-HDR, iDA, iSA, iVL, and M3).
- DA、SA、Vを削除します。M2から抽出します（TRILL-HDR、iDA、iSA、iVL、およびM3）。
- If the TRILL Alert flag is set and the OAM Ethertype is present at the end of Flow Entropy:
- TRILL Alertフラグが設定されていて、OAM EthertypeがFlow Entropyの最後にある場合：
* Perform OAM processing.
* OAM処理を実行します。
- Else, extract the TRILL Header, inner MAC addresses, and Inner.VLAN, and pass indication (TRILL-HDR, iDA, iSA, iVL and M3) to the TRILL RBridge layer.
- それ以外の場合は、TRILLヘッダー、内部MACアドレス、Inner.VLANを抽出し、表示（TRILL-HDR、iDA、iSA、iVL、M3）をTRILL RBridgeレイヤーに渡します。
o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, then pass frame up to TRILL IS-IS processing.
o DAがAll-IS-IS-RBridgesで、EthertypeがL2-IS-ISの場合、フレームをTRILL IS-IS処理まで渡します。
o If the DA is All-RBridges or All-IS-IS-RBridges but the Ethertype is not TRILL or L2-IS-IS respectively:
o DAがAll-RBridgesまたはAll-IS-IS-RBridgesであるが、EthertypeがそれぞれTRILLまたはL2-IS-ISでない場合：
- Discard the packet.
- パケットを破棄します。
o If the Ethertype is TRILL but the multicast DA is not All-RBridges or if the Ethertype is L2-IS-IS but the multicast DA is not All-IS-IS-RBridges:
o EthertypeがTRILLであるがマルチキャストDAがAll-RBridgesではない場合、またはEthertypeがL2-IS-ISであるがマルチキャストDAがAll-IS-IS-RBridgesでない場合：
- Discard the packet.
- パケットを破棄します。
o If the DA is All-Edge-RBridges and the Ethertype is RBridge-Channel [RFC7178]:
o DAがAll-Edge-RBridgesで、EthertypeがRBridge-Channel [RFC7178]の場合：
- Process as a possible multicast native RBridge Channel packet.
- 可能なマルチキャストネイティブRBridgeチャネルパケットとして処理します。
o If the DA is in the initial bridging/link protocols block (01-80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL block and not assigned for Outer.MacDA use (01-80-C2-00-00-42 to 01-80-C2-00-00-4F), then:
o DAが初期のブリッジ/リンクプロトコルブロック（01-80-C2-00-00-00から01-80-C2-00-00-0F）にあるか、またはTRILLブロックにあり、Outer.MacDAに割り当てられていない場合（01-80-C2-00-00-42から01-80-C2-00-00-4F）を使用してから、次のようにします。
- The frame is not propagated through an RBridge although some special processing may be done at the port as specified in [RFC6325], and the frame may be dispatched to Layer 2 processing at the port if certain protocols are supported by that port (examples include the Link Aggregation Protocol and the Link-Layer Discovery Protocol).
- フレームはRBridgeを介して伝播されませんが、[RFC6325]で指定されているようにポートで特別な処理が行われる場合があり、特定のプロトコルがそのポートでサポートされている場合、フレームはポートでレイヤ2処理にディスパッチされる場合があります（例には、 Link Aggregation ProtocolおよびLink-Layer Discovery Protocol）。
o If the DA is some other multicast value:
o DAが他のマルチキャスト値の場合：
- Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, M3).
- TRILL-HDRを挿入して構成します（TRILL-HDR、iDA、iSA、IVL、M3）。
- Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to the RBridge layer.
- （TRILL-HDR、iDA、iSA、IVL、M3）をRBridgeレイヤーに渡します。
The following ignores the case of transmitting TRILL IS-IS packets.
以下は、TRILL IS-ISパケットを送信する場合を無視します。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer.
o RBridgeレイヤーから指示（TRILL-HDR、iDA、iSA、iVL、M3）を受け取ります。
o If the TRILL Header multicast ("M") flag is set, the TRILL-HDR Alert flag is set, and the OAM Ethertype is present, then:
o TRILLヘッダーマルチキャスト（ "M"）フラグが設定され、TRILL-HDRアラートフラグが設定され、OAM Ethertypeが存在する場合、次のようになります。
- Construct (DA, SA, V, M2) by inserting TRILL Outer.MacDA of All-RBridges, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
- All-RBridgesのTRILL Outer.MacDA、Outer.MacSA、Outer.VLAN、およびTRILL Ethertypeを挿入して（DA、SA、V、M2）を構築します。ここのM2は（Ethertype TRILL、TRILL-HDR、iDA、iSA、iVL、M）です。
Note: A second copy of native format is not made.
注：ネイティブ形式の2番目のコピーは作成されません。
o Else, if the TRILL Header multicast ("M") flag is set and the Alert flag not set:
o それ以外の場合、TRILLヘッダーマルチキャスト（ "M"）フラグが設定されていて、アラートフラグが設定されていない場合：
- If the port is Appointed Forwarder for iVL and the port is not configured as a trunk port or a P2P port, strip TRILL-HDR, iSA, iDA, and iVL and construct (DA, SA, V, M2) for native format.
- ポートがiVLのAppointed Forwarderであり、ポートがトランクポートまたはP2Pポートとして構成されていない場合は、TRILL-HDR、iSA、iDA、およびiVLを取り除き、ネイティブ形式の（DA、SA、V、M2）を構築します。
- Make a second copy (DA, SA, V, M2) by inserting TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
- TRILL Outer.MacDA、Outer.MacSA、Outer.VLAN、およびTRILL Ethertypeを挿入して、2番目のコピー（DA、SA、V、M2）を作成します。ここのM2は（Ethertype TRILL、TRILL-HDR、iDA、iSA、iVL、M）です。
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 指示（DA、SA、V、M2）を端末VLANおよび優先処理レイヤーに渡します。
The TRILL OAM layer is located between the TRILL Encapsulation/Decapsulation layer and the RBridge layer. It performs the following: 1) identifies OAM frames that need local processing and 2) performs OAM processing or redirects to the CPU for OAM processing.
TRILL OAMレイヤーは、TRILLカプセル化/カプセル化解除レイヤーとRBridgeレイヤーの間にあります。 1）ローカル処理が必要なOAMフレームを識別し、2）OAM処理を実行するか、OAM処理のためにCPUにリダイレクトします。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer. M3 is the payload after Inner.VLAN iVL.
o RBridgeレイヤーから指示（TRILL-HDR、iDA、iSA、iVL、M3）を受け取ります。 M3は、Inner.VLAN iVLの後のペイロードです。
o If the TRILL Header multicast ("M") flag is set, the TRILL Alert flag is set, and TRILL OAM Ethertype is present, then:
o TRILLヘッダーマルチキャスト（「M」）フラグが設定され、TRILLアラートフラグが設定され、TRILL OAM Ethertypeが存在する場合、次のようになります。
- If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then:
- MEPまたはMIPがパケットのInner.VLAN / FGLで構成されている場合、次のようになります。
* Discard packets that have MD-Level less than that of the MEP or packets that do not have MD-Level present (e.g., due to packet truncation).
* MEPのMDレベルよりもMDレベルが小さいパケット、またはMDレベルが存在しないパケット（パケットの切り捨てなどにより）を破棄します。
* If MD-Level matches MD-Level of the MEP, then:
* MDレベルがMEPのMDレベルと一致する場合：
+ Redirect to OAM processing (Do not forward further).
+ OAM処理にリダイレクトします（これ以上転送しないでください）。
* If MD-Level matches MD-Level of MIP, then:
* MDレベルがMIPのMDレベルと一致する場合：
+ Make a copy for OAM processing and continue.
+ OAM処理のコピーを作成して続行します。
* If MD-Level matches MD-Level of MEP, then:
* MDレベルがMEPのMDレベルと一致する場合：
+ Redirect the OAM packet to OAM processing and do not forward along or forward as a native packet.
+ OAMパケットをOAM処理にリダイレクトし、ネイティブパケットとして転送または転送しないでください。
o Else, if the TRILL Alert flag is set and the TRILL OAM Ethertype is present, then:
o そうでない場合、TRILL Alertフラグが設定されていて、TRILL OAM Ethertypeが存在する場合は、次のようになります。
- If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then:
- MEPまたはMIPがパケットのInner.VLAN / FGLで構成されている場合、次のようになります。
* Discard packets that have MD-Level not present or where MD-Level is less than that of the MEP.
* MDレベルが存在しないか、MDレベルがMEPよりも小さいパケットを破棄します。
* If MD-Level matches MD-Level of the MEP, then:
* MDレベルがMEPのMDレベルと一致する場合：
+ Redirect to OAM processing (do not forward further).
+ OAM処理にリダイレクトします（これ以上転送しないでください）。
* If MD-Level matches MD-Level of MIP, then:
* MDレベルがMIPのMDレベルと一致する場合：
+ Make a copy for OAM processing and continue.
+ OAM処理のコピーを作成して続行します。
o Else, for a non-OAM packet:
o それ以外の場合、非OAMパケットの場合：
- Continue.
- 継続する。
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 指示（DA、SA、V、M2）を端末VLANおよび優先処理レイヤーに渡します。
Note: In the receive path, the processing above compares with the Down MEP and MIP Half functions. In the transmit processing, it compares with Up MEP and MIP Half functions.
注：受信パスでは、上記の処理がダウンMEPおよびMIPハーフ機能と比較されます。送信処理では、Up MEPおよびMIP Half機能と比較します。
Appointed Forwarder is a function that the TRILL Encapsulation/Decapsulation layer performs. The TRILL Encapsulation/Decapsulation layer is responsible for prevention of leaking of OAM packets as native frames.
Appointed Forwarderは、TRILLカプセル化/カプセル化解除レイヤーが実行する機能です。 TRILLカプセル化/カプセル化解除レイヤーは、ネイティブフレームとしてのOAMパケットの漏洩を防止する役割を果たします。
[8021Q] defines a Maintenance Association as a logical relationship between a group of nodes. Each Maintenance Association (MA) is identified with a unique MAID of 48 bytes [8021Q]. CCM and other related OAM functions operate within the scope of an MA. The definition of MA is technology independent. Similarly, it is encoded within the OAM message, not in the technology-dependent portion of the packet. Hence, the MAID as defined in [8021Q] can be utilized for TRILL OAM without modifications. This also allows us to utilize CCM and LBM messages defined in [8021Q] as is.
[8021Q]は、ノードのグループ間の論理関係としてメンテナンスアソシエーションを定義します。各メンテナンスアソシエーション（MA）は、48バイトの固有のMAID [8021Q]で識別されます。 CCMおよびその他の関連するOAM機能は、MAのスコープ内で動作します。 MAの定義はテクノロジーに依存しません。同様に、パケットはテクノロジーに依存する部分ではなく、OAMメッセージ内でエンコードされます。したがって、[8021Q]で定義されているMAIDを変更せずにTRILL OAMに使用できます。これにより、[8021Q]で定義されているCCMおよびLBMメッセージをそのまま利用することもできます。
In TRILL, an MA may contain two or more RBridges (MEPs). For unicast, it is likely that the MA contains exactly two MEPs that are the two end points of the flow. For multicast, the MA may contain two or more MEPs.
TRILLでは、MAに2つ以上のRBridge（MEP）を含めることができます。ユニキャストの場合、MAにはフローの2つのエンドポイントであるMEPが2つ含まれている可能性があります。マルチキャストの場合、MAには2つ以上のMEPが含まれる場合があります。
For TRILL, in addition to all of the standard [8021Q] CFM MIB definitions, each MEP's MIB contains one or more Flow Entropy definitions corresponding to the set of flows that the MEP monitors.
TRILLの場合、すべての標準[8021Q] CFM MIB定義に加えて、各MEPのMIBには、MEPが監視するフローのセットに対応する1つ以上のフローエントロピー定義が含まれます。
[8021Q] CFM MIB is augmented to add the TRILL-specific information. Figure 5 depicts the augmentation of the CFM MIB to add the TRILL-specific Flow Entropy.
[8021Q] CFM MIBは、TRILL固有の情報を追加するために拡張されています。図5は、TRILL固有のフローエントロピーを追加するためのCFM MIBの拡張を示しています。
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
| . - Flow Entropy List { Augments IEEE8021-CFM-MIB}
| 。 -Flow Entropy List {Augments IEEE8021-CFM-MIB}
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. --- (Flow Entropy-n)
|
Other MIB entries
Figure 5: Correlation of TRILL-Augmented MIB
図5：TRILL拡張MIBの相関関係
The detailed TRILL OAM MIB will be specified in a separate document [TRILLOAMMIB].
詳細なTRILL OAM MIBは、別のドキュメント[TRILLOAMMIB]で指定されます。
In IEEE CFM [8021Q], OAM messages address the target MEP by utilizing a unique MAC address. In TRILL, a MEP is addressed by a combination of the egress RBridge nickname and the Inner.VLAN/FGL.
IEEE CFM [8021Q]では、OAMメッセージは、一意のMACアドレスを利用してターゲットMEPをアドレス指定します。 TRILLでは、MEPは出力RBridgeニックネームとInner.VLAN / FGLの組み合わせによって対処されます。
Additionally, MEPs are represented by a 2-octet MEP-ID that is independent of the underlying technology. In CFM [8021Q], the value of MEP-ID is restricted to the range of 1 to 8191. However, on a CFM [8021Q] packet, MEP-IDs are encoded as a 2-octet field. In the TRILL Base Mode operation presented in Appendix B, MEP-IDs are mapped 1-to-1 with the RBridge nicknames. Hence, in TRILL, a MEP-ID MUST be a number in the range from 1 to 65535.
さらに、MEPは、基盤となるテクノロジーに依存しない2オクテットのMEP-IDで表されます。 CFM [8021Q]では、MEP-IDの値は1〜8191の範囲に制限されます。ただし、CFM [8021Q]パケットでは、MEP-IDは2オクテットフィールドとしてエンコードされます。付録Bに示されているTRILLベースモード操作では、MEP-IDはRBridgeニックネームで1対1にマッピングされます。したがって、TRILLでは、MEP-IDは1〜65535の範囲の数値である必要があります。
At the MEP, OAM packets go through a hierarchy of OpCode demultiplexers. The OpCode demultiplexers channel the incoming OAM packets to the appropriate message processor (e.g., LBM). Refer to Figure 6 for a visual depiction of these different demultiplexers.
MEPでは、OAMパケットはOpCodeデマルチプレクサの階層を通過します。 OpCodeデマルチプレクサは、着信OAMパケットを適切なメッセージプロセッサ（LBMなど）に送信します。これらの異なるデマルチプレクサーの視覚的描写については、図6を参照してください。
The demultiplexing sequence is as follows:
逆多重化シーケンスは次のとおりです。
1. Identify the packets that need OAM processing at the local RBridge as specified in Section 4.
1. セクション4で指定されているように、ローカルRBridgeでOAM処理が必要なパケットを特定します。
a. Identify the MEP that is associated with the Inner.VLAN/FGL.
a. Inner.VLAN / FGLに関連付けられているMEPを特定します。
2. The MEP first validates the MD-Level and then:
2. MEPは最初にMDレベルを検証してから、次のことを行います。
a. Redirects to the MD-Level demultiplexer.
a. MDレベルのデマルチプレクサーにリダイレクトします。
3. The MD-Level demultiplexer compares the MD-Level of the packet against the MD-Level of the local MEPs of a given MD-Level on the port. (Note: there can be more than one MEP at the same MD-Level but they belong to different MAs.)
3. MDレベルデマルチプレクサは、パケットのMDレベルを、ポート上の特定のMDレベルのローカルMEPのMDレベルと比較します。 （注：同じMDレベルに複数のMEPが存在する可能性がありますが、それらは異なるMAに属しています。）
a. If the packet MD-Level is equal to the configured MD-Level of the MEP, then pass to the OpCode demultiplexer.
a. パケットのMDレベルがMEPの構成されたMDレベルと等しい場合は、OpCodeデマルチプレクサに渡します。
b. If the packet MD-Level is less than the configured MD-Level of the MEP, discard the packet.
b. パケットのMDレベルがMEPの構成されたMDレベルより低い場合、パケットを破棄します。
c. If the packet MD-Level is greater than the configured MD-Level of the MEP, then pass on to the next-higher MD-Level demultiplexer, if available. Otherwise, if no such higher MD-Level demultiplexer exists, then forward the packet as normal data.
c. パケットのMDレベルがMEPの構成されたMDレベルよりも大きい場合は、次に高いMDレベルのデマルチプレクサー（使用可能な場合）に渡します。そうでなければ、そのようなより高いMDレベルのデマルチプレクサが存在しない場合は、パケットを通常のデータとして転送します。
4. The OpCode demultiplexer compares the OpCode in the packet with supported OpCodes.
4. OpCodeデマルチプレクサは、パケット内のOpCodeをサポートされているOpCodeと比較します。
a. If the OpCode is CCM, LBM, LBR, PTM, PTR, MTVM, or MTVR, then pass on to the correct processor.
a. OpCodeがCCM、LBM、LBR、PTM、PTR、MTVM、またはMTVRの場合は、正しいプロセッサーに渡してください。
b. If the OpCode is unknown, then discard.
b. OpCodeが不明な場合は、破棄してください。
|
.CCM LBM PTM MTVM . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code DE-Mux |--- Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |-->|L2 |-.- |Ln |---- >
+-+-+ +-+-+ +-+-+ |
| ^ | | |
MD<LI Drop | Drop Drop |
| |
MD not --- |TRILL OAM need local |
Present | Processing |
| |
TRILL Data ---- TRILL Data ----
------->| T |----------------- >| M |--- >
+ TRILL OAM ---- + pass through OAM ----
Figure 6: OAM Demultiplexers at MEP for Active SAP
図6：MEP for Active SAPのOAMデマルチプレクサ
o T: Denotes Tap. Identifies OAM frames that need local processing. These are the packets with the Alert flag set and OAM Ethertype present after the Flow Entropy of the packet.
o T：タップを示します。ローカル処理が必要なOAMフレームを識別します。これらは、パケットのフローエントロピーの後に存在する、アラートフラグが設定されたパケットとOAM Ethertypeです。
o M: The post-processing merge that merges data and OAM messages that are passed through. Additionally, the merge component ensures, as explained earlier, that OAM packets are not forwarded out as native frames.
o M：通過するデータとOAMメッセージをマージする後処理マージ。さらに、マージコンポーネントは、前に説明したように、OAMパケットがネイティブフレームとして転送されないようにします。
o L: Denotes MD-Level processing. Packets whose MD-Level is less than the MD-Level of the current processing step will be dropped. Packets with equal MD-Levels are passed on to the OpCode demultiplexer. Others are passed on to the next-level MD processors or eventually to the merge point (M).
o L：MDレベルの処理を示します。 MDレベルが現在の処理ステップのMDレベルよりも低いパケットはドロップされます。 MDレベルが等しいパケットは、OpCodeデマルチプレクサに渡されます。その他は、次のレベルのMDプロセッサに渡されるか、最終的にマージポイント（M）に渡されます。
NOTE: LBM, LBR, MTVM, MTVR, PTM, and PTR are not subject to MA demultiplexers. These packets do not have an MA encoded in the packet. Adequate response can be generated to these packets, without loss of functionality, by any of the MEPs present on that interface or an entity within the RBridge.
注：LBM、LBR、MTVM、MTVR、PTM、およびPTRはMAデマルチプレクサーの影響を受けません。これらのパケットには、パケットにエンコードされたMAはありません。これらのパケットに対する適切な応答は、機能を失うことなく、そのインターフェイスまたはRBridge内のエンティティに存在するMEPのいずれかによって生成できます。
Maintenance Intermediate Points (MIPs) are mainly used for fault isolation. Link Trace Messages in [8021Q] utilize a well-known multicast MAC address, and MIPs generate responses to Link Trace Messages. Response to Link Trace Messages or lack thereof can be used for fault isolation in TRILL.
メンテナンス中間ポイント（MIP）は、主に障害分離に使用されます。 [8021Q]のリンクトレースメッセージは、既知のマルチキャストMACアドレスを利用し、MIPはリンクトレースメッセージへの応答を生成します。リンクトレースメッセージへの応答またはその欠如は、TRILLの障害分離に使用できます。
As explained in Section 10, a Hop Count expiry approach will be utilized for fault isolation and path tracing. The approach is very similar to the well-known IP trace-route approach. Hence, explicit addressing of MIPs is not required for the purpose of fault isolation.
セクション10で説明したように、障害の分離とパスの追跡には、ホップカウントの有効期限アプローチが使用されます。このアプローチは、よく知られているIPトレースルートアプローチとよく似ています。したがって、障害を分離するためにMIPの明示的なアドレス指定は必要ありません。
Any given RBridge can have multiple MIPs located within an interface. As such, a mechanism is required to identify which MIP should respond to an incoming OAM message. Any MIP residing within the ingress interface may reply to the incoming Path Trace Message without loss of functionality or information. As specified in Section 3.4, the address of the responding RBridge can be identified by means of the Sender ID TLV (1). The Reply Ingress TLV (5) identifies the interface id. The combination of these allows the recipient of the response to uniquely identify the responder.
特定のRBridgeでは、インターフェイス内に複数のMIPを配置できます。そのため、着信OAMメッセージに応答するMIPを識別するメカニズムが必要です。入力インターフェイス内にあるMIPは、機能や情報を失うことなく、着信パストレースメッセージに応答できます。セクション3.4で指定されているように、応答するRBridgeのアドレスは、Sender ID TLV（1）を使用して識別できます。 Reply Ingress TLV（5）はインターフェースIDを識別します。これらの組み合わせにより、応答の受信者は応答者を一意に識別できます。
A similar approach to that presented above for MEPs can be used for MIP processing. It is important to note that "M", the merge block of a MIP, does not prevent OAM packets leaking out as native frames. On edge interfaces, MEPs MUST be configured to prevent the leaking of TRILL OAM packets out of the TRILL campus.
上記のMEPと同様のアプローチをMIP処理に使用できます。 MIPのマージブロックである「M」は、OAMパケットがネイティブフレームとしてリークすることを防止しないことに注意することが重要です。エッジインターフェイスでは、MEPを設定して、TRILLキャンパスからのTRILL OAMパケットの漏洩を防止する必要があります。
PTM PTR MTVM MTVR
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code De-Mux |-> Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |- >|L2 |-.- |Ln |------+
+-+-+ +-+-+ +-+-+ |
^ |
| |
Drop | |
MD not --- |TRILL OAM |
Present | |
| v
TRILL Data ---- TRILL Data -----
------- >| T |------------------ >| M |---->
+ TRILL OAM ---- ----
Figure 7: OAM Demultiplexers at MIP for Active SAP
図7：MIP for Active SAPのOAMデマルチプレクサー
o T: Tap processing for MIP. All packets with the TRILL Header Alert flag set are captured.
o T：MIPのタップ処理。 TRILLヘッダーアラートフラグが設定されたすべてのパケットがキャプチャされます。
o L: MD-Level Processing. Packets with matching MD-Levels are "copied" to the OpCode demultiplexer, and the original packet is passed on to the next MD-Level processor. Other packets are simply passed on to the next MD-Level processor without copying to the OpCode demultiplexer.
o L：MDレベルの処理。 MDレベルが一致するパケットはOpCodeデマルチプレクサに「コピー」され、元のパケットは次のMDレベルプロセッサに渡されます。他のパケットは、OpCodeデマルチプレクサにコピーせずに、単に次のMDレベルプロセッサに渡されます。
o M: The intermediate point processing merge that merges data and OAM messages that are passed through.
o M：通過するデータとOAMメッセージをマージする中間ポイント処理マージ。
Packets that carry Path Trace Message (PTM) or Multi-destination Tree Verification Message (MTVM) OpCodes are passed on to the respective processors.
パストレースメッセージ（PTM）またはマルチ宛先ツリー検証メッセージ（MTVM）のOpCodeを運ぶパケットは、それぞれのプロセッサに渡されます。
Packets with unknown OpCodes are counted and discarded.
OpCodeが不明なパケットはカウントされて破棄されます。
CCMs are used to monitor connectivity and configuration errors. [8021Q] monitors connectivity by listening to periodic CCM messages received from its remote MEP partners in the MA. An [8021Q] MEP identifies cross-connect errors by comparing the MAID in the received CCM message with the MEP's local MAID. The MAID [8021Q] is a 48-byte field that is technology independent. Similarly, the MEP-ID is a 2-byte field that is independent of the technology. Given this generic definition of CCM fields, CCM as defined in [8021Q] can be utilized in TRILL with no changes. TRILL-specific information may be carried in CCMs when encoded using TRILL-specific TLVs or sub-TLVs. This is possible since CCMs may carry optional TLVs.
CCMは、接続と構成のエラーを監視するために使用されます。 [8021Q]は、MAのリモートMEPパートナーから受信した定期的なCCMメッセージをリッスンして接続を監視します。 [8021Q] MEPは、受信したCCMメッセージのMAIDをMEPのローカルMAIDと比較して、クロスコネクトエラーを識別します。 MAID [8021Q]は、テクノロジーに依存しない48バイトのフィールドです。同様に、MEP-IDは、テクノロジーに依存しない2バイトのフィールドです。 CCMフィールドのこの一般的な定義を前提として、[8021Q]で定義されているCCMは、変更なしでTRILLで利用できます。 TRILL固有の情報は、TRILL固有のTLVまたはサブTLVを使用してエンコードされている場合、CCMで伝達されることがあります。 CCMはオプションのTLVを伝送できるため、これは可能です。
Unlike classical Ethernet environments, TRILL contains multipath forwarding. The path taken by a packet depends on the payload of the packet. The Maintenance Association (MA) identifies the interested Maintenance End Points (MEPs) of a given monitored path. For unicast, there are only two MEPs per MA. For multicast, there can be two or more MEPs in the MA. The entropy values of the monitored flows are defined within the MA. CCM transmit logic will utilize these Flow Entropy values when constructing the CCM packets. Please see Section 12 for the theory of operation of CCM.
従来のイーサネット環境とは異なり、TRILLにはマルチパス転送が含まれています。パケットがたどるパスは、パケットのペイロードによって異なります。メンテナンスアソシエーション（MA）は、特定の監視対象パスの対象のメンテナンスエンドポイント（MEP）を識別します。ユニキャストの場合、MAあたりのMEPは2つだけです。マルチキャストの場合、MAに2つ以上のMEPが存在する可能性があります。監視されるフローのエントロピー値はMA内で定義されます。 CCM送信ロジックは、CCMパケットを構築するときにこれらのフローエントロピー値を利用します。 CCMの動作理論については、セクション12を参照してください。
The MIB in [8021Q] is augmented with the definition of Flow Entropy. Please see [TRILLOAMMIB] for this and other TRILL-related OAM MIB definitions. Figure 8 depicts the correlation between MA, CCM, and the Flow Entropy.
[8021Q]のMIBには、フローエントロピーの定義が追加されています。これと他のTRILL関連のOAM MIB定義については、[TRILLOAMMIB]を参照してください。図8は、MA、CCM、およびフローエントロピーの相関関係を示しています。
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
| . - Flow Entropy List {Augments IEEE8021-CFM-MIB}
| 。 -Flow Entropy List {Augments IEEE8021-CFM-MIB}
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. ---(Flow Entropy-n)
|
. - CCM
|
--- (standard 8021ag entries)
|
--- (Hop Count) { Augments IEEE8021-CFM-MIB}
|
--- (Any other TRILL OAM-specific entries)
{Augmented}
|
.
|
- Other MIB entries
Figure 8: Augmentation of CCM MIB in TRILL
図8：TRILLでのCCM MIBの拡張
In a multi-pathing environment, a flow, by definition, is unidirectional. A question may arise as to what Flow Entropy should be used in the response. CCMs are unidirectional and have no explicit reply; as such, the issue of the response Flow Entropy does not arise. In the transmitted CCM, each MEP reports local status using the Remote Defect Indication (RDI) flag. Additionally, a MEP may raise SNMP TRAPs [TRILLOAMMIB] as alarms when a connectivity failure occurs.
マルチパス環境では、フローは定義上、単方向です。応答でどのフローエントロピーを使用する必要があるかという疑問が生じる場合があります。 CCMは単方向であり、明示的な応答はありません。そのため、応答フローエントロピーの問題は発生しません。送信されたCCMで、各MEPはリモート障害表示（RDI）フラグを使用してローカルステータスを報告します。さらに、MEPは、接続障害が発生したときにアラームとしてSNMP TRAP [TRILLOAMMIB]を生成する場合があります。
The TRILL OAM Message Channel can be divided into two parts: TRILL OAM message header and TRILL OAM TLVs. Every OAM message MUST contain a single TRILL OAM message header and a set of one or more specified OAM message TLVs.
TRILL OAMメッセージチャネルは、TRILL OAMメッセージヘッダーとTRILL OAM TLVの2つの部分に分けることができます。すべてのOAMメッセージには、1つのTRILL OAMメッセージヘッダーと、1つ以上の指定されたOAMメッセージTLVのセットが含まれている必要があります。
As discussed earlier, a common messaging framework between [8021Q], TRILL, and other similar standards such as Y.1731 is accomplished by reusing the OAM message header defined in [8021Q].
前述のように、[8021Q]、TRILL、およびY.1731などの他の同様の標準の間の共通のメッセージングフレームワークは、[8021Q]で定義されたOAMメッセージヘッダーを再利用することによって実現されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-Specific Information .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OAM Message Format
図9：OAMメッセージの形式
o MD-L: Maintenance Domain Level (3 bits). For TRILL, in general, this field is set to a single value across the TRILL campus. When using the TRILL Base Mode as specified in Appendix B, MD-L is set to 3. However, extension of TRILL (for example, to support multilevel) may create different MD-Levels, and the MD-L field must be appropriately set in those scenarios. (Please refer to [8021Q] for the definition of MD-Level).
o MD-L：メンテナンスドメインレベル（3ビット）。 TRILLの場合、通常、このフィールドはTRILLキャンパス全体で単一の値に設定されます。付録Bで指定されているTRILLベースモードを使用する場合、MD-Lは3に設定されます。ただし、TRILLの拡張（たとえば、マルチレベルをサポートするため）によって異なるMDレベルが作成される場合があり、MD-Lフィールドを適切に設定する必要がありますそれらのシナリオで。 （MDレベルの定義については、[8021Q]を参照してください）。
o Version: Indicates the version (5 bits) as specified in [8021Q]. This document does not require changing the Version defined in [8021Q].
o バージョン：[8021Q]で指定されているバージョン（5ビット）を示します。このドキュメントでは、[8021Q]で定義されているバージョンを変更する必要はありません。
o OpCode: Operation Code (8 bits). Specifies the operation performed by the message. See Section 8.2.
o OpCode：オペレーションコード（8ビット）。メッセージによって実行される操作を指定します。セクション8.2を参照してください。
o Flags: Includes operational flags (1 byte). The definition of flags is OpCode-specific and is covered in the applicable sections.
o フラグ：操作フラグが含まれます（1バイト）。フラグの定義はOpCode固有であり、該当するセクションで説明されています。
o FirstTLVOffset: Defines the location of the first TLV, in bytes, starting from the end of the FirstTLVOffset field (1 byte). (Refer to [8021Q] for the definition of the FirstTLVOffset.)
o FirstTLVOffset：FirstTLVOffsetフィールドの最後（1バイト）から始めて、最初のTLVの場所をバイト単位で定義します。 （FirstTLVOffsetの定義については、[8021Q]を参照してください。）
o OpCode-Specific Information: May contain Session Identification Number, timestamp, etc.
o OpCode固有の情報：セッション識別番号、タイムスタンプなどが含まれる場合があります。
The MD-L, Version, OpCode, Flags, and FirstTLVOffset fields collectively are referred to as the OAM message header.
MD-L、Version、OpCode、Flags、FirstTLVOffsetの各フィールドをまとめてOAMメッセージヘッダーと呼びます。
The following TRILL-specific CFM OpCodes are defined. Each of the OpCodes indicates a separate type of TRILL OAM message. Details of the messages are presented in Sections 10 and 11.
以下のTRILL固有のCFM OpCodeが定義されています。各OpCodeは、個別のタイプのTRILL OAMメッセージを示します。メッセージの詳細は、セクション10および11に記載されています。
TRILL OAM message OpCodes:
TRILL OAMメッセージのOpCode：
64: Path Trace Reply 65: Path Trace Message 66: Multi-destination Tree Verification Reply 67: Multi-destination Tree Verification Message
64：パストレース応答65：パストレースメッセージ66：複数宛先ツリー検証応答67：複数宛先ツリー検証メッセージ
Loopback and CCM Messages reuse the OpCodes defined by [8021Q].
ループバックとCCMメッセージは、[8021Q]で定義されたOpCodeを再利用します。
The same CFM TLV format as defined in [8021Q] is used for TRILL OAM. The following figure depicts the general format of a TRILL OAM TLV:
[8021Q]で定義されているものと同じCFM TLV形式がTRILL OAMに使用されます。次の図は、TRILL OAM TLVの一般的な形式を示しています。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL OAM TLV
図10：TRILL OAM TLV
o Type (1 octet): Specifies the type of the TLV (see Section 8.4 for TLV types).
o タイプ（1オクテット）：TLVのタイプを指定します（TLVタイプについてはセクション8.4を参照）。
o Length (2 octets): Specifies the length of the Value field in octets. Length of the Value field can be zero or more octets.
o 長さ（2オクテット）：値フィールドの長さをオクテットで指定します。値フィールドの長さは、0オクテット以上にすることができます。
o Value (variable): The length and the content of this field depend on the type of TLV. Please refer to applicable TLV definitions for details.
o 値（変数）：このフィールドの長さと内容は、TLVのタイプによって異なります。詳細については、該当するTLV定義を参照してください。
Semantics and usage of Type values allocated for TRILL OAM purpose are defined by this document and other future related documents.
TRILL OAMの目的で割り当てられたType値のセマンティクスと使用法は、このドキュメントと他の将来の関連ドキュメントで定義されています。
TRILL-related TLVs are defined in this section. TLVS defined in [8021Q] are reused, where applicable.
このセクションでは、TRILL関連のTLVを定義します。 [8021Q]で定義されたTLVSは、必要に応じて再利用されます。
The following TLVs are defined in [8021Q]. We reuse them where applicable. The format and semantics of the TLVs are as defined in [8021Q].
次のTLVは[8021Q]で定義されています。必要に応じて再利用します。 TLVのフォーマットとセマンティクスは、[8021Q]で定義されています。
Type Name of TLV in [8021Q]
---- ----------------------
0 End TLV
1 Sender ID TLV
2 Port Status TLV
3 Data TLV
4 Interface Status TLV
5 Reply Ingress TLV
6 Reply Egress TLV
7 LTM Egress Identifier TLV
8 LTR Egress Identifier TLV
9-30 Reserved
31 Organization Specific TLV
Listed below is a summary of TRILL OAM TLVs and their corresponding codes. Format and semantics of TRILL OAM TLVs are defined in subsequent sections.
以下に、TRILL OAM TLVとそれに対応するコードの概要を示します。 TRILL OAM TLVのフォーマットとセマンティクスは、後続のセクションで定義されています。
Type TLV Name
---- ------------------------------------
64 TRILL OAM Application Identifier TLV
65 Out-of-Band Reply Address TLV
66 Diagnostic Label TLV
67 Original Data Payload TLV
68 RBridge Scope TLV
69 Previous RBridge Nickname TLV
70 Next-Hop RBridge List TLV
71 Multicast Receiver Port Count TLV
72 Flow Identifier TLV
73 Reflector Entropy TLV
74 Authentication TLV
The TRILL OAM Application Identifier TLV (64) MUST be the first TLV. An End TLV (0) MUST be included as the last TLV. All other TLVs can be included in any order.
TRILL OAMアプリケーション識別子TLV（64）は最初のTLVでなければなりません。最後のTLVとして終了TLV（0）を含める必要があります。他のすべてのTLVは任意の順序で含めることができます。
The TRILL OAM Application Identifier TLV carries information specific to TRILL OAM applications. The TRILL OAM Application Identifier TLV MUST always be present and MUST be the first TLV in TRILL OAM messages. Messages that do not include the TRILL OAM Application Identifier TLV as the first TLV MUST be discarded by a TRILL MP.
TRILL OAMアプリケーション識別子TLVは、TRILL OAMアプリケーションに固有の情報を伝達します。 TRILL OAMアプリケーション識別子TLVは常に存在しなければならず、TRILL OAMメッセージの最初のTLVでなければなりません。最初のTLVとしてTRILL OAMアプリケーション識別子TLVを含まないメッセージは、TRILL MPによって破棄する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Fragment-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |Return Sub-code| Reserved2 |F|C|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TRILL OAM Application Identifier TLV
図11：TRILL OAMアプリケーション識別子TLV
o Type (1 octet): 64, TRILL OAM Application Identifier TLV
o タイプ（1オクテット）：64、TRILL OAMアプリケーション識別子TLV
o Length (2 octets): 9
o 長さ（2オクテット）：9
o Version (1 octet): Currently set to zero. Indicates the TRILL OAM version. The TRILL OAM version can be different than the [8021Q] version.
o バージョン（1オクテット）：現在ゼロに設定されています。 TRILL OAMバージョンを示します。 TRILL OAMバージョンは、[8021Q]バージョンと異なる場合があります。
o Reserved1 (3 octets): Set to zero on transmission and ignored on reception.
o Reserved1（3オクテット）：送信時にはゼロに設定され、受信時には無視されます。
o Fragment-ID (1 octet): Indicates the fragment number of the current message. This applies only to reply messages; in request messages, it must be set to zero on transmission and ignored on receipt. The "F" flag defined below MUST be set with the final message, whether it is the last fragment of the fragmented message or the only message of the reply. Section 13 provides more details on OAM message fragmentation.
o フラグメントID（1オクテット）：現在のメッセージのフラグメント番号を示します。これは返信メッセージにのみ適用されます。要求メッセージでは、送信時にゼロに設定し、受信時に無視する必要があります。以下で定義される「F」フラグは、それが断片化されたメッセージの最後のフラグメントであるか、または応答の唯一のメッセージであるかに関係なく、最終メッセージで設定する必要があります。セクション13では、OAMメッセージの断片化について詳しく説明します。
o Return Code (1 octet): Set to zero on requests. Set to an appropriate value in response messages.
o 戻りコード（1オクテット）：要求時にゼロに設定します。応答メッセージで適切な値に設定します。
o Return Sub-code (1 octet): Set to zero on transmission of request message. The Return Sub-code identifies categories within a specific Return Code and MUST be interpreted within a Return Code.
o サブコードを返す（1オクテット）：要求メッセージの送信時にゼロに設定します。リターンサブコードは、特定のリターンコード内のカテゴリを識別し、リターンコード内で解釈する必要があります。
o Reserved2 (12 bits): Set to zero on transmission and ignored on reception.
o Reserved2（12ビット）：送信時にゼロに設定され、受信時には無視されます。
o F (1 bit): Final flag. When set, indicates this is the last response.
o F（1ビット）：最終フラグ。設定されている場合、これが最後の応答であることを示します。
o C (1 bit): Cross-Connect Error flag (VLAN/FGL mapping error). If set, indicates that the label (VLAN/FGL) in the Flow Entropy is different than the label included in the Diagnostic Label TLV. This field is ignored in request messages and MUST only be interpreted in response messages.
o C（1ビット）：クロスコネクトエラーフラグ（VLAN / FGLマッピングエラー）。設定されている場合、フローエントロピーのラベル（VLAN / FGL）が診断ラベルTLVに含まれているラベルと異なることを示します。このフィールドは要求メッセージでは無視され、応答メッセージでのみ解釈される必要があります。
o O (1 bit): If set, indicates OAM out-of-band response requested.
o O（1ビット）：設定されている場合、OAM帯域外応答が要求されたことを示します。
o I (1 bit): If set, indicates OAM in-band response requested.
o I（1ビット）：設定されている場合、OAM帯域内応答が要求されたことを示します。
NOTE: When both O and I bits are set to zero, this indicates that no response is required (silent mode). Users MAY specify both O and I, one of them, or none. When both O and I bits are set, the response is sent both in-band and out-of-band.
注：OビットとIビットの両方がゼロに設定されている場合、これは応答が不要であることを示します（サイレントモード）。ユーザーは、OとIの両方を指定することも、どちらか一方を指定することもできます（MAY）。 OビットとIビットの両方が設定されている場合、応答は帯域内と帯域外の両方で送信されます。
The Out-of-Band Reply Address TLV specifies the address to which an out-of-band OAM reply message MUST be sent. When the O bit in the TRILL Version sub-TLV (Section 3.3) is not set, the Out-of-Band Reply Address TLV is ignored.
アウトオブバンド応答アドレスTLVは、アウトオブバンドOAM応答メッセージの送信先アドレスを指定します。 TRILLバージョンサブTLV（セクション3.3）のOビットが設定されていない場合、アウトオブバンド応答アドレスTLVは無視されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | |
+-+-+-+-+-+-+-+-+ |
| |
. Reply Address .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Out-of-Band Reply Address TLV
図12：帯域外応答アドレスTLV
o Type (1 octet): 65, Out-of-Band Reply Address TLV
o タイプ（1オクテット）：65、アウトオブバンド応答アドレスTLV
o Length (2 octets): Variable. Minimum length is 2 + the length (in octets) of the shortest address. Currently, the minimum value of this field is 4, but this could change in the future if a new address shorter than the TRILL nickname is defined.
o 長さ（2オクテット）：可変。最小長は2 +最短アドレスの長さ（オクテット単位）です。現在、このフィールドの最小値は4ですが、TRILLニックネームより短い新しいアドレスが定義されると、将来的に変更される可能性があります。
o Address Type (1 octet):
o アドレスタイプ（1オクテット）：
0 - IPv4
0-IPv4
1 - IPv6
1-IPv6
2 - TRILL nickname
2-TRILLニックネーム
All other values reserved.
他のすべての値は予約されています。
o Addr Length (1 octet): Depends on the Address Type. Currently, defined values are:
o アドレス長（1オクテット）：アドレスタイプによって異なります。現在、定義されている値は次のとおりです。
4 - IPv4
4-IPv4
16 - IPv6
16-IPv6
2 - TRILL nickname
2-TRILLニックネーム
Other lengths may be acceptable for future Address Types.
他の長さは、将来のアドレスタイプで許容される可能性があります。
o Reply Address (variable): Address where the reply needs to be sent. Length depends on the address specification.
o 返信アドレス（変数）：返信を送信する必要があるアドレス。長さはアドレス指定によって異なります。
The Diagnostic Label TLV specifies the data label (VLAN or FGL) in which the OAM messages are generated. Receiving RBridge MUST compare the data label of the Flow Entropy to the data label specified in the Diagnostic Label TLV. The "C" flag (Cross Connect Error) in the response (TRILL OAM Application Identifier TLV; Section 8.4.3) MUST be set when the two VLANs do not match.
診断ラベルTLVは、OAMメッセージが生成されるデータラベル（VLANまたはFGL）を指定します。受信RBridgeは、フローエントロピーのデータラベルを診断ラベルTLVで指定されたデータラベルと比較する必要があります。 2つのVLANが一致しない場合、応答（TRILL OAM Application Identifier TLV;セクション8.4.3）の「C」フラグ（Cross Connect Error）を設定する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | L-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Diagnostic Label TLV
図13：診断ラベルTLV
o Type (1 octet): 66, Diagnostic Label TLV
o タイプ（1オクテット）：66、診断ラベルTLV
o Length (2 octets): 5
o 長さ（2オクテット）：5
o L-Type (1 octet): Label type
o Lタイプ（1オクテット）：ラベルタイプ
0 - Indicates a right-justified 802.1Q 12-bit VLAN padded on the left with bits that must be sent as zero and ignored on receipt
0-右寄せの802.1Q 12ビットVLANを示します。左側には0として送信し、受信時に無視する必要があるビットが埋め込まれています。
1 - Indicates a TRILL 24-bit fine-grained label
1-TRILL 24ビットの細粒度ラベルを示します
o Reserved (1 octet): Set to zero on transmission and ignored on reception.
o 予約済み（1オクテット）：送信時にはゼロに設定され、受信時には無視されます。
o Label (24 bits): Either 12-bit VLAN or 24 bit fine-grained label.
o ラベル（24ビット）：12ビットVLANまたは24ビットのきめ細かいラベル。
RBridges do not perform label error checking when the Diagnostic Label TLV is not included in the OAM message. In certain deployments, intermediate devices may perform label translation. In such scenarios, the originator should not include the Diagnostic Label TLV in OAM messages. Inclusion of Diagnostic Label TLV will generate unwanted label error notifications.
診断ラベルTLVがOAMメッセージに含まれていない場合、RBridgeはラベルエラーチェックを実行しません。特定の展開では、中間デバイスがラベル変換を実行する場合があります。このようなシナリオでは、発信者はOAMメッセージに診断ラベルTLVを含めないでください。診断ラベルTLVを含めると、不要なラベルエラー通知が生成されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Original Payload .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Original Data Payload TLV
図14：元のデータペイロードTLV
o Type (1 octet): 67, Original Data Payload TLV
o タイプ（1オクテット）：67、元のデータペイロードTLV
o Length (2 octets): variable
o 長さ（2オクテット）：可変
o Original Payload: The original TRILL Header and Flow Entropy. Used in constructing replies to the Loopback Message (see Section 9) and the Path Trace Message (see Section 10).
o オリジナルのペイロード：オリジナルのTRILLヘッダーとフローエントロピー。ループバックメッセージ（セクション9を参照）およびパストレースメッセージ（セクション10を参照）への応答の作成に使用されます。
The RBridge Scope TLV identifies nicknames of RBridges from which a response is required. The RBridge Scope TLV is only applicable to Multi-destination Tree Verification Messages. This TLV SHOULD NOT be included in other messages. Receiving RBridges MUST ignore this TLV on messages other than Multi-destination Tree Verification Messages.
RBridge Scope TLVは、応答が必要なRBridgeのニックネームを識別します。 RBridge Scope TLVは、マルチ宛先ツリー検証メッセージにのみ適用されます。このTLVは他のメッセージに含まれるべきではありません。受信RBridgesは、マルチ宛先ツリー検証メッセージ以外のメッセージでこのTLVを無視する必要があります。
Each TLV can contain up to 255 nicknames of in-scope RBridges. A Multi-destination Tree Verification Message may contain multiple RBridge scope TLVs, in the event that more than 255 in-scope RBridges need to be specified.
各TLVには、スコープ内のRBridgeのニックネームを最大255個含めることができます。 255を超えるスコープ内RBridgeを指定する必要がある場合、複数宛先ツリー検証メッセージに複数のRBridgeスコープTLVが含まれる場合があります。
Absence of the RBridge Scope TLV indicates that a response is needed from all the RBridges. Please see Section 11 for details.
RBridge Scope TLVがない場合は、すべてのRBridgeからの応答が必要であることを示します。詳細については、セクション11を参照してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: RBridge Scope TLV
図15：RBridgeスコープTLV
o Type (1 octet): 68, RBridge Scope TLV
o タイプ（1オクテット）：68、RBridgeスコープTLV
o Length (2 octets): Variable. Minimum value is 1.
o 長さ（2オクテット）：可変。最小値は1です。
o nOfnicknames (1 octet): Indicates the number of nicknames included in this TLV. Zero (0) indicates no nicknames are included in the TLV. When this field is set to zero (0), the Length field MUST be set to 1.
o nOfnicknames（1オクテット）：このTLVに含まれるニックネームの数を示します。ゼロ（0）は、ニックネームがTLVに含まれていないことを示します。このフィールドがゼロ（0）に設定されている場合、長さフィールドは1に設定する必要があります。
o Nickname (2 octets): 16-bit RBridge nickname
o ニックネーム（2オクテット）：16ビットRBridgeニックネーム
The Previous RBridge Nickname TLV identifies the nickname or nicknames of the previous RBridge. [RFC6325] allows a given RBridge to hold multiple nicknames.
以前のRBridge Nickname TLVは、以前のRBridgeの1つまたは複数のニックネームを識別します。 [RFC6325]は、特定のRBridgeが複数のニックネームを保持できるようにします。
The Previous RBridge Nickname TLV is an optional TLV. Multiple instances of this TLV MAY be included when an upstream RBridge is represented by more than 255 nicknames (highly unlikely).
以前のRBridge Nickname TLVはオプションのTLVです。アップストリームRBridgeが255を超えるニックネームで表されている場合（ほとんどあり得ない）、このTLVの複数のインスタンスが含まれる場合があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Previous RBridge Nickname TLV
図16：以前のRBridgeニックネームTLV
o Type (1 octet): 69, Previous RBridge Nickname TLV
o タイプ（1オクテット）：69、以前のRBridgeニックネームTLV
o Length (2 octets): 5 o Reserved (3 octet): Set to zero on transmission and ignored on reception.
o長さ（2オクテット）：5 o予約済み（3オクテット）：送信時にゼロに設定され、受信時には無視されます。
o Nickname (2 octets): RBridge nickname
o ニックネーム（2オクテット）：RBridgeニックネーム
The Next-Hop RBridge List TLV identifies the nickname or nicknames of the downstream next-hop RBridges. [RFC6325] allows a given RBridge to have multiple equal-cost paths to a specified destination. Each next-hop RBridge is represented by one of its nicknames.
Next-Hop RBridge List TLVは、ダウンストリームのネクストホップRBridgeの1つまたは複数のニックネームを識別します。 [RFC6325]は、指定されたRBridgeが指定された宛先への複数の等価コストパスを持つことを許可します。各ネクストホップRBridgeは、そのニックネームの1つで表されます。
The Next-Hop RBridge List TLV is an optional TLV. Multiple instances of this TLV MAY be included when there are more than 255 equal-cost paths to the destination.
Next-Hop RBridge List TLVはオプションのTLVです。宛先への等コストパスが255を超える場合、このTLVの複数のインスタンスが含まれる場合があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Next-Hop RBridge List TLV
図17：ネクストホップRBridgeリストTLV
o Type (1 octet): 70, Next-Hop RBridge List TLV
o タイプ（1オクテット）：70、ネクストホップRBridgeリストTLV
o Length (2 octets): Variable. Minimum value is 1.
o 長さ（2オクテット）：可変。最小値は1です。
o nOfnicknames (1 octet): Indicates the number of nicknames included in this TLV. Zero (0) indicates no nicknames are included in the TLV. When this field is set to zero (0), the Length field MUST be set to 1.
o nOfnicknames（1オクテット）：このTLVに含まれるニックネームの数を示します。ゼロ（0）は、ニックネームがTLVに含まれていないことを示します。このフィールドがゼロ（0）に設定されている場合、長さフィールドは1に設定する必要があります。
o Nickname (2 octets): 16-bit RBridge nickname
o ニックネーム（2オクテット）：16ビットRBridgeニックネーム
The Multicast Receiver Port Count TLV identifies the number of ports interested in receiving the specified multicast stream within the responding RBridge on the label (VLAN or FGL) specified by the Diagnostic Label TLV.
マルチキャストレシーバーポート数TLVは、診断ラベルTLVで指定されたラベル（VLANまたはFGL）の応答RBridge内の指定されたマルチキャストストリームの受信に関係するポートの数を識別します。
The Multicast Receiver Port Count TLV is an optional TLV.
マルチキャストレシーバーポート数TLVは、オプションのTLVです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Receivers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Multicast Receiver Port Count TLV
図18：マルチキャストレシーバーのポート数TLV
o Type (1 octet): 71, Multicast Receiver Port Count TLV
o タイプ（1オクテット）：71、マルチキャストレシーバーポート数TLV
o Length (2 octets): 5
o 長さ（2オクテット）：5
o Reserved (1 octet): Set to zero on transmission and ignored on reception.
o 予約済み（1オクテット）：送信時にはゼロに設定され、受信時には無視されます。
o Number of Receivers (4 octets): Indicates the number of multicast receivers available on the responding RBridge on the label specified by the diagnostic label.
o レシーバーの数（4オクテット）：診断ラベルで指定されたラベルの応答RBridgeで使用可能なマルチキャストレシーバーの数を示します。
The Flow Identifier TLV uniquely identifies a specific flow. The flow-identifier value is unique per MEP and needs to be interpreted as such.
フロー識別子TLVは、特定のフローを一意に識別します。フロー識別子の値はMEPごとに一意であり、そのように解釈する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP-ID | flow-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Flow Identifier TLV
図19：フロー識別子TLV
o Type (1 octet): 72, Flow Identifier TLV
o タイプ（1オクテット）：72、フロー識別子TLV
o Length (2 octets): 5
o 長さ（2オクテット）：5
o Reserved (1 octet): Set to 0 on transmission and ignored on reception.
o 予約済み（1オクテット）：送信時には0に設定され、受信時には無視されます。
o MEP-ID (2 octets): MEP-ID of the originator [8021Q]. In TRILL, MEP-ID can take a value from 1 to 65535.
o MEP-ID（2オクテット）：発信者のMEP-ID [8021Q]。 TRILLでは、MEP-IDは1〜65535の値を取ることができます。
o flow-identifier (2 octets): Uniquely identifies the flow per MEP. Different MEPs may allocate the same flow-identifier value. The {MEP-ID, flow-identifier} pair is globally unique.
o フロー識別子（2オクテット）：MEPごとにフローを一意に識別します。異なるMEPが同じフロー識別子の値を割り当てる場合があります。 {MEP-ID、flow-identifier}のペアはグローバルに一意です。
Inclusion of the MEP-ID in the Flow Identifier TLV allows the inclusion of a MEP-ID for messages that do not contain a MEP-ID in their OAM header. Applications may use MEP-ID information for different types of troubleshooting.
フロー識別子TLVにMEP-IDを含めることで、OAMヘッダーにMEP-IDを含まないメッセージのMEP-IDを含めることができます。アプリケーションは、さまざまなタイプのトラブルシューティングにMEP-ID情報を使用できます。
The Reflector Entropy TLV is an optional TLV. This TLV, when present, tells the responder to utilize the Reflector Entropy specified within the TLV as the flow-entropy of the response message.
Reflector Entropy TLVはオプションのTLVです。このTLVが存在する場合、TLV内で指定されたリフレクターエントロピーを応答メッセージのフローエントロピーとして利用するようにレスポンダーに指示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Reflector Entropy .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Reflector Entropy TLV
図20：リフレクターエントロピーTLV
o Type (1 octet): 73, Reflector Entropy TLV
o タイプ（1オクテット）：73、リフレクターエントロピーTLV
o Length (2 octets): 97
o 長さ（2オクテット）：97
o Reserved (1 octet): Set to zero on transmission and ignored by the recipient.
o 予約済み（1オクテット）：送信時にゼロに設定され、受信者によって無視されます。
o Reflector Entropy (96 octets): Flow Entropy to be used by the responder. May be padded with zeros if the desired flow-entropy information is less than 96 octets.
o リフレクターエントロピー（96オクテット）：レスポンダが使用するフローエントロピー。必要なフローエントロピー情報が96オクテット未満の場合、ゼロが埋め込まれることがあります。
The Authentication TLV is an optional TLV that can appear in any OAM message or reply in TRILL.
認証TLVは、任意のOAMメッセージに表示されるか、TRILLで応答できるオプションのTLVです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Authentication Value .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Authentication TLV
図21：認証TLV
o Type (1 octet): 74, Authentication TLV
o タイプ（1オクテット）：74、認証TLV
o Length (2 octets): Variable
o 長さ（2オクテット）：可変
o The Auth Type and following Authentication Value are the same as the Auth Type and following value for the [IS-IS] Authentication TLV. It is RECOMMENDED that Auth Type 3 be used. Auth Types 0, 1, 2, and 54 MUST NOT be used. With Auth Type 3, the Authentication TLV is as follows:
o 認証タイプとそれに続く認証値は、[IS-IS]認証TLVの認証タイプとそれに続く値と同じです。 Auth Type 3を使用することをお勧めします。認証タイプ0、1、2、および54は使用しないでください。認証タイプ3では、認証TLVは次のようになります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. Authentication Data (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Authentication TLV with Auth Type 3
図22：認証タイプ3の認証TLV
With Auth Type 3, the process is generally as specified in [RFC5310] using the same Key ID space as TRILL [IS-IS]. The area covered by the Authentication TLV is from the beginning of the TRILL Header to the end of the TRILL OAM Message Channel; the Link Header and Trailer are not included. The TRILL Header Alert, Reserved bit, and Hop Count are treated as zero for the purposes of computing and verifying the Authentication Data.
認証タイプ3では、プロセスは一般に[RFC5310]で指定されているとおり、TRILL [IS-IS]と同じキーIDスペースを使用します。認証TLVでカバーされる領域は、TRILLヘッダーの先頭からTRILL OAMメッセージチャネルの末尾までです。リンクヘッダーとトレーラーは含まれていません。 TRILLヘッダーアラート、予約済みビット、およびホップカウントは、認証データの計算と検証のためにゼロとして扱われます。
Key distribution is out of the scope of this document as the keying distributed for IS-IS is used.
IS-ISに配布されたキーイングが使用されるため、キーの配布はこのドキュメントの範囲外です。
An RBridge supporting OAM authentication can be configured to either (1) ignore received OAM Authentication TLVs and not send them, (2) ignore received OAM Authentication TLVs but include them in all OAM packets sent, or (3) to include Authentication TLVs in all OAM messages sent and enforce authentication of OAM messages received. When an RBridge is enforcing authentication, it discards any OAM message subject to OAM processing that does not contain an Authentication TLV or an Authentication TLV does not verify.
OAM認証をサポートするRBridgeは、（1）受信したOAM認証TLVを無視して送信しない、（2）受信したOAM認証TLVを無視して送信するすべてのOAMパケットに含める、または（3）すべてに認証TLVを含めるように構成できます。送信されたOAMメッセージは、受信したOAMメッセージの認証を強制します。 RBridgeが認証を強制しているとき、認証TLVを含まない、または認証TLVが検証しない、OAM処理の対象となるOAMメッセージを破棄します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loopback Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Loopback Message Format
図23：ループバックメッセージの形式
The figure above depicts the format of the Loopback Request and Response messages as defined in [8021Q]. The OpCode for the Loopback Message is set to 3, and the OpCode for the reply message is set to 2 [8021Q]. The Loopback Transaction Identifier (commonly called the Session Identification Number or Session ID in this document) is a 32-bit integer that allows the requesting RBridge to uniquely identify the corresponding session. Responding RBridges, without modification, MUST echo the received "Loopback Transaction Identifier" number.
上の図は、[8021Q]で定義されているループバック要求および応答メッセージのフォーマットを示しています。ループバックメッセージのOpCodeは3に設定され、応答メッセージのOpCodeは2に設定されます[8021Q]。ループバックトランザクション識別子（このドキュメントでは一般にセッション識別番号またはセッションIDと呼ばれます）は32ビットの整数で、要求側のRBridgeが対応するセッションを一意に識別できるようにします。変更せずに応答するRBridgeは、受信した「ループバックトランザクション識別子」番号をエコーする必要があります。
The originator RBridge takes the following actions:
オリジネーターRBridgeは、以下のアクションを実行します。
o Identifies the destination RBridge nickname based on user specification or based on the specified destination MAC or IP address.
o ユーザー指定または指定された宛先MACまたはIPアドレスに基づいて、宛先RBridgeニックネームを識別します。
o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters.
o ユーザー指定のパラメーターまたは実装固有のデフォルトパラメーターに基づいて、フローエントロピーを構築します。
o Constructs the TRILL OAM header: sets the OpCode to Loopback Message type (3) [8021Q]. Assigns applicable Loopback Transaction Identifier number for the request.
o TRILL OAMヘッダーを作成します。OpCodeをループバックメッセージタイプ（3）[8021Q]に設定します。リクエストに適切なループバックトランザクション識別子番号を割り当てます。
o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values.
o TRILL OAMアプリケーション識別子TLVは、適切な値に設定されたフラグに含まれている必要があります。
o Includes following OAM TLVs, where applicable:
o 該当する場合、次のOAM TLVが含まれます。
- Out-of-Band Reply Address TLV
- アウトオブバンド応答アドレスTLV
- Diagnostic Label TLV
- 診断ラベルTLV
- Sender ID TLV
- 送信者ID TLV
o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value.
o ユーザー指定ごとのTRILLデータフレームのホップカウントを指定するか、適用可能なホップカウント値を利用します。
o Dispatches the OAM frame for transmission.
o 送信するOAMフレームをディスパッチします。
RBridges may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each transmission, the Session Identification Number MUST be incremented.
RBridgeは、応答が受信されるか、再送信カウントが期限切れになるまで、定期的な間隔で要求を再送信し続ける場合があります。送信ごとに、セッション識別番号をインクリメントする必要があります。
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.
中間RBridgeは、フレームを通常のデータフレームとして転送します。特別な処理は必要ありません。
If the Loopback Message is addressed to the local RBridge and satisfies the OAM identification criteria specified in Section 3.1, then the RBridge data plane forwards the message to the CPU for further processing.
ループバックメッセージがローカルRBridgeにアドレス指定され、セクション3.1で指定されたOAM識別基準を満たしている場合、RBridgeデータプレーンはメッセージをCPUに転送して、さらに処理します。
The TRILL OAM application layer further validates the received OAM frame by checking for the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAMアプリケーション層は、フローエントロピーの最後にOAM Ethertypeが存在するかどうかをチェックすることにより、受信したOAMフレームをさらに検証します。フローエントロピーの最後にOAM Ethertypeを含まないフレームは破棄する必要があります。
Construction of the TRILL OAM response:
TRILL OAM応答の作成：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message.
o TRILL OAMアプリケーションは、受信したTRILLヘッダーとフローエントロピーを元のデータペイロードTLVにエンコードし、OAMメッセージに含めます。
o Set the Return Code to (1) "Reply" and Return Sub-code to zero (0) "Valid Response". Update the TRILL OAM OpCode to 2 (Loopback Message Reply).
o リターンコードを（1）「返信」に設定し、リターンサブコードをゼロ（0）「有効な応答」に設定します。 TRILL OAM OpCodeを2（ループバックメッセージ応答）に更新します。
o Optionally, if the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the Diagnostic Label TLV, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV.
o オプションで、受信したフローエントロピーのVLAN / FGL識別子の値が診断ラベルTLVで指定された値と異なる場合は、TRILL OAMアプリケーション識別子TLVで「C」フラグ（クロス接続エラー）を設定します。
o Include the Sender ID TLV (1).
o Sender ID TLV（1）を含めます。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 帯域内応答が要求された場合は、要求RBニックネームを出力RBridgeニックネームとして、要求元のRBridgeニックネームを指定してフレームをTRILLデータプレーンにディスパッチします。
o If out-of-band response was requested, dispatch the frame to the IP forwarding process.
o 帯域外応答が要求された場合は、フレームをIP転送プロセスに送信します。
The primary use of the Path Trace Message is for fault isolation. It may also be used for plotting the path taken from a given RBridge to another RBridge.
パストレースメッセージの主な用途は、障害の分離です。また、特定のRBridgeから別のRBridgeへのパスをプロットするためにも使用できます。
[8021Q] accomplishes the objectives of the TRILL Path Trace Message using Link Trace Messages. Link Trace Messages utilize a well-known multicast MAC address. This works for [8021Q] because both the unicast and multicast paths are congruent. However, in TRILL, multicast and unicast are not congruent. Hence, TRILL OAM uses a new message format: the Path Trace Message.
[8021Q]は、リンクトレースメッセージを使用してTRILLパストレースメッセージの目的を達成します。リンクトレースメッセージは、よく知られたマルチキャストMACアドレスを利用します。ユニキャストパスとマルチキャストパスの両方が一致しているため、これは[8021Q]で機能します。ただし、TRILLでは、マルチキャストとユニキャストは合同ではありません。したがって、TRILL OAMは新しいメッセージ形式であるパストレースメッセージを使用します。
The Path Trace Message has the same format as the Loopback Message. The OpCode for Path Trace Reply is 64, and the OpCode for the Path Trace Message is 65.
パストレースメッセージは、ループバックメッセージと同じ形式です。パストレース応答のOpCodeは64で、パストレースメッセージのOpCodeは65です。
Operation of the Path Trace Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop Count field value of 1. The sending RBridge expects an "Intermediate RBridge" Return Sub-code from the next hop or a "Valid response" Return Sub-code response from the destination RBridge. If an "Intermediate RBridge" Return Sub-code is received in the response, the originator RBridge records the information received from the intermediate node that generated the message and resends the message by incrementing the previous Hop Count value by 1. This process is continued until, a response is received from the destination RBridge, a Path Trace process timeout occurs, or the Hop Count reaches a configured maximum value.
パストレースメッセージの操作は、最初にTRILLヘッダーホップカウントフィールドの値が1で送信されることを除いて、ループバックメッセージと同じです。送信RBridgeは、次のホップまたは「有効な」からの「中間RBridge」リターンサブコードを期待します。 response "宛先RBridgeからサブコード応答を返します。 「中間RBridge」リターンサブコードが応答で受信された場合、発信者RBridgeは、メッセージを生成した中間ノードから受信した情報を記録し、以前のホップカウント値を1ずつ増やしてメッセージを再送信します。このプロセスは、 、宛先RBridgeから応答を受信した、パストレースプロセスのタイムアウトが発生した、またはホップカウントが構成された最大値に達した。
The originator RBridge takes the following actions:
オリジネーターRBridgeは、以下のアクションを実行します。
o Identifies the destination RBridge based on user specification or based on location of the specified MAC address.
o ユーザーの指定に基づいて、または指定されたMACアドレスの場所に基づいて、宛先RBridgeを識別します。
o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters.
o ユーザー指定のパラメーターまたは実装固有のデフォルトパラメーターに基づいて、フローエントロピーを構築します。
o Constructs the TRILL OAM header: set the OpCode to Path Trace Message type (65). Assign an applicable Session Identification number for the request. Return Code and Return Sub-code MUST be set to zero.
o TRILL OAMヘッダーを作成します。OpCodeをパストレースメッセージタイプ（65）に設定します。リクエストに適切なセッション識別番号を割り当てます。戻りコードと戻りサブコードはゼロに設定する必要があります。
o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values.
o TRILL OAMアプリケーション識別子TLVは、適切な値に設定されたフラグに含まれている必要があります。
o Includes the following OAM TLVs, where applicable:
o 該当する場合、次のOAM TLVが含まれます。
- Out-of-Band Reply Address TLV
- アウトオブバンド応答アドレスTLV
- Diagnostic Label TLV
- 診断ラベルTLV
- Sender ID TLV
- 送信者ID TLV
o Specifies the Hop Count of the TRILL Data frame as 1 for the first request.
o 最初の要求に対して、TRILLデータフレームのホップカウントを1に指定します。
o Dispatches the OAM frame to the TRILL data plane for transmission.
o OAMフレームをTRILLデータプレーンに送信して送信します。
An RBridge may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each new retransmission, the Session Identification number MUST be incremented. Additionally, for responses received from intermediate RBridges, the RBridge nickname and interface information MUST be recorded.
RBridgeは、応答が受信されるか、再送信カウントが期限切れになるまで、定期的な間隔で要求を再送信し続けます。新しい再送信のたびに、セッション識別番号をインクリメントする必要があります。さらに、中間のRBridgeから受信した応答については、RBridgeのニックネームとインターフェース情報を記録する必要があります。
Path Trace Messages transit through Intermediate RBridges transparently, unless the Hop Count has expired.
パストレースメッセージは、ホップカウントが期限切れにならない限り、中間RBridgeを透過的に通過します。
The TRILL OAM application layer further validates the received OAM frame by examining the presence of the TRILL Alert flag and OAM Ethertype at the end of the Flow Entropy and by examining the MD-Level. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAMアプリケーションレイヤーは、フローエントロピーの最後にあるTRILL AlertフラグとOAM Ethertypeの存在を調べ、MDレベルを調べることで、受信したOAMフレームをさらに検証します。フローエントロピーの最後にOAM Ethertypeを含まないフレームは破棄する必要があります。
Construction of the TRILL OAM response:
TRILL OAM応答の作成：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message.
o TRILL OAMアプリケーションは、受信したTRILLヘッダーとフローエントロピーを元のデータペイロードTLVにエンコードし、OAMメッセージに含めます。
o Set the Return Code to (1) "Reply" and Return Sub-code to two (2) "Intermediate RBridge". Update the TRILL OAM OpCode to 64 (Path Trace Reply).
o リターンコードを（1） "Reply"に設定し、リターンサブコードを2（2） "Intermediate RBridge"に設定します。 TRILL OAM OpCodeを64（パストレース応答）に更新します。
o If the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the diagnostic label, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV.
o 受信したフローエントロピーのVLAN / FGL識別子の値が診断ラベルで指定された値と異なる場合は、TRILL OAMアプリケーション識別子TLVで「C」フラグ（クロス接続エラー）を設定します。
o Include the following TLVs:
o 次のTLVを含めます。
- Previous RBridge Nickname TLV (69)
- 以前のRBridgeニックネームTLV（69）
- Reply Ingress TLV (5)
- 応答イングレスTLV（5）
- Reply Egress TLV (6)
- 応答出力TLV（6）
- Interface Status TLV (4)
- インターフェイスステータスTLV（4）
- Next-Hop RBridge List TLV (70) (Repeat for each ECMP)
- ネクストホップRBridgeリストTLV（70）（各ECMPについて繰り返す）
- Sender ID TLV (1)
- 送信者ID TLV（1）
o If a cross-connect error is detected, set the "C" flag (Cross-Connect Error) in the reply's TRILL OAM Application Identifier TLV.
o 相互接続エラーが検出された場合は、応答のTRILL OAM Application Identifier TLVに「C」フラグ（Cross-Connect Error）を設定します。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 帯域内応答が要求された場合は、要求RBニックネームを出力RBridgeニックネームとして、要求元のRBridgeニックネームを指定してフレームをTRILLデータプレーンにディスパッチします。
o If out-of-band response was requested, dispatch the frame to the standard IP forwarding process.
o 帯域外応答が要求された場合は、フレームを標準のIP転送プロセスにディスパッチします。
Processing is identical to that in Section 10.1.2 with the exception that the TRILL OAM OpCode is set to Path Trace Reply (64).
処理はセクション10.1.2と同じですが、TRILL OAM OpCodeがPath Trace Reply（64）に設定されている点が異なります。
Multi-destination Tree Verification Messages allow verifying TRILL distribution tree integrity and pruning. TRILL VLAN/FGL and multicast pruning are described in [RFC6325], [RFC7180], and [RFC7172]. Multi-destination Tree Verification and Multicast Group Verification Messages are designed to detect pruning defects. Additionally, these tools can be used for plotting a given multicast tree within the TRILL campus.
複数宛先ツリー検証メッセージにより、TRILL配布ツリーの整合性とプルーニングを検証できます。 TRILL VLAN / FGLとマルチキャストプルーニングについては、[RFC6325]、[RFC7180]、および[RFC7172]で説明されています。複数宛先ツリー検証およびマルチキャストグループ検証メッセージは、剪定欠陥を検出するように設計されています。さらに、これらのツールは、TRILLキャンパス内の特定のマルチキャストツリーをプロットするために使用できます。
Multi-destination Tree Verification OAM frames are copied to the CPU of every intermediate RBridge that is part of the distribution tree being verified. The originator of the Multi-destination Tree Verification Message specifies the scope of RBridges from which a response is required. Only the RBridges listed in the scope field respond to the request. Other RBridges silently discard the request. Inclusion of the scope field is required to prevent receiving an excessive number of responses. The typical scenario of distribution tree verification or group verification involves verifying multicast connectivity to a selected set of end nodes as opposed to the entire network. Availability of the scope facilitates narrowing down the focus to only the RBridges of interest.
複数の宛先ツリーの検証OAMフレームは、検証される配布ツリーの一部であるすべての中間RBridgeのCPUにコピーされます。 Multi-destination Tree Verification Messageの発信者は、応答が要求されるRBridgeのスコープを指定します。スコープフィールドにリストされているRBridgeのみが要求に応答します。他のRBridgeは要求を黙って破棄します。過剰な数の応答を受信しないようにするには、スコープフィールドを含める必要があります。配信ツリー検証またはグループ検証の一般的なシナリオには、ネットワーク全体ではなく、選択したエンドノードのセットへのマルチキャスト接続を検証することが含まれます。スコープを利用できるため、関心のあるRBridgeのみに焦点を絞ることができます。
Implementations MAY choose to rate-limit CPU-bound multicast traffic. As a result of rate-limiting or due to other congestion conditions, MTVM messages may be discarded from time to time by the intermediate RBridges, and the requester may be required to retransmit the request. Implementations SHOULD narrow the embedded scope of retransmission requests only to RBridges that have failed to respond.
実装は、CPUにバインドされたマルチキャストトラフィックをレート制限することを選択できます。レート制限の結果として、または他の輻輳状態により、MTVMメッセージは中間のRBridgeによって時々破棄され、リクエスタはリクエストを再送信する必要がある場合があります。実装は、応答に失敗したRBridgeのみに再送要求の埋め込み範囲を狭める必要があります（SHOULD）。
The format of MTVM is identical to the Loopback Message format defined in Section 9 with the exception that the OpCode used is 67.
MTVMのフォーマットは、使用されるOpCodeが67であることを除いて、セクション9で定義されたループバックメッセージフォーマットと同じです。
The user is required, at a minimum, to specify either the distribution trees that need to be verified, the Multicast MAC address and VLAN/FGL, or the VLAN/FGL and Multicast Destination IP address. Alternatively, for more specific multicast flow verification, the user MAY specify more information, e.g., source MAC address, VLAN/FGL, and Destination and Source IP addresses. Implementations, at a minimum, must allow the user to specify a choice of distribution trees, Destination Multicast MAC address, and VLAN/FGL that needs to be verified. Although it is not mandatory, it is highly desired to provide an option to specify the scope. It should be noted that the source MAC address and some other parameters may not be specified if the backwards-compatibility method in Appendix A is used to identify the OAM frames.
ユーザーは、少なくとも、検証が必要な配布ツリー、マルチキャストMACアドレスとVLAN / FGL、またはVLAN / FGLとマルチキャスト宛先IPアドレスのいずれかを指定する必要があります。または、より具体的なマルチキャストフロー検証の場合、ユーザーは、送信元MACアドレス、VLAN / FGL、宛先および送信元IPアドレスなどの詳細情報を指定できます（MAY）。実装では、少なくとも、検証が必要な配信ツリー、宛先マルチキャストMACアドレス、およびVLAN / FGLの選択をユーザーが指定できるようにする必要があります。必須ではありませんが、スコープを指定するオプションを提供することが強く望まれます。付録Aの後方互換性メソッドを使用してOAMフレームを識別する場合、送信元MACアドレスおよび他のいくつかのパラメーターが指定されない場合があることに注意してください。
Default parameters MUST be used for unspecified parameters. Flow Entropy is constructed based on user-specified parameters and/or default parameters.
未指定のパラメーターには、デフォルトのパラメーターを使用する必要があります。フローエントロピーは、ユーザー指定のパラメーターまたはデフォルトパラメーター、あるいはその両方に基づいて構築されます。
Based on user specified parameters, the originating RBridge does the following:
ユーザー指定のパラメーターに基づいて、元のRBridgeは次のことを行います。
o Identifies the nickname that represents the multicast tree.
o マルチキャストツリーを表すニックネームを識別します。
o Obtains the applicable Hop Count value for the selected multicast tree.
o 選択したマルチキャストツリーの該当するホップカウント値を取得します。
o Constructs TRILL OAM message header and includes the Session Identification number. The Session Identification Number facilitates the originator mapping the response to the correct request.
o TRILL OAMメッセージヘッダーを作成し、セッション識別番号を含めます。セッション識別番号は、発信者が応答を正しい要求にマッピングするのに役立ちます。
o Includes the TRILL OAM Application Identifier TLV, which MUST be included.
o TRILL OAM Application Identifier TLVが含まれています。これは必ず含める必要があります。
o Includes the OpCode Multicast Tree Verification Message (67).
o OpCodeマルチキャストツリー検証メッセージ（67）が含まれています。
o Includes RBridge Scope TLV (68).
o RBridge Scope TLV（68）を含みます。
o Optionally, includes the following TLVs, where applicable:
o 必要に応じて、オプションで次のTLVを含めます。
- Out-of-Band IP Address TLV (65)
- アウトオブバンドIPアドレスTLV（65）
- Diagnostic Label TLV (66)
- 診断ラベルTLV（66）
- Sender ID TLV (1)
- 送信者ID TLV（1）
o Specifies the Hop Count of the TRILL Data frame per user specification or alternatively utilizes the applicable Hop Count value if the TRILL Hop Count is not being specified by the user.
o ユーザー指定ごとのTRILLデータフレームのホップカウントを指定します。または、ユーザーがTRILLホップカウントを指定していない場合は、該当するホップカウント値を利用します。
o Dispatches the OAM frame to the TRILL data plane to be ingressed for transmission.
o OAMフレームをTRILLデータプレーンにディスパッチして、送信のために入力します。
The RBridge may continue to retransmit the request at a periodic interval until either a response is received or the retransmission count expires. At each new retransmission, the Session Identification Number MUST be incremented. At each retransmission, the RBridge may further reduce the scope to the RBridges that it has not received a response from.
RBridgeは、応答を受信するか、再送信カウントの期限が切れるまで、定期的な間隔で要求を再送信し続けます。新しい再送信のたびに、セッション識別番号をインクリメントする必要があります。再送信するたびに、RBridgeは、応答を受信していないRBridgeへのスコープをさらに縮小できます。
Receiving RBridges identify multicast verification frames per the procedure explained in Section 3.2.
RBridgeを受信すると、セクション3.2で説明した手順に従ってマルチキャスト検証フレームが識別されます。
The RBridge validates the frame and analyzes the scope RBridge list. If the RBridge Scope TLV is present and the local RBridge nickname is not specified in the scope list, it will silently discard the frame. If the local RBridge is specified in the scope list OR the RBridge Scope TLV is absent, the receiving RBridge proceeds with further processing as defined in Section 11.2.3.
RBridgeはフレームを検証し、スコープRBridgeリストを分析します。 RBridge Scope TLVが存在し、ローカルRBridgeニックネームがスコープリストで指定されていない場合は、サイレントにフレームを破棄します。ローカルRBridgeがスコープリストで指定されている場合、またはRBridge Scope TLVが存在しない場合、受信RBridgeはセクション11.2.3で定義されているようにさらに処理を進めます。
Construction of the TRILL OAM response:
TRILL OAM応答の作成：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes them in the OAM message.
o TRILL OAMアプリケーションは、受信したTRILLヘッダーとフローエントロピーを元のデータペイロードTLVにエンコードし、OAMメッセージに含めます。
o Set the Return Code to zero (0) and Return Sub-code to zero (0). Update the TRILL OAM OpCode to 66 (Multi-destination Tree Verification Reply).
o 戻りコードをゼロ（0）に設定し、戻りサブコードをゼロ（0）に設定します。 TRILL OAM OpCodeを66（Multi-destination Tree Verification Reply）に更新します。
o Include following TLVs:
o 次のTLVを含めます。
- Previous RBridge Nickname TLV (69)
- 以前のRBridgeニックネームTLV（69）
- Reply Ingress TLV (5)
- 応答イングレスTLV（5）
- Interface Status TLV (4)
- インターフェイスステータスTLV（4）
- Next-Hop RBridge List TLV (70)
- ネクストホップRBridgeリストTLV（70）
- Sender ID TLV (1)
- 送信者ID TLV（1）
- Multicast Receiver Port Count TLV (71)
- マルチキャストレシーバーポート数TLV（71）
o If a VLAN/FGL cross-connect error is detected, set the "C" flag (Cross-Connect Error) in the TRILL OAM Application Identifier TLV.
o VLAN / FGLクロスコネクトエラーが検出された場合は、TRILL OAMアプリケーションID TLVの「C」フラグ（クロスコネクトエラー）を設定します。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 帯域内応答が要求された場合は、要求RBニックネームを出力RBridgeニックネームとして、要求元のRBridgeニックネームを指定してフレームをTRILLデータプレーンにディスパッチします。
o If out-of-band response was requested, dispatch the frame to the standard IP forwarding process.
o 帯域外応答が要求された場合は、フレームを標準のIP転送プロセスにディスパッチします。
Section 7 provides an overview of CCM Messages defined in [8021Q] and how they can be used within TRILL OAM. This section presents the application and theory of operations of CCM within the TRILL OAM framework. Readers are referred to [8021Q] for CCM message format and applicable TLV definitions and usages. Only the TRILL-specific aspects are explained below.
セクション7では、[8021Q]で定義されているCCMメッセージの概要と、TRILL OAM内でそれらを使用する方法について説明します。このセクションでは、TRILL OAMフレームワーク内でのCCMの操作のアプリケーションと理論について説明します。読者は、CCMメッセージ形式と該当するTLV定義および使用法について[8021Q]を参照されます。以下では、TRILL固有の側面のみを説明します。
In TRILL, between any two given MEPs, there can be multiple potential paths. Whereas in [8021Q], there is always a single path between any two MEPs at any given time. [RFC6905] requires solutions to have the ability to monitor continuity over one or more paths.
TRILLでは、指定された2つのMEPの間に、複数の潜在的なパスが存在する可能性があります。一方、[8021Q]では、任意の2つのMEP間に常に単一のパスがあります。 [RFC6905]には、1つ以上のパスの連続性を監視する機能を備えたソリューションが必要です。
CCM Messages are uni-directional, such that there is no explicit response to a received CCM message. Connectivity status is indicated by setting the applicable flags (e.g., RDI) of the CCM messages transmitted by a MEP.
CCMメッセージは単方向であるため、受信したCCMメッセージに対する明示的な応答はありません。接続状態は、MEPによって送信されるCCMメッセージの適切なフラグ（RDIなど）を設定することで示されます。
It is important that the solution presented in this document accomplishes the requirements specified in [RFC6905] within the framework of [8021Q] in a straightforward manner and with minimum changes. Section 8 defines multiple flows within the CCM object,
このドキュメントで提示されているソリューションが、[RFC6905]で指定された要件を[8021Q]のフレームワーク内で簡単な方法で最小限の変更で達成することが重要です。セクション8では、CCMオブジェクト内の複数のフローを定義します。
each corresponding to a flow that a given MEP wishes to monitor. Hence, CCM, in multipath environments like TRILL, monitors per-flow connectivity and cross-connect errors.
それぞれが、特定のMEPが監視するフローに対応しています。したがって、CILLはTRILLなどのマルチパス環境で、フローごとの接続とクロスコネクトエラーを監視します。
Receiving MEPs do not cross-check whether a received CCM belongs to a specific flow from the originating RBridge. Any attempt to track status of individual flows may explode the amount of state information that any given RBridge has to maintain.
受信側のMEPは、受信したCCMが発信側のRBridgeからの特定のフローに属しているかどうかをクロスチェックしません。個々のフローのステータスを追跡しようとすると、特定のRBridgeが保持しなければならない状態情報の量が爆発する可能性があります。
The obvious question arises: how does the originating RBridge know which flow or flows are at fault?
明らかな問題が発生します。発信元のRBridgeは、どのフローに障害があるかをどのようにして知るのですか？
This is accomplished with a combination of the RDI flag in the CCM header, Flow Identifier TLV, and SNMP Notifications (Traps). Section 12.1 discusses the procedure.
これは、CCMヘッダーのRDIフラグ、フロー識別子TLV、およびSNMP通知（トラップ）の組み合わせで実現されます。セクション12.1で手順について説明します。
Each MEP transmits four CCM messages per each flow. ([8021Q] detects CCM fault when three consecutive CCM messages are lost). Each CCM message has a unique sequence number (Session ID) and unique flow-identifier. The flow-identifier is included in the OAM message via the Flow Identifier TLV.
各MEPは、フローごとに4つのCCMメッセージを送信します。 （[8021Q]は、3つの連続したCCMメッセージが失われたときにCCM障害を検出します）。各CCMメッセージには、一意のシーケンス番号（セッションID）と一意のフロー識別子があります。フロー識別子は、フロー識別子TLVを介してOAMメッセージに含まれます。
When a MEP notices a CCM timeout from a remote MEP (MEP-A), it sets the RDI flag on the next CCM message it generates. Additionally, it logs and sends an SNMP notification that contains the remote MEP Identification, flow-identifier, and the sequence number of the last CCM message it received, and, if available, the flow-identifier and the sequence number of the first CCM message it received after the failure. Each MEP maintains a unique flow-identifier per each flow; hence, the operator can easily identify flows that correspond to the specific flow-identifier.
MEPは、リモートMEP（MEP-A）からのCCMタイムアウトを認識すると、生成する次のCCMメッセージにRDIフラグを設定します。さらに、リモートMEP識別、フロー識別子、最後に受信したCCMメッセージのシーケンス番号、および利用可能な場合はフロー識別子と最初のCCMメッセージのシーケンス番号を含むSNMP通知をログに記録して送信します。失敗後に受け取った。各MEPは、各フローごとに一意のフロー識別子を維持します。したがって、オペレーターは、特定のフロー識別子に対応するフローを簡単に識別できます。
The following example illustrates the above.
次の例は、上記を示しています。
Assume there are two MEPs: MEP-A and MEP-B.
MEP-AとMEP-Bの2つのMEPがあるとします。
Assume there are three flows between MEP-A and MEP-B.
MEP-AとMEP-Bの間に3つのフローがあると仮定します。
Let's assume MEP-A allocates sequence numbers as follows:
MEP-Aがシーケンス番号を次のように割り当てると仮定します。
Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-identifier=(1)
Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-identifier=(2)
Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-identifier=(3)
Let's assume Flow-2 is at fault.
Flow-2に問題があると仮定しましょう。
MEP-B receives CCM from MEP-A with sequence numbers 1, 2, 3, and 4 but did not receive 5, 6, 7, and 8. CCM timeout is set to three CCM intervals in [8021Q]. Hence, MEP-B detects the error at the 8th CCM message. At this time, the sequence number of the last good CCM message MEP-B has received from MEP-A is 4, and the flow-identifier of the last good CCM Message is (1). Hence, MEP-B will generate a CCM error SNMP notification with MEP-A, last good flow-identifier (1), and sequence number 4.
MEP-Bは、MEP-Aからシーケンス番号1、2、3、および4でCCMを受信しますが、5、6、7、および8を受信しませんでした。CCMタイムアウトは、[8021Q]で3つのCCM間隔に設定されています。したがって、MEP-Bは8番目のCCMメッセージでエラーを検出します。このとき、MEP-BがMEP-Aから受信した最後の適切なCCMメッセージのシーケンス番号は4であり、最後の適切なCCMメッセージのフロー識別子は（1）です。したがって、MEP-Bは、MEP-A、最後の適切なフロー識別子（1）、およびシーケンス番号4を使用してCCMエラーSNMP通知を生成します。
When MEP-A switches to Flow-3 after transmitting Flow-2, MEP-B will start receiving CCM messages. In the foregoing example, it will be a CCM message with sequence numbers 9, 10, 11, 12, and 21 and so on. When in receipt of a new CCM message from a specific MEP, after a CCM timeout, the TRILL OAM will generate an SNMP Notification of CCM resume with remote MEP-ID, the first valid flow-identifier, and the sequence number after the CCM timeout. In the foregoing example, it is MEP-A, flow-identifier (3), and sequence number 9.
MEP-AがFlow-2の送信後にFlow-3に切り替えると、MEP-BはCCMメッセージの受信を開始します。前述の例では、シーケンス番号が9、10、11、12、21などのCCMメッセージになります。特定のMEPから新しいCCMメッセージを受信すると、CCMタイムアウト後、TRILL OAMはCCM再開のSNMP通知を生成し、リモートMEP-ID、最初の有効なフロー識別子、CCMタイムアウト後のシーケンス番号を使用します。 。前述の例では、MEP-A、フローID（3）、シーケンス番号9です。
The remote MEP list under the CCM MIB Object is augmented to contain "Last Sequence Number", flow-identifier, and "CCM Timeout" variables. "Last Sequence Number" and flow-identifier are updated every time a CCM is received from a remote MEP. The CCM Timeout variable is set when the CCM timeout occurs and is cleared when a CCM is received.
CCM MIBオブジェクトの下のリモートMEPリストは、「最後のシーケンス番号」、フロー識別子、および「CCMタイムアウト」変数を含むように拡張されています。 「最後のシーケンス番号」とフロー識別子は、リモートMEPからCCMを受信するたびに更新されます。 CCMタイムアウト変数は、CCMタイムアウトが発生すると設定され、CCMを受信するとクリアされます。
The originator RBridge takes the following actions:
オリジネーターRBridgeは、以下のアクションを実行します。
o Derives the Flow Entropy field based on flow-entropy information specified in the CCM Management object.
o CCM管理オブジェクトで指定されたフローエントロピー情報に基づいて、フローエントロピーフィールドを導出します。
o Constructs the TRILL CCM OAM header as specified in [8021Q].
o [8021Q]で指定されているようにTRILL CCM OAMヘッダーを作成します。
o The TRILL OAM Application Identifier TLV MUST be included as the first TLV with the flags set to applicable values.
o TRILL OAMアプリケーション識別子TLVは、フラグを適切な値に設定した最初のTLVとして含める必要があります。
o Includes other TLVs specified in [8021Q].
o [8021Q]で指定された他のTLVを含みます。
o Includes the following optional TLV, where applicable:
o 該当する場合、次のオプションのTLVが含まれます。
- Sender ID TLV (1)
- 送信者ID TLV（1）
o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value.
o ユーザー指定ごとのTRILLデータフレームのホップカウントを指定するか、適用可能なホップカウント値を利用します。
o Dispatches the OAM frame to the TRILL data plane for transmission.
o OAMフレームをTRILLデータプレーンに送信して送信します。
An RBridge transmits a total of four requests, each at CCM retransmission interval. At each transmission, the Session Identification number MUST be incremented by one.
RBridgeは、それぞれがCCM再送信間隔で合計4つの要求を送信します。送信のたびに、セッション識別番号を1ずつ増やす必要があります。
At the 5th retransmission interval, the Flow Entropy of the CCM packet is updated to the next flow-entropy information specified in the CCM Management object. If the current Flow Entropy is the last Flow Entropy specified, move to the first Flow Entropy specified and continue the process.
5番目の再送信間隔で、CCMパケットのフローエントロピーは、CCM管理オブジェクトで指定された次のフローエントロピー情報に更新されます。現在のフローエントロピーが最後に指定されたフローエントロピーである場合は、最初に指定されたフローエントロピーに移動して、プロセスを続行します。
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.
中間RBridgeは、フレームを通常のデータフレームとして転送します。特別な処理は必要ありません。
If the CCM Message is addressed to the local RBridge or multicast and satisfies the OAM identification methods specified in Section 3.2, then the RBridge data plane forwards the message to the CPU for further processing.
CCMメッセージがローカルのRBridgeまたはマルチキャストにアドレス指定され、セクション3.2で指定されたOAM識別メソッドを満たしている場合、RBridgeデータプレーンは、CPUにメッセージを転送してさらに処理します。
The TRILL OAM application layer further validates the received OAM frame by examining the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAMアプリケーション層は、フローエントロピーの最後にOAM Ethertypeが存在するかどうかを調べることにより、受信したOAMフレームをさらに検証します。フローエントロピーの最後にOAM Ethertypeを含まないフレームは破棄する必要があります。
The TRILL OAM application layer then validates the MD-Level and pass the packet to the OpCode demultiplexer. The OpCode demultiplexer delivers CCM packets to the CCM process.
次にTRILL OAMアプリケーションレイヤーはMDレベルを検証し、パケットをOpCodeデマルチプレクサに渡します。 OpCodeデマルチプレクサは、CCMパケットをCCMプロセスに配信します。
The CCM process performs the processing specified in [8021Q].
CCMプロセスは、[8021Q]で指定された処理を実行します。
Additionally, the CCM process updates the CCM Management object with the sequence number of the received CCM packet. Note: The last received CCM sequence number and CCM timeout are tracked per each remote MEP.
さらに、CCMプロセスは、受信したCCMパケットのシーケンス番号でCCM管理オブジェクトを更新します。注：最後に受信したCCMシーケンス番号とCCMタイムアウトは、各リモートMEPごとに追跡されます。
If the CCM timeout is true for the sending remote MEP, then clear the CCM timeout in the CCM Management object and generate the SNMP notification as specified above.
送信側リモートMEPのCCMタイムアウトがtrueの場合、CCM管理オブジェクトのCCMタイムアウトをクリアし、上記のようにSNMP通知を生成します。
TRILL OAM allows fragmented reply messages. In case of fragmented replies, all parts of the reply MUST follow the procedure defined in this section.
TRILL OAMは、フラグメント化された応答メッセージを許可します。断片化された応答の場合、応答のすべての部分は、このセクションで定義されている手順に従う必要があります。
The same Session Identification Number MUST be included in all related fragments of the same message.
同じセッション識別番号は、同じメッセージの関連するすべてのフラグメントに含まれている必要があります。
The TRILL OAM Application Identifier TLV MUST be included, with the Fragment-ID field monotonically increasing with each fragment transmitted with the appropriate Final flag field. The Final flag MUST only be equal to one on the final fragment of the reply.
TRILL OAMアプリケーション識別子TLVを含める必要があります。フラグメントIDフィールドは、適切な最終フラグフィールドで送信される各フラグメントとともに単調に増加します。最終フラグは、応答の最終フラグメントで1にのみ等しい必要があります。
On the receiver, the process MUST order the fragments based on the Fragment-ID. Any fragments received after the final fragment MUST be discarded. Messages with incomplete fragments (i.e., messages with one or missing fragments after the receipt of the fragment with the final flag set) MUST be discarded as well.
レシーバーでは、プロセスはフラグメントIDに基づいてフラグメントを順序付けする必要があります。最後のフラグメントの後に受信されたフラグメントは破棄されなければなりません（MUST）。不完全なフラグメントを含むメッセージ（つまり、最後のフラグが設定されたフラグメントの受信後にフラグメントが1つまたは欠落しているメッセージ）も破棄する必要があります。
If the number of fragments exceeds the maximum supported fragments (255), then the Return Code of the reply message MUST be set to 1 (Reply message), and the Return Sub-code MUST be set to 1 (Fragment limit exceeded).
フラグメントの数がサポートされる最大フラグメント（255）を超える場合、応答メッセージの戻りコードを1（応答メッセージ）に設定する必要があり、戻りサブコードを1（フラグメント制限を超える）に設定する必要があります。
Forged OAM packets could cause false error or failure indications, mask actual errors or failures, or be used for denial of service. Source addresses for messages can be forged and the out-of-band reply facility (see Section 8.4.4) provides for explicitly supplying the address for replies. For protection against forged OAM packets, the Authentication TLV (see Section 8.4.13) can be used in an OAM message in TRILL. This TLV is virtually identical to the IS-IS Authentication TLV specified in [IS-IS] and depends on IS-IS keying material and the current state of IS-IS keying as discussed in [KARPISIS] and [RFC5310]. In particular, there is currently no standardized IS-IS automated key management.
偽造されたOAMパケットは、誤ったエラーまたは障害の表示を引き起こしたり、実際のエラーまたは障害をマスクしたり、サービス拒否に使用されたりする可能性があります。メッセージの送信元アドレスは偽造される可能性があり、帯域外応答機能（セクション8.4.4を参照）は、応答用のアドレスを明示的に提供することを提供します。偽造されたOAMパケットに対する保護のために、認証TLV（セクション8.4.13を参照）をTRILLのOAMメッセージで使用できます。このTLVは、[IS-IS]で指定されているIS-IS認証TLVと実質的に同じであり、IS-ISキーイングマテリアルと、[KARPISIS]および[RFC5310]で説明されているIS-ISキーイングの現在の状態に依存します。特に、現在、標準化されたIS-IS自動キー管理はありません。
Of course, authentication is ineffective unless verified and ineffective against senders who have the keying material needed to produce OAM messages that will pass authentication checks. Implementations MUST implement rate-limiting functionality to protect against exploitation of OAM messages as a means of denial-of-service attacks. Aggressive rate-limiting may trigger false positive errors against CCM and LBM-based session monitoring.
もちろん、認証は検証されない限り無効であり、認証チェックに合格するOAMメッセージを生成するために必要なキー情報を持っている送信者に対して無効です。実装は、サービス拒否攻撃の手段としてOAMメッセージの悪用を防ぐためにレート制限機能を実装する必要があります。積極的なレート制限により、CCMおよびLBMベースのセッションモニタリングに対して誤検知エラーがトリガーされる場合があります。
Even with authentication, replay of authenticated messages may be possible. There are four types of messages: Continuity Check (CCM), Loopback, Path Trace, and Multi-destination Tree Verification (MTVM). In the case of CCM messages, sequence numbers are required (see Section 12.1) that can protect against replay. In the case of Loopback Messages (see Section 9.1), a Loopback Transaction Identifier is included that, as required by [8021Q], is incremented with each transmission and can detect replays. PTMs (see Section 10) and MTVMs (see Section 11.1) are specified to have the same format as Loopback Messages (although with different OpCodes), so they also have an identifier incremented with each transmission that can detect replays. Thus, all TRILL OAM messages have a field that can be used for replay protection.
認証があっても、認証されたメッセージの再生が可能な場合があります。メッセージには、連続性チェック（CCM）、ループバック、パストレース、およびマルチ宛先ツリー検証（MTVM）の4つのタイプがあります。 CCMメッセージの場合、再生から保護できるシーケンス番号が必要です（セクション12.1を参照）。ループバックメッセージ（セクション9.1を参照）の場合、ループバックトランザクション識別子が含まれます。これは、[8021Q]での必要に応じて、送信ごとに増分され、リプレイを検出できます。 PTM（セクション10を参照）およびMTVM（セクション11.1を参照）は、ループバックメッセージ（異なるOpCodeを使用）と同じフォーマットを持つように指定されているため、リプレイを検出できるように、送信ごとに識別子が増分されます。したがって、すべてのTRILL OAMメッセージには、リプレイ保護に使用できるフィールドがあります。
For general TRILL-related security considerations, please refer to [RFC6325].
TRILL関連の一般的なセキュリティの考慮事項については、[RFC6325]を参照してください。
[8021Q] requires that the MEP filters or passes through OAM messages based on the MD-Level. The MD-Level is embedded deep in the OAM message. Hence, conventional methods of frame filtering may not be able to filter frames based on the MD-Level. As a result, OAM messages that must be dropped due to MD-Level mismatch may leak into a TRILL domain with a different MD-Level.
[8021Q]は、MEPがMDレベルに基づいてOAMメッセージをフィルタリングまたは通過させることを要求します。 MDレベルはOAMメッセージの奥深くに埋め込まれています。したがって、フレームフィルタリングの従来の方法では、MDレベルに基づいてフレームをフィルタリングできない場合があります。その結果、MDレベルの不一致のためにドロップする必要があるOAMメッセージが、別のMDレベルのTRILLドメインにリークする可能性があります。
This leaking may not cause any functionality loss. The receiving MEP/MIP is required to validate the MD-level prior to acting on the message. Any frames received with an incorrect MD-Level need to be dropped.
このリークにより、機能が失われることはありません。受信側のMEP / MIPは、メッセージを操作する前にMDレベルを検証する必要があります。不正なMDレベルで受信されたフレームはすべてドロップする必要があります。
Generally, a single operator manages each TRILL campus; hence, there is no risk of security exposure. However, in the event of multi-operator deployments, operators should be aware of possible exposure of device-specific information, and appropriate measures must be taken.
通常、1人のオペレーターが各TRILLキャンパスを管理します。したがって、機密漏れのリスクはありません。ただし、複数のオペレーターが配備されている場合、オペレーターはデバイス固有の情報が公開される可能性があることを認識し、適切な対策を講じる必要があります。
It is also important to note that the MPLS OAM framework [RFC4379] does not include the concept of domains and OAM filtering based on operators. It is our opinion that the lack of OAM frame filtering based on domains does not introduce significant functional deficiency or security risk.
また、MPLS OAMフレームワーク[RFC4379]には、ドメインの概念とオペレーターに基づくOAMフィルタリングが含まれていないことに注意することも重要です。ドメインに基づいたOAMフレームフィルタリングの欠如は、重大な機能的欠陥やセキュリティリスクをもたらさないと私たちは考えています。
It is possible to mandate requiring different credentials to use different OAM functions or capabilities within a specific OAM function. Implementations may consider grouping users to different security clearance levels and restricting functions and capabilities to different clearance levels. However, exact implementation details of such a framework are outside the scope of this document.
特定のOAM機能内でさまざまなOAM機能または機能を使用するために、さまざまな資格情報を要求することを義務付けることができます。実装では、ユーザーをさまざまなセキュリティクリアランスレベルにグループ化し、機能と機能をさまざまなクリアランスレベルに制限することを検討します。ただし、そのようなフレームワークの正確な実装の詳細は、このドキュメントの範囲外です。
IANA has made the assignments described below.
IANAは、以下に説明する割り当てを行いました。
Two TRILL-VER sub-TLV Capability Flags (see Section 3.3) have been assigned as follows:
2つのTRILL-VERサブTLV機能フラグ（セクション3.3を参照）は、次のように割り当てられています。
Bit Description Reference
--- ----------- ---------
2 OAM capable RFC 7455
3 Backwards-compatible OAM RFC 7455
Four OpCodes have been assigned from the "CFM OAM IETF OpCodes" sub-registry as follows:
次のように、「CFM OAM IETF OpCodes」サブレジストリから4つのOpCodeが割り当てられています。
Value Assignment Reference
----- ---------- ---------
64 Path Trace Reply RFC 7455
65 Path Trace Message RFC 7455
66 Multi-destination Tree Verification Reply RFC 7455
67 Multi-destination Tree Verification Message RFC 7455
Eleven TLV Types have been assigned from the "CFM OAM IETF TLV Types" sub-registry as follows:
「CFM OAM IETF TLVタイプ」サブレジストリから次のように11のTLVタイプが割り当てられています。
Value Assignment Reference
----- ---------- ---------
64 TRILL OAM Application Identifier TLV RFC 7455
65 Out-of-Band Reply Address TLV RFC 7455
66 Diagnostic Label TLV RFC 7455
67 Original Data Payload TLV RFC 7455
68 RBridge Scope TLV RFC 7455
69 Previous RBridge Nickname TLV RFC 7455
70 Next-Hop RBridge List TLV RFC 7455
71 Multicast Receiver Port Count TLV RFC 7455
72 Flow Identifier TLV RFC 7455
73 Reflector Entropy TLV RFC 7455
74 Authentication TLV RFC 7455
IANA has assigned a unicast and a multicast MAC address under the IANA Organizationally Unique Identifier (OUI) for identification of OAM packets as discussed for the backwards-compatibility method (Appendix A.2) and based on the request template in Appendix C. The assigned addresses are 00-00-5E-90-01-00 (unicast) and 01-00-5E-90-01-00 (multicast).
IANAは、下位互換性の方法（付録A.2）で説明されているように、付録Cの要求テンプレートに基づいて、OAMパケットの識別のためにIANA組織固有識別子（OUI）の下でユニキャストおよびマルチキャストMACアドレスを割り当てました。アドレスは00-00-5E-90-01-00（ユニキャスト）および01-00-5E-90-01-00（マルチキャスト）です。
IANA has created the "TRILL OAM Return Codes" registry within the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry and a separate sub-code sub-registry for each Return Code as shown below:
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリ内に「TRILL OAMリターンコード」レジストリを作成し、以下に示すように、各リターンコードに対して個別のサブコードサブレジストリを作成しました。
Registry: TRILL OAM Return Codes
レジストリ：TRILL OAMの戻りコード
Registration Procedure: Standards Action
登録手順：標準アクション
Return Code Assignment References
----------- ---------- ----------
0 Request message RFC 7455
1 Reply message RFC 7455
2-255 Unassigned RFC 7455
Sub-Registry: Sub-codes for TRILL OAM Return Code 0
サブレジストリ：TRILL OAM戻りコード0のサブコード
Registration Procedure: Standards Action
登録手順：標準アクション
Sub-code Assignment References
-------- ---------- ----------
0 Valid request RFC 7455
1-255 Unassigned RFC 7455
Sub-Registry: Sub-codes for TRILL OAM Return Code 1
サブレジストリ：TRILL OAM戻りコード1のサブコード
Registration Procedure: Standards Action
登録手順：標準アクション
Sub-code Assignment References
-------- ---------- ----------
0 Valid response RFC 7455
1 Fragment limit exceeded RFC 7455
2 Intermediate RBridge RFC 7455
3-255 Unassigned RFC 7455
IANA has allocated 16396 as the Address Family Number for TRILL nickname.
IANAは、TRILLニックネームのアドレスファミリー番号として16396を割り当てました。
[8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014.
[8021Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q、2014年12月。
[IS-IS] ISO/IEC, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS] ISO / IEC、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル（ ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月、<http ：//www.rfc-editor.org/info/rfc5310>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S.、and A. Ghanwani、 "Routing Bridges（RBridges）：Base Protocol Specification"、RFC 6325、July 2011、<http： //www.rfc-editor.org/info/rfc6325>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、May 2014、<http://www.rfc-editor.org/info/rfc7172>。
[KARPISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, draft-ietf-karp-isis-analysis-04, March 2015.
[KARPISIS] Chunduri、U.、Tian、A。、およびW. Lu、「KARP IS-ISセキュリティ分析」、Work in Progress、draft-ietf-karp-isis-analysis-04、2015年3月。
[RFC4379] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4379] Eronen、P.、Ed。およびH. Tschofenig、Ed。、 "Pre-Shared Key Ciphersuites for Transport Layer Security（TLS）"、RFC 4279、December 2005、<http：//www.rfc-editor .org / info / rfc4279>。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011, <http://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、2011年6月、<http://www.rfc-editor.org/info/rfc6291>。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361] Carlson、J.およびD. Eastlake 3rd、 "PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol"、RFC 6361、August 2011、<http://www.rfc-editor.org/info/ rfc6361>。
[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013, <http://www.rfc-editor.org/info/rfc6905>.
[RFC6905] Senevirathne、T.、Bond、D.、Aldrin、S.、Li、Y.、and R. Watve、Requirements for Operations、Administration、and Maintenance（OAM）in Transparent Interconnection of Links of Links（TRILL） "、RFC 6905、2013年3月、<http://www.rfc-editor.org/info/rfc6905>。
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
[RFC7174] Salam、S.、Senevirathne、T.、Aldrin、S。、およびD. Eastlake、第3回、「リンクの透過的な相互接続（TRILL）運用、管理、および保守（OAM）フレームワーク」、RFC 7174、5月2014、<http://www.rfc-editor.org/info/rfc7174>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、May 2014、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、May 2014 、<http://www.rfc-editor.org/info/rfc7178>。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>.
[RFC7179] Eastlake 3rd、D.、Ghanwani、A.、Manral、V.、Li、Y.、and C. Bestler、 "Transparent Interconnection of Lots of Links（TRILL）：Header Extension"、RFC 7179、May 2014、 <http://www.rfc-editor.org/info/rfc7179>。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、2014年5月、<http://www.rfc-editor.org/info/rfc7180>。
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, March 2015, <http://www.rfc-editor.org/info/rfc7456>.
[RFC7456] Mizrahi、T.、Senevirathne、T.、Salam、S.、Kumar、D。、およびD. Eastlake 3度、「リンクの透過的相互接続（TRILL）における損失と遅延の測定」、RFC 7456、3月2015、<http://www.rfc-editor.org/info/rfc7456>。
[TRILLOAMMIB] Kumar, D., Salam, S., and T. Senevirathne, "TRILL OAM MIB", Work in Progress, draft-deepak-trill-oam-mib-01, October 2013.
[TRILLOAMMIB] Kumar、D.、Salam、S。、およびT. Senevirathne、「TRILL OAM MIB」、作業中、draft-deepak-trill-oam-mib-01、2013年10月。
[Y1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
[Y1731] ITU-T、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T勧告G.8013 / Y.1731、2013年11月。
The methodology presented in this document is in-line with the framework defined in [8021Q] for providing fault management coverage. However, in practice, some TRILL platforms may not have the capabilities to support some of the required techniques. In this appendix, we present a method that allows RBridges, which do not have the required hardware capabilities, to participate in the TRILL OAM solution.
このドキュメントで提示されている方法論は、障害管理カバレッジを提供するために[8021Q]で定義されたフレームワークと一致しています。ただし、実際には、一部のTRILLプラットフォームには、必要な技術の一部をサポートする機能がない場合があります。この付録では、必要なハードウェア機能を持たないRBridgeがTRILL OAMソリューションに参加できるようにする方法を示します。
There are two broad areas to be considered: 1) the Maintenance Point (MEP/MIP) Model and 2) data-plane encoding and frame identification.
考慮すべき2つの広範な領域があります。1）メンテナンスポイント（MEP / MIP）モデルと、2）データプレーンエンコーディングとフレーム識別です。
For backwards compatibility, MEPs and MIPs are located in the CPU. This will be referred to as the "central brain" model as opposed to "port brain" model.
下位互換性のために、MEPとMIPはCPUに配置されています。これは、「ポートブレイン」モデルではなく、「セントラルブレイン」モデルと呼ばれます。
In the "central brain" model, an RBridge using either Access Control Lists (ACLs) or some other method forwards qualifying OAM messages to the CPU. The CPU then performs the required processing and multiplexing to the correct MP (Maintenance Point).
「中央脳」モデルでは、アクセス制御リスト（ACL）またはその他の方法を使用するRBridgeが、適格なOAMメッセージをCPUに転送します。次に、CPUは必要な処理と正しいMP（Maintenance Point）への多重化を実行します。
Additionally, RBridges MUST have the capability to prevent the leaking of OAM packets, as specified in [RFC6905].
さらに、RBridgesは、[RFC6905]で指定されているように、OAMパケットのリークを防止する機能を持っている必要があります。
The backwards-compatibility method presented in this section defines methods to identify OAM frames when implementations do not have capabilities to utilize the TRILL OAM Alert flag presented earlier in this document to identify OAM frames in the hardware.
このセクションで説明する下位互換性メソッドは、このドキュメントで前述したTRILL OAMアラートフラグを利用してハードウェアのOAMフレームを特定する機能が実装にない場合に、OAMフレームを特定するメソッドを定義します。
It is assumed that ECMP path selection of non-IP flows utilizes MAC DA, MAC SA, and VLAN; IP flows utilize IP DA, IP SA, TCP/UDP port numbers, and other Layer 3 and Layer 4 information. The well-known fields to identify OAM flows are chosen such that they mimic the ECMP selection of the actual data along the path. However, it is important to note that there may be implementations that would utilize these well-known fields for ECMP selections. Hence, implementations that support OAM SHOULD move to utilizing the TRILL Alert flag, as soon as possible, and methods presented here SHOULD be used only as an interim solution.
非IPフローのECMPパス選択はMAC DA、MAC SA、およびVLANを利用すると想定されています。 IPフローは、IP DA、IP SA、TCP / UDPポート番号、およびその他のレイヤー3およびレイヤー4情報を利用します。 OAMフローを識別するための既知のフィールドは、パスに沿った実際のデータのECMP選択を模倣するように選択されます。ただし、これらのよく知られたフィールドをECMPの選択に利用する実装が存在する可能性があることに注意することが重要です。したがって、OAMをサポートする実装は、できるだけ早くTRILL Alertフラグを使用するように移行する必要があり（SHOULD）、ここに示すメソッドは暫定的なソリューションとしてのみ使用する必要があります（SHOULD）。
Identification methods are divided in to four broader groups:
識別方法は、4つの広いグループに分けられます。
1. Identification of Unicast non-IP OAM Flows,
1. ユニキャスト非IP OAMフローの識別、
2. Identification of Multicast non-IP OAM Flows,
2. マルチキャスト非IP OAMフローの識別、
3. Identification of Unicast IP OAM Flows, and
3. ユニキャストIP OAMフローの識別、および
4. Identification of Multicast IP OAM Flows.
4. マルチキャストIP OAMフローの識別。
As presented in Figure 24, based on the flow type (as defined above), implementations are required to use a well-known value in either the Inner.MacSA field or OAM Ethertype field to identify OAM flows.
図24に示すように、フロータイプ（上記で定義）に基づいて、実装はInner.MacSAフィールドまたはOAM Ethertypeフィールドの既知の値を使用してOAMフローを識別する必要があります。
A receiving RBridge identifies OAM flows based on the presence of the well-known values in the specified fields. Additionally, for unicast flows, the egress RBridge nickname of the packet MUST match that of the local RBridge, or for multicast flows, the TRILL Header multicast ("M") flag MUST be set.
受信RBridgeは、指定されたフィールド内の既知の値の存在に基づいてOAMフローを識別します。さらに、ユニキャストフローの場合、パケットの出力RBridgeニックネームはローカルRBridgeのニックネームと一致する必要があります。または、マルチキャストフローの場合、TRILLヘッダーマルチキャスト（ "M"）フラグを設定する必要があります。
Unicast OAM flows that qualify for local processing MUST be redirected to the OAM process and MUST NOT be forwarded (to prevent leaking of the packet out of the TRILL campus).
ローカル処理に適格なユニキャストOAMフローは、OAMプロセスにリダイレクトする必要があり、転送しないでください（TRILLキャンパスからのパケットの漏洩を防ぐため）。
A copy of multicast OAM flows that qualify for local processing MUST be sent to the OAM process, and the packets MUST be forwarded along the normal path. Additionally, methods MUST be in place to prevent multicast packets from leaking out of the TRILL campus.
ローカル処理に適格なマルチキャストOAMフローのコピーをOAMプロセスに送信する必要があり、パケットは通常のパスに沿って転送する必要があります。さらに、マルチキャストパケットがTRILLキャンパスの外に漏洩するのを防ぐためのメソッドを配置する必要があります。
Figure 24 summarizes the identification of different OAM frames from data frames.
図24は、データフレームからのさまざまなOAMフレームの識別を要約しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Entropy |Inner.MacSA |OAM Ethertype |Egress |
| | | |nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Unicast no IP | N/A |Match |Match |
| | | | |
|Multicast no IP| N/A |Match |N/A |
| | | | |
|Unicast IP | Match |N/A |Match |
| | | | |
|Multicast IP | Match |N/A |N/A |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Identification of TRILL OAM Frames
図24：TRILL OAMフレームの識別
The unicast and multicast Inner.MacSAs used for the unicast and multicast IP cases, respectively, are 00-00-5E-90-01-00 and 01-00-5E-90-01-00. These have been assigned per the request in Appendix C.
ユニキャストIPケースとマルチキャストIPケースでそれぞれ使用されるユニキャストとマルチキャストのInner.MacSAは、00-00-5E-90-01-00と01-00-5E-90-01-00です。これらは、付録Cの要求に従って割り当てられています。
It is important to note that all RBridges MUST generate OAM flows with the "A" flag set and CFM Ethertype "0x8902" at the Flow Entropy off-set. However, well-known values MUST be utilized as part of the flow-entropy when generating OAM messages destined for older RBridges that are compliant to the backwards-compatibility method defined in this appendix.
すべてのRBridgeは、「A」フラグセットとCFM Ethertype「0x8902」をフローエントロピーオフセットで設定してOAMフローを生成する必要があることに注意することが重要です。ただし、この付録で定義されている後方互換性メソッドに準拠する古いRBridge宛てのOAMメッセージを生成する場合、既知の値をフローエントロピーの一部として使用する必要があります。
CFM, as defined in [8021Q], requires configuration of several parameters before the protocol can be used. These parameters include MAID, Maintenance Domain Level (MD-Level), and MEP-IDs. The Base Mode for TRILL OAM defined here facilitates ease of use and provides out-of-the-box plug-and-play capabilities, supporting the operational and manageability considerations described in Section 6 of [RFC7174].
[8021Q]で定義されているCFMでは、プロトコルを使用する前に、いくつかのパラメータの設定が必要です。これらのパラメーターには、MAID、メンテナンスドメインレベル（MDレベル）、およびMEP-IDが含まれます。ここで定義されているTRILL OAMの基本モードは、使いやすさを促進し、すぐに使用できるプラグアンドプレイ機能を提供し、[RFC7174]のセクション6で説明されている運用と管理の考慮事項をサポートします。
All RBridges that support TRILL OAM MUST support the Base Mode operation.
TRILL OAMをサポートするすべてのRBridgeは、ベースモード操作をサポートする必要があります。
All RBridges MUST create a default MA with MAID as specified herein.
すべてのRBridgeは、ここで指定されたMAIDでデフォルトのMAを作成する必要があります。
MAID [8021Q] has a flexible format and includes two parts: Maintenance Domain Name and Short MA Name. In the Base Mode operation, the value of the Maintenance Domain Name must be the character string "TrillBaseMode" (excluding the quotes). In the Base Mode operation, the Short MA Name format is set to a 2-octet integer format (value 3 in Short MA Format field) and Short MA Name set to 65532 (0xFFFC).
MAID [8021Q]の形式は柔軟で、2つの部分（メンテナンスドメイン名と短いMA名）が含まれています。基本モード操作では、メンテナンスドメイン名の値は文字列「TrillBaseMode」（引用符を除く）でなければなりません。基本モード操作では、ショートMA名のフォーマットは2オクテット整数フォーマット（ショートMAフォーマットフィールドの値3）に設定され、ショートMA名は65532（0xFFFC）に設定されます。
The default MA belongs to MD-Level 3.
デフォルトのMAはMDレベル3に属しています。
In the Base Mode of operation, each RBridge creates a single UP MEP associated with a virtual OAM port with no physical layer (NULL PHY). The MEP-ID associated with this MEP is the 2-octet RBridge nickname.
基本動作モードでは、各RBridgeは、物理層なし（NULL PHY）の仮想OAMポートに関連付けられた単一のUP MEPを作成します。このMEPに関連付けられたMEP-IDは、2オクテットのRBridgeニックネームです。
By default, all RBridges operating in Base Mode for TRILL OAM are able to initiate LBM, PTM, and other OAM tools with no configuration.
デフォルトでは、TRILL OAMの基本モードで動作しているすべてのRBridgeは、設定なしでLBM、PTM、およびその他のOAMツールを開始できます。
Implementations MAY provide default flow-entropy to be included in OAM messages. Content of the default flow-entropy is outside the scope of this document.
実装は、OAMメッセージに含まれるデフォルトのフローエントロピーを提供する場合があります。デフォルトのフローエントロピーの内容は、このドキュメントの範囲外です。
Figure 25 depicts encoding of MAID within CCM messages.
図25は、CCMメッセージ内のMAIDのエンコードを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Field Name |Size |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 1 |
|Domain Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 2 |
|Domain Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | variable|
|Domain Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 1 |
|Name Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 2 |
|Name Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | variable|
|Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Padding | Variable|
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: MAID Structure as Defined in [8021Q]
図25：[8021Q]で定義されたMAID構造
Maintenance Domain Name Format: set to value 4
メンテナンスドメイン名の形式：値4に設定
Maintenance Domain Name Length: set to value 13
メンテナンスドメイン名の長さ：値13に設定
Maintenance Domain Name: set to TrillBaseMode
メンテナンスドメイン名：TrillBaseModeに設定
Short MA Name Format: set to value 3
短いMA名の形式：値3に設定
Short MA Name Length: set to value 2
短いMA名の長さ：値2に設定
Short MA Name: set to FFFC
短いMA名：FFFCに設定
Padding: set of zero up to 48 octets of total length of the MAID
パディング：MAIDの全長のゼロから最大48オクテットのセット
Please refer to [8021Q] for details.
詳細は【8021Q】をご参照ください。
Applicant Name: IETF TRILL Working Group
申請者名：IETF TRILLワーキンググループ
Applicant Email: tsenevir@cisco.com
申請者のメール：tsenevir@cisco.com
Applicant Telephone: +1-408-853-2291
申請者の電話番号：+ 1-408-853-2291
Use Name: TRILL OAM
名前を使用：TRILL OAM
Document: RFC 7455
ドキュメント：RFC 7455
Specify whether this is an application for EUI-48 or EUI-64 identifiers: EUI-48
これがEUI-48またはEUI-64識別子のアプリケーションかどうかを指定します：EUI-48
Size of Block requested: 1
要求されたブロックのサイズ：1
Specify multicast, unicast, or both: Both
マルチキャスト、ユニキャスト、またはその両方を指定します。両方
Acknowledgments
謝辞
Work on this document was largely inspired by the directions provided by Stewart Bryant in finding a common OAM solution between SDOs.
このドキュメントでの作業は、SDO間の共通のOAMソリューションを見つける際にスチュワートブライアントが提供した指示に大きく影響を受けました。
Acknowledgments are due for many who volunteered to review this document, notably, Jari Arkko, Adrian Farrel, Pete Resnick, Stephen Farrell, Dan Romascanu, Gayle Nobel, and Tal Mizrahi.
謝辞は、このドキュメントのレビューを志願した多くの人、特にJari Arkko、Adrian Farrel、Pete Resnick、Stephen Farrell、Dan Romascanu、Gayle Nobel、Tal Mizrahiによるものです。
Special appreciation is due to Dinesh Dutt for his support and encouragement, especially during the initial discussion phase of TRILL OAM.
特にTRILL OAMの最初のディスカッションフェーズでは、Dinesh Duttのサポートと励ましを特に感謝します。
Authors' Addresses
著者のアドレス
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose, CA 95134 United States
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose、CA 95134アメリカ合衆国
Phone: +1 408-853-2291
EMail: tsenevir@cisco.com
Norman Finn Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States
Norman Finn Cisco Systems 510 McCarthy Blvd Milpitas、CA 95035アメリカ合衆国
EMail: nfinn@cisco.com
Samer Salam Cisco Systems 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada
Samer Salam Cisco Systems 595 Burrard St.、Suite 2123バンクーバー、BC V7X 1J1カナダ
EMail: ssalam@cisco.com Deepak Kumar Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States
Eメール：ssalam@cisco.com Deepak Kumar Cisco Systems 510 McCarthy Blvd Milpitas、CA 95035 United States
Phone: +1 408-853-9760
EMail: dekumar@cisco.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757アメリカ合衆国
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara、CA 95951アメリカ合衆国
EMail: aldrin.ietf@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56625375
EMail: liyizhou@huawei.com