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
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）协议的通用数据模型
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）协议的基本数据模型。它为此类协议提供了关键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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
[RFC7276]中介绍了OAM工具的概述。多年来，许多技术已经开发出类似的故障和性能管理工具。
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]）。[RFC8532]和[IEEE802.1Q]中规定了使用无连接通信的OAM协议的数据模型。
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]都定义了基于连接故障管理（CFM）[IEEE802.1Q]的可管理性框架的OAM机制。
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
鉴于CFM[IEEE802.1Q]中定义的基本OAM概念已被广泛采用，基于这些概念开发面向连接的OAM的统一管理框架是一个合理的选择。在本文档中，我们采用CFM[IEEE802.1Q]模型，并将其扩展到与技术无关的框架中，并相应地定义了相应的数据模型。本文中介绍的YANG数据模型是面向连接的OAM协议的基础模型，支持通用连续性检查、连接验证和路径发现（traceroute）。面向连接的OAM的通用数据模型设计为可扩展到其他面向连接的技术。技术相关节点
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).
远程过程调用（RPC）命令在特定于技术的数据模型中定义，这些数据模型使用并扩展了此处定义的基本模型。例如，虚拟可扩展局域网（VXLAN）使用源UDP端口号表示流熵，而TRILL使用（a）MAC地址、（b）VLAN标记或细粒度标签，和/或（c）IP地址表示多路径选择哈希中的流熵。为了捕捉这种变化，相应的YANG数据模型将定义适用的结构，作为对此处介绍的通用基础模型的补充。这实现了三个目标：首先，它使每个数据模型更小、更易于管理。其次，它允许独立开发相应的数据模型。第三，实现可以将支持限制为仅适用于一组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协议而异。希望发出连续性检查命令或环回或启动性能监视会话的用户可以以相同的方式执行此操作，而不考虑底层协议或技术或特定的供应商实现。
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发布相应的故障验证（环回消息）和故障隔离（Looktrace消息）工具。这种深入到路径中特定段的协议栈较低层以进行故障定位和故障排除的能力称为“嵌套OAM工作流”。这是一个非常有用的概念，可以引导高效的网络故障排除和维护工作流。本文中介绍的面向连接的OAM数据模型简化了这一过程，而无需更改底层协议。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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]
连接故障管理[RFC7174][IEEE802.1Q]
RPC - Remote Procedure Call
远程过程调用
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.
连接验证-连接验证用于验证目标是否已连接。它也被称为“路径验证”，不仅用于验证两个MPs是否连接，还用于验证它们是否通过预期路径连接，从而允许检测意外的拓扑变化。
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数据模型在某种意义上是通用的，其他技术可以扩展它以满足特定于技术的需求。面向连接的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 |
+-------------------------------------------------------+
+-----------+
|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.
在每个维护域下，都有一个或多个维护关联（MAs）。在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下，可以有两个或更多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.
命令显示在管理协议中，该协议与维护域正交。用杨的话来说，这些是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.
这里定义的通用数据模型中的OAM实体将使用任何OAM工具进行显式或隐式配置。此处使用的OAM工具仅限于[RFC7276]第5.1节中指定的OAM工具集。为了促进零接触体验，本文档定义了OAM的默认模式。OAM的默认模式称为“基本模式”，并为模型的每个参数指定默认值，例如维护域级别、维护关联的名称、MEP的地址等。这些的默认值取决于技术。颤音的基本模式在[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名称字符串”进行索引。“md name string”是一个从类型string派生的叶。[IEEE802.1Q]或其他标准中定义的其他名称格式可通过“md名称格式”与标识参考的关联来包含。“md名称格式”表示扩展的“md名称”的格式。“md名称”表示为选项/案例构造。因此，它很容易通过导数来扩充。
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
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".
在给定的维护域中，可以有一个或多个维护关联（MA）。ma表示为一个列表，并由“ma名称字符串”索引。与前面定义的“md名称”类似，可以通过增加名称格式“identity ref”并将适用的案例语句添加到“ma名称”来添加其他名称格式。
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
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)
与维护关联（MAs）相关的数据层次结构片段
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）中，可以有一个或多个维护端点（MEP）。mep表示为数据层次结构中的列表，并由键“mep名称”索引。
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
. .
. .
. .
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.
有几个RPC命令是为OAM而定义的。在本节中，我们提供了连续性检查命令的一个片段，以便于演示。请参阅第4.5节了解完整的数据层次结构，第5节了解YANG模块。
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)
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}?
| | | | +---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
| +--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名称、缺陷类型（当前活动的缺陷）、生成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.
监控统计数据的分组将由特定于技术的YANG模块使用，这些模块扩展了通用YANG数据模型，以提供由于主动OAM（如连续性检查消息）而产生的统计数据，例如，CCM传输、CCM接收、CCM错误等。
The complete data hierarchy related to the connection-oriented OAM YANG data model is presented below.
下面介绍了与面向连接的OAM数据模型相关的完整数据层次结构。
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
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
+--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
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 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
+---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
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]导入typedefs，并引用[RFC6371]、[RFC6905]和[RFC7276]。
<CODE BEGINS> file "ietf-connection-oriented-oam@2019-04-16.yang"
<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;
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;
}
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
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.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
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
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改
(http://trustee.ietf.org/license-info).
(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.";
此模块的此版本是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";
}
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 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 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 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";
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 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 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 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 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 {
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 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 {
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 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 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 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 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
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";
}
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 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 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.";
}
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 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.
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.";
}
0 means no packets are sent.";
}
typedef md-name-string {
type string;
description
"Generic administrative name for Maintenance Domain (MD).";
}
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 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 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).";
}
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-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
分组维护关联引用{description“此分组唯一标识维护关联。它由维护域引用和
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.";
}
}
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 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 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
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.";
}
"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.";
}
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";
}
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 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
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.";
}
}
"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 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-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;
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.";
}
}
}
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-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;
}
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 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.";
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.";
}
}
}
}
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 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.";
}
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.";
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.";
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.";
}
}
}
}
}
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;
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.";
}
}
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 {
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.";
}
}
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 {
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
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.";
}
}
}
"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";
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.";
}
}
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.";
}
}
}
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.";
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,
}
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.";
}
}
}
}
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.
在基本操作模式下，每个设备创建一个与没有物理层（空物理层）的虚拟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-octet字段。除非使用CCM，否则不得在导线上使用。重要的是要有一种方法，能够在无需用户干预的情况下自动导出基本模式的MEP-ID。IP地址不能直接用于此目的，因为MEP-ID是一个小得多的字段。对于基本操作模式，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
维护协会（MA-ID）[IEEE802.1Q]的ID具有灵活的格式，包括两部分：维护域名和短MA名称。在基本操作模式下，维护域名的值必须是字符串“GenericBaseMode”（不包括引号）。在基本模式下
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).
操作时，短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面向连接的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数据模型对各种面向连接的OAM技术的可用性，例如TRILL和MPLS-TP。请注意，在本节中，为了便于说明，我们只提供了一些特定于技术的模型扩展片段。完整的模型扩展应在各自的协议工作组中进行。
The TRILL OAM YANG module [TRILL-YANG-OAM] is augmenting the connection-oriented OAM module for both configuration and RPC commands.
TRILL-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案例中，域名可以设置为区域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";
}
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）级别（即，在第二级别），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中，连接上下文的一个示例是12位VLAN ID或24位细粒度标签。面向连接的基本模型为context-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
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昵称表示。因此，TRILL 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
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）级别（即，在第三级别），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
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
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模块可以通过一些特定于技术的细节来扩充面向连接的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”被定义为一个标识，它扩展了面向连接的基本模型中定义的基本“技术类型”：
identity mpls-tp{
base co-oam:technology-types;
description
"mpls-tp type";
}
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 {
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-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.";
}
}
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;
}
}
}
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中，在G-ACH封装的情况下，MEP-ID是可变长度标签值，在IP/UDP封装的情况下，MEP-ID是2-octet无符号整数值。MEP-ID的一个示例是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）级别（即，在第三级别），可以使用会话扩展和接口扩展来扩充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].
本文档中指定的模块为数据定义了一个模式，该模式旨在通过网络管理协议（如NETCONF[RFC6241]或restcconf[RFC8040]）进行访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（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，这是默认值）。在某些网络环境中，这些数据节点可能被认为是敏感的。对这些数据节点的写入操作（如编辑配置）如果没有适当的保护，可能会对网络操作产生负面影响。这些是子树和数据节点及其敏感性/漏洞：
/co-oam:domains/co-oam:domain/
/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: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:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/
co-oam:session
/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面向连接的oam注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
本文件在“阳模块名称”注册表[RFC6020]中注册阳模块。
name: ietf-connection-oriented-oam
namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
prefix: co-oam
reference: RFC 8531
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标准”，IEEE标准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.，“IETF XML注册表”，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.，Ed.“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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（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.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<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传输配置文件（MPLS-TP）标识符”，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]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年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.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<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，“网络配置访问控制模型”，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.，“用于接口管理的YANG数据模型”，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.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<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.17311913。
[MEF-17] MEF Forum, "Service OAM Requirements & Framework - Phase 1", MEF 17, April 2007.
[MEF-17]MEF论坛，“服务OAM需求和框架-第一阶段”，MEF 17，2007年4月。
[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数据模型”，正在进行的工作，草稿-Zhang-MPLS-TP-YANG-OAM-052017年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.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<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，Ed.，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，DOI 10.17487/RFC63711911年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.，和R.Watve，“大量链路透明互连（TRILL）中的操作、管理和维护（OAM）要求”，RFC 6905，DOI 10.17487/RFC6905，2013年3月<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]Mizrahi，T.，Sprecher，N.，Bellagamba，E.，和Y.Weingarten，“运营、管理和维护（OAM）工具概述”，RFC 7276，DOI 10.17487/RFC72762014年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，编辑，“杨树图”，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.，Schoenwaeld，J.，Shafer，P.，Watsen，K.，和R.Wilton，“网络管理数据存储体系结构（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）协议管理的通用数据模型”，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]魏国，H.，益州，L.，库马尔，D.，杜拉尼，M.，翟，H.，和夏立军，“TRILL-YANG数据模型”，正在进行的工作，草案-ietf-TRILL-YANG-042015年12月。
[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操作、管理和维护（OAM）的YANG数据模型”，在建工程，草案-ietf-TRILL-YANG-OAM-05，2017年3月。
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提出了开发YANG数据模型作为创建统一OAM API集（接口）的方法的想法；本文件的主要灵感来源于此。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.
卡洛斯·皮格纳塔罗、大卫·鲍尔、马赫什·杰塔南达尼、贝诺伊特·克莱斯、拉迪斯拉夫·洛特卡、延斯·古巴拉、尤吉·托乔、格雷戈里·米尔斯基、胡布·范·赫尔沃特、汤姆·泰勒、刘大鹏、米沙尔·韦克斯勒和阿迪·莫尔科参与了本文件的编制。
Contributors
贡献者
Tissa Senevirathne Consultant
Tissa Senevirathne顾问公司
Email: tsenevir@gmail.com
Email: tsenevir@gmail.com
Norman Finn CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America
美国加利福尼亚州米尔皮塔斯麦卡锡大道510号诺曼·芬恩思科系统公司，邮编95035
Email: nfinn@cisco.com
Email: nfinn@cisco.com
Samer Salam CISCO Systems 595 Burrard St. Suite 2123 Vancouver, BC V7X 1J1 Canada
Samer Salam CISCO Systems 595 Burrard St.2123套房加拿大不列颠哥伦比亚省温哥华V7X 1J1
Email: ssalam@cisco.com
Email: ssalam@cisco.com
Authors' Addresses
作者地址
Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America
美国加利福尼亚州米尔皮塔斯麦卡锡大道510号迪帕克·库马尔思科系统公司，邮编95035
Email: dekumar@cisco.com
Email: dekumar@cisco.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
Email: bill.wu@huawei.com
Email: bill.wu@huawei.com
Michael Wang Huawei Technologies, Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China
中国南京雨花区软件大道101号麦可王华为技术有限公司210012
Email: wangzitao@huawei.com
Email: wangzitao@huawei.com