當前主流SDN的概念探討
長期以來，網絡技術總是以被動方式進行演變，并且大量的技術革新都落地在網絡設備本身，如帶寬不斷提升，從千兆到萬兆、再到40G和100G;設備體系架構變化，也是為了性能地不斷提升，從交換能力幾十Gbps提升到T級別以致100T級別;組網變化，網絡設備的N:1集群性質的虛擬化，在一定范圍內和一定規模上優化了網絡架構，簡化了網絡設計;大二層網絡技術，通過消除環路因素，支持了虛擬化條件下的虛機大范圍二層擴散性計算。
新的技術商用，總會引起設備的升級換代，并且隨著流量的巨大變化，網絡的部署與變更技術上越來越復雜，網絡在應對流量變化上很難有良好的預期性，在當前方式下，一旦完成業務部署，服務器通過網線連入網絡，應用流量吞吐對網絡的影響就難以控制、網絡的調整也就變得相當滯后。
軟件定義網絡——SDN(Software Defined Network)的出現和理念演進，開始改變網絡被動性的現狀，使網絡具備較大靈活程度的“定義”能力;這種可定義性，是網絡主動“處理”流量而不僅僅是被動“承載”流量，并使得網絡與計算之間的關系不僅僅是“對接”，而是“交互”。
SDN的思想集中體現在控制面與實體數據轉發層面之間分離，這對網絡交換機的工作方式產生了深遠的影響。高端用戶原本就不滿足于使用網絡預先設定好的功能，而是希望在自己的業務功能不斷豐富變化的過程中，能夠按照自身需求快速進行調整。而在控制層面分離出來后，或者說控制層面可以開放出來，更能實現虛擬化的靈活性，使得用戶能夠進行程序編制，那么基于應用與流量變化的快速響應，便不需要完全依賴于設備供應商的長周期軟硬件升級來完成。
SDN的思想是將更多的控制權交給網絡使用者，除了設計部署、配置變更，還可以進行網絡軟件的重構，使得新的技術驗證可以先于商業化。這種網絡能夠以抽象化的方式解決網絡的復雜性問題，解除了用戶收支網絡功能和特性的緊約束，能夠在更高層面研究和滿足項業務需求。
1 當前主流SDN的概念探討
最經典的SDN架構描述是來自ONF(Open Network Foundation)的SDN體系架構圖。SDN的分層解耦合概念，包括通用的基礎硬件層、硬件抽象層、網絡操作系統、上層應用。其中基礎硬件與硬件抽象兩層組成物理網絡設備，也就是SDN架構中的數據轉發層面;網絡操作系統與上層應用組成了控制層面。數據轉發層面與控制層面間以一種標準化的交互協議來解耦合，此協議當前為OpenFlow。這種去耦合的架構，表明網絡操作系統及網絡應用(如路由控制協議等)不必運行在物理設備上，而可以運行在外部系統(如X86架構的服務器)內，從而實現網絡控制的靈活可編程性。
除了解耦合控制層面與數據轉發層面，SDN還引入了集中控制的概念(如圖2所示)。對于傳統的設備，因為不同的硬件、供應商私有的軟件，使得網絡本身相對封閉，只能通過標準的互通協議與計算設備配合運行。網絡中所有設備的自身系統都是相對孤立和分散的，網絡控制分布在所有設備中，網絡變更復雜、工作量大，并且因為設備異構，管理上兼容性很差，不同設備的功能與配置差異極大;同時網絡功能的修改或演進，會涉及到全網的升級與更新。而在SDN的開放架構下，一定范圍內的網絡(或稱SDN域)，由集中統一的控制邏輯單元來實施管理，由此解決了網絡中大量設備分散獨立運行管理的問題，使得網絡的設計、部署、運維、管理在一個控制點完成，而底層網絡差異性也因為解耦合的架構得到了消除。集中控制在網絡中引入了SDN區別于傳統網絡架構的角色——SDN Controller，也就是運行SDN網絡操作系統并控制所有網絡節點的控制單元。SDN能夠提供網絡應用的接口，在此基礎上按照業務需求進行軟件設計與編程，并且是在SDN Controller上加載，從而使得全網迅速升級新的網絡功能，而不必再對每個網元節點進行獨立操作。
分層解耦合架構中采用了OpenFlow的協議來分離網絡的控制與轉發層，圖3是來自斯坦福的一張圖表明OpenFlow的解耦模型。
網絡設備OpenFlowSwitch)由標準的網絡硬件和支持OpenFlow代理的軟件構成。OpenFlow定義的網絡硬件，不是傳統的交換模式，而是以一種流表的方式來進行數據的轉發處理，非常類似于當前交換機使用的TCAM對數據流的分類與控制行為，每一個網絡中的流均由流表中的規則來控制處理，可以達到極精細的粒度。OpenFlow協議定義了一種通用的數據平面描述語言，設備上的OpenFlow代理軟件通過與OpenFlow Controller建立安全加密(如SSL通信機制)通信隧道來接受對設備的控制轉發指令。所有的流表指令均被定義成標準規范，通過Controller與代理之間的加密協議可靠傳遞。Controller上運行的各種網絡應用，均被轉換成OpenFlow“指令集”下發，從而易于實現標準化的模式，這使得OpenFlow成為SDN架構下的重要技術。
OpenFlow以一種比較理想的形式定義了網絡設備的供應方式，但這種定義使得網絡不是一個平滑升級和演進，而是一個顛覆性的更新，現有網絡不能通過OpenFlow來升級，而是需要被完全替換。同時，OpenFlow設備是一種流表轉發，也需要新的體系架構來設計網絡芯片，雖然現有TCAM技術能支持OpenFlow的特性，但是功能不完備、大TCAM表項設備極其昂貴。因此，當前的OpenFlow設備，基本是在傳統網絡基礎上支持OpenFlow協議，規格受限的初期產品。
OpenFlow的設計思路體現了SDN架構，但是，這種思路只體現了集中控制的優勢，對于網絡的運維管理并沒有深入考慮，管理通信如何采用OpenFlow并與正常業務流的分離，是否覆蓋替代還是與傳統SNMP/NETCONF的管理方式，集中的OpenFlow Controller與分散的OpenFlow網絡設備之間采取一種如何的管理方式更優，還需要OpenFlow本身的技術不斷實踐來印證。
OpenFlow在協議定義上還不完善，針對已有網絡特性的定義還在補充變化，內容變更會不斷持續，并逐步形成不同的技術版本，這使得軟件和硬件在配套兼容上存在較大的問題，這也是OpenFlow作為SDN協議的在網絡應用覆蓋不全方面的嚴重不足。
2 H3C SDN體系架構：開放與融合
2.1 H3C SDN總體架構與策略
H3C在基于全網端到端的總體網絡架構上，將會交付一個逐步發展豐富的SDN產品與解決方案集。(如圖4所示)H3C SDN當前提供三大方案集：基于Controller/Agent的SDN全套網絡交付、基于Open API的網絡平臺開放接口、基于OAA的自定義網絡平臺。在這三大方案集成基礎上，構建一個標準化深度開放、用戶應用可融合的NPaaS(Network Platform as a Service)網絡平臺即服務的SDN體系，既具備H3C已有的優勢網絡技術方案，又能在各種層次融合與擴展用戶自制化網絡應用。
2.2 基于Controller/Agent的SDN全套網絡交付
在上述SDN基本體系架構定義的框架下，H3C提供與此一致的方案架構。H3C將在同一SDN的架構下，除了支持標準化的OpenFlow協議，并提供基于H3C自身成熟技術的自有協議RIPCRIPC(Remote IPC)。
H3C將提供標準化的系列化Controller部件，能夠以OpenFlow協議進行OpenFlow設備的集中控制，對上層提供靈活的開放接口，以滿足各種網絡應用的調用需求。在當前網絡產品逐步集成OpenFlow特性，滿足初始OpenFlow網絡部署需求，并逐步豐OpenFlow的產品組成，如圖6左圖構建了整體OpenFlow的SDN網絡。
針對H3C優勢技術IRF的進一步強化，基于Controller/Agent架構，以H3C RIPCRIPC的協議實現了VCF的技術，如圖6右圖所示，使用多臺S5820V2組成的IRF結構體工作為網絡的Controller角色，下聯多臺S5120HI。
VCF采用SDN架構的N:1網絡虛擬化，不僅將多臺同一網絡層面的設備整合，也將另一層次的設備整合，整個網絡運行如同一臺大型框式設備，運行管理各種操作均被虛擬化在一臺大型設備內。所有的控制、設備管理均在S5820V2的IRF組上，其它的S5120HI運行為線卡模式。在這種SDN架構下，H3C的RIPC協議消除了OpenFlow協議在效率與管理上的不足，并有效繼承了H3C Comware平臺的原有IRF優勢。
2.3 基于Open API的網絡平臺
SDN最重要的網絡需求是可編程性，即用戶可以在自身業務變化的情況下，根據需要自行軟件開發，這種需求的核心是網絡要有靈活開放的接口提供給用戶的編程實現。H3C實現了多層化的Open API方案。
基礎設備層面可以提供深度的SDK級標準化VCC網絡應用(VCC: Virtual Computing Container 虛擬計算容器)，并提供高級XML的訪問操作NETCONF標準接口體系，OpenFlow也是設備層面提供的一種標準接口模式;
設備控制層面(SDN Controller)，作為網絡操作系統，標準化的接口依據Controller的不同實現，對外可提供VCC、REST/SOAP、NETCONF、OpenFlow等。
Open API與H3C系統(Comware/iMC)內部集成(Integrated)API(如RIPC)相輔相成，構建差別的SDN架構，并在不同層次形成自有系統及對外開放與標準化，使得不同用戶的可編程與應用變化性需求得以滿足。
在Open API接口中，REST/SOAP是常規的高層協議編程接口，NETCONF是網絡設備上新興的XML語言編程接口，OpenFlow是SDN的一種協議，以上均是通用化的技術實現，VCC則是H3C在長期網絡軟件技術積累過程中形成的一種更為底層的標準化實現。
ComwareV7是基于Linux內核實現的新一代云計算網絡操作系統，當前的架構，基于類POSIX的Linux接口及擴展形成一套開放的SDK，H3C提供了含SDK的接口描述、調用庫、編譯環境等完備的編程環境，使得用戶可以使用C/C++以幾乎完全等同于Linux系統下的環境進行自己的網絡應用程序軟件開發，而ComwareV7則為用戶的軟件運行提供了一個完整的系統環境。
在VCC環境中，用戶程序包可獨立加載到設備上運行，軟件可以不間斷業務升級。Comware V7提供接口給用戶，軟件設計可以一定程度上訪問底層硬件，對路由、MAC等硬件表項進行操作，或者設備的配置變更及相應狀態監控等，同時還可以利用Comware V7現有的特性來輔助實現用戶業務，從而實現用戶軟件定義網絡的真正需求。
2.4 基于OAA的自定義網絡平臺
早期，H3C提出了開放應用架構(Open Application Architecture)的網絡模型，即在H3C的網絡設備中提供具有計算能力的線卡，用戶可以在其上開發自己的特殊應用，并通過H3C的OAA關聯協議與網絡進行數據交互。
基于SDN的架構思路，H3C演繹了更靈活的用戶化網絡設計，實現的OAA新的業務模式，可以方便用戶靈活實現自定義的網絡功能。在OAA基礎上，提出了兩種開放式的接口模型。
一種全松耦合的OAA架構。針對用戶任意形態運行的網絡業務，可能是在服務器上的計算業務(如流量監控分析、數據旁路挖掘)，也可能是專用的業務設備(如防火墻、IPS、加密機、數據壓縮機)，用戶設備可以支持標準的OpenFlow協議，即可與H3C網絡進行通信，在OpenFlow協議中傳輸業務指令，對需要處理的網絡流量進行鏡像、牽引、封裝、定向等操作，將清晰定義的數據流以合適的方式導引到用戶的計算設備進行自定義處理。這種方案的本質是，借助SDN的模型，將用戶的數據處理設備運行為SDN Controller方式，而對特定業務流進行處理。
一種緊耦合的OAA架構，其中分兩種模式：模式一，用戶自設計提供高性能計算單元子卡，H3C提供OAA的線卡底板，兩者以開放的標準化電氣接口連接器相連，用戶計算單元與網絡之間依然通過標準的OpenFlow方式進行網絡流量的引流操作，而軟件、硬件均由用戶自身根據業務需求來設計;模式二，H3C提供了整體的OAA線卡，用戶基于H3C的硬件來開發自己的軟件，在協議上仍然采用OpenFlow的方式進行特定數據處理。
3 結束語
SDN是一個寬泛的網絡體系架構，需要通過靈活開放的結構來實現用戶需求，H3C的技術模式，是在不同的網絡層面、不同的體系架構上均可提供用戶需要的接口與業務環境，同時H3C本身也提供基于SDN的用戶網絡應用。
京公網安備 11010502049343號