基於YANG模型傳送SDN北向開放API的定義，開源平臺架構及可程式設計技術研究報告

北京郵電大學

資訊光子學與光通訊國家重點實驗室

2015.3

目錄

VTN 25

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. 按需程式碼（CodeonDemand）

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
		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
	0/1

圖13 Statistics REST APIs

Subnets REST API

Subnets REST APIs用來管理子網。

可提供的服務：

請求分類	客戶端請求	伺服器響應
subnets	GET:列出給定範圍的所有子網	list
subnet	GET:列出給定區域一個子網的配置
	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，隨著北向介面不斷完善，從業務角度出發，按照業務應用描述、編排、流程化等需求對底層介面進行封裝。