YANG模型介绍及语法 - 图文

YANG 模型介绍及语法

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

The leaf Statement

The leaf-list Statement

The container Statement

The must Statement

The list Statement

The augment Statement

The when Statement

The union Statement

The grouping Statement

The choice Statement

The anyxml Statement

The rpc Statement

The notification Statement

图4

https://wiki.opendaylight.org/view/YANG Tools:YANG to Java Mapping

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）。

本文来源：https://www.bwwdw.com/article/oaoo.html