自斯坦福CLEANState項目孵化OpenFlow協(xié)議，在2009年業(yè)界正式提出軟件定義網(wǎng)絡(luò)(SDN)以來，業(yè)界已經(jīng)有上百家企業(yè)正式加入到開放網(wǎng)絡(luò)基金會(ONF)。SDN的產(chǎn)品及樣機覆蓋了SDN控制器、交換機、路由、虛擬網(wǎng)絡(luò)功能部件等產(chǎn)品，應(yīng)用場景覆蓋了數(shù)據(jù)中心網(wǎng)絡(luò)、企業(yè)網(wǎng)、校園網(wǎng)、光網(wǎng)絡(luò)及業(yè)務(wù)邊緣網(wǎng)絡(luò)等。迄今為止，SDN的功能架構(gòu)在不同的領(lǐng)域，出于技術(shù)和利益博弈兩個方面的原因，業(yè)界尚無統(tǒng)一的認(rèn)識。一般來說，ONF定義的轉(zhuǎn)發(fā)、控制、應(yīng)用3層架構(gòu)得到相對廣泛的認(rèn)同。
1.SDN架構(gòu)
按照ONF的定義，SDN分為基礎(chǔ)設(shè)施層、控制層和應(yīng)用層，見圖1所示。虛擬化在基礎(chǔ)設(shè)施以及控制層兩個層面上實現(xiàn)，前者實現(xiàn)設(shè)備級的虛擬化，比如一個物理交換機支持多個邏輯交換機；后者實現(xiàn)網(wǎng)絡(luò)級的虛擬化，首先是SDN控制器將整個網(wǎng)絡(luò)當(dāng)成一個邏輯的超級交換機進行管理控制，其次將物理資源進一步根據(jù)端口、媒體訪問控制(MAC)地址、IP地址段等信息劃分為多個虛擬網(wǎng)絡(luò)遵照傳統(tǒng)通信領(lǐng)域的慣例，在架構(gòu)圖中下方為南，上方為北，因此基礎(chǔ)設(shè)施層和轉(zhuǎn)發(fā)層之間的接口稱為南向接口。ONF標(biāo)準(zhǔn)化的是OpenFlow協(xié)議，互聯(lián)網(wǎng)工程任務(wù)組(IETF)正在制訂路由系統(tǒng)接口(12RS)協(xié)議。控制層和應(yīng)用層之間的接口稱為北向接口，業(yè)界主流實現(xiàn)的是基于超文本傳輸協(xié)議(HTTP)的RESTful接口，具體編程接口隨應(yīng)用場景不同而有所區(qū)別。
圖1 SDN分層架構(gòu)
在更廣義的SDN架構(gòu)中，控制層之上還有業(yè)務(wù)編排層，主要實現(xiàn)SDN域間資源的統(tǒng)一管理、SDN網(wǎng)絡(luò)和其他資源的統(tǒng)一調(diào)度，比如0penstack+SDN的數(shù)據(jù)中心解決方案。
Openstack統(tǒng)一調(diào)度計算、網(wǎng)絡(luò)和存儲資源，相當(dāng)于SDN的業(yè)務(wù)編排層。站在SDN的角度來看，控制層之上如何劃分則是廠商解決方案、應(yīng)用實現(xiàn)的具體行為，就如同傳輸控制協(xié)議，網(wǎng)間協(xié)議(TCP/IP)并不關(guān)心應(yīng)用層進一步如何分層設(shè)計，統(tǒng)稱為應(yīng)用層。站在整個網(wǎng)路架構(gòu)的層面來看SDN，則業(yè)界存在不同的看法：
(1)SDN只進行區(qū)域性網(wǎng)絡(luò)改造，可將SDN控制域看成一個超級設(shè)備。SDN并不改變原有的網(wǎng)絡(luò)橫向接口，邊界網(wǎng)關(guān)協(xié)議(BGP)/多協(xié)議標(biāo)簽交換(MPLS)等仍然有效。
(2)SDN控制域間定義專門/增強的SDN東西向接口，將SDN作為整個網(wǎng)絡(luò)的控制平面。
本文認(rèn)為，第一種方案更加具有現(xiàn)實意義，利于網(wǎng)絡(luò)的平滑演進。第二種方案中的東西向接口要么可以通過擴充現(xiàn)有的BGP，MPLS協(xié)議實現(xiàn)，要么可以通過北向接口在業(yè)務(wù)編排層面進行實現(xiàn)，如果要定義更加專用的SDN東西向接口，雖然有可能可以增強整網(wǎng)的能力，但是無疑也為部署增加了難度，業(yè)界正在探索之中。
2.ZENIC架構(gòu)及控制面關(guān)鍵技術(shù)實現(xiàn)
現(xiàn)有來自于學(xué)術(shù)界的開源SDN控制器實現(xiàn)基于OpenFlow協(xié)議，整個轉(zhuǎn)發(fā)模型也綁定于某個具體的OpenFlow協(xié)議版本”。對于商用系統(tǒng)而言，必須要考慮整個產(chǎn)品生命周期內(nèi)協(xié)議接口的兼容，還要考慮不同應(yīng)用場景的區(qū)別以及和多廠家、多協(xié)議接口的差別，因此SDN控制面必須設(shè)置一個兼容多版本OpenFlow、多種控制協(xié)議以及不同轉(zhuǎn)發(fā)面能力的抽象層，我們稱之為轉(zhuǎn)發(fā)抽象層(FAL)，在此之上為網(wǎng)絡(luò)操作系統(tǒng)(NOS)核心以及應(yīng)用層提供的接口是獨立于具體的協(xié)議和硬件能力的。在OpenDaylight中，此層次稱為業(yè)務(wù)抽象層(SAL)”。
本文實現(xiàn)一種SDN控制器——ZENIC，其架構(gòu)如圖2所示。圖2自上而下主要包括協(xié)議棧、驅(qū)動和轉(zhuǎn)發(fā)抽象層、NOS內(nèi)核和應(yīng)用層。
圖2 ZENIC架構(gòu)
2.1 轉(zhuǎn)發(fā)抽象層及驅(qū)動層
轉(zhuǎn)發(fā)抽象層定義統(tǒng)一的轉(zhuǎn)發(fā)控制接口，包括對抽象轉(zhuǎn)發(fā)面的狀態(tài)、能力、硬件資源、轉(zhuǎn)發(fā)表、統(tǒng)計信息等進行讀取/操作，相當(dāng)于驅(qū)動的基類。同時轉(zhuǎn)發(fā)抽象層還管理轉(zhuǎn)發(fā)面驅(qū)動的實例，根據(jù)轉(zhuǎn)發(fā)面接入時的基本能力協(xié)商加載不同的驅(qū)動實例，將轉(zhuǎn)發(fā)面的控制連接綁定到相應(yīng)的驅(qū)動實例。
每個具體設(shè)備的驅(qū)動實現(xiàn)轉(zhuǎn)發(fā)抽象層的接口，完成不同接口協(xié)議、不同硬件能力到轉(zhuǎn)發(fā)抽象層的統(tǒng)一適配。從控制面及其上層應(yīng)用的角度來看，F(xiàn)AL提供了一個統(tǒng)一的轉(zhuǎn)發(fā)操縱接口，但是由于各轉(zhuǎn)發(fā)面的能力差別較大，應(yīng)用對于轉(zhuǎn)發(fā)面的操作存在失敗的可能，因此FAL需要向應(yīng)用提供轉(zhuǎn)發(fā)面能力獲取/協(xié)商的接口。ZENIC已經(jīng)實現(xiàn)對于OpenFlow1.1/1.2/1.3的自適應(yīng)協(xié)商。
2.2 網(wǎng)絡(luò)操作系統(tǒng)內(nèi)核層
NOS內(nèi)核層是對網(wǎng)絡(luò)、系統(tǒng)資源的管理，包括拓?fù)涔芾怼⒅鳈C管理、接口資源管理、轉(zhuǎn)發(fā)表管理等，并管理物理拓?fù)洹⑻摂M拓?fù)洹⑥D(zhuǎn)發(fā)表等構(gòu)成的網(wǎng)絡(luò)信息庫。總體而言，內(nèi)核層并無預(yù)設(shè)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)邏輯處理，而是維護準(zhǔn)確的網(wǎng)絡(luò)拓?fù)洹①Y源狀態(tài)以及轉(zhuǎn)發(fā)表的存儲、合成，接受應(yīng)用對于網(wǎng)絡(luò)、資源狀態(tài)的訂閱以及應(yīng)用對于網(wǎng)絡(luò)資源、轉(zhuǎn)發(fā)邏輯的操作。
拓?fù)涔芾淼膶崿F(xiàn)目前能夠基于OpenFlow標(biāo)準(zhǔn)化的實現(xiàn)是基于控制器在鏈路上周期下發(fā)探測報文實現(xiàn)的，以太網(wǎng)一般是基于鏈路層發(fā)現(xiàn)協(xié)議(LLDP)實現(xiàn)。這樣實現(xiàn)的好處是轉(zhuǎn)發(fā)面完全無需感知，缺點是鏈路較多、檢測定時器較短時，控制器的開銷較高。另外一種方式是有轉(zhuǎn)發(fā)面維護鏈路檢測定時器，自行檢測，將狀態(tài)上報，這一實現(xiàn)方式的優(yōu)點是控制面開銷小，缺點是需要轉(zhuǎn)發(fā)面具有一定的預(yù)設(shè)邏輯。
內(nèi)核層不僅要維護網(wǎng)絡(luò)節(jié)點、拓?fù)錉顟B(tài)，而且也需要收集基本的主機位置、狀態(tài)，從而可以給應(yīng)用提供一個完整的網(wǎng)絡(luò)視圖，進一步做轉(zhuǎn)發(fā)、業(yè)務(wù)的決策。
對于SDN控制器而言，網(wǎng)絡(luò)虛擬化應(yīng)該內(nèi)置支持。虛擬化應(yīng)該內(nèi)置支持。虛擬化首先是轉(zhuǎn)發(fā)面資源的分區(qū)和隔離，比如按照端口、邏輯端口、主機MAC地址、IP地址段等進行虛擬網(wǎng)絡(luò)的劃分，其次是虛擬拓?fù)鋵τ谄渖峡蛻?應(yīng)用的權(quán)限管理適配。
OpenFlow的流表模型以及對于交換機統(tǒng)一、扁平化的管理視圖帶來了很多問題，包括交換機硬件復(fù)雜化、不靈活、主機和網(wǎng)絡(luò)需緊耦合”。在ZENIC系統(tǒng)中，將內(nèi)聯(lián)網(wǎng)絡(luò)管理作為內(nèi)核服務(wù)之一，解耦接入網(wǎng)絡(luò)和互聯(lián)網(wǎng)絡(luò)。內(nèi)核管理互聯(lián)網(wǎng)絡(luò)的封裝格式，上層應(yīng)用只需要決策SDN控制域內(nèi)兩個接入端口的位置和策略。內(nèi)核計算出完整端到端路徑，并在接入側(cè)將轉(zhuǎn)發(fā)決策映射到互聯(lián)網(wǎng)絡(luò)路徑的封裝標(biāo)簽。ZENIC支持多種互聯(lián)網(wǎng)絡(luò)封裝格式，包括MPLS、虛擬局域網(wǎng)(VLAN)等，下一步將支持虛擬擴展的局域網(wǎng)(VXLAN)/通用路由封裝協(xié)議(GRE)。這種接入一互聯(lián)網(wǎng)絡(luò)的模式，應(yīng)用完全無需感知，專注于主機接入側(cè)的策略。同時內(nèi)連網(wǎng)絡(luò)管理本身也可以開放接口，支持應(yīng)用自定義的路由算法和策略。
2.3 北向應(yīng)用編程接口
北向應(yīng)用編程接口(API)在不同的應(yīng)用場景中需求不同，對于封裝的要求也有區(qū)分。如果將網(wǎng)絡(luò)的原子能力暴露給應(yīng)用，是有可能形成統(tǒng)一的API，但是由于缺乏封裝和易用性，應(yīng)用編程、實現(xiàn)的復(fù)雜度較高。比如有廠商實現(xiàn)的設(shè)備級開放API多達700多個，涵蓋幾乎所有協(xié)議和設(shè)備功能，但是對于SDN而言，將會面臨至少兩類應(yīng)用，需求迥異：
(1)專業(yè)網(wǎng)絡(luò)應(yīng)用
訂制化需求高，需要更加細(xì)節(jié)的API，對底層網(wǎng)絡(luò)的操作操縱能力強，比如訂制開發(fā)路由協(xié)議、訂制進行精細(xì)化的流量調(diào)度。
(2)普通應(yīng)用
將網(wǎng)絡(luò)作為一種服務(wù)，只是請求網(wǎng)絡(luò)為應(yīng)用提供服務(wù)，并不關(guān)心網(wǎng)絡(luò)細(xì)節(jié)。
對于后者，北向接口最好能封裝幾個模型和交互簡單、易懂的服務(wù)接口，如向網(wǎng)絡(luò)請求創(chuàng)建從交換機A端口l到交換機B端口2的一條lGb/s有帶寬保證的通路，而不是由應(yīng)用向路徑上的交換機逐個下發(fā)轉(zhuǎn)發(fā)表以及相應(yīng)的隊列配置參數(shù)。
還有一種北向接口的思路就是由應(yīng)用定義自身對網(wǎng)絡(luò)的需求和操作接口，網(wǎng)絡(luò)廠商提供插件實現(xiàn)應(yīng)用的網(wǎng)絡(luò)接口。比較典型的是Openstack的Quantum組件，其定義了網(wǎng)絡(luò)的API，由各個廠商提供Quantum Plug—In來控制自己的SDN控制器或網(wǎng)絡(luò)設(shè)備。此架構(gòu)相當(dāng)于把SDN的北向接口標(biāo)準(zhǔn)化工作往上推到應(yīng)用，網(wǎng)絡(luò)去適配應(yīng)用需求。
兩種思路各有利弊，由SDN定義北向接口比較理想化，試圖統(tǒng)一解決所有問題，但是網(wǎng)絡(luò)很難一一理解應(yīng)用的需求，標(biāo)準(zhǔn)化的推進工作相對困難，而且易用性也很難保證；應(yīng)用驅(qū)動的模式使得SDN落地更加容易，但是應(yīng)用和多廠商網(wǎng)絡(luò)之間的互通要較耗費更大代價。ZENIC提供基本的細(xì)顆粒度的底層API，同時提供封裝后的虛擬網(wǎng)絡(luò)API，目前已經(jīng)提供Openstack的Quantum Plug—In接入到Openstack之中。
2.4 分布式處理算法
控制面本身的分布式架構(gòu)以及SDN轉(zhuǎn)發(fā)控制分離的架構(gòu)帶來了狀態(tài)同步的額外開銷，準(zhǔn)確的SDN全局視圖能夠保證決策的精確性和實時性，對于負(fù)載均衡等應(yīng)用而言可以提升資源利用率，但需更加頻繁的信息同步，這大大降低了系統(tǒng)性能。本文從設(shè)計上采用兩種手段：控制器的分布式方案盡可能減少消息的復(fù)制；控制轉(zhuǎn)發(fā)之間的狀態(tài)同步由用戶根據(jù)需求進行配置，只進行必要、夠用的狀態(tài)復(fù)制。
傳統(tǒng)的集群網(wǎng)絡(luò)系統(tǒng)控制面基本上是基于進程的分布式處理，比如各個不同的業(yè)務(wù)進程分布在不同的CPU上，但是一種進程仍然是單實例或少數(shù)實例，并行度受限。在單一業(yè)務(wù)進程突發(fā)負(fù)載的情況下，比如自治域問路由調(diào)整時的邊界網(wǎng)關(guān)協(xié)議(BGP)進程就是“瓶頸”。對于SDN而言，由于控制的網(wǎng)絡(luò)規(guī)模可能遠”高于集群路由器，對控制面節(jié)點數(shù)墮的要求更高，因此這種方法存在“瓶頸”不太可行。
分布式哈希表(DHT)算法提供了一個可伸縮的分布式數(shù)據(jù)存儲/路由算法。對于傳統(tǒng)應(yīng)用不穩(wěn)定網(wǎng)絡(luò)的Log2(N)查找復(fù)雜度的算法，在數(shù)據(jù)中心、電信網(wǎng)絡(luò)應(yīng)用時，業(yè)界提出了多種增強的單跳算法，部分基于單跳DHT的增強型結(jié)構(gòu)化查詢語言系統(tǒng)(No—SQL)開源系統(tǒng)也已經(jīng)過商用考驗，包括Dynamo、Cassandra等，最早公開采用DHT分布式算法的SDN控制器是onix，OpenDaylight項目近期也提出來采用Cassandra作為底層的分布式數(shù)據(jù)庫系統(tǒng)。作者所在團隊也實現(xiàn)了改良的單跳DHT算法”。
DHT算法基于一致性哈希，適用于鍵一值(Key—Value)存儲模型，類結(jié)構(gòu)化查詢語言(SQL)的支持需要進一步封裝。對于SDN控制器而言，拓?fù)湫畔⑹侨中缘模贿m合于DHT存儲，而是需要進行額外的全局復(fù)制。與轉(zhuǎn)發(fā)設(shè)備相關(guān)的信息組織以交換節(jié)點為單位進行分布式儲存，可以滿足基本要求，但是顆粒度較粗，不利于控制節(jié)點之間的負(fù)載均衡。主機信息可以按IP地址、MAC表兩個維度進行分布化，更加均勻。
3.轉(zhuǎn)發(fā)層面的轉(zhuǎn)發(fā)抽象技術(shù)實現(xiàn)
OpenFlow 1.0提供的是一個單流表的抽象模型91，OpenFlow 1.1之后定義了一個多級流表的模型。12RS以及部分廠商的開放接口給應(yīng)用暴露的是一個路由信息庫(RIB)之上的多種業(yè)務(wù)表，表之間隱含了協(xié)議規(guī)定的各種邏輯。OpenFlow給了應(yīng)用/控制面對轉(zhuǎn)發(fā)面最大程度的操縱能力，理論上可以完全不受現(xiàn)有網(wǎng)絡(luò)協(xié)議的限制，轉(zhuǎn)發(fā)面可以是完全傻瓜化指令執(zhí)行引擎，而其他開放API則是現(xiàn)有協(xié)議框架下的開放API，有嚴(yán)格的限定條件。
OpenFlowl.0非常簡單，但是需要三態(tài)內(nèi)容尋址存儲器(TCAM)的支持，而TCAM價格相對較昂貴，同時其單表結(jié)構(gòu)使得復(fù)雜轉(zhuǎn)發(fā)邏輯的分解很困難。在現(xiàn)有基于專用集成電路芯片(ASIC)的交換機上，OpenFlow1.0可以很容易地映射到AcL流水線之上，因此目前市場上支持OpenFlow的以太網(wǎng)交換機絕大多數(shù)都是只支持OpenFlow 1.0。
OpenFlow 1.x提供了多級流表模型，增加了更多的表匹配字段和指令類型，能力越來越強，但是離現(xiàn)有交換機ASIC的能力越來越遠。軟件交換機可以容易地實現(xiàn)OpenFlow1.x的多表模型。硬件交換機可以通過將自身的傳統(tǒng)ASIC流水線進行一些必要的封裝，形成多級流表上報給控制面，由控制面進行適配，只下發(fā)轉(zhuǎn)發(fā)面支持的指令和表結(jié)構(gòu)。這對轉(zhuǎn)發(fā)面和控制器均提出了更高的要求。業(yè)界也有少數(shù)廠商推出了可配置TCAM流水環(huán)節(jié)的ASIC，這些將固定寬度的TCAM查表處理單元分解成更小的分片，比如每32比特TCAM是一個基本分片。應(yīng)用可以靈活定義多個分片構(gòu)成一級OpenFlow流表，從而支持了OpenFlow的多級流表模型。應(yīng)用可以將L2交換、L3交換，路由、ACL等分解到不同的流表上實現(xiàn)，從而避免了超長單一流表關(guān)鍵字帶來的不必要的TCAM開銷。
4.結(jié)束語
SDN通過采用轉(zhuǎn)發(fā)控制分離、集中控制的理念改造網(wǎng)絡(luò)，試圖將轉(zhuǎn)發(fā)設(shè)備改造為簡單的受控轉(zhuǎn)發(fā)設(shè)備，將智能留在純軟件化的SDN控制器之中，使得網(wǎng)絡(luò)的創(chuàng)新更加快速、簡單，這帶來了開放的產(chǎn)業(yè)鏈和新的技術(shù)變革的機會。本文描述了作者及其團隊對于SDN相關(guān)關(guān)鍵技術(shù)的研究成果及SDN控制器產(chǎn)品實現(xiàn)架構(gòu)，并闡述了各種對比方案的優(yōu)劣勢。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.lukmueng.com/
本文標(biāo)題：軟件定義網(wǎng)絡(luò)關(guān)鍵技術(shù)及其實現(xiàn)
本文網(wǎng)址：http://m.lukmueng.com/html/consultation/10839712677.html
相關(guān)文章
