SDN的網絡模型及北向接口

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

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

關鍵詞： 網絡模型；業務模型；網管模型；功能模型

1 網絡模型定義和特征

1.1 多層次、多視角的網絡需求

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

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

1.2 網絡的多層模型

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

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

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

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

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

網絡多層模型之間有著映射關系，業務模型中的具體指標會映射為網絡功能模型中的具體技術，部分業務還需要讀取網管模型中的監測控制及告警指標，觸發調度策略生效。

1.3 網絡模型和SDN北向接口

北向接口（NBI）是網絡業務模型、網絡功能模型和網管模型的一種使用方式。

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

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

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

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

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

1.4 網絡模型和NBI的描述形式

網絡模型主要用數據模型和協議的組合來描述，和網絡模型描述有關的協議和數據模型主要包括4種。

·NETCONF協議：網絡設備配置協議（RFC6241），包括消息層、操作層、內容層等。

·YANG數據模型：數據模型，為NETCONF提供通用數據格式，可以用統一建模語言（UML）、壓縮樹的方式展現。

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

·RESTCONF協議：用RESTful方式訪問YANG數據。

網絡模型的描述形式目前主要采用YANG數據模型或一系列API消息來描述。NBI所采用的協議主要為RESTCONF或RESTful API。

2 業務/網管/功能模型

2.1 網絡業務模型

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

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

其次操作分為條件、動作和限制。在滿足帶寬、時延等網絡條件下，在匹配哪些節點之間不可互通等限制下，執行標記優先級，實現轉發的操作。

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

關于網絡業務模型，我們可采用3個例子加以描述。

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

（1）各分支站點可以訪問位于總部站點的網絡服務器，不可以訪問位于總部站點的戶數據庫。

（a）目標：各分支、總部站點網絡服務器，總部站點用戶數據庫等；

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

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

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

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

例2：企業站點間視頻會議服務、數據傳輸基于意圖的需求

（1）站點間視頻會議優先保證語音流暢，數據備份優先級低傳輸。

（a）目標：站點間的視頻數據流、數據備份數據流；

（b）操作：設定優先級。

（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）定義業務數據流。

（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 網管通用模型描述

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

網管模型主要由類和對象視圖構成，要管理的物理或者邏輯模塊抽象成對象類，網管實現成對象實例。

2.3 網絡功能模型

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

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

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

2.4網絡業務模型和網管模型的關系

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

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

3 數據中心場景下的網絡模型

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

數據中心場景下基于意圖的 API實例為：

（1）創建路由器API。

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

（2）創建子網API。

（a）Post /v2.0/networks；

（b）Post /v2.0/subnets，包括了地址段、掩碼、網關、動態主機配置協議（DHCP）使能等參數。

（3）路由器綁定子網。

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

router_interface。

數據中心網絡功能模型基于OpenStack Neutron，采用SDN plugin方式實現，如圖8所示。

功能型API實例為：

（1）租戶內2層網絡隔離，使用vNet（不同 VXLAN或VLAN ID）。

（2）租戶間3層網絡隔離，除非明確配置，數據中心內不允許跨租戶的流量訪問（即租戶間互訪流量建議通過廣域互通）。

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

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

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

（4）FW/LB功能。

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

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

4 業界標準化和開源社區進展

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

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

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

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

5 展望

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

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

參考文獻

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

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