NETCONF协议详解

目录

　　随着SDN的大热，一个诞生了十年之久的协议焕发了第二春，它就是NETCONF协议。如果你在两年前去搜索NETCONF协议，基本得到的信息都是“这个协议是一个网管协议，主要目的是弥补SNMP协议的不足，希望可以取代SNMP协议”。SNMP有哪些不足，而NETCONF是否真的能够弥补，这都不是重点，重点是NETCONF诞生至今SNMP依旧活的好好的。所以如果我们还是把NETCONF当做一个网管协议的话，估计它会在冷板凳上一直坐下去，而如果我们换一个角度去看待NETCONF协议，你会发现也许它是最适合SDN的一个协议。

0. 概述

　　NETCONF = The Network Configuration Protocol
　　SDN = Software Define Network
　　从文字含义上就觉得NETCONF和SDN可以在一起搞事情，搞什么事情？ 搞Network啊。
　　SDN要用软件去定义网络，如何定义？简单就是要用软件去配置网络，有人说”配置网络太空泛了，能不能具体点？”，但我真的没法说的具体，因为网络能配置的东西太多了，网络的设备类型多种多样，业务类型更是成百上千了，但SDN就是想在这么复杂的网络上开辟一番新的天地，NETCONF可以说是其不二的选择。
　　接下来就对NETCONF1.1(RFC6241)版本进行详细分析。

1. NETCONF1.1协议详解

　　NETCONF采用的是C/S的模式：

　　从上图中可以看出NETCONF协议内部分为4层，由下至上分别是安全传输层，消息层，操作层和内容层。
　　在详细介绍这四层之前，需要提前建立一个概念，NETCONF认为网络的模型数据可以分为两大类，即状态数据和配置数据。状态数据一般指server（设备）的固有属性数据和当前运行的状态数据等，这类数据仅能查询。而配置数据则是指由用户（以某种方式）配置到server上的数据。而配置数据本身又可以存在多个数据库，标准中提到了<running/>库用于保存当前已经生效的配置；<candidate/>用于保存可以提交为生效的数据；以及<startup/>用于保存启动时的配置数据。

1.1. 安全传输层

　　NETCONF的第一大优势就是其从协议层面就已经规定其传输层必须使用带有安全加密的通信协议，例如SSH，TLS等。相比与其它也允许明文传输的协议来说其在协议层面就已经对数据安全做了第一道守护。由于NETCONF协议规定必须要支持SSH，所以目前SSH是NETCONF使用最广泛的传输层协议。
　　NETCONF的协议内容是承载在安全传输层之上的，所以NETCONF本身是一个应用层协议，所以NETCONF协议中并没有规定建链和保活相关的内容。

1.2. 消息层

　　NETCONF中定义了三种消息类型，分别是hello， rpc和rpc-reply, notification。

1.2.1. <hello>

　　<hello>仅用于回话刚刚建立时netconf-server和netconf-client之间进行能力交换。
　　server和client需要在回话建立后互相发送<hello>消息，并在<hello>消息中携带自身支持的能力，以及支持的netconf协议的版本号，server和client根据自身和对方的能力信息协商使用的netconf版本。
　　一般来说，C/S双方互发<hello>且协商版本成功后，认为netconf会话建立成功。

1.2.1.1. 几种常用的能力

(1) XPath Capability
　　该能力表示client可以在filter中使用XPath表达式作为过滤条件
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:xpath:1.0
(2) Writable-Running Capability
　　该能力表示server支持直接对<running/>库进行修改操作。
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:writable-running:1.0
(3) Candidate Configuration Capability
　　该能力表示server具有一个candidate数据库，并且可以将candidate数据库中的配置提交生效并更新running数据库
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:candidate:1.0
(４) Rollback-on-Error Capability
　　该能力表示server在执行client发送的配置数据出错后可以进行回滚
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:rollback-on-error:1.0
(５) Validate Capability
　　该能力表示server可以校验client发送的配置数据是否正确
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:validate:1.1
(６) Distinct startup Capability
　　该能力表示server有一个startup数据库，用于保存启动配置
　　Capability Identifier:
　　urn:ietf:params:netconf:capability:startup:1.0

1.2.2. <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最重要的一点： 原文如下：
　　NETCONF<rpc>requests MUST be processed serially by the managed device. Additional<rpc>requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.
　　个人对这段话的理解是这样的：
　　1. netconf-client必须保证server收到的rpc请求的顺序和message-id的顺序是一致的。
　　2. netconf-server在能保证数据不冲突的前提下可以并行处理收到的rpc请求。
　　3. netconf-server在发送<rpc-reply>时必须严格按照收到的<rpc>的顺序。

1.2.3. <notification>

　　在netconf的1.0版本中还没有加入Notification相关的内容，而在1.1版本已经将RFC5277(NETCONF Event Notifications)囊落在内了。支持Notification上报的netconf-server需在能力交换时上报能力：
　　“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会话会关闭。
　　Stream发现：
例如：

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter type="subtree">
            <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
                <streams/>
            </netconf