SDN的網(wǎng)絡(luò)模型及北向接口

李晨+陳俏鋼+李鳳凱+吳波

摘要：網(wǎng)絡(luò)模型及北向接口（NBI）是軟件定義網(wǎng)絡(luò)（SDN）中的關(guān)鍵問題。根據(jù)業(yè)界標準發(fā)展情況，提出了網(wǎng)絡(luò)模型分為網(wǎng)絡(luò)業(yè)務(wù)模型、網(wǎng)管模型、功能模型和網(wǎng)絡(luò)設(shè)備模型，并指出了不同的模型對應(yīng)了不同的需求。認為運營商、大型廠商等應(yīng)定義統(tǒng)一的SDN模型和接口，能夠推動產(chǎn)業(yè)鏈的成熟和統(tǒng)一。

關(guān)鍵詞： 網(wǎng)絡(luò)模型；業(yè)務(wù)模型；網(wǎng)管模型；功能模型

1 網(wǎng)絡(luò)模型定義和特征

1.1 多層次、多視角的網(wǎng)絡(luò)需求

不同角色的網(wǎng)絡(luò)用戶，對網(wǎng)絡(luò)的需求是不同的。比如對于一個公有云租戶，或者一個運營商網(wǎng)絡(luò)業(yè)務(wù)的設(shè)計者來說，更加關(guān)注的是網(wǎng)絡(luò)業(yè)務(wù)相關(guān)的指標（模型和接口），如何幫助他們快速定義自己的云網(wǎng)絡(luò)或者短時間內(nèi)推出一個新業(yè)務(wù)，而不關(guān)注網(wǎng)絡(luò)實現(xiàn)的細節(jié)。對于網(wǎng)絡(luò)架構(gòu)設(shè)計者和運維人員來說，如何快速定位故障，如何設(shè)計出更加穩(wěn)定、靈活和可擴展的網(wǎng)絡(luò)，進而具體選擇哪種網(wǎng)絡(luò)技術(shù)實現(xiàn)是更重要的問題。

因此，同一張網(wǎng)絡(luò)對應(yīng)不同的需求，在模型和接口上也需要有層次的劃分，如圖1所示。

1.2 網(wǎng)絡(luò)的多層模型

網(wǎng)絡(luò)模型是多層次的，可以分為網(wǎng)絡(luò)業(yè)務(wù)模型、網(wǎng)管模型、功能模型和設(shè)備模型，如圖2所示。

網(wǎng)絡(luò)業(yè)務(wù)模型是網(wǎng)絡(luò)業(yè)務(wù)、應(yīng)用驅(qū)動，面向用戶需求，與實現(xiàn)技術(shù)無關(guān)，與物理網(wǎng)絡(luò)無關(guān)的抽象模型。網(wǎng)絡(luò)業(yè)務(wù)模型主要包括邏輯網(wǎng)絡(luò)之間相互交互、網(wǎng)絡(luò)策略、業(yè)務(wù)服務(wù)等級（SLA）、業(yè)務(wù)調(diào)度策略等。

網(wǎng)管模型在軟件定義網(wǎng)絡(luò)（SDN）中，是專注于網(wǎng)絡(luò)的運維（OAM），運維需求驅(qū)動，面向具體運維技術(shù)相關(guān)的抽象模型，如網(wǎng)管模型能夠看到具體的交換機、路由器設(shè)備，以及端口信息。

網(wǎng)絡(luò)功能模型是具體網(wǎng)絡(luò)技術(shù)的功能模型抽象，如為了實現(xiàn)租戶隔離，將采用第3層虛擬專用網(wǎng)絡(luò)（L3 VPN）或第2層虛擬專用網(wǎng)絡(luò)（L2 VPN）等具體技術(shù)。

網(wǎng)絡(luò)設(shè)備模型指對各個廠家單臺網(wǎng)絡(luò)設(shè)備的抽象，如該設(shè)備路由表項采用何種隧道以及封裝、解封裝描述，服務(wù)質(zhì)量（QoS）隊列描述，訪問控制策略，以及轉(zhuǎn)發(fā)協(xié)議采用OpenFlow、邊界網(wǎng)關(guān)協(xié)議（BGP）等。

網(wǎng)絡(luò)多層模型之間有著映射關(guān)系，業(yè)務(wù)模型中的具體指標會映射為網(wǎng)絡(luò)功能模型中的具體技術(shù)，部分業(yè)務(wù)還需要讀取網(wǎng)管模型中的監(jiān)測控制及告警指標，觸發(fā)調(diào)度策略生效。

1.3 網(wǎng)絡(luò)模型和SDN北向接口

北向接口（NBI）是網(wǎng)絡(luò)業(yè)務(wù)模型、網(wǎng)絡(luò)功能模型和網(wǎng)管模型的一種使用方式。

在SDN網(wǎng)絡(luò)中，控制器以上部分的接口稱為NBI，通常以RESTful應(yīng)用程序編程接口（API）方式與控制器交互。目前SDN的NBI主要分為基于意圖的NBI和功能型NBI兩大類。

結(jié)合SDN網(wǎng)絡(luò)的層次架構(gòu)，網(wǎng)絡(luò)模型有相對應(yīng)的抽象?；谝鈭D的NBI對應(yīng)了網(wǎng)絡(luò)業(yè)務(wù)模型，它主要用于描述SDN網(wǎng)絡(luò)使用者的需求，與技術(shù)無關(guān)，目前主要包括連接服務(wù)、資源需求、訪問控制、流處理、策略邏輯等幾部分內(nèi)容，并且仍在完善中。功能型NBI對應(yīng)了網(wǎng)絡(luò)功能模型和網(wǎng)管模型，面向具體的網(wǎng)絡(luò)功能，與網(wǎng)絡(luò)技術(shù)方案相關(guān)的NBI接口。這部分NBI在每個場景和案例中都會有區(qū)別，所以應(yīng)結(jié)合場景逐一分析，目前也在完善中，如圖3所示[1]。

結(jié)合SDN的3層架構(gòu)，可以對基于意圖的NBI、功能型NBI與網(wǎng)絡(luò)模型、SDN應(yīng)用程序（APP）、SDN控制器以及網(wǎng)管的關(guān)系總結(jié)如下，具體如圖4所示。

（1）基于意圖的NBI是網(wǎng)絡(luò)業(yè)務(wù)模型所需要的輸入消息。業(yè)務(wù)模型可以在SDN APP內(nèi)部實現(xiàn)（圖4中綠色區(qū)域），也可以在控制器上實現(xiàn)（圖4中黃色區(qū)域）。對應(yīng)地，業(yè)務(wù)模型向功能模型的映射也分為在APP完成或控制器完成兩種方式，基于意圖的NBI也會終結(jié)在APP或控制器上[2]。

（2）功能型NBI是網(wǎng)管模型+網(wǎng)絡(luò)功能模型所需要的輸入消息。網(wǎng)絡(luò)功能模型主要在控制器上實現(xiàn)，網(wǎng)管模型主要在運營支撐系統(tǒng)（OSS）網(wǎng)管上實現(xiàn)。其中控制器和OSS網(wǎng)管從目前的實現(xiàn)看，有完全獨立、互相重疊、完全包含3種方式。從近期看，控制器側(cè)重于業(yè)務(wù)下發(fā)和流量統(tǒng)計，網(wǎng)管側(cè)重于告警、性能監(jiān)測控制和日志統(tǒng)計，將會繼續(xù)并存。

1.4 網(wǎng)絡(luò)模型和NBI的描述形式

網(wǎng)絡(luò)模型主要用數(shù)據(jù)模型和協(xié)議的組合來描述，和網(wǎng)絡(luò)模型描述有關(guān)的協(xié)議和數(shù)據(jù)模型主要包括4種。

·NETCONF協(xié)議：網(wǎng)絡(luò)設(shè)備配置協(xié)議（RFC6241），包括消息層、操作層、內(nèi)容層等。

·YANG數(shù)據(jù)模型：數(shù)據(jù)模型，為NETCONF提供通用數(shù)據(jù)格式，可以用統(tǒng)一建模語言（UML）、壓縮樹的方式展現(xiàn)。

·RESTful協(xié)議：基于HTTP協(xié)議，包括post、put、delete、get等消息。

·RESTCONF協(xié)議：用RESTful方式訪問YANG數(shù)據(jù)。

網(wǎng)絡(luò)模型的描述形式目前主要采用YANG數(shù)據(jù)模型或一系列API消息來描述。NBI所采用的協(xié)議主要為RESTCONF或RESTful API。

2 業(yè)務(wù)/網(wǎng)管/功能模型

2.1 網(wǎng)絡(luò)業(yè)務(wù)模型

網(wǎng)絡(luò)業(yè)務(wù)模型可以用對象、操作、結(jié)果（OOR）來描述，如圖5中所示，這種描述的方式也充分體現(xiàn)了業(yè)務(wù)描述與網(wǎng)絡(luò)細節(jié)無關(guān)的思想。圖5中業(yè)務(wù)模型表述的意思是：用戶在某個上下文環(huán)境中有基于意圖的表述。

首先對于對象來說，包括節(jié)點、連接和流信息，這些對象將作為網(wǎng)絡(luò)模型所描述的主體。

其次操作分為條件、動作和限制。在滿足帶寬、時延等網(wǎng)絡(luò)條件下，在匹配哪些節(jié)點之間不可互通等限制下，執(zhí)行標記優(yōu)先級，實現(xiàn)轉(zhuǎn)發(fā)的操作。

最后對于結(jié)果，包括期待結(jié)果和避免結(jié)果兩類，如預(yù)期保證帶寬利用率大于80%，或避免端到端時延大于100 ms等。

關(guān)于網(wǎng)絡(luò)業(yè)務(wù)模型，我們可采用3個例子加以描述。

例1：銀行多站點間基于意圖的需求

（1）各分支站點可以訪問位于總部站點的網(wǎng)絡(luò)服務(wù)器，不可以訪問位于總部站點的戶數(shù)據(jù)庫。

（a）目標：各分支、總部站點網(wǎng)絡(luò)服務(wù)器，總部站點用戶數(shù)據(jù)庫等；

（b）操作：可以訪問，或者不可以訪問。

（2）各站點間的帶寬利用率保持大于80%。

（a）目標：各站點間的帶寬資源；

（b）結(jié)果：期待大于80%。

例2：企業(yè)站點間視頻會議服務(wù)、數(shù)據(jù)傳輸基于意圖的需求

（1）站點間視頻會議優(yōu)先保證語音流暢，數(shù)據(jù)備份優(yōu)先級低傳輸。

（a）目標：站點間的視頻數(shù)據(jù)流、數(shù)據(jù)備份數(shù)據(jù)流；

（b）操作：設(shè)定優(yōu)先級。

（2）數(shù)據(jù)備份的數(shù)據(jù)內(nèi)容進行日志記錄和安全識別。

（a）目標：數(shù)據(jù)備份數(shù)據(jù)流；

（b）操作：logging和流清處理。

例3：云計算中心網(wǎng)絡(luò)應(yīng)用場景中的幾個需求描述

（1）需要構(gòu)建2層、3層網(wǎng)絡(luò)。

（a）CREATE Node l2_network Type l2-group Contain h1，h2；

（b）CREATE Node l3_network Type l3-group Contain n1，n2。

（2）鏈接虛擬機。

CREATE Connection c1 Type p2p Endnodes n1， n2 Property bandwidth：1024。

（3）定義業(yè)務(wù)數(shù)據(jù)流。

（a）CREATE Flow f1 Match src-ip： 10.0.1.0/24， dst-ip： 10.0.2.0/24， dst-port： 80；

（b）CREATE Flow f2 Match src-ip： 10.0.5.0/24， dst-ip： 10.0.6.0/24， dst-port： 80。

（4）部署訪問控制列表（ACL）訪問控制策略。

（a）CREATE Operation o1 Priority 1 Target f1 Action drop；

（b）CREATE Operation o1 Priority 1 Target f1 Action allow。

（5）部署QoS策略。

（a）CREATE Operation o3 Priority 1 Target c1 Action qos-bandwidth： 4096。

2.2 網(wǎng)管通用模型描述

根據(jù)電信國際電信聯(lián)盟電信管理網(wǎng)（ITU-T TMN）的定義，網(wǎng)管模型定義了標準q接口，對現(xiàn)有網(wǎng)絡(luò)中業(yè)務(wù)，如VPN、多協(xié)議標簽交換傳送應(yīng)用（MPLS-TP）、網(wǎng)絡(luò)拓撲、資源（單板、網(wǎng)元）等進行管理，并分為故障管理、配置管理、計費管理、性能管理和安全性管理5類功能，如圖6所示。

網(wǎng)管模型主要由類和對象視圖構(gòu)成，要管理的物理或者邏輯模塊抽象成對象類，網(wǎng)管實現(xiàn)成對象實例。

2.3 網(wǎng)絡(luò)功能模型

網(wǎng)絡(luò)功能模型是具體問題具體分析的，目前沒有統(tǒng)一定義。以L3 VPN為例，功能模型包括：

·基本信息，如名稱、類型、接口

·接口信息，如接口狀態(tài)、IP地址、多媒體接入控制（MAC）地址、接口role、鏈路類型、虛擬局域網(wǎng)（VLAN）、proto等。

2.4網(wǎng)絡(luò)業(yè)務(wù)模型和網(wǎng)管模型的關(guān)系

網(wǎng)絡(luò)業(yè)務(wù)模型的操作專注業(yè)務(wù)需求，網(wǎng)絡(luò)功能模型專注于具體技術(shù)的配置、開通，網(wǎng)管模型的操作專注運維。

隨著網(wǎng)絡(luò)演進，業(yè)務(wù)靈活性的增加以及SDN的逐步部署，網(wǎng)管模型中和業(yè)務(wù)控制管理關(guān)系密切的模型，如業(yè)務(wù)配置、業(yè)務(wù)性能、業(yè)務(wù)故障以及部分網(wǎng)絡(luò)配置等管理，會由SDN 控制器支持的NBI實現(xiàn)。如在業(yè)務(wù)功能豐富的數(shù)據(jù)中心網(wǎng)絡(luò)中，SDN網(wǎng)管將逐漸側(cè)重于運維，更多利于業(yè)務(wù)控制和對時間敏感的傳統(tǒng)網(wǎng)管功能模型會通過SDN功能型NBI來實現(xiàn)。而廣域網(wǎng)（WAN）承載了各種復(fù)雜業(yè)務(wù)，仍有大量的傳統(tǒng)設(shè)備。

3 數(shù)據(jù)中心場景下的網(wǎng)絡(luò)模型

數(shù)據(jù)中心場景是目前模型和NBI相對完善的領(lǐng)域。在該場景下，云租戶或業(yè)務(wù)系統(tǒng)利用網(wǎng)絡(luò)模型訂購虛擬私有云服務(wù)，包括路由器、子網(wǎng)、安全組策略、彈性公網(wǎng)IP等基礎(chǔ)資源，以及防火墻（FW）、負載均衡（LB）、VPN等增值網(wǎng)絡(luò)服務(wù)資源。數(shù)據(jù)中心網(wǎng)絡(luò)模型如圖7所示。

數(shù)據(jù)中心場景下基于意圖的 API實例為：

（1）創(chuàng)建路由器API。

Post /v2.0/routers/{routerID}。

（2）創(chuàng)建子網(wǎng)API。

（a）Post /v2.0/networks；

（b）Post /v2.0/subnets，包括了地址段、掩碼、網(wǎng)關(guān)、動態(tài)主機配置協(xié)議（DHCP）使能等參數(shù)。

（3）路由器綁定子網(wǎng)。

Put /v2.0/routers/{routerID}/add_

router_interface。

數(shù)據(jù)中心網(wǎng)絡(luò)功能模型基于OpenStack Neutron，采用SDN plugin方式實現(xiàn)，如圖8所示。

功能型API實例為：

（1）租戶內(nèi)2層網(wǎng)絡(luò)隔離，使用vNet（不同 VXLAN或VLAN ID）。

（2）租戶間3層網(wǎng)絡(luò)隔離，除非明確配置，數(shù)據(jù)中心內(nèi)不允許跨租戶的流量訪問（即租戶間互訪流量建議通過廣域互通）。

（a）采用軟件方案時，使用虛擬路由器實現(xiàn)在路由層面的租戶隔離，每個租戶使用單獨的虛擬路由器；

（b）采用硬件方案時， 使用 VPN路由和轉(zhuǎn)發(fā)（VRF）實現(xiàn)在路由層面的租戶隔離。

（3）安全組隔離：通過虛擬交換機（vSW）上流表實現(xiàn)。

（4）FW/LB功能。

（a）采用軟件方案時，使用虛擬防火墻（vFW）或虛擬負載均衡（vLB）虛擬機實現(xiàn)；

（b）采用硬件方案時， 使用硬件設(shè)備虛擬出多實例實現(xiàn)。

4 業(yè)界標準化和開源社區(qū)進展

目前關(guān)注網(wǎng)絡(luò)模型及NBI的標準化組織主要包括開放網(wǎng)絡(luò)基金會（ONF）、國際互聯(lián)網(wǎng)工程任務(wù)組（IETF）和城域以太網(wǎng)論壇（MEF）。ONF作為SDN領(lǐng)域領(lǐng)先的標準組織，從2013年起就開始成立北向工作組，并通過幾次重組，現(xiàn)在在信息模型工程（IMP）工作組制定功能型 NBI。同時，ONF在OSSDN中成立了BOULDER項目，專注于模型和基于意圖的NBI設(shè)計，目前主要在討論基于角色的業(yè)務(wù)模型。

IETF前期定義了大量的網(wǎng)絡(luò)設(shè)備模型，和網(wǎng)絡(luò)業(yè)務(wù)模型、功能模型無關(guān)。目前IETF正在L3SM工作組制訂網(wǎng)絡(luò)業(yè)務(wù)模型相關(guān)的內(nèi)容，并在網(wǎng)絡(luò)移動（NEMO）工作組商討基于意圖的模型立項的可行性。

MEF正在開展業(yè)務(wù)需求分析，主要針對2層以太網(wǎng)業(yè)務(wù)的YANG模型定義，尚未開展具體業(yè)務(wù)信息模型的標準化。

除了標準化組織，各個開源社區(qū)也在積極實現(xiàn)和推動NBI，爭取形成事實標準，加速產(chǎn)業(yè)成熟。其中，OpenDaylight正在網(wǎng)絡(luò)意圖組成（NIC）、NEMO等項目中快速推進基于意圖的NBI；OpenStack的Congress項目以及ONOS都從自己的角度定義了北向接口。

5 展望

SDN正如其定義軟件定義網(wǎng)絡(luò)，其核心價值在于軟件。一方面在基礎(chǔ)設(shè)施層面，需要軟件化的控制器將網(wǎng)絡(luò)的控制權(quán)集中，實現(xiàn)全局的調(diào)度，優(yōu)化并提升網(wǎng)絡(luò)利用率。更重要的是基于這個基礎(chǔ)設(shè)施層，利用網(wǎng)絡(luò)的開放能力，定義各種各樣的網(wǎng)絡(luò)APP，挖掘網(wǎng)絡(luò)價值，能夠更加緊密地貼合業(yè)務(wù)的需求。從這個角度講，網(wǎng)絡(luò)更緊耦合于業(yè)務(wù)。

要做到這一點，標準的網(wǎng)絡(luò)模型和北向接口將成為重中之重。從業(yè)界格局看，標準化組織和開源組織在并行定義自己的模型和接口，但是各自又存在著不足。比如標準化組織流程長，定義出來的東西可能無法趕上越來越快的現(xiàn)網(wǎng)部署節(jié)奏；而開源組織短平快的方式缺少全局考慮，在新版本中經(jīng)常發(fā)生變化的情況屢見不鮮。因此在這個時間點上，運營商、大型廠商等應(yīng)聯(lián)合標準化和開源力量定義統(tǒng)一的模型和接口，推動產(chǎn)業(yè)鏈的成熟和統(tǒng)一。

參考文獻

[1] ONF. Intent Definition and Principles [R]. ONF， 2016

[2] ONF. NBI-North Bound Interface Framework： ONF2014.071.22 [R]. ONF， 2014