SDN-原理-技術(shù)-研究-應(yīng)用

第一章、SDN技術(shù)概覽1.1SDN定義SDN(softwareDefinedNetworking),軟件定義網(wǎng)絡(luò)是一種新興的基于軟件的網(wǎng)絡(luò)架構(gòu)及技術(shù)，其最大的特點(diǎn)在于具有松耦合的控制平面與數(shù)據(jù)平面、支持集中化的網(wǎng)絡(luò)狀態(tài)控制、實(shí)現(xiàn)底層網(wǎng)絡(luò)設(shè)施對(duì)上層應(yīng)用的透明。正如SDN的名字所言，它肯有靈活的軟件編程能力，使得網(wǎng)絡(luò)的自動(dòng)化管理和控制能力獲得了空前的提升，能夠有效地解決當(dāng)前網(wǎng)絡(luò)系統(tǒng)所面臨的資源規(guī)模擴(kuò)展受限、組網(wǎng)靈活性差、難以快速滿足業(yè)務(wù)需求等問題。SDN概念被提出的確切時(shí)間和最初起源很難考評(píng)清楚，這主要是因?yàn)闃I(yè)界一直以來就有很多的研發(fā)工作在向著SDN的方向努力。但是，在當(dāng)前來臨的這一波SDN浪潮中，ONF(OpenNetworkingFoundation,開發(fā)網(wǎng)絡(luò)基金會(huì))標(biāo)準(zhǔn)化組織無疑是潮流的引領(lǐng)者，其提出并倡導(dǎo)的基于OpenFlow的網(wǎng)絡(luò)架構(gòu)首次向業(yè)界全面系統(tǒng)地闡釋了SDN的重要特性，從面成為當(dāng)前SDN發(fā)展的重要基礎(chǔ)。面隨著SDN日益獲得關(guān)注成為網(wǎng)絡(luò)領(lǐng)域的焦點(diǎn)，其內(nèi)涵和外延也在不斷豐富中，不同的參與者從各自的角度出發(fā)提出了很多存在差異的對(duì)于SDN的理解，因此當(dāng)前存在著多種多樣的SDN定義。其中，最具有代表性的除了ONF從用戶角度出發(fā)定義的SDN架構(gòu)外，還有ETSI（EuropeanTelecommunicationsStandardsInstitue，歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)）從網(wǎng)絡(luò)運(yùn)營商角度出發(fā)提出的NFV（NetworkFunctionsVirtualization，網(wǎng)絡(luò)功能虛擬化）架構(gòu)。另外，2013年4月，思科、IBM、微軟等巨頭聯(lián)手推出名為OpenDaylight的開源SDN項(xiàng)目，雖然該項(xiàng)目并非以制定標(biāo)準(zhǔn)為目標(biāo)，但它非常有可能成為業(yè)界的事實(shí)標(biāo)準(zhǔn)。ONFSDN架構(gòu)定義ONF是一家非盈利的組織機(jī)構(gòu)，成立于2011年。ONF致力于SND的發(fā)展和標(biāo)準(zhǔn)化，是當(dāng)前業(yè)界最活躍、規(guī)模最大的SDN標(biāo)準(zhǔn)組織。在短短不到兩年的時(shí)間里，ONF成員人數(shù)就已經(jīng)人初創(chuàng)的23個(gè)發(fā)展到90多個(gè)，并在持續(xù)快速增長中，成員范圍涵蓋運(yùn)營商、網(wǎng)絡(luò)設(shè)備廠家、IT廠商、互聯(lián)網(wǎng)服務(wù)提供商等不同領(lǐng)域。ONF提出的SDN架構(gòu)如圖1-1所示。如圖1-1所示，ONF提出的SDN的典型架構(gòu)分為三層，最上層為應(yīng)用層，包括各種不同的業(yè)務(wù)和應(yīng)用；中間的控制層主要負(fù)責(zé)處理平面資源的編排，維護(hù)網(wǎng)絡(luò)拓?fù)?、狀態(tài)信息等；最下層的基礎(chǔ)設(shè)施層負(fù)責(zé)數(shù)據(jù)處理、轉(zhuǎn)發(fā)和狀態(tài)收集。除了上述三個(gè)層次之外，控制層與基礎(chǔ)設(shè)施層之間的接口和應(yīng)用層與控制層之間的接口與是SDN架構(gòu)中兩重要組成部分。按照接口與控制層的位置關(guān)系，前者通常被稱作南向接口，后者被稱作北向接口。其中，ONF在南向接口上定義了開放的OpenFlow標(biāo)準(zhǔn)，而在北向接口上還沒有作統(tǒng)一要求。因此，ONFSDN架構(gòu)更多的是從網(wǎng)絡(luò)資源用戶的角度出發(fā)，希望通過對(duì)網(wǎng)絡(luò)的抽象推動(dòng)更快的業(yè)務(wù)創(chuàng)新。ETSINFV架構(gòu)定義ETSI是由歐共體委員會(huì)于1988年批準(zhǔn)建立的一個(gè)非營利性的電信標(biāo)準(zhǔn)化組織，其標(biāo)準(zhǔn)化領(lǐng)域主要是信息通信技術(shù)。當(dāng)前，ETSI擁有來自世界各地的超過700家成員，成員覆蓋電信行政管理機(jī)構(gòu)、國家標(biāo)準(zhǔn)化組織、網(wǎng)絡(luò)運(yùn)營商、設(shè)備制造商、網(wǎng)絡(luò)業(yè)務(wù)提供者、用戶研究機(jī)構(gòu)等領(lǐng)域。作為網(wǎng)絡(luò)領(lǐng)域中極具影響力的標(biāo)準(zhǔn)化組織，ETSI很早就意識(shí)到了現(xiàn)有網(wǎng)絡(luò)存在的缺陷，ETST于2012年11月成立了專門用于討論NFV架構(gòu)和技術(shù)的ISG（IndustrySpecificationGroup，行業(yè)規(guī)范組），其目標(biāo)是基于軟件實(shí)現(xiàn)網(wǎng)絡(luò)功能并使之運(yùn)行在種類廣泛的業(yè)界標(biāo)準(zhǔn)設(shè)備上。ETSINFV的重點(diǎn)是網(wǎng)絡(luò)功能的虛擬化、更為關(guān)注當(dāng)前網(wǎng)絡(luò)中第4層到第7層的業(yè)務(wù)應(yīng)用，而與這對(duì)應(yīng)的底層網(wǎng)絡(luò)架構(gòu)則是支撐上層技術(shù)的基礎(chǔ)。雖然當(dāng)前ETSINFV的標(biāo)準(zhǔn)還在研究和討論中，最終的網(wǎng)絡(luò)架構(gòu)還沒有正式發(fā)布，便如圖1-2所示的NFV網(wǎng)絡(luò)架構(gòu)草案之一，就已經(jīng)部分地展現(xiàn)出了NFV的設(shè)計(jì)思想和主要觀點(diǎn)。如圖1-2所示的NFV網(wǎng)絡(luò)架構(gòu)草案在設(shè)計(jì)時(shí)參考了ONF的SDN定義，因此兩者具有相似之處，例如都實(shí)現(xiàn)了轉(zhuǎn)發(fā)層面與控制層面的分離，并在控制面之上提出了類似SDN中應(yīng)用層的虛擬化架構(gòu)的管理和編排層。同時(shí)，因?yàn)檫\(yùn)營商在ETSI成員中占據(jù)了非常重要的地位，所以期NFV網(wǎng)絡(luò)架構(gòu)中體現(xiàn)了多運(yùn)營商的需求和思路，例如：ETSINFV架構(gòu)在南向接口上，除了ONF倡導(dǎo)的OpenFlow協(xié)議之外，還包含了ForCES、PCE-P等之前已經(jīng)在IETF等傳統(tǒng)網(wǎng)絡(luò)標(biāo)準(zhǔn)化組織中獲得認(rèn)可的接口，這使得更廣泛的設(shè)備能在運(yùn)營商的網(wǎng)絡(luò)中被采用；另外，NFV架構(gòu)將控制層面進(jìn)行了更細(xì)致的劃分，提出了端到端（EndtoEnd,E2E）的網(wǎng)絡(luò)控制層，能夠?qū)Χ鄠€(gè)數(shù)據(jù)中心和不同技術(shù)制式提供支持，這主要是考慮了運(yùn)營商的規(guī)?；渴鸷瓦\(yùn)營的實(shí)際需求，同時(shí)也是為了規(guī)避只引入單一技術(shù)產(chǎn)品導(dǎo)致的廠商依賴性；在虛擬化架構(gòu)的管理和編排層，NFV從運(yùn)營商角度研究了如何通過網(wǎng)絡(luò)能力的高效管理和按需交付推動(dòng)網(wǎng)絡(luò)業(yè)務(wù)的創(chuàng)新，從面更著重考慮對(duì)網(wǎng)絡(luò)資源的調(diào)配能力。OpenDaylight開源項(xiàng)目2013年4月8日，OpenDaylight開源項(xiàng)目被推出，其參與者主要來自設(shè)備廠商，其中包括思科、Juniper等傳統(tǒng)網(wǎng)絡(luò)設(shè)備巨頭，IBM、微軟等傳統(tǒng)IT軟硬件設(shè)備巨頭，還包括Arista、BigSwitch等新興網(wǎng)絡(luò)設(shè)備廠商，以及VMware、紅帽、思杰等新興IT軟件廠商，這充分證明了SDN領(lǐng)域?yàn)闃I(yè)界帶來了更多的機(jī)會(huì)，使得更多的參與者能夠加入到SDN的研發(fā)和創(chuàng)新中。OpenDaylight開源項(xiàng)目與Linux基金會(huì)合作，其目標(biāo)是成為SDN架構(gòu)中的核心組件，使用戶能減少網(wǎng)絡(luò)運(yùn)營的復(fù)雜度，擴(kuò)展其現(xiàn)有網(wǎng)絡(luò)架構(gòu)中硬件的生命期，同時(shí)還能夠支持SDN新業(yè)務(wù)和新能力的創(chuàng)新。OpenDaylight開源項(xiàng)目的架構(gòu)如圖1-3所示。如圖1-3所示，OpenDaylight開源項(xiàng)目的架構(gòu)與ONFSDN類似，主要包括：與SDN基礎(chǔ)設(shè)備層對(duì)應(yīng)的數(shù)據(jù)平面網(wǎng)元（例如虛擬交換，物理設(shè)備等），以及相應(yīng)的南向接口（例如OpenFlow等標(biāo)準(zhǔn)協(xié)議及一些廠商專有的接口）；與SDN控制層對(duì)應(yīng)的控制層及相應(yīng)的基于REST的OpenDaylightAPI北向接口；與SDN應(yīng)用層對(duì)應(yīng)的網(wǎng)絡(luò)應(yīng)用、編排和服務(wù)層。OpenDaylight開源項(xiàng)目的主要內(nèi)容包括SDN控制器開發(fā)、南北向接口API的擴(kuò)展、用于多個(gè)控制器關(guān)聯(lián)的東西向協(xié)議實(shí)現(xiàn)等。SDN架構(gòu)的特征分析從上述介紹中可以看出，無論是ONFSDN架構(gòu)定義、ETSINVF架構(gòu)定義，還是OpenDaylight開源項(xiàng)目，它們?cè)跇I(yè)界都擁有眾多的擁護(hù)者，從面具有權(quán)威性。這三種不同的架構(gòu)在定義上存在共性，從中可以總結(jié)出業(yè)界普遍認(rèn)可的SDN應(yīng)具有的三大基本特征：集中控制：邏輯上集中的控制能夠支持獲得網(wǎng)絡(luò)資源的全局信息并根據(jù)業(yè)務(wù)需求進(jìn)行資源的全局調(diào)配和優(yōu)化，例如流量工程、負(fù)載均衡等。同時(shí)，集中控制還使得整個(gè)網(wǎng)絡(luò)可在邏輯上被視作是一臺(tái)設(shè)備進(jìn)行運(yùn)行和維護(hù)，無須對(duì)物理設(shè)備進(jìn)行現(xiàn)場配置，從面提升了網(wǎng)絡(luò)控制的便捷性。開放接口：通過開放南向和北向接口，能夠?qū)崿F(xiàn)應(yīng)用和網(wǎng)絡(luò)的無縫集成，使得應(yīng)用能告知網(wǎng)絡(luò)如何運(yùn)行才能更好地滿足應(yīng)用的需求，比如業(yè)務(wù)的帶寬、時(shí)長需求，計(jì)費(fèi)對(duì)路由的影響等。另外，支持用戶基于開放接口自行開發(fā)網(wǎng)絡(luò)業(yè)務(wù)并調(diào)用資源，加快新業(yè)務(wù)的上線周期。網(wǎng)絡(luò)虛擬化：通過南向接口的統(tǒng)一和開放，屏蔽了底層物理轉(zhuǎn)發(fā)設(shè)備的差異，實(shí)現(xiàn)了底層網(wǎng)絡(luò)對(duì)上層應(yīng)用的透明化。邏輯網(wǎng)絡(luò)和物理網(wǎng)絡(luò)分離后，邏輯網(wǎng)絡(luò)可以根據(jù)業(yè)務(wù)需要進(jìn)行配置、遷移、不再受具體設(shè)備物理位置的限制。同時(shí)，邏輯網(wǎng)絡(luò)還支持多租戶共享，支持租戶網(wǎng)絡(luò)定制需求。簡而言這，SDN支持控制平面與轉(zhuǎn)發(fā)平面的分享，使得對(duì)網(wǎng)絡(luò)設(shè)備的集中控制成為可能。以O(shè)penFlow為代表的南向接口的提出使得底層的轉(zhuǎn)發(fā)設(shè)備可以被統(tǒng)一控制和管理，而其具體的物理實(shí)現(xiàn)將被透明化，從而實(shí)現(xiàn)設(shè)備的虛擬化。多種多樣的開放接口，將推動(dòng)網(wǎng)絡(luò)能力被便捷地調(diào)用，支持網(wǎng)絡(luò)業(yè)務(wù)的創(chuàng)新。同時(shí)，因?yàn)镾DN定義的提出者具有不同的背景，所以每個(gè)定義上都存在一定的差異性，例如ONFSDN架構(gòu)以O(shè)penFlow協(xié)議為基礎(chǔ)，并將其作為架構(gòu)中唯一的南向接口協(xié)議；而ETSINFV架構(gòu)和OpenDaylight開源項(xiàng)目，在南向接口方面除了OpenFlow之外還會(huì)有更豐富的選擇。SDN發(fā)展背景本質(zhì)上看，分離網(wǎng)絡(luò)的控制平面與轉(zhuǎn)發(fā)平面、實(shí)現(xiàn)網(wǎng)絡(luò)狀態(tài)的集中控制、支持靈活的軟件編程等SDN的核心理念在網(wǎng)絡(luò)領(lǐng)域并不是什么新鮮事，業(yè)界曾經(jīng)對(duì)其開展了很多有益的研究和探索，但是長久以為一直沒有獲得非常卓著的成效。直到近年，SDN才重新引起業(yè)務(wù)的廣泛關(guān)注，那么究竟為什么SDN會(huì)在這個(gè)時(shí)刻爆發(fā)？其最關(guān)鍵的原因是以云計(jì)算、大數(shù)據(jù)為代表的新興業(yè)務(wù)所具有的需求推動(dòng)了網(wǎng)絡(luò)的這變革。從所周知，伴隨著云計(jì)算及其相關(guān)業(yè)務(wù)的發(fā)展，服務(wù)器的應(yīng)用需求產(chǎn)生了爆炸性的增長。受制于空間、能源等相關(guān)因素的影響，單純使用物理服務(wù)器已經(jīng)無法滿足使用需求的增長。同時(shí)，單一物理服務(wù)器所具有的高運(yùn)算能力也使得它可以承擔(dān)更多的負(fù)載，于是以服務(wù)器虛擬化為代表的虛擬化技術(shù)日益成為主流。利用虛擬化軟件創(chuàng)建的虛擬機(jī)，用戶所需要的資源可以被動(dòng)態(tài)地分配，實(shí)現(xiàn)建立、刪除、移動(dòng)、變更等靈活的操作。但是，這也為相應(yīng)的網(wǎng)絡(luò)資源配置帶來了巨大的壓力，例如虛擬機(jī)可能會(huì)因?yàn)橘Y源優(yōu)化或負(fù)載均衡等原因進(jìn)行移動(dòng)，從面導(dǎo)致對(duì)應(yīng)物理節(jié)點(diǎn)上的數(shù)據(jù)游特征發(fā)生變化，同時(shí)虛擬機(jī)在遷移前后的網(wǎng)絡(luò)尋址策略、命名空間等也可能出現(xiàn)沖突。另外，在當(dāng)前的環(huán)境中，業(yè)務(wù)應(yīng)用通常不再僅僅局限在單臺(tái)服務(wù)器中運(yùn)行，而可能分布部署在多臺(tái)彼此進(jìn)行數(shù)據(jù)通信的物理服務(wù)器或者虛擬機(jī)上，這就導(dǎo)致了橫向數(shù)據(jù)流量的增加和變化，與這相應(yīng)的網(wǎng)絡(luò)資源也需要能根據(jù)流量模式的變化做及時(shí)調(diào)整。隨著社交網(wǎng)絡(luò)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等業(yè)務(wù)領(lǐng)域的快速發(fā)展，大數(shù)據(jù)（BigData）正日益成為當(dāng)前的焦點(diǎn)，其面向的海量數(shù)據(jù)處理也對(duì)網(wǎng)絡(luò)提出了更高的要求。大數(shù)據(jù)應(yīng)用依賴于預(yù)先定義好的計(jì)算模式，在集中化的管理架構(gòu)下運(yùn)行，存在著大量的數(shù)據(jù)批量傳輸及相關(guān)的聚合、劃分操作。數(shù)據(jù)的聚合和劃分通常發(fā)生在一臺(tái)服務(wù)器和一個(gè)擁有眾多服務(wù)器的服務(wù)器組之間，這也是大數(shù)據(jù)應(yīng)用中最典型的網(wǎng)絡(luò)流量模式。例如，在用于大數(shù)據(jù)處理的MapReduce算法的執(zhí)行過程中，來自眾多Mapper服務(wù)器的中間結(jié)果需要集中匯總到一臺(tái)Reducer服務(wù)器上進(jìn)行歸約操作，而MapReduce的Shuffle過程更是由Mapper和Deducer之前的多次數(shù)據(jù)聚合組成而成。大數(shù)據(jù)處理過程中的每一次聚合都將導(dǎo)致大量服務(wù)器之間的海量數(shù)據(jù)交換，從而需要極高的網(wǎng)絡(luò)帶寬支持，而如果按照超額認(rèn)購帶寬的方式為每臺(tái)服務(wù)器預(yù)留網(wǎng)絡(luò)資源，將導(dǎo)致網(wǎng)絡(luò)瓶頸，同時(shí)造成資源浪費(fèi)。因此，對(duì)于大數(shù)據(jù)業(yè)務(wù)而言，它更需要對(duì)網(wǎng)絡(luò)進(jìn)行快速、頻繁的實(shí)時(shí)配置，按需調(diào)用網(wǎng)絡(luò)資源。但是，傳統(tǒng)的網(wǎng)絡(luò)卻難以滿足云計(jì)算、大數(shù)據(jù)，以及相關(guān)業(yè)務(wù)提出的靈活的資源需求，這主要是因?yàn)樗呀?jīng)過于復(fù)雜從面只能處理靜態(tài)的動(dòng)作模式。當(dāng)前，網(wǎng)絡(luò)中存在著大量各樣的互不相干的協(xié)議，它們被用于在不同間隔距離、不同的鏈接速度、不同的拓?fù)浼軜?gòu)的網(wǎng)絡(luò)主機(jī)這間建立網(wǎng)絡(luò)連接。因?yàn)闅v史原因，這些協(xié)議的研發(fā)和應(yīng)用通常是彼此隔離的，每個(gè)協(xié)議通常只是為了解決某個(gè)專門的問題缺少對(duì)共性問題的的抽象，這就導(dǎo)致了當(dāng)前網(wǎng)絡(luò)中的復(fù)雜性。例如，為了在網(wǎng)絡(luò)中增加或者刪除一臺(tái)設(shè)備，管理者們往往需要利用設(shè)備級(jí)的管理工具對(duì)與之相關(guān)的多臺(tái)交換機(jī)、路由器、Web認(rèn)證門戶等進(jìn)行操作以更新相應(yīng)的ACL、VLAN設(shè)置、Qos及其他一些基于協(xié)議的機(jī)制。除此這外，網(wǎng)絡(luò)拓?fù)錂C(jī)構(gòu)、廠商交換機(jī)模型、軟件版本等信息也需要被通盤考慮。傳統(tǒng)網(wǎng)絡(luò)的復(fù)雜性增加了網(wǎng)絡(luò)管理的難度，進(jìn)面導(dǎo)致網(wǎng)絡(luò)的脆弱性。例如，如果在全網(wǎng)范圍內(nèi)下發(fā)策略，管理員通常需要配置不計(jì)其數(shù)的網(wǎng)絡(luò)設(shè)備和策略機(jī)制，同時(shí)還很難確保網(wǎng)絡(luò)策略在接入、安全、QOS等方面能夠保持一致，所以非常容易出現(xiàn)策略不合規(guī)、網(wǎng)絡(luò)安全降低等情況，這些對(duì)于業(yè)務(wù)應(yīng)用的運(yùn)行都是致命的因素。正是因?yàn)樯鲜龅膹?fù)雜性，傳統(tǒng)網(wǎng)絡(luò)通暢是維持在相對(duì)靜態(tài)的狀態(tài)，網(wǎng)絡(luò)管理員通常都要盡可能地減少網(wǎng)絡(luò)的變動(dòng)以避免服務(wù)中斷的風(fēng)險(xiǎn)。正是在這一背景下，SDN的概念被大家廣泛接受和認(rèn)同。邏輯上集中的控制層面能夠支持網(wǎng)絡(luò)資源的靈活調(diào)度，靈活的開放接口能夠支持網(wǎng)絡(luò)能力的按需調(diào)用，標(biāo)準(zhǔn)統(tǒng)一的南向接口能夠?qū)崿F(xiàn)網(wǎng)絡(luò)設(shè)備的虛擬透明。這者有助于地SDN去改變網(wǎng)絡(luò)的靜態(tài)化現(xiàn)狀，并與以服務(wù)器領(lǐng)域?yàn)榇淼膭?dòng)態(tài)化趨勢相吻合，能夠有力地為云計(jì)算、大數(shù)據(jù)、以及更多的創(chuàng)新業(yè)務(wù)提供網(wǎng)絡(luò)支持。SDN實(shí)現(xiàn)方案如前所述，SDN核心理念是控制平面和轉(zhuǎn)發(fā)平面的分離、支持全局的軟件控制。遵循這一理念，各種類型的廠商結(jié)合自身優(yōu)勢提出了很多類型的實(shí)現(xiàn)方案，總體可分為三類：基于專用接口的方案、基于疊加的網(wǎng)絡(luò)方案和基于開放協(xié)議的方案，如圖1-4所示。如圖所示，不同的SDN實(shí)現(xiàn)方案擁有不同的架構(gòu)和技術(shù)，具體說明如下：基于專用按口的方案基于專用接口的方案的實(shí)現(xiàn)思路是不改變傳統(tǒng)網(wǎng)絡(luò)的實(shí)現(xiàn)機(jī)制和工作方式，通過對(duì)網(wǎng)絡(luò)設(shè)備的操作系統(tǒng)進(jìn)行升級(jí)改造，在網(wǎng)絡(luò)設(shè)備上開發(fā)出專用的API接口，管理人員可能通過API接口實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備的統(tǒng)一配置管理和下發(fā)，改變?cè)刃枰慌_(tái)臺(tái)設(shè)備登錄配置的手工操作方式，同時(shí)這些接口也可供用戶開發(fā)網(wǎng)絡(luò)應(yīng)用，實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備的可編程。這類方案由目前主流的網(wǎng)絡(luò)設(shè)備廠商主導(dǎo)。典型的基于專用接口的SDN實(shí)現(xiàn)方案是思科的onePK(onePlatformKit，平臺(tái)軟件開發(fā)套件)，它是思科的ONE（OpenNetworkEnvironment,開放式網(wǎng)絡(luò)環(huán)境）的一部分。ONE是思科的SDN戰(zhàn)略，其目標(biāo)是構(gòu)建一個(gè)完整開放的網(wǎng)絡(luò)環(huán)境，使得網(wǎng)絡(luò)更靈活、可定制，以便適應(yīng)更新型的網(wǎng)絡(luò)和IT趨勢，其內(nèi)容主要包括三方面：用于對(duì)思科的網(wǎng)絡(luò)硬件進(jìn)行編程的onePK接口、由支持OpenFlow協(xié)議和onePK接口的控制器和交換設(shè)備組成的軟件定義網(wǎng)絡(luò)，以及用于云計(jì)算場景可與多種虛擬化平臺(tái)整合的虛擬網(wǎng)絡(luò)設(shè)備（如Nexus1000V）。onePK作為ONE戰(zhàn)略的重要組成部分，主要提供了一個(gè)網(wǎng)絡(luò)編程環(huán)境，可以直接對(duì)思科的各種設(shè)備進(jìn)行可編程操作，如圖1-5所示。如圖1-5所示，思科的onePK實(shí)現(xiàn)方案分為多個(gè)層次，即包括面向底層的網(wǎng)絡(luò)設(shè)備接口，與包括面向上層的業(yè)務(wù)開放接口。onePK能夠?qū)Ω鞣N現(xiàn)有的思科操作系統(tǒng)和硬件平臺(tái)進(jìn)行深入的編程訪問，其被推出的主要目的是應(yīng)對(duì)OpenFlow在網(wǎng)絡(luò)架構(gòu)和設(shè)備等方面造成的巨大挑戰(zhàn)和沖擊?；趯Ｓ媒涌诘腟DN實(shí)現(xiàn)方案的最大優(yōu)點(diǎn)是能夠依托網(wǎng)絡(luò)設(shè)備廠商已有的產(chǎn)品體系，對(duì)現(xiàn)有的網(wǎng)絡(luò)部署改動(dòng)小，實(shí)施部署方便快捷。但是，因?yàn)樵擃惙桨钢薪涌谂c設(shè)備之間存在緊密耦合關(guān)系，所以它仍舊是一個(gè)封閉系統(tǒng)的解決方案，存在著網(wǎng)絡(luò)設(shè)備和能力被廠商鎖定的風(fēng)險(xiǎn)?；诏B加網(wǎng)絡(luò)的方案基于疊加網(wǎng)絡(luò)的方案的實(shí)現(xiàn)思路是以現(xiàn)行的IP網(wǎng)絡(luò)為基礎(chǔ)，在其上建立疊加的邏輯網(wǎng)絡(luò)（OverlayLogicalNetwork），屏蔽掉底層物理網(wǎng)絡(luò)差異，實(shí)現(xiàn)網(wǎng)絡(luò)資源的虛擬化，使得多個(gè)邏輯上彼此隔離的網(wǎng)絡(luò)分區(qū)，以及多種異構(gòu)的虛擬網(wǎng)絡(luò)可以在同一共享網(wǎng)絡(luò)基礎(chǔ)設(shè)施上共存。該類方案的主要思想可被歸納為解耦、獨(dú)立、控制三個(gè)方面。解耦是指將網(wǎng)絡(luò)的控制從網(wǎng)絡(luò)物理硬件中脫離出來，交給虛擬化的網(wǎng)絡(luò)層處理。這個(gè)虛擬化網(wǎng)絡(luò)層加載在物理網(wǎng)絡(luò)這上，屏蔽掉底層的物理差異，在虛擬的空間重建整個(gè)網(wǎng)絡(luò)。因此，物理網(wǎng)絡(luò)資源將被泛化成網(wǎng)絡(luò)池，正如服務(wù)器虛擬化技術(shù)把服務(wù)器資源轉(zhuǎn)化為計(jì)算能力池一樣，它使得網(wǎng)絡(luò)資源的調(diào)用更加靈活，滿足用戶對(duì)網(wǎng)絡(luò)資源的按需交付需求。獨(dú)立是指該類方案承載于IP網(wǎng)絡(luò)這上，因此只要IP可達(dá)，那么相應(yīng)的虛擬化網(wǎng)絡(luò)就可以被部署，而無需對(duì)原有物理網(wǎng)絡(luò)架構(gòu)（例如原有的網(wǎng)絡(luò)硬件、原有的服務(wù)器虛擬化解決方案、原有的網(wǎng)絡(luò)管理體統(tǒng)、原有的IP地址等等）做出任何改變。該類方案可以便捷地在現(xiàn)網(wǎng)上部署和實(shí)施，這是它最大的優(yōu)勢?？刂剖侵腐B加的邏輯網(wǎng)絡(luò)將以軟件可編程的方式被統(tǒng)一控制。通過應(yīng)用該方案，網(wǎng)絡(luò)資源可以和計(jì)算資源、存儲(chǔ)資源一起被統(tǒng)一調(diào)度和按需交付。以虛擬交換機(jī)為代表的虛擬化網(wǎng)絡(luò)設(shè)備可以被整合在服務(wù)器虛擬化管理程序（Hypervisor）中統(tǒng)一部署，也可以以軟件方式部署在網(wǎng)關(guān)中實(shí)現(xiàn)與外部物理網(wǎng)絡(luò)的整合。各種虛擬化網(wǎng)絡(luò)設(shè)備協(xié)同工作，在資源管理平臺(tái)的統(tǒng)一控制下，通過在節(jié)點(diǎn)間按需搭建虛擬網(wǎng)絡(luò)，實(shí)現(xiàn)網(wǎng)絡(luò)資源的虛擬化。基于疊加網(wǎng)絡(luò)的方案并不是新近才被提出的，VLAN就是典型的代表。但是，隨著云計(jì)算等新興業(yè)務(wù)對(duì)網(wǎng)絡(luò)要求的提升，傳統(tǒng)的技術(shù)已經(jīng)難以滿足要求，例如業(yè)務(wù)只局限于同一二層網(wǎng)絡(luò)、VLAN數(shù)量有限影響多租戶業(yè)務(wù)規(guī)模等等。在當(dāng)前的基于疊加網(wǎng)絡(luò)的SDN實(shí)現(xiàn)領(lǐng)域，隧道（tunneling）技術(shù)被廣泛應(yīng)用，它可以基于現(xiàn)行的IP網(wǎng)絡(luò)進(jìn)行疊加部署，消除傳統(tǒng)二層網(wǎng)絡(luò)的限制。很多新興的協(xié)議都采用了隧道的原理進(jìn)行網(wǎng)絡(luò)通信，例如VXLAN、NVGRE等。它們均利用疊加在三層網(wǎng)絡(luò)之上的虛擬網(wǎng)絡(luò)傳遞二層數(shù)據(jù)包，實(shí)現(xiàn)了可以跨越三層物理網(wǎng)絡(luò)進(jìn)行通信的二層邏輯網(wǎng)絡(luò)，突破了傳統(tǒng)二層網(wǎng)絡(luò)中存在的物理位置受限、VLAN數(shù)量有限等障礙，同時(shí)還使得網(wǎng)絡(luò)支持服務(wù)的可移動(dòng)性，大幅度降低管理的成本和運(yùn)營的風(fēng)險(xiǎn)。該類方案主要由虛擬化技術(shù)廠商主導(dǎo)，例如VMware在其虛擬化平臺(tái)中實(shí)現(xiàn)VXLAN技術(shù)、微軟在其虛擬化平臺(tái)中實(shí)現(xiàn)了VVGRE技術(shù)，而其中最典型的代表是Nicira公司提出的NVP（NetworkVirtualizationPlatform,網(wǎng)絡(luò)虛擬化平臺(tái)）方案。NVP支持在現(xiàn)有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施上利用隧道技術(shù)屏蔽底層物理網(wǎng)絡(luò)的實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)了網(wǎng)絡(luò)虛擬化，并利用邏輯上集中的軟件進(jìn)行統(tǒng)一管控，實(shí)現(xiàn)網(wǎng)絡(luò)資源的按需高度。該類解決方案與虛擬化管理地的整合較便捷，但是在實(shí)際實(shí)施和應(yīng)用中，其效果會(huì)受到底層網(wǎng)絡(luò)質(zhì)量的影響。同時(shí)，基于網(wǎng)絡(luò)疊加的技術(shù)會(huì)增加網(wǎng)絡(luò)架構(gòu)的復(fù)雜度，并降低數(shù)據(jù)的處理性能?；陂_放協(xié)議的方案基于專用開放協(xié)議的方案是當(dāng)前SDN實(shí)現(xiàn)的主流方案，ONFSDN和ETSINFV都屬于這類解決方案，該類解決方案基于開放的網(wǎng)絡(luò)協(xié)議，實(shí)現(xiàn)控制平面與轉(zhuǎn)發(fā)平面的分離，支持控制全局化，獲得了最多的產(chǎn)業(yè)支持，相關(guān)技術(shù)進(jìn)展很快，產(chǎn)業(yè)規(guī)模發(fā)展迅速，業(yè)界影響力最大。SDN實(shí)現(xiàn)方案分析在三種SDN典型實(shí)現(xiàn)方案中，都能夠支持邏輯上集中的網(wǎng)絡(luò)控制系統(tǒng)，并且具有豐富靈活的軟件接口供上層調(diào)用底層設(shè)備能力。同時(shí)，轉(zhuǎn)發(fā)層面設(shè)備的能力都被隱藏在軟件接口之下，使設(shè)備的物理差異透明化。這都充分體現(xiàn)了其SDN特征。其中，開放協(xié)議是最具革命性的技術(shù)流派，通過開放的架構(gòu)和運(yùn)作方式獲得最廣泛的支持，也是業(yè)務(wù)創(chuàng)新最活躍的流派；專用接口是傳統(tǒng)網(wǎng)絡(luò)設(shè)備廠商為了在SDN大潮來臨之時(shí)繼續(xù)保持其領(lǐng)先地位而做出的妥協(xié)；基于疊加網(wǎng)絡(luò)的虛擬化是當(dāng)前的一項(xiàng)熱門技術(shù)，通過屏蔽底層物理設(shè)備的差異實(shí)現(xiàn)網(wǎng)絡(luò)資源的池化，能夠很好地滿足云計(jì)算數(shù)據(jù)中心內(nèi)部和中心之間的虛擬機(jī)遷移等業(yè)務(wù)場景的網(wǎng)絡(luò)需求。SDN核心技術(shù)頂層的架構(gòu)可以與人的身體做類比：控制層就是人的大腦，負(fù)責(zé)對(duì)人身體的總體管控；轉(zhuǎn)發(fā)層的設(shè)備是人的四肢，在大腦的控制下進(jìn)行各種活動(dòng)；應(yīng)用層對(duì)應(yīng)的各種創(chuàng)新的想法，大腦在它們的驅(qū)動(dòng)下對(duì)四肢進(jìn)行指揮以達(dá)到其所需的效果；南向接口和北向接口則分別相當(dāng)于人體內(nèi)的神經(jīng)和腦電波，負(fù)責(zé)各種信號(hào)的上傳下達(dá)。從類比中可以看出：作為四肢的轉(zhuǎn)發(fā)層，其處理性能一定要高，而其本身可以不做更多的思考面成為“傻”設(shè)備；作為大腦的控制層，其控制邏輯一定要周全，能夠根據(jù)全局的網(wǎng)絡(luò)視圖作出合理的資源調(diào)配決策；作為創(chuàng)新想法的應(yīng)用層，其工作充分利用大腦提供的能力完成各種花樣翻新的任務(wù)，同時(shí)針對(duì)自身需要向大腦提出新的能力需求?；谏鲜龇治觯琒DN中引入了很多創(chuàng)新以支撐相應(yīng)的需求。遵循SDN的層次架構(gòu)，SDN核心技術(shù)體系如圖1-6所示。交換機(jī)及南向接口技術(shù)SDN交換機(jī)是SDN網(wǎng)絡(luò)中負(fù)責(zé)具體數(shù)據(jù)轉(zhuǎn)發(fā)處理的設(shè)備。本質(zhì)上看，傳統(tǒng)設(shè)備中無論是交換機(jī)還是路由器，其工作原理都是在收到數(shù)據(jù)時(shí)，將數(shù)據(jù)包中的某些特征域與設(shè)備自身存儲(chǔ)的一些表項(xiàng)進(jìn)行比對(duì)，當(dāng)發(fā)現(xiàn)匹配時(shí)則按照表項(xiàng)的要求進(jìn)行相應(yīng)處理。SDN交換機(jī)也是類似的原理，但是與傳統(tǒng)設(shè)備存在差異的是，設(shè)備中的各個(gè)表項(xiàng)并非是由設(shè)備自身根據(jù)周邊的網(wǎng)絡(luò)環(huán)境在本地自行生成的，而是由遠(yuǎn)程控制器統(tǒng)一下發(fā)的，因此各種復(fù)雜的控制邏輯（例如鏈路發(fā)現(xiàn)、地址學(xué)習(xí)、路由計(jì)算等等）都無需在SDN交換機(jī)實(shí)現(xiàn)。SDN交換機(jī)可以忽略控制邏輯的實(shí)現(xiàn)，全力關(guān)注基于表項(xiàng)的數(shù)據(jù)處理，而數(shù)據(jù)處理的性能也就成為評(píng)價(jià)SDN交換機(jī)優(yōu)劣的最關(guān)鍵指標(biāo)，因此，很多高性能轉(zhuǎn)發(fā)技術(shù)被提出，例如基于多張表以流水線方式進(jìn)行調(diào)整處理的技術(shù)。另外，考慮到SDN和傳統(tǒng)網(wǎng)絡(luò)的混合工作問題，支持混合模式的SDN交換機(jī)也是當(dāng)前設(shè)備層技術(shù)研發(fā)的焦點(diǎn)。同時(shí)，隨著虛擬化技術(shù)的出現(xiàn)和完善，虛擬化環(huán)境將是SDN交換機(jī)的一個(gè)重要應(yīng)用場景，因此SDN交換機(jī)可能會(huì)有硬件、軟件等多種形態(tài)。例如，OVS（OpenVswitch，開放虛擬交換標(biāo)準(zhǔn)）交換機(jī)就是一款基于開源軟件技術(shù)實(shí)現(xiàn)的能夠集成在服務(wù)器虛擬化Hypervisor中的交換機(jī)，具備完善的交換機(jī)功能，在虛擬化組網(wǎng)中起到了重要的作用。SDN交換機(jī)需要在遠(yuǎn)程控制器的管控下工作，與之相關(guān)的設(shè)備狀態(tài)和控制指令都需要經(jīng)由SDN的南向接口傳達(dá)。當(dāng)前，最知名的南向接口莫過于ONF倡導(dǎo)的OpenFlow協(xié)議。作為一個(gè)開放的協(xié)議，OpenFlow突破了傳統(tǒng)網(wǎng)絡(luò)設(shè)備廠商對(duì)設(shè)備能力的接口壁壘，經(jīng)過多年的發(fā)展，在業(yè)界的共同努力下，當(dāng)前已經(jīng)日臻完善，能夠全面解決SDN網(wǎng)絡(luò)中面臨的各種問題。當(dāng)前，OpenFlow已經(jīng)獲得了業(yè)界的廣泛支持，并成為了SDN領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，例如前文提及的OVS交換機(jī)就能夠支持OpenFLow協(xié)議。OpenFLow解決了如何由控制層把SDN交換機(jī)所需的用于和數(shù)據(jù)流做匹配的表項(xiàng)下發(fā)給轉(zhuǎn)發(fā)層設(shè)備的問題，同時(shí)ONF還提出來OF-CONFIG協(xié)議，用于對(duì)SDN交換機(jī)進(jìn)行遠(yuǎn)程配置和管理，其目標(biāo)都是為了更好地對(duì)分散部署的SDN交換機(jī)實(shí)現(xiàn)集中化管控?？刂破骷氨毕蚪涌诩夹g(shù)SDN控制器負(fù)責(zé)整個(gè)網(wǎng)絡(luò)的運(yùn)行，是提升SDN網(wǎng)絡(luò)效率的關(guān)鍵。SDN交換機(jī)的“去智能化”、OpenFlow等南向接口的開放，產(chǎn)生了很多新的機(jī)會(huì)，使得更多人能夠投身于控制器的設(shè)計(jì)與實(shí)現(xiàn)中。當(dāng)前，業(yè)界有很多基于OpenFlow控制協(xié)議的開源控制器實(shí)現(xiàn)，例如NOX、Onix、Floodligh等，它們都有各自的特色設(shè)計(jì)，能夠?qū)崿F(xiàn)鏈路發(fā)現(xiàn)、拓?fù)涔芾?、策略制定、表?xiàng)下發(fā)等支持SDN網(wǎng)絡(luò)運(yùn)行的基本操作。雖然不同的控制器在功能和性能上仍舊存在差異，但是從中已經(jīng)可以總結(jié)出SDN控制器應(yīng)當(dāng)具備的技術(shù)特征，從這些開源系統(tǒng)的研發(fā)與實(shí)踐中得到的經(jīng)驗(yàn)和教訓(xùn)將有助于推動(dòng)SDN控制器的規(guī)范化發(fā)展。另外，用于網(wǎng)絡(luò)集中化控制的控制器作為SDN網(wǎng)絡(luò)的核心，其性能和安全性非常重要，其可能存在負(fù)載過大、單點(diǎn)失效等問題一直是SDN領(lǐng)域中亟待解決的問題。當(dāng)前，業(yè)界對(duì)此也有了很多探討，從部署架構(gòu)、技術(shù)措施等多個(gè)方面提出了很多有創(chuàng)見的方法。SDN北向接口是通過控制器向上層業(yè)務(wù)應(yīng)用開放的接口，其目標(biāo)是使得業(yè)務(wù)應(yīng)用能夠便利地調(diào)用底層的網(wǎng)絡(luò)資源和能力。北向接口直接為應(yīng)用服務(wù)的，其設(shè)計(jì)需要密切聯(lián)系業(yè)務(wù)應(yīng)用需求，具有多樣化的牲征。同時(shí)，北向接口的設(shè)計(jì)是否合理、便捷，以便能被業(yè)務(wù)應(yīng)用廣泛調(diào)用，會(huì)直接影響到SDN控制器廠商的市場前景。因此，與南向接口方面已有OpenFlow等國際標(biāo)準(zhǔn)不同，北向接口方面還缺少業(yè)務(wù)公認(rèn)的標(biāo)準(zhǔn)，成為當(dāng)前SDN領(lǐng)域競爭的焦點(diǎn)，不同的參與者或者從用戶角度出發(fā)，或者從運(yùn)營角度出發(fā)，或者從產(chǎn)品能力角度提了提出了很多解決方案。雖然北向接口標(biāo)準(zhǔn)當(dāng)前還很難達(dá)成共識(shí)，但是充分的開放性、便捷性、靈活性將是衡量接口優(yōu)劣的重要標(biāo)準(zhǔn)，例如RESTAPI就是上層業(yè)務(wù)應(yīng)用的開發(fā)者比較喜歡的接口形式。部分傳統(tǒng)的網(wǎng)絡(luò)設(shè)備廠商在其現(xiàn)在設(shè)備上提供了編程接口業(yè)務(wù)應(yīng)用直接調(diào)用，也可被視作北向接口之一，其目的是在不改變現(xiàn)在設(shè)備架構(gòu)的條件下提升配置管理靈活性，應(yīng)對(duì)開放協(xié)議的競爭。應(yīng)用編排和資源管理技術(shù)SDN網(wǎng)絡(luò)的最終目標(biāo)是服務(wù)于多樣化的應(yīng)用創(chuàng)新。因此隨著SDN技術(shù)的部署和推廣，將會(huì)有越來越多的業(yè)務(wù)應(yīng)用被研發(fā)，這類應(yīng)用將能夠更便捷地通過SDN北向接口調(diào)用底層能力，按需使用網(wǎng)絡(luò)資源。SDN推動(dòng)業(yè)務(wù)創(chuàng)新已經(jīng)是業(yè)界不爭的事實(shí)，它可以被廣泛地應(yīng)用在云數(shù)據(jù)中心、寬帶傳輸網(wǎng)絡(luò)、移動(dòng)網(wǎng)絡(luò)等種種場景中，其中為云計(jì)算業(yè)務(wù)提供網(wǎng)絡(luò)服務(wù)就是一個(gè)非常典型的案例。眾所周知，在當(dāng)前的云計(jì)算業(yè)務(wù)中，服務(wù)器虛擬化、存儲(chǔ)虛擬化都已經(jīng)被廣泛應(yīng)用，它們將底層的物理資源進(jìn)行池化共享，進(jìn)而按需分配給用戶使用。相比之下，傳統(tǒng)的網(wǎng)絡(luò)資源遠(yuǎn)遠(yuǎn)沒有達(dá)到類似的靈活性，而SDN的引入則能夠很好地解決這一問題。SDN通過標(biāo)準(zhǔn)的南向接口屏蔽了底層物理轉(zhuǎn)發(fā)設(shè)備的差異，實(shí)現(xiàn)了資源的虛擬化，同時(shí)開放了靈活的北向接口供上層業(yè)務(wù)按需進(jìn)行網(wǎng)絡(luò)配置并調(diào)用網(wǎng)絡(luò)資源。云計(jì)算領(lǐng)域中知名的OpenStack就是可以工作在SDN應(yīng)用層的云管理平臺(tái)，通過在其網(wǎng)絡(luò)資源組件中增加SDN管理插件，管理者和使用者可利用SDN北向接口便捷地調(diào)用SDN控制器對(duì)外開放的網(wǎng)絡(luò)能力。當(dāng)有云主機(jī)組網(wǎng)需求（例如建立用戶專有的VLAN）被發(fā)出時(shí)，相關(guān)的網(wǎng)絡(luò)策略和配置可以在OpenStack管理平臺(tái)的界面上集中制定并進(jìn)面驅(qū)動(dòng)SDN控制器統(tǒng)一地自動(dòng)下發(fā)到相關(guān)的網(wǎng)絡(luò)設(shè)備上。因此，網(wǎng)絡(luò)資源可以和其他類型的虛擬化資源一樣，以抽象的資源能力的面貌統(tǒng)一呈現(xiàn)給業(yè)務(wù)應(yīng)用開發(fā)者，開發(fā)者無需針對(duì)底層網(wǎng)絡(luò)設(shè)備的差異耗費(fèi)大量開銷從事額外的適配工作，這有助于業(yè)務(wù)應(yīng)用的快速創(chuàng)新。本章小結(jié)隨著云計(jì)算、大數(shù)據(jù)等新興業(yè)務(wù)對(duì)網(wǎng)絡(luò)支持的要求越來越高，SDN的概念應(yīng)運(yùn)而生并日漸深入人心，它所倡導(dǎo)的控制與轉(zhuǎn)發(fā)分離、邏輯上集中化的控制、豐富靈活的開放編程接口都將是未來網(wǎng)絡(luò)發(fā)展的方向。SDN擺脫了傳統(tǒng)硬件網(wǎng)絡(luò)設(shè)備的束縛，通過標(biāo)準(zhǔn)化的控制器南向接口協(xié)議實(shí)現(xiàn)了底層網(wǎng)絡(luò)設(shè)備的虛擬化，能夠支持遠(yuǎn)程控制器的集中化配置和管理。同時(shí)，SDN控制器為上層網(wǎng)絡(luò)應(yīng)用提供了豐富的編程接口API，使得網(wǎng)絡(luò)應(yīng)用能夠靈活地調(diào)用底層的網(wǎng)絡(luò)能力，推動(dòng)網(wǎng)絡(luò)應(yīng)用的創(chuàng)新。遵循著上述理念，越來越多的SDN技術(shù)和產(chǎn)品被提出和應(yīng)用，并在數(shù)據(jù)中心網(wǎng)絡(luò)、運(yùn)營商網(wǎng)絡(luò)、企業(yè)網(wǎng)絡(luò)等典型場景中被應(yīng)用和推廣。第二章SDN交換機(jī)及南向接口技術(shù)SDN的核心理念之一是將控制功能從網(wǎng)絡(luò)交換設(shè)備中剝離出來，從而達(dá)到降低設(shè)備復(fù)雜度，提升網(wǎng)絡(luò)管控效率的目的。工作在基礎(chǔ)設(shè)施層的SDN交換機(jī)雖然不再需要對(duì)控制邏輯的實(shí)現(xiàn)進(jìn)行更多考慮，但為了完成高速的數(shù)據(jù)轉(zhuǎn)發(fā)，它仍然需要借鑒傳統(tǒng)領(lǐng)域中的成熟理念。"去智能化"的SDN交換機(jī)對(duì)數(shù)據(jù)包的轉(zhuǎn)發(fā)決策來自于控制器的南向接口，而OpenFlow和OF-CONFIG則是當(dāng)前南向接口領(lǐng)域的典型代表。SDN交換機(jī)究竟如何執(zhí)行數(shù)據(jù)包轉(zhuǎn)發(fā)？又如何根據(jù)南向接口進(jìn)行轉(zhuǎn)發(fā)決策呢？開源的OpenvSwitch虛擬交換機(jī)為相關(guān)探討提供了便利。2.1交換機(jī)核心技術(shù)網(wǎng)絡(luò)架構(gòu)中，無論是交換機(jī)（Switch）還是路由器（Router），它們的最主要工作都是實(shí)現(xiàn)數(shù)據(jù)信息在網(wǎng)絡(luò)上的交換。需要注意的是，這里提及的交換是一種技術(shù)概念，即完成數(shù)據(jù)信息從設(shè)備入端口到出端口的轉(zhuǎn)發(fā)。因此，只要是符合該定義的所有設(shè)備都可被稱為交換設(shè)備。由此可見，"交換"是一個(gè)涵義廣泛的詞語，當(dāng)它被用來描述數(shù)據(jù)網(wǎng)絡(luò)第二層的設(shè)備時(shí)，實(shí)際指的就是交換機(jī)；而當(dāng)它被用來描述數(shù)據(jù)網(wǎng)絡(luò)第三層的設(shè)備時(shí)，通常指的是路由器或者三層交換機(jī)。對(duì)應(yīng)于國際標(biāo)準(zhǔn)化組織（ISO）定義的七層網(wǎng)絡(luò)架構(gòu)，交換機(jī)最初是工作在第二層（即數(shù)據(jù)鏈路層）的設(shè)備，它主要根據(jù)MAC地址等網(wǎng)絡(luò)信息完成數(shù)據(jù)交換；而路由器則是工作在第三層（即網(wǎng)絡(luò)層）的設(shè)備，它需要根據(jù)IP地址等網(wǎng)絡(luò)信息完成數(shù)據(jù)交換。隨著設(shè)備功能的擴(kuò)展與提升，當(dāng)前的交換機(jī)中也有很多能夠基于三層網(wǎng)絡(luò)信息進(jìn)行數(shù)據(jù)高速轉(zhuǎn)發(fā)的實(shí)現(xiàn)。無論是交換機(jī)還是路由器，傳統(tǒng)網(wǎng)絡(luò)交換設(shè)備的典型系統(tǒng)架構(gòu)如圖2-1所示。如圖2-1所示，傳統(tǒng)網(wǎng)絡(luò)交換設(shè)備的架構(gòu)中包含兩個(gè)平面的工作：轉(zhuǎn)發(fā)平面：主要用于對(duì)每一個(gè)數(shù)據(jù)報(bào)文進(jìn)行處理，使得它能夠通過網(wǎng)絡(luò)交換設(shè)備。這些操作大多采用專門的硬件實(shí)現(xiàn)，主要包括轉(zhuǎn)發(fā)決策、背板和輸出鏈路調(diào)度等功能?？刂破矫妫褐饕糜趯?duì)交換機(jī)的轉(zhuǎn)發(fā)表或路由器的路由表進(jìn)行管理，同時(shí)負(fù)責(zé)網(wǎng)絡(luò)配置、系統(tǒng)管理等方面的操作，與轉(zhuǎn)發(fā)平面相比，運(yùn)行頻率較低，可以采用軟件實(shí)現(xiàn)在傳統(tǒng)的網(wǎng)絡(luò)交換設(shè)備中，轉(zhuǎn)發(fā)平面和控制平面是緊密耦合的，被集成實(shí)現(xiàn)在單獨(dú)的設(shè)備箱中。各個(gè)設(shè)備的控制平面被分布地部署在網(wǎng)絡(luò)的各個(gè)節(jié)點(diǎn)上，很難對(duì)全網(wǎng)的網(wǎng)絡(luò)情況有全局把控。另外，轉(zhuǎn)發(fā)平面通常會(huì)采用專門設(shè)計(jì)的ASIC芯片實(shí)現(xiàn)提升性能，控制平面則以控制軟件或者網(wǎng)絡(luò)操作系統(tǒng)的形式實(shí)現(xiàn)。在傳統(tǒng)網(wǎng)絡(luò)設(shè)備中，各家廠商出于技術(shù)保密的考慮，幾乎不會(huì)對(duì)外開放接口供設(shè)備用戶調(diào)用，以此對(duì)設(shè)備進(jìn)行控制和管理。這導(dǎo)致用戶難以對(duì)網(wǎng)絡(luò)設(shè)備能力進(jìn)行靈活調(diào)用，甚至在一些情形下，設(shè)備管理員必須到現(xiàn)場對(duì)設(shè)備進(jìn)行逐臺(tái)配置。如第1章所述，受到架構(gòu)設(shè)計(jì)、設(shè)備技術(shù)等方面的限制，傳統(tǒng)的網(wǎng)絡(luò)在滿足新興業(yè)務(wù)需求方面存在很多問題。因此，SDN的理念被提出，而其最主要的貢獻(xiàn)之一就是定義了標(biāo)準(zhǔn)的南向接口，用于對(duì)網(wǎng)絡(luò)基礎(chǔ)設(shè)施層的交換機(jī)、路由器等設(shè)備進(jìn)行抽象建模，從而把每臺(tái)單獨(dú)的網(wǎng)絡(luò)設(shè)備中的控制平面集中抽取到控制層中，實(shí)現(xiàn)底層轉(zhuǎn)發(fā)設(shè)備的"去智能化"。在SDN網(wǎng)絡(luò)中，底層負(fù)責(zé)轉(zhuǎn)發(fā)的設(shè)備只需要按照其本地保存的轉(zhuǎn)發(fā)決策機(jī)制進(jìn)行高速數(shù)據(jù)轉(zhuǎn)發(fā)，而轉(zhuǎn)發(fā)決策中的具體策略都由控制層通過南向接口協(xié)議統(tǒng)一下發(fā)。2.1.1交換機(jī)工作原理如前文所述，無論是交換機(jī)還是路由器，其最核心的工作就是"交換"，它們的工作流程可以被歸納為解析從設(shè)備入端口接收到的數(shù)據(jù)包，并將其中包含的網(wǎng)絡(luò)信息與設(shè)備中保存的轉(zhuǎn)發(fā)表或者路由表的內(nèi)容進(jìn)行匹配，進(jìn)而根據(jù)匹配結(jié)果將數(shù)據(jù)通過背板發(fā)送到相應(yīng)的設(shè)備出端口上。因此，在SDN網(wǎng)絡(luò)中，單純負(fù)責(zé)網(wǎng)絡(luò)數(shù)據(jù)高速轉(zhuǎn)發(fā)的基礎(chǔ)設(shè)施層設(shè)備被統(tǒng)一稱作交換機(jī)。除了命名上的統(tǒng)一之外，在以O(shè)penFlow交換機(jī)為代表的SDN基礎(chǔ)設(shè)施層設(shè)備中，還對(duì)交換過程所需的轉(zhuǎn)發(fā)決策機(jī)制進(jìn)行了進(jìn)一步的抽象，將傳統(tǒng)網(wǎng)絡(luò)設(shè)備中的二層轉(zhuǎn)發(fā)表、三層路由表機(jī)制進(jìn)一步抽象為統(tǒng)一的流表（FlowTable）。如圖2-1所示，作為網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)平面，交換機(jī)需要具備的最根本的功能，主要包括轉(zhuǎn)發(fā)決策、背板、輸出鏈路調(diào)度等。以交換機(jī)對(duì)三層數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā)為例，其相關(guān)功能說明如下：轉(zhuǎn)發(fā)決策（ForwardingDecision）：當(dāng)數(shù)據(jù)報(bào)文到達(dá)SDN交換機(jī)后，數(shù)據(jù)包頭中攜帶的信息會(huì)在交換機(jī)轉(zhuǎn)發(fā)表中（例如OpenFlow流表）被查找。如果地址被找到了，那么對(duì)應(yīng)的下一跳的MAC地址就會(huì)被掛接在數(shù)據(jù)報(bào)文的最前端，同時(shí)IP數(shù)據(jù)報(bào)文的TTL域遞減1，并計(jì)算出一個(gè)新的校驗(yàn)和。背板（Backplane）：數(shù)據(jù)報(bào)文進(jìn)而將通過背板轉(zhuǎn)發(fā)到SDN交換機(jī)對(duì)應(yīng)的設(shè)備出端口。其中，為了保證處理順序，數(shù)據(jù)報(bào)文需要被加入到一個(gè)隊(duì)列中等待。如果當(dāng)前的等待隊(duì)列中沒有足夠的空間存在，那么數(shù)據(jù)報(bào)文可能會(huì)被丟棄或替換掉其他數(shù)據(jù)報(bào)文，占據(jù)別的數(shù)據(jù)報(bào)文此前在隊(duì)列中的位置。輸出鏈路調(diào)度（OutputLinkScheduling）：當(dāng)數(shù)據(jù)報(bào)文到達(dá)SDN交換機(jī)的設(shè)備出端口后，它需要按照一定的順序進(jìn)行等待，直到它被發(fā)出到相應(yīng)的交換機(jī)輸出鏈路上。在當(dāng)今絕大多數(shù)的轉(zhuǎn)發(fā)設(shè)備中，設(shè)備出端口普遍支持利用FIFO（FirstInFirstOut，先入先出）隊(duì)列的方式按照數(shù)據(jù)報(bào)文的到達(dá)順序進(jìn)行下一步轉(zhuǎn)發(fā)。同時(shí)，也有一些先進(jìn)的轉(zhuǎn)發(fā)設(shè)備能夠?qū)?shù)據(jù)報(bào)文區(qū)分成不同的數(shù)據(jù)流或者優(yōu)先級(jí)的集合，進(jìn)而精心地對(duì)每個(gè)數(shù)據(jù)報(bào)文的發(fā)出時(shí)間進(jìn)行安排以滿足相應(yīng)的QoS（QualityofService，服務(wù)質(zhì)量）要求，這些策略也可以在OpenFlow交換機(jī)的設(shè)計(jì)與實(shí)現(xiàn)中被應(yīng)用。2.1.2交換機(jī)實(shí)現(xiàn)技術(shù)對(duì)于SDN網(wǎng)絡(luò)中的交換機(jī)而言，根據(jù)使用場景的需要，上述交換功能可以采用軟件或者硬件實(shí)現(xiàn)。其中，軟件實(shí)現(xiàn)的SDN交換機(jī)通常與虛擬化Hypervisor相整合，從而為云計(jì)算場景中的多租戶靈活組網(wǎng)等業(yè)務(wù)提供支持。硬件實(shí)現(xiàn)的交換機(jī)則能夠支持基于硬件設(shè)備的組網(wǎng)，還能夠滿足SDN網(wǎng)絡(luò)與傳統(tǒng)網(wǎng)絡(luò)的混合組網(wǎng)需求。無論是軟件還是硬件，參考傳統(tǒng)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備，SDN交換機(jī)在具體的設(shè)計(jì)和實(shí)現(xiàn)中還需要對(duì)交換模式、背板設(shè)計(jì)、緩沖機(jī)制、數(shù)據(jù)轉(zhuǎn)發(fā)等多方面的技術(shù)進(jìn)行合理地選擇。交換模式SDN交換機(jī)的數(shù)據(jù)交換模式?jīng)Q定了其轉(zhuǎn)發(fā)數(shù)據(jù)包的速度及交換過程導(dǎo)致的延遲（即交換機(jī)在一個(gè)端口接收到數(shù)據(jù)包的時(shí)間與在另一個(gè)端口發(fā)送該數(shù)據(jù)包的時(shí)間差）。在實(shí)際應(yīng)用中，數(shù)據(jù)包的轉(zhuǎn)發(fā)既希望具有盡可能低的轉(zhuǎn)發(fā)延遲以提升數(shù)據(jù)傳輸性能，又希望能夠在轉(zhuǎn)發(fā)過程中對(duì)數(shù)據(jù)包進(jìn)行檢驗(yàn)，以保證信息傳輸?shù)目煽啃?。和傳統(tǒng)的網(wǎng)絡(luò)交換設(shè)備一樣，SDN交換機(jī)的數(shù)據(jù)交換模式也可以有直通、零碎片、存儲(chǔ)轉(zhuǎn)發(fā)等多種選擇，各種模式的介紹和分析如下：直通（Cut-Through）：交換機(jī)僅對(duì)數(shù)據(jù)幀（二層網(wǎng)絡(luò)對(duì)數(shù)據(jù)包的特有稱呼）的前6個(gè)字節(jié)的信息進(jìn)行接收和分析，并將數(shù)據(jù)幀的其余部分直接剪切（即所謂的Cut）到出端口上。這是因?yàn)閿?shù)據(jù)幀的前6個(gè)字節(jié)包含了該數(shù)據(jù)幀的目的MAC地址，這已經(jīng)足以供交換機(jī)做出轉(zhuǎn)發(fā)決策。直通模式具有最小的轉(zhuǎn)發(fā)延遲，但是它并不檢查數(shù)據(jù)的完整性，因此可能會(huì)把能夠?qū)е乱蕴W(wǎng)沖突的"壞包"轉(zhuǎn)發(fā)出去，從而產(chǎn)生網(wǎng)絡(luò)可靠性問題。零碎片（Fragment-Free）：交換機(jī)首先對(duì)數(shù)據(jù)幀的前64個(gè)字節(jié)進(jìn)行接收和解析，再進(jìn)行轉(zhuǎn)發(fā)。之所以選擇64個(gè)字節(jié)的長度，是因?yàn)榻?jīng)驗(yàn)表明在以太網(wǎng)絡(luò)中，絕大部分的"壞包"都能在這些字節(jié)的處理過程中被檢測到。這種模式雖然有可能造成極少量的"壞包"漏檢，但是它對(duì)網(wǎng)絡(luò)的整體性能影響不大，因此在很多應(yīng)用場景中又被稱為"快速轉(zhuǎn)發(fā)（Fast-Forwarding）"。存儲(chǔ)轉(zhuǎn)發(fā)（Store-and-Forward）：交換機(jī)需要對(duì)整個(gè)數(shù)據(jù)幀的內(nèi)容進(jìn)行接收和解析，并開展數(shù)據(jù)幀的完整性檢驗(yàn)等操作，以有效地避免出現(xiàn)錯(cuò)誤。雖然該模式增加了轉(zhuǎn)發(fā)延遲，但是考慮到當(dāng)前的處理器或者ASIC已經(jīng)具有足夠的性能，因此，在SDN交換機(jī)的設(shè)計(jì)與實(shí)現(xiàn)中，仍舊建議其采用這種模式用于數(shù)據(jù)交換。背板設(shè)計(jì)SDN交換機(jī)中，從設(shè)備入端口接收到的數(shù)據(jù)包將通過背板被發(fā)送到設(shè)備出端口。交換機(jī)的背板是數(shù)據(jù)幀在交換機(jī)內(nèi)部傳輸?shù)耐ㄐ磐ǖ溃瑪y帶有轉(zhuǎn)發(fā)決策信息及中繼管理信息。參考傳統(tǒng)的網(wǎng)絡(luò)交換設(shè)備，SDN交換機(jī)可采用的背板設(shè)計(jì)主要包括共享總線機(jī)制和交叉開關(guān)矩陣機(jī)制兩種方式，相應(yīng)的介紹和分析如下。共享總線（SharedBus）機(jī)制：交換機(jī)中所有的入端口和出端口都共享同一數(shù)據(jù)通路，并由一個(gè)集中的仲裁器負(fù)責(zé)決定何時(shí)以何種方式將總線的訪問權(quán)賦予哪個(gè)交換機(jī)端口。根據(jù)不同的交換機(jī)配置，仲裁器可以用多種多樣的方法保證總線訪問的公平性。在共享總線的數(shù)據(jù)幀傳輸流程中，交換機(jī)設(shè)備入端口在接收到數(shù)據(jù)幀后，將發(fā)起對(duì)總線的訪問請(qǐng)求，并等待請(qǐng)求被仲裁器批準(zhǔn)后將數(shù)據(jù)幀發(fā)送到數(shù)據(jù)總線上。該數(shù)據(jù)幀會(huì)被總線上掛接的所有端口接收到，同時(shí)交換機(jī)將決定哪個(gè)出端口應(yīng)該繼續(xù)傳遞該數(shù)據(jù)幀。在接收到交換機(jī)的決定后，負(fù)責(zé)轉(zhuǎn)發(fā)的設(shè)備出端口將繼續(xù)傳遞數(shù)據(jù)幀，而其他端口則將該數(shù)據(jù)幀丟棄。共享總線的交換機(jī)制使得除了交換機(jī)的設(shè)備入端口外，其他掛接在總線上的端口都可以自動(dòng)獲得數(shù)據(jù)幀的副本而無需額外的復(fù)制操作，從而比較容易實(shí)現(xiàn)組播和廣播。但是，共享總線的速度將會(huì)對(duì)整個(gè)交換機(jī)的流量造成很大影響，這主要是因?yàn)榭偩€是共享的，所以端口必須要等到輪到它們使用總線時(shí)才能進(jìn)行通信。交叉開關(guān)矩陣（Crossbar）機(jī)制：又可以被稱作"縱橫式交換矩陣"，其基本思路是支持在交換機(jī)端口之間提供多個(gè)可以同時(shí)使用的數(shù)據(jù)通路。它突破了共享總線機(jī)制中的帶寬限制，在交換網(wǎng)絡(luò)內(nèi)部沒有帶寬瓶頸，不會(huì)因?yàn)閹捹Y源不夠而產(chǎn)生阻塞。因此，在SDN交換機(jī)的設(shè)計(jì)與實(shí)現(xiàn)時(shí)，交叉開關(guān)矩陣可以被引入，以改進(jìn)數(shù)據(jù)交換效率。緩沖機(jī)制如果SDN交換機(jī)采用了基于共享總線的背板設(shè)計(jì)，那么數(shù)據(jù)幀必須要依次等待仲裁器裁決直至輪到它們對(duì)應(yīng)的端口可以訪問總線時(shí)才可以被發(fā)出；而即使是采用了基于交叉開關(guān)矩陣的背板設(shè)計(jì)，數(shù)據(jù)幀也有可能因?yàn)榫W(wǎng)絡(luò)出現(xiàn)擁塞被延遲發(fā)出。因此，相關(guān)的數(shù)據(jù)幀就必須被SDN交換機(jī)所緩沖直至它被發(fā)出。如果SDN交換機(jī)沒有設(shè)計(jì)合理的緩沖機(jī)制，那么在出現(xiàn)流量超標(biāo)或者網(wǎng)絡(luò)擁塞時(shí)，數(shù)據(jù)幀就有可能被隨時(shí)丟棄。SDN交換機(jī)的緩沖機(jī)制用于解決數(shù)據(jù)包不能夠被設(shè)備出端口及時(shí)轉(zhuǎn)發(fā)的問題，而發(fā)生該情況的原因主要包括交換機(jī)的設(shè)備入端口和設(shè)備出端口速率不匹配、多個(gè)設(shè)備入端口向同一設(shè)備出端口發(fā)送數(shù)據(jù)、設(shè)備出端口處于半雙工工作狀態(tài)等。為了避免發(fā)生上述情況導(dǎo)致數(shù)據(jù)包被丟棄，當(dāng)前有兩種常用的緩沖機(jī)制可供SDN交換機(jī)選擇：端口緩沖：為每個(gè)交換機(jī)上的以太網(wǎng)端口提供一定數(shù)量的高速內(nèi)存用于緩沖數(shù)據(jù)幀的到來與轉(zhuǎn)發(fā)。該方法存在的主要問題是當(dāng)端口的緩沖被使用殆盡時(shí)，其后續(xù)接收到的數(shù)據(jù)幀將被丟棄，而支持緩沖規(guī)模的靈活調(diào)整將有助于緩解這一問題。共享內(nèi)存：為所有端口提供可以同時(shí)訪問的共享內(nèi)存空間用于端口緩沖。該方法將所有接收到的數(shù)據(jù)幀都保存在共享的內(nèi)存池中，直到設(shè)備出端口準(zhǔn)備將其轉(zhuǎn)發(fā)到網(wǎng)絡(luò)中。使用這種方法，交換機(jī)能夠動(dòng)態(tài)地分配共享內(nèi)存，可以根據(jù)端口流量的大小設(shè)定相應(yīng)的緩沖規(guī)模。數(shù)據(jù)轉(zhuǎn)發(fā)無論是硬件實(shí)現(xiàn)還是軟件實(shí)現(xiàn)的SDN交換機(jī)，數(shù)據(jù)幀在交換機(jī)內(nèi)部從設(shè)備入端口到設(shè)備出端口的傳遞過程都需要交換機(jī)做出轉(zhuǎn)發(fā)決策。在傳統(tǒng)的網(wǎng)絡(luò)交換設(shè)備中，這一決策過程需要交換機(jī)中的轉(zhuǎn)發(fā)表、路由器中的路由表等機(jī)制實(shí)現(xiàn)，它們通過對(duì)設(shè)備入端口接收到的數(shù)據(jù)包的目的地址信息進(jìn)行匹配，就能夠確定該數(shù)據(jù)包應(yīng)該被發(fā)往哪個(gè)設(shè)備出端口。對(duì)SDN交換機(jī)而言，設(shè)備中同樣需要這樣的轉(zhuǎn)發(fā)決策機(jī)制。以O(shè)penFlow交換機(jī)為例，它提出了流表的概念對(duì)傳統(tǒng)的二層轉(zhuǎn)發(fā)表、三層路由表進(jìn)行了抽象，從而使得數(shù)據(jù)包在轉(zhuǎn)發(fā)過程中的決策更具靈活性。傳統(tǒng)網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)表和路由表的組成都有標(biāo)準(zhǔn)的定義，以及相對(duì)簡單的格式，例如二層交換機(jī)轉(zhuǎn)發(fā)表就是一個(gè)設(shè)備端口和MAC地址的映射關(guān)系，因此非常適合采用靜態(tài)的專用集成電路高效實(shí)現(xiàn)，而SDN交換機(jī)中的轉(zhuǎn)發(fā)決策中使用的轉(zhuǎn)發(fā)表可能會(huì)具有非常復(fù)雜的組成結(jié)構(gòu)。仍以O(shè)penFlow為例，在OpenFlowv1.2版本后，其流表中各個(gè)表項(xiàng)的長度及其中包含的匹配域都是可自定義而非固定的格式，雖然這些設(shè)置在交換機(jī)的軟件實(shí)現(xiàn)中能夠提供極高的靈活性，但是對(duì)于相應(yīng)的硬件OpenFlow交換機(jī)而言，它將不再適合采用預(yù)先定義好的硬件電路進(jìn)行流表的實(shí)現(xiàn)。為了應(yīng)對(duì)這一問題，硬件的SDN交換機(jī)可以考慮引入TCAM（TernaryContentAddressableMemory，三態(tài)內(nèi)容尋址存儲(chǔ)器）技術(shù)完成相關(guān)流表信息的存儲(chǔ)和查詢。TCAM在傳統(tǒng)的網(wǎng)絡(luò)交換設(shè)備中也有應(yīng)用，例如用于快速查找ACL等。和一般只能支持"0"和"1"兩種狀態(tài)的存儲(chǔ)器件不同，TCAM存儲(chǔ)器中的每個(gè)bit位都具有一個(gè)通過掩碼實(shí)現(xiàn)的"don'tcare"狀態(tài)。而正是這個(gè)第三種狀態(tài)，使得TCAM既能夠支持精確匹配查找，又能夠支持模糊匹配查找，完全能夠滿足SDN交換機(jī)的轉(zhuǎn)發(fā)決策表項(xiàng)的存儲(chǔ)和查詢需求。但需要注意的是，當(dāng)前的TCAM存在成本高、功耗大等問題，這可能會(huì)成為影響SDN交換機(jī)推廣的一個(gè)障礙。2.2OpenFlow交換機(jī)規(guī)范根據(jù)SDN架構(gòu)定義，SDN交換機(jī)只負(fù)責(zé)網(wǎng)絡(luò)數(shù)據(jù)的高速轉(zhuǎn)發(fā)，而其中保存的用于進(jìn)行轉(zhuǎn)發(fā)決策的轉(zhuǎn)發(fā)表信息則來自于SDN控制器。SDN控制器通過控制器南向接口對(duì)網(wǎng)絡(luò)中所有的SDN交換機(jī)進(jìn)行集中化統(tǒng)一管理，這也是SDN網(wǎng)絡(luò)的另一個(gè)重要特點(diǎn)。目前OpenFlow是標(biāo)準(zhǔn)化組織ONF唯一確定的控制器南向接口，在SDN的發(fā)展中具有舉足輕重的地位。OpenFlow還在不斷地演進(jìn)和快速成熟中，本節(jié)將首先以O(shè)penFlowv1.0為主介紹OpenFlow協(xié)議的基本架構(gòu)，然后再逐個(gè)展示后續(xù)OpenFlow版本中的重要變化。2.2.1OpenFlowv1.0概述OpenFlow最早由斯坦福大學(xué)的NickMcKeown教授等研究人員在2008年4月發(fā)表的論文OpenFlow:EnablingInnovationinCampusNetworks中提出，其最初的出發(fā)點(diǎn)是考慮到網(wǎng)絡(luò)的創(chuàng)新思想需要在實(shí)際網(wǎng)絡(luò)上才能被更好地驗(yàn)證，而研究人員又無法修改現(xiàn)網(wǎng)中的網(wǎng)絡(luò)設(shè)備，故而提出了名為OpenFlow的控制和轉(zhuǎn)發(fā)分離的架構(gòu)，將控制邏輯從網(wǎng)絡(luò)設(shè)備盒子中引出來，供研究者對(duì)其進(jìn)行任意的編程從而實(shí)現(xiàn)新型的網(wǎng)絡(luò)協(xié)議、拓?fù)浼軜?gòu)而無需改動(dòng)網(wǎng)絡(luò)設(shè)備本身。從其起源可以看出，OpenFlow的設(shè)計(jì)與SDN有著非常一致的目標(biāo),對(duì)網(wǎng)絡(luò)的創(chuàng)新發(fā)展起到了巨大的推動(dòng)作用，因此受到了廣泛的關(guān)注和支持。OpenFlow標(biāo)準(zhǔn)的名稱是OpenFlowSwitchSpecification，因此它本身是一份設(shè)備規(guī)范，其中規(guī)定了作為SDN基礎(chǔ)設(shè)施層轉(zhuǎn)發(fā)設(shè)備的OpenFlow交換機(jī)的基本組件和功能要求，以及用于由遠(yuǎn)程控制器對(duì)交換機(jī)進(jìn)行控制的OpenFlow協(xié)議。OpenFlowv1.0是OpenFlow規(guī)范的第一個(gè)商業(yè)化版本，于2009年12月31日發(fā)布，它是OpenFlow規(guī)范后續(xù)版本的重要基礎(chǔ)。OpenFlowv1.0中已經(jīng)充分體現(xiàn)了基于OpenFlow交換機(jī)、OpenFlow控制器，以及OpenFlow協(xié)議搭建SDN的設(shè)計(jì)思想和整體架構(gòu)，如圖2-2所示。如圖2-2所示，OpenFlow交換機(jī)利用基于安全連接的OpenFlow協(xié)議與遠(yuǎn)程控制器相通信。其中，流表（FlowTable）是OpenFlow交換機(jī)的關(guān)鍵組件，負(fù)責(zé)數(shù)據(jù)包的高速查詢和轉(zhuǎn)發(fā)。另外，OpenFlow交換機(jī)還需要通過一個(gè)安全通道與外部的控制器進(jìn)行通信，這個(gè)安全通道上傳輸?shù)氖荗penFlow協(xié)議，它將負(fù)責(zé)傳遞控制器和交換機(jī)之間的管理和控制信息。因此，流表、安全通道及OpenFlow協(xié)議是OpenFlowv1.0的核心組成部分。流表如前文所述，OpenFlow的設(shè)計(jì)目標(biāo)之一就是將網(wǎng)絡(luò)設(shè)備的控制功能與轉(zhuǎn)發(fā)功能進(jìn)行分離，進(jìn)而將控制功能全部集中到遠(yuǎn)程的控制器上完成，而OpenFlow交換機(jī)只負(fù)責(zé)在本地做簡單高速的數(shù)據(jù)轉(zhuǎn)發(fā)。在OpenFlow交換機(jī)的運(yùn)行過程中，其數(shù)據(jù)轉(zhuǎn)發(fā)的依據(jù)就是流表。所謂流表，其實(shí)可被視作是OpenFlow對(duì)網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā)功能的一種抽象。在傳統(tǒng)網(wǎng)絡(luò)設(shè)備中，交換機(jī)和路由器的數(shù)據(jù)轉(zhuǎn)發(fā)需要依賴設(shè)備中保存的二層MAC地址轉(zhuǎn)發(fā)表或者三層IP地址路由表，而OpenFlow交換機(jī)中使用的流表也是如此，不過在它的表項(xiàng)中整合了網(wǎng)絡(luò)中各個(gè)層次的網(wǎng)絡(luò)配置信息，從而在進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)時(shí)可以使用更豐富的規(guī)則。流表中每個(gè)表項(xiàng)的結(jié)構(gòu)如圖2-3所示。如圖2-3所示，OpenFlow流表的每個(gè)流表項(xiàng)都由3部分組成：用于數(shù)據(jù)包匹配的包頭域（HeaderFields），用于統(tǒng)計(jì)匹配數(shù)據(jù)包個(gè)數(shù)的計(jì)數(shù)器（Counters），用于展示匹配的數(shù)據(jù)包如何處理的動(dòng)作（Actions）。包頭域：OpenFlow流表的包頭域（OpenFlowv1.1之后被稱作匹配域），用于對(duì)交換機(jī)接收到的數(shù)據(jù)包的包頭內(nèi)容進(jìn)行匹配。在OpenFlowv1.0中，流表的包頭域中包括了12個(gè)元組（Tuple），相關(guān)內(nèi)容如圖2-4所示。如圖2-4所示，包頭域中用于和交換機(jī)接收到的數(shù)據(jù)包進(jìn)行匹配的元組涵蓋了ISO網(wǎng)絡(luò)模型中第二至第四層的網(wǎng)絡(luò)配置信息。每一個(gè)元組中的數(shù)值可以是一個(gè)確定的值或者是"ANY"以支持對(duì)任意值的匹配。另外，如果交換機(jī)能夠在IP地址相關(guān)元組上支持子網(wǎng)掩碼的話，將有助于實(shí)現(xiàn)更精確的匹配。計(jì)數(shù)器：OpenFlow流表的計(jì)數(shù)器可以針對(duì)交換機(jī)中的每張流表、每個(gè)數(shù)據(jù)流、每個(gè)設(shè)備端口、每個(gè)轉(zhuǎn)發(fā)隊(duì)列進(jìn)行維護(hù)，用于統(tǒng)計(jì)數(shù)據(jù)流量的相關(guān)信息。例如：針對(duì)每張流表，統(tǒng)計(jì)當(dāng)前活動(dòng)的表項(xiàng)數(shù)、數(shù)據(jù)包查詢次數(shù)、數(shù)據(jù)包匹配次數(shù)等；針對(duì)每個(gè)數(shù)據(jù)流，統(tǒng)計(jì)接收到的數(shù)據(jù)包數(shù)、字節(jié)數(shù)、數(shù)據(jù)流持續(xù)時(shí)間等；針對(duì)每個(gè)設(shè)備端口，除統(tǒng)計(jì)接收到的數(shù)據(jù)包數(shù)、發(fā)送數(shù)據(jù)包數(shù)、接收字節(jié)數(shù)、發(fā)送字節(jié)數(shù)等指標(biāo)之外，還可以對(duì)各種錯(cuò)誤發(fā)生的次數(shù)進(jìn)行統(tǒng)計(jì)；針對(duì)每個(gè)隊(duì)列，統(tǒng)計(jì)發(fā)送的數(shù)據(jù)包數(shù)和字節(jié)數(shù)，還有發(fā)送時(shí)的溢出（Overrun）錯(cuò)誤次數(shù)等。動(dòng)作：OpenFlow流表的動(dòng)作用于指示交換機(jī)在收到匹配的數(shù)據(jù)包后應(yīng)該如何對(duì)其進(jìn)行處理。與傳統(tǒng)交換機(jī)轉(zhuǎn)發(fā)表只需要指明數(shù)據(jù)包的轉(zhuǎn)發(fā)出端口不同，OpenFlow交換機(jī)因?yàn)槿鄙倏刂破矫娴哪芰Γ詫?duì)匹配數(shù)據(jù)包的處理不僅僅是簡單的轉(zhuǎn)發(fā)操作，而需要用動(dòng)作來詳細(xì)說明交換機(jī)將要對(duì)數(shù)據(jù)包所做的處理。OpenFlow交換機(jī)的每個(gè)流表項(xiàng)可以對(duì)應(yīng)有零至多個(gè)動(dòng)作，如果沒有定義轉(zhuǎn)發(fā)動(dòng)作，那么與流表項(xiàng)包頭域匹配的數(shù)據(jù)包將被默認(rèn)丟棄。統(tǒng)一流表項(xiàng)中的多個(gè)動(dòng)作的執(zhí)行可以具有優(yōu)先級(jí)，但是在數(shù)據(jù)包的發(fā)送上并不保證其順序。另外，如果流表項(xiàng)中出現(xiàn)有OpenFlow交換機(jī)不支持的參數(shù)值，交換機(jī)將向控制器返回相應(yīng)的出錯(cuò)信息。動(dòng)作分為必備動(dòng)作（RequiredActions）和可選動(dòng)作（OptionalActions）兩種類型。其中，必備動(dòng)作是需要由所有的OpenFlow交換機(jī)默認(rèn)支持的，而可選動(dòng)作則需要由交換機(jī)告知控制器它所能支持的動(dòng)作種類。OpenFlow流表動(dòng)作的列表如表2-1所示。表2-1OpenFlow流表動(dòng)作列表類型名稱說明必備動(dòng)作轉(zhuǎn)發(fā)(Forward)交換機(jī)必須支持將數(shù)據(jù)包轉(zhuǎn)發(fā)給設(shè)備的物理端口及如下的一個(gè)或多個(gè)虛擬端口ALL：轉(zhuǎn)發(fā)給所有出端口，但不包括入端口CONTROLLER：封裝數(shù)據(jù)包并轉(zhuǎn)發(fā)給控制器LOCAL：轉(zhuǎn)發(fā)給本地的網(wǎng)絡(luò)棧TABLE：對(duì)packet_out消息執(zhí)行流表的動(dòng)作IN_PORT：從入端口發(fā)出丟棄（Drop）對(duì)沒有明確指明處理動(dòng)作的流表項(xiàng)，交換機(jī)將會(huì)對(duì)與其所匹配的所有數(shù)據(jù)包進(jìn)行默認(rèn)的丟棄處理可選動(dòng)作轉(zhuǎn)發(fā)(Forward)交換機(jī)可選支持將數(shù)據(jù)包轉(zhuǎn)發(fā)給如下的虛擬端口NORMAL：利用交換機(jī)所能支持的傳統(tǒng)轉(zhuǎn)發(fā)機(jī)制（例如二層的MAC、VLAN信息或者三層的IP信息）處理數(shù)據(jù)包FLOOD：遵照最小生成樹從設(shè)備出端口洪泛發(fā)出，但不包括入端口排隊(duì)(Enqueue)交換機(jī)將數(shù)據(jù)包轉(zhuǎn)發(fā)到某個(gè)出端口對(duì)應(yīng)的轉(zhuǎn)發(fā)隊(duì)列中，便于提供QoS支持修改域(Modify-Field)交換機(jī)修改數(shù)據(jù)包的包頭內(nèi)容，具體可以包括：設(shè)置VLANID、VLAN優(yōu)先級(jí)，剝離VLAN頭修改源MAC地址、目的MAC地址修改源IPv4地址、目的IPv4地址、ToS位修改源TCP/IP端口、目的TCP/IP端口根據(jù)交換機(jī)的應(yīng)用場景及其所能夠支持的流表動(dòng)作類型，OpenFlow交換機(jī)可以被分為"OpenFlow專用交換機(jī)（OpenFlow-only）"和"OpenFlow使能交換機(jī)（OpenFlow-enabled，在OpenFlowv1.1之后被稱作OpenFlow-hybrid）"。其中，前者只支持OpenFlow協(xié)議，而后者則是考慮到了OpenFlow交換機(jī)與傳統(tǒng)交換機(jī)混合組網(wǎng)時(shí)可能遇到的協(xié)議棧不兼容問題，能同時(shí)運(yùn)行OpenFlow協(xié)議和傳統(tǒng)的二層/三層協(xié)議棧。因此，后者可以支持OpenFlow可選轉(zhuǎn)發(fā)動(dòng)作中的NORMAL動(dòng)作。OpenFlow交換機(jī)在接收到網(wǎng)絡(luò)數(shù)據(jù)包后，對(duì)其開展的處理流程如圖2-5所示。如圖2-5所示，流程中對(duì)802.1d協(xié)議的處理是流程中的可選步驟（在OpenFlowv1.1之后已刪除）。當(dāng)OpenFlow交換機(jī)接收到一個(gè)數(shù)據(jù)包時(shí)，將按照優(yōu)先級(jí)依次匹配其本地保存的流表中的表項(xiàng)，并以發(fā)生具有最高優(yōu)先級(jí)的匹配表項(xiàng)作為匹配結(jié)果，并根據(jù)相應(yīng)的動(dòng)作對(duì)數(shù)據(jù)包進(jìn)行操作。同時(shí)，一旦匹配成功，對(duì)應(yīng)的計(jì)數(shù)器將更新；而如果沒能找到匹配的表項(xiàng)，則將數(shù)據(jù)包轉(zhuǎn)發(fā)給控制器。OpenFlow交換機(jī)對(duì)數(shù)據(jù)包頭的解析和匹配過程的細(xì)節(jié)操作如圖2-6所示。如圖2-6所示，交換機(jī)中每一個(gè)表項(xiàng)的匹配首先按照接收到數(shù)據(jù)包的物理端口對(duì)入端口進(jìn)行匹配，然后按照二層數(shù)據(jù)包頭進(jìn)行比較。如果以太網(wǎng)類型為0x8100，即數(shù)據(jù)包是VLAN包，則繼續(xù)查詢VLANID和PCP域。如果以太網(wǎng)類型為0x0806，則為ARP包，繼續(xù)查詢?cè)碔P地址和目的IP地址。如果以太網(wǎng)類型為0x0800，即為IP包，則繼續(xù)查詢IP包頭的相關(guān)域。如果IP包是TCP/UDP包，則還需繼續(xù)查詢傳輸層端口。如果IP包是ICMP包，則繼續(xù)查詢ICMP包中的Type和Code。對(duì)于分段數(shù)據(jù)包的后續(xù)包，則將傳輸層端口設(shè)為0后繼續(xù)查詢。安全通道OpenFlow采用的是集中控制方式，控制器需要利用OpenFlow協(xié)議對(duì)交換機(jī)進(jìn)行流表的配置，因此在它們之間傳送信息的通道非常重要。通道是連接OpenFlow交換機(jī)到控制器的接口，控制器通過這個(gè)接口管理和控制OpenFlow交換機(jī)，同時(shí)也通過這個(gè)接口接收來自O(shè)penFlow交換機(jī)的消息。在具體的通道實(shí)現(xiàn)中，OpenFlowv1.0要求承載OpenFlow協(xié)議傳送的通路必須是安全的，并規(guī)定通道需要采用TLS（TransportLayerSecurity，安全傳輸層協(xié)議）技術(shù)。TLS是基于早期的SSL（SecureSocketsLayer，安全套接字層）規(guī)范而來，用于互聯(lián)網(wǎng)上的通信加密。所有安全通道必須遵守OpenFlow協(xié)議，所有的信息必須按照OpenFlow協(xié)議規(guī)定的格式執(zhí)行。OpenFlow協(xié)議OpenFlow協(xié)議是用來描述控制器和OpenFlow交換機(jī)之間交互所用的信息的接口標(biāo)準(zhǔn)，其核心是OpenFlow協(xié)議信息的集合。OpenFlow協(xié)議支持三種消息類型：controller-to-switch、asynchronous（異步）和symmetric（對(duì)稱），而每一類消息又可以擁有多個(gè)子消息類型。其中，controller-to-switch消息由控制器發(fā)起，用來管理或獲取OpenFlow交換機(jī)的狀態(tài)；asynchronous消息由OpenFlow交換機(jī)發(fā)起，用來將網(wǎng)絡(luò)事件或交換機(jī)狀態(tài)變化更新到控制器；symmetric消息可由交換機(jī)或控制器發(fā)起。各類消息的細(xì)節(jié)描述如表2-2所示。表2-2OpenFlow協(xié)議消息列表類型名稱說明備注controller-to-switchFeatures在建立TIS會(huì)話時(shí)，控制器發(fā)送features請(qǐng)求消息給交換機(jī)，交換機(jī)需要應(yīng)答自身支持的功能由控制器發(fā)起，對(duì)OpenFlow交換機(jī)進(jìn)行狀態(tài)查詢和修改配置等操作。OpenFlow交換機(jī)接收并處理可能發(fā)送或不需要發(fā)送的應(yīng)答消息Configuration控制器設(shè)置或查詢交換機(jī)上的配置參數(shù)，交換機(jī)僅需要應(yīng)答查詢消息Modify-state控制器管理交換機(jī)流表項(xiàng)和端口狀態(tài)等Read-state控制器向交換機(jī)請(qǐng)求諸如流表、端口、各個(gè)流表項(xiàng)等方面的統(tǒng)計(jì)信息Send-packet控制器通過交換機(jī)指定端口發(fā)出數(shù)據(jù)包Barrier控制器通過barrier請(qǐng)求及相應(yīng)報(bào)文，確認(rèn)相關(guān)消息已經(jīng)被滿足或收到完成操作的通知aPacket-in交換機(jī)收到一個(gè)數(shù)據(jù)包，在流表中沒有匹配項(xiàng)，或者在流表中規(guī)定的行為是“發(fā)送到控制器”，則發(fā)送Packet-in消息給控制器。如果交換機(jī)緩存足夠多，數(shù)據(jù)包被臨時(shí)放在緩存中，數(shù)據(jù)包的部分內(nèi)容（默認(rèn)128字節(jié)）和在交換機(jī)緩存中的序號(hào)也一同發(fā)給控制器；如果交換機(jī)緩存不足以存儲(chǔ)數(shù)據(jù)包，則將整個(gè)數(shù)據(jù)包作為消息的附帶內(nèi)容發(fā)給控制器由OpenFlow交換機(jī)主動(dòng)發(fā)起，用來通知交換機(jī)上發(fā)生的某些異步事件，消息是單向的，不需要控制器應(yīng)答。主要用于交換機(jī)向控制器通知收到報(bào)文、狀態(tài)變化及出席錯(cuò)誤等事件信息OpenFlow交換機(jī)中的流表項(xiàng)因?yàn)槌瑫r(shí)或收到修改/刪除命令等原因被刪除掉，會(huì)觸發(fā)Flow-removed消息Port-statusOpenFlow交換機(jī)端口狀態(tài)發(fā)生變化時(shí)，觸發(fā)Port-status消息ErrorOpenFlow交換機(jī)通過Error消息通知控制器發(fā)生的問題symmetricHello用于在OpenFlow交換機(jī)和控制器之間發(fā)起連接建立本類消息不必通過請(qǐng)求建立，控制器和交換機(jī)都可以主動(dòng)發(fā)起，并需要接收方應(yīng)答。這些都是雙向?qū)ΨQ的消息，主要用來建立連接、檢測對(duì)方是否在線等Echo交換機(jī)和控制器均可以向?qū)Ψ桨l(fā)出Echo消息，接收者則需要回復(fù)Echoreply。該消息用來協(xié)商延遲、帶寬、是否連接保持等控制器到OpenFlow交換機(jī)之間隧道的連接參數(shù)Vendor用于OpenFlow交換機(jī)協(xié)商廠家自定義的附加功能。為未來版本預(yù)留基于表2-2所示的內(nèi)容，OpenFlow規(guī)定了在其主要的協(xié)議交互過程（例如連接建立、連接中斷、加密、生成樹支持、流表刪除、流表項(xiàng)修改等等）中需要使用的協(xié)議消息，具體情況包括如下幾點(diǎn)：連接建立：控制器與OpenFlow交換機(jī)建立TLS隧道后，隧道中傳送的都是控制協(xié)議消息，因此隧道中的所有流量轉(zhuǎn)發(fā)都無需查詢交換機(jī)中的流表。當(dāng)OpenFlow安全隧道建立起來后，雙方必須首先發(fā)送HELLO消息給對(duì)方，該消息攜帶本方支持的最高協(xié)議版本號(hào)，接收方將采用雙方都支持的最低協(xié)議版本進(jìn)行通信。一旦發(fā)現(xiàn)兩者擁有共同支持的協(xié)議版本，則連接建立，否則發(fā)送ERROR消息，描述失敗原因，并終止連接。連接中斷：當(dāng)交換機(jī)與控制器之間的連接發(fā)生異常時(shí)，OpenFlow交換機(jī)應(yīng)嘗試連接備份控制器。當(dāng)多次嘗試均失敗后，OpenFlow交換機(jī)將進(jìn)入緊急模式，并重置所有的TCP連接。此時(shí)，所有包將匹配指定的緊急模式表項(xiàng)，其他所有正常表項(xiàng)將從流表中刪除。此外，當(dāng)交換機(jī)剛啟動(dòng)時(shí)，默認(rèn)進(jìn)入緊急模式。加密：控制器與OpenFlow交換機(jī)之間的安全通道采用TLS連接加密。當(dāng)交換機(jī)啟動(dòng)時(shí)，嘗試連接到控制器的6633TCP端口。雙方通過交換證書進(jìn)行認(rèn)證。因此，每個(gè)交換機(jī)至少需配置兩個(gè)證書，一個(gè)用來認(rèn)證控制器，一個(gè)用來向控制器發(fā)出認(rèn)證。生成樹支持：OpenFlow交換機(jī)可以選擇支持802.1d生成樹協(xié)議。如果支持，所有相關(guān)包在查找流表之前應(yīng)該先在本地進(jìn)行傳統(tǒng)生成樹處理。支持生成樹協(xié)議的交換機(jī)在應(yīng)答控制器的FEATURES消息的相應(yīng)應(yīng)答域中設(shè)置STP（SpanningTreeProtocol，生成樹協(xié)議）支持位，并且需要所有物理端口均支持生成樹協(xié)議，但無需在虛擬端口支持。生成樹協(xié)議會(huì)設(shè)置端口狀態(tài)，來限制發(fā)往FLOOD的數(shù)據(jù)包僅被轉(zhuǎn)發(fā)到生成樹指定的端口。需要注意的是，已經(jīng)指定了出端口的轉(zhuǎn)發(fā)或發(fā)往ALL的數(shù)據(jù)包會(huì)忽略生成樹所指定的端口，而按照規(guī)則的設(shè)置進(jìn)行端口轉(zhuǎn)發(fā)。如果交換機(jī)不支持802.1d生成樹協(xié)議，則必須允許控制器指定洪泛時(shí)的端口狀態(tài)。流表項(xiàng)修改：流表項(xiàng)修改是控制器下發(fā)的最主要的消息，共有五種類型，如表2-3所示。名稱說明ADD增加一個(gè)新的流表項(xiàng)MODIFY修改所有匹配的流表項(xiàng)MODIFY_STRICT修改嚴(yán)格匹配的流表項(xiàng)DELETE刪除所有匹配的流表項(xiàng)DELETE_STRICT刪除嚴(yán)格匹配的流表項(xiàng)表2-3流表項(xiàng)修改消息類型2-3所示的每個(gè)消息的發(fā)送都會(huì)引起一系列OpenFlow協(xié)議消息的觸發(fā)，從而引起流表項(xiàng)的變化。同時(shí)，如果消息發(fā)送失敗，將會(huì)返回錯(cuò)誤消息及相應(yīng)的錯(cuò)誤代碼，指明出現(xiàn)錯(cuò)誤的原因。另外，MODIFY和DELETE還有另一條帶STRICT的消息。對(duì)于非STRICT消息，可使用通配的流表項(xiàng)，因此，一次可能匹配多條流表項(xiàng)，所有匹配消息描述的流表項(xiàng)均受影響。而帶有STRICT的消息，表項(xiàng)頭跟優(yōu)先級(jí)等都必須嚴(yán)格匹配后才執(zhí)行，即只有同一個(gè)流表項(xiàng)會(huì)受到影響。交換機(jī)移除流表項(xiàng)：交換機(jī)移除流表項(xiàng)有兩種情況：一種是定時(shí)器計(jì)時(shí)結(jié)束，另一種是控制器發(fā)出刪除表項(xiàng)的命令。每個(gè)表項(xiàng)均有一個(gè)idle_timeout定時(shí)器和一個(gè)hard_timeout定時(shí)器，前者計(jì)算沒有流量匹配的時(shí)間（單位都是秒），后者計(jì)算被插入表中的總時(shí)間。一旦到達(dá)時(shí)間期限，則交換機(jī)自動(dòng)刪除該表項(xiàng)，同時(shí)發(fā)出一個(gè)流刪除的消息。另外，控制器也可以下發(fā)DELETE、DELETE_STRICT等消息主動(dòng)刪除流表項(xiàng)。2.2.2OpenFlow標(biāo)準(zhǔn)演進(jìn)OpenFlow由ONF組織的Extensibility工作組負(fù)責(zé)維護(hù)。繼OpenFlowv1.0于2009年12月發(fā)布后，迄今又有五個(gè)版本的標(biāo)準(zhǔn)被陸續(xù)推出，它們分別是v1.1、v1.2、v1.3、v1.3.1和v1.3.2，這些版本的OpenFlow均在前一版本標(biāo)準(zhǔn)的基礎(chǔ)上進(jìn)行了完善，其發(fā)布時(shí)間和主要特征如圖2-7所示。如圖2-7所示，隨著SDN的興起，OpenFlow也在不斷演進(jìn)和快速成熟中。在OpenFlowv1.1及其之后的各個(gè)版本中，OpenFlow交換機(jī)的架構(gòu)發(fā)生了變化，其架構(gòu)示意如圖2-8所示如圖2-8所示，與OpenFlowv1.0中定義的交換機(jī)架構(gòu)相比，OpenFlowv1.1中的交換機(jī)主要有兩個(gè)變化：第一是交換機(jī)中的流表由單一的流表演變?yōu)橛闪魉€串聯(lián)而成的多流表；第二是增加了組表（GroupTable）。而這兩個(gè)變化都是為解決流表的轉(zhuǎn)發(fā)性能而做的改進(jìn)。流表結(jié)構(gòu)在OpenFlowv1.1和v1.2中，交換機(jī)中的流表項(xiàng)雖然還是由三部分組成，但是相應(yīng)的名稱已經(jīng)發(fā)生了變化。其中，v1.0中定義的包頭域（HeaderFields）和動(dòng)作（Actions）被分別更名為匹配域（MatchFields）和指令（Instructions）。之所以對(duì)包頭域進(jìn)行改名，是因?yàn)榱鞅眄?xiàng)中的入端口等元組信息并不是屬于數(shù)據(jù)包頭的內(nèi)容，因此將其改為匹配域?qū)⒏鼮榇_切。而使用指令一詞替代動(dòng)作，則主要是因?yàn)镺penFlow交換機(jī)中多流表的引入。在多流表場景中，雖然數(shù)據(jù)包在前一流表中出現(xiàn)了匹配，但是交換機(jī)后續(xù)的操作仍舊可能是將其轉(zhuǎn)到下一流表中繼續(xù)進(jìn)行匹配，而并非像v1.0一樣馬上依照流表動(dòng)作對(duì)數(shù)據(jù)包做具體操作。因此，新版本的OpenFlow將相關(guān)的動(dòng)作統(tǒng)一更名為指令。OpenFlowv1.1和v1.2中定義的流表結(jié)構(gòu)如圖2-9所示。而在OpenFlowv1.3之后，流表結(jié)構(gòu)的內(nèi)容又一次發(fā)生了變化，增加了優(yōu)先級(jí)（Priority）、超時(shí)定時(shí)器（Timeouts）和Cookie等內(nèi)容，從而將原來流表結(jié)構(gòu)中的三部分?jǐn)U展至六部分，如圖2-10所示。如圖2-10所示，OpenFlowv1.3的流表結(jié)構(gòu)的各個(gè)域的說明如下:匹配域：對(duì)數(shù)據(jù)包匹配。包括入端口和數(shù)據(jù)包報(bào)頭，以及由前一個(gè)表指定的可選的元數(shù)據(jù)。優(yōu)先級(jí)：流表項(xiàng)的匹配次序。計(jì)數(shù)器：更新匹配數(shù)據(jù)包的計(jì)數(shù)。指令：修改動(dòng)作集或流水線處理。超時(shí)定時(shí)器：一個(gè)流的最長有效時(shí)間或最大空閑時(shí)間。Cookie:由控制器選擇的不透明數(shù)據(jù)值?？刂破饔脕磉^濾流統(tǒng)計(jì)數(shù)據(jù)、流改變和流刪除。但處理數(shù)據(jù)包時(shí)不能使用。多流表OpenFlowv1.0在實(shí)際部署和應(yīng)用中面臨的問題之一就是TCAM存儲(chǔ)器成本問題。在傳統(tǒng)網(wǎng)絡(luò)設(shè)備中，TCAM主要用于FIB、MAC、MPLSLable和ACL表，因?yàn)槊總€(gè)表的匹配字段長度不一，所以可以分別設(shè)計(jì)，并且具有最大容量限制以期達(dá)到最小的開銷。而在OpenFlow交換中，不再區(qū)分匹配長度較短的FIB、MAC、MPLSLable表以及較長的ACL表，而一律采用具有最大長度的流表項(xiàng)記錄代替。對(duì)OpenFlowv1.0而言，流表的匹配字段長度長達(dá)252位，而一般的IPv4RIBTCAM匹配字段長度只有60至80位，其開銷增加了三倍以上。因此如何減少流表的尺寸是OpenFlow面臨的一個(gè)難題。為了解決上述問題，OpenFlowv1.1設(shè)計(jì)了多級(jí)流表來減少流表的開銷，將流表進(jìn)行特征提取，進(jìn)而將匹配過程分解成多個(gè)步驟，形成流水線的處理形式，從而降低總的流表記錄條數(shù)。例如，原始流表共有10000條，如果將其分解成先匹配VLAN和MAC地址，再匹配IP地址和傳輸層頭部等兩個(gè)獨(dú)立的流表，那么每個(gè)流表的數(shù)量可能均小于1000條，使得流表總數(shù)小于2000條。OpenFlow交換機(jī)中，所有的轉(zhuǎn)發(fā)規(guī)則都被組織在不同的OpenFlow流表中，而屬于同一個(gè)流表中的規(guī)則則按照相應(yīng)的優(yōu)先級(jí)順序進(jìn)行匹配。OpenFlow交換機(jī)中可以包含一個(gè)或者多個(gè)流表，這些流表被從0開始依次編號(hào)。OpenFlow對(duì)多流表的處理定義了流水線工作流程，如圖2-11所示。當(dāng)數(shù)據(jù)包進(jìn)入交換機(jī)后，將從流表0開始依次匹配，在后續(xù)處理中流表可以按次序從小到大越級(jí)跳轉(zhuǎn)，但不能從某一流表向前跳轉(zhuǎn)至編號(hào)更小的流表。流表項(xiàng)將以優(yōu)先級(jí)高低的順序與數(shù)據(jù)包進(jìn)行匹配，當(dāng)數(shù)據(jù)包成功匹配到一條流表項(xiàng)后，會(huì)首先更新該流表項(xiàng)對(duì)應(yīng)的計(jì)數(shù)器記錄的統(tǒng)計(jì)數(shù)據(jù)（例如發(fā)生成功匹配的數(shù)據(jù)包數(shù)量和總字節(jié)數(shù)等），然后根據(jù)流表項(xiàng)中的指令進(jìn)行相應(yīng)操作（例如跳轉(zhuǎn)至后續(xù)的某一流表繼續(xù)處理、修改或者立即執(zhí)行該數(shù)據(jù)包對(duì)應(yīng)的動(dòng)作集合等）。當(dāng)數(shù)據(jù)包已經(jīng)處于最后一個(gè)流表時(shí)，其對(duì)應(yīng)的動(dòng)作集合（ActionSet）中的所有動(dòng)作指令將被執(zhí)行（例如轉(zhuǎn)發(fā)至某一端口、修改數(shù)據(jù)包某一字段、丟棄數(shù)據(jù)包等）。OpenFlowv1.3對(duì)多流表作了進(jìn)一步完善，提出在多流表的每個(gè)表的最后都可以增加一個(gè)Table-miss項(xiàng)（缺省可不設(shè)置該項(xiàng)），用于指明數(shù)據(jù)包與其他流表項(xiàng)都不匹配。Table-miss項(xiàng)將沒有發(fā)生匹配作為一個(gè)流表項(xiàng)，它的所有匹配域都支持通配，同時(shí)該流表項(xiàng)的優(yōu)先級(jí)被設(shè)置為0級(jí)是最低的優(yōu)先級(jí)。多流表流水線處理的架構(gòu)和流程能夠有效地提升流表處理效率，但它也使得交換機(jī)的流表匹配時(shí)延增加，同時(shí)提高了數(shù)據(jù)流量生成及維護(hù)的算法復(fù)雜度。組表OpenFlowv1.1中增加了組表（GroupTable）的概念，并一直被后續(xù)的版本所沿用。組是OpenFlow為數(shù)據(jù)包指定在多個(gè)流中執(zhí)行相同操作集的高效方法，其對(duì)應(yīng)的組表結(jié)構(gòu)如圖2-12所示。如圖2-12所示，每一條OpenFlow組表記錄都包括：組標(biāo)志符、組類型、計(jì)數(shù)器和動(dòng)作桶。利用組表，每個(gè)數(shù)據(jù)流可以被劃分到相應(yīng)的組中，動(dòng)作指令的執(zhí)行可以針對(duì)屬于同一個(gè)組標(biāo)識(shí)符的所有數(shù)據(jù)包，這非常適合于實(shí)現(xiàn)廣播或多播，或者規(guī)定只執(zhí)行某些特定的操作集。其中，組類型規(guī)定了是否所有的動(dòng)作桶中的指令都會(huì)被執(zhí)行，其定義了如下四種類型:所有（all）：執(zhí)行所有動(dòng)作桶中的動(dòng)作，可用組播或廣播。選擇（select）：執(zhí)行該組中的一個(gè)動(dòng)作桶中的動(dòng)作，可用于多路徑。間接（indirect）：執(zhí)行組的一個(gè)確定的動(dòng)作桶中的動(dòng)作。快速故障恢復(fù)（fastfailover）：執(zhí)行第一個(gè)具有有效活動(dòng)端口的動(dòng)作桶中的指令。匹配域隨著OpenFlow的演進(jìn)，匹配域（在OpenFlowv1.0中稱作包頭域）的覆蓋范圍越來越廣，以滿足更靈活的轉(zhuǎn)發(fā)決策。隨著版本的升級(jí)，匹配域數(shù)量不斷增加，應(yīng)用方式也進(jìn)行了調(diào)整，其相應(yīng)的變化如表2-4所示。表2-4OpenFlow流表匹配域的變化示意規(guī)范版本匹配域數(shù)量匹配域主要變化備注v1.012——v1.115在v1.0基礎(chǔ)上增加了元數(shù)據(jù)（Metadata）、MPLS標(biāo)簽、MPLS業(yè)務(wù)類別等3個(gè)匹配域支持將v1.0中定義的IP協(xié)議、TCP/UDP源端口、目的端口進(jìn)行復(fù)用元數(shù)據(jù)不是數(shù)據(jù)包自帶的，而是多流表處理時(shí)所需的附加信息，用于在同一交換機(jī)的不同流表間傳遞信息v1.236將v1.1定義為可復(fù)用的匹配域全部拆分—

增加對(duì)IPv6信息的匹配規(guī)定OpenFlow交換機(jī)必須支持13個(gè)匹配域v1.339增加了PBB、tunnel-ID及IPv6擴(kuò)展頭的匹配OpenFlow交換機(jī)必須支持的匹配域與v1.2相同計(jì)數(shù)器變化OpenFlow流表中的計(jì)數(shù)器隨著流表功能的完善也有了變化，主要包括：OpenFlowv1.1增加了組表的概念，因此計(jì)數(shù)器相應(yīng)增加了針對(duì)每組、每個(gè)動(dòng)作桶的相關(guān)統(tǒng)計(jì)。OpenFlowv1.3增加了針對(duì)數(shù)據(jù)流的計(jì)量，因此計(jì)數(shù)器相應(yīng)增加了針對(duì)各個(gè)數(shù)據(jù)流計(jì)量表（meter）的統(tǒng)計(jì)。指令和動(dòng)作如前文流表結(jié)構(gòu)變化中所述，OpenFlowv1.0中將流表項(xiàng)與數(shù)據(jù)包匹配后對(duì)其進(jìn)行的操作稱為動(dòng)作，而在OpenFlowv1.1及其后續(xù)版本中都將其改稱為指令。每個(gè)流表項(xiàng)中都會(huì)包含一組指令，當(dāng)一個(gè)數(shù)據(jù)包與流表項(xiàng)相匹配時(shí)，相應(yīng)的指令就會(huì)被執(zhí)行。這些指令對(duì)應(yīng)的操作既包括一些之前定義的對(duì)數(shù)據(jù)包的動(dòng)作，也包括在OpenFlow后續(xù)版本中引入的新的處理（例如流水線處理等等）。針對(duì)OpenFlow功能的增加（例如OpenFlowv1.1中對(duì)多流表、組表的支持、OpenFlowv1.3對(duì)數(shù)據(jù)流計(jì)量的支持），OpenFlowv1.1和v1.3先后增加了五條指令和一條指令，相關(guān)信息如表2-5所示。表2-5OpenFlow流表新增指令信息版本類型名稱說明v1.1可選指令A(yù)pply-Actions立即進(jìn)行指定的動(dòng)作，而不改變動(dòng)作集合。這個(gè)指令經(jīng)常用來修改數(shù)據(jù)包，在兩個(gè)表之間或者執(zhí)行同類型的多個(gè)動(dòng)作的時(shí)候使用可選指令Clear-Actions在動(dòng)作集合中立即清除所有動(dòng)作必備指令Write-Actions將指定的動(dòng)作添加到正在運(yùn)行的動(dòng)作集合中可選指令Write-Metadatametadata/mask在元數(shù)據(jù)區(qū)域記錄元數(shù)據(jù)必備指令Goto-Tablenext-table-id轉(zhuǎn)到流水線處理進(jìn)程中的下一張表的IDv1.3可選指令Metermeterid直接將包計(jì)量后丟棄OpenFlow指令的執(zhí)行可能會(huì)導(dǎo)致數(shù)據(jù)包在多流表之間的轉(zhuǎn)移，也可