基于YANG模型传送SDN北向开放API的报告

基于YANG模型传送SDN北向开放API的定义，开源平台架构及可编程技术研究报告

北京邮电大学

信息光子学与光通信国家重点实验室

2015.3

目录

1.SDN被向接口 2

REST API 2

1.2 RESTful 4

1.3 SDN北向接口发展现状与趋势 4

2.开源实现的SDN北向接口&YANG 5

2.1 YANG 5

2.2 OpenDaylight 6

3. SDN北向接口标准化 23

3.1 ONF NBI-WG 23

3.2 IRTF和IETF相关工作组 24

4. 学术界关于北向接口的研究 25

VTN 25

4.2 Nox&Pox 26

5. 部分SDN初创公司关于REST API主要应用 27

5.1 Big Switch Networks 27

5.2 Embrane 27

6.总结 28

 

 

 

 

 

 

 

 

 

 

 

 

 

1. SDN被向接口

根据接口特性可以将北向接口分为强耦合接口(应用编程接口)、松耦合接口以及基于状态的功能接口三种。

1)强耦合API包括进程内API和进程间API。进程内API主要由控制器提供用于在控制器内实现编程功能；进程间API主要由控制器外部部件用来同控制器通信以执行功能或者交换/读取状态。

2) 松耦合接口由外部部件以松耦合的方式与控制器通信，通常并不需要立即响应，也不需要直接或即时同步出现。

3) 基于状态的功能接口包括主要以处理状态为主的API，其功能就是设置和读取状态以及通知状态改变。功能性API提供一套功能以供编程使用，如编程库或SDK，包括系统和协议，它们并不通过过程调用，而是

通过状态改变。

REST API

1.1.1 REST 简介

REST 从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表示方式。获得这些表徵致使这些应用程序转变了其状态。随着不断获取资源的表示方式，客户端应用不断地在转变着其状态，所谓表述性状态转移（Representational State Transfer）。表象化状态转变或者表述性状态转移。

这一观点不是凭空臆造的，而是通过观察当前Web互联网的运作方式而抽象出来的。“设计良好的网络应用表现为一系列的网页，这些网页可以看作的虚拟的状态机，用户选择这些链接导致下一网页传输到用户端展现给使用的人，而这正代表了状态的转变。”

REST是设计风格而不是标准。基于HTTP，URI，以及XML这些现有的广泛流行的协议和标准，伴随着REST，HTTP协议得到了更加正确的使用。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。

• 资源是由URI来指定的。

• 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

• 通过操作资源的表现形式来操作资源

• 资源的表现形式则是XML或者HTML，取决于读者是机器还是人，消费Web服务的刻苦软件还是Web浏览器。当然也可以是任何其他的格式。

1.1.2 REST的优点 

• 可以利用缓存Cache来提高响应速度。

• 通讯本身的无状态性可以让不同的服务器处理一系列请求中的不同请求，提高服务器的扩展性。

• 浏览器即可作为客户端，简化软件需求。

• 不需要额外的资源发现机制。

• 在软件技术演进中的长期兼容性更好。

1.1.3 REST vs SOAP 

1) 成熟度

SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正）。REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。总的来说SOAP在成熟度上优于REST。

2) 效率和易用性

SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。

因此在效率和易用性上来说，REST更胜一筹。

3) 应用设计与改造

REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。

1.2 RESTful

满足以下架构约束条件和原则的应用程序或设计就是RESTful：

1. 客户端和服务器结构

2. 能够利用Cache机制

3. 层次化的系统

4. 连接协议具有无状态性

5. 统一接口

6. 按需代码（Code on Demand）

1.3 SDN北向接口发展现状与趋势

1.3.1 北向接口发展简述

网络开放是产业发展的必然趋势，不但能够为设备的网络带来变革，还可以进一步细分产业链，带来新的产业发展机遇。在网络通信领域，从网络开放性的角度来理解SDN，可以将SDN抽象出图1所示的北向接口、南向接口、东西向接口3中接口类型，其中，SDN通过南向接口实现数据网络中控制平面与数据平面的分离，以ONF的OpenFlow协议和IETF的ForCES、OVSDB、NETCONF+YANG、PCEP等协议为典型代表；东西向接口负责解决多个设备控制平面之间的协同工作的问题；

 

图1  SDN接口示意

从应用的角度自北向南看，SDN北向接口是用户业务以及各种网络业务开发者有效控制和利用网络的门户，开发者能与软件编程的形式调用各种网络资源；从网络运营角度自南向北看，SDN北向接口是通过控制器向上层业务应用开放的接口，SDN向上提供资源抽象，实现软件可编程控制的网络架构，上层的网络资源管理系统或者网络应用可以通过控制器的北向接口，全局把控整个网络的资源状态，并对资源进行统一调度。

北向接口方案制定成为当前SDN领域竞争的焦点，目前尚未形成统一的标准。不同的参与者或者从用户角度出发，或者从运营商角度出发，提出了很多方案，甚至部分传统的网络设备厂商在其现有设备上提供了编程接口供业务应用直接调用。如Cisco的ONE方案，基本不涉及原有网元设备的智能分离，仅通过管理面编程开放有限的能力，缺陷是创新业务的开发和部署困难，与硬件厂商捆绑缺乏兼容性。总体而言，当前SDN北向接口发展一方面由各开源平台推动，力图通过支持更多网络应用落地，造成事实标准；另一方面通过各个标准组织对北向接口的分类、框架、协议等进行标准化定义；还有学术界的知名SDN专家，站在本领域的研究前沿，也在积极探索北向接口的制定。

 

2.开源实现的SDN北向接口&YANG

2.1 YANG

Yang Tools Plugin通过各个Plugin的model定义来自动生成API、Service Interface和相应Java代码。

YANG初始作为NETCONF的建模语言被创建出来，在整个NETCONF的配置协议体系中，YANG用来描述具体网元的配置、状态、通知时间、操作维护的数据信息以及之间的约束关系。在NETCONF+NETMOD联合配置框架下工作时，网元可以对客户端体检的配置信息通过YANG描述的模型进行校验，保证其准确性，同时，也保证各厂商NETCONF协议支持的规范兼容性。一个YANG来描述的OSPF配置示例，表明一个OSPF的属性配置包括Area名称（ID）、启用OSPF的接口描述、Metrix的配置范围以及心跳保活检测的时间范围等。YANG建模示例：OSPF协议配置项以及约束如图3所示。

 

图2 OSPF协议配置项以及约束

目前，YANG的标准化将要完成，其应用范围已经完全脱离了前述的网元配置管理的数据模型描述范畴，部分厂商根据自身的需求，更多地采用YANG在SDN控制场景中来构建南北向的API定义，如上述的OpenDaylight。OpenDaylight定义的REST API，基于YANG来构建模型，然后由YANG Tools开源工具生成对外的API以及部分Plug-in框架代码，接口符合IETF RESTCONF【RFC6241】规范。

2.2 OpenDaylight

2.2.1 OpenDaylight Controller:YANG模式和模型

绑定独立数据模式表述数据的结构、程序和由模块的通知。并且该模式是基于YANG语言的。YANG规范允许图式节点不在原杨规范定义的存在。通常，这些节点与一个或多个扩展模块定义语句，但没有进一步的语义这个节点是在一个计算机可以理解的形式定义（如有效使用的节点，它可以用）。这一模型我们添加的概念图式的未知节点。一个未知的schema节点可以是一个任意模式的节点的子节点。

2.2.2 YANG Tools:YANG to Java Mapping

一、Model 

杨模块转换为Java作为两个Java类。每个类在单独的Java文件。对Java文件的名称组成如下：

< yang_module_name > < Sufix >。Java在< Sufix >可以是数据或服务。示例如下图5 所示：

YANG

Java

module module {

 

    namespace "urn:module";

    prefix "sbd";

 

    organization "OPEN DAYLIGHT";

    contact "http://www.whatever.com/";    

 

    revision 2013-07-09 {

    }

}

ModuleData.java

package org.opendaylight.yang.gen.v1.urn.module.rev201379;

public interface ModuleData {

}

 

ModuleService.java

package org.opendaylight.yang.gen.v1.urn.module.rev201379;

public interface ModuleService {

}

 

二、YANG grouping flow to JAVA

YANG

JAVA

  grouping flow {

        container match {

            uses match:match;

        }

        container instructions {

            uses instruction-list;

        }     

        uses generic_flow_attributes;

        leaf container-name {

            type string; 

        }

        leaf cookie_mask {

            type uint64;

        }

        leaf buffer_id {

            type uint32;

        }

        leaf out_port {

            type uint64;

        }

        leaf out_group {

            type uint32;

        }

        leaf flags {

            type flow-mod-flags;

        }

        leaf flow-name {

            type string;

        }

        leaf installHw {

            type boolean;

        }

}

package org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026;

import java.math.BigInteger;

import org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.FlowModFlags;

import org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.flow.Instructions;

import org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.flow.Match;

import org.opendaylight.yangtools.yang.binding.DataObject;

import org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.GenericFlowAttributes;

import org.opendaylight.yangtools.yang.common.QName;

public interface Flow extends

    DataObject,

    GenericFlowAttributes

{

    Boolean isBarrier();

    Long getBufferId();

    String getContainerName();

    BigInteger getCookieMask();

    FlowModFlags getFlags();

    String getFlowName();

    Boolean isInstallHw();

 }  

      

图3 YANG grouping flow to JAVA

图六使用YANG语言写了一个grouping flow，编译之后会将grouping里相应的leaf字段映射成JAVA语言。并且YANG里用grouping定义的结构体会在JAVA里映射成接口。

三、YANG container with uses mapping

杨容器相匹配的分组流元生成Java接口匹配，代码示例如图七所示：

YANG

JAVA

 

 

 

 

 

 

 

//code omitted

//grouping flow {

container match {

uses match:match;

}

//code omitted

//}

//code omitted

 

package org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.flow;

import org.opendaylight.yangtools.yang.binding.ChildOf;

import org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.Flow;

import org.opendaylight.yangtools.yang.binding.Augmentable;

import org.opendaylight.yangtools.yang.common.QName;

public interface Match

    extends

    ChildOf<Flow>,

    Augmentable<org.opendaylight.yang.gen.v1.urn.opendaylight.flow.types.rev131026.flow.Match>, org.opendaylight.yang.gen.v1.urn.opendaylight.model.match.types.rev131026.Match

{

    public static final QName QNAME = org.opendaylight.yangtools.yang.common.QName.create("urn:opendaylight:flow:types","2013-10-26","match")

    ;

}

图4  Container match to JAVA

 

2.2.2 JAX-RS

Java API for RESTful Web Services旨在定义一个统一的规范，使得Java程序员可以使用一套固定的接口来开发REST应用，避免了依赖于第三方框架。OpenDayight使用了JAX-RS来简化REST API的开发。

2.2.3 北向接口

OpenDaylight为应用（App）提供开放的北向API。支持OSGi 框架和双向的REST 接口。OSGi框架提供给与控制器运行在同一地址空间的应用，而REST API 则提供给运行在不同地址空间的应用。所有的逻辑和算法都运行在应用中。

Topology REST APIs

可提供的服务

请求内容

请求方式

服务器响应

检测拓扑信息

GET

Topology

获取UserLink信息

GRT

List

设置UserLink

PUT

TopologyUserLinkConfig

图5 TopologyRestAPI

Topology的基本单元是：节点node，node的标识包括id和类型，头节点和尾节点连接器的连线组成边edge，edge和多个property的组合构成了具有实际属性的edgeProperties即有了一个具有实际特性的连接，若干edgePeoperties的组合构成了Topology。

另外该APIs提供了TopologyUserLinkConfig组成的list，存储的是用户定义连接的配置信息。

HOST TRACKER REST API

Host Trancker REST APIs提供追踪主机在网络中的位置的功能。主机位置通过Host node connector表示。Host node connector本质是一个逻辑实体，它表示一个交换机或端口。一个主机被IP地址和MAC地址所标识。

Host Tracker REST APIs可提供的服务：

请求分类

客户端请求

服务器响应

地址

GET：返回一个同IP地址参数的主机

PUT：增加一个主机

DELETE:删除一个主机

hostConfig

活动主机

GET：返回本网络所有主机的列表

 

不活动主机

GET:返回本网络中静态配置和NodeConnector掉线的主机

 

图6 Host Trancker REST APIs

Host Tracker REST APIs数据模型：

 

图7 Host Tracker REST APIs

Flow Programmer REST API

Flow Progranmmer REST APIs提供对流性能的编程。

可提供的服务;

请求分类

客户端请求

服务器响应

一般的流

GET：返回指定流的配置列表

list

指定节点上的流

GET：返回在某节点上的流的配置列表

list

指定节点上的静态流

GET：返回与可读的名字、nodeId匹配的流

flowConfig

PUT：增加或修改一个流的配置。若流存在则替换最近的流。

flowConfig

DELETE:删除流配置

(custom)

POST：切换流配置

(custom)

图8 Flow Progranmmer REST APIs

 

Flow Progranmmer REST APIs数据模型

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

flowConfig

 

vlanPriority (string)

0/1

nwDst (string)

0/1

idleTimeout (string)

0/1

tosBits (string)

0/1

name (string)

0/1

dlSrc (string)

0/1

hardTimeout (string)

0/1

protocol (string)

0/1

node (node)

0/1

cookie (string)

0/1

installInHw (string)

0/1

tpDst (string)

0/1

nwSrc (string)

0/1

vlanId (string)

0/1

tpSrc (string)

0/1

ingressPort (string)

0/1

etherType (string)

0/1

dlDst (string)

0/1

priority (string)

0/1

actions (string)

0/unbounded

list

flowConfigs

flowConfig (flowConfig)

0/unbounded

Node

node

type (string)

0/1

id (string)

0/1

图9 Flow Progranmmer REST APIs

 

Static Routing REST API

Static Routing REST APIs涉及到静态路由的管理。

可提供的服务：

请求分类

客户端请求

服务器响应

routes

GET:返回静态路由现状的列表

list

Route

GET:返回所提供配置名称的静态路由

staticRoute

PUT:增加新的静态路由（如果该路由存在，返回错误）

staticRoute

DELETE:删除静态路由

(custom)

图10 Static Routing REST APIs

Static Routing REST APIs数据模型：

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

list

staticRoutes

staticRoute (staticRoute)

0/unbounded

staticRoute

staticRoute

name (string)

注：The name of the static route.

0/1

prefix (string)

注：The prefix for the route. Format: A.B.C.D/MM Where A.B.C.D is the Default Gateway IP (L3) or ARP Querier IP (L2)

0/1

nextHop (string)

注：NextHop IP-Address (or) datapath ID/port list: xx:xx:xx:xx:xx:xx:xx:xx/a,b,c-m,r-t,y

0/1

图11 Static Routing REST APIs

Statics REST API

Statics REST APIs返回被南向的协议插件（如OpenFlow）公开的各种统计信息。

可提供的服务：

 

请求分类

客户端请求

服务器响应

flow

GET:返回所有节点的所有流的统计信息的列表

list

port

GET:返回所有经过节点上的NodeConnector的端口统计信息

list

table

GET：返回在所有节点上的链表信息

list

Flow on a node

GET:返回指定节点上的流的统计信息的列表

nodeFlowStatistics

Port on a node

GET:返回所有经过指定节点上的NodeConnector的端口统计信息

nodePortStatistics

table on a node

GET：返回在指定节点上的链表信息

nodeTableStatistics

图12 Statistics REST APIs

Statistics REST APIs数据模型

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

action

action

type (actionType)

0/1

flow

flow

actions (action)

0/unbounded

hardTimeout (short)

1/1

idleTimeout (short)

1/1

match (match)

0/1

priority (short)

1/1

id (long)

1/1

FlowStat

flowOnNode

flow (flow)

0/1

tableId (byte)

1/1

byteCount (long)

1/1

durationSeconds (int)

1/1

packetCount (long)

1/1

durationNanoseconds (int)

1/1

list

allTableStatistics

tableStatistics (tableStatistics)

0/unbounded

match

match

matchField (matchField)

0/unbounded

matchField

matchField

 

 

node

node

type (string)

0/1

id (string)

0/1

nodeConnector

nodeConnector

type (string)

0/1

id (string)

0/1

node (node)

0/1

nodeConnectorStatistics

nodeConnectorStatistics

receivePackets (long)

1/1

receiveBytes (long)

1/1

transmitErrors (long)

1/1

transmitPackets (long)

1/1

receiveDrops (long)

1/1

receiveOverRunError (long)

1/1

receiveErrors (long)

1/1

nodeConnector (nodeConnector)

0/1

transmitDrops (long)

1/1

transmitBytes (long)

1/1

collisionCount (long)

1/1

receiveCrcError (long)

1/1

receiveFrameError (long)

1/1

nodeFlowStatistics

flowStatistics

node (node)

0/1

flowStatistic (flowOnNode)

0/unbounded

nodePortStatistics

portStatistics

node (node)

0/1

portStatistic (nodeConnectorStatistics)

0/unbounded

nodeTable

nodeTable

id (string)

0/1

node (node)

0/1

nodeTableStatistics

tableStatistics

node (node)

0/1

tableStatistic (nodeTableStatistics)

0/unbounded

 

nodeTableStatistics

maximumEntries (int)

1/1

name (string)

0/1

matchedCount (long)

1/1

activeCount (int)

1/1

lookupCount (long)

1/1

nodeTable (nodeTable)

0/1

图13 Statistics REST APIs

 

Subnets REST API

Subnets REST APIs用来管理子网。

可提供的服务：

请求分类

客户端请求

服务器响应

subnets

GET:列出给定范围的所有子网

list

subnet

GET:列出给定区域一个子网的配置

subnetConfig

PUT：增加一个子网到指定的区域，节点连接器可选

subnetConfig

DELETE：从指定区域删除子网

(custom)

POST：修改一个子网。用新的代替旧的。只有端口的列表可以修改。若不存在则新建子网。

subnetConfig

图14 Subnets REST APIs

Subnets REST APIs数据模型

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

list

subnetConfigs

subnetConfig (subnetConfig)

0/unbounded

subnetConfig

subnetConfig

 

subnet (string)

0/1

name (string)

0/1

nodeConnectors (string)

0/unbounded

图15 Subnets REST APIs

Switch Manager REST API

Switch Mannager REST APIs用来批准node、node connector、property的接入。可提供的服务：

请求分类

客户端请求

服务器响应

nodes

GET:在网络上检索所有的节点和他们的属性

list

save

POST：保存最近的交换机设置

(custom)

node

GET:在网络上检索指定节点的节点连接器和他们的属性

list

node property 

DELETE：删除指定节点的属性

(custom)

Node property value

PUT：增加一个转发层模式属性的描述给节点

(custom)

nodeConnector property

DELETE:删除节点连接器的属性

(custom)

图16 Switch Mannager REST APIs

Switch Manager REST APIs数据模型

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

list

nodes

nodeProperties (nodeProperties)

0/unbounded

node

node

type (string)

0/1

 

id (string)

0/1

nodeConnector

nodeConnector

type (string)

0/1

id (string)

0/1

node (node)

0/1

nodeConnectorProperties

nodeConnectorProperties

nodeconnector (nodeConnector)

0/1

properties/property

0/unbounded

nodeProperties

nodeProperties

node (node)

0/1

properties/property

0/unbounded

图17 Switch Mannager REST APIs

User Manager REST API

User Manager REST APIs用来管理用户，并且只能用于HTTPs协议。

可提供的服务：

请求分类

客户端请求

服务器响应

users

POST：增加一位新用户

userConfig

users

DELETE：删除一个用户

(custom)

图18 User Manager REST APIs

User Manager REST APIs数据模型

Data Elements

Data Types

XML Elements

 

 

名称（类型）

最大/最小 出现

userConfig

userConfig

roles (string)

0/unbounded

password (string)

0/1

user (string)

0/1

 

configurationObject

 

 

图19 User Manager REST APIs

2.2.4 OpenDaylight简述

 

图20 基于OpenDayLight 的SDN架构图

OpenDayLight。图1为OpenDayLight给出的SDN架构，其中，网络应用/编排/业务和控制平台之间的OpenDayLight APIs即为通常所说的北向接口，这里指定以REST方式进行定义，OpenDayLight所给出的SDN应用包括对L2/L3转发以及负载均衡、集线器等。

 

图21 OpenDaylight架构

 

OpenDaylight是Linux基金下的一个开源软件项目，以进一步的应用和创新目标为基础，创建一个共同的软件定义网络（SDN）行业支持的平台。OpenDaylight旨在打造一个统一开放的SDN平台，如图2所示，应用可以通过OpenDaylight的北向接口API访问网络中的资源和信息。

 

 

图22 应用通过OpenDaylight北向接口访问网络资源

2.1.3.1 MD-SAL&YANG

 

图23 MD-SAL Overview

OpenDaylight控制器采用了模块化驱动（model-driven）的方法抽象出SDN控制器各个组件的南北向API以及各种服务和组件使用的数据结构，并且使用YANG数据建模语言【RFC6020】作为服务和数据抽象的建模语言。

ONOS

2.2.1 ONOS简介

服务提供商希望他们的网络敏捷、高效，满足日益增长的带宽需求，以创新服务和新型业务模式获取收入。软件定义网络SDN是服务提供商网络转型的关键，而ONOS是一个为服务提供商量身打造的新型运营商级别的SDN网络操作系统，由ON.Lab和ONOS社区内领先的服务提供商、供应商和开发者共同开发。

ONOS是首款开源的SDN网络操作系统，主要面向服务提供商和企业骨干网。ONOS的设计宗旨是满足网络需求实现可靠性强、性能好、灵活度高。此外，ONOS的北向接口抽象层和API支持简单的应用开发，而通过南向接口抽象层和接口则可以管控OpenFlow或者传统设备。总体来说，ONOS将会实现以下功能：

1.SDN控制层面实现电信级特征（可靠性强，性能好，灵活度高）；

2.提供网络敏捷性强有力保证；

3.帮助服务提供商从现有网络迁移到白牌设备；

4.减少服务提供商的资本开支和运营开支。

 

图24 ONOS架构概述

ONOS具有下述核心功能：

1.分布式核心平台，提供高可扩展性、高可靠性以及高稳性能，实现运营商级SDN控制器平台特征。ONOS像集群一样运行，使SDN控制平台和服务提供商网络具有网页式敏捷度。

2.北向接口抽象层/APIs，图像化界面和应用提供更加友好的控制、管理和配置服务，抽象层也是实现网页式敏捷度的重要因素。

3.南向接口抽象层/APIs，可插拔式南向接口协议可以控制OpenFlow设备和传统设备。南向接口抽象层隔离ONOS核心平台和底层设备，屏蔽底层设备和协议的差异性。且南向接口是从传统设备向OpenFlow白牌设备迁移的关键。

4.软件模块化，让ONOS像软件操作系统一样，便于社区开发者和服务提供商开发、调试、维护和升级。

2.2.2 ONOS北向抽象层（API）

ONOS架构中有两个强大的北向抽象层：意图框架和全局网络视图。意图框架屏蔽服务运行的复杂性，允许应用向网络请求服务而不需要了解服务运行的具体细节，这就意味着网络运营商和应用开发者可以进行高级编程。他们可以轻松地提出意图：一个策略声明或连接需求。

意图框架处理所有应用的请求，判断可以满足哪些应用，解决应用之间的冲突，执行管理者的策略，对网络编程提供请求的功能，交付请求的服务给应用。

一个意图转化为多个目标。例如，一个连接2个主机的意图转化为2个目标，各提供一个方向的流。将意图转化的目标编译成指令发送给网络设备，整个流程按照网络运维人员指定的策略进行。从某种程度上说这个方法可以解决意图之间的冲突。

全局网络视图为应用提供了网络视图，包括主机、交换机以及网络相关的状态参数，如利用率。应用可以通过APIs对网络视图进行编程，一个API可以为应用以网络图的形式提供网络视图。

确切的说，北向接口抽象层和APIs将应用与网络细节进行隔离。而且也可以隔离需要了解网络事件（如链路中断）的应用和其它应用。反而言之，将网络操作系统与应用隔离，网络操作系统可以管理来自多个、竞争应用的请求。从业务角度看，提高了应用开发速度，允许网络改变并且保证应用不会当机。

2.2.3 软件模块化

软件模块化是ONOS一大特征，基于软件的形式可以很方便地进行添加、改变和维护。ONOS团队在模块化方面投入很多心血，务必让开发者可以简单快捷地操作软件。将软件拆分为若干组件以及组件之间的交互。从如下的示意图所示，ONOS的主体架构是围绕分布式核心的分层架构。所以，从宏观结构上说，北向接口与南向接口API将应用、分布式核心和适配层相互隔离，可以独立添加新的应用和协议适配器。

同样，从具体细节来看，分布式核心内部的子结构也能体现模块化特征，分布式核心的存在价值就是约束所有子系统的规模并保证模块的可拓展性。此外，连接不同模块的接口是至关重要的，允许模块不依赖其他模块独立更新。这样就可以不断更新算法和数据结构，并且不会影响整体系统或是应用。

显然，ONOS很重视接口，因为接口可以促进模块业务和职责的分离，尽量使子系统之间的交互更为自然、简单。这一特点是确保软件稳定更新的关键。例如，尽量提供南向API的抽象程度，避免将不同协议的偏差传递到上层，并且强化分布式核心而不是适配层来创建网络模型对象。

ONOS源代码的树形结构不仅仅为了遵循而是要加强这些结构原则。合理控制模块大小并且模块之间保持适当依赖形成一个非循环的结构图，模块之间通过API模块相互关联，正如下图所示。

 

图25：ONOS Models

2.3 Floodlight

Floodlight是BIG Switch控制器的开源版本，Floodlight架构如图4所示，其北向接口也是基于REST API。Floodlight不仅提供了基本的网络状态查询、统计、配置接口，还提供了以下3种API。

 

图26 Floodlight架构

 

1) 静态流推送器API

静态流推送器API允许用户手动将流插入到OpenFlow网络，包括OpenFlow的主动添加和被动添加2中方式。

2) 虚拟网络API

虚拟网络API负责创建新的虚拟网络的名称、ID、网关等，将主机加入到虚拟网络中等。

3) 防火墙API

防火墙API负责防火墙的创建、开启、删除等操作。

2.4 Ryu

Ryu采用组件化的结构，由Rython语言编写，并提供大量库函数（组件）供SDN应用的开发。RyuSDN框架如图5所示，针对北向的用户的应用，Ryu框架也提供了丰富的API。

1) RESTful管理API

用户通过相应组件配置管理SDN网络的接口，如可以通过OF REST组件API配置OpenFlow交换机；通过Firewall组件API配置防火墙等。

 

 

图27 RyuSDN框架

2) REST API

REST API是与OpenStack云编排系统（orchestration）对接的接口。

3) 用户自定义API

用户也可通过自定义的方式实现REST API或RPC API。

2.5 Group-Based-Policy

Group-Based-Policy是由Cisco和IBM主导，在Openstack平台新增的一个关于北向接口的开源项目。

2013年11月，Cisco收购Insieme Networks公司以后，以该公司技术为核心，推出了以应用为中心的基础设施解决方案“ACI”。同时，在其主导的OpenDaylight社区创建新的孵化项目Group Policy，随后与IBM联合提案，在Neutron项目中增加以应用为中心的、面向策略的、抽象的接口项目，并最终命名为“基于组的策略抽象（GBP）”。

该项目的基本目标是制定更合适与应用所使用的、开放的北向API、其出发点认为目前面向网络及其服务的北向接口比较复杂，不利于应用开发者使用，特别是不熟悉网络编程的人员，无法面对复杂的网络协议和功能，因此，需要提供面向策略的语义接口，能够使上层对网络的使用更简化。

2.6 Congress Project

Congress Project由VMware公司主导，与2014年初启动，目的是提供面向策略的北向接口（Policy as a service）。

作为云计算领域领头的IT公司，VMware面对的主要是IT设施以及应用层面的开放，Congress的提出也是对Cisco（Vendor厂商）面向应用部署、自动化方面渗透的GBP项目的一个应激防御，防止由Vendor厂商来主导面向应用层次接口的开放制订。

Congress希望给应用提供一个关于部署、配置、管理等方面的接口框架，简化应用层对下层细节理解以及使用管理。主要涉及以下几个方面：

• 租户资源的配置（如VMs、Applications）；

• 自动化部署（如application/VM locations）；

• 资源应用自适应（如Web App scaling based on load）；

• 基础设施的管理（如relationship between hosts、newworks。Storege）。

3. SDN北向接口标准化

3.1 ONF NBI-WG

ONF原本在架构与框架工作小组（architecture framework WG，ARCH-WG）中有一个研究小组在从事不同SDN解决方案的北向接口研究，为了响应产业对SDN北向API标准化的需求，新成立了北向接口工作小组（NBI-WG）。

NBI工作组目前尚未发布相关的标准草案，但是在工作组的目标文档中提出，对于SDN北向接口应给出不同层次的抽象及接口范围，ONF北向接口层次框架规划如图6所示。

 

图28 ONF北向接口层次框架规划

ONF期望定义并发展通用的以及一些预定领域的API，其主要目的是为控制器、网络服务以及开发者提供可扩展且稳定的北向API，增加软件设计上与SDN控制器交互运作的便利性，同时确保控制器供货商开发时能在共通API自由创新。

3.2 IRTF和IETF相关工作组

IRTF已经成立了SDN研究工作组（software defined networking research group，SDNRG），工作组草案提出了SDN层次化结构，其中，在管理和控制层面上给出了网络服务抽象层（networking services abstraction layer，NSAL），为应用、服务、控制和管理提供接入，也就是北向接口，具体的接口形式包括但不局限于RESTful APIs、RPC、公开的或特定的协议、CORBA接口。IRTF认为北向接口应该具有更多信息，整个设备、资源的管理平面也纳入到SDN北向接口的考虑范围。SDNRG定义的SDN层次架构如图7所示。

 

图29 SDNRG定义的SDN层次架构

IETF前期对于SDN的标准化多集中于南向接口技术，围绕传统的协议接口进行完善和扩展，并在一定程度上进行少量创新，试图在对传统网络不造成较大冲击的情况下适应SDN的需求，如ForCES【REC5810】、BFD、PCEP、BGP的修改、新增I2RS提交的OVSDB等。北向接口方面，前期的ALTO可作为网络拓扑以及路径计算服务的开放接口，NETCONF管理协议，完成YANG、RESTCONF等一系列与SDN紧密相关的扩展，可作为北向接口的选择之一。另外，考虑到NFV以及NFV与SDN结合的影响，IETF成立了SFC（service function chain）工作组，意图确立各网络功能服务整合的体系架构以及对外的接口，SFC的对外控制接口是SDN北向接口的重要组成部分

一方面，产业界出资与学术机构合作研究可商业化的原型系统实现，并以原型平台为基础，对业界推介SDN的北向接口定义，如ONIX、NOX、BEACON等都是类似这样的SDN控制器平台，进而自定义一套北向接口。

另一方面，针对OpenFlow，在POF这类网络编程方面接近汇编语言可能的缺陷，如暴露太多底层细节，模拟设备的转发行为，需要编程者在类似规则重叠、优先级冲突、数据面状态一致性上等细节上最更多考虑。一些研究者致力于创造新的网络编程语言的研究，代表有Frenetic、Pyretic、Maple、Netcore等。

4. 学术界关于北向接口的研究

一方面，产业界出资与学术机构合作研究可商业化的原型系统实现，并以原型平台为基础，对业界推介SDN的北向接口定义，如ONIX、NOX、BEACON等都是类似这样的SDN控制器平台，进而自定义一套北向接口。

另一方面，针对OpenFlow，在POF这类网络编程方面接近汇编语言可能的缺陷，如暴露太多底层细节，模拟设备的转发行为，需要编程者在类似规则重叠、优先级冲突、数据面状态一致性上等细节上最更多考虑。一些研究者致力于创造新的网络编程语言的研究，代表有Frenetic、Pyretic、Maple、Netcore等。

VTN 

VTN简单介绍

VTN是SDN控制器中用于提供多租户虚拟网络的一项应用。通常，为每个部门的系统配置网络需要耗费大量的人力、物力，同样，需要为每个租户安装各种网络应用，并且很难共享这些资源，因此，设计、部署、管理整个复杂的网络是一项繁重的任务。为了解决这一难题，OpenDaylight提出在控制器中使用VTN，VTN的独特之处在于逻辑抽象平台。VTN将逻辑层面与物理层面完全分离，用户可以设计、利用任何所需网络，并且无需了解物理网络的拓扑结构和带宽限制。

VTN允许用户根据对L2/L3层网络的感知来定义网络。由此可知，基于VTN设计的网络会自动被映射到底层物理设备，并配置到支持SDN控制协议的独立的交换机上。这样不仅屏蔽了底层网络的复杂性而且可以更好的管理网络资源，减少了网络服务的配置时间和配置错误。

 

图30 VTN架构

4.1.2 VTN API

Virtual Tenant Network项目是ODP中的一个重要项目，主要负责在SDN控制器上提供对多租户虚拟网络的支持。利用该项目，可以很好的让ODP支持OpenStack。

北向API

VTN提供了REST API，因此用户可以通过web操作来对VTN资源进行管理。支持Json和XML格式。如下图所示。

 

图31 VTN北向API

支持的操作如下表格所示：

 

图32 支持的操作

4.2 Nox&Pox

第一个OpenFlow控制器是用C++编写的NOX，它同时还提供了用于Python开发的API。在早期人们探索OpenFlow和SDN领域的时候，NOX一直是很多研究和开发项目的基础。NOX的开发遵循两条不同的路线：经典NOX、NOX。

前者是广为人知的开发路线，它包括了Python和C++，以及一组网络应用，不过，这种开发路线将被弃用，对NOX-Classic已不再有进一步的开发计划。新的NOX只支持C++，与经典NOX相比，它的网络应用也更少，但是运行速度更快，代码更简洁。POX是一个只支持Python的NOX版本，可以把它看作是一个通用的、开源的、用Python编写的OpenFlow控制器，也是一个能快速开发网络应用和构建网络应用原型的平台。POX的主要目标是研究领域，由于大多数研究项目在本质上生命周期都不长，POX的开发人员关注的是提供合适的接口，而非维护一个稳定的API。NOX（和POX）目前由GitHub的Git源代码仓库（Git source code repository）管理。复制（Cloning）Git repository是获取NOX和POX的最佳途径。POX软件可分为两个分支（branch）：active分支和released分支，active分支是正处于活跃开发阶段的软件，released分支是在开发的某个阶段，被选作新的版本发布的软件。最新发布的分支仍有可能继续改进，不过只提供以补丁形式的修订，而新增的功能总是包含在active分支中。

POX是由NOX演变而来，其底层模块有C++实现，上层应用可以用C++或Python编写，它的核心作用是提供快速开发网络控制软件原型的平台。POX和OpenFlow交换机进行交互，可以用于软件定义网络这个新兴学科的基础研究，比如探索和圆形分布、SDN调试、网络虚拟化、控制器设计和编程模型。

5. 部分SDN初创公司关于REST API主要应用

5.1 Big Switch Networks

Big Network Controller 大网络控制器

大网络控制器的开放式软件定义网络（SDN）是网络应用平台，提供统一的网络智能，企业级的可扩展性和高可用性，部署范围广泛的网络应用，包括数据中心网络虚拟化和平台。大网络控制器采用业界标准的协议，如OpenFlow，创建一个通用的抽象和通用数据模型为基础的网络数据平面元素。结合开放和发布的应用程序编程接口（API）。

5.2 Embrane 

HELEOS ESM

HELEOS的弹性服务管理简化容量规划和网络工程任务，并允许运营商打开客户，定义新的服务并是服务能力快速，方便地增长。不涉及底层服务器或虚拟机基础设施。其加快和简化了网络服务的自动分配和管理物理资源在每个服务。HELEOS ESM消除了管理的复杂性和加快部署的前期配置和配置任务自动化以及有效动态，运行时间的变化。提供可编程的特点，即采用REST风格的API。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6. 总结 

从技术实现上看，在开源组织、标准化组织，甚至工业领域，RESTful API是当前普遍认同的接口技术，其具备以下4个特点：

1) 可寻址性强

对应于而言，需要使用到的数据或算法片段，都会具有唯一的、可访问的资源地址。

2) 资源表述与操作

资源以JSON、XML、HTML等格式进行表述，通过表述操作资源。

3) 无状态

对每个请求而言，彼此之间是隔离的，服务器不保存“应于状态”，客户端无需事先获知如何和服务器交互。

4) 消息自描述

通过消息交互，每条消息包含足够的信息描述该条消息应该如何处理。

从北向接口的发展趋势来看，当前SDN北向接口更多是从网络的角度，如网元、链路、端口、网络业务实体化等视角出发提供API，随着北向接口不断完善，从业务角度出发，按照业务应用描述、编排、流程化等需求对底层接口进行封装。