2.9 协议
在深入了解不同协议之前，表2-1提供了数据模型驱动管理中最常用的协议的比较：NETCONF、RESTCONF和gNMI。
表2-1 NETCONF/RESTCONF/gNMI协议快速比较
2.9.1 NETCONF
NETCONF协议解决了“2002年IAB网络管理研讨会概述”（RFC 3535）期间提出的许多问题。下面是其中的几个例子：
- 事务：NETCONF提供了一种事务机制，确保配置正确且完全应用。
- 转储和还原：NETCONF提供了保存和恢复配置数据的能力。也可执行于特定的YANG模块。
- 配置处理：NETCONF提供了区分分发配置数据和激活配置数据的能力。
NETCONF提供了一种事务机制，与SNMP等协议相比这是一个主要优势。事务的特征是“ACID测试”（来自数据库的专业词汇）：
- 原子性：要么全有，要么全无。要么生效整个变更，要么丢弃。这是错误处理的一个主要优势。
- 一致性：一次完成。数据必须对YANG规则有效。事务中没有时间的概念，没有“之前”和“之后”。没有“先是这个，然后是那个”。这有益于简单性。
- 独立：没有串扰。多个客户端可以同时进行配置更改，而不会使事务相互干扰。
- 持久性：执行后即使出现断电或软件崩溃事务也会保持不变。换句话说，“当它完成了，它就完成了”。
RFC6241“网络配置协议”（NETCONF）定义NETCONF协议的方式如下：
RFC 6241 NETCONF定义
“NETCONF定义了一种基于XML的远程过程调用（RPC）机制，该机制利用了高质量XML分析器的简单性和可用性。XML为数据提供了丰富、灵活、分层的标准表示形式以满足网络设备的要求。NETCONF通过面向连接的传输，使用XML编码的RPC携带配置数据和操作作为请求和响应。”
XML的分层数据表示允许以自然的方式呈现复杂的网络数据。示例2-2将网络接口置于OSPF路由协议区域中。<ospf>元素包含<area>元素列表，每个元素都包含<interface>元素列表。<name>元素标识特定区域或接口。每个区域或接口的其他配置直接出现在相应的元素内。
示例2-2 OSPF区域NETCONF配置
NETCONF包括控制配置数据存储的机制。每个数据存储是一个特定的配置数据集合，用作配置相关操作的源或目标。设备指示它是否具有不同的“启动”配置数据存储；当前或“运行”数据存储是否可直接写入；以及是否有一个“候选”配置数据存储，其中可以进行配置更改，调用“commit-configuration”操作之前这些更改不会影响设备操作。
NETCONF协议提供了一小组低级别操作，这些操作作为rpc从客户端（应用程序）调用到服务器（在设备上运行），以管理设备配置和检索设备状态信息。基本协议提供检索、配置、复制和删除配置数据存储的操作。表2-2列出了这些操作。
表2-2 NETCONF操作
NETCONF的“功能”机制允许设备通告所支持的一组功能，包括协议操作、数据存储、数据模型和其他功能，如表2-3所示。这些是在会话建立过程中作为<hello>消息的一部分宣布的。客户端可以检查hello消息，以确定设备的能力以及如何与设备交互来执行所需的任务。与SNMP等协议相比，这是一个真正的优势。此外，NETCONF还获取状态数据，接收通知，以及调用作为某个功能一部分的额外RPC方法。
表2-3 可选NETCONF能力
此能力集通过:rollback-on-error、:candidate、:confirmed-commit和:validate等能力，有效地提供强大的全网范围配置。这里使用ACID概念，你可以将网络视为分布式数据库。当一个更改试图影响多个设备时，这些功能会极大地简化故障场景的管理，从而导致事务能力原子性上的成功或失败。这种全网范围的事务机制在数据库世界中称为三阶段式事务（PREPARE、COMMIT和CONFIRM）。
NETCONF还定义了从服务器向客户端发送异步通知的方法，如RFC 5277中所述。
在安全性方面，NETCONF在由SecureShell（SSH）或可选HTTP/TLS（传输层安全）保护的传输协议上运行，允许使用可信技术进行安全通信和身份验证。
2.9.2 RESTCONF
就像NETCONF定义了配置数据存储和一组用于访问这些数据存储的创建、读取、更新、删除、执行（CRUDX）操作一样，RESTCONF规定了HTTP方法以提供相同的操作。与NETCONF一样，RESTCONF用于访问YANG中定义的数据编程接口。
那么，IETF为什么指定另一个类似于NETCONF的协议呢？在第1章中了解到自动化与工具链一样好。在此你将理解一个关键信息：在数据模型驱动管理中，重要的是从中推导出API的YANG数据模块集。由于运营工程师正在开发基于HTTP的工具，使用同样基于HTTP的工具链来规范数据模型驱动的管理协议是很自然的。
RFC 8040 RESTCONF：一种新协议，作为NETCONF功能的子集
“RESTCONF无须照搬NETCONF协议的全部功能，但它需要与NETCONF兼容。RESTCONF通过实现NETCONF协议提供的交互功能子集来实现这一点，例如，清除数据存储和显式锁定。
RESTCONF使用HTTP方法实现与NETCONF同样的操作，在资源的概念层次结构上提供基本的CRUD操作。
HTTP方法POST、PUT、PATCH和DELETE用于编辑由YANG数据模型表示的数据资源。这些基本编辑操作允许RESTCONF客户端更改运行中的配置。
RESTCONF无意取代NETCONF，而是提供一个HTTP接口，该接口遵循代表性状态传输（REST）原则（REST-Dissertation）[22]，并与NETCONF数据存储模型兼容。”
以下是RESTCONF规范（RFC 8040），以便你了解NETCONF和RESTCONF之间的关系。
注意，第4章提供了NETCONF和RESTCONF的技术比较。与NETCONF相比，RESTCONF添加了一种新的编码可能，因为它支持XML或JSON。使用RESTCONF，服务器报告每一个YANG模块和任何偏差，并支持使用在YANG模块库（RFC 7895）和全新的YANG库（RFC 8525）中定义的ietf-yang-library YANG模块，废弃了以前版本RESTCONF协议不包含组成事务的多个调用的概念。每个RESTCONF调用本身都是一个事务，因为它使用HTTP方法POST、PUT、PATCH和DELETE编辑由YANG数据模型表示的数据资源。RESTCONF没有任何验证的方法，也没有激活配置。但是，验证是隐式的，事务的成功或失败是RESTCONF调用的一部分。
考虑到NETCONF的功能，自然的服务自动化流程是NETCONF<lock>操作（在运行和候选数据存储上），编辑候选配置数据存储中的配置，验证配置，承诺将候选数据存储中的配置应用于运行数据存储，最后是解锁操作。这些操作是在多个设备上同时从编排器完成的，以实现全网范围的事务。RESTCONF不提供锁定、候选配置或提交操作的概念；配置更改立即被应用。RESTCONF不支持三阶段事务（PREPARE、COMMIT和CONFIRM）。但是它支持两阶段事务（PREPARE和COMMIT），且只对单个REST调用的给定数据有效。
因此，RESTCONF不支持全网范围的事务，只支持逐个设备的配置。故而，RESTCONF适合用于门户和编排器之间（因为只有一个），但不适合从编排器到拥有很多设备的网络。
如果你是Web开发人员，认为“只要”选择RESTCONF，而不是NETCONF作为协议就可以了，这想得过于简单了。要记住工具的重要性。一般自动化，特别是网络配置，意味着整个工具链的集成。如果现有的工具链（例如，存储和计算）以HTTP为中心，RESTCONF可能是最好的选项。归根结底，这一切都与无缝整合和降低成本有关。
了解使用RESTCONF进行设备配置的缺点非常重要，这样你就知道选择RESTCONF的原因仅仅是RESTCONF使用HTML。作为建议，当有选择权时（也就是说，不受工具链的约束），请使用NETCONF进行网元配置。RESTCONF用于编排器或/和控制器的北向接口也有可能不错。
2.9.3 gNMI（gRPC）
gRPC网络管理接口（gNMI）协议来自OpenConfig联盟[20]，这是一个由谷歌领导的网络运营商团体，其目的为：“OpenConfig是一个非正式的网络运营商工作组，其共同目标是通过采用软件定义网络原则，如声明性配置和模型驱动的管理和操作，使网络朝着更富动态、基础设施可编程的方向发展。”
OpenConfig最初的重点是基于用例的实际操作要求和来自多个网络运营商的要求，编译一组一致的、与供应商无关的、用YANG编写的数据模型。在OpenConfig继续改进YANG模块集的同时，Google利用开源gRPC[23]框架开发了gNMI，作为一个统一的流式遥测和配置管理协议。
gNMI和gRPC有时会混淆，因此本节才使用这两个名称。澄清如下，gNMI是管理协议，gRPC是底层RPC框架。
gNMI编码之一是protobuf，前面讨论过。protobuf的优点是更紧凑，但它们也提供了更复杂的操作部署。对于NETCONF和RESTCONF，只有YANG模式才需要解析有效载荷。对于带有protobuf传输的gRPC上的gNMI，还需要分发.proto文件。这在设备升级时会增加复杂性。
2.9.4 CoMI
CoAP管理接口（CoMI）协议扩展了一组基于YANG的协议（NETCONF /RESTCONF/gNMI），用于管理受限设备和网络。
受限应用协议（CoAP；RFC 7252）是为机器对机器（M2M）应用而设计的，用于（诸如智慧能源、智慧城市和楼宇控制等）低功耗、易丢包的受限节点和受限网络。物联网节点通常使用8位微控制器，带有少量ROM和RAM，而低功耗无线个人区域网络（6LoWPAN）上的IPv6等受限网络通常具有较高的数据包错误率和数十Kbps的典型吞吐量。
这些受限设备必须以自动化方式进行管理，以处理在未来安装中预期的大量设备。设备之间的消息须尽可能小且不频繁。实现时的复杂性和运行时间资源也要尽可能小。
CoMI为受限设备和网络规范了网络管理接口，其中CoAP用于访问YANG中指定的数据存储和数据节点资源。CoMI使用YANG-to-CBOR映射[24]，并将YANG标识符字符串转换为数字标识符以减小有效载荷。在协议栈方面，CoMI运行在CoAP上，CoAP运行在用户数据报协议（UDP）上，NETCONF/RESTCONF/gNMI运行在传输控制协议（TCP）上。
在撰写本文时，CoMI正处于IETF标准化的最后阶段。