LUOPING0 2019-11-07
i. 安全传输层,用于跟交换机安全通信,NETCONF并未规定具体使用哪种传输层协议,所以可以使用SSH、TLS、HTTP等各种协议,官方默认使用<strong>SSH</strong>
进行加密及数据传输
ii.消息层,提供一种传输无关的消息封装格式,用于RPC通信,消息层流程如下:
NETCONF中定义了三种消息类型,分别是hello, rpc和rpc-reply, notification。
Ø <hello>
<hello>仅用于回话刚刚建立时netconf-server和netconf-client之间进行能力交换。
server和client需要在回话建立后互相发送<hello>消息,并在<hello>消息中携带自身支持的能力,以及支持的netconf协议的版本号,server和client根据自身和对方的能力信息协商使用的netconf版本。
一般来说,C/S双方互发<hello>且协商版本成功后,认为netconf会话建立成功。操作层,定义了一系列的RPC调用方法,并可以通过Capabilities来扩展
几种常用能力:
(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
(4) Rollback-on-Error Capability
该能力表示server在执行client发送的配置数据出错后可以进行回滚
Capability Identifier:
urn:ietf:params:netconf:capability:rollback-on-error:1.0
(5) Validate Capability
该能力表示server可以校验client发送的配置数据是否正确
Capability Identifier:
urn:ietf:params:netconf:capability:validate:1.1
(6) Distinct startup Capability
该能力表示server有一个startup数据库,用于保存启动配置
Capability Identifier:
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执行失败。
Ø notification
持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会话会关闭。
iii.操作层,NETCONF提供了九种基本操作:
Ø get-config 用于查询配置数据
Ø edit-config 用于对指定配置数据库的内容进行修改,支持以下几种操作:
merge: 合并操作,此操作为默认操作。
replace: 替换操作,如果对象已经存在则替换,不存在则创建。
create: 创建操作,如果对象已经存在,则报错误“data-exists”。
delete: 删除操作,如果对象存在则删除,不存在则报错 “data-missing”。
remove: 删除操作,如果对象存在则删除,不存在则忽略。
Ø copy-config 将一个库的数据复制到另一个库
Ø delete-config 删除一个数据库。但是<running/>库不能被删除。
Ø lock 获取指定数据库的锁,当某个client获得了指定数据库的锁之后,在其没有释放该锁之前,其余client均不能获得该数据库的锁,也不能对其进行修改操作。同一client也不能在没有释放锁之前,重复申请锁。 获取锁的主要目的就是避免并发导致数据冲突。
Ø unlock释放指定数据库的锁。client只能释放自己持有的锁,不能释放其它client的锁。
Ø get 用于查询状态数据
Ø close-session 优雅关闭netconf会话,netconf-server将释放该client持有的锁和为其分配的资源,并优雅的关闭与该client链接。
Ø kill-session 强制关闭netconf会话。
get-config请求报文解析流程B
iv.内容层,定义RPC调用的数据内容,即配置数据库
NETCONF实现流程:
<rpc>元素用于封装从客户端发送到服务器的NETCONF请求。
<rpc>元素有一个强制属性“message-id”,它是由RPC的发送者选择的一个字符串,它通常编码一个单调递增的整数。 RPC的接收者不解码或解释这个字符串,只是简单地保存它在任何生成的<rpc-reply>消息中用作“message-id”属性。
<rpc-reply>响应<rpc>操作发送<rpc-reply>消息。
<rpc-reply>元素有一个强制属性“message-id”,它等于这是一个响应的<rpc>的“message-id”属性。
响应名称和响应数据被编码为<rpc-reply>元素的内容。 回复的名字是直接在<rpc-reply>元素中的一个元素,任何数据都在这个元素内编码。
如果服务器在处理<rpc>请求期间遇到多个错误,<rpc-reply>可能包含多个<rpc-error>元素。但是,如果请求包含多个错误,则服务器不需要检测或报告多个<rpc-error>元素。
服务器不需要按照特定的顺序检查特定的错误条件。如果在处理期间出现任何错误情况,服务器务必返回一个<rpc-error>元素,并且如果在处理期间出现任何警告条件,应该返回一个<rpc-error>元素。
服务器绝对不能在客户端没有足够访问权限的<rpc-error>元素中返回应用级或数据模型特定的错误信息。
error-type:定义错误发生的概念层,下列类型之一。
Ø transport (layer: Secure Transport)
Ø rpc (layer: Messages)
Ø protocol (layer: Operations)
Ø application (layer: Content)
error-tag:包含识别错误条件的字符串。
error-severity:包含标识错误严重性的字符串,由设备确定。 下列之一:
Ø error
Ø warning
error-app-tag:包含标识数据模型特定或特定于实现的错误条件(如果存在)的字符串。
error-path:包含绝对XPath表达式,用于标识<rpc-error>元素中报告的错误关联的节点的元素路径。 如果没有适当的有效载荷元素或数据存储节点可以与特定的错误条件相关联,则该元素将不存在。
error-message:包含一个适合人类阅读的字符串,用于描述错误情况
error-info:包含协议或数据模型特定的错误内容。