[要約] RFC 6905は、TRILLにおけるOAMの要件を定義しています。その目的は、TRILLネットワークの運用、管理、および保守を向上させることです。
Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 6905 Cisco
Category: Informational D. Bond
ISSN: 2070-1721 IBM
S. Aldrin
Y. Li
Huawei
R. Watve
Cisco
March 2013
Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
多数のリンクの透過的な相互接続（TRILL）における運用、管理、保守（OAM）の要件
Abstract
概要
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (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/rfc6905.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6905で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. Scope ......................................................3
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. OAM Requirements ................................................4
4.1. Data Plane .................................................4
4.2. Connectivity Verification ..................................5
4.2.1. Unicast .............................................5
4.2.2. Distribution Trees ..................................5
4.3. Continuity Check ...........................................5
4.4. Path Tracing ...............................................6
4.5. General Requirements .......................................6
4.6. Performance Monitoring .....................................7
4.6.1. Packet Loss .........................................7
4.6.2. Packet Delay ........................................7
4.7. ECMP Utilization ...........................................8
4.8. Security and Operational Considerations ....................8
4.9. Fault Indications ..........................................8
4.10. Defect Indications ........................................9
4.11. Live Traffic Monitoring ...................................9
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
7. Acknowledgments ................................................11
8. Contributors ...................................................11
The Operations, Administration, and Maintenance (OAM) generally covers various production aspects of a network. In this document, we use the term OAM as defined in [RFC6291].
運用、管理、および保守（OAM）は、通常、ネットワークのさまざまな運用面をカバーします。このドキュメントでは、[RFC6291]で定義されているOAMという用語を使用します。
The success of network operations depends on the ability to proactively monitor it for faults, performance, etc., as well as the ability to efficiently and quickly troubleshoot defects and failures. A well-defined OAM toolset is a vital requirement for wider adoption of Transparent Interconnection of Lots of Links (TRILL) as the next generation data-forwarding technology in larger networks such as data centers.
ネットワーク操作の成功は、障害やパフォーマンスなどについてネットワークを予防的に監視する機能と、欠陥や障害を効率的かつ迅速にトラブルシューティングする機能に依存します。明確に定義されたOAMツールセットは、データセンターなどの大規模ネットワークにおける次世代のデータ転送テクノロジーとして、リンクの透過的相互接続（TRILL）をより広く採用するための重要な要件です。
In this document, we define the requirements for TRILL OAM. It is assumed that the readers are familiar with the OAM concepts and terminologies defined in other OAM standards such as [8021ag], [RFC5860], and [RFC4377]. This document does not attempt to redefine the terms and concepts specified elsewhere.
このドキュメントでは、TRILL OAMの要件を定義します。読者は、[8021ag]、[RFC5860]、[RFC4377]などの他のOAM標準で定義されているOAMの概念と用語に精通していることを前提としています。このドキュメントは、他の場所で指定された用語と概念を再定義することを試みません。
The scope of this document is OAM between Routing Bridges (RBridges) of a TRILL campus over links selected by TRILL routing.
このドキュメントの範囲は、TRILLルーティングによって選択されたリンクを介したTRILLキャンパスのルーティングブリッジ（RBridges）間のOAMです。
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]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。このドキュメントはプロトコルの仕様ではありませんが、この言語を使用すると、このドキュメントに記載されている要件を満たすソリューションを作成するプロトコル設計者への指示が明確になります。
Section: This term refers to a segment of a path between any two given RBridges. As an example, consider the case where RB1 is connected to RBx via RB2, RB3, and RB4. The segment between RB2 to RB4 is referred to as a section of the path RB1 to RBx. More details of this definition can be found in [RFC5960].
セクション：この用語は、指定された2つのRBridge間のパスのセグメントを指します。例として、RB1がRB2、RB3、およびRB4を介してRBxに接続されている場合を考えます。 RB2からRB4までのセグメントは、パスRB1からRBxのセクションと呼ばれます。この定義の詳細は、[RFC5960]にあります。
Flow: This term indicates a set of packets that share the same path and per-hop behavior (such as priority). A flow is typically identified by a portion of the inner payload that affects the hop-by-hop forwarding decisions. This may contain Layer 2 through Layer 4 information.
フロー：この用語は、同じパスとホップごとの動作（優先度など）を共有するパケットのセットを示します。フローは通常、ホップバイホップ転送の決定に影響する内部ペイロードの一部によって識別されます。これには、レイヤー2からレイヤー4の情報が含まれる場合があります。
All Selectable Least-Cost Paths: This term refers to a subset of all potentially available least-cost paths to a specified destination RBridge that are available (and usable) for forwarding of frames. It is important to note that in practice, due to limitations in implementations, not all available least-cost paths may be selectable for forwarding.
すべての選択可能な最小コストパス：この用語は、指定された宛先RBridgeへのすべての潜在的に使用可能な最小コストパスのうち、フレームの転送に使用できる（および使用できる）サブセットを指します。実際には、実装の制限により、利用可能なすべての最小コストパスが転送用に選択できるとは限らないことに注意することが重要です。
Connectivity: This term indicates reachability between an arbitrary RBridge RB1 and any other RBridge RB2. The specific path can be either explicit (i.e., associated with a specific flow) or unspecified. Unspecified means that messages used for connectivity verification take whatever path the RBs happen to select. Please refer to [OAMOVER] for details.
接続性：この用語は、任意のRBridge RB1と他のRBridge RB2の間の到達可能性を示します。特定のパスは、明示的（つまり、特定のフローに関連付けられている）または未指定のいずれかです。未指定とは、接続検証に使用されるメッセージが、RBがたまたま選択した経路をたどることを意味します。詳細は【OAMOVER】をご覧ください。
Continuity Verification: This term refers to proactive verification of liveliness between two RBridges at periodic intervals and the generation of explicit notification when connectivity failures occur. Please refer to [OAMOVER] for details.
継続性の検証：この用語は、定期的な間隔で2つのRBridge間の活発性を積極的に検証し、接続障害が発生したときに明示的な通知を生成することを指します。詳細は【OAMOVER】をご覧ください。
Fault: This term refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Please refer to [TERMTP] for definition.
障害：この用語は、必要なアクションを実行できないことを意味します。たとえば、パケットの配信の失敗などです。定義については[TERMTP]を参照してください。
Defect: This term refers to an interruption in the normal operation, such that over a period of time no packets are delivered successfully. Please refer to [TERMTP] for definition.
欠陥：この用語は、通常の操作の中断を意味し、一定期間パケットが正常に配信されないようにします。定義については[TERMTP]を参照してください。
Failure: This term refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. Please refer to [TERMTP] for definition.
失敗：この用語は、必要な機能が長期間にわたって終了することを指します。一定期間欠陥が持続する場合は、失敗と解釈されます。定義については[TERMTP]を参照してください。
Simulated Flow: This term refers to a sequence of OAM-generated packets designed to follow a specific path. The fields of the packets in the simulated flow may or may not be identical to the fields of data packets of an actual flow being simulated. However, the purpose of the simulated flow is to have OAM packets of the simulated flow follow a specific path.
シミュレートされたフロー：この用語は、特定のパスをたどるように設計されたOAM生成パケットのシーケンスを指します。シミュレートされたフロー内のパケットのフィールドは、シミュレートされている実際のフローのデータパケットのフィールドと同一であってもなくてもかまいません。ただし、シミュレーションフローの目的は、シミュレーションフローのOAMパケットが特定のパスをたどることです。
OAM frames, utilized for connectivity verification, continuity checks, performance measurements, etc., will by default take whatever path TRILL chooses based on the current topology and per-hop equal-cost path choices. In some cases, it may be required that the OAM frames utilize specific paths. Thus, it MUST be possible to arrange that OAM frames follow the path taken by a specific flow.
接続検証、継続性チェック、パフォーマンス測定などに使用されるOAMフレームは、デフォルトで、現在のトポロジとホップごとの等コストパスの選択に基づいてTRILLが選択するパスを使用します。場合によっては、OAMフレームが特定のパスを利用する必要があります。したがって、OAMフレームが特定のフローがたどるパスをたどるように調整できる必要があります。
RBridges MUST have the ability to identify frames that require OAM processing.
RBridgeは、OAM処理を必要とするフレームを識別する機能を持たなければなりません（MUST）。
TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be egressed from a TRILL network as native frames.
TRILL OAMフレームはTRILLキャンパス内に残しておく必要があり、ネイティブフレームとしてTRILLネットワークから出力してはなりません。
OAM MUST have the ability to include all Ethernet traffic types carried by TRILL.
OAMには、TRILLによって伝送されるすべてのイーサネットトラフィックタイプを含める機能が必要です。
From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2.
任意のRBridge RB1から、OAMは他のRBridge RB2への接続を検証する機能を持っている必要があります。
From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2 for a specific flow via the path associated with the specified flow.
任意のRBridge RB1から、OAMは、指定されたフローに関連付けられたパスを介して特定のフローの他のRBridge RB2への接続を検証する機能を持っている必要があります。
OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree. This functionality is referred to as verification of the unpruned distribution tree.
OAMは、指定された配布ツリーについて、任意のRBridge RB1から特定のRBridgeセットまたはすべてのメンバーRBridgeへの接続を検証する機能を持っている必要があります。この機能は、枝刈りされていない配布ツリーの検証と呼ばれます。
OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree and for a specified flow. This functionality is referred to as verification of the pruned tree.
OAMは、指定された配布ツリーと指定されたフローについて、任意のRBridge RB1から特定のRBridgeセットまたはすべてのメンバーRBridgeへの接続を検証する機能を持っている必要があります。この機能は、枝刈りされたツリーの検証と呼ばれます。
OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge.
OAMは、任意のRBridge RB1が他のRBridgeへの導通チェックを実行できるようにする機能を提供する必要があります。
OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge using a path associated with a specified flow.
OAMは、任意のRBridge RB1が、指定されたフローに関連付けられたパスを使用して、他のRBridgeへの導通チェックを実行できるようにする機能を提供する必要があります。
OAM SHOULD provide functions that allow any arbitrary RBridge to perform a Continuity Check to any other RBridge over any section of any selectable least-cost path.
OAM SHOULDは、任意のRBridgeが、選択可能な任意の最小コストパスの任意のセクションで他のRBridgeへの導通チェックを実行できるようにする機能を提供する必要があります（SHOULD）。
OAM SHOULD provide the ability to perform a Continuity Check on sections of any selectable path within the network.
OAMは、ネットワーク内の選択可能なパスのセクションで導通チェックを実行する機能を提供する必要があります（SHOULD）。
OAM SHOULD provide the ability to perform a multicast Continuity Check for specified distribution tree(s), as well as specified combinations of distribution trees and flows. The former is referred to as an unpruned multi-destination tree Continuity Check and the latter is referred to as a pruned tree Continuity Check.
OAMは、指定された配信ツリー、および配信ツリーとフローの指定された組み合わせに対してマルチキャスト継続性チェックを実行する機能を提供する必要があります（SHOULD）。前者はプルーニングされていない複数宛先ツリーの連続性チェックと呼ばれ、後者はプルーニングされたツリーの連続性チェックと呼ばれます。
OAM MUST provide the ability to trace a path between any two RBridges corresponding to a specified unicast flow.
OAMは、指定されたユニキャストフローに対応する2つのRBridge間のパスをトレースする機能を提供する必要があります。
OAM SHOULD provide the ability to trace all selectable least-cost paths between any two RBridges.
OAMは、任意の2つのRBridge間のすべての選択可能な最小コストパスをトレースする機能を提供する必要があります（SHOULD）。
OAM SHOULD provide functionality to trace all branches of a specified distribution tree (unpruned tree).
OAMは、指定された配布ツリー（枝刈りされていないツリー）のすべてのブランチをトレースする機能を提供する必要があります（SHOULD）。
OAM SHOULD provide functionality to trace all branches of a specified distribution tree for a specified flow (pruned tree).
OAMは、指定されたフロー（枝刈りされたツリー）の指定された配布ツリーのすべてのブランチをトレースする機能を提供する必要があります（SHOULD）。
OAM MUST provide the ability to initiate and maintain multiple concurrent sessions for multiple OAM functions between any arbitrary RBridge RB1 to any other RBridge. In general, multiple OAM operations will run concurrently. For example, proactive continuity checks may take place between RB1 and RB2 at the same time that an operator decides to test connectivity between the same two RBs. Multiple OAM functions and instances of those functions MUST be able to run concurrently without interfering with each other.
OAMは、任意のRBridge RB1と他のRBridgeの間の複数のOAM機能に対して複数の同時セッションを開始および維持する機能を提供する必要があります。一般に、複数のOAM操作が同時に実行されます。たとえば、プロアクティブな導通チェックは、オペレーターが同じ2つのRB間の接続をテストすることを決定すると同時に、RB1とRB2の間で行われる場合があります。複数のOAM関数とそれらの関数のインスタンスは、互いに干渉することなく同時に実行できる必要があります。
OAM MUST provide a single OAM framework for all TRILL OAM functions within the scope of this document.
OAMは、このドキュメントの範囲内のすべてのTRILL OAM機能に対して単一のOAMフレームワークを提供する必要があります。
OAM, as practical and as possible, SHOULD reuse functional, operational, and semantic elements of existing OAM standards.
OAMは、実用的かつ可能な限り、既存のOAM標準の機能、運用、および意味の要素を再利用する必要があります（SHOULD）。
OAM MUST maintain related error and operational counters. Such counters MUST be accessible via network management applications (e.g., SNMP).
OAMは、関連するエラーおよび操作カウンターを維持する必要があります。このようなカウンターは、ネットワーク管理アプリケーション（SNMPなど）を介してアクセスできる必要があります。
OAM functions related to continuity and connectivity checks MUST be able to be invoked either proactively or on demand.
継続性と接続性のチェックに関連するOAM機能は、事前またはオンデマンドで呼び出すことができる必要があります。
OAM MAY be required to provide the ability to specify a desired response mode for a specific OAM message. The desired response mode can be in-band, out-of-band, or none.
特定のOAMメッセージに必要な応答モードを指定する機能を提供するには、OAMが必要になる場合があります。必要な応答モードは、帯域内、帯域外、またはなしです。
The OAM Framework MUST be extensible to include new functionality. For example, the solution needs to include a version number to differentiate older and newer implementations and TLV structures for flexibility to include new information elements.
OAMフレームワークは、新しい機能を含めるために拡張可能でなければなりません。たとえば、ソリューションには、新旧の実装を区別するためのバージョン番号と、新しい情報要素を柔軟に含めるためのTLV構造を含める必要があります。
OAM MAY provide methods to verify control-plane and forwarding-plane alignments.
OAMは、コントロールプレーンとフォワーディングプレーンの位置合わせを確認する方法を提供する場合があります。
OAM SHOULD leverage existing OAM technologies, where practical.
OAMは、実用的であれば、既存のOAMテクノロジーを活用する必要があります（SHOULD）。
In this document, the term "packet loss" is used as defined in Section 2.4 of [RFC2680].
このドキュメントでは、「パケット損失」という用語は、[RFC2680]のセクション2.4で定義されているように使用されます。
OAM SHOULD provide the ability to measure packet loss statistics for a flow from any arbitrary RBridge RB1 to any other RBridge.
OAMは、任意のRBridge RB1から他のRBridgeへのフローのパケット損失統計を測定する機能を提供する必要があります（SHOULD）。
OAM SHOULD provide the ability to measure packet loss statistics over a section for a flow between any arbitrary RBridge RB1 to any other RBridge.
OAM SHOULDは、任意のRBridge RB1から他のRBridgeまでのフローのセクションのパケット損失統計を測定する機能を提供する必要があります。
OAM SHOULD provide the ability to measure packet loss statistics between any two RBridges over all least-cost paths.
OAMは、すべての最小コストパス上の2つのRBridge間のパケット損失統計を測定する機能を提供する必要があります（SHOULD）。
An RBridge SHOULD be able to perform the above packet loss measurement functions either proactively or on demand.
RBridgeは、上記のパケット損失測定機能を事前またはオンデマンドで実行できる必要があります（SHOULD）。
There are two types of packet delays -- one-way delay and two-way delay (Round-Trip Delay).
パケット遅延には、一方向の遅延と双方向の遅延（ラウンドトリップ遅延）の2種類があります。
One-way delay is defined in [RFC2679] as the time elapsed from the start of transmission of the first bit of a packet by an RBridge until the reception of the last bit of the packet by the destination RBridge.
一方向遅延は、[RFC2679]で、RBridgeによるパケットの最初のビットの送信の開始から宛先RBridgeによるパケットの最後のビットの受信までの経過時間として定義されています。
Two-way delay is also referred to as Round-Trip Delay and is defined similar to [RFC2681]; i.e., the time elapsed from the start of transmission of the first bit of a packet from RB1, receipt of the packet at RB2, RB2 sending a response packet back to RB1, and RB1 receiving the last bit of that response packet.
双方向遅延はラウンドトリップ遅延とも呼ばれ、[RFC2681]と同様に定義されます。つまり、RB1からのパケットの最初のビットの送信の開始から経過した時間、RB2でのパケットの受信、RB2は応答パケットをRB1に送り返し、RB1はその応答パケットの最後のビットを受信します。
OAM SHOULD provide functions to measure two-way delay between two RBridges.
OAMは、2つのRBridge間の双方向遅延を測定する機能を提供する必要があります（SHOULD）。
OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow.
OAMは、指定されたフローの2つのRBridge間の片方向遅延を測定する機能を提供する場合があります。
OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow over a specific section.
OAMは、特定のセクション上の指定されたフローの2つのRBridge間の一方向の遅延を測定する機能を提供する場合があります。
OAM MAY provide functionality to monitor the effectiveness of per-hop Equal-Cost Multipath (ECMP) hashing. For example, individual RBridges could maintain counters that show how packets are being distributed across equal-cost next hops for a specified destination RBridge or RBridges as a result of ECMP hashing.
OAMは、ホップごとの等価コストマルチパス（ECMP）ハッシュの有効性を監視する機能を提供する場合があります。たとえば、個々のRBridgeは、ECMPハッシュの結果として、指定された1つまたは複数の宛先RBridgeの等コストネクストホップにパケットがどのように分散されるかを示すカウンターを維持できます。
Methods MUST be provided to protect against exploitation of OAM framework for security and denial-of-service attacks.
セキュリティおよびサービス拒否攻撃のためのOAMフレームワークの悪用を防ぐためのメソッドを提供する必要があります。
Methods MUST be provided to prevent OAM messages from causing congestion in the networks. Periodically generated messages with high frequencies may lead to congestion, hence methods such as shaping or rate limiting SHOULD be utilized.
OAMメッセージがネットワークで輻輳を引き起こさないようにするためのメソッドを提供する必要があります。高い頻度で定期的に生成されるメッセージは輻輳につながる可能性があるため、シェーピングやレート制限などの方法を使用する必要があります。
Certain OAM functions may be utilized to gather operational information such as topology of the network. Methods MUST be provided to prevent unauthorized users accessing OAM functions to gather critical and sensitive information of the network.
特定のOAM機能を利用して、ネットワークのトポロジーなどの運用情報を収集できます。権限のないユーザーがOAM機能にアクセスしてネットワークの重要かつ機密情報を収集しないようにするための方法を提供する必要があります。
OAM packets MUST be limited to within the TRILL campus, and the implementation MUST provide methods to prevent leaking of OAM packets out of the TRILL campus. Additionally, methods MUST be provided to prevent accepting OAM packets from outside the TRILL campus.
OAMパケットはTRILLキャンパス内に限定する必要があり、実装はOAMパケットがTRILLキャンパスの外に漏れないようにするメソッドを提供する必要があります。さらに、TRILLキャンパス外からのOAMパケットの受け入れを防ぐためのメソッドを提供する必要があります。
OAM MUST provide a Fault Indication framework to notify the packet's ingress RBridge or other interested parties (such as syslog servers) about faults.
OAMは、障害についてパケットの入力RBridgeまたは他の関係者（syslogサーバーなど）に通知する障害表示フレームワークを提供する必要があります。
OAM MUST provide functions to selectively enable or disable different types of Fault Indications.
OAMは、さまざまなタイプの障害表示を選択的に有効または無効にする機能を提供する必要があります。
OAM SHOULD provide a framework for Defect Detection and Indication.
OAMは、欠陥の検出と表示のフレームワークを提供する必要があります（SHOULD）。
OAM Defect Detection and Indication Framework SHOULD provide methods to selectively enable or disable Defect Detection per defect type.
OAM欠陥検出および表示フレームワークは、欠陥タイプごとに欠陥検出を選択的に有効または無効にするメソッドを提供する必要があります（SHOULD）。
OAM Defect Detection and Indication Framework SHOULD provide methods to configure Defect Detection thresholds per different types of defects.
OAM欠陥検出および表示フレームワークは、さまざまな種類の欠陥ごとに欠陥検出しきい値を設定する方法を提供する必要があります（SHOULD）。
OAM Defect Detection and Indication Framework SHOULD provide methods to log defect indications to a locally defined archive (such as log buffer) or Simple Network Management Protocol (SNMP) traps.
OAM欠陥検出および表示フレームワークは、ローカルで定義されたアーカイブ（ログバッファーなど）または簡易ネットワーク管理プロトコル（SNMP）トラップに欠陥表示を記録する方法を提供する必要があります（SHOULD）。
OAM Defect Detection and Indication Framework SHOULD provide a Remote Defect Indication framework that facilitates notifying the originator/owner of the flow experiencing the defect, which is the ingress RBridge.
OAM欠陥検出および表示フレームワークは、入口RBridgeである欠陥を経験しているフローの発信者/所有者への通知を容易にするリモート欠陥表示フレームワークを提供する必要があります（SHOULD）。
Remote Defect Indication MAY be either in-band or out-of-band.
リモート障害表示は、インバンドまたはアウトオブバンドのいずれかになる場合があります。
OAM implementations MAY provide methods to utilize live traffic for troubleshooting and performance monitoring.
OAM実装は、トラブルシューティングとパフォーマンス監視のためにライブトラフィックを利用する方法を提供する場合があります。
Security requirements are specified in Section 4.8. For general TRILL security considerations, please refer to [RFC6325].
セキュリティ要件はセクション4.8で指定されています。 TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", IEEE Std 802.1ag-2007, 2007.
[8021ag] IEEE、「Virtual Bridged Local Area Networks Amendment 5：Connectivity Fault Management」、IEEE Std 802.1ag-2007、2007。
[OAMOVER] Mizrahi, T., Sprecher, N., Bellagamba, E., Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, January 2013.
[OAMOVER]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E.、Y。ウェインガルテン、「運用、管理、保守（OAM）メカニズムの概要」、2013年1月、進行中。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの片方向パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operations and Management（OAM）Requirements for Multi-Protocol Label Switched（MPLS）Networks」、RFC 4377 、2006年2月。
[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 。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960] Frost、D.、Ed。、Bryant、S.、Ed。、and M. Bocci、Ed。、 "MPLS Transport Profile Data Plane Architecture"、RFC 5960、August 2010。
[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月。
[TERMTP] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T' Transport Network Recommendations", Work in Progress, February 2013.
[TERMTP] van Helvoort、H。、編、Andersson、L。、編、N。Sprecher、編、「マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）ドラフト/ RFCで使用される用語のシソーラスITU-T 'Transport Network Recommendations」、Work in Progress、2013年2月。
Special acknowledgments to IEEE 802.1 chair, Tony Jeffree, for allowing us to solicit comments from IEEE 802.1 group. Also recognized are the comments received from the IEEE group, IESG, Stewart Bryant, Ralph Droms, Adrian Farrel, Benoit Claise, Ayal Lior, and others.
IEEE 802.1グループからコメントを求めることを許可してくださったIEEE 802.1チェア、Tony Jeffreeへの特別な謝辞。また、IEEEグループ、IESG、スチュワートブライアント、ラルフドロムス、エイドリアンファレル、ブノワクレイズ、アヤルリアーなどから寄せられたコメントも認められています。
Thomas Narten IBM Corporation 3039 Cornwallis Avenue, PO Box 12195 Research Triangle Park, NC 27709 USA
Thomas Narten IBM Corporation 3039 Cornwallis Avenue、PO Box 12195 Research Triangle Park、NC 27709 USA
EMail:narten@us.ibm.com
EMail：narten@us.ibm.com
Donald Eastlake Huawei Technologies 155 Beaver Street, Milford, MA 01757 USA
ドナルドイーストレイクファーウェイテクノロジーズ155 Beaver Street、Milford、MA 01757 USA
EMail: d3e3e3@gmail.com
Anoop Ghanwani Dell 350 Holger Way San Jose, CA 95134 USA
Anoop Ghanwani Dell 350 Holger Way San Jose、CA 95134 USA
Phone: +1-408-571-3500
EMail: Anoop@alumni.duke.edu
Jon Hudson Brocade 120 Holger Way San Jose, CA 95134 USA
Jon Hudson Brocade 120 Holger Way San Jose、CA 95134 USA
EMail: jon.hudson@gmail.com Naveen Nimmu Broadcom 9th Floor, Building no 9, Raheja Mind space Hi-Tec City, Madhapur, Hyderabad - 500 081 India
EMail：jon.hudson@gmail.com Naveen Nimmu Broadcom 9階、9号棟、Raheja Mind space Hi-Tec City、マダプール、ハイデラバード-500 081インド
Phone: +1-408-218-8893
EMail: naveen@broadcom.com
Radia Perlman Intel Labs 2700 156th Ave NE, Suite 300, Bellevue, WA 98007 USA
らぢあ ぺｒｌまん いんてｌ ぁｂｓ ２７００ １５６ｔｈ あゔぇ ね、 すいて ３００、 べっぇゔえ、 わ ９８００７ うさ
Phone: +1-425-881-4824
EMail: radia.perlman@intel.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel
EMail: talmi@marvell.com
Authors' Addresses
著者のアドレス
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose, CA 95134 USA
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose、CA 95134 USA
Phone: +1-408-853-2291 EMail: tsenevir@cisco.com David Bond IBM 4400 North 1st Street San Jose, CA 95134 USA
電話：+ 1-408-853-2291メール：tsenevir@cisco.com David Bond IBM 4400 North 1st Street San Jose、CA 95134 USA
Phone: +1-603-339-7575
EMail: mokon@mokon.net
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 USA
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara、CA 95951 USA
EMail: aldrin.ietf@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Phone: +86-25-56625375
EMail: liyizhou@huawei.com
Rohit Watve Cisco Systems 375 East Tasman Drive San Jose, CA 95134 USA
Rohit Watve Cisco Systems 375 East Tasman Drive San Jose、CA 95134 USA
Phone: +1-408-424-2091
EMail: rwatve@cisco.com