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

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