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

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

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