[要約] RFC 7174は、TRILLネットワークの運用、管理、および保守（OAM）フレームワークに関するものであり、TRILLネットワークのOAM機能の要件と設計を提供します。このRFCの目的は、TRILLネットワークの信頼性と可用性を向上させるためのOAM機能の標準化と実装を促進することです。
Internet Engineering Task Force (IETF) S. Salam
Request for Comments: 7174 T. Senevirathne
Category: Informational Cisco
ISSN: 2070-1721 S. Aldrin
D. Eastlake 3rd
Huawei
May 2014
Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework
多くのリンクの透過的な相互接続（TRILL）運用、管理、および保守（OAM）フレームワーク
Abstract
概要
This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.
このドキュメントでは、リンクの透過的な相互接続（TRILL）ネットワークにおける運用、管理、および保守（OAM）の参照フレームワークを指定します。このドキュメントの焦点は、TRILL OAMの障害とパフォーマンス管理の側面にあります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7174.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7174で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 ....................................................3
1.1. Terminology ................................................4
1.2. Relationship to Other OAM Work .............................5
2. TRILL OAM Model .................................................6
2.1. OAM Layering ...............................................6
2.1.1. Relationship to CFM .................................7
2.1.2. Relationship to BFD .................................8
2.1.3. Relationship to Link OAM ............................8
2.2. TRILL OAM in the RBridge Port Model ........................8
2.3. Network, Service, and Flow OAM ............................10
2.4. Maintenance Domains .......................................10
2.5. Maintenance Entity and Maintenance Entity Group ...........11
2.6. MEPs and MIPs .............................................12
2.7. Maintenance Point Addressing ..............................13
3. OAM Frame Format ...............................................14
3.1. Motivation ................................................14
3.2. Determination of Flow Entropy .............................16
3.2.1. Address Learning and Flow Entropy ..................16
3.3. OAM Message Channel .......................................17
3.4. Identification of OAM Messages ............................17
4. Fault Management ...............................................18
4.1. Proactive Fault Management Functions ......................18
4.1.1. Fault Detection (Continuity Check) .................18
4.1.2. Defect Indication ..................................19
4.1.2.1. Forward Defect Indication .................19
4.1.2.2. Reverse Defect Indication (RDI) ...........19
4.2. On-Demand Fault Management Functions ......................20
4.2.1. Connectivity Verification ..........................20
4.2.1.1. Unicast ...................................20
4.2.1.2. Multicast .................................21
4.2.2. Fault Isolation ....................................21
5. Performance Monitoring .........................................22
5.1. Packet Loss ...............................................22
5.2. Packet Delay ..............................................23
6. Operational and Manageability Considerations ...................23
6.1. TRILL OAM Configuration ...................................23
6.1.1. Maintenance Domain Parameters ......................24
6.1.2. Maintenance Association Parameters .................24
6.1.3. Maintenance Endpoint Parameters ....................24
6.1.4. Continuity Check Parameters (Applicable per MA) ....25
6.1.5. Connectivity Verification Parameters
(Applicable per Operation) .........................25
6.1.6. Fault Isolation Parameters (Applicable per
Operation) .........................................26
6.1.7. Packet Loss Monitoring .............................27
6.1.8. Packet Delay Monitoring ............................27
6.2. TRILL OAM Notifications ...................................28
6.3. Collecting Performance Monitoring Metrics .................28
7. Security Considerations ........................................29
8. Acknowledgments ................................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) [RFC6291] in Transparent Interconnection of Lots of Links (TRILL) networks.
このドキュメントは、リンクの透過的な相互接続（TRILL）ネットワークにおける運用、管理、および保守（OAM）[RFC6291]の参照フレームワークを指定します。
TRILL [RFC6325] specifies a protocol for shortest-path frame routing in multi-hop networks with arbitrary topologies and link technologies, using the IS-IS routing protocol. TRILL capable devices are referred to as TRILL Switches or RBridges (Routing Bridges). RBridges provide an optimized and transparent Layer 2 delivery service for Ethernet unicast and multicast traffic. Some characteristics of a TRILL network that are different from IEEE 802.1 bridging are the following:
TRILL [RFC6325]は、IS-ISルーティングプロトコルを使用して、任意のトポロジとリンクテクノロジーを備えたマルチホップネットワークでの最短パスフレームルーティング用のプロトコルを指定します。 TRILL対応デバイスは、TRILLスイッチまたはRBridge（ルーティングブリッジ）と呼ばれます。 RBridgesは、イーサネットユニキャストおよびマルチキャストトラフィックに最適化された透過的なレイヤー2配信サービスを提供します。 IEEE 802.1ブリッジングとは異なるTRILLネットワークの特徴は次のとおりです。
- TRILL networks support arbitrary link technology between TRILL Switches. Hence, a TRILL Switch port may not have a 48-bit Media Access Control (MAC) address [802] but might, for example, have an IP address as an identifier [TRILL-IP] or no unique identifier (e.g., PPP [RFC6361]).
- TRILLネットワークは、TRILLスイッチ間の任意のリンク技術をサポートしています。したがって、TRILLスイッチポートには48ビットメディアアクセス制御（MAC）アドレスがない[802]かもしれませんが、たとえば、IPアドレスが識別子[TRILL-IP]としてあるか、一意の識別子がない（たとえばPPP [ RFC6361]）。
- TRILL networks do not enforce congruence of unicast and multicast paths between a given pair of RBridges.
- TRILLネットワークは、RBridgeの特定のペア間のユニキャストパスとマルチキャストパスの合同を強制しません。
- TRILL networks do not impose symmetry of the forward and reverse paths between a given pair of RBridges.
- TRILLネットワークは、RBridgeの特定のペア間のフォワードパスとリバースパスに対称性を課しません。
- TRILL Switches terminate spanning tree protocols instead of propagating them.
- TRILLスイッチは、スパニングツリープロトコルを伝播せずに終了します。
In this document, we refer to the term "OAM" as defined in [RFC6291]. The Operations aspect involves finding problems that prevent proper functioning of the network. It also includes monitoring of the network to identify potential problems before they occur. Administration involves keeping track of network resources. Maintenance activities are focused on facilitating repairs and upgrades as well as corrective and preventive measures. [ISO/IEC7498-4] defines 5 functional areas in the OSI model for network management, commonly referred to as FCAPS:
このドキュメントでは、[RFC6291]で定義されている「OAM」という用語を使用します。運用の側面には、ネットワークの適切な機能を妨げる問題の発見が含まれます。また、潜在的な問題が発生する前に識別するためのネットワークの監視も含まれます。管理には、ネットワークリソースの追跡が含まれます。メンテナンス活動は、修理とアップグレード、および是正措置と予防措置の促進に重点を置いています。 [ISO / IEC7498-4]は、一般にFCAPSと呼ばれる、ネットワーク管理用のOSIモデルの5つの機能領域を定義します。
- Fault Management
- 障害管理
- Configuration Management
- 構成管理
- Accounting Management
- 会計管理
- Performance Management
- パフォーマンス管理
- Security Management
- セキュリティ管理
The focus of this document is on the first and fourth functional aspects, Fault Management and Performance Management, in TRILL networks. These primarily map to the Operations and Maintenance parts of OAM.
このドキュメントの焦点は、TRILLネットワークの最初と4番目の機能的側面である障害管理とパフォーマンス管理にあります。これらは主にOAMの運用と保守の部分にマッピングされます。
This document provides a generic framework for a comprehensive solution that meets the requirements outlined in [RFC6905]. However, specific mechanisms to address these requirements are considered to be outside the scope of this document. Furthermore, future document(s) will specify the optional reporting of errors in TRILL user traffic, such as the use of a reserved or unknown egress nickname, etc.
このドキュメントは、[RFC6905]で概説されている要件を満たす包括的なソリューションの一般的なフレームワークを提供します。ただし、これらの要件に対処する特定のメカニズムは、このドキュメントの範囲外であると見なされます。さらに、将来のドキュメントでは、予約済みまたは不明な出力ニックネームの使用など、TRILLユーザートラフィックのエラーのオプションのレポートを指定する予定です。
Definitions of many OAM terms can be found in [RFC7087].
多くのOAM用語の定義は[RFC7087]にあります。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
BFD - Bidirectional Forwarding Detection [RFC5880]
BFD-双方向転送検出[RFC5880]
CFM - Connectivity Fault Management [802.1Q]
CFM-接続障害管理[802.1Q]
ECMP - Equal-Cost Multipath
ECMP-等コストマルチパス
FGL - Fine-Grained Label(ing) [RFC7172]
FGL-きめの細かいラベル（ing）[RFC7172]
IEEE - Institute for Electrical and Electronic Engineers
IEEE-Institute for Electrical and Electronic Engineers
IP - Internet Protocol (includes both IPv4 and IPv6)
IP-インターネットプロトコル（IPv4とIPv6の両方を含む）
LAN - Local Area Network
LAN-ローカルエリアネットワーク
MA - Maintenance Association MAC - Media Access Control [802]
ま ー まいんてなんせ あっそしあちおん まＣ ー めぢあ あっせっｓ こんｔろｌ 「８０２」
ME - Maintenance Entity
ME-メンテナンスエンティティ
MEP - Maintenance End Point
MEP-メンテナンスエンドポイント
MIP - Maintenance Intermediate Point
MIP-メンテナンス中間ポイント
MP - Maintenance Point (MEP or MIP)
MP-メンテナンスポイント（MEPまたはMIP）
OAM - Operations, Administration, and Maintenance [RFC6291]
OAM-運用、管理、およびメンテナンス[RFC6291]
PPP - Point-to-Point Protocol [RFC1661]
PPP-ポイントツーポイントプロトコル[RFC1661]
RBridge - Routing Bridge, a device implementing TRILL [RFC6325]
RBridge-Routing Bridge、TRILLを実装するデバイス[RFC6325]
RDI - Reverse Defect Indication
RDI-欠陥の表示を元に戻す
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-多くのリンクの透過的な相互接続[RFC6325]
TRILL Switch - an alternate name for an RBridge
TRILLスイッチ-RBridgeの別名
VLAN - Virtual LAN [802.1Q]
VLAN-仮想LAN [802.1Q]
OAM is a technology area where a wealth of prior art exists. This document leverages concepts and draws upon elements defined and/or used in the following documents:
OAMは、豊富な先行技術が存在する技術分野です。このドキュメントは、概念を活用し、次のドキュメントで定義および/または使用されている要素を利用しています。
- [RFC6905] defines the requirements for TRILL OAM that serve as the basis for this framework. It also defines terminology that is used extensively in this document.
- [RFC6905]は、このフレームワークの基礎となるTRILL OAMの要件を定義しています。また、このドキュメントで広く使用されている用語も定義しています。
- [802.1Q] specifies the Connectivity Fault Management (CFM) protocol, which defines the concepts of Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points.
- [802.1Q]は、保守ドメイン、保守エンドポイント、および保守中間ポイントの概念を定義する接続障害管理（CFM）プロトコルを指定します。
- [Y.1731] extends Connectivity Fault Management in the following areas: it defines fault notification and alarm suppression functions for Ethernet. It also specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement.
- [Y.1731]は、次の領域で接続障害管理を拡張します。イーサネットの障害通知およびアラーム抑制機能を定義します。また、損失、遅延、ジッター、スループット測定など、イーサネットパフォーマンス管理のメカニズムも指定します。
- [RFC7175] defines a TRILL encapsulation for BFD that enables the use of the latter for network fast failure detection.
- [RFC7175]は、BFDのTRILLカプセル化を定義し、ネットワークの高速障害検出に後者を使用できるようにします。
- [RFC5860] and [RFC6371] specify requirements and a framework for OAM in MPLS-based networks.
- [RFC5860]と[RFC6371]は、MPLSベースのネットワークにおけるOAMの要件とフレームワークを指定しています。
In the TRILL architecture, the TRILL layer is independent of the underlying link-layer technology. Therefore, it is possible to run TRILL over any transport layer capable of carrying TRILL packets such as Ethernet [RFC6325], PPP [RFC6361], or IP [TRILL-IP]. Furthermore, TRILL provides a virtual Ethernet connectivity service that is transparent to higher-layer entities (Layer 3 and above). This strict layering is observed by TRILL OAM.
TRILLアーキテクチャでは、TRILLレイヤーは基礎となるリンクレイヤーテクノロジーから独立しています。したがって、イーサネット[RFC6325]、PPP [RFC6361]、IP [TRILL-IP]などのTRILLパケットを伝送できるトランスポート層でTRILLを実行できます。さらに、TRILLは、上位レイヤーエンティティ（レイヤー3以上）に対して透過的な仮想イーサネット接続サービスを提供します。この厳密な階層化は、TRILL OAMによって観察されます。
Of particular interest is the layering of TRILL OAM with respect to:
特に興味深いのは、TRILL OAMの階層化です。
- BFD, which is typically used for fast failure detection.
- BFD。これは通常、高速障害検出に使用されます。
- Ethernet CFM [802.1Q] on paths from an external device, over a TRILL campus, to another external device, especially since TRILL Switches are likely to be deployed where existing 802.1 bridges can be such external devices.
- 外部デバイスからTRILLキャンパスを経由して別の外部デバイスへのパス上のイーサネットCFM [802.1Q]。特に、既存の802.1ブリッジがそのような外部デバイスになり得る場所にTRILLスイッチが配備される可能性が高いためです。
- Link OAM, on links interior to a TRILL campus, which is link-technology-specific.
- リンクテクノロジー固有のTRILLキャンパスへのリンク内部のリンクOAM。
Consider the example network depicted in Figure 1 below, where a TRILL network is interconnected via Ethernet links:
下の図1に示すネットワークの例を考えます。TRILLネットワークはイーサネットリンクを介して相互接続されています。
LAN LAN
+---+ +---+ ====== +---+ ============= +---+
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
+---+ +---+ ====== +---+ ============= +---+
a. Ethernet CFM (Client Layer) on path over the TRILL campus
>---o------------------------------------------------o---<
b. TRILL OAM (Network Layer)
>------o-----------o---------------------<
c. Ethernet CFM (Transport Layer) on interior Ethernet LANs
>---o--o---< >---o--o---o--o---<
d. BFD (Media Independent Link Layer)
#---# #----------# #-----------------#
e. Link OAM (Media Dependent Link Layer)
*---* *---* *---* *---* *---* *---* *---* *---*
Legend: >, < MEP o MIP # BFD Endpoint * Link OAM Endpoint
Figure 1: OAM Layering in TRILL
図1：TRILLでのOAMレイヤー
Where Bn and RBn (n= 1,2,3, ...) denote IEEE 802.1Q bridges and TRILL RBridges, respectively.
ここで、BnおよびRBn（n = 1,2,3、...）は、それぞれIEEE 802.1QブリッジおよびTRILL RBridgeを示します。
In the context of a TRILL network, CFM can be used as either a client-layer OAM or a transport-layer OAM mechanism.
TRILLネットワークのコンテキストでは、CFMはクライアント層OAMまたはトランスポート層OAMメカニズムとして使用できます。
When acting as a client-layer OAM (see Figure 1a), CFM provides fault management capabilities for the user, on an end-to-end basis over the TRILL network. Edge ports of the TRILL network may be visible to CFM operations through the optional presence of a CFM Maintenance Intermediate Point (MIP) in the TRILL Switches' edge Ethernet ports.
クライアント層OAMとして機能する場合（図1aを参照）、CFMはTRILLネットワークを介してエンドツーエンドでユーザーに障害管理機能を提供します。 TRILLネットワークのエッジポートは、オプションでTRILLスイッチのエッジイーサネットポートにCFMメンテナンス中間ポイント（MIP）が存在することにより、CFM操作から見える可能性があります。
When acting as a transport-layer OAM (see Figure 1c), CFM provides fault management functions for the IEEE 802.1Q bridged LANs that may interconnect RBridges. Such bridged LANs can be used as TRILL level links between RBridges. RBridges directly connected to the intervening 802.1Q bridges may host CFM Down Maintenance End Points (MEPs).
トランスポート層OAMとして機能する場合（図1cを参照）、CFMは、RBridgeを相互接続する可能性のあるIEEE 802.1QブリッジLANに障害管理機能を提供します。このようなブリッジLANは、RBridge間のTRILLレベルのリンクとして使用できます。介在する802.1Qブリッジに直接接続されたRBridgeは、CFMダウンメンテナンスエンドポイント（MEP）をホストする場合があります。
One-hop BFD (see Figure 1d) runs between adjacent RBridges and provides fast link as well as node failure detection capability [RFC7175]. Note that TRILL BFD also provides some testing of the TRILL protocol stack and thus sits a layer above Link OAM, which is media specific. BFD's fast failure detection helps support rapid convergence in TRILL networks. The requirements for BFD are different from those of the TRILL OAM mechanisms that are the prime focus of this document. Furthermore, BFD does not use the frame format described in Section 3.1.
ワンホップBFD（図1dを参照）は隣接するRBridge間で実行され、高速リンクとノード障害検出機能を提供します[RFC7175]。 TRILL BFDはTRILLプロトコルスタックのいくつかのテストも提供するため、メディア固有のLink OAMの上の層に位置することに注意してください。 BFDの高速障害検出は、TRILLネットワークでの迅速な収束をサポートするのに役立ちます。 BFDの要件は、このドキュメントの主な焦点であるTRILL OAMメカニズムの要件とは異なります。さらに、BFDはセクション3.1で説明されているフレーム形式を使用しません。
TRILL BFD differs from TRILL OAM in two significant ways:
TRILL BFDは、2つの重要な点でTRILL OAMと異なります。
1. A TRILL BFD transmitter is always bound to a specific TRILL output port.
1. TRILL BFDトランスミッターは常に特定のTRILL出力ポートにバインドされます。
2. TRILL BFD messages can be transmitted by the originator out of a port to a neighbor RBridge when the adjacency is in the Detect or 2-Way states as well as when the adjacency is in the Report (Up) state [RFC7177].
2. TRILL BFDメッセージは、隣接がDetectまたは2-Way状態であるとき、および隣接がReport（Up）状態であるときに[RFC7177]、ポートから隣接RBridgeに発信元によって送信できます。
In contrast, TRILL OAM messages are typically transmitted by appearing to have been received on a TRILL input port (refer to Section 2.2 for details). In that case, the output ports on which TRILL OAM messages are sent are determined by the TRILL routing function. The TRILL routing function will only send on links that are in the Report state and have been incorporated into the local view of the campus topology.
対照的に、TRILL OAMメッセージは通常、TRILL入力ポートで受信されたように見えて送信されます（詳細については、セクション2.2を参照してください）。その場合、TRILL OAMメッセージが送信される出力ポートは、TRILLルーティング機能によって決定されます。 TRILLルーティング機能は、レポート状態にあり、キャンパストポロジのローカルビューに組み込まれているリンクでのみ送信します。
Link OAM (see Figure 1e) depends on the nature of the technology used in the links interconnecting RBridges. For example, for Ethernet links, the OAM described in Clause 57 of [802.3] may be used.
リンクOAM（図1eを参照）は、RBridgeを相互接続するリンクで使用されるテクノロジーの性質に依存します。たとえば、イーサネットリンクの場合、[802.3]の57節に記載されているOAMを使用できます。
TRILL OAM processing can be represented as a layer situated between the port's TRILL encapsulation/decapsulation function and the TRILL forwarding engine function on any RBridge port. TRILL OAM requires services of the RBridge forwarding engine and utilizes information from the IS-IS control plane. Figure 2 below depicts TRILL OAM processing in the context of the RBridge Port Model defined in [RFC6325]. In this figure, double lines represent flow of both frames and information.
TRILL OAM処理は、ポートのTRILLカプセル化/カプセル化解除機能と任意のRBridgeポートのTRILL転送エンジン機能の間に位置するレイヤーとして表すことができます。 TRILL OAMはRBridge転送エンジンのサービスを必要とし、IS-ISコントロールプレーンからの情報を利用します。以下の図2は、[RFC6325]で定義されているRBridgeポートモデルのコンテキストでのTRILL OAM処理を示しています。この図では、二重線がフレームと情報の両方の流れを表しています。
This figure shows a conceptual model. It is to be understood that implementations need not mirror this exact model as long as the intended OAM requirements and functionality are preserved.
この図は概念モデルを示しています。意図されたOAM要件と機能が維持されている限り、実装はこの正確なモデルをミラーリングする必要がないことを理解してください。
+-----------------------------------------------+----
| (Flow of OAM Messages) RBridge
| +----------------------+
| |+-------------------+|| Forwarding Engine,
| || || IS-IS, etc.
| || || Processing of
| V V TRILL packets
+---------------------------------------------+-----
|| || ...other ports
+------------+ +------------+
UP MEP /\ | TRILL OAM | | TRILL OAM | /\ UP MEP
MIP () | Layer | | Layer | () MIP
DOWN MEP \/ +------------+ +------------+ \/ DOWN MEP
| TRILL | | TRILL |
| Encap/Decap| | Encap/Decap|
+------------+ +------------+
|End-Station | |End-Station |
|VLAN & | |VLAN & |
|Priority | |Priority |
|Processing | |Processing |
+------------+ +------------+ <-- ISS
|802.1/802.3 | |802.1/802.3 |
|Low-Level | |Low-Level |
|Control | |Control |
|Frame | |Frame |
|Processing, | |Processing, |
|Port/Link | |Port/Link |
|Control | |Control |
|Logic | |Logic |
+------------+ +------------+
| 802.3PHY | | 802.3PHY |
|(Physical | |(Physical |
| interface) | | interface) |
+------------+ +------------+
|| ||
Link Link
Figure 2: TRILL OAM in RBridge Port Model
図2：RBridgeポートモデルのTRILL OAM
Note that the terms "MEP" and "MIP" in the above figure are explained in detail in Section 2.6 below.
上の図の「MEP」および「MIP」という用語については、以下のセクション2.6で詳しく説明しています。
OAM functions in a TRILL network can be conducted at different granularity. This gives rise to 'Network', 'Service', and 'Flow' OAM, listed in order of finer granularity.
TRILLネットワークのOAM機能は、さまざまな粒度で実行できます。これにより、「ネットワーク」、「サービス」、および「フロー」のOAMが、より細かい順序でリストされます。
Network OAM mechanisms provide fault and performance management functions in the context of a 'test' VLAN or fine-grained label [RFC7172]. The test VLAN can be thought of as a management or diagnostics VLAN that extends to all RBridges in a TRILL network. In order to account for multipathing, Network OAM functions also make use of test flows (both unicast and multicast) to provide coverage of the various paths in the network.
ネットワークOAMメカニズムは、「テスト」VLANまたは細粒度ラベル[RFC7172]のコンテキストで障害およびパフォーマンス管理機能を提供します。テストVLANは、TRILLネットワーク内のすべてのRBridgeに拡張される管理または診断VLANと考えることができます。マルチパスを考慮するために、ネットワークOAM機能はテストフロー（ユニキャストとマルチキャストの両方）を利用して、ネットワーク内のさまざまなパスをカバーします。
Service OAM mechanisms provide fault and performance management functions in the context of the actual VLAN or fine-grained label set for which end-station service is enabled. Test flows are used here, as well, to provide coverage in the case of multipathing.
サービスOAMメカニズムは、エンドステーションサービスが有効になっている実際のVLANまたは粒度の細かいラベルセットのコンテキストで障害およびパフォーマンス管理機能を提供します。ここでもテストフローを使用して、マルチパスの場合のカバレッジを提供します。
Flow OAM mechanisms provide the most fine-grained fault and performance management capabilities, where OAM functions are performed in the context of end-station flows within VLANs or fine-grained labels. While Flow OAM provides the most granular control, it clearly poses scalability challenges if attempted on large numbers of flows.
フローOAMメカニズムは、最も細かい障害とパフォーマンス管理機能を提供します。OAM機能は、VLANまたは細かいラベル内のエンドステーションフローのコンテキストで実行されます。フローOAMは最もきめ細かい制御を提供しますが、多数のフローで試行すると、スケーラビリティの課題が明らかに生じます。
The concept of Maintenance Domains, or OAM Domains, is well known in the industry. IEEE [802.1Q] defines the notion of a Maintenance Domain as a collection of devices (for example, network elements) that are grouped for administrative and/or management purposes. Maintenance Domains usually delineate trust relationships, varying addressing schemes, network infrastructure capabilities, etc.
メンテナンスドメインまたはOAMドメインの概念は業界でよく知られています。 IEEE [802.1Q]は、メンテナンスドメインの概念を、管理や管理の目的でグループ化されたデバイス（ネットワーク要素など）の集合として定義しています。メンテナンスドメインは通常、信頼関係、さまざまなアドレッシングスキーム、ネットワークインフラストラクチャ機能などを示します。
When mapped to TRILL, a Maintenance Domain is defined as a collection of RBridges in a network for which connectivity faults and performance degradation are to be managed by a single operator. All RBridges in a given Maintenance Domain are, by definition, managed by a single entity (for example, an enterprise or a data center operator, etc.). [RFC6325] defines the operation of TRILL in a single IS-IS area, with the assumption that a single operator manages the network. In this context, a single (default) Maintenance Domain is sufficient for TRILL OAM.
TRILLにマップされると、メンテナンスドメインは、ネットワーク内のRBridgeのコレクションとして定義され、接続障害とパフォーマンスの低下は単一のオペレーターによって管理されます。特定のメンテナンスドメイン内のすべてのRBridgeは、定義により、単一のエンティティ（たとえば、企業やデータセンターのオペレーターなど）によって管理されます。 [RFC6325]は、単一のオペレータがネットワークを管理することを前提として、単一のIS-ISエリアでのTRILLの動作を定義しています。このコンテキストでは、TRILL OAMには単一の（デフォルトの）メンテナンスドメインで十分です。
However, when considering scenarios where different TRILL networks need to be interconnected, for example, as discussed in [TRILL-ML], then the introduction of multiple Maintenance Domains, and Maintenance Domain hierarchies, becomes useful to map and enforce administrative boundaries. When considering multi-domain scenarios, the following rules must be followed: TRILL OAM Domains must not partially intersect but must either be disjoint or nest to form a hierarchy (that is, a higher Maintenance Domain may completely enclose a lower domain). A Maintenance Domain is typically identified by a Domain Name and a Maintenance Level (a numeric identifier). If two domains are nested, the encompassing domain must be assigned a higher Maintenance Level number than the enclosed domain. For this reason, the encompassing domain is commonly referred to as the 'higher' domain, and the enclosed domain is referred to as the 'lower' domain. OAM functions in the lower domain are completely transparent to the higher domain. Furthermore, OAM functions in the higher domain only have visibility to the boundary of the lower domain (for example, an attempt to trace the path in the higher domain will depict the entire lower domain as a single-hop between the RBridges that constitute the boundary of that lower domain). By the same token, OAM functions in the higher domain are transparent to RBridges that are internal to the lower domain. The hierarchical nesting of domains is established through operator configuration of the RBridges.
ただし、たとえば[TRILL-ML]で説明されているように、異なるTRILLネットワークを相互接続する必要があるシナリオを検討する場合、複数のメンテナンスドメインとメンテナンスドメイン階層の導入は、管理境界のマッピングと適用に役立ちます。マルチドメインのシナリオを検討するときは、次のルールに従う必要があります。TRILL OAMドメインは部分的に交差してはならず、階層を形成するために分離またはネストする必要があります（つまり、上位のメンテナンスドメインが下位のドメインを完全に囲む場合があります）。メンテナンスドメインは通常、ドメイン名とメンテナンスレベル（数値識別子）で識別されます。 2つのドメインがネストされている場合、包含するドメインには、囲まれているドメインよりも高いメンテナンスレベル番号を割り当てる必要があります。このため、通常、包含ドメインは「上位」ドメインと呼ばれ、囲まれたドメインは「下位」ドメインと呼ばれます。下位ドメインのOAM機能は、上位ドメインに対して完全に透過的です。さらに、上位ドメインのOAM機能は下位ドメインの境界のみを表示します（たとえば、上位ドメインのパスを追跡しようとすると、境界を構成するRBridge間の単一ホップとして下位ドメイン全体が描写されますその下位ドメインの）。同様に、上位ドメインのOAM機能は、下位ドメインの内部にあるRBridgeに対して透過的です。ドメインの階層的なネストは、RBridgesのオペレーター構成によって確立されます。
+-------------------+ +---------------+ +-------------------+
| | | TRILL | | |
| Site 1 +----+Interconnect +----+ Site 2 |
| TRILL | RB | Network | RB | TRILL |
| (Level 1) +----+ (Level 2) +----+ (Level 1) |
| | | | | |
+-------------------+ +---------------+ +-------------------+
<------------------------End-to-End Domain-------------------->
<----Site Domain----> <--Interconnect --> <----Site Domain---->
Domain
Figure 3: TRILL OAM Maintenance Domains
図3：TRILL OAMメンテナンスドメイン
TRILL OAM functions are performed in the context of logical endpoint pairs referred to as Maintenance Entities (ME). A Maintenance Entity defines a relationship between two points in a TRILL network where OAM functions (for example, monitoring operations) are applied. The two points that define a Maintenance Entity are known as Maintenance End Points (MEPs) -- see Section 2.6 below. The set of Maintenance
TRILL OAM機能は、メンテナンスエンティティ（ME）と呼ばれる論理エンドポイントペアのコンテキストで実行されます。保守エンティティーは、OAM機能（例えば、モニター操作）が適用されるTRILLネットワーク内の2つのポイント間の関係を定義します。メンテナンスエンティティを定義する2つのポイントは、メンテナンスエンドポイント（MEP）と呼ばれます。以下のセクション2.6を参照してください。メンテナンスのセット
End Points that belong to the same Maintenance Domain are referred to as a Maintenance Association (MA). On the network path in between MEPs, there can be zero or more intermediate points, called Maintenance Intermediate Points (MIPs). MEPs can be part of more than one ME in a given MA.
同じメンテナンスドメインに属するエンドポイントは、メンテナンスアソシエーション（MA）と呼ばれます。 MEP間のネットワークパスには、メンテナンス中間ポイント（MIP）と呼ばれるゼロ以上の中間ポイントが存在する場合があります。 MEPは、特定のMA内の複数のMEの一部になることができます。
OAM capabilities on RBridges can be defined in terms of logical groupings of functions that can be categorized into two functional objects: Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). The two are collectively referred to as Maintenance Points (MPs).
RBridgeのOAM機能は、メンテナンスエンドポイント（MEP）とメンテナンス中間ポイント（MIP）の2つの機能オブジェクトに分類できる機能の論理グループの観点から定義できます。 2つはまとめてメンテナンスポイント（MP）と呼ばれます。
MEPs are the active components of TRILL OAM: MEPs source TRILL OAM messages periodically or on-demand based on operator configuration actions. Furthermore, MEPs ensure that TRILL OAM messages do not leak outside a given Maintenance Domain, for example, out of the TRILL network and into end stations. MIPs, on the other hand, are internal to a Maintenance Domain. They are the more passive components of TRILL OAM, primarily responsible for forwarding TRILL OAM messages and selectively responding to a subset of these messages.
MEPはTRILL OAMのアクティブなコンポーネントです。MEPはTRILL OAMメッセージを定期的に、またはオペレーターの構成アクションに基づいてオンデマンドで送信します。さらに、MEPは、TRILL OAMメッセージが特定のメンテナンスドメインの外部、たとえばTRILLネットワークから端末に漏れないようにします。一方、MIPはメンテナンスドメインの内部にあります。これらは、TRILL OAMのよりパッシブなコンポーネントであり、主にTRILL OAMメッセージを転送し、これらのメッセージのサブセットに選択的に応答します。
The following figure shows the MEP and MIP placement for the Maintenance Domains depicted in Figure 3 above.
次の図は、上記の図3に示したメンテナンスドメインのMEPとMIPの配置を示しています。
TRILL Site 1 Interconnect TRILL Site 2
+-----------------+ +------------------+ +-----------------+
| | | | | |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| |RB1|--|RB2|--|RB3|--|RB4|--|RB5|--|RB6|--|RB7|--|RB8| |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| | | | | |
+-----------------+ +------------------+ +-----------------+
<E------------I--------------------I-------------E>
<E------I----E><E----I-------I----E><E-----I-----E>
Legend E: MEP I: MIP
凡例E：MEP I：MIP
Figure 4: MEPs and MIPs
図4：MEPとMIP
A single RBridge may host multiple MEPs of different technologies, for example, TRILL OAM MEP(s) and [802.1Q] MEP(s). This does not mean that the protocol operation is necessarily consolidated into a single functional entity on those ports. The protocol functions for each MEP remain independent and reside in different shims in the RBridge Port Model of Figure 2: the TRILL OAM MEP resides in the "TRILL OAM Layer" block whereas a CFM MEP resides in the "End-Station VLAN & Priority Processing" block.
単一のRBridgeは、TRILL OAM MEPおよび[802.1Q] MEPなど、異なるテクノロジーの複数のMEPをホストできます。これは、プロトコル操作がこれらのポートで単一の機能エンティティに必ず統合されることを意味しません。各MEPのプロトコル機能は独立しており、図2のRBridgeポートモデルの異なるシムにあります。TRILLOAM MEPは「TRILL OAM Layer」ブロックにあり、CFM MEPは「Endpoint VLAN＆Priority Processing」にあります。 "ブロック。
In the model of Section 2.2, a single MEP and/or MIP per MA can be instantiated per RBridge port. A MEP is further qualified with an administratively set direction (UP or DOWN), as follows:
セクション2.2のモデルでは、MAごとに単一のMEPまたはMIP、あるいはその両方をRBridgeポートごとにインスタンス化できます。 MEPは、次のように、管理上設定された方向（UPまたはDOWN）でさらに修飾されます。
- An UP MEP sends and receives OAM messages through the RBridge forwarding engine. This means that an UP MEP effectively communicates with MEPs on other RBridges through TRILL interfaces other than the one that the MEP is configured on.
- UP MEPは、RBridge転送エンジンを介してOAMメッセージを送受信します。つまり、UP MEPは、MEPが構成されているもの以外のTRILLインターフェイスを介して、他のRBridge上のMEPと効果的に通信します。
- A DOWN MEP sends and receives OAM messages through the link connected to the interface on which the MEP is configured.
- DOWN MEPは、MEPが設定されているインターフェイスに接続されたリンクを介してOAMメッセージを送受信します。
In order to support TRILL OAM functions on sections, as described in [RFC6905], while maintaining the simplicity of a single TRILL OAM Maintenance Domain, the TRILL OAM layer may be implemented on a virtual port with no physical layer (Null PHY). In this case, the Down MEP function is not supported, since the virtual port does not attach to a link; as such, a Down MEP on a virtual port would not be capable of sending or receiving OAM messages.
[RFC6905]で説明されているように、セクションでTRILL OAM機能をサポートするために、単一のTRILL OAMメンテナンスドメインのシンプルさを維持しながら、TRILL OAMレイヤーを物理ポートのない仮想ポート（Null PHY）に実装できます。この場合、仮想ポートはリンクに接続されないため、Down MEP機能はサポートされません。そのため、仮想ポートのダウンMEPは、OAMメッセージを送受信できません。
A TRILL OAM solution that conforms to this framework:
このフレームワークに準拠するTRILL OAMソリューション：
- must support the MIP function on TRILL ports (to support Fault Isolation).
- TRILLポートでMIP機能をサポートする必要があります（障害分離をサポートするため）。
- must support the UP MEP function on a TRILL virtual port (to support OAM functions on sections, as defined in [RFC6905]).
- TRILL仮想ポートでUP MEP機能をサポートする必要があります（[RFC6905]で定義されているように、セクションでOAM機能をサポートするため）。
- may support the UP MEP function on TRILL ports.
- TRILLポートでUP MEP機能をサポートする場合があります。
- may support the DOWN MEP function on TRILL ports.
- TRILLポートでDOWN MEP機能をサポートする場合があります。
TRILL OAM functions must provide the capability to address a specific Maintenance Point or a set of one or more Maintenance Points in an MA. To that end, RBridges need to recognize two sets of addresses:
TRILL OAM機能は、MA内の特定のメンテナンスポイントまたは1つ以上のメンテナンスポイントのセットに対処する機能を提供する必要があります。そのために、RBridgeは2つのアドレスセットを認識する必要があります。
- Individual MP addresses
- 個別のMPアドレス
- Group MP addresses
- グループMPアドレス
TRILL OAM will support the Shared MP address model, where all MPs on an RBridge share the same Individual MP address. In other words, TRILL OAM messages can be addressed to a specific RBridge but not to a specific port on an RBridge.
TRILL OAMは、RBridge上のすべてのMPが同じ個別MPアドレスを共有する共有MPアドレスモデルをサポートします。つまり、TRILL OAMメッセージは特定のRBridgeにアドレス指定できますが、RBridgeの特定のポートには送信できません。
One cannot discern, from observing the external behavior of an RBridge, whether TRILL OAM messages are actually delivered to a certain MP or another entity within the RBridge. The Shared MP address model takes advantage of this fact by allowing MPs in different RBridge ports to share the same Individual MP address. The MPs may still be implemented as residing on different RBridge ports, and for the most part, they have distinct identities.
TRILL OAMメッセージが実際に特定のMPまたはRBridge内の別のエンティティに配信されるかどうかは、RBridgeの外部動作の観察からは識別できません。共有MPアドレスモデルは、異なるRBridgeポートのMPが同じ個別MPアドレスを共有できるようにすることで、この事実を利用します。 MPは、異なるRBridgeポートに常駐するものとして実装される可能性があり、ほとんどの場合、それらは異なるIDを持っています。
The Group MP addresses enable the OAM mechanism to reach all the MPs in a given MA. Certain OAM functions, for example, pruned tree verification, require addressing a subset of the MPs in an MA. Group MP addresses are not defined for such subsets. Rather, the OAM function in question must use the Group MP addresses combined with an indication of the scope of the MP subset encoded in the OAM Message Channel. This prevents an unwieldy set of responses to Group MP addresses.
グループMPアドレスにより、OAMメカニズムは特定のMA内のすべてのMPに到達できます。特定のOAM機能（プルーンツリー検証など）では、MA内のMPのサブセットをアドレス指定する必要があります。そのようなサブセットには、グループMPアドレスは定義されていません。むしろ、問題のOAM機能は、OAMメッセージチャネルでエンコードされたMPサブセットのスコープの表示と組み合わせたグループMPアドレスを使用する必要があります。これにより、グループMPアドレスへの扱いにくい一連の応答が防止されます。
In order for TRILL OAM messages to accurately test the data path, these messages must be transparent to transit RBridges. That is, a TRILL OAM message must be indistinguishable from a TRILL Data packet through normal transit RBridge processing. Only the target RBridge, which needs to process the message, should identify and trap the packet as a control message through normal processing. Additionally, methods must be provided to prevent OAM packets from being transmitted out as native frames.
TRILL OAMメッセージでデータパスを正確にテストするには、これらのメッセージがRBridgeを通過するときに透過的である必要があります。つまり、TRILL OAMメッセージは、通常の中継RBridge処理を通じてTRILLデータパケットと区別できない必要があります。メッセージを処理する必要があるターゲットRBridgeのみが、通常の処理を通じてパケットを制御メッセージとして識別およびトラップする必要があります。さらに、OAMパケットがネイティブフレームとして送信されないようにする方法を提供する必要があります。
The TRILL OAM packet format defined below provides the necessary flexibility to exercise the data path as closely as possible to actual data packets.
以下に定義するTRILL OAMパケット形式は、実際のデータパケットにできる限り近いデータパスを実行するために必要な柔軟性を提供します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial 6-byte fixed part of |
+ TRILL Header + 6 bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Header Extensions |
. (if any) . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| DA / SA | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
| Data Label | | Flow Entropy
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Fixed Size
. . |
. . /
| | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| OAM Ethertype | 2 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Trailer . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OAM Frame Format
図5：OAMフレーム形式
The TRILL Header and the Link Header and Trailer need to be as similar as practical to the TRILL Header and the Link Header and Trailer of the normal TRILL Data packet corresponding to the traffic that OAM is testing.
TRILLヘッダーとリンクヘッダーおよびトレーラーは、OAMがテストしているトラフィックに対応する通常のTRILLデータパケットのTRILLヘッダーとリンクヘッダーとトレーラーに実際的に類似している必要があります。
The OAM Ethertype demarcates the boundary between the Flow Entropy field and the OAM Message Channel. The OAM Ethertype is expected at a deterministic offset from the TRILL Header, thereby allowing applications to clearly identify the beginning of the OAM Message Channel. Additionally, it facilitates the use of the same OAM frame structure by different Ethernet technologies.
OAM Ethertypeは、フローエントロピーフィールドとOAMメッセージチャネルの境界を区別します。 OAM EthertypeはTRILLヘッダーからの確定的なオフセットで期待されているため、アプリケーションはOAMメッセージチャネルの開始を明確に識別できます。さらに、異なるイーサネットテクノロジーによる同じOAMフレーム構造の使用を容易にします。
The Link Trailer is usually a checksum, such as the Ethernet Frame Check Sequence, which is examined at a low level very early in the frame input process and automatically generated as part of the low-level frame output process. If the checksum fails, the frame is normally discarded with no higher-level processing.
リンクトレーラーは通常、イーサネットフレームチェックシーケンスなどのチェックサムであり、フレーム入力プロセスの非常に早い段階で低レベルで検査され、低レベルフレーム出力プロセスの一部として自動的に生成されます。チェックサムが失敗した場合、フレームは通常、上位レベルの処理なしで破棄されます。
The Flow Entropy field is a fixed-length field that is populated with either real packet data or synthetic data that mimics the intended flow. It always starts with a destination and source MAC address area followed by a Data Label area (either a VLAN or fine-grained label).
フローエントロピーフィールドは、実際のパケットデータまたは目的のフローを模倣する合成データのいずれかが入力される固定長フィールドです。それは常に宛先と送信元のMACアドレス領域で始まり、その後にデータラベル領域（VLANまたは細粒度ラベル）が続きます。
For a Layer 2 flow (that is, non-IP) the Flow Entropy field must specify the desired Ethernet header, including the MAC destination and source addresses as well as a VLAN tag or fine-grained label.
レイヤー2フロー（つまり、非IP）の場合、フローエントロピーフィールドは、MAC宛先と送信元アドレス、およびVLANタグまたはきめの細かいラベルを含む、必要なイーサネットヘッダーを指定する必要があります。
For a Layer 3 flow, the Flow Entropy field must specify the desired Ethernet header, the IP header, and UDP or TCP header fields, although the Ethernet-layer header fields are also still present.
レイヤー3フローの場合、フローエントロピーフィールドで目的のイーサネットヘッダー、IPヘッダー、UDPまたはTCPヘッダーフィールドを指定する必要がありますが、イーサネットレイヤーヘッダーフィールドも引き続き存在します。
Not all fields in the Flow Entropy field need to be identical to the data flow that the OAM message is mimicking. The only requirement is for the selected flow entropy to follow the same path as the data flow that it is mimicking. In other words, the selected flow entropy must result in the same ECMP selection or multicast pruning behavior or other applicable forwarding paradigm.
Flow Entropyフィールドのすべてのフィールドが、OAMメッセージが模倣しているデータフローと同一である必要はありません。唯一の要件は、選択したフローエントロピーが、模倣しているデータフローと同じパスをたどることです。つまり、選択されたフローエントロピーは、同じECMP選択、マルチキャストプルーニング動作、またはその他の適用可能な転送パラダイムをもたらす必要があります。
When performing diagnostics on user flows, the OAM mechanisms must allow the network operator to configure the flow entropy parameters (for example, Layer 2 and/or 3) on the RBridge from which the diagnostic operations are to be triggered.
ユーザーフローで診断を実行する場合、OAMメカニズムにより、ネットワークオペレーターは、診断操作がトリガーされるRBridgeでフローエントロピーパラメーター（たとえば、レイヤー2または3、あるいはその両方）を構成できる必要があります。
When running OAM functions over test flows, the TRILL OAM may provide a mechanism for discovering the flow entropy parameters by querying the RBridges dynamically, or it may allow the network operator to configure the flow entropy parameters.
テストフローでOAM機能を実行する場合、TRILL OAMは、RBridgeに動的にクエリを実行してフローエントロピーパラメーターを検出するメカニズムを提供するか、ネットワークオペレーターがフローエントロピーパラメーターを構成できるようにします。
Edge TRILL Switches, like traditional 802.1 bridges, are required to learn MAC address associations. Learning is accomplished either by snooping data packets or through other methods. The Flow Entropy field of TRILL OAM messages mimics real packets and may impact the address-learning process of the TRILL data plane. TRILL OAM is required to provide methods to prevent any learning of addresses from the Flow Entropy field of OAM messages that would interfere with normal TRILL operation. This can be done, for example, by suppressing/preventing MAC address learning from OAM messages.
従来の802.1ブリッジと同様に、エッジTRILLスイッチは、MACアドレスの関連付けを学習するために必要です。学習は、データパケットをスヌーピングするか、他の方法で行います。 TRILL OAMメッセージのFlow Entropyフィールドは実際のパケットを模倣しており、TRILLデータプレーンのアドレス学習プロセスに影響を与える可能性があります。 TRILL OAMは、通常のTRILL操作を妨げるOAMメッセージのFlow Entropyフィールドからのアドレスの学習を防ぐ方法を提供する必要があります。これは、たとえば、OAMメッセージからのMACアドレスラーニングを抑制または防止することによって実行できます。
The OAM Message Channel provides methods to communicate OAM-specific details between RBridges. CFM [802.1Q] and [RFC4379] have implemented OAM message channels. It is desirable to select an appropriate technology and reuse it, instead of redesigning yet another OAM channel. TRILL is a transport layer that carries Ethernet frames, so the TRILL OAM model specified earlier is based on the CFM [802.1Q] model. The use of the CFM [802.1Q] encoding format for the OAM Message Channel is one possible choice. [TRILL-OAM] presents a proposal on the use of CFM [802.1Q] payload as the OAM Message Channel.
OAMメッセージチャネルは、RBridge間でOAM固有の詳細を通信するメソッドを提供します。 CFM [802.1Q]および[RFC4379]はOAMメッセージチャネルを実装しています。さらに別のOAMチャネルを再設計するのではなく、適切なテクノロジーを選択して再利用することが望ましいです。 TRILLはイーサネットフレームを伝送するトランスポート層であるため、前に指定したTRILL OAMモデルはCFM [802.1Q]モデルに基づいています。 OAMメッセージチャネルにCFM [802.1Q]エンコード形式を使用することは、1つの選択肢です。 [TRILL-OAM]は、CFM [802.1Q]ペイロードをOAMメッセージチャネルとして使用することに関する提案を提示しています。
RBridges must be able to identify OAM messages that are destined to them, either individually or as a group, so as to properly process those messages.
RBridgeは、これらのメッセージを適切に処理するために、それらを宛先とするOAMメッセージを個別にまたはグループとして識別できる必要があります。
TRILL, as defined in [RFC6325], does not specify a method to identify OAM messages. The most reliable method to identify these messages, without imposing restrictions on the Flow Entropy field, involves modifying the definition of the TRILL Header to include an "Alert" flag. This flag signals that the content of the TRILL packet is a control message as opposed to user data. The use of such a flag would not be limited to TRILL OAM and may be leveraged by any other TRILL control protocol that requires in-band behavior. The TRILL Header currently has two reserved bits that are unused. One of those bits may be used as the Alert flag. In order to guarantee accurate in-band forwarding behavior, RBridges must not use the Alert flag in ECMP hashing decisions. Furthermore, to ensure that this flag remains protocol agnostic, TRILL OAM mechanisms must not rely solely on the Alert flag to identify OAM messages. Rather, these solutions must identify OAM messages based on the combination of the Alert flag and the OAM Ethertype.
[RFC6325]で定義されているTRILLは、OAMメッセージを識別する方法を指定していません。 Flow Entropyフィールドに制限を課すことなくこれらのメッセージを識別する最も信頼できる方法は、「アラート」フラグを含めるようにTRILLヘッダーの定義を変更することです。このフラグは、TRILLパケットの内容がユーザーデータではなく制御メッセージであることを示します。このようなフラグの使用はTRILL OAMに限定されず、帯域内動作を必要とする他のTRILL制御プロトコルによって活用される場合があります。 TRILLヘッダーには現在、未使用の2つの予約ビットがあります。これらのビットの1つをアラートフラグとして使用できます。正確な帯域内転送動作を保証するために、RBridgeはECMPハッシュ決定でAlertフラグを使用してはなりません。さらに、このフラグがプロトコルにとらわれないままであることを保証するために、TRILL OAMメカニズムはOAMメッセージを識別するためにアラートフラグだけに依存してはなりません。むしろ、これらのソリューションは、アラートフラグとOAM Ethertypeの組み合わせに基づいてOAMメッセージを識別する必要があります。
Since the above mechanism requires modification of the TRILL Header, it is not backward compatible. TRILL OAM solutions should provide alternate methods to identify OAM messages that work on existing RBridge implementations, thereby providing backward compatibility.
上記のメカニズムではTRILLヘッダーを変更する必要があるため、下位互換性はありません。 TRILL OAMソリューションは、既存のRBridge実装で機能するOAMメッセージを識別するための代替方法を提供する必要があります。これにより、下位互換性が提供されます。
Section 4.1 below discusses proactive fault management, and Section 4.2 discusses on-demand fault management.
以下のセクション4.1ではプロアクティブな障害管理について説明し、セクション4.2ではオンデマンドの障害管理について説明します。
Proactive fault management functions are configured by the network operator to run periodically without a time bound or are configured to trigger certain actions upon the occurrence of specific events.
プロアクティブな障害管理機能は、時間制限なしで定期的に実行されるようにネットワークオペレーターによって構成されているか、特定のイベントの発生時に特定のアクションをトリガーするように構成されています。
Proactive fault detection is performed by periodically monitoring the reachability between service endpoints, that is, MEPs in a given MA, through the exchange of Continuity Check messages. The reachability between any two arbitrary MEPs may be monitored for a specified path, all paths, or any representative path. The fact that TRILL networks do not enforce congruence between unicast and multicast paths means that the proactive fault detection mechanism must provide procedures to monitor the unicast paths independently of the multicast paths. Furthermore, where the network has ECMP, the proactive fault detection mechanism must be capable of exercising the equal-cost paths individually.
プロアクティブな障害検出は、継続性チェックメッセージの交換を通じて、サービスエンドポイント、つまり特定のMA内のMEP間の到達可能性を定期的に監視することによって実行されます。任意の2つの任意のMEP間の到達可能性は、指定されたパス、すべてのパス、または任意の代表的なパスについて監視できます。 TRILLネットワークがユニキャストパスとマルチキャストパス間の合同を強制しないという事実は、予防的障害検出メカニズムがマルチキャストパスとは無関係にユニキャストパスを監視する手順を提供する必要があることを意味します。さらに、ネットワークにECMPがある場合、予防的障害検出メカニズムは、等コストパスを個別に実行できなければなりません。
The set of MEPs exchanging Continuity Check messages in a given domain and for a specific monitored entity (flow, network, or service) must use the same transmission period. As long as the fault detection mechanism involves MEPs transmitting periodic heartbeat messages independently, then this OAM procedure is not affected by the lack of forward/reverse path symmetry in TRILL.
特定のドメインで、特定の監視対象エンティティ（フロー、ネットワーク、またはサービス）のContinuity Checkメッセージを交換するMEPのセットは、同じ送信期間を使用する必要があります。障害検出メカニズムが定期的なハートビートメッセージを個別に送信するMEPを含む限り、このOAM手順はTRILLでのフォワード/リバースパス対称性の欠如による影響を受けません。
The proactive fault detection function must detect the following types of defects:
プロアクティブな障害検出機能は、次のタイプの欠陥を検出する必要があります。
- Loss of continuity to one or more remote MEPs
- 1つ以上のリモートMEPへの連続性の喪失
- Unexpected connectivity between isolated VLANs or fine-grained labels (mismerge)
- 分離されたVLANまたは細かいラベル間の予期しない接続（ミスマージ）
- Unexpected connectivity to one or more remote MEPs
- 1つ以上のリモートMEPへの予期しない接続
- Mismatch of the Continuity Check transmission period between MEPs
- MEP間のContinuity Check送信期間の不一致
TRILL OAM must support event-driven defect indication upon the detection of a connectivity defect. Defect indications can be categorized into two types; these types are discussed in the following subsections.
TRILL OAMは、接続障害の検出時にイベント駆動型の障害表示をサポートする必要があります。欠陥の兆候は2つのタイプに分類できます。これらのタイプについては、次のサブセクションで説明します。
Forward defect indication is used to signal a failure that is detected by a lower-layer OAM mechanism. A forward defect indication is transmitted away from the direction of the failure. For example, consider a simple network comprised of four RBridges connected in series: RB1, RB2, RB3, and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4.
前方障害表示は、下位層のOAMメカニズムによって検出された障害を通知するために使用されます。前方欠陥表示は、障害の方向から離れて送信されます。たとえば、直列に接続された4つのRBridgeで構成される単純なネットワーク、RB1、RB2、RB3、およびRB4について考えます。 RB1とRB4はどちらもTRILL OAM MEPをホストしていますが、RB2とRB3はMIPを持っています。 RB2とRB3の間のリンクに障害が発生した場合、RB2はRB1に向けて転送不良表示を送信でき、RB3はRB4に向けて転送不良表示を送信します。
Forward defect indication may be used for alarm suppression and/or for the purpose of interworking with other layer OAM protocols. Alarm suppression is useful when a transport/network-level fault translates to multiple service- or flow-level faults. In such a scenario, it is enough to alert a network management station (NMS) of the single transport/network-level fault in lieu of flooding that NMS with a multitude of Service or Flow granularity alarms.
前方欠陥表示は、アラーム抑制や他のレイヤーOAMプロトコルとの相互作用の目的で使用できます。アラーム抑制は、トランスポート/ネットワークレベルの障害が複数のサービスレベルまたはフローレベルの障害に変換される場合に役立ちます。このようなシナリオでは、フラッディングの代わりに、単一のトランスポート/ネットワークレベルの障害をネットワーク管理ステーション（NMS）に通知するだけで十分です。
RDI is used to signal that the advertising MEP has detected a loss-of-continuity defect. RDI is transmitted in the direction of the failure. For example, consider the same series network as that in Section 4.1.2.1. If RB1 detects that is has lost connectivity to RB4 because it is no longer receiving Continuity Check messages from the MEP on RB4, then RB1 can transmit an RDI towards RB4 to inform the latter of the failure. If the failure is unidirectional (it is affecting the direction from RB4 to RB1), then the RDI enables RB4 to become aware of the unidirectional connectivity anomaly.
RDIは、アドバタイジングMEPが連続性の損失の欠陥を検出したことを通知するために使用されます。 RDIは障害の方向に送信されます。たとえば、4.1.2.1と同じシリーズネットワークを考えます。 RB4のMEPから継続性チェックメッセージを受信していないためにRB1がRB4への接続を失ったことを検出した場合、RB1はRDIをRB4に送信して障害を通知できます。障害が単方向である（RB4からRB1への方向に影響している）場合、RDIはRB4が単方向の接続異常を認識できるようにします。
In the presence of equal-cost paths between MEPs, RDI must be able to identify on which equal-cost path the failure was detected.
MEP間に等コストパスが存在する場合、RDIは、どの等コストパスで障害が検出されたかを識別できる必要があります。
RDI allows single-sided management, where the network operator can examine the state of a single MEP and deduce the overall health of a monitored entity (network, flow, or service).
RDIを使用すると、ネットワーク管理者が単一のMEPの状態を調べて、監視対象エンティティ（ネットワーク、フロー、またはサービス）の全体的な状態を推定できる、片側管理が可能になります。
On-demand fault management functions are initiated manually by the network operator either as a one-time occurrence or as an action/test that continues for a time bound period. These functions enable the operator to run diagnostics to investigate a defect condition.
オンデマンドの障害管理機能は、1回限りの発生として、または一定期間継続するアクション/テストとして、ネットワークオペレーターによって手動で開始されます。これらの機能により、オペレーターは診断を実行して欠陥状態を調査できます。
As specified in [RFC6905], TRILL OAM must support on-demand Connectivity Verification for unicast and multicast. The Connectivity-Verification mechanism must provide a means for specifying and carrying in the messages:
[RFC6905]で指定されているように、TRILL OAMは、ユニキャストおよびマルチキャストのオンデマンド接続検証をサポートする必要があります。接続性検証メカニズムは、メッセージを指定して運ぶ手段を提供する必要があります。
- variable-length payload/padding to test MTU-related connectivity problems.
- MTU関連の接続問題をテストするための可変長ペイロード/パディング。
- test message formats as defined in [RFC2544].
- [RFC2544]で定義されているメッセージ形式をテストします。
A unicast Connectivity Verification operation must be initiated from a MEP and may target either a MIP or another MEP. For unicast, Connectivity Verification can be performed at either Network or Flow granularity.
ユニキャスト接続検証操作はMEPから開始する必要があり、MIPまたは別のMEPのいずれかをターゲットにすることができます。ユニキャストの場合、接続検証はネットワークまたはフローのいずれかの粒度で実行できます。
Connectivity verification at the Network granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over a test flow in a test VLAN or fine-grained label. The operator must supply the source and target RBridges for the operation, and the test VLAN/flow information uses pre-set values or defaults.
ネットワーク細分性での接続検証は、ソースRBridge上のMEPとターゲットRBridge上のMIPまたはMEPの間の接続を、テストVLANまたは細粒度ラベルのテストフローでテストします。オペレーターは操作のソースとターゲットのRBridgeを提供する必要があり、テストVLAN /フロー情報は事前設定された値またはデフォルトを使用します。
Connectivity Verification at the Flow granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over an operator-specified VLAN or fine-grained label with operator-specified flow parameters.
フロー粒度での接続性検証では、オペレーターが指定したVLANまたはオペレーターが指定したフローパラメーターを使用したきめの細かいラベルを介して、ソースRBridge上のMEPとターゲットRBridge上のMIPまたはMEP間の接続性をテストします。
The above functions must be supported on sections, as defined in [RFC6905]. When Connectivity Verification is triggered over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated Connectivity Verification messages. The operator must supply the edge RBridge nickname as part of the operation parameters.
上記の関数は、[RFC6905]で定義されているように、セクションでサポートされている必要があります。セクションで接続検証がトリガーされ、開始MEPがエッジ（入力）RBridgeと一致しない場合、MEPは関連する接続検証メッセージでローカルRBridgeニックネームの代わりにエッジRBridgeニックネームを使用する必要があります。オペレーターは、操作パラメーターの一部としてエッジRBridgeニックネームを指定する必要があります。
For multicast, the Connectivity Verification function tests all branches and leaf nodes of a multi-destination distribution tree for reachability. This function should include mechanisms to prevent reply storms from overwhelming the initiating RBridge. This may be done, for example, by staggering the replies through the introduction of a random delay timer, with a preset upper bound, on the responding RBridge (CFM [802.1Q] uses similar mechanisms for Linktrace Reply messages to mitigate the load on the originating MEP). The upper bound on the timer value should be selected by the OAM solution to be long enough to accommodate large distribution trees, while allowing the Connectivity Verification operation to conclude within a reasonable time. To further prevent reply storms, Connectivity Verification operation is initiated from a MEP and must target MEPs only. MIPs are transparent to multicast Connectivity Verification.
マルチキャストの場合、接続検証機能は、複数の宛先の配信ツリーのすべてのブランチとリーフノードに到達可能かどうかをテストします。この機能には、応答ストームが開始RBridgeを圧倒しないようにするメカニズムを含める必要があります。これは、たとえば、応答するRBridgeにランダムな遅延タイマーを導入し、事前に上限を設定して応答をずらすことで実行できます（CFM [802.1Q]は、Linktrace Replyメッセージに同様のメカニズムを使用して、元のMEP）。タイマー値の上限は、OAMソリューションによって、大規模な配信ツリーに対応できるだけの長さになるように選択する必要がありますが、接続検証操作は妥当な時間内に完了できます。応答ストームをさらに防止するために、接続検証操作はMEPから開始され、MEPのみをターゲットにする必要があります。 MIPはマルチキャスト接続検証に対して透過的です。
Per [RFC6905], multicast Connectivity Verification must provide the following granularity of operation:
[RFC6905]に従い、マルチキャスト接続検証は次の粒度の操作を提供する必要があります。
A. Un-pruned Tree
A.剪定されていない木
- Connectivity Verification for un-pruned multi-destination distribution tree. The operator in this case supplies the tree identifier (root nickname) and campus-wide diagnostic VLAN or fine-grained label.
- 剪定されていない複数宛先の配布ツリーの接続検証。この場合のオペレーターは、ツリー識別子（ルートニックネーム）とキャンパス全体の診断VLANまたは詳細なラベルを提供します。
B. Pruned Tree
B.剪定木
- Connectivity Verification for a VLAN or fine-grain label in a given multi-destination distribution tree. The operator in this case supplies the tree identifier and VLAN or fine-grained label.
- 特定の複数宛先配布ツリー内のVLANまたは細粒度ラベルの接続検証。この場合のオペレーターは、ツリー識別子とVLANまたは細かいラベルを提供します。
- Connectivity Verification for an IP multicast group in a given multi-destination distribution tree. The operator in this case supplies: the tree identifier, VLAN or fine-grained label, and IP (S,G) or (*,G).
- 特定の複数宛先配布ツリー内のIPマルチキャストグループの接続検証。この場合のオペレーターは、ツリーID、VLANまたは細粒度ラベル、およびIP（S、G）または（*、G）を提供します。
TRILL OAM must support an on-demand connectivity fault localization function. This is the capability to trace the path of a flow on a hop-by-hop (RBridge-by-RBridge) basis to isolate failures. This involves the capability to narrow down the locality of a fault to a particular port, link, or node. The characteristic of forward/reverse path asymmetry, in TRILL, renders Fault Isolation into a direction-sensitive operation. That is, given two RBridges, A and B, localization of connectivity faults between them requires running Fault Isolation procedures from RBridge A to RBridge B as well as from RBridge B to RBridge A. Generally speaking, single-sided Fault Isolation is not possible in TRILL OAM.
TRILL OAMは、オンデマンド接続障害のローカライズ機能をサポートする必要があります。これは、ホップバイホップ（RBridge-by-RBridge）ベースでフローのパスをトレースして、障害を分離する機能です。これには、障害の局所性を特定のポート、リンク、またはノードに絞り込む機能が含まれます。 TRILLの順方向/逆方向経路の非対称性の特徴により、障害分離が方向に依存する操作になります。つまり、AとBの2つのRBridgeがある場合、それらの間の接続障害を特定するには、RBridge AからRBridge Bへ、およびRBridge BからRBridge Aへの障害分離手順を実行する必要があります。一般に、片側の障害分離は、 TRILL OAM。
Furthermore, TRILL OAM should support Fault Isolation over distribution trees for both un-pruned as well as pruned trees. The former allows the tracing of all active branches of a tree, whereas the latter allows tracing of the active subset of branches associated with a given flow.
さらに、TRILL OAMは、プルーニングされていないツリーとプルーニングされたツリーの両方について、配布ツリー上の障害分離をサポートする必要があります。前者はツリーのすべてのアクティブなブランチのトレースを許可しますが、後者は特定のフローに関連付けられたブランチのアクティブなサブセットのトレースを許可します。
Performance monitoring functions are optional in TRILL OAM, per [RFC6905]. These functions can be performed both proactively and on-demand. Proactive management involves a scheduling function, where the performance monitoring probes can be triggered on a recurring basis. Since the basic performance monitoring functions involved are the same, we make no distinction between proactive and on-demand functions in this section.
[RFC6905]に従い、TRILL OAMではパフォーマンス監視機能はオプションです。これらの機能は、プロアクティブにもオンデマンドにも実行できます。プロアクティブな管理には、スケジュール機能が含まれます。この機能では、パフォーマンスモニタリングプローブを繰り返しトリガーできます。関連する基本的なパフォーマンス監視機能は同じであるため、このセクションではプロアクティブ機能とオンデマンド機能を区別しません。
Given that TRILL provides inherent support for multipoint-to-multipoint connectivity, then packet loss cannot be accurately measured by means of counting user data packets. This is because user packets can be delivered to more RBridges or more ports than are necessary (for example, due to broadcast, un-pruned multicast, or unknown unicast flooding). As such, a statistical means of approximating packet loss rate is required. This can be achieved by sending "synthetic" (TRILL OAM) packets that are counted only by those ports (MEPs) that are required to receive them. This provides a statistical approximation of the number of data frames lost, even with multipoint-to-multipoint connectivity. TRILL OAM mechanisms for synthetic packet loss measurement should follow the statistical considerations specified in [MEF35], especially with regard to the volume/frequency of synthetic traffic generation and associated impact on packet loss count accuracy.
TRILLがマルチポイントツーマルチポイント接続の固有のサポートを提供する場合、ユーザーデータパケットをカウントしてパケット損失を正確に測定することはできません。これは、ユーザーパケットが必要以上のRBridgeまたはポートに配信される可能性があるためです（たとえば、ブロードキャスト、剪定されていないマルチキャスト、または不明なユニキャストフラッディングが原因で）。そのため、パケット損失率を概算する統計的手段が必要です。これは、受信に必要なポート（MEP）でのみカウントされる「合成」（TRILL OAM）パケットを送信することで実現できます。これにより、マルチポイントツーマルチポイント接続であっても、失われたデータフレーム数の統計的概算が得られます。合成パケット損失測定のTRILL OAMメカニズムは、特に合成トラフィック生成の量/頻度とパケット損失カウント精度への関連する影響に関して、[MEF35]で指定された統計的考慮事項に従う必要があります。
Packet loss probes must be initiated from a MEP and must target a MEP. This function should be supported on sections, as defined in [RFC6905]. When packet loss is measured over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated loss measurement messages. The user must supply the edge RBridge nickname as part of the operation parameters.
パケット損失プローブは、MEPから開始し、MEPをターゲットにする必要があります。この関数は、[RFC6905]で定義されているように、セクションでサポートされている必要があります。セクションでパケット損失が測定され、開始MEPがエッジ（入力）RBridgeと一致しない場合、MEPは、関連する損失測定メッセージでローカルRBridgeニックネームではなく、エッジRBridgeニックネームを使用する必要があります。ユーザーは、エッジRBridgeニックネームを操作パラメーターの一部として指定する必要があります。
TRILL OAM mechanisms should support one-way and two-way Packet Loss Monitoring. In one-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter is responsible for calculating the loss in the direction from the source RBridge towards the target RBridge. In two-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet loss in both directions (source to target and target to source).
TRILL OAMメカニズムは、一方向および双方向のパケット損失監視をサポートする必要があります。一方向モニタリングでは、ソースRBridgeがターゲットRBridgeへのパケット損失モニタリングメッセージをトリガーし、後者はソースRBridgeからターゲットRBridgeへの方向の損失を計算します。双方向監視では、ソースRBridgeがターゲットRBridgeへのパケット損失監視メッセージをトリガーし、ターゲットRBridgeは応答メッセージでソースに応答します。その後、ソースRBridgeは、両方向（ソースからターゲット、およびターゲットからソース）のパケット損失を監視できます。
Packet delay is measured by inserting timestamps in TRILL OAM packets. In order to ensure high accuracy of measurement, TRILL OAM must specify the timestamp location at fixed offsets within the OAM packet in order to facilitate hardware-based timestamping. Hardware implementations must implement the timestamping function as close to the wire as practical in order to maintain high accuracy.
パケット遅延は、TRILL OAMパケットにタイムスタンプを挿入することで測定されます。高精度の測定を保証するために、TRILL OAMは、ハードウェアベースのタイムスタンプを容易にするために、OAMパケット内の固定オフセットでタイムスタンプの場所を指定する必要があります。ハードウェアの実装では、高い精度を維持するために、タイムスタンプ機能をできるだけワイヤの近くに実装する必要があります。
TRILL OAM mechanisms should support one-way and two-way Packet Delay Monitoring. In one-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter is responsible for calculating the delay in the direction from the source RBridge towards the target RBridge. This requires synchronization of the clocks between the two RBridges. In two-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet delay in both directions (source to target and target to source) as well as the cumulative round-trip delay. In this case as well, monitoring the delay in a single direction requires clock synchronization between the two RBridges, whereas monitoring the round-trip delay does not require clock synchronization. Mechanisms for clock synchronization between RBridges are outside the scope of this document.
TRILL OAMメカニズムは、一方向および双方向のパケット遅延監視をサポートする必要があります。一方向モニタリングでは、ソースRBridgeがターゲットRBridgeへのパケット遅延モニタリングメッセージをトリガーし、後者はソースRBridgeからターゲットRBridgeへの方向の遅延を計算します。これには、2つのRBridge間のクロックの同期が必要です。双方向監視では、ソースRBridgeがターゲットRBridgeへのパケット遅延監視メッセージをトリガーし、ターゲットRBridgeが応答メッセージでソースに応答します。次に、ソースRBridgeは、両方向（ソースからターゲット、およびターゲットからソース）のパケット遅延と、累積往復遅延を監視できます。この場合も、単一方向の遅延の監視には2つのRBridge間のクロック同期が必要ですが、往復遅延の監視にはクロック同期は必要ありません。 RBridge間のクロック同期のメカニズムは、このドキュメントの範囲外です。
RBridges may be configured to enable TRILL OAM functions via the device Command Line Interface (CLI) or through one of the defined management protocols, such as the Simple Network Management Protocol (SNMP) [RFC3410] or the Network Configuration Protocol (NETCONF) [RFC6241].
RBridgesは、デバイスのコマンドラインインターフェース（CLI）を介して、または簡易ネットワーク管理プロトコル（SNMP）[RFC3410]やネットワーク構成プロトコル（NETCONF）[RFC6241 ]。
In order to maintain the plug-and-play characteristics of TRILL, the number of parameters that need to be configured on RBridges, in order to activate TRILL OAM, should be kept to a minimum. To that end, TRILL OAM mechanisms should rely on default values and auto-discovery mechanisms (for example, leveraging IS-IS) where applicable. The following is a non-exhaustive list of configuration parameters that apply to TRILL OAM.
TRILLのプラグアンドプレイ特性を維持するには、TRILL OAMをアクティブにするためにRBridgeで構成する必要があるパラメーターの数を最小限に抑える必要があります。そのために、TRILL OAMメカニズムは、デフォルト値と自動検出メカニズム（たとえば、IS-ISの活用）に依存する必要があります。以下は、TRILL OAMに適用される構成パラメーターの完全ではないリストです。
- Maintenance Domain Name An alphanumeric name for the Maintenance Domain. This is an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used. The recommended default value is the character string "DEFAULT".
- メンテナンスドメイン名メンテナンスドメインの英数字の名前。これはIETF [RFC2579] DisplayStringですが、文字コード0〜31（10進数）は使用されません。推奨されるデフォルト値は、文字列「DEFAULT」です。
- Maintenance Domain Level An integer in the range 0 to 7 indicating the level at which the Maintenance Domain is to be created. Default value is 0.
- メンテナンスドメインレベルメンテナンスドメインを作成するレベルを示す0〜7の範囲の整数。デフォルト値は0です。
- MA Name An alphanumeric name that uniquely identifies the Maintenance Association. This is an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used. The recommended default value is a character string set to the value of the VLAN or fine-grained label as "vl" or "fgl" concatenated with the VLAN ID or FGL ID as an unsigned decimal integer, for example, "vl42".
- MA名メンテナンスアソシエーションを一意に識別する英数字の名前。これはIETF [RFC2579] DisplayStringですが、文字コード0〜31（10進数）は使用されません。推奨されるデフォルト値は、「vl」または「fgl」などのVLANまたはファイングレインラベルの値に設定された文字列で、符号なしの10進整数として「vl42」などのVLAN IDまたはFGL IDと連結されます。
- List of MEP Identifiers A list of the identifiers of the MEPs that belong to the MA. This is optional and required only if the operator wants to detect missing MEPs as part of the Continuity Check function.
- MEP識別子のリストMAに属するMEPの識別子のリスト。これはオプションであり、オペレーターが連続性チェック機能の一部として欠落しているMEPを検出する場合にのみ必要です。
- MEP Identifier An integer, unique over a given Maintenance Association, identifying a specific MEP. CFM [802.1Q] limits this to the range 1 to 8191. This document recommends expanding the range from 1 to 65535 so that the RBridge nickname can be used as a default value. This will help keep TRILL OAM low-touch in terms of configuration overhead.
- MEP識別子特定のMEPを識別する、所定のメンテナンスアソシエーション上で一意の整数。 CFM [802.1Q]は、これを1から8191の範囲に制限します。このドキュメントでは、RBridgeニックネームをデフォルト値として使用できるように、1から65535の範囲を拡大することを推奨しています。これにより、設定のオーバーヘッドの面でTRILL OAMを簡単に保つことができます。
- Direction Indicates whether this is an UP MEP or DOWN MEP.
- 方向これがUP MEPかDOWN MEPかを示します。
- Associated Interface Specifies the interface on which the MEP is configured.
- 関連付けられたインターフェイスMEPが構成されているインターフェイスを指定します。
- MA Context Specifies the Maintenance Association to which the MEP belongs.
- MAコンテキストMEPが属するメンテナンスアソシエーションを指定します。
- Transmission Interval Indicates the interval at which Continuity Check messages are sent by a MEP.
- 送信間隔MEPがContinuity Checkメッセージを送信する間隔を示します。
- Loss Threshold Indicates the number of consecutive Continuity Check messages that a MEP must not receive from any one of the other MEPs in its MA before indicating either a MEP failure or a network failure. Recommended default value is 3.
- 損失しきい値MEP障害またはネットワーク障害のいずれかを示す前に、MEPがMA内の他のMEPのいずれからも受信してはならない連続性チェックメッセージの数を示します。推奨デフォルト値は3です。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Continuity Check messages.
- VLAN、きめの細かいラベル、およびフローパラメータ導通チェックメッセージで使用されるVLANまたはきめの細かいラベルとフローパラメータ。
- Hop Count The hop count to be used in the Continuity Check messages.
- ホップカウント導通チェックメッセージで使用されるホップカウント。
- MA context Specifies the Maintenance Association in which the Connectivity Verification operation is to be performed.
- MAコンテキスト接続検証操作が実行されるメンテナンスアソシエーションを指定します。
- Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group For unicast, the nickname of the RBridge that is the target of the Connectivity Verification operation. For multicast, the target Tree Identifier for un-pruned tree verification or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree verification.
- ターゲットRBridgeニックネーム（ユニキャスト）、ツリー識別子（マルチキャスト）、およびIPマルチキャストグループユニキャストの場合、接続検証操作のターゲットであるRBridgeのニックネーム。マルチキャストの場合、剪定されていないツリー検証のターゲットツリー識別子、または剪定されたツリー検証のツリー識別子とIPマルチキャストグループ（S、G）または（*、G）。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Connectivity Verification message.
- VLAN、ファイングレインラベル、およびフローパラメーター接続検証メッセージで使用されるVLANまたはファイングレインラベルおよびフローパラメーター。
- Operation Timeout Value The timeout on the initiating MEP before the Connectivity Verification operation is declared to have failed. The recommended default value is 5 seconds.
- 操作のタイムアウト値接続検証操作が失敗したと宣言される前の開始MEPのタイムアウト。推奨されるデフォルト値は5秒です。
- Repeat Count The number of Connectivity Verification messages that must be transmitted per operation. The recommended default value is 1.
- Repeat Count操作ごとに送信する必要がある接続検証メッセージの数。推奨されるデフォルト値は1です。
- Hop Count The hop count to be used in the Connectivity Verification messages.
- ホップ数接続検証メッセージで使用されるホップ数。
- Reply Mode Indicates whether the response to the Connectivity Verification operation should be sent in-band or out-of-band.
- 応答モード接続検証操作への応答をインバンドまたはアウトオブバンドのどちらで送信するかを示します。
- Scope List (Multicast) List of MEP Identifiers that must respond to the message.
- スコープリスト（マルチキャスト）メッセージに応答する必要のあるMEP識別子のリスト。
- MA Context Specifies the Maintenance Association in which the Fault Isolation operation is to be performed.
- MAコンテキスト障害分離操作が実行されるメンテナンスアソシエーションを指定します。
- Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group For unicast, the nickname of the RBridge that is the target of the Fault Isolation operation. For multicast, the target Tree Identifier for un-pruned tree tracing or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree tracing.
- ターゲットRBridgeニックネーム（ユニキャスト）、ツリー識別子（マルチキャスト）、およびIPマルチキャストグループユニキャストの場合、障害分離操作のターゲットであるRBridgeのニックネーム。マルチキャストの場合、プルーニングされていないツリートレースのターゲットツリー識別子、またはプルーニングされたツリートレースのツリー識別子とIPマルチキャストグループ（S、G）または（*、G）。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grain label and flow parameters to be used in the Fault Isolation messages.
- VLAN、細粒度ラベル、およびフローパラメーター障害分離メッセージで使用されるVLANまたは細粒度ラベルおよびフローパラメーター。
- Operation Timeout Value The timeout on the initiating MEP before the Fault Isolation operation is declared to have failed. The recommended default value is 5 seconds.
- 操作タイムアウト値障害分離操作が失敗したと宣言される前の、開始MEPのタイムアウト。推奨されるデフォルト値は5秒です。
- Hop Count The hop count to be used in the Fault Isolation messages.
- ホップ数障害分離メッセージで使用されるホップ数。
- Reply Mode Indicates whether the response to the Fault Isolation operation should be sent in-band or out-of-band.
- 応答モード障害分離操作への応答を帯域内または帯域外のどちらで送信するかを示します。
- Scope List (Multicast) List of MEP Identifiers that must respond to the message.
- スコープリスト（マルチキャスト）メッセージに応答する必要のあるMEP識別子のリスト。
- MA Context Specifies the Maintenance Association in which the Packet Loss Monitoring operation is to be performed.
- MAコンテキストパケット損失監視操作が実行されるメンテナンスアソシエーションを指定します。
- Target RBridge Nickname The nickname of the RBridge that is the target of the Packet Loss Monitoring operation.
- ターゲットRBridgeニックネームパケット損失監視操作のターゲットであるRBridgeのニックネーム。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Packet Loss Monitoring messages.
- VLAN、細粒度ラベル、およびフローパラメータパケット損失監視メッセージで使用されるVLANまたは細粒度ラベルおよびフローパラメータ。
- Transmission Rate The transmission rate at which the Packet Loss Monitoring messages are to be sent.
- 伝送速度パケット損失監視メッセージが送信される伝送速度。
- Monitoring Interval The total duration of time for which a single Packet Loss Monitoring probe is to continue.
- モニタリング間隔単一のパケット損失モニタリングプローブが継続する合計時間。
- Repeat Count The number of probe operations to be performed. For on-demand monitoring, this is typically set to 1. For proactive monitoring, this may be set to allow for infinite monitoring.
- Repeat Count実行されるプローブ操作の数。オンデマンドモニタリングの場合、これは通常1に設定されます。プロアクティブモニタリングの場合、これは無限モニタリングを許可するように設定できます。
- Hop Count The hop count to be used in the Packet Loss Monitoring messages.
- ホップカウントパケット損失監視メッセージで使用されるホップカウント。
- Mode Indicates whether one-way or two-way loss measurement is required.
- モード一方向または双方向の損失測定が必要かどうかを示します。
- MA Context Specifies the Maintenance Association in which the Packet Delay Monitoring operation is to be performed
- MAコンテキストパケット遅延監視操作が実行されるメンテナンスアソシエーションを指定します
- Target RBridge Nickname The nickname of the RBridge that is the target of the Packet Delay Monitoring operation.
- ターゲットRBridgeニックネームパケット遅延監視操作のターゲットであるRBridgeのニックネーム。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Packet Delay Monitoring messages.
- VLAN、細粒度ラベル、およびフローパラメータパケット遅延監視メッセージで使用されるVLANまたは細粒度ラベルおよびフローパラメータ。
- Transmission Rate The transmission rate at which the Packet Delay Monitoring messages are to be sent.
- 伝送速度パケット遅延監視メッセージが送信される伝送速度。
- Monitoring Interval The total duration of time for which a single Packet Delay Monitoring probe is to continue.
- モニタリング間隔単一のパケット遅延モニタリングプローブが継続する合計時間。
- Repeat Count The number of probe operations to be performed. For on-demand monitoring, this is typically set to 1. For proactive monitoring this may be set to allow for infinite monitoring.
- Repeat Count実行されるプローブ操作の数。オンデマンドモニタリングの場合、これは通常1に設定されます。プロアクティブモニタリングの場合、これは無限モニタリングを許可するように設定できます。
- Hop Count The hop count to be used in the Packet Delay Monitoring messages.
- ホップ数パケット遅延監視メッセージで使用されるホップ数。
- Mode Indicates whether one-way or two-way delay measurement is required.
- モード一方向または双方向の遅延測定が必要かどうかを示します。
TRILL OAM mechanisms should trigger notifications to alert operators to certain conditions. Such conditions include but are not limited to:
TRILL OAMメカニズムは、特定の条件についてオペレーターに警告する通知をトリガーする必要があります。このような条件には次のものが含まれますが、これらに限定されません。
- Faults detected by proactive mechanisms.
- 予防的なメカニズムによって検出された障害。
- Reception of event-driven defect indications.
- イベント駆動型の欠陥表示の受信。
- Logged security incidents pertaining to the OAM Message Channel.
- OAMメッセージチャネルに関連するログに記録されたセキュリティインシデント。
- Protocol errors (for example, as caused by misconfiguration).
- プロトコルエラー（たとえば、構成の誤りが原因）。
Notifications generated by TRILL OAM mechanisms may be via SNMP, Syslog messages [RFC5424], or any other standard management protocol that supports asynchronous notifications.
TRILL OAMメカニズムによって生成された通知は、SNMP、Syslogメッセージ[RFC5424]、または非同期通知をサポートするその他の標準管理プロトコルを介する場合があります。
When performing the optional TRILL OAM performance monitoring functions, two RBridge designations are involved: a source RBridge and a target RBridge. The source RBridge is the one from which the performance monitoring probe is initiated, and the target RBridge is the destination of the probe. The goal is to monitor performance characteristics between the two RBridges. The RBridge from which the network operator can extract the results of the probe (the performance monitoring metrics) depends on whether one-way or two-way performance monitoring functions are performed:
オプションのTRILL OAMパフォーマンス監視機能を実行する場合、ソースRBridgeとターゲットRBridgeの2つのRBridge指定が含まれます。ソースRBridgeは、パフォーマンスモニタリングプローブの開始元であり、ターゲットRBridgeはプローブの宛先です。目標は、2つのRBridge間のパフォーマンス特性を監視することです。ネットワークオペレーターがプローブの結果（パフォーマンスモニタリングメトリック）を抽出できるRBridgeは、一方向または双方向のどちらのパフォーマンスモニタリング機能が実行されるかによって異なります。
- In the case of one-way performance monitoring functions, the metrics will be available at the target RBridge.
- 一方向のパフォーマンス監視機能の場合、メトリックはターゲットのRBridgeで使用できます。
- In the case of two-way performance monitoring functions, all the metrics will be available at the source RBridge, and a subset will be available at the target RBridge. More specifically, metrics in the direction from source to target as well as the direction from target to source will be available at the source RBridge. Metrics in the direction from source to target will be available at the target RBridge.
- 双方向のパフォーマンス監視機能の場合、すべてのメトリックはソースRBridgeで利用でき、サブセットはターゲットRBridgeで利用できます。より具体的には、ソースからターゲットへの方向とターゲットからソースへの方向のメトリックは、ソースRBridgeで使用できます。ソースからターゲットへの方向のメトリックは、ターゲットRBridgeで使用できます。
TRILL OAM must provide mechanisms for:
TRILL OAMは、以下のメカニズムを提供する必要があります。
- Preventing denial-of-service attacks caused by exploitation of the OAM Message Channel, where a rogue device may overload the RBridges and the network with OAM messages. This could lead to interruption of the OAM services and, in the extreme case, disrupt network connectivity. Mechanisms such as control-plane policing combined with shaping or rate limiting of OAM messaging can be employed to mitigate this.
- 悪意のあるデバイスがRBridgeとネットワークにOAMメッセージで過負荷をかける可能性があるOAMメッセージチャネルの悪用によって引き起こされるサービス拒否攻撃の防止。これは、OAMサービスの中断につながる可能性があり、極端な場合には、ネットワーク接続を中断させる可能性があります。これを緩和するために、OAMメッセージングのシェーピングまたはレート制限と組み合わせたコントロールプレーンポリシングなどのメカニズムを使用できます。
- Optionally authenticating at communicating endpoints (MEPs and MIPs) that an OAM message has originated at an appropriate communicating endpoint.
- オプションで、OAMメッセージが適切な通信エンドポイントで発信されたことを通信エンドポイント（MEPおよびMIP）で認証します。
- Preventing TRILL OAM packets from leaking outside of the TRILL network or outside their corresponding Maintenance Domain. This can be done by having MEPs implement a filtering function based on the Maintenance Level associated with received OAM packets.
- TRILL OAMパケットがTRILLネットワークの外部または対応するメンテナンスドメインの外部に漏洩しないようにします。これは、MEPに、受信したOAMパケットに関連付けられたメンテナンスレベルに基づいてフィルタリング機能を実装させることで実現できます。
For general TRILL Security Considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
We thank Gayle Noble, Dan Romascanu, Olen Stokes, Susan Hares, Ali Karimi, and Prabhu Raj for their thorough review of this work and their comments.
ゲイルノーブル、ダンロマスカヌ、オーレンストークス、スーザンヘアーズ、アリカリミ、プラブーラージのこの作品の徹底的なレビューとコメントに感謝します。
[802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Overview and Architecture", IEEE Std 802-2001, 8 March 2002.
[802] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Overview and Architecture」、IEEE Std 802-2001、8 March 2002。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks", IEEE Std 802.1Q-2011, 31 August 2011.
[802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridge Local Area Networks」、IEEE Std 802.1Q-2011、31 August 2011。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S.およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、1999年3月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
[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.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、2011年6月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[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.
[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月。
[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.
[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 。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3-2012, December 2012.
[802.3] IEEE、「情報技術に関するIEEE規格-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート3：衝突検知（CSMA / CD）アクセス方式によるキャリアセンスマルチアクセスおよび物理層の仕様」 、IEEE Std 802.3-2012、2012年12月。
[ISO/IEC7498-4] ISO/IEC, "Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management framework", ISO/IEC 7498-4, 1989.
[ISO / IEC7498-4] ISO / IEC、「情報処理システム-オープンシステム相互接続-基本参照モデル-パート4：管理フレームワーク」、ISO / IEC 7498-4、1989。
[MEF35] Metro Ethernet Forum, "MEF 35 - Service OAM Performance Monitoring Implementation Agreement", April 2012.
[MEF35]メトロイーサネットフォーラム、「MEF 35-Service OAM Performance Monitoring Implementation Agreement」、2012年4月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、Ed。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「Introduction and Applicability Statements for Internet-Standard Management Framework」、RFC 3410、2002年12月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、and M. Betts、Ed。、 "Requirements for Operations、Administration、and Maintenance（OAM）in MPLS Transport Networks"、RFC 5860、May 2010 。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、A。Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361] Carlson、J。およびD. Eastlake 3度、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、2011年8月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I.、Ed。およびD. Allan、Ed。、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC7087] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013.
[RFC7087] van Helvoort、H.、Ed。、Andersson、L.、Ed。、and N. Sprecher、Ed。、 "A Interpretation for the Interpretation of Terminology Used in MPLS Transport Profile（MPLS-TP）Internet-Drafts and ITU-Tのトランスポートネットワーク推奨事項に関連するRFC」、RFC 7087、2013年12月。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「Transparent Interconnection of Lots of Links（TRILL）：Bidirectional Forwarding Detection（BFD）Support」、RFC 7175、2014年5月。
[TRILL-IP] Wasserman, M, Eastlake 3rd, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
[TRILL-IP] Wasserman、M、Eastlake 3rd、D。、およびD. Zhang、「IPを介した多数のリンクの透過的な相互接続（TRILL）」、進行中の作業、2014年3月。
[TRILL-ML] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[TRILL-ML] Perlman、R.、Eastlake 3rd、D.、Gwanwani、A。、およびH. Zhai、「Flexible Multilevel TRILL（Transparent Interconnection of Lots of Links）」、進行中の作業、2014年1月。
[TRILL-OAM] Senevirathne, T., Salam, S., Kumar, D, Eastlake 3rd, D., Aldrin, S., and Y. Li, "TRILL Fault Management", Work in Progress, February 2014.
[TRILL-OAM] Senevirathne、T.、Salam、S.、Kumar、D、Eastlake 3rd、D.、Aldrin、S.、Y。Li、「TRILL Fault Management」、Work in Progress、2014年2月。
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation Y.1731, February 2008.
[Y.1731] ITU-T、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T勧告Y.1731、2008年2月。
Authors' Addresses
著者のアドレス
Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada
Samer Salam Cisco 595 Burrard Street、Suite 2123 Vancouver、BC V7X 1J1 Canada
EMail: ssalam@cisco.com
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose, CA 95134 USA
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose、CA 95134 USA
EMail: tsenevir@cisco.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050 USA
EMail: sam.aldrin@gmail.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: 1-508-333-2270 EMail: d3e3e3@gmail.com
電話：1-508-333-2270メール：d3e3e3@gmail.com