[要約] RFC 8531は、接続指向の操作、管理、および保守（OAM）プロトコルのための汎用YANGデータモデルです。このRFCの目的は、異なるOAMプロトコル間の一貫性を確保し、ネットワーク管理者が効果的にOAM機能を設定および管理できるようにすることです。
Internet Engineering Task Force (IETF) D. Kumar
Request for Comments: 8531 Cisco
Category: Standards Track Q. Wu
ISSN: 2070-1721 M. Wang
Huawei
April 2019
Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
接続指向の運用、管理、および保守（OAM）プロトコル用の汎用YANGデータモデル
Abstract
概要
This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).
このドキュメントでは、接続指向の運用、管理、および保守（OAM）プロトコルの基本的なYANGデータモデルについて説明します。それはそのようなプロトコルのための主要なOAM構造の技術に依存しない抽象化を提供します。ここで紹介するモデルは、テクノロジー固有の詳細を含めるように拡張できます。これにより、OAMプロトコルの管理の均一性が保証され、ネストされたOAMワークフローのサポートが提供されます（つまり、統一されたインターフェースを通じてさまざまなレベルでOAM機能を実行できます）。
The YANG data model in this document conforms to the Network Management Datastore Architecture.
このドキュメントのYANGデータモデルは、ネットワーク管理データストアアーキテクチャに準拠しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8531.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8531で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 7
3. Architecture of Generic YANG Data Model for Connection-
Oriented OAM . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overview of the Connection-Oriented OAM YANG Data Model . . . 8
4.1. Maintenance Domain (MD) Configuration . . . . . . . . . . 9
4.2. Maintenance Association (MA) Configuration . . . . . . . 10
4.3. Maintenance End Point (MEP) Configuration . . . . . . . . 11
4.4. RPC Definitions . . . . . . . . . . . . . . . . . . . . . 11
4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Monitor Statistics . . . . . . . . . . . . . . . . . . . 14
4.7. OAM Data Hierarchy . . . . . . . . . . . . . . . . . . . 14
5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19
6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 42
6.3. Maintenance Association . . . . . . . . . . . . . . . . . 42
7. Connection-Oriented OAM YANG Data Model Applicability . . . . 43
7.1. Generic YANG Data Model Extension for TRILL OAM . . . . . 43
7.1.1. MD Configuration Extension . . . . . . . . . . . . . 43
7.1.2. MA Configuration Extension . . . . . . . . . . . . . 44
7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 45
7.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 46
7.2. Generic YANG Data Model Extension for MPLS-TP OAM . . . . 46
7.2.1. MD Configuration Extension . . . . . . . . . . . . . 47
7.2.2. MA Configuration Extension . . . . . . . . . . . . . 48
7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 48
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Normative References . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
Operations, Administration, and Maintenance (OAM) are important networking functions that allow operators to:
運用、管理、および保守（OAM）は、オペレーターが次のことを行えるようにする重要なネットワーク機能です。
1. monitor network communications (i.e., reachability verification and Continuity Check)
1. ネットワーク通信を監視する（つまり、到達可能性の検証と継続性チェック）
2. troubleshoot failures (i.e., fault verification and localization)
2. 障害のトラブルシューティング（障害の検証とローカリゼーションなど）
3. monitor service-level agreements and performance (i.e., performance management)
3. サービスレベルアグリーメントとパフォーマンス（つまり、パフォーマンス管理）を監視する
An overview of OAM tools is presented in [RFC7276]. Over the years, many technologies have developed similar tools for fault and performance management.
OAMツールの概要は[RFC7276]に示されています。長年にわたって、多くのテクノロジーが障害およびパフォーマンス管理のための同様のツールを開発してきました。
The different sets of OAM tools may support both connection-oriented technologies or connectionless technologies. In connection-oriented technologies, a connection is established prior to the transmission of data. After the connection is established, no additional control information such as signaling or operations and maintenance information is required to transmit the actual user data. In connectionless technologies, data is typically sent between communicating endpoints without prior arrangement, but control information is required to identify the destination (e.g., [G.800]). The YANG data model for OAM protocols using connectionless communications is specified in [RFC8532] and [IEEE802.1Q].
OAMツールの異なるセットは、接続指向テクノロジーまたはコネクションレステクノロジーの両方をサポートする場合があります。接続指向のテクノロジーでは、データの送信前に接続が確立されます。接続が確立された後、実際のユーザーデータを送信するために、シグナリングや操作、メンテナンス情報などの追加の制御情報は必要ありません。コネクションレス型の技術では、データは通常、事前の準備なしに通信するエンドポイント間で送信されますが、宛先を識別するために制御情報が必要です（たとえば、[G.800]）。コネクションレス型通信を使用するOAMプロトコルのYANGデータモデルは、[RFC8532]および[IEEE802.1Q]で指定されています。
Connectivity Fault Management as specified in [IEEE802.1Q] is a well-established OAM standard that is widely adopted for Ethernet networks. ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS Transport Profile (MPLS-TP) [RFC6371], and Transparent Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM mechanisms based on the manageability framework of Connectivity Fault Management (CFM) [IEEE802.1Q].
[IEEE802.1Q]で指定されている接続障害管理は、イーサネットネットワークで広く採用されている確立されたOAM標準です。 ITU-T [G.8013]、MEFフォーラム（MEF）サービスOAM [MEF-17]、MPLSトランスポートプロファイル（MPLS-TP）[RFC6371]、およびリンクの透過的相互接続（TRILL）[RFC7455]はすべてOAMを定義します接続性障害管理（CFM）の管理容易性フレームワークに基づくメカニズム[IEEE802.1Q]。
Given the wide adoption of the underlying OAM concepts defined in CFM [IEEE802.1Q], it is a reasonable choice to develop the unified management framework for connection-oriented OAM based on those concepts. In this document, we take the CFM [IEEE802.1Q] model and extend it to a technology-independent framework and define the corresponding YANG data model accordingly. The YANG data model presented in this document is the base model for connection-oriented OAM protocols and supports generic continuity check, connectivity verification, and path discovery (traceroute). The generic YANG data model for connection-oriented OAM is designed to be extensible to other connection-oriented technologies. Technology-dependent nodes and remote procedure call (RPC) commands are defined in technology-specific YANG data models, which use and extend the base model defined here. As an example, Virtual eXtensible Local Area Network (VXLAN) uses the source UDP port number for flow entropy, while TRILL uses either (a) MAC addresses, (b) the VLAN tag or Fine-Grained Label, and/or (c) IP addresses for flow entropy in the hashing for multipath selection. To capture this variation, corresponding YANG data models would define the applicable structures as augmentation to the generic base model presented here. This accomplishes three goals: First, it keeps each YANG data model smaller and more manageable. Second, it allows independent development of corresponding YANG data models. Third, implementations can limit support to only the applicable set of YANG data models (e.g., TRILL RBridge may only need to implement the generic model and the TRILL YANG data model).
CFM [IEEE802.1Q]で定義されている基礎となるOAMの概念が広く採用されていることを考えると、それらの概念に基づいて接続指向のOAMの統合管理フレームワークを開発することは合理的な選択です。このドキュメントでは、CFM [IEEE802.1Q]モデルを採用して、テクノロジーに依存しないフレームワークに拡張し、それに応じて対応するYANGデータモデルを定義します。このドキュメントで紹介するYANGデータモデルは、コネクション型OAMプロトコルの基本モデルであり、一般的な連続性チェック、接続検証、およびパスディスカバリ（traceroute）をサポートしています。コネクション型OAMの一般的なYANGデータモデルは、他のコネクション型テクノロジーに拡張できるように設計されています。テクノロジーに依存するノードとリモートプロシージャコール（RPC）コマンドは、テクノロジー固有のYANGデータモデルで定義され、ここで定義された基本モデルを使用および拡張します。例として、Virtual eXtensible Local Area Network（VXLAN）はフローエントロピーにソースUDPポート番号を使用し、TRILLは（a）MACアドレス、（b）VLANタグまたはファイングレインラベル、または（c）のいずれかを使用します。マルチパス選択のハッシュにおけるフローエントロピーのIPアドレス。この変化を捉えるために、対応するYANGデータモデルは、ここで提示されている一般的なベースモデルへの拡張として、該当する構造を定義します。これにより、3つの目標が達成されます。1つ目は、各YANGデータモデルを小さく維持し、管理しやすくすることです。第二に、対応するYANGデータモデルの独立した開発を可能にします。第3に、実装はサポートをYANGデータモデルの適用可能なセットのみに制限できます（たとえば、TRILL RBridgeは一般的なモデルとTRILL YANGデータモデルを実装するだけでよい場合があります）。
The YANG data model presented in this document is generated at the management layer. Encapsulations and state machines may differ according to each OAM protocol. A user who wishes to issue a Continuity Check command or a Loopback or initiate a performance monitoring session can do so in the same manner, regardless of the underlying protocol or technology or specific vendor implementation.
このドキュメントに記載されているYANGデータモデルは、管理レイヤーで生成されます。カプセル化とステートマシンは、各OAMプロトコルによって異なる場合があります。 Continuity Checkコマンドやループバックを発行したり、パフォーマンス監視セッションを開始したりするユーザーは、基盤となるプロトコルやテクノロジー、特定のベンダーの実装に関係なく、同じ方法でこれを行うことができます。
As an example, consider a scenario where connectivity from device A loopback to device B fails. Between device A and B there are IEEE 802.1 bridges a, b, and c. Let's assume a, b, and c are using CFM [IEEE802.1Q]. A user, upon detecting the loopback failure, may decide to drill down to the lower level at different segments of the path and issue the corresponding fault verification (Loopback Message) and fault isolation (Looktrace Message) tools, using the same API. This ability to drill down to a lower layer of the protocol stack at a specific segment within a path for fault localization and troubleshooting is referred to as "nested OAM workflow". It is a useful concept that leads to efficient network troubleshooting and maintenance workflows. The connection-oriented OAM YANG data model presented in this document facilitates that without needing changes to the underlying protocols.
例として、デバイスAのループバックからデバイスBへの接続が失敗するシナリオを考えます。デバイスAとデバイスBの間には、IEEE 802.1ブリッジa、b、cがあります。 a、b、cがCFM [IEEE802.1Q]を使用していると仮定します。ユーザーは、ループバック障害を検出すると、パスのさまざまなセグメントで下位レベルにドリルダウンし、同じAPIを使用して、対応する障害検証（ループバックメッセージ）ツールと障害分離（ルックトレースメッセージ）ツールを発行することを決定できます。障害の特定とトラブルシューティングのために、パス内の特定のセグメントでプロトコルスタックの下位層にドリルダウンするこの機能は、「ネストされたOAMワークフロー」と呼ばれます。これは、効率的なネットワークのトラブルシューティングとメンテナンスのワークフローにつながる便利な概念です。このドキュメントに示されている接続指向のOAM YANGデータモデルは、基礎となるプロトコルを変更する必要なく、それを容易にします。
The YANG data model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342].
このドキュメントのYANGデータモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャに準拠しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Many of the terms used in this document (including those set out in Sections Section 2.1 and Section 2.2) are specific to the world of OAM. This document does not attempt to explain the terms but does assume that the reader is familiar with the concepts. For a good overview, read [IEEE802.1Q]. For an example of how these OAM terms appear in IETF work, see [RFC6371].
このドキュメントで使用されている用語の多く（セクション2.1およびセクション2.2に記載されているものを含む）は、OAMの世界に固有のものです。このドキュメントでは、用語の説明は試みていませんが、読者が概念に精通していることを前提としています。概要については、[IEEE802.1Q]をお読みください。これらのOAM用語がIETFでどのように表示されるかの例については、[RFC6371]を参照してください。
CCM - Continuity Check Message [IEEE802.1Q]
CCM-導通チェックメッセージ[IEEE802.1Q]
ECMP - Equal-Cost Multipath
ECMP-等コストマルチパス
LBM - Loopback Message [IEEE802.1Q]
LBM-ループバックメッセージ[IEEE802.1Q]
LTM - Linktrace Message [IEEE802.1Q]
LTM-リンクトレースメッセージ[IEEE802.1Q]
MP - Maintenance Point [IEEE802.1Q]
MP-メンテナンスポイント[IEEE802.1Q]
MEP - Maintenance End Point [RFC7174] (also known as Maintenance association End Point [IEEE802.1Q] and MEG End Point [RFC6371])
MEP-メンテナンスエンドポイント[RFC7174]（メンテナンスアソシエーションエンドポイント[IEEE802.1Q]およびMEGエンドポイント[RFC6371]とも呼ばれます）
MIP - Maintenance Intermediate Point [RFC7174] (also known as Maintenance domain Intermediate Point [IEEE802.1Q] and MEG Intermediate Point [RFC6371])
MIP-メンテナンス中間ポイント[RFC7174]（メンテナンスドメイン中間ポイント[IEEE802.1Q]およびMEG中間ポイント[RFC6371]とも呼ばれる）
MA - Maintenance Association [IEEE802.1Q] [RFC7174]
MA-メンテナンスアソシエーション[IEEE802.1Q] [RFC7174]
MD - Maintenance Domain [IEEE802.1Q]
MD-メンテナンスドメイン[IEEE802.1Q]
MEG - Maintenance Entity Group [RFC6371]
MEG-メンテナンスエンティティグループ[RFC6371]
MTV - Multi-destination Tree Verification Message
MTV-複数宛先ツリー検証メッセージ
OAM - Operations, Administration, and Maintenance [RFC6291]
OAM-運用、管理、およびメンテナンス[RFC6291]
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-多くのリンクの透過的な相互接続[RFC6325]
CFM - Connectivity Fault Management [RFC7174] [IEEE802.1Q]
CFM-接続障害管理[RFC7174] [IEEE802.1Q]
RPC - Remote Procedure Call
RPC-リモートプロシージャコール
CC - Continuity Check [RFC7276]
CC-導通チェック[RFC7276]
CV - Connectivity Verification [RFC7276]
CV-接続検証[RFC7276]
Continuity Checks - Continuity Checks are used to verify that a destination is reachable and therefore also are referred to as "reachability verification".
導通チェック-導通チェックは、宛先が到達可能であることを検証するために使用されるため、「到達可能性の検証」とも呼ばれます。
Connectivity Verification - Connectivity Verification is used to verify that a destination is connected. It is also referred to as "path verification" and used to verify not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes.
接続性検証-接続性検証は、宛先が接続されていることを検証するために使用されます。これは「パス検証」とも呼ばれ、2つのMPが接続されていることだけでなく、予期されたパスを介して接続されていることを検証するために使用され、予期しないトポロジ変更を検出できます。
Proactive OAM - Proactive OAM refers to OAM actions that are carried out continuously to permit proactive reporting of fault. A proactive OAM method requires persistent configuration.
プロアクティブOAM-プロアクティブOAMは、障害のプロアクティブなレポートを可能にするために継続的に実行されるOAMアクションを指します。プロアクティブなOAM方式では、永続的な構成が必要です。
On-demand OAM - On-demand OAM refers to OAM actions that are initiated via manual intervention for a limited time to carry out diagnostics. An on-demand OAM method requires only transient configuration.
オンデマンドOAM-オンデマンドOAMとは、診断を実行するために、限られた時間だけ手動の介入によって開始されるOAMアクションを指します。オンデマンドOAM方式では、一時的な設定のみが必要です。
Tree diagrams used in this document follow the notation defined in [RFC8340].
このドキュメントで使用されるツリー図は、[RFC8340]で定義された表記に従います。
In this document, we define a generic YANG data model for connection-oriented OAM protocols. The YANG data model defined here is generic in a sense that other technologies can extend it for technology-specific needs. The generic YANG data model for connection-oriented OAM acts as the root for other OAM YANG data models. This allows users to traverse between different OAM protocols with ease through a uniform API set. This also enables a nested OAM workflow. Figure 1 depicts the relationship of different OAM YANG data models to the Generic YANG Data Model for connection-oriented OAM. The Generic YANG data model for connection-oriented OAM provides a framework where technology-specific YANG data models can inherit constructs from the base YANG data models without needing to redefine them within the sub-technology.
このドキュメントでは、コネクション型OAMプロトコルの一般的なYANGデータモデルを定義します。ここで定義されているYANGデータモデルは、他のテクノロジーがテクノロジー固有のニーズに合わせて拡張できるという意味で一般的です。接続指向のOAMの汎用YANGデータモデルは、他のOAM YANGデータモデルのルートとして機能します。これにより、ユーザーは、統一されたAPIセットを使用して、異なるOAMプロトコル間を簡単にトラバースできます。これにより、ネストされたOAMワークフローも有効になります。図1は、さまざまなOAM YANGデータモデルと、コネクション型OAMのジェネリックYANGデータモデルとの関係を示しています。接続指向のOAMの汎用YANGデータモデルは、テクノロジー固有のYANGデータモデルが、サブテクノロジー内で再定義する必要なく、基本YANGデータモデルから構成を継承できるフレームワークを提供します。
+-----------+
|Connection-|
| Oriented |
| generic |
| OAM YANG |
+-+-+-+-+-+-+
|
|
|
+------------------------------------------+
| | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| TRILL | | MPLS-TP | . . .| foo |
|OAM YANG | |OAM YANG | |OAM YANG |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | |
| | +-+-+-+-+-+
| | . . .| foo |
| | |sub tech |
| | +-+-+-+-+-+
| | |
| | |
+-------------------------------------------------------+
| Uniform API |
+-------------------------------------------------------+
Figure 1: Relationship of OAM YANG Data Model to Generic (Base) YANG Data Model
図1：OAM YANGデータモデルとジェネリック（ベース）YANGデータモデルの関係
In this document, we adopt the concepts of the CFM [IEEE802.1Q] model and structure such that it can be adapted to different connection-oriented OAM protocols.
このドキュメントでは、CFM [IEEE802.1Q]モデルと構造の概念を採用して、さまざまな接続指向のOAMプロトコルに適合できるようにします。
At the top of the model is the Maintenance Domain. Each Maintenance Domain is associated with a Maintenance Name and a Domain Level.
モデルの最上位はメンテナンスドメインです。各メンテナンスドメインは、メンテナンス名とドメインレベルに関連付けられています。
Under each Maintenance Domain, there is one or more Maintenance Associations (MAs). In TRILL, the MA can correspond to a Fine-Grained Label.
各メンテナンスドメインの下に、1つ以上のメンテナンスアソシエーション（MA）があります。 TRILLでは、MAは細粒度ラベルに対応できます。
Under each MA, there can be two or more MEPs (Maintenance End Points). MEPs are addressed by their respective technology-specific address identifiers. The YANG data model presented here provides flexibility to accommodate different addressing schemes.
各MAの下には、2つ以上のMEP（メンテナンスエンドポイント）があります。 MEPは、それぞれのテクノロジー固有のアドレス識別子によってアドレス指定されます。ここに示すYANGデータモデルは、さまざまなアドレッシングスキームに対応する柔軟性を提供します。
Commands are presented in the management protocol, which is orthogonal to the Maintenance Domain. These are RPC commands, in YANG terms. They provide uniform APIs for Continuity Check, connectivity verification, path discovery (traceroute), and their equivalents, as well as other OAM commands.
コマンドは、メンテナンスドメインに直交する管理プロトコルで提示されます。これらはYANG用語でのRPCコマンドです。これらは、継続性チェック、接続検証、パス検出（traceroute）、およびそれらに相当するもの、およびその他のOAMコマンド用の統一されたAPIを提供します。
The OAM entities in the generic YANG data model defined here will be either explicitly or implicitly configured using any of the OAM tools. The OAM tools used here are limited to the OAM toolset specified in Section 5.1 of [RFC7276]. In order to facilitate a zero-touch experience, this document defines a default mode of OAM. The default mode of OAM is referred to as the "Base Mode" and specifies default values for each of the model's parameters, such as Maintenance Domain Level, Name of the Maintenance Association, Addresses of MEPs, and so on. The default values of these depend on the technology. Base Mode for TRILL is defined in [RFC7455]. Base Mode for other technologies and future extensions developed in IETF will be defined in their corresponding documents.
ここで定義されている一般的なYANGデータモデルのOAMエンティティは、OAMツールのいずれかを使用して明示的または暗黙的に構成されます。ここで使用されるOAMツールは、[RFC7276]のセクション5.1で指定されたOAMツールセットに限定されています。ゼロタッチエクスペリエンスを促進するために、このドキュメントではOAMのデフォルトモードを定義しています。 OAMのデフォルトモードは「ベースモード」と呼ばれ、メンテナンスドメインレベル、メンテナンスアソシエーションの名前、MEPのアドレスなど、モデルの各パラメーターのデフォルト値を指定します。これらのデフォルト値はテクノロジーによって異なります。 TRILLのベースモードは[RFC7455]で定義されています。 IETFで開発された他のテクノロジーと将来の拡張機能のベースモードは、対応するドキュメントで定義されます。
It is important to note that no specific enhancements are needed in the YANG data model to support Base Mode. Implementations that comply with this document use, by default, the data nodes of the applicable technology. Data nodes of the Base Mode are read-only nodes.
YANGデータモデルでは、ベースモードをサポートするために特定の機能強化は必要ないことに注意してください。このドキュメントに準拠する実装では、デフォルトで、該当するテクノロジーのデータノードが使用されます。基本モードのデータノードは読み取り専用ノードです。
The container "domains" is the top-level container within the "gen-oam" module. Within the container "domains", a separate list is maintained per MD. The MD list uses the key "md-name-string" for indexing. The "md-name-string" is a leaf and derived from type string. Additional name formats as defined in [IEEE802.1Q], or other standards, can be included by association of the "md-name-format" with an identity-ref. The "md-name-format" indicates the format of the augmented "md-name". The "md-name" is presented as choice/case construct. Thus, it is easily augmentable by derivative work.
コンテナ「ドメイン」は、「gen-oam」モジュール内の最上位のコンテナです。コンテナ「ドメイン」内では、MDごとに個別のリストが維持されます。 MDリストは、インデックス付けにキー「md-name-string」を使用します。 「md-name-string」はリーフであり、string型から派生しています。 [IEEE802.1Q]または他の標準で定義されている追加の名前形式は、「md-name-format」とidentity-refを関連付けることで含めることができます。 「md-name-format」は、拡張された「md-name」のフォーマットを示します。 「md-name」は、選択肢/ケース構成として提示されます。したがって、派生的な作業によって簡単に拡張できます。
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
+--rw md-name-string md-name-string
+--rw md-name-format? identityref
+--rw (md-name)?
| +--:(md-name-null)
| +--rw md-name-null? empty
+--rw md-level? md-level
Snippet of Data Hierarchy Related to OAM Domains
OAMドメインに関連するデータ階層のスニペット
Within a given Maintenance Domain, there can be one or more Maintenance Associations (MAs). MAs are represented as a list and indexed by the "ma-name-string". Similar to "md-name" defined previously, additional name formats can be added by augmenting the name-format "identity-ref" and adding applicable case statements to "ma-name".
特定のメンテナンスドメイン内に、1つ以上のメンテナンスアソシエーション（MA）が存在する場合があります。 MAはリストとして表され、「ma-name-string」によって索引付けされます。以前に定義された「md-name」と同様に、名前フォーマット「identity-ref」を拡張し、「ma-name」に適用可能なcaseステートメントを追加することにより、追加の名前フォーマットを追加できます。
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
.
.
+--rw mas
+--rw ma* [ma-name-string]
+--rw ma-name-string ma-name-string
+--rw ma-name-format? identityref
+--rw (ma-name)?
| +--:(ma-name-null)
| +--rw ma-name-null? empty
Snippet of Data Hierarchy Related to Maintenance Associations (MAs)
メンテナンスアソシエーション（MA）に関連するデータ階層のスニペット
Within a given Maintenance Association (MA), there can be one or more Maintenance End Points (MEPs). MEPs are represented as a list within the data hierarchy and indexed by the key "mep-name".
特定のメンテナンスアソシエーション（MA）内に、1つ以上のメンテナンスエンドポイント（MEP）が存在する場合があります。 MEPはデータ階層内のリストとして表され、キー「mep-name」によってインデックスが付けられます。
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
.
.
+--rw mas
+--rw ma* [ma-name-string]
.
.
+--rw mep* [mep-name]
| +--rw mep-name mep-name
| +--rw (mep-id)?
| | +--:(mep-id-int)
| | +--rw mep-id-int? int32
| +--rw mep-id-format? identityref
| +--rw (mep-address)?
| | +--:(mac-address)
| | | +--rw mac-address? yang:mac-address
| | +--:(ip-address)
| | +--rw ip-address? inet:ip-address
. .
. .
. .
Snippet of Data Hierarchy Related to Maintenance End Point (MEP)
メンテナンスエンドポイント（MEP）に関連するデータ階層のスニペット
The RPC model facilitates issuing commands to a "server" (in this case, to the device that need to execute the OAM command) and obtaining a response. The RPC model defined here abstracts OAM-specific commands in a technology-independent manner.
RPCモデルは、「サーバー」（この場合は、OAMコマンドを実行する必要のあるデバイス）へのコマンドの発行と応答の取得を容易にします。ここで定義されるRPCモデルは、テクノロジーに依存しない方法でOAM固有のコマンドを抽象化します。
There are several RPC commands defined for the purpose of OAM. In this section, we present a snippet of the Continuity Check command for illustration purposes. Please refer to Section 4.5 for the complete data hierarchy and Section 5 for the YANG module.
OAMの目的で定義されたRPCコマンドがいくつかあります。このセクションでは、説明のために、導通チェックコマンドのスニペットを示します。完全なデータ階層についてはセクション4.5を、YANGモジュールについてはセクション5を参照してください。
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
.
.
rpcs:
+---x continuity-check {continuity-check}?
| +---w input
| | +---w technology? identityref
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w cc-transmit-interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x continuity-verification {connectivity-verification}?
| +---w input
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x traceroute {traceroute}?
+---w input
| +---w md-name-string -> /domains/domain/md-name-string
| +---w md-level? -> /domains/domain/md-level
| +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +---w cos-id? uint8
| +---w ttl? uint8
| +---w command-sub-type? identityref
| +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| +---w destination-mep
| | +---w (mep-address)?
| | | +--:(mac-address)
| | | | +---w mac-address? yang:mac-address
| | | +--:(ip-address)
| | | +---w ip-address? inet:ip-address
| | +---w (mep-id)?
| | | +--:(mep-id-int)
| | | +---w mep-id-int? int32
| | +---w mep-id-format? identityref
| +---w count? uint32
| +---w interval? time-interval
+--ro output
+--ro response* [response-index]
+--ro response-index uint8
+--ro ttl? uint8
+--ro destination-mep
| +--ro (mep-address)?
| | +--:(mac-address)
| | | +--ro mac-address? yang:mac-address
| | +--:(ip-address)
| | +--ro ip-address? inet:ip-address
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro mip {mip}?
| +--ro interface? if:interface-ref
| +--ro (mip-address)?
| +--:(mac-address)
| | +--ro mac-address? yang:mac-address
| +--:(ip-address)
| +--ro ip-address? inet:ip-address
+--ro (monitor-stats)?
+--:(monitor-null)
+--ro monitor-null? empty
Snippet of Data Hierarchy Related to RPC Call Continuity-Check
RPC呼び出しの継続性チェックに関連するデータ階層のスニペット
Notification is sent upon detecting a defect condition and upon clearing a defect with a Maintenance Domain Name, MA Name, defect-type (the currently active defects), generating-mepid, and defect-message to indicate more details.
通知は、障害状態を検出し、メンテナンスドメイン名、MA名、障害タイプ（現在アクティブな障害）、generating-mepid、および障害メッセージで詳細を示す障害をクリアすると送信されます。
Grouping for monitoring statistics is to be used by technology-specific YANG modules that augment the generic YANG data model to provide statistics due to proactive OAM-like Continuity Check Messages -- for example, CCM transmit, CCM receive, CCM error, etc.
モニタリング統計のグループ化は、CAM送信、CCM受信、CCMエラーなどのプロアクティブなOAMのような連続性チェックメッセージによる統計を提供するために、汎用YANGデータモデルを補強するテクノロジー固有のYANGモジュールによって使用されます。
The complete data hierarchy related to the connection-oriented OAM YANG data model is presented below.
接続指向のOAM YANGデータモデルに関連する完全なデータ階層を以下に示します。
module: ietf-connection-oriented-oam
+--rw domains
+--rw domain* [technology md-name-string]
+--rw technology identityref
+--rw md-name-string md-name-string
+--rw md-name-format? identityref
+--rw (md-name)?
| +--:(md-name-null)
| +--rw md-name-null? empty
+--rw md-level? md-level
+--rw mas
+--rw ma* [ma-name-string]
+--rw ma-name-string ma-name-string
+--rw ma-name-format? identityref
+--rw (ma-name)?
| +--:(ma-name-null)
| +--rw ma-name-null? empty
+--rw (connectivity-context)?
| +--:(context-null)
| +--rw context-null? empty
+--rw cos-id? uint8
+--rw cc-enable? boolean
+--rw mep* [mep-name]
| +--rw mep-name mep-name
| +--rw (mep-id)?
| | +--:(mep-id-int)
| | +--rw mep-id-int? int32
| +--rw mep-id-format? identityref
| +--rw (mep-address)?
| | +--:(mac-address)
| | | +--rw mac-address? yang:mac-address
| | +--:(ip-address)
| | +--rw ip-address? inet:ip-address
| +--rw cos-id? uint8
| +--rw cc-enable? boolean
| +--rw session* [session-cookie]
| +--rw session-cookie uint32
| +--rw destination-mep
| | +--rw (mep-id)?
| | | +--:(mep-id-int)
| | | +--rw mep-id-int? int32
| | +--rw mep-id-format? identityref
| +--rw destination-mep-address
| | +--rw (mep-address)?
| | +--:(mac-address)
| | | +--rw mac-address? yang:mac-address
| | +--:(ip-address)
| | +--rw ip-address? inet:ip-address
| +--rw cos-id? uint8
+--rw mip* [name] {mip}?
+--rw name string
+--rw interface? if:interface-ref
+--rw (mip-address)?
+--:(mac-address)
| +--rw mac-address? yang:mac-address
+--:(ip-address)
+--rw ip-address? inet:ip-address
rpcs:
+---x continuity-check {continuity-check}?
| +---w input
| | +---w technology? identityref
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w cc-transmit-interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x continuity-verification {connectivity-verification}?
| +---w input
| | +---w md-name-string -> /domains/domain/md-name-string
| | +---w md-level? -> /domains/domain/md-level
| | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| | +---w cos-id? uint8
| | +---w ttl? uint8
| | +---w sub-type? identityref
| | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| | +---w destination-mep
| | | +---w (mep-address)?
| | | | +--:(mac-address)
| | | | | +---w mac-address? yang:mac-address
| | | | +--:(ip-address)
| | | | +---w ip-address? inet:ip-address
| | | +---w (mep-id)?
| | | | +--:(mep-id-int)
| | | | +---w mep-id-int? int32
| | | +---w mep-id-format? identityref
| | +---w count? uint32
| | +---w interval? time-interval
| | +---w packet-size? uint32
| +--ro output
| +--ro (monitor-stats)?
| +--:(monitor-null)
| +--ro monitor-null? empty
+---x traceroute {traceroute}?
+---w input
| +---w md-name-string -> /domains/domain/md-name-string
| +---w md-level? -> /domains/domain/md-level
| +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +---w cos-id? uint8
| +---w ttl? uint8
| +---w command-sub-type? identityref
| +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name
| +---w destination-mep
| | +---w (mep-address)?
| | | +--:(mac-address)
| | | | +---w mac-address? yang:mac-address
| | | +--:(ip-address)
| | | +---w ip-address? inet:ip-address
| | +---w (mep-id)?
| | | +--:(mep-id-int)
| | | +---w mep-id-int? int32
| | +---w mep-id-format? identityref
| +---w count? uint32
| +---w interval? time-interval
+--ro output
+--ro response* [response-index]
+--ro response-index uint8
+--ro ttl? uint8
+--ro destination-mep
| +--ro (mep-address)?
| | +--:(mac-address)
| | | +--ro mac-address? yang:mac-address
| | +--:(ip-address)
| | +--ro ip-address? inet:ip-address
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro mip {mip}?
| +--ro interface? if:interface-ref
| +--ro (mip-address)?
| +--:(mac-address)
| | +--ro mac-address? yang:mac-address
| +--:(ip-address)
| +--ro ip-address? inet:ip-address
+--ro (monitor-stats)?
+--:(monitor-null)
+--ro monitor-null? empty
notifications:
+---n defect-condition-notification
| +--ro technology? identityref
| +--ro md-name-string -> /domains/domain/md-name-string
| +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
| +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name
| +--ro defect-type? identityref
| +--ro generating-mepid
| | +--ro (mep-id)?
| | | +--:(mep-id-int)
| | | +--ro mep-id-int? int32
| | +--ro mep-id-format? identityref
| +--ro (defect)?
| +--:(defect-null)
| | +--ro defect-null? empty
| +--:(defect-code)
| +--ro defect-code? int32
+---n defect-cleared-notification
+--ro technology? identityref
+--ro md-name-string -> /domains/domain/md-name-string
+--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
+--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name
+--ro defect-type? identityref
+--ro generating-mepid
| +--ro (mep-id)?
| | +--:(mep-id-int)
| | +--ro mep-id-int? int32
| +--ro mep-id-format? identityref
+--ro (defect)?
+--:(defect-null)
| +--ro defect-null? empty
+--:(defect-code)
+--ro defect-code? int32
Data Hierarchy of OAM
OAMのデータ階層
This module imports typedefs from [RFC6991] and [RFC8343], and it references [RFC6371], [RFC6905], and [RFC7276].
このモジュールは、[RFC6991]および[RFC8343]からtypedefをインポートし、[RFC6371]、[RFC6905]、および[RFC7276]を参照します。
<CODE BEGINS> file "ietf-connection-oriented-oam@2019-04-16.yang"
module ietf-connection-oriented-oam {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam";
prefix co-oam;
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
import ietf-interfaces {
prefix if;
}
organization
"IETF LIME Working Group";
contact
"WG Web: http://datatracker.ietf.org/wg/lime
WG List: <mailto:lime@ietf.org>
Editor: Deepak Kumar <dekumar@cisco.com>
Editor: Qin Wu <bill.wu@huawei.com>
Editor: Michael Wang <wangzitao@huawei.com>";
description
"This YANG module defines the generic configuration,
statistics and RPC for connection-oriented OAM
to be used within IETF in a protocol-independent manner.
Functional-level abstraction is independent
with YANG modeling. It is assumed that each protocol
maps corresponding abstracts to its native format.
Each protocol may extend the YANG data model defined
here to include protocol-specific extensions
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2019 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8531; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8531の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2019-04-16 {
description
"Initial revision.";
reference
"RFC 8531: Generic YANG Data Model for Connection-
Oriented Operations, Administration, and Maintenance (OAM)
Protocols";
}
feature connectivity-verification {
description
"This feature indicates that the server supports
executing a connectivity verification OAM command and
returning a response. Servers that do not advertise
this feature will not support executing a
connectivity verification command or RPC model for a
connectivity verification command.";
}
feature continuity-check {
description
"This feature indicates that the server supports
executing a Continuity Check OAM command and
returning a response. Servers that do not advertise
this feature will not support executing a
Continuity Check command or RPC model for a
Continuity Check command.";
}
feature traceroute {
description
"This feature indicates that the server supports
executing a traceroute OAM command and
returning a response. Servers that do not advertise
this feature will not support executing a
traceroute command or RPC model for a
traceroute command.";
}
feature mip {
description
"This feature indicates that the Maintenance
Intermediate Point (MIP) needs to be explicitly configured";
}
｝
identity technology-types {
description
"This is the base identity of technology types that are
TRILL, MPLS-TP, etc.";
}
identity command-sub-type {
description
"Defines different RPC command subtypes,
e.g., TRILL OAM as specified in RFC 6905; this is
optional for most cases.";
reference
"RFC 6905: Requirements for OAM in Transparent
Interconnection of Lots of Links (TRILL)";
}
identity on-demand {
base command-sub-type;
description
"On-demand activation indicates that the tool is activated
manually to detect a specific anomaly.
An on-demand OAM method requires only transient configuration.";
reference
"RFC 7276: An Overview of Operations, Administration, and
Maintenance (OAM) Tools";
}
identity proactive {
base command-sub-type;
description
"Proactive activation indicates that the tool is activated on a
continual basis, where messages are sent periodically, and errors
are detected when a certain number of expected messages are not
received. A proactive OAM method requires persistent
configuration.";
reference
"RFC 7276: An Overview of Operations, Administration, and
Maintenance (OAM) Tools";
}
identity name-format {
description
"This defines the name format, CFM (IEEE 802.1Q) defines varying
styles of names. It is expected that name format is an identity
reference to be extended with new types.";
}
identity name-format-null {
base name-format;
description
"Defines name format as null.";
}
identity identifier-format {
description
"Identifier-format identity can be augmented to define other
format identifiers used in MEP-ID, etc.";
}
identity identifier-format-integer {
base identifier-format;
description
"Defines identifier-format to be integer.";
}
identity defect-types {
description
"Defines different defect types, e.g.,
Remote Defect Indication (RDI), loss of continuity.";
}
identity rdi {
base defect-types;
description
"The RDI indicates the
aggregate health of the remote Maintenance End Points (MEPs).";
}
identity remote-mep-defect {
base defect-types;
description
"Indicates that one or more of the remote MEPs are
reporting a failure.";
}
identity loss-of-continuity {
base defect-types;
description
"Indicates that there are no proactive Continuity Check (CC)
OAM packets from the source MEP (and in the case of
Connectivity Verification, this includes the requirement to have
the expected unique, technology-dependent source MEP identifier)
received within the interval.";
reference
"RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks";
}
identity cv-defect {
base defect-types;
description
"This function should support monitoring between the MEPs
and, in addition, between a MEP and MIP. When performing
Connectivity Verification, the Continuity Check and
Connectivity Verification (CC-V) messages need to include
unique identification of the MEG that is being monitored and
the MEP that originated the message.";
reference
"RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks";
}
identity invalid-oam-defect {
base defect-types;
description
"Indicates that one or more invalid OAM messages have been
received and that 3.5 times that OAM message transmission
interval has not yet expired.";
}
identity cross-connect-defect {
base defect-types;
description
"Indicates that one or more cross-connect defect
(for example, a service ID does not match the VLAN)
messages have been received and that 3.5 times that OAM message
transmission interval has not yet expired.";
}
typedef mep-name {
type string;
description
"Generic administrative name for a MEP.";
}
typedef time-interval {
type decimal64 {
fraction-digits 2;
}
units "milliseconds";
description
"Time interval between packets in milliseconds.
Time interval should not be less than 0.
0 means no packets are sent.";
}
typedef md-name-string {
type string;
description
"Generic administrative name for Maintenance Domain (MD).";
}
typedef ma-name-string {
type string;
description
"Generic administrative name for a
Maintenance Association (MA).";
}
typedef oam-counter32 {
type yang:zero-based-counter32;
description
"Define 32-bit counter for OAM.";
}
typedef md-level {
type uint32 {
range "0..255";
}
description
"Maintenance Domain Level. The level may be restricted in
certain protocols (e.g., protocol in layer 0 to layer 7).";
}
grouping maintenance-domain-reference {
description
"This grouping uniquely identifies a Maintenance Domain.";
leaf maintenance-domain {
type leafref {
path "/co-oam:domains/co-oam:domain/co-oam:md-name-string";
}
description
"A reference to a specific Maintenance Domain.";
}
}
grouping maintenance-association-reference {
description
"This grouping uniquely identifies a
Maintenance Association. It consists
of a maintenance-domain-reference and
a maintenance-association leafref.";
uses maintenance-domain-reference;
leaf maintenance-association {
type leafref {
path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
+ "= current()/../maintenance-domain]/co-oam:mas"
+ "/co-oam:ma/co-oam:ma-name-string";
}
description
"A reference to a specific Maintenance Association.";
}
}
grouping maintenance-association-end-point-reference {
description
"This grouping uniquely identifies
a Maintenance Association. It consists
of a maintenance-association-reference and
a maintenance-association-end-point leafref.";
uses maintenance-association-reference;
leaf maintenance-association-end-point {
type leafref {
path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
+ "= current()/../maintenance-domain]/co-oam:mas"
+ "/co-oam:ma[co-oam:ma-name-string = "
+ "current()/../maintenance-association]"
+ "/co-oam:mep/co-oam:mep-name";
}
description
"A reference to a specific Maintenance
association End Point.";
}
}
grouping time-to-live {
leaf ttl {
type uint8;
description
"Time to Live.";
}
description
"Time to Live grouping.";
}
grouping defect-message {
choice defect {
case defect-null {
description
"This is a placeholder when no defect status is needed.";
leaf defect-null {
type empty;
description
"There is no defect to be defined; it will be defined in
a technology-specific model.";
}
}
case defect-code {
description
"This is a placeholder to display defect code.";
leaf defect-code {
type int32;
description
"Defect code is integer value specific to a technology.";
}
}
description
"Defect Message choices.";
}
description
"Defect Message.";
}
grouping mep-address {
choice mep-address {
default "ip-address";
case mac-address {
leaf mac-address {
type yang:mac-address;
description
"MAC Address.";
}
description
"MAC Address based MEP Addressing.";
}
case ip-address {
leaf ip-address {
type inet:ip-address;
description
"IP Address.";
}
description
"IP Address based MEP Addressing.";
}
description
"MEP Addressing.";
}
description
"Grouping for MEP Address";
}
grouping mip-address {
choice mip-address {
default "ip-address";
case mac-address {
leaf mac-address {
type yang:mac-address;
description
"MAC Address of Maintenance Intermediate Point";
}
description
"MAC Address based MIP Addressing.";
}
case ip-address {
leaf ip-address {
type inet:ip-address;
description
"IP Address.";
}
description
"IP Address based MIP Addressing.";
}
description
"MIP Addressing.";
}
description
"MIP Address.";
}
grouping maintenance-domain-id {
description
"Grouping containing leaves sufficient to identify
a Maintenance Domain.";
leaf technology {
type identityref {
base technology-types;
}
mandatory true;
description
"Defines the technology.";
}
leaf md-name-string {
type md-name-string;
mandatory true;
description
"Defines the generic administrative Maintenance Domain name.";
}
}
grouping md-name {
leaf md-name-format {
type identityref {
base name-format;
}
description
"Maintenance Domain Name format.";
}
choice md-name {
case md-name-null {
leaf md-name-null {
when "derived-from-or-self(../md-name-format,"
+ "'name-format-null')" {
description
"MD name format is equal to null format.";
}
type empty;
description
"MD name null.";
}
}
description
"MD name.";
}
description
"MD name.";
}
grouping ma-identifier {
description
"Grouping containing leaves sufficient to identify an MA.";
leaf ma-name-string {
type ma-name-string;
description
"MA name string.";
}
}
grouping ma-name {
description
"MA name.";
leaf ma-name-format {
type identityref {
base name-format;
}
description
"MA name format.";
}
choice ma-name {
case ma-name-null {
leaf ma-name-null {
when "derived-from-or-self(../ma-name-format,"
+ "'name-format-null')" {
description
"MA.";
}
type empty;
description
"Empty";
}
}
description
"MA name.";
}
}
grouping mep-id {
choice mep-id {
default "mep-id-int";
case mep-id-int {
leaf mep-id-int {
type int32;
description
"MEP ID
in integer format.";
}
}
description
"MEP ID.";
}
leaf mep-id-format {
type identityref {
base identifier-format;
}
description
"MEP ID format.";
}
description
"MEP ID.";
}
grouping mep {
グループ化mep {
description
"Defines elements within the MEP.";
leaf mep-name {
type mep-name;
mandatory true;
description
"Generic administrative name of the
MEP.";
}
uses mep-id;
uses mep-address;
}
grouping monitor-stats {
description
"Grouping for monitoring statistics; this will be augmented
by others who use this component.";
choice monitor-stats {
default "monitor-null";
case monitor-null {
description
"This is a placeholder when
no monitoring statistics are needed.";
leaf monitor-null {
type empty;
description
"There are no monitoring statistics to be defined.";
}
}
description
"Define the monitor stats.";
}
}
grouping connectivity-context {
description
"Grouping defining the connectivity context for an MA,
for example, an LSP for MPLS-TP. This will be
augmented by each protocol that uses this component.";
choice connectivity-context {
default "context-null";
case context-null {
description
"This is a placeholder when no context is needed.";
leaf context-null {
type empty;
description
"There is no context to be defined.";
}
}
description
"Connectivity context.";
}
}
grouping cos {
description
"Grouping for Priority used in transmitted packets,
for example, in the CoS field in MPLS-TP.";
leaf cos-id {
type uint8;
description
"Class of Service (CoS) ID; this value is used to indicate
Class of Service information .";
}
}
grouping mip-grouping {
uses mip-address;
description
"Grouping for MIP
configuration.";
}
container domains {
description
"Contains configuration related data. Within the
container, there is a list of fault domains. Each
domain has a list of MAs.";
list domain {
key "technology md-name-string";
description
"Define a list of Domains within the
ietf-connection-oriented-oam module.";
uses maintenance-domain-id;
uses md-name;
leaf md-level {
type md-level;
description
"Define the MD level.";
}
container mas {
description
"Contains configuration-related data. Within the
container, there is a list of MAs. Each MA has a
list of MEPs.";
list ma {
key "ma-name-string";
uses ma-identifier;
uses ma-name;
uses connectivity-context;
uses cos {
description
"Default class of service for this MA;
it may be overridden for particular MEPs,
sessions, or operations.";
}
leaf cc-enable {
type boolean;
description
"Indicate whether the CC is enabled.";
}
list mep {
key "mep-name";
description
"Contain a list of MEPs.";
uses mep;
uses cos;
leaf cc-enable {
type boolean;
description
"Indicate whether the CC is enabled.";
}
list session {
key "session-cookie";
description
"Monitoring session to/from a particular remote MEP.
Depending on the protocol, this could represent
CC messages received from a single remote MEP (if the
protocol uses multicast CCs) or a target to which
unicast echo request CCs are sent and from which
responses are received (if the protocol uses a
unicast request/response mechanism).";
leaf session-cookie {
type uint32;
description
"Cookie to identify different sessions, when there
are multiple remote MEPs or multiple sessions to
the same remote MEP.";
}
container destination-mep {
uses mep-id;
description
"Destination MEP.";
}
container destination-mep-address {
uses mep-address;
description
"Destination MEP Address.";
}
uses cos;
}
}
list mip {
if-feature "mip";
key "name";
leaf name {
type string;
description
"Identifier of Maintenance Intermediate Point";
}
leaf interface {
type if:interface-ref;
description
"Interface.";
}
uses mip-grouping;
description
"List for MIP.";
}
description
"Maintenance Association list.";
}
}
}
}
notification defect-condition-notification {
description
"When the defect condition is met, this notification is sent.";
leaf technology {
type identityref {
base technology-types;
}
description
"The technology.";
}
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to.";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
}
leaf mep-name {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Indicate which MEP is seeing the defect.";
}
leaf defect-type {
type identityref {
base defect-types;
}
description
"The currently active defects on the specific MEP.";
}
container generating-mepid {
uses mep-id;
description
"Indicate who is generating the defect (if known). If
unknown, set it to 0.";
}
uses defect-message {
description
"Defect message to provide more details.";
}
}
notification defect-cleared-notification {
description
"When the defect is cleared, this notification is sent.";
leaf technology {
type identityref {
base technology-types;
}
description
"The technology.";
}
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
}
leaf mep-name {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Indicate which MEP is seeing the defect.";
}
leaf defect-type {
type identityref {
base defect-types;
}
description
"The currently active defects on the specific MEP.";
}
container generating-mepid {
uses mep-id;
description
"Indicate who is generating the defect (if known). If
unknown, set it to 0.";
}
uses defect-message {
description
"Defect message to provide more details.";
}
}
rpc continuity-check {
if-feature "continuity-check";
description
"Generates Continuity Check as per Table 4 of RFC 7276.";
input {
leaf technology {
type identityref {
base technology-types;
}
description
"The technology.";
}
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to.";
}
leaf md-level {
type leafref {
path "/domains/domain/md-level";
}
description
"The Maintenance Domain Level.";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
}
uses cos;
uses time-to-live;
leaf sub-type {
type identityref {
base command-sub-type;
}
description
"Defines different command types.";
}
leaf source-mep {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Source MEP.";
}
container destination-mep {
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
description
"Destination MEP.";
}
leaf count {
type uint32;
default "3";
description
"Number of continuity-check messages to be sent.";
}
leaf cc-transmit-interval {
type time-interval;
description
"Time interval between echo requests.";
}
leaf packet-size {
type uint32 {
range "64..10000";
}
description
"Size of continuity-check packets, in octets.";
}
}
output {
uses monitor-stats {
description
"Stats of Continuity Check.";
}
}
}
rpc continuity-verification {
if-feature "connectivity-verification";
description
"Generates Connectivity Verification as per Table 4 in RFC 7276.";
input {
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to.";
}
leaf md-level {
type leafref {
path "/domains/domain/md-level";
}
description
"The Maintenance Domain Level.";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
}
uses cos;
uses time-to-live;
leaf sub-type {
type identityref {
base command-sub-type;
}
description
"Defines different command types.";
}
leaf source-mep {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Source MEP.";
}
container destination-mep {
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
description
"Destination MEP.";
}
leaf count {
type uint32;
default "3";
description
"Number of continuity-verification messages to be sent.";
}
leaf interval {
type time-interval;
description
"Time interval between echo requests.";
}
leaf packet-size {
type uint32 {
range "64..10000";
}
description
"Size of continuity-verification packets, in octets.";
}
}
output {
uses monitor-stats {
description
"Stats of Continuity Check.";
}
}
}
rpc traceroute {
if-feature "traceroute";
description
"Generates Traceroute or Path Trace and returns response.
References RFC 7276 for common Toolset name -- for
MPLS-TP OAM, it's Route Tracing, and for TRILL OAM, it's
Path Tracing tool. Starts with TTL of one and increments
by one at each hop until the destination is reached or TTL
reaches max value.";
input {
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to.";
}
leaf md-level {
type leafref {
path "/domains/domain/md-level";
}
description
"The Maintenance Domain Level.";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
}
uses cos;
uses time-to-live;
leaf command-sub-type {
type identityref {
base command-sub-type;
}
description
"Defines different command types.";
}
leaf source-mep {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Source MEP.";
}
container destination-mep {
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
description
"Destination MEP.";
}
leaf count {
type uint32;
default "1";
description
"Number of traceroute probes to send. In protocols where a
separate message is sent at each TTL, this is the number
of packets to be sent at each TTL.";
}
leaf interval {
type time-interval;
description
"Time interval between echo requests.";
}
}
output {
list response {
key "response-index";
leaf response-index {
type uint8;
description
"Arbitrary index for the response. In protocols that
guarantee there is only a single response at each TTL,
the TTL can be used as the response index.";
}
uses time-to-live;
container destination-mep {
description
"MEP from which the response has been received";
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
}
container mip {
if-feature "mip";
leaf interface {
type if:interface-ref;
description
"MIP interface.";
}
uses mip-address;
description
"MIP responding with traceroute";
}
uses monitor-stats {
description
"Stats of traceroute.";
}
description
"List of responses.";
}
}
}
}
<CODE ENDS>
<コード終了>
The Base Mode ("default mode" described in Section 4) defines the default configuration that MUST be present in the devices that comply with this document. Base Mode allows users to have a "zero-touch" experience. Several parameters require technology-specific definition.
基本モード（セクション4で説明する「デフォルトモード」）は、このドキュメントに準拠するデバイスに存在する必要があるデフォルト設定を定義します。基本モードでは、ユーザーは「ゼロタッチ」体験をすることができます。いくつかのパラメーターには、テクノロジー固有の定義が必要です。
In the Base Mode of operation, the MEP Address is by default the IP address of the interface on which the MEP is located.
基本動作モードでは、MEPアドレスはデフォルトで、MEPが配置されているインターフェイスのIPアドレスです。
In the Base Mode of operation, each device creates a single MEP associated with a virtual OAM port with no physical layer (NULL PHY). The MEP-ID associated with this MEP is zero (0). The choice of MEP-ID of zero is explained below.
基本動作モードでは、各デバイスは、物理層のない（NULL PHY）仮想OAMポートに関連付けられた単一のMEPを作成します。このMEPに関連付けられたMEP-IDはゼロ（0）です。ゼロのMEP-IDの選択については、以下で説明します。
MEP-ID is a 2-octet field by default. It is never used on the wire except when using CCM. It is important to have a method that can derive the MEP-ID of Base Mode in an automatic manner with no user intervention. The IP address cannot be directly used for this purpose, as the MEP-ID is a much smaller field. For the Base Mode of operation, MEP-ID is set to zero by default.
MEP-IDは、デフォルトでは2オクテットのフィールドです。 CCMを使用する場合を除いて、ネットワーク上で使用されることはありません。ユーザーの介入なしに自動的にベースモードのMEP-IDを導出できる方法を用意することが重要です。 MEP-IDははるかに小さいフィールドであるため、IPアドレスを直接この目的で使用することはできません。基本動作モードの場合、MEP-IDはデフォルトでゼロに設定されています。
The CCM packet uses the MEP-ID in the payload. CCM MUST NOT be used in the Base Mode. Hence, CCM MUST be disabled on the Maintenance Association of the Base Mode.
CCMパケットは、ペイロードでMEP-IDを使用します。 CCMは基本モードで使用してはなりません。したがって、ベースモードのメンテナンスアソシエーションではCCMを無効にする必要があります。
If CCM is required, users MUST configure a separate Maintenance Association and assign unique values for the corresponding MEP IDs.
CCMが必要な場合、ユーザーは別のメンテナンスアソシエーションを構成し、対応するMEP IDに一意の値を割り当てる必要があります。
CFM [IEEE802.1Q] defines MEP-ID as an unsigned integer in the range 1 to 8191. In this document, we propose extending the range to 0 to 65535. Value 0 is reserved for the MEP-ID in the Base Mode operation and MUST NOT be used for other purposes.
CFM [IEEE802.1Q]は、MEP-IDを1〜8191の範囲の符号なし整数として定義します。このドキュメントでは、範囲を0〜65535に拡張することを提案します。値0は、ベースモード操作のMEP-ID用に予約されています。他の目的で使用してはなりません。
The ID of the Maintenance Association (MA-ID) [IEEE802.1Q] has a flexible format and includes two parts: Maintenance Domain Name and Short MA name. In the Base Mode of operation, the value of the Maintenance Domain Name must be the character string "GenericBaseMode" (excluding the quotes). In the Base Mode operation, the Short MA Name format is set to a 2-octet integer format (value 3 in Short MA Format field [IEEE802.1Q]) and the Short MA name is set to 65532 (0xFFFC).
メンテナンスアソシエーションのID（MA-ID）[IEEE802.1Q]は柔軟な形式で、メンテナンスドメイン名と短いMA名の2つの部分で構成されています。基本動作モードでは、メンテナンスドメイン名の値は文字列「GenericBaseMode」（引用符を除く）でなければなりません。基本モード操作では、ショートMA名のフォーマットは2オクテット整数フォーマット（ショートMAフォーマットフィールド[IEEE802.1Q]の値3）に設定され、ショートMA名は65532（0xFFFC）に設定されます。
The "ietf-connection-oriented-oam" module defined in this document provides a technology-independent abstraction of key OAM constructs for connection-oriented protocols. This module can be further extended to include technology-specific details, e.g., adding new data nodes with technology-specific functions and parameters into proper anchor points of the base model, so as to develop a technology-specific connection-oriented OAM model.
このドキュメントで定義されている「ietf-connection-oriented-oam」モジュールは、コネクション型プロトコルの主要なOAMコンストラクトのテクノロジーに依存しない抽象化を提供します。このモジュールをさらに拡張して、テクノロジー固有の詳細を含めることができます。たとえば、テクノロジー固有の機能とパラメーターを持つ新しいデータノードをベースモデルの適切なアンカーポイントに追加して、テクノロジー固有の接続指向のOAMモデルを開発できます。
This section demonstrates the usability of the connection-oriented YANG OAM data model to various connection-oriented OAM technologies, e.g., TRILL and MPLS-TP. Note that, in this section, we only present several snippets of technology-specific model extensions for illustrative purposes. The complete model extensions should be worked on in respective protocol working groups.
このセクションでは、さまざまな接続指向のOAMテクノロジー（TRILLやMPLS-TPなど）に対する接続指向のYANG OAMデータモデルの使いやすさを示します。このセクションでは、説明のために、テクノロジー固有のモデル拡張のいくつかのスニペットのみを示しています。完全なモデル拡張は、それぞれのプロトコルワーキンググループで作業する必要があります。
The TRILL OAM YANG module [TRILL-YANG-OAM] is augmenting the connection-oriented OAM module for both configuration and RPC commands.
TRILL OAM YANGモジュール[TRILL-YANG-OAM]は、構成とRPCコマンドの両方の接続指向のOAMモジュールを拡張しています。
In addition,the TRILL OAM YANG module also requires the base TRILL module ([TRILL-YANG]) to be supported, as there is a strong relationship between those modules.
さらに、TRILL OAM YANGモジュールは、基本的なTRILLモジュール（[TRILL-YANG]）もサポートする必要があります。これは、これらのモジュール間に強い関係があるためです。
The configuration extensions for connection-oriented OAM include the MD configuration extension, technology type extension, MA configuration extension, Connectivity-Context extension, MEP Configuration extension, and ECMP extension. In the RPC extension, the continuity-check and path-discovery RPC are extended with TRILL-specific parameters.
コネクション型OAMの構成拡張には、MD構成拡張、テクノロジータイプ拡張、MA構成拡張、接続性コンテキスト拡張、MEP構成拡張、およびECMP拡張が含まれます。 RPC拡張では、導通チェックとパス検出RPCがTRILL固有のパラメーターで拡張されています。
MD level configuration parameters are management information that can be inherited in the TRILL OAM model and set by the connection-oriented base model as default values. For example, domain name can be set to area-ID in the TRILL OAM case. In addition, at the Maintenance Domain Level (i.e., at root level), the domain data node can be augmented with technology type.
MDレベルの構成パラメーターは、TRILL OAMモデルで継承され、接続指向の基本モデルによってデフォルト値として設定できる管理情報です。たとえば、TRILL OAMの場合、ドメイン名をarea-IDに設定できます。さらに、メンテナンスドメインレベル（つまり、ルートレベル）では、ドメインデータノードにテクノロジータイプを追加できます。
Note that MD level configuration parameters provide context information for the management system to correlate faults, defects, and network failures with location information; this helps quickly identify root causes of network failures.
MDレベルの構成パラメーターは、管理システムがコンテキスト情報を提供して、障害、欠陥、およびネットワーク障害を場所情報と関連付けることに注意してください。これにより、ネットワーク障害の根本的な原因をすばやく特定できます。
No TRILL technology type has been defined in the connection-oriented base model. Therefore, a technology type extension is required in the TRILL OAM model. The technology type "trill" is defined as an identity that augments the base "technology-types" defined in the connection-oriented base model:
接続指向の基本モデルでは、TRILLテクノロジータイプは定義されていません。したがって、TRILL OAMモデルではテクノロジータイプの拡張が必要です。テクノロジータイプ「trill」は、コネクション型ベースモデルで定義されたベース「テクノロジータイプ」を補強するアイデンティティとして定義されます。
identity trill{
base co-oam:technology-types;
description
"trill type";
}
MA level configuration parameters are management information that can be inherited in the TRILL OAM model and set by the connection-oriented base model as default values. In addition, at the Maintenance Association (MA) level (i.e., at the second level), the MA data node can be augmented with a connectivity-context extension.
MAレベルの構成パラメーターは、TRILL OAMモデルで継承でき、接続指向の基本モデルによってデフォルト値として設定できる管理情報です。さらに、メンテナンスアソシエーション（MA）レベル（つまり、第2レベル）では、MAデータノードに接続性コンテキスト拡張を追加できます。
Note that MA level configuration parameters provide context information for the management system to correlate faults, defects, and network failures with location information; this helps quickly identify root causes of network failures.
MAレベルの構成パラメーターは、管理システムがコンテキスト情報を提供して、障害、欠陥、およびネットワーク障害を場所情報と関連付けることに注意してください。これにより、ネットワーク障害の根本的な原因をすばやく特定できます。
In TRILL OAM, one example of connectivity-context is either a 12-bit VLAN ID or a 24-bit Fine-Grained Label. The connection-oriented base model defines a placeholder for context-id. This allows other technologies to easily augment that to include technology-specific extensions. The snippet below depicts an example of augmenting connectivity-context to include either a VLAN ID or Fine-Grained Label.
TRILL OAMでは、接続性コンテキストの1つの例は、12ビットのVLAN IDまたは24ビットの細粒度ラベルです。接続指向の基本モデルは、コンテキストIDのプレースホルダーを定義します。これにより、他のテクノロジーがテクノロジー固有の拡張機能を含めるように簡単に拡張できます。以下のスニペットは、VLAN-IDまたは細かいラベルのいずれかを含めるために接続コンテキストを拡張する例を示しています。
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:connectivity-context:
+--:(connectivity-context-vlan)
| +--rw connectivity-context-vlan? vlan
+--:(connectivity-context-fgl)
+--rw connectivity-context-fgl? fgl
The MEP configuration definition in the connection-oriented base model already supports configuring the interface of MEP with either a MAC address or IP address. In addition, the MEP address can be represented using a 2-octet RBridge Nickname in TRILL OAM. Hence, the TRILL OAM model augments the MEP configuration in the base model to add a nickname case to the MEP address choice node as follows:
コネクション型基本モデルのMEP構成定義は、MACアドレスまたはIPアドレスのいずれかを使用したMEPのインターフェースの構成をすでにサポートしています。さらに、MEPアドレスは、TRILL OAMの2オクテットRBridgeニックネームを使用して表すことができます。したがって、TRIL OAMモデルは、基本モデルのMEP構成を拡張して、ニックネームケースをMEPアドレス選択ノードに次のように追加します。
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address:
+--:( mep-address-trill)
| +--rw mep-address-trill? tril-rb-nickname
In addition, at the Maintenance association End Point (MEP) level (i.e., at the third level), the MEP data node can be augmented with an ECMP extension.
さらに、メンテナンスアソシエーションエンドポイント（MEP）レベル（つまり、3番目のレベル）では、MEPデータノードをECMP拡張で拡張できます。
Since TRILL supports ECMP path selection, flow-entropy in TRILL is defined as a 96-octet field in the Layer-Independent OAM Management in the Multi-Layer Environment (LIME) model extension for TRILL OAM. The snippet below illustrates its extension.
TRILLはECMPパス選択をサポートしているため、TRILLのフローエントロピーは、TRILL OAMのマルチレイヤー環境（LIME）モデル拡張のレイヤー非依存OAM管理の96オクテットフィールドとして定義されます。以下のスニペットは、その拡張を示しています。
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep:
+--rw flow-entropy-trill? flow-entropy-trill
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
+--rw flow-entropy-trill? flow-entropy-trill
In the TRILL OAM YANG data model, the continuity-check and path-discovery RPC commands are extended with TRILL-specific requirements. The snippet below depicts an example of the TRILL OAM RPC extension.
TRILL OAM YANGデータモデルでは、導通チェックとパス検出RPCコマンドがTRILL固有の要件で拡張されています。以下のスニペットは、TRILL OAM RPC拡張の例を示しています。
augment /co-oam:continuity-check/co-oam:input:
+--ro (out-of-band)?
| +--:(ipv4-address)
| | +--ro ipv4-address? inet:ipv4-address
| +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean
augment /co-oam:continuity-check/co-oam:input:
+--ro flow-entropy-trill? flow-entropy-trill
augment /co-oam:continuity-check/co-oam:output:
+--ro upstream-rbridge? tril-rb-nickname
+--ro next-hop-rbridge* tril-rb-nickname
augment /co-oam:path-discovery/co-oam:input:
+--ro (out-of-band)?
| +--:(ipv4-address)
| | +--ro ipv4-address? inet:ipv4-address
| +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean
augment /co-oam:path-discovery/co-oam:input:
+--ro flow-entropy-trill? flow-entropy-trill
augment /co-oam:path-discovery/co-oam:output/co-oam:response:
+--ro upstream-rbridge? tril-rb-nickname
+--ro next-hop-rbridge* tril-rb-nickname
The MPLS-TP OAM YANG module can augment the connection-oriented OAM module with some technology-specific details. [MPLS-TP-OAM-YANG] presents the YANG data model for MPLS-TP OAM.
MPLS-TP OAM YANGモジュールは、テクノロジー固有の詳細を使用して、コネクション型OAMモジュールを補強できます。 [MPLS-TP-OAM-YANG]は、MPLS-TP OAMのYANGデータモデルを示します。
The configuration extensions for connection-oriented OAM include the MD configuration extension, Technology type extension, Technology Subtype extension, MA configuration extension, and MEP Configuration extension.
コネクション型OAMの構成拡張には、MD構成拡張、テクノロジータイプ拡張、テクノロジーサブタイプ拡張、MA構成拡張、およびMEP構成拡張が含まれます。
MD level configuration parameters are management information that can be inherited in the MPLS-TP OAM model and set by the connection-oriented OAM base model as default values. For example, domain name can be set to area-ID or the provider's Autonomous System Number (ASN) [RFC6370] in the MPLS-TP OAM case. In addition, at the Maintenance Domain Level (i.e., at root level), the domain data node can be augmented with technology type and technology subtype.
MDレベルの構成パラメーターは、MPLS-TP OAMモデルで継承され、接続指向のOAM基本モデルによってデフォルト値として設定できる管理情報です。たとえば、MPLS-TP OAMの場合、ドメイン名をエリアIDまたはプロバイダーの自律システム番号（ASN）[RFC6370]に設定できます。さらに、メンテナンスドメインレベル（つまり、ルートレベル）では、ドメインデータノードにテクノロジータイプとテクノロジーサブタイプを追加できます。
Note that MD level configuration parameters provide context information for the management system to correlate faults, defects, and network failures with location information; this helps quickly identify root causes of network failures
MDレベルの構成パラメーターは、管理システムがコンテキスト情報を提供して、障害、欠陥、およびネットワーク障害を場所情報と関連付けることに注意してください。これにより、ネットワーク障害の根本的な原因をすばやく特定できます
No MPLS-TP technology type has been defined in the connection-oriented base model, hence it is required in the MPLS-TP OAM model. The technology type "mpls-tp" is defined as an identity that augments the base "technology-types" defined in the connection-oriented base model:
接続指向の基本モデルではMPLS-TPテクノロジータイプが定義されていないため、MPLS-TP OAMモデルでは必須です。テクノロジータイプ「mpls-tp」は、コネクション型ベースモデルで定義されたベース「テクノロジータイプ」を補強するIDとして定義されます。
identity mpls-tp{
base co-oam:technology-types;
description
"mpls-tp type";
}
In MPLS-TP, since different encapsulation types such as IP/UDP encapsulation and PW-ACH encapsulation can be employed, the "technology-sub-type" data node is defined and added into the MPLS-TP OAM model to further identify the encapsulation types within the MPLS-TP OAM model. Based on it, we also define a technology subtype for IP/UDP encapsulation and PW-ACH encapsulation. Other encapsulation types can be defined in the same way. The snippet below depicts an example of several encapsulation types.
MPLS-TPでは、IP / UDPカプセル化やPW-ACHカプセル化などのさまざまなカプセル化タイプを使用できるため、「テクノロジーサブタイプ」データノードが定義され、MPLS-TP OAMモデルに追加されてカプセル化をさらに識別しますMPLS-TP OAMモデル内のタイプ。これに基づいて、IP / UDPカプセル化およびPW-ACHカプセル化のテクノロジーサブタイプも定義します。他のカプセル化タイプも同じ方法で定義できます。以下のスニペットは、いくつかのカプセル化タイプの例を示しています。
identity technology-sub-type {
description
"Certain implementations can have different
encapsulation types such as IP/UDP, PW-ACH, and so on.
Instead of defining separate models for each
encapsulation, we define a technology subtype to
further identify different encapsulations.
Technology subtype is associated at the MA level."; }
identity technology-sub-type-udp {
base technology-sub-type;
description
"Technology subtype is IP/UDP encapsulation.";
}
identity technology-sub-type-ach {
base technology-sub-type;
description
"Technology subtype is PW-ACH encapsulation.";
}
}
augment "/co-oam:domains/co-oam:domain"
+ "/co-oam:mas/co-oam:ma" {
leaf technology-sub-type {
type identityref {
base technology-sub-type;
}
}
}
MA level configuration parameters are management information that can be inherited in the MPLS-TP OAM model and set by the connection-oriented OAM base model as default values. Examples of MA Name are MPLS-TP LSP MEG_ID, MEG Section ID, or MEG PW ID [RFC6370].
MAレベルの構成パラメーターは、MPLS-TP OAMモデルで継承でき、コネクション型OAMベースモデルによってデフォルト値として設定できる管理情報です。 MA名の例は、MPLS-TP LSP MEG_ID、MEGセクションID、またはMEG PW ID [RFC6370]です。
Note that MA level configuration parameters provide context information for the management system to correlate faults, defects, and network failures with location information; this helps quickly identify root causes of network failures.
MAレベルの構成パラメーターは、管理システムがコンテキスト情報を提供して、障害、欠陥、およびネットワーク障害を場所情報と関連付けることに注意してください。これにより、ネットワーク障害の根本的な原因をすばやく特定できます。
In MPLS-TP, MEP-ID is either a variable-length label value in case of G-ACH encapsulation or a 2-octet unsigned integer value in case of IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID
MPLS-TPでは、MEP-IDは、G-ACHカプセル化の場合は可変長のラベル値、IP / UDPカプセル化の場合は2オクテットの符号なし整数値です。 MEP-IDの1つの例は、MPLS-TP LSP_MEP_IDです。
[RFC6370]. In the connection-oriented base model, MEP-ID is defined as a choice/case node that can support an int32 value, and the same definition can be used for MPLS-TP with no further modification. In addition, at the Maintenance association End Point (MEP) level (i.e., at the third level), the MEP data node can be augmented with a session extension and interface extension.
[RFC6370]。接続指向の基本モデルでは、MEP-IDはint32値をサポートできる選択/ケースノードとして定義され、同じ定義をMPLS-TPに使用でき、それ以上の変更は不要です。さらに、メンテナンスアソシエーションエンドポイント（MEP）レベル（つまり、第3レベル）では、MEPデータノードにセッション拡張とインターフェース拡張を追加できます。
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）です[RFC6242]。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC8446]です。
The Network Configuration Access Control Model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成済みサブセットに制限する手段を提供します。
There are a number of data nodes defined in the YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
YANGモジュールで定義されている、書き込み可能/作成可能/削除可能なデータノードがいくつかあります（つまり、デフォルトのconfig true）。これらのデータノードは、一部のネットワーク環境では機密と見なされる場合があります。適切な保護なしにこれらのデータノードに書き込み操作（edit-configなど）を行うと、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
/co-oam:domains/co-oam:domain/
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/
co-oam:session
Unauthorized access to any of these lists can adversely affect OAM management system handling of end-to-end OAM and coordination of OAM within underlying network layers. This may lead to inconsistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network.
これらのリストへの不正アクセスは、OAM管理システムによるエンドツーエンドOAMの処理と、基盤となるネットワークレイヤー内のOAMの調整に悪影響を及ぼす可能性があります。これにより、ネットワークの管理に使用されるOAMメカニズムの構成、レポート、および表示に一貫性がなくなる可能性があります。
This document registers a URI in the "IETF XML Registry" [RFC3688]. The following registration has been made:
このドキュメントは、「IETF XMLレジストリ」[RFC3688]にURIを登録します。次の登録が行われました：
URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-connection-oriented-oam登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-connection-oriented-oam
namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
prefix: co-oam
reference: RFC 8531
[IEEE802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks", IEEE Std 802.1Q.
[IEEE802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、DOI 10.17487 / RFC6370、2011年9月、<https：//www.rfc- editor.org/info/rfc6370>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A。およびM. Bjorklund、「Network Configuration Access Control Model」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https://www.rfc-editor.org/info/rfc8341 >。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[G.800] "Unified functional architecture of transport networks", ITU-T Recommendation G.800, 2016.
[G.800]「トランスポートネットワークの統合機能アーキテクチャ」、ITU-T勧告G.800、2016。
[G.8013] "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, 2013.
[G.8013]「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T勧告G.8013 / Y.1731、2013。
[MEF-17] MEF Forum, "Service OAM Requirements & Framework - Phase 1", MEF 17, April 2007.
[MEF-17] MEF Forum, "Service OAM Requirements & Framework - Phase 1", MEF 17, April 2007.
[MPLS-TP-OAM-YANG] Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG Data Model for MPLS-TP Operations, Administration, and Maintenance (OAM)", Work in Progress, draft-zhang-mpls-tp-yang-oam-05, October 2017.
[MPLS-TP-OAM-YANG] Zhang、L.、Zheng、L.、Aldrin、S。、およびG. Mirsky、「MPLS-TP運用、管理、および保守（OAM）のYANGデータモデル」、Work in進捗状況、draft-zhang-mpls-tp-yang-oam-05、2017年10月。
[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, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、DOI 10.17487 / RFC6291、2011年6月、<https://www.rfc-editor.org/info/rfc6291>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.、Ed。およびD. Allan編、「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、DOI 10.17487 / RFC6371、2011年9月、<https://www.rfc-editor.org/info/ rfc6371>。
[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, DOI 10.17487/RFC6905, March 2013, <https://www.rfc-editor.org/info/rfc6905>.
[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, DOI 10.17487/RFC6905, March 2013, <https://www.rfc-editor.org/info/rfc6905>.
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, <https://www.rfc-editor.org/info/rfc7174>.
[RFC7174] Salam、S.、Senevirathne、T.、Aldrin、S。、およびD. Eastlake 3rd、「透過的な相互リンクの多くのリンク（TRILL）運用、管理、および保守（OAM）フレームワーク」、RFC 7174、DOI 10.17487 / RFC7174、2014年5月、<https://www.rfc-editor.org/info/rfc7174>。
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.
[RFC7276]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E。、およびY.ウェインガルテン、「運用、管理、および保守（OAM）ツールの概要」、RFC 7276、DOI 10.17487 / RFC7276、2014年6月、 <https://www.rfc-editor.org/info/rfc7276>。
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <https://www.rfc-editor.org/info/rfc7455>.
[RFC7455] Senevirathne、T.、Finn、N.、Salam、S.、Kumar、D.、Eastlake 3rd、D.、Aldrin、S。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：障害管理」、RFC 7455、DOI 10.17487 / RFC7455、2015年3月、<https://www.rfc-editor.org/info/rfc7455>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M。およびL. Berger、編、「YANG Tree Diagrams」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https://www.rfc-editor.org/info/ rfc8340>。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「Network Management Datastore Architecture（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、< https://www.rfc-editor.org/info/rfc8342>。
[RFC8532] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.
[RFC8532] Kumar、D.、Wang、M.、Wu、Q.、Ed。、Rahman、R。、およびS. Raghavan、「運用、管理、保守（OAM）プロトコルの管理のための汎用YANGデータモデルThat Use Connectionless Communications」、RFC 8532、DOI 10.17487 / RFC8532、2019年4月、<https://www.rfc-editor.org/info/rfc8532>。
[TRILL-YANG] Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., and L. Xia, "TRILL YANG Data Model", Work in Progress, draft-ietf-trill-yang-04, December 2015.
[TRILL-YANG] Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., and L. Xia, "TRILL YANG Data Model", Work in Progress, draft-ietf-trill-yang-04, December 2015.
[TRILL-YANG-OAM] Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., and H. Weiguo, "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)", Work in Progress, draft-ietf-trill-yang-oam-05, March 2017.
[TRILL-YANG-OAM] Kumar、D.、Senevirathne、T.、Finn、N.、Salam、S.、Xia、L。、およびH. Weiguo、「TRILLの運用、管理、および保守のためのYANGデータモデル（ OAM）」、作業中、draft-ietf-trill-yang-oam-05、2017年3月。
Acknowledgments
Acknowledgments
Giles Heron came up with the idea of developing a YANG data model as a way of creating a unified OAM API set (interface); this document was largely inspired by that. Alexander Clemm provided many valuable tips, comments, and remarks that helped to refine the YANG data model presented in this document.
Giles Heronは、統合されたOAM APIセット（インターフェース）を作成する方法として、YANGデータモデルを開発するというアイデアを思いつきました。このドキュメントは、主にそれに触発されました。 Alexander Clemmは、このドキュメントに記載されているYANGデータモデルの改良に役立つ多くの貴重なヒント、コメント、およびコメントを提供しました。
Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise, Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler, and Adi Molkho contributed to and participated in the development of this document.
Carlos Pignataro、David Ball、Mahesh Jethanandani、Benoit Claise、Ladislav Lhotka、Jens Guballa、Yuji Tochio、Gregory Mirsky、Huub van Helvoort、Tom Taylor、Dapeng Liu、Mishael Wexler、およびAdi Molkhoがこのドキュメントの開発に貢献し、参加しました。
Contributors
貢献者
Tissa Senevirathne Consultant
Tissa Senevirathneコンサルタント
Email: tsenevir@gmail.com
Norman Finn CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America
Norman Finn CISCO Systems 510 McCarthy Blvd Milpitas、CA 95035アメリカ合衆国
Email: nfinn@cisco.com Samer Salam CISCO Systems 595 Burrard St. Suite 2123 Vancouver, BC V7X 1J1 Canada
メール：nfinn@cisco.com Samer Salam CISCO Systems 595 Burrard St. Suite 2123バンクーバー、BC V7X 1J1カナダ
Email: ssalam@cisco.com
Authors' Addresses
著者のアドレス
Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America
Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas、CA 95035アメリカ合衆国
Email: dekumar@cisco.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
Email: bill.wu@huawei.com
Michael Wang Huawei Technologies, Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China
Michael Wang hu Aはテクノロジー株式会社です101ソフトウェアアベニュー、Y Uは地区NaN京210012中国を描画します
Email: wangzitao@huawei.com