【编者的话】本文系SDN实战团微信群（团长张宇峰@brocade）组织的线上技术分享整理而成，本文由北京邮电大学研三学生陈明明分享，分享的内容是YANG模型与OpenDaylight南北向接口。
嘉宾介绍
--------------------------------------------------------------------------
陈明明：北京邮电大学研三在读；研究方向：软件定义光网络控制平面与南向接口研究；实习经历：（1）中国信息通信研究院（前工信部电信研究院）OpenDaylight开发，完成OpenFlow v1.3协议光网络扩展、南向接口设计以及光路由功能，完成搭建实体OpenFlow交换机与OpenDaylight实验环境；（2）思科（中国）：OpenDaylight开发，扩展BGP协议labeled-unicast，完成源码并搭建实际环境测试验证；学生活动：（SDN）培训暨专家学术研讨会、SDN南京技术交流会、中国SDN/NFV大会。
分享正文
--------------------------------------------------------------------------
YANG模型是什么？
YANG模型是一种数据建模语言，用来建模由NETCONF协议、NETCONF远端过程调用（RPCs）、和NETCONF通知（notification）操作的配置数据和状态数据。
YANG建模NETCONF协议的操作和内容层（RFC4741，Section 1.1）。
YANG模型特性：
•建模XML格式数据并由控制器元素提供功能：具有自己的语法格式，可以无差地转化为XML格式，同时通过yangtools plugin可以生成相应的java接口、类及方法等，为OpenDaylight内部数据（控制器元素）处理编程提供了便利。
•定义语义元素和他们的关系，模拟所有的元素作为一个系统，YANG模型是一种树形结构的建模语言，通过YANG模型本身的语法和语义关系可以看出其定义方式的灵活性。
•YANG数据模型的XML特性提供了一种自表述数据的方式，控制器元素和采用控制器北向接口API的应用可以以一种原生格式与数据模型一起调用。
•利用一种模式语言简化控制器元素和应用的开发。模块中提供功能的开发者可以定义一个模型，从而可以创建对于所提供功能的更简单的、数据类型的API。因此降低了通过服务抽象层提供的数据结构的错误交互。
YANG模型与NETCONF
由最初YANG模型的定义可知，YANG模型与NETCONF密切相关，其产生是为了对NETCONF协议所操作的数据进行建模。最初的网络管理协议SNMP也有对应的建模语言SMI。
下图给出NETCONF/YANG与SNMP/SMI相关概念对比。
图1
如图中所示，NETCONF在很多方面体现出对于SNMP协议的优越性，NETCONF协议由XML编码，以SSH加密，采用TCP连接，体现出更好的安全性和可靠性。
下面简单引出NETCONF协议的configuration data store。
Pic
YANG模型通过树形结构的节点定义描述了数据模型的层级嵌套结构以及各属性的数据类型。YANG具有自己的语法格式，也可以无差别地转换为XML格式，称之为YIN。可以使用第三方工具pyang进行转换。pyang地址：http://www.yang-central.org/twiki/pub/Main/YangTools/pyang.1.html
接下来将会对YANG模型的语法和语义进行描述，说明在YANG中数据模型是如何定义的，并且以XML格式展示，以及NETCONF操作如何来操作数据。（https://tools.ietf.org/html/rfc6020#section-1）
YANG模型语义及语法
YANG模型主要内容
图2
正如之前所提到的，除去header information、imports&includes、Type definitions之外，YANG模型的主要内容Configuration&Operational data declarations和Action（RPC）&Notification declarations对应了YANG模型定义中的“NETCONF协议、NETCONF远端过程调用（RPCs）、和NETCONF通知（notification）”。下面将通过基本示例来介绍以上所述主要内容。
YANG HEADER
图3
上图所示是一个YANG文件的HEADER，其中module name（vxlan）要与YANG文件的文件名一致（即这个YANG文件的名字为vxlan.yang），namespace用来唯一标识这个YANG模型与其他YANG模型不同，prefix作为namespace的一种简写，其次import用来定义导入的其他YANG模型，注意到在后面的大括号中包括这个YANG模型的prefix和revision-data。revision用来唯一定义这个YANG模型的revision。其余一些organization、contact、description定义仅用于描述。YANG模型是一个XML格式定义语言。
另外，针对上图示例中没有体现的“include”来说，include是用于将sub-module引入到module里面，这个module不一定要有一个文件。Submodule没有namespace而是以belongs-to来表征属于哪一个main module.
YANG TYPES
Data Type
YANG模型的Data Type包括Base Type和Derived Type, Base Type即为一个简单的类型，Derived Type或许是typedefs定义的一个Base Type或许是grouping定义的具有结构的类型。接下来在Typedef Statement和Grouping Statement中将会进一步介绍Derived Type。
Base Type
图4
https://wiki.opendaylight.org/view/YANGTools:YANGtoJavaMapping
Typedef Statement
在Typedef中还包涵诸如“rang”、“length”的细节定义，有兴趣可查看rfc6020
图5
图中定义实现了一个“percent”类型（Derived Type），
Container Statement
作为data store有效入口的存在，可以理解为从container处以下的值才是有效的，没有值，但包含一系列的子节点
图6
Grouping Statement
定义树形结构的“暂时”树干，这么说主要是区别于container，从形式上看两者及其相似都是具有树形结构，但在运行过程中grouping是无效的数据，只有当它作为衍生类型（uses）存在于container中时才有效.
图7
Leaf Statement
leaf:用来定义属性值，如name,ID等。有值，但不包含任何子节点
List Statement
定义了一组具有相同数据结构的数据，在json格式的实例中是一个数组，在xml格式的实例中是一系列名称和结构相同的xml节点 。List中的各个元素之间通过key来唯一标识；例如nodes
图8
兼具leaf和list的特点，定义了一组相同类型的值。不包含子节点。在json格式实例中是一个数组且数组中每个元素都是一个值，在xml格式的实例中是一系列名称相同值不同的xml节点
Choice & case Statement
choice:定义的节点结构是不完全确定的。它包含多个case子节点，代表不同的分支，分别定义了该节点的一种可能的结构。最终节点的结构是且仅能是所有分支中的一种。
Augment
YANG模型允许一个module插入附加节点到data models中，包括当前的module(以及子mudule)或者一个外部module. 对于供应商来说，增加vendor-specific参数到标注的data model中可协作使用。
图9
Configuration & Operational Data Store
Data store中的数据存储分两种形式：config和operational ，config持有由应用所写的数据，而operational反映了设备的实际状态，从设备读取数据，如果没有错误即可以看到设备的当前实际信息。
config data store中查询流表通常不包含以路由为目的的流表项（这就是为什么operational方式可以查询到table-miss流表项，即out-port：controller，而config方式查询不到），但是OpenDaylight开发者表示这个方面未来可以改变，而之所以这样是因为这些流通过外部的流服务（不经过dataStore和config）发送到设备，然后这些流由设备通过数据形式以operational的形式重新报回。
config具有相对于控制器的生命周期（甚至重启都可以依然存活）。这些流表项由应用添加到这里并且当有合适的设备时就会发送给它。
原则上讲openflowplugin和controller都不应该动用config。这个是为应用程序而保留的，比如FRM监听到改变就写到config里面以发送流到设备。这个可以用来做预配置-应用程序可以为一些尚未存在的设备写一些“有用的“流，一旦设备存在相关的流就会下发到其中，而不用任何应用程序的动作。
Config 一般用来下发配置（post,put）,也可以获取信息（get）
Operational一般是获取实际设备信息（get），config data store的内容和operational data store的内容可能不同，但是不同模块之间两者的设计可能不太相同，举例说明：
对于openflow协议：operational反映设备的实际信息，假如下发配置，流程是config->device->operational
对于bgp协议：下发配置流程是：config->operational->device
在YANG模型中，只有当 “config true”存在时这段数据才是config data store的内容，否则均为operational data store，不定义则默认”config false”.
RPC
rpc：用于定义netconf的一个rpc操作。它可能包含input和output子节点，分别是该rpc操作所需要的输入和输出数据结构。若没有则表明该操作不需要输入数据或者没有输出数据。
NOTIFICAION
除了rpc，yang还有一个类似的“notification”， notification用于定义netconf的通知消息的内容，也是用来定义一个服务。两者的区别在于rpc是一对一的，即单播，而notification是多播的，当Provider提交一个notification时，所有的订阅该服务的Consumer都会收到通知，如典型的PacketIn消息，所谓的订阅即实现该notification的接口。rpc生成的接口类名后缀都是Service。nontification生成的接口类名后缀是Listener。
OpenDaylight南北向接口
针对以上讨论了这么多关于YANG模型的知识， YANG模型除却本身作为NETCONF协议的数据建模语言之外，在OpenDaylight中的应用诞生了众所周知的MD-SAL。
MD-SAL简述
对于服务抽象层的Model-driven方法体现出一种统一北向和南向API以及SDN控制器中多种服务和元素中所使用的数据结构。
为了描述控制器元素所提供的数据结构，YANG模型作为一种服务和数据抽象的建模语言就起到了作用。
MD-SAL（Model Driven Service Abstraction Layer）模型驱动服务抽象层的特别就体现在模型（即YANG模型）驱动。如前所述，YANG模型可以无差别地转换为XML格式，同时可以通过yangtools生成java代码，这就是YANG模型实现对OpenDaylight南北向接口数据建模的关键。
下面以实际示例的形式展现YANG模型定义与南北向接口的关系。
YANG模型与北向接口
图3、图6、图7所示为一个简单的北向接口示例的YANG模型截图，在完成YANG模型、java程序实现以后，启动起OpenDaylight可以在北向得到如下RESTCONF接口：
图12
为了看的清楚接下来采用restclient做展示
针对以上YANG模型定义，可以知道相应的配置下发为：
图13
下发之后可以通过get方法查到刚刚所下发的配置，如下图所示
图14
以上简单示例了一个yang模型对北向接口数据结构的定义模式，其中还有很多诸如operational data store& config data store、list& key以及格式书写的细节，由于时间关系就暂且不展示了。
YANG模型与南向接口
YANG模型与南向接口的关系主要由java语言体现，也即yangtools将YANG模型生成相应的java代码，对于这部分将以ovsdb代码作展示。
在ovsdb->southbound中定义了ovsdb的具体南向接口，截取southbound-api中ovsdb.yang中的一条主线如下所示，其实由此我们同时也可以分析出ovsdb的北向接口，即为http://localhost:8181/config/network-topology:network-topology/topology/{topology-id}/node/{node-id}/termination-point/{tp-id}/
下面我们来找一下这样的YANG模型会生成什么样子的java代码：
跟从YANG模型定义的路径就可以追踪到想要找到的接口生成代码，对于这个例子来说，YANG模型生成的代码如上图所示。
上图是针对augment来说所生成的代码，图中容易看到，在ovsdb-port-interface-attributes中所具有的leaf节点，在ovsdbTerminationPointAugmentationBuilder.java中都有相应的getter和setter方法（如图中灰色部分的getOptions）。
在wiki.opendaylight.org中很容易搜到yang-java mapping的页面，在此不再敖述。
Tips:仔细观察yang模型与生成的代码不难发现，本例中的list都是具有interface的java文件，而leaf则没有，yang模型生成的代码多很容易混乱，实际编程体会一下就会清晰好多。
找到生成的代码以后剩下就可以通过IDE一路追踪到具体实现，随便找到其中getTrunk方法，ctrl+Alt+H(eclipse)就可以找到它的层级结构，跳转到相应的java文件继续阅读代码。
以上就是YANG模型与南向接口的关系，与其说是代码分析不如说是如何针对YANG模型来分析OpenDaylight代码的方法。
总结
在不同项目中，相应的南北向接口可能不同，这主要依据实际情况而定，拿openflow协议来讲，它是具有南向北向两套YANG模型的，这主要是因为OpenFlow协议复杂冗长，不适合直接以这种数据格式提供给北向接口，而要是以北向接口为准简化南向接口中诸如“length”这样的字段也很难使接口简单有效，所以对于openflow协议来说是有openflowjava（openflow 南向接口）和openflowplugin（北向接口）两个工程，分别定义了南北接口，当然，这其中肯定是有环节将南向北向接口数据进行对接。
另一个例子bgp，由于bgp协议数据结构相对简单很多，在这个工程中只有一套YANG，对应于北向接口，而南向接口中诸如”length“这样的字段就可以直接用本地变量来存储。
所以YANG模型的定义可以针对具体情况具体分析，而在使用的过程中，只要先掌握基本的语法规则，对于其他不常用的语法规则现查现用即可。
Q&A
Q1：遇惠君
生成的java代码可以编辑吗，还是只能修改yang？
当然是可以编辑的，但是这样是不合理的，因为这个代码还对应于北向接口，假若修改了代码下一次重新编译代码还是会变回去（如果没有改YANG）所以还是修改YANG模型才是正确方法
Q2：北京-仲平(55544510)
有些container 即出现在config里，又出现在operational里，我理解 一个container要么是config要么是operational，为啥会出现2个都是的情况？
没有两个都是哦
Q3：遇惠君
另外好像通篇都木有看到xml文件呢，倒是提到好多次，xml文件哪去了，干啥用的，用来传参数的？
XML涉及到NETCONF，NETCONF配置是xml格式的，YANG 可以无差转化为XML格式，即YIN YANG
而在OpenDaylight中xml就体现在北向接口:RESTCONF，restconf接口就是xml格式（当然也可以是json，两者可以互转）
Q4：IT难人
NOTIFICAION:除了rpc，yang还有一个类似的“notification”， notification用于定义netconf的通知消息的内容，也是用来定义一个服务。两者的区别在于rpc是一对一的，即单播，而notification是多播的，当Provider提交一个notification时，所有的订阅该服务的Consumer都会收到通知，如典型的PacketIn消息，所谓的订阅即实现该notification的接口。rpc生成的接口类名后缀都是Service。nontification生成的接口类名后缀是Listener。这个地方我觉得有问题，应该是packetout消息吧？
这里是说OpenDaylight内部并不是交换机和OpenDaylight的交互，这个其实是一整套的消息架构，可能会有多个模块需要接受并处理packetin
Q5：遇惠君
南向接口例如openflow snmp也会转换成xml吗？
openflow协议是基于TCP连接，抓一下包就知道了，都是字节流，openflow协议还有一个of-config协议作为配套来配置的
Q6：北京-小舟
operational 再到device是什么意思？
operational是ODL设计的另一个data store了，device就是网元，这个我认为跟NETCONF的三个data store有关系。
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。
