張 巖 張忠平 張曼君
軟件定義網絡(Software Defined Network, SDN)是一種新型未來網絡架構,SDN將網絡的控制與轉發分離,實現了網絡流量的靈活管理和調度[1]。控制平面是SDN網絡的核心架構,控制平面以上與網絡應用交互的接口被稱為SDN北向接口(Northbound Interface, NBI),之下對數據平面的接口稱為南向接口(Southbound Interface, SBI)。SDN北向接口確保了SDN控制器及其以下部分作為網絡驅動供上層SDN應用調用,是技術能力與業務需求的結合點。
SDN北向接口可進行網絡抽象和網絡虛擬化。另外,北向接口還可以實現基礎的網絡功能,同時向編排系統提供網絡管理的功能[2]。基于用戶意圖的北向接口是最近兩年來興起的一種高度抽象的且概括度極高的北向接口通用語言技術,多個組織和廠商都在積極跟進研究。本文先介紹Intent NBI的基本概念,接著從標準化和開源組織兩個方面介紹Intent NBI的進展,并重點介紹具有代表性的一些項目。
在最近的北向接口研究中,研究者希望用一種通用的語言描述網絡控制接口,多個組織開始在SDN北向接口推動一種新的應用程序接口,這種應用程序只需要制定通信需求,并且獨立于底層網絡的各種細節,這個新的應用程序接口稱為“基于Intent的北向接口模型(Intent NBI)”。在這個模型中, SDN控制器決定了如何將用戶Intent解析到網絡基礎設施上,使網絡表現為用戶期望的方式。
Intent NBI是一種與網絡實現技術無關的北向接口,不需要看到VPN、MPLS、路由協議等技術,它通過一種聲明式的表達來體現用戶的意圖,是一種自頂向下,從需求視角對網絡對象與能力的抽象。Intent NBI簡單易用,通過對實現相關信息的隱藏,可以降低用戶使用的門檻,促進應用開發的豐富性;且與平臺實現無關,增強了應用的可移植性。由于用戶希望看到更易用且功能更強的基于Intent的SDN系統,許多研究小組現在開始與標準組織和開源社區一起工作,致力于打造通用的基于Intent NBI的SDN網絡。通過實施涵蓋多個控制器、供應商和多種技術的通用北向接口技術,為網絡運營商部署基于Intent的解決方案鋪平道路。
目前,北向接口的標準制定成為SDN領域中占領先機的關鍵,目前SDN的各種控制器都有自己專屬的北向接口且開放程度不一,用戶很難將他們全部都掌握。ONF和IETF是對SDN進行標準化的最重要的兩大標準化組織,已有一些標準化的工作[3-4]。
主導SDN/OpenFlow的標準組織ONF于2013年10月成立SDN北向接口工作小組(NBI-WG),旨在通過北向接口的標準化以加速SDN的商用。ONF發現這些控制器提供的北向接口非常混亂,時常會給用戶帶來很大的困擾,于是ONF決定將SDN北向接口標準化。該工作組成立的另外一個原因,就是防止控制器通過提供殺手級應用形成廠商鎖定的局面。
NBI小組制定了工作組的工作目標和范圍[5]:定義一個基礎NBI通用的SDN控制器能力以及功能,并開發NBI信息模型,如圖1所示,以一種編程語言中立的方式提供建議性的代碼,僅僅作為數據標準模型提供出來,具體數據模型的實現由各個研究團隊按照此模型自行設計開發。

圖1 ONF定義的Intent NBI的SDN架構
兩個與SDN相關的工作組存在于IETF前期,分別是轉發與控制分離組ForCES(Forwarding and Control Element Separation)和應用層流量優化工作組ALTO(Application-layer Traffic Optimization),隨著SDN的進化,IETF開始涉及北向接口的標準化工作,SFC(Service Function Chain)工作組于2013年成立,其目的是希望確立各網絡服務整合的體系架構及其應用接口,其對外控制接口是SDN北向接口的重要組成部分。
Intent NBI的目標用戶為運營商的業務設計人員,快速構建新的網絡業務組合與服務IT的管理、開發人員。Intent NBI將網絡資源與能力作為一部分集成到IT服務中,目前在SDN北向接口研究開發領域最活躍的是OpenStack和OpenDayLight,各個廠商在這兩大開源組織中均有一些北向接口立項,下面分別介紹這兩個組織中的一些研究項目。
OpenStack作為SDN控制器的一個重要應用,其由多個組件組成,與SDN網絡北向接口相關的組件有基于Neutron的GBP以及Congress組件。
1)GBP(Group Based Policy for OpenStack)。GBPforOpenStack[6]由Cisco和IBM主導,是在OpenStack架構中增加的一個SDN北向接口的開源項目,它是一個OpenStack的API框架,提供了一個意向性驅動模型,旨在以獨立于底層基礎架構的方式描述應用需求。GBP通過包括Horizon Extensions(基于組策略的UI)、Heat(基于組策略自動化)和CLI(基于組策略客戶端)等多種OpenStack的接口,提供了一個新的策略API,它被設計作為Neutron頂部的一個層(以及將來其他的OpenStack服務),如圖2所示。

圖2 GBP在Openstack中的位置
GBP認為當前的Neutron API只是在連接層面描述了業務的訪問與隔離需求,既不直觀,也不靈活。GBP將策略作用的對象稱為Group,引入了策略規則(Policy Rule)來描述Group之間的連通性、安全性和網絡服務,而這些策略是一些規則的集合,每個規則規定了兩個Group之間流量的行為,比如重定向、業務鏈等,其模型為圖3所示。GBP彌補了Neutron只能靜態地描述虛擬機之間的互通隔離的缺陷,并且解決了業務開發者和網絡技術人員之間的不對稱問題。

圖3 GBP在Openstack中的模型
GBP使用戶能夠指定不同層次應用程序之間的關系,使其非常容易擴展;同時,GBP從網絡的具體要求(IP使用地址范圍、繪制網絡邊界、分配VIPS等)分離出應用的安全性要求,這使得應用程序、安全性和操作團隊既相互獨立,又能協助運行;此外,GBP提供了一個抽象的網絡服務,允許用戶鏈接多個網絡服務,并作為應用程序部署的一部分來描述需求。
2)Congress。Congress[7]是VMware公司在2014年啟動的嵌入在OpenStack中一個項目,可以為任何云服務提供Policy as a Service(策略即服務)的功能,目的是為動態的基礎設施提供管理和合規性,實現IT業務快速自動部署。圖4為Congress在OpenStack的位置。

圖4 Congress在Openstack中的位置
由于當前的IT服務一直被各種條件制約,因此需要加入符合業務的策略。一直以來,策略總是手動配置的,例如由某人發送一封電子郵件,要求一個應用程序被添加到網絡,由特定的防火墻條目保證安全,然后連接到一個約定的存儲中等等。在云時代,IT變得更加靈活敏捷,用戶期望快捷的服務傳遞,但是由管理團隊提供的響應很難達到快速響應的水平,因此人工的方法是不靈活的。Congress認為云服務可以展示為“表”,當前Congress使用的策略語言是Datalog語言,Datalog常用于數據域查詢語言領域,與SQL(結構化查詢語言)語言相似,但和傳統的編程語言更接近。Congress用一種更加抽象的方式描述OpenStack各組件之間哪些狀態是允許的,哪些是不允許的。
Congress允許云的管理者和租戶使用高層級的通用陳述性語言來描述業務邏輯,例如:“應用A只被允許與應用B通信”或是“如果租戶A是group B的一部分,租戶A的虛機應該獲得一個公網連接”等等業務邏輯;Congress中策略的執行包括主動的(在行為發生之前防止違規)、被動的(行為發生后糾正違規)以及交互的(為管理員提供深入了解策略和違規行為,如識別違規行為、解釋其原因、計算潛在的調控措施等)執行。
OpenDayLight項目在2013年初由Linux協會聯合業內18家企業(包括Cisco、Juniper、Broadcom等多家傳統網絡的巨頭公司)創立,旨在推出一個開源的通用SDN平臺。該項目采用模型驅動架構抽象出控制器各組件的南北向API以及各組件的數據結構, 其設計目標是降低網絡運營的復雜度,擴展現有網絡架構中硬件的生命期,同時還能夠支持SDN新業務和新能力的創新。OpenDayLight希望能夠提供開放的北向API,并使用YANG數據建模語言為服務和數據建模,與北向接口相關的組件有GBP、NIC、NEMO等。
1)GBP(Group Based Policy for OpenDayLight)。GBP for OpenDayLight[8]的架構模型如圖5所示。與OpenStack中有所不同的是,OpenDayLight中的GBP將策略作用的最底層抽象命名為Endpoint,可以對應物理網絡中的特定設備,也可以是虛擬機接口、物理接口或其他網絡設備。將具有相同策略的Endpoint組合成為Group。Contract是不同Group之間的協定,這種協定包含一些規則,每個規則規定了兩個Group之間流量的行為。

圖5 GBP在OpenDaylight中的模型
2)NIC(Network Intent Composition)。NIC[9]是2014年底由HP牽頭向OpenDayLight提交的項目,目的是提供一種通用的抽象的策略語法,讓用戶很方便地描述自己的意圖,是比GBP更高層次、更接近用戶的模型。NIC將Intent通過一個新的北向接口表現給控制器,它提供了廣義和抽象的策略語義代替類似OpenFlow的流規則;NIC允許用描述的方式來獲得在基礎設施中的需要是什么,不描述如何提供不同的服務;NIC利用現有OpenDaylight網絡服務功能和南向插件來控制虛擬和物理網絡設備,而且NIC被設計成與協議無關,因此任何控制協議都可以使用。NIC試圖逐步從少量簡單的用例構建支持幾乎任何可以想象的用例。NIC可以創建一個可擴展的NBI,用來提供以業務為中心的Intent描述,并在可用設備中自動化配置實現,也可以解決沖突的Intent,以及優化規則得到更好的資源利用率及網絡性能。
3)NEMO(Network Model)。NEMO[10]作為OpenDayLight中的一個項目,是華為推出的一種新的基于Intent的SDN北向接口語言。NEMO基于DSL(Domain Specific Language,領域特定語言)的抽象網絡模型以及結論性的操作模式。以一種新的語言形式來提供NBI。不像基于功能的那些深奧難懂的北向接口應用,NEMO只提供了很少的關鍵字和表達語句,就可以使網絡用戶或者網絡應用可以直觀描述其對網絡資源的需求、服務、邏輯操作等等。NEMO的表達可以被NEMO語言引擎解釋和執行。
NEMO的實現設計參考了SQL的成功案例,簡化復雜的數據操作到一個統一和直觀方式的形式語言。應用程序不定義數據存儲和數據操作的底層機制,只描述期望的數據存儲和操作,然后得到結果。作為一個數據域DSL,SQL是簡單直觀的,可以嵌入到應用程序中,這正是當前SDN北向接口所需要的。
NEMO定義了用戶的Intent模型,在這種Intent模型下,用戶是發起者和Intent的所有者。 NEMO項目創建每個租戶隔離的獨立虛擬網絡空間,在自己的虛擬網絡空間中,租戶可以部署NEMO模型定義的元素與服務。用戶的Intent是由三部分組成,即對象、操作和結果,用戶可以使用模型描述他們的Intent[11]。
對象(Object)指的是在網絡中的網絡資源和服務。它們是整個網絡的基礎,并且必須首先創建;操作(Operation)表達調整網絡資源或服務的行為;結果(Result)用來限制網絡資源和服務的最終狀態。Operation和Result的作用目標是Object。圖6給出了NEMO的Intent模型。

圖6 NEMO的Intent模型
NEMO相對GBP出現較晚,GBP已經在控制器中有所應用。NEMO與GBP的不同之處在于[12]:1)GBP使用策略來控制網絡流的行為,但NEMO需要處理整個網絡系統,需要創建和控制節點及鏈路的能力;2)GBP只檢查兩個終端系統之間的合同,而不考慮對路徑的要求,但NEMO會考慮整個路徑;3)GBP運行在應用程序接口以下,不允許應用程序直接表達需求,但NEMO使用表達基于Intent驅動的API,由用戶直接表達需求;NEMO提供的應用程序可以實現一個簡單的界面,并提供NEMO引擎以能夠控制計算、存儲和網絡。
SDN控制器通過南向接口關聯轉發平面,使用戶不用接觸到底層網絡的細節;通過北向接口與上層應用交互,提供更高層次的業務邏輯抽象。SDN的最終價值在于根據豐富的上層應用需求更加靈活地部署和控制網絡,而北向接口是否友好完備,直接決定著控制器的生命力,是控制器能否獲得大規模應用的決定因素。基于Intent的北向接口技術簡化了網絡管理和新業務建立,對業務設計者不再要求具備高深的網絡專業知識,僅需要明確業務的目的和流程以及對網絡資源的需求,業務的底層映射由基于Intent NBI的控制器引擎完成,因此,基于Intent的北向接口技術應該是SDN實現未來應用創新和部署時不可或缺的技術。
參考文獻
[1]黃韜,劉江,魏亮,等.軟件定義網絡核心原理與應用實踐[M].北京:人民郵電出版社, 2014
[2]程瑩,張云勇.SDN應用及北向接口技術研究[J].信息通信技術,2014,8(1):36-39
[3]王雪偉.SDN北向接口技術發展[J].電信網技術,2015,(4):19-23
[4]龐濤.SDN北向接口發展現狀與趨勢研究[J].互聯網天地,2014,(9):50-56
[5]Michael C, Hemanth R.Group-Based Policy for OpenStack[EB/OL].[2015-12-10].http://www.cisco.com/c/en/us/solutions/collateral/data-centervirtualization/application-centric-infrastructure/whitepaper-c11-733126.html
[6]Christopher J.Intent NBI - Definition and Principles[R].Version V3.August, 2015
[7]Congress[EB/OL].[2015-12-10].https://wiki.openstack.org/wiki/Congress
[8]OpenDaylight User Guide[R].2015
[9]Network Intent Composition[EB/OL].[2015-12-10].https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition
[10]NEMO[EB/OL].[2015-12-10].https://wiki.opendaylight.org/view/NEMO:Main
[11]Xia Y, Zhou T, Zhang Y, et al.Intent Common Information Model[R].IETF draft.2015
[12]NeMo compared with Yang and Open Daylight Group Policy[EB/OL].[2015-12-10].http://www.nemo-project.net/nemo-vs-ODL-group-policy-v1.pdf