最近在做TSN设备相关的项目，项目中使用了Netconfig协议进行设备管理和配置。以前没接触过，在网上找了很多资料学习，做个笔记记录一下。
NETCONFIG简介
NETCONF（NetworkConfigurationProtocol，网络配置协议）是一种基于XML的网络管理协议，它提供了一种可编程的、对网络设备进行配置和管理的方法。它使用简单的基于RPC（RemoteProcedureCall）机制实现客户端和服务器之间通信。客户端可以是脚本或者网管上运行的一个应用程序。服务器是一个典型的网络设备。
NETCONF报文使用XML格式，具有强大的过滤能力，而且每一个数据项都有一个固定的元素名称和位置，所以具有很强的兼容性，不同厂家不同设备可以通过XML得到相同的结果，便于混合不同厂商不同设备的为冷热软件开发。
NETCONF的优点
NETCONF协议以XML格式定义消息，运用RPC机制修改配置信息，这样既能方便管理配置信息，又能满足来自不同制造商设备之间的互操作性。
减少由于人工配置错误引起的网络故障。
提高使用配置工具升级系统软件的效率。
扩展性好，不同制造商设备可以定义自己的协议操作，以实现独特的管理功能。
NETCONF提供了认证、鉴权等安全机制，保证了消息传递的安全。
NETCONFIG与SNMP比较
NETCONFIG协议结构
NETCONF协议采用了分层结构。每层分别对协议的某一方面进行包装，并向上层提供相关服务。分层结构使每层只
NETCONF的第一大优势就是其从协议层面就已经规定其传输层必须使用带有安全加密的通信协议。由于NETCONF协议规定必须要支持SSH，所以目前SSH是NETCONF使用最广泛的传输层协议。NETCONF的协议内容是承载在安全传输层之上的，所以NETCONF本身是一个应用层协议。
消息层
NETCONF中定义了三种消息类型，分别是hello，rpc和rpc-reply,notification。
hello
hello仅用于回话刚刚建立时netconf-server和netconf-client之间进行能力交换。server和client需要在回话建立后互相发送hello消息，并在hello消息中携带自身支持的能力，以及支持的netconf协议的版本号，server和client根据自身和对方的能力信息协商使用的netconf版本。一般来说，C/S双方互发hello且协商版本成功后，认为netconf会话建立成功。
几种常用的能力
(1)XPathCapability
该能力表示client可以在filter中使用XPath表达式作为过滤条件
CapabilityIdentifier:
urn:ietf:params:netconf:capability:xpath:1.0(2)Writable-RunningCapability
该能力表示server支持直接对running/库进行修改操作。
CapabilityIdentifier:
urn:ietf:params:netconf:capability:writable-running:1.0(3)CandidateConfigurationCapability
该能力表示server具有一个candidate数据库，并且可以将candidate数据库中的配置提交生效并更新running数据库
CapabilityIdentifier:
urn:ietf:params:netconf:capability:candidate:1.0(４)Rollback-on-ErrorCapability
该能力表示server在执行client发送的配置数据出错后可以进行回滚
CapabilityIdentifier:
urn:ietf:params:netconf:capability:rollback-on-error:1.0(５)ValidateCapability
该能力表示server可以校验client发送的配置数据是否正确
CapabilityIdentifier:
urn:ietf:params:netconf:capability:validate:1.1(６)DistinctstartupCapability
该能力表示server有一个startup数据库，用于保存启动配置
CapabilityIdentifier:
urn:ietf:params:netconf:capability:startup:1.0
rpc和rpc-reply
rpc是由netconf-client发起的发送到netconf-server的消息。用于client请求server执行某项具体的操作。rpc包含一个强制属性”message-id”，这个id是一个单调递增的正整数，同一会话内不能重复。该id用于rpc和rpc-reply的配对。rpc-reply是有netconf-server发送给netconf-client的rpc响应。不能主动发起，仅能在收到rpc之后回复，切必须携带与收到的rpc相同的message-id。在rpc-reply定义了两种默认的元素分别是ok和rpc-error。ok表示未定义响应内容的rpc执行成功，而rpc-error表示rpc执行失败。
关于RPC最重要的几点：
1.netconf-client必须保证server收到的rpc请求的顺序和message-id的顺序是一致的。
2.netconf-server在能保证数据不冲突的前提下可以并行处理收到的rpc请求。
3.netconf-server在发送rpc-reply时必须严格按照收到的rpc的顺序。
notification
支持Notification上报的netconfigserver需在能力交换时上报能力：“urn:ietf:params:netconf:capability:notification:1.0”。几个关键的知识点：
1.Netconf的通知采用的是订阅发布机制，server仅会向发送过订阅请求的client发送通知。
2.Netconf的通知是以Stream进行分类的，不同类的Stream以不同的stream-name进行区分。netconf-server默认需要支持的stream-name是”NETCONF”。
3.client不能重复下发订阅，即同一Stream的订阅不能重复下发，也不能同时订阅多个Stream，订阅可以设置定时取消，如果没有设置终止时间，取消订阅需要使用close-session或者kill-session。定时取消的订阅netconf的会话还是激活的，而使用close-session或者kill-session来取消的话，netconf会话会关闭。
操作层
操作层仅承载在rpc和rpc-reply消息上，hello和notification消息无操作层。 NETCONF协议规定了9种简单的rpc操作，同时也支持用户自定义rpc操作。
1、get
查询的是设备当前运行的状态数据，即只能从配置数据库中获取数据。所以，不需要使用source参数指定配置数据库。如果server支持能力：urn:ietf:params:netconf:capability:xpath:1.0则还可以使用filter进行条件查询。
rpcmessage-id=""xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"getfiltertype="subtree"topxmlns="