網(wǎng)絡(luò)編排技術(shù)進(jìn)展研究

張 晨 黃 韜 張 嬌 劉 江

背景

編排一詞最早出現(xiàn)在藝術(shù)領(lǐng)域，指的是按照一定目的對音樂、舞蹈等表現(xiàn)元素進(jìn)行排列，以達(dá)到最佳的藝術(shù)效果。而網(wǎng)絡(luò)中的編排一詞則指的是對于服務(wù)器、存儲設(shè)備、網(wǎng)絡(luò)轉(zhuǎn)發(fā)與網(wǎng)絡(luò)服務(wù)設(shè)備進(jìn)行排列，以滿足網(wǎng)絡(luò)用戶或管理員的需求。網(wǎng)絡(luò)中的編排可以分為底層資源的編排以及高層業(yè)務(wù)的編排，其中資源編排側(cè)重于對設(shè)備進(jìn)行調(diào)度，業(yè)務(wù)編排側(cè)重于對工作流程的規(guī)范，業(yè)務(wù)編排往往要依賴于資源編排來實(shí)現(xiàn)。

傳統(tǒng)網(wǎng)絡(luò)中，編排的工作主要由管理人員手工完成。在實(shí)際生產(chǎn)環(huán)境中，一個(gè)業(yè)務(wù)的開通往往需要不同領(lǐng)域的專業(yè)人員投入大量時(shí)間，短則一周半個(gè)月，長則數(shù)月半年。這不僅造成大量的運(yùn)維開銷，而且設(shè)備配置上的變更也難以跟上需求的快速變更，導(dǎo)致新業(yè)務(wù)遲遲不能上線?，F(xiàn)網(wǎng)中，運(yùn)營商的運(yùn)營支撐系統(tǒng)(Operation Support System, OSS)具備對高層業(yè)務(wù)進(jìn)行編排的能力，不過由于傳統(tǒng)網(wǎng)絡(luò)設(shè)備的能力不夠開放，OSS對網(wǎng)絡(luò)設(shè)備只能進(jìn)行一些簡單的管理和操作，業(yè)務(wù)的最終交付仍需要網(wǎng)絡(luò)專業(yè)人員進(jìn)行配置和調(diào)測。

網(wǎng)絡(luò)自動化編排技術(shù)的變革首先發(fā)生在云計(jì)算領(lǐng)域。近年來，云計(jì)算的商業(yè)模式逐漸成熟，一切即服務(wù)(Everything as a Service, XaaS)的愿景要求IT基礎(chǔ)設(shè)施能夠按需地為云用戶提供服務(wù)。在此背景下，虛擬化技術(shù)也得到飛速發(fā)展。虛擬化技術(shù)通過對服務(wù)器、存儲設(shè)備、網(wǎng)絡(luò)設(shè)備的能力進(jìn)行抽象，將硬件設(shè)備軟化為計(jì)算、存儲、網(wǎng)絡(luò)的資源池，這些資源都能夠通過開放接口進(jìn)行靈活調(diào)度，為實(shí)現(xiàn)物理資源的編排提供技術(shù)基礎(chǔ)。同時(shí)，基于對物理資源的調(diào)度，在云中能夠?qū)崿F(xiàn)豐富的高層業(yè)務(wù)編排邏輯。目前，以Vmware、Microsoft為代表的IT服務(wù)商都形成了較為完整的云解決方案[1-2]，開源社區(qū)也緊跟廠商的腳步，以O(shè)penStack[3]為代表的開源云管理平臺自推出以來迅速風(fēng)靡全球。

然而在云中，網(wǎng)絡(luò)資源的開放性仍然有所欠缺，相比于計(jì)算、存儲虛擬化的縱深式發(fā)展，網(wǎng)絡(luò)即服務(wù)(Network as a Service, NaaS)的發(fā)展則相對滯后。為填補(bǔ)網(wǎng)絡(luò)資源在開放性上的不足，軟件定義網(wǎng)絡(luò)(Software Defined Networking, SDN)成為了網(wǎng)絡(luò)界近幾年來的焦點(diǎn)。SDN將傳統(tǒng)網(wǎng)絡(luò)設(shè)備中本地嵌入的控制邏輯提取到遠(yuǎn)端，并提倡通過開放的接口實(shí)現(xiàn)網(wǎng)絡(luò)的可編程性[4]。自2008年提出以來，SDN的概念已經(jīng)在云數(shù)據(jù)中心中得到廣泛應(yīng)用，SDN搭配OpenStack已經(jīng)成為云數(shù)據(jù)中心的主流趨勢。云數(shù)據(jù)中心是SDN的典型應(yīng)用場景，但SDN不限于用作云數(shù)據(jù)中心網(wǎng)絡(luò)，在企業(yè)網(wǎng)、廣域網(wǎng)中SDN也正在逐步落地。

SDN側(cè)重于對L2～L3中的網(wǎng)絡(luò)連接進(jìn)行虛擬化，而網(wǎng)絡(luò)功能虛擬化(Network Function Virtualization, NFV)則側(cè)重于對L4～L7中的網(wǎng)絡(luò)服務(wù)(如防火墻、負(fù)載均衡等)進(jìn)行虛擬化。NFV提出將專用硬件設(shè)施進(jìn)行軟件化，運(yùn)行在通用服務(wù)器、通用存儲和通用轉(zhuǎn)發(fā)設(shè)備中，從而實(shí)現(xiàn)網(wǎng)絡(luò)功能服務(wù)的靈活部署，并降低CAPEX和OPEX[5]。如果說SDN結(jié)合云管理平臺提供了對計(jì)算、存儲、網(wǎng)絡(luò)連接的編排調(diào)度能力，那么NFV則提供了對于網(wǎng)絡(luò)服務(wù)的編排調(diào)度能力。三者的有機(jī)結(jié)合，將共同描繪一張端到端、全程全網(wǎng)編排管理的新一代網(wǎng)絡(luò)藍(lán)圖。

基于上述愿景，業(yè)界正在完善云、SDN和NFV相關(guān)技術(shù)，對于全自動化的網(wǎng)絡(luò)編排進(jìn)行著不斷嘗試。

1 云管理平臺中的編排

云計(jì)算的一個(gè)典型特點(diǎn)是集中式管理與控制。云中的各類資源和模塊都實(shí)現(xiàn)了數(shù)據(jù)和控制層面的分離，云管理平臺對底層的計(jì)算、存儲、網(wǎng)絡(luò)資源進(jìn)行統(tǒng)一調(diào)度，以實(shí)現(xiàn)底層資源的編排。在此基礎(chǔ)上，云管理平臺往往通過提供標(biāo)準(zhǔn)、開放的模板來簡化業(yè)務(wù)部署、業(yè)務(wù)交付和新型業(yè)務(wù)的設(shè)計(jì)，從而實(shí)現(xiàn)高層業(yè)務(wù)的編排。

1.1 Vmware vCloud

vCloud Suite[1]是Vmware公司提供的云數(shù)據(jù)中心解決方案，能夠?qū)崿F(xiàn)數(shù)據(jù)中心的自動化控制，硬件配置通過軟件系統(tǒng)進(jìn)行維護(hù)。vCloud目前已經(jīng)更新至6.0版本，其產(chǎn)品架構(gòu)如圖1所示。其中，vSphere組件負(fù)責(zé)進(jìn)行服務(wù)器虛擬化和對虛擬計(jì)算資源的管理調(diào)度，Virtual SAN組件負(fù)責(zé)對存儲進(jìn)行虛擬化和對虛擬存儲資源的管理調(diào)度，Site Recovery Manager組件負(fù)責(zé)提供基于策略的云高可用性。在網(wǎng)絡(luò)虛擬化技術(shù)方面，vCloud自研的虛擬分布式交換機(jī)(Virtual Distuibuted Switch, VDS)使用了VLAN技術(shù)，在收購SDN創(chuàng)業(yè)公司Nicira后，Vmware將Nicira的網(wǎng)絡(luò)虛擬化平臺(Network Virtualization Platform, NVP)和開源虛擬交換機(jī)(OpenvSwitch, OVS)集成為目前vCloud中的NSX組件，基于Overlay技術(shù)實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化并對虛擬網(wǎng)絡(luò)資源進(jìn)行管理調(diào)度，在不同的租戶間提供安全策略和隔離性。上述組件共同提供云數(shù)據(jù)中心的基礎(chǔ)設(shè)施即服務(wù)(Infrastructure as a Service, IaaS)的能力。在此基礎(chǔ)上，vRealize Automation/Operations/Business共同提供了云管理能力，其中vRealize Automation提供一個(gè)安全門戶，已授權(quán)的管理員、開發(fā)人員或業(yè)務(wù)用戶可以請求新的云服務(wù)，vRealize Automation會觸發(fā)vRealize Orchestrator，Orchestrator支持對云中的工作流程進(jìn)行標(biāo)準(zhǔn)化，并通過調(diào)用IaaS接口來自動部署云服務(wù)，實(shí)現(xiàn)Vmware中的高層業(yè)務(wù)編排。vCloud是Vmware的商用產(chǎn)品，并提供與OpenStack等開源云平臺項(xiàng)目的對接。

圖1 Vmware Cloud Suite v6.0架構(gòu)圖[1]

1.2 OpenStack

OpenStack是一個(gè)開源的云計(jì)算平臺，可以大規(guī)模地管理計(jì)算資源、存儲資源、網(wǎng)絡(luò)資源等基礎(chǔ)架構(gòu)。OpenStack是由Rackspace Cloud和NASA在2010年發(fā)起的，自成立以來，OpenStack已經(jīng)獲得業(yè)界廣泛認(rèn)可，目前，已經(jīng)迭代到第12個(gè)發(fā)行版本—Liberty。OpenStack Liberty的組件結(jié)構(gòu)如圖2所示，其中Nova對計(jì)算資源進(jìn)行編排，提供虛擬機(jī)的全生命周期管理功能，Cinder和Swift對存儲資源進(jìn)行編排，分別提供塊存儲和對象存儲的能力，Neutron對網(wǎng)絡(luò)資源進(jìn)行編排，以插件的形式支持多類網(wǎng)絡(luò)資源的互聯(lián)互通。其它組件如Horizon提供面板控制、Keystone提供身份認(rèn)證、Glance提供鏡像等等。Heat是OpenStack中的業(yè)務(wù)編排組件，通過接收面板的調(diào)用，或者根據(jù)模板文件中的描述，將服務(wù)請求解析為對各種類型資源的請求，然后通過調(diào)用Nova、Neutron等組件的接口來完成部署。Heat還支持資源的彈性伸縮，以按需服務(wù)于云用戶。

圖2 OpenStack組件結(jié)構(gòu)圖

目前，在Liberty版本中，Neutron作為OpenStack中管理網(wǎng)絡(luò)的組件，能夠接收前端傳送過來的業(yè)務(wù)請求，或者接收開放的Neutron API的調(diào)用，據(jù)此對計(jì)算節(jié)點(diǎn)HyperVisor中的虛擬轉(zhuǎn)發(fā)設(shè)備(如Linux Bridge和OpenvSwitch)進(jìn)行控制，OpenStack在設(shè)計(jì)之初采用Nova-network對網(wǎng)絡(luò)進(jìn)行管理，支持簡單的Flat DHCP 2層網(wǎng)絡(luò)以及VLAN網(wǎng)絡(luò)，不過不提供面向租戶的開放API，后續(xù)OpenStack在Folsom版本中推出了專用的網(wǎng)絡(luò)組件Quantum，支持Overlay技術(shù)，并提供面向租戶的開放式API。Quantum還支持廠商開發(fā)各家的設(shè)備驅(qū)動，不過一些基本功能(如租戶網(wǎng)絡(luò)的數(shù)據(jù)庫)也需要各個(gè)廠商自己獨(dú)立開發(fā)。Openstack在Havana版本上將Quantum更名為Neutron，并開發(fā)了ML2(Modular Layer 2，模塊化的2層網(wǎng)絡(luò))插件記錄租戶網(wǎng)絡(luò)的一些基本信息(如網(wǎng)絡(luò)類型是VLAN還是VxLAN等)，各個(gè)廠家基于ML2進(jìn)行設(shè)備驅(qū)動的插件開發(fā)。

1.3 CloudStack

CloudStack[6]是一個(gè)開源云計(jì)算解決方案，最初由Cloud.com公司開發(fā)，Citrix公司在2011年收購Cloud.com后，將全部代碼開源，目前已經(jīng)發(fā)布了4.6版本。CloudStack的架構(gòu)如圖3所示，可以看到它與OpenStack的主要功能類似，通過Orchestration Engine對業(yè)務(wù)進(jìn)行編排，Orchestration Engine通過與Compute Controller、Network Controller和Storage Controller進(jìn)行交互來編排底層的資源。不過與OpenStack的分布式服務(wù)架構(gòu)不同，CloudStack采用了集中式的單體架構(gòu)，整個(gè)平臺只有一個(gè)項(xiàng)目，不同模塊之間通過本地調(diào)用進(jìn)行交互，在一臺主機(jī)上就可以完成平臺的部署。CloudStack中的Network Controller支持基于VLAN、Overlay等技術(shù)實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化。

圖3 CloudStack架構(gòu)圖

2 SDN網(wǎng)絡(luò)中的編排

SDN中控制平面與轉(zhuǎn)發(fā)平面分離，設(shè)備的轉(zhuǎn)發(fā)邏輯由遠(yuǎn)端集中式的控制器實(shí)現(xiàn)，解決了傳統(tǒng)網(wǎng)絡(luò)設(shè)備的嵌入式控制不夠靈活、分布式控制無法全局最優(yōu)等問題。SDN中編排的概念很廣泛，控制器通過南向協(xié)議控制設(shè)備的轉(zhuǎn)發(fā)可以看做是對底層資源進(jìn)行編排，應(yīng)用程序通過北向接口調(diào)用控制器的功能可以看做是對業(yè)務(wù)的編排。關(guān)于控制器如何對底層資源進(jìn)行編排，本節(jié)不做詳細(xì)的描述，下面主要對SDN中的業(yè)務(wù)編排進(jìn)行介紹。

2.1 SDN高級編程語言

計(jì)算機(jī)編程語言的發(fā)展經(jīng)歷了晦澀的機(jī)器語言、匯編語言等階段，最終發(fā)展出易于理解的高級語言。同樣，對于SDN來說，高度用戶化的編程語言能夠屏蔽底層設(shè)備接口的復(fù)雜性，使得SDN應(yīng)用開發(fā)人員可以注重于業(yè)務(wù)邏輯，而非底層硬件實(shí)現(xiàn)，是推動SDN發(fā)展的重要技術(shù)。普林斯頓大學(xué)和康奈爾大學(xué)的研究人員分別在2011年和2013年提出Frentic[7]和Pyretic[8]，這兩個(gè)語言的研發(fā)都在Frenetic Project的整體框架中進(jìn)行，主要在網(wǎng)絡(luò)流量監(jiān)測、轉(zhuǎn)發(fā)策略指定、一致性策略更新和服務(wù)質(zhì)量等方面進(jìn)行了高層業(yè)務(wù)邏輯的抽象。Frenetic提供了并行的模型，進(jìn)入控制器的每一個(gè)數(shù)據(jù)包都由一個(gè)對應(yīng)的策略模塊處理，多個(gè)條件組合形成的策略也是并行執(zhí)行的。Pyretic則在Frenetic的基礎(chǔ)上支持策略的串行執(zhí)行，以及串行并行相結(jié)合的混合模型。耶魯大學(xué)的研究人員在2013年提出了Maple[9]，相比于Frentic和Pyretic對策略模型的關(guān)注，Maple則能夠通過高效的算法將集中式的業(yè)務(wù)策略映射為分布式部署的流表，并支持多核處理，提高了編譯的性能。

P4[10]是斯坦福大學(xué)和普林斯頓大學(xué)于2015年發(fā)布的SDN編程語言項(xiàng)目，起源于2014年的一篇Sigcomm論文。P4是一種數(shù)據(jù)平面的編程語言，旨在徹底打破現(xiàn)有協(xié)議對于網(wǎng)絡(luò)的限制，基于P4的用戶可以任意地指定字段的解析、匹配與處理動作，這也是目前能夠看到的SDN最為理想的形態(tài)。除了底層的數(shù)據(jù)平面編程，P4也提供了高層的邏輯，編程者能夠方便地指定與設(shè)備類型無關(guān)的轉(zhuǎn)發(fā)表匹配范式。P4直接打通了高層業(yè)務(wù)邏輯和底層轉(zhuǎn)發(fā)資源，被寄希望作為OpenFlow 2.0，不過P4這種接近于終極的靈活性也對芯片的設(shè)計(jì)要求極高，短期內(nèi)還很難進(jìn)行商用。

上述的SDN編程語言均采用自底向上模型驅(qū)動的設(shè)計(jì)方式，雖然用戶無需關(guān)注底層資源，但語言本身仍關(guān)注網(wǎng)絡(luò)配置和實(shí)現(xiàn)的細(xì)節(jié)。相比之下，SDN編程語言還可以采用自頂向下業(yè)務(wù)驅(qū)動的設(shè)計(jì)方式，從業(yè)務(wù)行為和應(yīng)用需求的角度出發(fā)，語言本身無需關(guān)注底層實(shí)現(xiàn)細(xì)節(jié)，從而使得北向接口和南向協(xié)議能夠完全解耦。開源項(xiàng)目ONOS[11]的Intent設(shè)計(jì)，OpenDaylight[12]的GBP、NEMO設(shè)計(jì)均采用了這種思路。

2.2 Cisco ACI策略引擎

ACI[13](Application Centric Infrastructure，以應(yīng)用為中心)是思科推出的SDN解決方案，通過應(yīng)用驅(qū)動型策略模式簡化自動化工作，同時(shí)能夠利用實(shí)時(shí)的應(yīng)用運(yùn)行狀況監(jiān)控實(shí)現(xiàn)集中式可視性。ACI策略引擎實(shí)現(xiàn)了應(yīng)用程序需求策略的具體要求，管理著整個(gè)ACI網(wǎng)絡(luò)，包括基礎(chǔ)架構(gòu)、驗(yàn)證授權(quán)、安全、服務(wù)、應(yīng)用和故障排查等，ACI策略引擎的模型如圖4所示。APIC作為控制器在ACI網(wǎng)絡(luò)中自動將策略部署到ACI設(shè)備中，對包括應(yīng)用程序設(shè)置、安全策略、租戶子網(wǎng)等進(jìn)行自動化實(shí)現(xiàn)。ACI改變了思科傳統(tǒng)以硬件為核心的產(chǎn)品和服務(wù)策略，它的核心基礎(chǔ)是以軟件方式管理和運(yùn)營網(wǎng)絡(luò)，不過ACI的實(shí)現(xiàn)仍主要基于思科硬件設(shè)備如Nexus交換機(jī)和定制化的ASIC商用芯片。

圖4 ACI策略引擎模型[13]

2.3 華為Netmatrix編排系統(tǒng)

Netmatrix[14]是華為2013年推出的SDN/NFV編排系統(tǒng)，它獨(dú)立于SDN控制器存在，向上提供了與運(yùn)營商OSS的集成能力，支持OpenStack、CloudStack等多種主流云平臺的接口，向下通過Netconf、REST API等接口協(xié)議與SDN控制器互通，負(fù)責(zé)業(yè)務(wù)模版定義和業(yè)務(wù)發(fā)放，同時(shí)Netmatrix支持通過Netconf、SNMP、CLI、XML等接口協(xié)議與傳統(tǒng)設(shè)備互通。通過上述技術(shù)，Netmatrix希望提供端到端的跨域SDN控制器協(xié)同，SDN和傳統(tǒng)網(wǎng)絡(luò)協(xié)同，網(wǎng)絡(luò)和DC業(yè)務(wù)協(xié)同。Netmatrix屏蔽了網(wǎng)絡(luò)技術(shù)的細(xì)節(jié)和設(shè)備差異，并提供模型驅(qū)動的可編程框架，以期快速適應(yīng)新需求改變。

3 NFV網(wǎng)絡(luò)中的編排

在ETSI提出的NFV架構(gòu)中[5]，MANO(Management&Orchestration)負(fù)責(zé)對NFV網(wǎng)絡(luò)進(jìn)行管理。MANO又分為NFVO(NFV Orchestrator)、VNFM(VNF Management)和VIM(Virtualised Infrastructure Management)。VIM和VNFM聯(lián)合對資源進(jìn)行編排，其中VIM負(fù)責(zé)對通用物理設(shè)備進(jìn)行虛擬化，VNFM負(fù)責(zé)對虛擬網(wǎng)元VNF(Virtual Network Function)進(jìn)行生命周期的管理，而NFVO負(fù)責(zé)對NFV網(wǎng)絡(luò)中的業(yè)務(wù)進(jìn)行編排。本章將對MANO的一些具體實(shí)現(xiàn)進(jìn)行簡要的介紹。

3.1 HP NFV Director

NFV Director[15]是惠普推出的MANO產(chǎn)品，實(shí)現(xiàn)了ESTI提出的NFV架構(gòu)中的NFVO和VNFM。HP NFV Director的模塊如圖5所示。

圖5 HP NFV Director的組成模塊[15]

其中，策略管理模塊通過北向接口接收服務(wù)的描述和需求，目錄和列表模塊負(fù)責(zé)對服務(wù)和網(wǎng)元進(jìn)行存放和記錄，執(zhí)行模塊包括服務(wù)執(zhí)行、VNF執(zhí)行和全局資源執(zhí)行，負(fù)責(zé)服務(wù)開通與一些具體的網(wǎng)絡(luò)配置，監(jiān)測模塊包括服務(wù)監(jiān)測、VNF監(jiān)測和全局資源監(jiān)測，負(fù)責(zé)對NFV網(wǎng)絡(luò)進(jìn)行多個(gè)層次的保障。HP NFV Director采用模塊化的設(shè)計(jì)，能夠支持第三方VNFM擴(kuò)展，能夠?qū)Χ鄰S商的物理基礎(chǔ)設(shè)施和虛擬網(wǎng)元進(jìn)行聯(lián)合的編排與調(diào)度。

3.2 Oracle NSO&AO

NSO[16](Network Service Orchestration，網(wǎng)絡(luò)服務(wù)編排器)和AO[17](Application Orchestrator，應(yīng)用編排器)分別是Oracle基于ESTI的NFV架構(gòu)開發(fā)的NFVO和VNFM產(chǎn)品，如圖6所示。NSO由三個(gè)組件構(gòu)成：UIM負(fù)責(zé)記錄VNF和網(wǎng)絡(luò)服務(wù)的目錄清單，ASAP負(fù)責(zé)與AO進(jìn)行交互以對VNF進(jìn)行管理，Design Studio負(fù)責(zé)定義VNF和網(wǎng)絡(luò)服務(wù)的部署方式、屬性和配置信息。AO由六個(gè)組件構(gòu)成：Virtual Image Archive負(fù)責(zé)管理VNF虛擬機(jī)的鏡像，Orchestration Engines負(fù)責(zé)與VIM進(jìn)行交互以管理VNF虛擬機(jī)，Virtual Machine Group負(fù)責(zé)維護(hù)具有相同策略的VNF虛擬機(jī)，Cloud Administration負(fù)責(zé)權(quán)限管理，KPI Thresholds負(fù)責(zé)記錄VNF關(guān)鍵性能指標(biāo)的閾值信息，Monitor負(fù)責(zé)對VNF關(guān)鍵性能指標(biāo)進(jìn)行周期性的監(jiān)測。NSO的設(shè)計(jì)與AO是解耦的，能夠支持第三方VNFM擴(kuò)展。

圖6 Oracle的NFV產(chǎn)品NSO和AO[16]

3.3 OPNFV

OPNFV[18]是目前全球最大的NFV開源組織，它是一個(gè)運(yùn)營商級的、集成的平臺，旨在加速引入NFV產(chǎn)品和服務(wù)。2015年6月，OPNFV發(fā)布了首個(gè)版本Arno，這個(gè)版本基于OpenStack和SDN開源控制器OpenDaylight進(jìn)行集成開發(fā)，提供了ESTI的NFV架構(gòu)中基礎(chǔ)設(shè)施層的NFVI和VIM，但目前仍缺乏VNFM和NFVO的實(shí)現(xiàn)。據(jù)OPNFV項(xiàng)目組計(jì)劃，在2016年2月發(fā)布的第二個(gè)版本Brahmaputra中將對VNFM和NFVO進(jìn)行簡單的實(shí)現(xiàn)。

4 云、SDN、NFV的混合編排

4.1 云管理平臺與SDN混合編排

云管理平臺主要通過其專門負(fù)責(zé)網(wǎng)絡(luò)的Neutron組件來完成對計(jì)算、存儲、網(wǎng)絡(luò)三維資源的編排及與SDN的混合編排。當(dāng)廠家為Neutron提供的是虛擬轉(zhuǎn)發(fā)設(shè)備的插件時(shí)(如OpenvSwitch在Neutron中的插件)，此時(shí)Neutron直接控制設(shè)備的轉(zhuǎn)發(fā)，即可將Neutron看做是SDN控制器；當(dāng)廠家為Neutron提供的是控制器的插件時(shí)(如Nicira NVP、OpenDaylight、ONOS在Neutron中的插件)，Neutron不直接控制虛擬轉(zhuǎn)發(fā)設(shè)備，而是由SDN控制器在接收Neutron的調(diào)用后通過南向協(xié)議(如OpenFlow、OVSDB等)對設(shè)備進(jìn)行控制，此時(shí)Neutron可以看做是網(wǎng)絡(luò)的服務(wù)編排器，而SDN控制器可以看做是網(wǎng)絡(luò)的資源編排器。上述兩種云管理平臺與SDN混合編排的模式分別示意為圖7中(a)與(b)。

4.2 云管理平臺與NFV混合編排

N F V的基本思想是將硬件設(shè)備軟件化，在NFV框架中包括基礎(chǔ)設(shè)施層、虛擬功能實(shí)例層和NFV編排層，而云中管理平臺(如OpenStack)可以看做是NFV的一個(gè)特殊的實(shí)現(xiàn)。目前，NFV開源項(xiàng)目OPNFV中即使用OpenStack作為NFVI對物理基礎(chǔ)設(shè)施進(jìn)行虛擬化。另外，OpenStack除了能夠?qū)ξ锢砘A(chǔ)設(shè)施進(jìn)行虛擬化以外，也能夠作為虛擬功能實(shí)例層(如通過Celimetor組件對虛擬機(jī)進(jìn)行生命周期監(jiān)測)，還能夠作為NFV編排層(如通過Heat組件對服務(wù)進(jìn)行模板化設(shè)計(jì))，OpenStack項(xiàng)目組也正在積極準(zhǔn)備一個(gè)名為Tracker的項(xiàng)目，以對虛擬功能實(shí)例層和NFV編排層進(jìn)行更好的實(shí)現(xiàn)。上述云管理平臺與NFV混合編排的架構(gòu)如圖8（a)所示。

在云中，一些V N F(如Firewalls、vRouter等)可以看做是為租戶提供增值業(yè)務(wù)的設(shè)備，一些VNF可以在云管理平臺中的網(wǎng)絡(luò)組件(如OpenStack的Neutron)中實(shí)現(xiàn)，并通過對其接口進(jìn)行擴(kuò)展以實(shí)現(xiàn)對VNF資源的編排，此時(shí)云管平臺從系統(tǒng)建設(shè)角度來看也不再附屬于NFV，對NFV服務(wù)鏈的編排依賴于云管平臺的服務(wù)編排組件進(jìn)行實(shí)現(xiàn)(如OpenStack Heat)。上述兩種云管理平臺與NFV混合編排的架構(gòu)如圖8(b)所示。

圖7 云管理平臺與SDN混合編排

圖8 云管理平臺與NFV混合編排

4.3 SDN與NFV的混合編排

當(dāng)SDN在ETSI提出的NFV架構(gòu)下進(jìn)行部署時(shí)，SDN不再進(jìn)行單獨(dú)的系統(tǒng)建設(shè)，包括SDN控制器、SDN轉(zhuǎn)發(fā)設(shè)備都可能有不同的部署位置。如圖9(a)所示，橙色和綠色的方框分別為SDN控制器、SDN轉(zhuǎn)發(fā)設(shè)備可能的部署位置。其中，當(dāng)控制器部署在a點(diǎn)即VIM中時(shí)，轉(zhuǎn)發(fā)設(shè)備可以部署在d點(diǎn)作為硬件網(wǎng)絡(luò)資源，也可以部署在通用硬件虛擬化層中的e點(diǎn)作為虛擬網(wǎng)絡(luò)資源；當(dāng)控制器部署在通用硬件虛擬化層中的虛擬計(jì)算資源即b點(diǎn)時(shí)，轉(zhuǎn)發(fā)設(shè)備以VNF轉(zhuǎn)發(fā)實(shí)例的形式部署在c點(diǎn)；當(dāng)控制器部署在VNF SDN Controller實(shí)例時(shí)，轉(zhuǎn)發(fā)設(shè)備同樣以VNF轉(zhuǎn)發(fā)實(shí)例的形式部署在c點(diǎn)。SDN編排器的功能在該架構(gòu)中可以集成在NFVO和VNFM中，其編排主要功能包括服務(wù)鏈的標(biāo)簽分配，服務(wù)鏈的流量引導(dǎo)，SLA策略等等。另外，在這種混合部署模式中，由NFVO完成與傳統(tǒng)網(wǎng)絡(luò)OSS系統(tǒng)的對接。業(yè)務(wù)入口可以為OSS系統(tǒng)，其對于SDN服務(wù)的需求傳遞給NFVO來完成。業(yè)務(wù)入口也可以為MANO，其對于傳統(tǒng)網(wǎng)絡(luò)服務(wù)的需求由NFVO傳遞給OSS來完成。

SDN網(wǎng)絡(luò)在某些場景下是不依賴于NFV的，網(wǎng)絡(luò)中除了包括NFV虛擬轉(zhuǎn)發(fā)設(shè)備以外，還很有可能包括一些硬件轉(zhuǎn)發(fā)設(shè)備。此時(shí)，SDN系統(tǒng)與NFV系統(tǒng)將獨(dú)立建設(shè)，由SDN負(fù)責(zé)對虛擬、物理設(shè)備的轉(zhuǎn)發(fā)進(jìn)行控制，而NFV則扮演類似于SDN網(wǎng)管的角色，負(fù)責(zé)虛擬轉(zhuǎn)發(fā)設(shè)備的實(shí)例化和配置等，兩套系統(tǒng)并行工作，協(xié)同完成對網(wǎng)絡(luò)的編排工作，如圖9(b)所示。

圖9 SDN與NFV混合編排

5 總結(jié)

云、SDN、NFV都是近年來業(yè)界比較重視的新型網(wǎng)絡(luò)技術(shù)，它們沿著虛擬化、軟件化的路線正在對靈活性差、自動化能力弱的傳統(tǒng)網(wǎng)絡(luò)進(jìn)行著深刻的變革。本文對云、SDN、NFV中的網(wǎng)絡(luò)編排原理進(jìn)行描述，并選擇有代表性的產(chǎn)品和開源項(xiàng)目進(jìn)行了介紹。網(wǎng)絡(luò)的自動化編排能力正是虛擬化和軟件化所追求的理想結(jié)果，目前，云管理平臺在自動化編排能力上已經(jīng)獲得業(yè)界的廣泛認(rèn)可，而SDN和NFV在自動化編排方面仍缺乏相關(guān)標(biāo)準(zhǔn)，三類技術(shù)混合編排的部署方式也有待進(jìn)一步的探索。

參考文獻(xiàn)

[1]Vmware.vCloud Suite[EB/OL].[2016-01-20].http://www.vmware.com/cn/products/vcloud-suite/

[2]Microsoft.Windows Azure[EB/OL].[2016-01-20].http://www.windowsazure.cn/zh-cn/

[3]OpenStack.Official Website[EB/OL].[2016-01-20].http://openstack.org/

[4] ONF.SDN_ARCH_1.0[EB/OL].[2016-01-20].https://www.opennetworking.org/images/stories/downloads/ sdnresources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf

[5]ESTI.NFV Witepaper[EB/OL].[2016-01-20].http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/ 01.02.01_60/gs_NFV002v010201p.pdf

[6 CloudStack.Official Website[EB/OL].[2016-01-20].http://cloudstack.apache.org/

[7]Nate Foster, Arjun Guha, Mark Reitblatt, et al.Languages for software-defined networks[J].Communications Magazine,IEEE, 2013, 51(2): 128-134

[8]Joshua Reich, Christopher Monsanto, Nate Foster, et al.Modular sdn programming with pyretic[J].Technical Reprot of USENIX, 2013

[9]Andreas Voellmy, Junchang Wang, Yang Y, et al.Maple:Simplifying SDN programming using algorithmic policies[C]//ACM SIGCOMM Computer Communication Review.ACM,2013, 43(4): 87-98

[10] Pat Bosshart, Dan Daly, Glen Gibb, et al.P4: Programming protocol-independent packet processors[J].ACM SIGCOMM Computer Communication Review, 2014, 44(3): 87-95

[11] Pankaj Berde, Matteo Gerola, Jonathan Hart, et al.ONOS: towards an open, distributed SDN OS[C]//Proceedings of the third workshop on Hot topics in software defined networking.ACM, 2014: 1-6

[12]Jan Medved, Robert Varga, Anton Tkacik, et al.Opendaylight: Towards a model-driven sdn controller architecture[C]//2014 IEEE 15th International Symposium on.IEEE, 2014: 1-6

[13]Cisco.Application Based Infrastructure[EB/OL].[2016-01-20].http://www.cisco.com/web/CN/solutions/datacenter/aci.html?CAMPAIGN=Insieme&COUNTRY_SITE=cn&POSITION=sl&REFERRING_SITE=Cisco.co m+homepage&CREATIVE=homepage+spotlight+to+AC I+launch+landing

[14]Huawei.NetMatrix[EB/OL].[2016-01-20].http://www.huawei.com/ilink/cn/about-huawei/newsroom/pr essrelease/HW_310988

[15]HP.NFV Director[EB/OL].[2016-01-20].http://www8.hp.com/uk/en/pdf/NFV_Director_customer_prese ntation_tcm_183_1541136.pdf

[16]Oracle.Network Service Orchestartor[EB/OL].[2016-01-20].http://www.oracle.com/us/products/ applications/communications/service-orchestration/index.html

[17]Oracle.Application Orchestrator[EB/OL].[2016-01-20].http://www.oracle.com/us/products/applications /communications/application-orchestrator/index.html

[18]OPNFV[EB/OL].[2016-01-20].https://www.opnfv.org/