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

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

關鍵詞： 網(wǎng)絡模型；業(yè)務模型；網(wǎng)管模型；功能模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·NETCONF協(xié)議：網(wǎng)絡設備配置協(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)絡模型的描述形式目前主要采用YANG數(shù)據(jù)模型或一系列API消息來描述。NBI所采用的協(xié)議主要為RESTCONF或RESTful API。

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

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

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

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

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

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

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

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

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

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

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

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

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

（b）結果：期待大于80%。

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

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

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

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

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

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

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

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

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

（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è)務數(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)絡中業(yè)務，如VPN、多協(xié)議標簽交換傳送應用（MPLS-TP）、網(wǎng)絡拓撲、資源（單板、網(wǎng)元）等進行管理，并分為故障管理、配置管理、計費管理、性能管理和安全性管理5類功能，如圖6所示。

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

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

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

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

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

2.4網(wǎng)絡業(yè)務模型和網(wǎng)管模型的關系

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

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

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

數(shù)據(jù)中心場景是目前模型和NBI相對完善的領域。在該場景下，云租戶或業(yè)務系統(tǒng)利用網(wǎng)絡模型訂購虛擬私有云服務，包括路由器、子網(wǎng)、安全組策略、彈性公網(wǎng)IP等基礎資源，以及防火墻（FW）、負載均衡（LB）、VPN等增值網(wǎng)絡服務資源。數(shù)據(jù)中心網(wǎng)絡模型如圖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)關、動態(tài)主機配置協(xié)議（DHCP）使能等參數(shù)。

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

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

router_interface。

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

功能型API實例為：

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

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

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

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

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

（4）FW/LB功能。

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

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

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

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

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

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

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

5 展望

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

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