前言
前传接口（FrontHual）是传统的BBU与RU之间的接口，在O-RAN之前，前传接口虽然定义了物理连接的CPRI接口规范标准，但CPRI之上承载的M plane的配置管理数据格式，却是设备厂家私有的。
有基于TCP的、有基于UDP的，有基于http协议的，自定义格式的，总之，不同的厂家，没有统一的标准。
O-RAN的一个重要的目标就是把这个私有接口开放化、标准化。
这就需要有这样一个标准的网络配置管理协议，能够满足下面的几个重要的需求：
（1）定义网络设备的配置和管理数据的承载和传送，如TCP, UDP, HTTP, SSL, SSH
（2）定义网络设备的配置和管理数据的流程控制和操作，如get，set，notify操作。
（3）定义网络设备的配置和管理数据的数据格式与模型，即管理数据的数据结构，数据的数据必须支持动态编程，而不能是静态的、不可伸缩的。
SNMP是传统的网络管理协议，但这样的协议，不太适合现代软件定义网络网络需求，不符合动态可伸缩性的要求，无法承担如此重任。
在O-RAN中，采用了netconf协议+Yang数据建模语言共同承担上述的三个职责。
其中netconf承担了上述（1）和（2）职责；Yang承担了（3）的职责。
文本先介绍netconf协议，后文再介绍Yang数据建模语言。
目录：
前言
第一章 NETCONF概述与协议架构
1.1 NETCONF概述
1.2 NETCONF协议架构
第二章 安全传输子层
第三章 消息子层
3.1 hello消息
3.2 rpc请求与rpc-reply应答消息
3.3 notification通知消息
第四章 操作子层
4.1 get
4.2 get-config
4.3 edit-config
4.4 copy-config
4.5 delete-config
4.6 lock
4.7 unlock
4.8 close-session
4.9 kill-session
第五章 内容子层
第一章 NETCONF概述与协议架构
1.1 NETCONF概述
NETCONF = The Network Configuration Protocol
NETCONF是由IETF在2003年5月成立了Netconf工作组，提出一个全新的基于XML的网络配置（NETCONF）协议。
NETCONF协议是完全基于XML 之上的，所有的配置数据和协议消息都用XML 表示。
XML可以表达复杂的、具有内在逻辑关系的、模型化的管理对象，而且由于它是W3C（互联网联盟）提出的国际标准，因而受到广大软件提供商的支持，易于进行数据交流和开发。
1.2 NETCONF协议架构
（1）NetConf采用的是Client Server机制，被管理的网络设备是NetConf的server，网络程序是Client。
（2）NetConf协议承载在TCP/IP协议之上，包括4个子层协议。
-
安全传输子层：定义用于承载或传输配置、管理数据的网络传输层协议，如SSH, TLS, HTTP...
-
消息子层：定义配置、管理数据的消息类型, 如RPC（相当于request），RPC reply，notification。
-
操作子层：定义消息的配置、管理数据的操作类型，如get，set操作。
-
配置管理数据子层：定义配置管理数据的格式和内容和数据结构，支持Yang语言数据建模语言。
其中安全传输层，消息层，操作层这3层是通过XML文本格式来描述的。
而安全传输子层是借用了已有的各种互联网传输协议协议。
第二章 安全传输子层
NETCONF的第一大优势就是其从协议层面就已经规定其传输层必须使用带有安全加密的通信协议，
且借用已有的各种互联网传输协议协议，以及支持其他未来可能会出现的新的传输层协议。如SSH, TLS, SOAP/Http/TLS等。
相比与其它允许明文传输的协议来说其在协议层面就已经对数据安全做了第一道守护。
由于是借用的已有协议，在这里不对它们进行进一步的探讨。
第三章 消息子层
NETCONF协议，真正的新标准的部分，是从消息子层开始，并通过XML文本格式的明文进行承载。
NETCONF中定义了三种消息类型，分别是hello， rpc和rpc-reply, notification。
3.1 hello消息
<hello>仅用于时netconf-server和netconf-client之间进行交换双方的管理XML中数据的能力。
一般来说，C/S双方互发<hello>消息且协商版本成功后，认为netconf会话建立成功。
常用的几种数据管理的能力有：
(1) XPath Capability
XPath为XML路径语言（XML Path Language），它是一种用来定位XML文档中数据位置的语言
该能力表示client是否可以在filter中使用XPath表达式作为过滤条件，来标识一个或一组XML中的数据。
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
3.2 rpc请求与rpc-reply应答消息
（1）<rpc>
是由netconf-client发起的，发送到netconf-server的消息。用于client请求server执行某项具体的操作。
<rpc>包含一个强制属性”message-id”，这个id是一个单调递增的正整数，同一会话内不能重复。
该id用于<rpc>和<rpc-reply>的配对。
（2）<rpc-reply>
是有netconf-server发送给netconf-client的rpc响应。
不能主动发起，仅能在收到<rpc>之后回复，切必须携带与收到的rpc相同的message-id。
在<rpc-reply>定义了两种默认的元素分别是<ok>和<rpc-error>。
<ok>表示未定义响应内容的rpc执行成功，
而<rpc-error>表示rpc执行失败。
3.3 notification通知消息
用于netconf-server向netconf-client主动单方向上报消息。
（1）Netconf的通知采用的是订阅发布机制，server仅会向发送过订阅请求的client发送通知。
（2）Netconf的通知是以Stream进行分类的，不同类的Stream以不同的stream-name进行区分。netconf-server默认需要支持的stream-name是”NETCONF”。
第四章 操作子层
操作子层定义消息的配置、管理数据的操作类型。
因此，操作层仅针对<rpc>和<rpc-reply>消息上，<hello>和<notification>消息无操作层。
NETCONF协议规定了9种简单的rpc操作，同时也支持用户自定义rpc操作。
（1）<get>：查询状态数据
（2）<get-config>：查询配置数据
（3）<edit-config>：修改配置数据
数据对象的的子操作有：
merge: 合并操作，此操作为默认操作。
replace: 替换操作，如果对象已经存在则替换，不存在则创建。
create: 创建操作，如果对象已经存在，则报错误“data-exists”。
delete: 删除操作，如果对象存在则删除，不存在则报错 “data-missing”。
remove: 删除操作，如果对象存在则删除，不存在则忽略。
（4）<copy-config>：copy配置数据
（5）<delete-config>：删除配置数据
（6）<lock>：锁定数据库，在修改、删除数据库时，必须先锁定数据库
（7）<unlock>：解锁定数据库。
（8）<close-session>：正常关闭一个会话
（9）<kill-session>：强行关闭一个会话
4.1 get
用于查询状态数据。
例如，要获取server支持的能力：urn:ietf:params:netconf:capability:xpath:1.0，则还可以使用filter进行条件查询
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get><filter type="subtree"><topxmlns="http://example.com/schema/1.2/stats"><interfaces><interface><ifName>eth0</ifName></interface></interfaces></top></filter></get>
</rpc><rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data><top xmlns="http://example.com/schema/1.2/stats"><interfaces><interface><ifName>eth0</ifName><ifInOctets>45621</ifInOctets><ifOutOctets>774344</ifOutOctets></interface></interfaces></top></data>
</rpc-reply>4.2 get-config
用于查询配置数据，可以通过 <source/>来指定不同的配置数据库。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/></source><filter type="subtree"><top xmlns="http://example.com/schema/1.2/config"><users/></top></filter></get-config>
</rpc>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><data><top xmlns="http://example.com/schema/1.2/config"><users><user><name>root</name><type>superuser</type><full-name>Charlie Root</full-name><company-info><dept>1</dept><id>1</id></company-info></user><!-- additional <user> elements appear here... --></users></top></data>
</rpc-reply>4.3 edit-config
用于对指定配置数据库的内容进行修改，支持以下几种子操作：
merge: 合并操作，此操作为默认操作。
replace: 替换操作，如果对象已经存在则替换，不存在则创建。
create: 创建操作，如果对象已经存在，则报错误“data-exists”。
delete: 删除操作，如果对象存在则删除，不存在则报错 “data-missing”。
remove: 删除操作，如果对象存在则删除，不存在则忽略。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><edit-config><target><running/></target><configxmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"><topxmlns="http://example.com/schema/1.2/config"><interface xc:operation="replace"><name>Ethernet0/0</name><mtu>1500</mtu><address><name>192.0.2.4</name><prefix-length>24</prefix-length></address></interface></top></config></edit-config>
</rpc>
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><edit-config><target><running/></target><default-operation>none</default-operation><configxmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"><topxmlns="http://example.com/schema/1.2/config"><protocols><ospf><area><name>0.0.0.0</name><interfaces><interface xc:operation="delete"><name>192.0.2.4</name></interface></interfaces></area></ospf></protocols></top></config></edit-config>
</rpc>4.4 copy-config
将一个库的数据复制到另一个库。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><copy-config><target><running/></target><source><url>https://user:password@example.com/cfg/new.txt</url></source></copy-config>
</rpc>4.5 delete-config
删除一个数据库。但是<running/>库不能被删除。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><delete-config><target><startup/></target></delete-config>
</rpc>4.6 lock
获取指定数据库的锁，当某个client获得了指定数据库的锁之后，在其没有释放该锁之前，其余client均不能获得该数据库的锁，也不能对其进行修改操作。同一client也不能在没有释放锁之前，重复申请锁。
获取锁的主要目的就是避免并发导致数据冲突。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><lock><target><running/></target></lock>
</rpc>4.7 unlock
释放指定数据库的锁。client只能释放自己持有的锁，不能释放其它client的锁。
代码案例：
<rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><unlock><target><running/></target></unlock>
</rpc>4.8 close-session
优雅关闭netconf会话，netconf-server将释放该client持有的锁和为其分配的资源，并优雅的关闭与该client链接。所有在<close-session>之后收到的操作均会被忽略。
4.9 kill-session
强制关闭netconf会话。
第五章 内容子层
开放性、标准化的配置、管理数据是整个netconf协议的精髓所在。
放体性：体现在netconf协议本身不对内容层的配置和管理数据的数据结构做任何的预先、固定化的限定和规定。
标准化：体现在对内容层的配置、管理数据的格式和数据结构的定义能够进行某种约束，不能以任意的形式存在，否则就无法实现不同节点之间进行互联互通。
Yang语言是数据进行建模的一种语言，NetConf使用Yang语言对内容子层的数据进行约束和建模。
在netconf出现之前，我们所熟知且常用的协议，均采用在协议中固定的报文的结构体，并按字节流读取并解析的架构。
为了更好的在字节流中表达更丰富的报文结构，我们采用TLV等方式来定义对象。但这种方式几乎虽然具备了一定的扩展伸缩性，不具备任何扩展性，一旦扩充新的对象，或修改对象，就需要变更代码。而如果对一个协议扩展了大量的私有数据，那么首先协议不在标准，其次协议栈的代码几乎是完全重写。
而netconf的出现可以说直接对上述问题进行了一次”降维“打击，它完全站在了一个更高的维度来解决上述问题。
其内容层未指定具体的模型结构，而是指定了一套建模语言–yang。也就是说使用yang定义的数据模型，均可以作为netconf的内容层。所以对netconf而言，“扩展”就是不断的增加和修改Yang语言的配置文件而已。而这个配置文件是文本文件，不需要重新编译目标代码，就可以执行的配置、管理数据。
Yang本身是独立于NetConf的数据建模语言，NetConf只是借用该数据建模语言，并提供对其的支持。
关于Yang建模语言，下文将单独探讨。
