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



摘要:網絡模型及北向接口(NBI)是軟件定義網絡(SDN)中的關鍵問題。根據業(yè)界標準發(fā)展情況,提出了網絡模型分為網絡業(yè)務模型、網管模型、功能模型和網絡設備模型,并指出了不同的模型對應了不同的需求。認為運營商、大型廠商等應定義統(tǒng)一的SDN模型和接口,能夠推動產業(yè)鏈的成熟和統(tǒng)一。
關鍵詞: 網絡模型;業(yè)務模型;網管模型;功能模型
1 網絡模型定義和特征
1.1 多層次、多視角的網絡需求
不同角色的網絡用戶,對網絡的需求是不同的。比如對于一個公有云租戶,或者一個運營商網絡業(yè)務的設計者來說,更加關注的是網絡業(yè)務相關的指標(模型和接口),如何幫助他們快速定義自己的云網絡或者短時間內推出一個新業(yè)務,而不關注網絡實現(xiàn)的細節(jié)。對于網絡架構設計者和運維人員來說,如何快速定位故障,如何設計出更加穩(wěn)定、靈活和可擴展的網絡,進而具體選擇哪種網絡技術實現(xiàn)是更重要的問題。
因此,同一張網絡對應不同的需求,在模型和接口上也需要有層次的劃分,如圖1所示。
1.2 網絡的多層模型
網絡模型是多層次的,可以分為網絡業(yè)務模型、網管模型、功能模型和設備模型,如圖2所示。
網絡業(yè)務模型是網絡業(yè)務、應用驅動,面向用戶需求,與實現(xiàn)技術無關,與物理網絡無關的抽象模型。網絡業(yè)務模型主要包括邏輯網絡之間相互交互、網絡策略、業(yè)務服務等級(SLA)、業(yè)務調度策略等。
網管模型在軟件定義網絡(SDN)中,是專注于網絡的運維(OAM),運維需求驅動,面向具體運維技術相關的抽象模型,如網管模型能夠看到具體的交換機、路由器設備,以及端口信息。
網絡功能模型是具體網絡技術的功能模型抽象,如為了實現(xiàn)租戶隔離,將采用第3層虛擬專用網絡(L3 VPN)或第2層虛擬專用網絡(L2 VPN)等具體技術。
網絡設備模型指對各個廠家單臺網絡設備的抽象,如該設備路由表項采用何種隧道以及封裝、解封裝描述,服務質量(QoS)隊列描述,訪問控制策略,以及轉發(fā)協(xié)議采用OpenFlow、邊界網關協(xié)議(BGP)等。
網絡多層模型之間有著映射關系,業(yè)務模型中的具體指標會映射為網絡功能模型中的具體技術,部分業(yè)務還需要讀取網管模型中的監(jiān)測控制及告警指標,觸發(fā)調度策略生效。
1.3 網絡模型和SDN北向接口
北向接口(NBI)是網絡業(yè)務模型、網絡功能模型和網管模型的一種使用方式。
在SDN網絡中,控制器以上部分的接口稱為NBI,通常以RESTful應用程序編程接口(API)方式與控制器交互。目前SDN的NBI主要分為基于意圖的NBI和功能型NBI兩大類。
結合SDN網絡的層次架構,網絡模型有相對應的抽象。基于意圖的NBI對應了網絡業(yè)務模型,它主要用于描述SDN網絡使用者的需求,與技術無關,目前主要包括連接服務、資源需求、訪問控制、流處理、策略邏輯等幾部分內容,并且仍在完善中。功能型NBI對應了網絡功能模型和網管模型,面向具體的網絡功能,與網絡技術方案相關的NBI接口。這部分NBI在每個場景和案例中都會有區(qū)別,所以應結合場景逐一分析,目前也在完善中,如圖3所示[1]。
結合SDN的3層架構,可以對基于意圖的NBI、功能型NBI與網絡模型、SDN應用程序(APP)、SDN控制器以及網管的關系總結如下,具體如圖4所示。
(1)基于意圖的NBI是網絡業(yè)務模型所需要的輸入消息。業(yè)務模型可以在SDN APP內部實現(xiàn)(圖4中綠色區(qū)域),也可以在控制器上實現(xiàn)(圖4中黃色區(qū)域)。對應地,業(yè)務模型向功能模型的映射也分為在APP完成或控制器完成兩種方式,基于意圖的NBI也會終結在APP或控制器上[2]。
(2)功能型NBI是網管模型+網絡功能模型所需要的輸入消息。網絡功能模型主要在控制器上實現(xiàn),網管模型主要在運營支撐系統(tǒng)(OSS)網管上實現(xiàn)。其中控制器和OSS網管從目前的實現(xiàn)看,有完全獨立、互相重疊、完全包含3種方式。從近期看,控制器側重于業(yè)務下發(fā)和流量統(tǒng)計,網管側重于告警、性能監(jiān)測控制和日志統(tǒng)計,將會繼續(xù)并存。
1.4 網絡模型和NBI的描述形式
網絡模型主要用數據模型和協(xié)議的組合來描述,和網絡模型描述有關的協(xié)議和數據模型主要包括4種。
·NETCONF協(xié)議:網絡設備配置協(xié)議(RFC6241),包括消息層、操作層、內容層等。
·YANG數據模型:數據模型,為NETCONF提供通用數據格式,可以用統(tǒng)一建模語言(UML)、壓縮樹的方式展現(xiàn)。
·RESTful協(xié)議:基于HTTP協(xié)議,包括post、put、delete、get等消息。
·RESTCONF協(xié)議:用RESTful方式訪問YANG數據。
網絡模型的描述形式目前主要采用YANG數據模型或一系列API消息來描述。NBI所采用的協(xié)議主要為RESTCONF或RESTful API。
2 業(yè)務/網管/功能模型
2.1 網絡業(yè)務模型
網絡業(yè)務模型可以用對象、操作、結果(OOR)來描述,如圖5中所示,這種描述的方式也充分體現(xiàn)了業(yè)務描述與網絡細節(jié)無關的思想。圖5中業(yè)務模型表述的意思是:用戶在某個上下文環(huán)境中有基于意圖的表述。
首先對于對象來說,包括節(jié)點、連接和流信息,這些對象將作為網絡模型所描述的主體。
其次操作分為條件、動作和限制。在滿足帶寬、時延等網絡條件下,在匹配哪些節(jié)點之間不可互通等限制下,執(zhí)行標記優(yōu)先級,實現(xiàn)轉發(fā)的操作。
最后對于結果,包括期待結果和避免結果兩類,如預期保證帶寬利用率大于80%,或避免端到端時延大于100 ms等。
關于網絡業(yè)務模型,我們可采用3個例子加以描述。
例1:銀行多站點間基于意圖的需求
(1)各分支站點可以訪問位于總部站點的網絡服務器,不可以訪問位于總部站點的戶數據庫。
(a)目標:各分支、總部站點網絡服務器,總部站點用戶數據庫等;
(b)操作:可以訪問,或者不可以訪問。
(2)各站點間的帶寬利用率保持大于80%。
(a)目標:各站點間的帶寬資源;
(b)結果:期待大于80%。
例2:企業(yè)站點間視頻會議服務、數據傳輸基于意圖的需求
(1)站點間視頻會議優(yōu)先保證語音流暢,數據備份優(yōu)先級低傳輸。
(a)目標:站點間的視頻數據流、數據備份數據流;
(b)操作:設定優(yōu)先級。
(2)數據備份的數據內容進行日志記錄和安全識別。
(a)目標:數據備份數據流;
(b)操作:logging和流清處理。
例3:云計算中心網絡應用場景中的幾個需求描述
(1)需要構建2層、3層網絡。
(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è)務數據流。
(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 網管通用模型描述
根據電信國際電信聯(lián)盟電信管理網(ITU-T TMN)的定義,網管模型定義了標準q接口,對現(xiàn)有網絡中業(yè)務,如VPN、多協(xié)議標簽交換傳送應用(MPLS-TP)、網絡拓撲、資源(單板、網元)等進行管理,并分為故障管理、配置管理、計費管理、性能管理和安全性管理5類功能,如圖6所示。
網管模型主要由類和對象視圖構成,要管理的物理或者邏輯模塊抽象成對象類,網管實現(xiàn)成對象實例。
2.3 網絡功能模型
網絡功能模型是具體問題具體分析的,目前沒有統(tǒng)一定義。以L3 VPN為例,功能模型包括:
·基本信息,如名稱、類型、接口
·接口信息,如接口狀態(tài)、IP地址、多媒體接入控制(MAC)地址、接口role、鏈路類型、虛擬局域網(VLAN)、proto等。
2.4網絡業(yè)務模型和網管模型的關系
網絡業(yè)務模型的操作專注業(yè)務需求,網絡功能模型專注于具體技術的配置、開通,網管模型的操作專注運維。
隨著網絡演進,業(yè)務靈活性的增加以及SDN的逐步部署,網管模型中和業(yè)務控制管理關系密切的模型,如業(yè)務配置、業(yè)務性能、業(yè)務故障以及部分網絡配置等管理,會由SDN 控制器支持的NBI實現(xiàn)。如在業(yè)務功能豐富的數據中心網絡中,SDN網管將逐漸側重于運維,更多利于業(yè)務控制和對時間敏感的傳統(tǒng)網管功能模型會通過SDN功能型NBI來實現(xiàn)。而廣域網(WAN)承載了各種復雜業(yè)務,仍有大量的傳統(tǒng)設備。
3 數據中心場景下的網絡模型
數據中心場景是目前模型和NBI相對完善的領域。在該場景下,云租戶或業(yè)務系統(tǒng)利用網絡模型訂購虛擬私有云服務,包括路由器、子網、安全組策略、彈性公網IP等基礎資源,以及防火墻(FW)、負載均衡(LB)、VPN等增值網絡服務資源。數據中心網絡模型如圖7所示。
數據中心場景下基于意圖的 API實例為:
(1)創(chuàng)建路由器API。
Post /v2.0/routers/{routerID}。
(2)創(chuàng)建子網API。
(a)Post /v2.0/networks;
(b)Post /v2.0/subnets,包括了地址段、掩碼、網關、動態(tài)主機配置協(xié)議(DHCP)使能等參數。
(3)路由器綁定子網。
Put /v2.0/routers/{routerID}/add_
router_interface。
數據中心網絡功能模型基于OpenStack Neutron,采用SDN plugin方式實現(xiàn),如圖8所示。
功能型API實例為:
(1)租戶內2層網絡隔離,使用vNet(不同 VXLAN或VLAN ID)。
(2)租戶間3層網絡隔離,除非明確配置,數據中心內不允許跨租戶的流量訪問(即租戶間互訪流量建議通過廣域互通)。
(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ū)進展
目前關注網絡模型及NBI的標準化組織主要包括開放網絡基金會(ONF)、國際互聯(lián)網工程任務組(IETF)和城域以太網論壇(MEF)。ONF作為SDN領域領先的標準組織,從2013年起就開始成立北向工作組,并通過幾次重組,現(xiàn)在在信息模型工程(IMP)工作組制定功能型 NBI。同時,ONF在OSSDN中成立了BOULDER項目,專注于模型和基于意圖的NBI設計,目前主要在討論基于角色的業(yè)務模型。
IETF前期定義了大量的網絡設備模型,和網絡業(yè)務模型、功能模型無關。目前IETF正在L3SM工作組制訂網絡業(yè)務模型相關的內容,并在網絡移動(NEMO)工作組商討基于意圖的模型立項的可行性。
MEF正在開展業(yè)務需求分析,主要針對2層以太網業(yè)務的YANG模型定義,尚未開展具體業(yè)務信息模型的標準化。
除了標準化組織,各個開源社區(qū)也在積極實現(xiàn)和推動NBI,爭取形成事實標準,加速產業(yè)成熟。其中,OpenDaylight正在網絡意圖組成(NIC)、NEMO等項目中快速推進基于意圖的NBI;OpenStack的Congress項目以及ONOS都從自己的角度定義了北向接口。
5 展望
SDN正如其定義軟件定義網絡,其核心價值在于軟件。一方面在基礎設施層面,需要軟件化的控制器將網絡的控制權集中,實現(xiàn)全局的調度,優(yōu)化并提升網絡利用率。更重要的是基于這個基礎設施層,利用網絡的開放能力,定義各種各樣的網絡APP,挖掘網絡價值,能夠更加緊密地貼合業(yè)務的需求。從這個角度講,網絡更緊耦合于業(yè)務。
要做到這一點,標準的網絡模型和北向接口將成為重中之重。從業(yè)界格局看,標準化組織和開源組織在并行定義自己的模型和接口,但是各自又存在著不足。比如標準化組織流程長,定義出來的東西可能無法趕上越來越快的現(xiàn)網部署節(jié)奏;而開源組織短平快的方式缺少全局考慮,在新版本中經常發(fā)生變化的情況屢見不鮮。因此在這個時間點上,運營商、大型廠商等應聯(lián)合標準化和開源力量定義統(tǒng)一的模型和接口,推動產業(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