如果要問(wèn)當(dāng)前最著名、最有影響力的基于SDN技術(shù)搭建的商用網(wǎng)絡(luò)是哪個(gè)，我想大多數(shù)人都會(huì)投票給Google的B4網(wǎng)絡(luò)，一方面因?yàn)镚oogle本 身的名氣，另一方面也是因?yàn)镚oogle在這個(gè)網(wǎng)絡(luò)的搭建上投入大、周期長(zhǎng)，最后的驗(yàn)證效果也很好，是為數(shù)不多的大型SDN商用案例，而且非常成功，是充 分利用了SDN優(yōu)點(diǎn)（特別是OpenFlow協(xié)議）的案例。

背景介紹

Google 的網(wǎng)絡(luò)分為數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)（IDC Network）及骨干網(wǎng)（Backbone Network，也可以稱為WAN網(wǎng)）。其中WAN網(wǎng)按照流量方向由兩張骨干網(wǎng)構(gòu)成，分別為：第一，數(shù)據(jù)中心之間互聯(lián)的網(wǎng)絡(luò)（Inter-DC WAN，即G-scale Network），用來(lái)連接Google位于世界各地之間的數(shù)據(jù)中心，屬于內(nèi)部網(wǎng)絡(luò)；第二，面向Internet用戶訪問(wèn)的網(wǎng)絡(luò)（Internet- facing WAN，即I-Scale Network）。Google選擇使用SDN來(lái)改造數(shù)據(jù)中心之間互聯(lián)的WAN網(wǎng)（即G-scale Network），因?yàn)檫@個(gè)網(wǎng)絡(luò)相對(duì)簡(jiǎn)單，設(shè)備類型以及功能比較單一，而且WAN網(wǎng)鏈路成本高昂（比如很多海底光纜），所以對(duì)WAN網(wǎng)的改造無(wú)論建設(shè)成本、運(yùn)營(yíng)成本收益都非常顯著。他們把這個(gè)網(wǎng)絡(luò)稱為B4（我在網(wǎng)上搜了一下也沒(méi)找到該名字的由來(lái)）。

Google的數(shù)據(jù)中心之間傳輸?shù)臄?shù)據(jù)可以分為三大類：

1、用戶數(shù)據(jù)備份，包括視頻、圖片、語(yǔ)音和文字等；

2、遠(yuǎn)程跨數(shù)據(jù)中心存儲(chǔ)訪問(wèn)，例如計(jì)算資源和存儲(chǔ)資源分布在不同的數(shù)據(jù)中心；

3、大規(guī)模的數(shù)據(jù)同步（為了分布式訪問(wèn)，負(fù)載分擔(dān)）。

這三大類從前往后數(shù)據(jù)量依次變大，對(duì)延時(shí)的敏感度依次降低，優(yōu)先級(jí)依次變低。這些都是B4網(wǎng)絡(luò)改造中涉及 到的流量工程（TE，Traffic Engineering）部分所要考慮的因素。

促使Google使用SDN改造WAN網(wǎng)的最大原因是 當(dāng)前連接WAN網(wǎng)的鏈路帶寬利用率很低。GoogleWAN網(wǎng)的出口設(shè)備有上百條對(duì)外鏈路，分成很多的ECMP負(fù)載均衡組，在這些均衡組內(nèi)的多條鏈路之間 用的是基于靜態(tài)Hash的負(fù)載均衡方式。由于靜態(tài)Hash的方式并不能做到完全均衡，為了避免很大的流量都被分發(fā)到同一個(gè)鏈路上導(dǎo)致丟包，Google不 得不使用過(guò)量鏈路，提供比實(shí)際需要多得多的帶寬。這導(dǎo)致實(shí)際鏈路帶寬利用率只有30%~40%，且仍不可避免有的鏈路很空，有的鏈路產(chǎn)生擁塞，設(shè)備必須支持很大的包緩存，成本太高，而且也無(wú)法對(duì)上文中不同的數(shù)據(jù)區(qū)別對(duì)待。從一個(gè)數(shù)據(jù)中心到另外一個(gè)數(shù)據(jù)中心，中間可以經(jīng)過(guò)不同的數(shù)據(jù)中心，比如可以是 A→B→D，也可以是A→C→D，也許有的時(shí)候B很忙，C很空，路徑不是最優(yōu)。除此之外，增加網(wǎng)絡(luò)可見性、穩(wěn)定性，簡(jiǎn)化管理，希望靠應(yīng)用程序來(lái)控制網(wǎng)絡(luò)， 都是本次網(wǎng)絡(luò)改造的動(dòng)機(jī)之一。以上原因也決定了Google這個(gè)基于SDN的網(wǎng)絡(luò)，最主要的應(yīng)用是流量工程，最主要的控制手段是軟件應(yīng)用程序。

Google對(duì)B4網(wǎng)絡(luò)的改造方法，充分考慮了其網(wǎng)絡(luò)的一些特性以及想要達(dá)到的主要目標(biāo)，一切都圍繞這幾個(gè)事實(shí)或者期望。

Google B4網(wǎng)絡(luò)的絕大多數(shù)的流量都是來(lái)自數(shù)據(jù)中心之間的數(shù)據(jù)同步應(yīng)用，這些應(yīng)用希望給它們的帶寬越大越好，但是可以容忍偶爾的擁塞丟包、鏈路不通以及高延時(shí)。Google再?gòu)?qiáng)大，數(shù)據(jù)中心的數(shù)量也是有限的，這個(gè)特點(diǎn)意味著Controller的scalability的壓力相對(duì)小很多。

Google能夠控制應(yīng)用數(shù)據(jù)以及每個(gè)數(shù)據(jù)中心的邊界網(wǎng)絡(luò)，希望通過(guò)控制應(yīng)用數(shù)據(jù)的優(yōu)先級(jí)和網(wǎng)絡(luò)邊緣的突發(fā)流量（Burst）來(lái)優(yōu)化路徑，緩解帶寬壓力，而不是靠無(wú)限制地增大出口帶寬。

這個(gè)網(wǎng)絡(luò)必須要考慮成本，雖然Google富可敵國(guó)，但其WAN網(wǎng)的數(shù)據(jù)流量每天都在增加，無(wú)法承受無(wú)止境的設(shè)備成本的增加，所以必須想辦法降低成本。

Google的部署分為三個(gè)階段。

第一階段在2010年春天完成，把OpenFlow交換機(jī)引入到網(wǎng)絡(luò)里面，但這時(shí)OpenFlow交換機(jī)對(duì)同網(wǎng)絡(luò)中的其他非OpenFlow設(shè)備表現(xiàn)得就像是傳統(tǒng)交換機(jī)一樣，只是網(wǎng)絡(luò)協(xié)議都是在Controller上完成的，外部行為來(lái)看表現(xiàn)得仍然像傳統(tǒng)網(wǎng)絡(luò)。

第二階段是到 2011年中完成，這個(gè)階段引入更多流量到OpenFlow網(wǎng)絡(luò)中，并且開始引入SDN管理，讓網(wǎng)絡(luò)開始向SDN網(wǎng)絡(luò)演變。

第三個(gè)階段在2012年初完 成，整個(gè)B4網(wǎng)絡(luò)完全切換到了OpenFlow網(wǎng)絡(luò)，引入了流量工程，完全靠OpenFlow來(lái)規(guī)劃流量路徑，對(duì)網(wǎng)絡(luò)流量進(jìn)行極大的優(yōu)化。

為了對(duì)這個(gè)方案進(jìn)行充分測(cè)試，Google運(yùn)用了其強(qiáng)大的軟件能力，用軟件模擬了整個(gè)B4網(wǎng)絡(luò)拓?fù)浜土髁俊?/p>

具體實(shí)現(xiàn)

雖然該網(wǎng)絡(luò)的應(yīng)用場(chǎng)景相對(duì)簡(jiǎn)單，但用來(lái)控制該網(wǎng)絡(luò)的這套系統(tǒng)并不簡(jiǎn)單，它充分體現(xiàn)了Google強(qiáng)大的軟件能力。這個(gè)網(wǎng)絡(luò)一共分為三個(gè)層次，分別是物理設(shè)備層（Switch Hardware）、局部網(wǎng)絡(luò)控制層（Site Controllers）和全局控制層（Global）。一個(gè)Site就是一個(gè)數(shù)據(jù)中心。第一層的物理交換機(jī)和第二層的Controller在每個(gè)數(shù)據(jù)中心的內(nèi)部出口的地方都有部署，而第三層的SDN網(wǎng)關(guān)和TE服務(wù)器則是在一個(gè)全局統(tǒng)一的控制地。 第一層：物理設(shè)備層

第一層的物理交換機(jī)是Google自己設(shè)計(jì)并請(qǐng)ODM廠商代工的，用了24顆16×10Gb的芯片，搭建了一個(gè)128個(gè)10Gb端口的交換機(jī)。交換機(jī)里面運(yùn) 行了OpenFlow協(xié)議，但它并非僅僅使用一般的OpenFlow交換機(jī)最常使用的ACL表，而是用了TTP的方式，包括ACL表、路由表和 Tunnel表等。但向上提供的是OpenFlow接口，只是內(nèi)部做了包裝。這些交換機(jī)會(huì)把BGP/IS-IS協(xié)議報(bào)文送到Controller去供 Controller處理。

說(shuō)到TTP這里要稍微介紹一下，TTP是ONF的FAWG工作組提出的一個(gè)在現(xiàn)有芯片架構(gòu)基礎(chǔ)上包裝出 OpenFlow接口的一個(gè)折中方案。TTP是Table Typing Patterns的縮寫，中文不知道怎么翻譯能比較精確地表達(dá)它的本意，但TTP想要達(dá)到的目的是很清楚的，就是要利用現(xiàn)有芯片的處理邏輯和表項(xiàng)來(lái)組合出 OpenFlow想要達(dá)到的功能，當(dāng)然不可能是所有功能，只能是部分。在2013年，ONF覺(jué)得TTP這個(gè)名字含義不夠清晰，無(wú)法望文生義，所以他們又給 它改了個(gè)名字叫NDM（Negotiabable Data-plane Model），即可協(xié)商的數(shù)據(jù)轉(zhuǎn)發(fā)面模型。我認(rèn)為這個(gè)名字比TTP好多了，不僅因?yàn)槲夷芊g出來(lái)，更重要的是這個(gè)名字中的三個(gè)單詞都能體現(xiàn)方案的精髓。 NDM其實(shí)是定義了一個(gè)框架，基于這個(gè)框架，允許廠商基于實(shí)際的應(yīng)用需求和現(xiàn)有的芯片架構(gòu)來(lái)定義很多種不同的轉(zhuǎn)發(fā)模型，每種模型可以涉及到多張表，匹配不 同的字段，基于查找結(jié)果執(zhí)行不同的動(dòng)作。由于是基于現(xiàn)有的芯片，所以無(wú)論匹配的字段還是執(zhí)行的動(dòng)作都是有限制的，不能隨心所欲。關(guān)于NDM有很多東西可以 講，但不是本文重點(diǎn)，這里略過(guò)不表。不過(guò)，我認(rèn)為也許NDM將是OpenFlow的最終方案，它將大大推動(dòng)OpenFlow以及SDN的發(fā)展。

第二層：局部網(wǎng)絡(luò)控制層

在我看來(lái)，第二層最復(fù)雜。第二層在每個(gè)數(shù)據(jù)中心出口并不是只有一臺(tái)服務(wù)器，而是有一個(gè)服務(wù)器集群，每個(gè)服務(wù)器上都運(yùn)行了一個(gè)Controller，一臺(tái)交換 機(jī)可以連接到多個(gè)Controller，但其中只有一個(gè)處于工作狀態(tài)。一個(gè)Controller可以控制多臺(tái)交換機(jī)，一個(gè)名叫Paxos的程序用來(lái)進(jìn)行 leader選舉（即選出工作狀態(tài)的Controller）。從文檔的描述來(lái)看，貌似這種選舉不是基于Controller的，而是基于功能的。也就是說(shuō) 對(duì)于控制功能A，可能選舉Controller1為leader；而對(duì)于控制功能B，則有可能選舉Controller2為leader。這里說(shuō)的leader就是OpenFlow標(biāo)準(zhǔn)里面的master。

Google用的Controller是基于分布式的Onix Controller改造來(lái)的。Onix是Nicira、Google、NEC和Berkerly大學(xué)的一些人一起參與設(shè)計(jì)的，由Nicira主導(dǎo)。這是 一個(gè)分布式架構(gòu)的Controller模型，被設(shè)計(jì)用來(lái)控制大型網(wǎng)絡(luò)，具有很強(qiáng)的可擴(kuò)展性。它通過(guò)引入Control Logic（控制邏輯，可以認(rèn)為是特殊的應(yīng)用程序）、Controller和物理設(shè)備三層架構(gòu)，每個(gè)Controller只控制部分物理設(shè)備，并且只發(fā)送 匯聚過(guò)后的信息到邏輯控制服務(wù)器，邏輯控制服務(wù)器了解全網(wǎng)的拓?fù)淝闆r，來(lái)達(dá)到分布式控制的目的，從而使整個(gè)方案具有高度可擴(kuò)展性。

顯而易見，這個(gè)架構(gòu)非常適合Google的網(wǎng)絡(luò)，對(duì)每個(gè)特定的控制功能（比如TE或者Route），每個(gè)site有一組Controller（邏輯上是一個(gè)）用 來(lái)控制該數(shù)據(jù)中心WAN網(wǎng)的交換機(jī)，而一個(gè)中心控制服務(wù)器運(yùn)行控制邏輯來(lái)協(xié)調(diào)所有數(shù)據(jù)中心的所有Controller。 在Controller之上跑了兩個(gè)應(yīng)用，一個(gè)叫RAP，是Routing Application Proxy的意思，作為SDN應(yīng)用跟Quagga通信。Quagga是一個(gè)開源的三層路由協(xié)議棧，支持很多路由協(xié)議，Google用到了BGP和IS- IS。其中跟數(shù)據(jù)中心內(nèi)部的路由器運(yùn)行eBGP，跟其他數(shù)據(jù)中心WAN里面的設(shè)備之間運(yùn)行iBGP。Onix Controller收到下面交換機(jī)送上來(lái)的路由協(xié)議報(bào)文以及鏈路狀態(tài)變化通知時(shí)，自己并不處理，而是通過(guò)RAP把它送給Quagga協(xié)議棧。 Controller會(huì)把它所管理的所有交換機(jī)的端口信息都通過(guò)RAP告訴Quagga，Quagga協(xié)議棧管理了所有這些端口。Quagga協(xié)議計(jì)算出 來(lái)的路由會(huì)在Controller里面保留一份（放在一個(gè)叫NIB的數(shù)據(jù)庫(kù)里面，即Network Information Base，類似于傳統(tǒng)路由中的RIB，而NIB是Onix里面的概念），同時(shí)會(huì)下發(fā)到交換機(jī)中。路由的下一跳可以是ECMP，即有多個(gè)等價(jià)下一跳，通過(guò) Hash選擇一個(gè)出口。這是最標(biāo)準(zhǔn)的傳統(tǒng)路由轉(zhuǎn)發(fā)。它的路由架構(gòu)圖如圖2所示。

跑在Controller上面的另外一個(gè)應(yīng)用程序叫TE Agent，跟全局的Gateway通信。每個(gè)OpenFlow交換機(jī)的鏈路狀態(tài)（包括帶寬信息）會(huì)通過(guò)TE Agent送給全局的Gateway，Gateway匯總后，送給TE Server進(jìn)行路徑計(jì)算。

第三層：全局控制層

第三層中，全局的TE Server通過(guò)SDN Gateway從各個(gè)數(shù)據(jù)中心的控制器收集鏈路信息，從而掌握路徑信息。這些路徑被以IP-In-IP Tunnel的方式創(chuàng)建而不是TE最經(jīng)常使用的MPLS Tunnel，通過(guò)Gateway到Onix Controller，最終下發(fā)到交換機(jī)中。當(dāng)一個(gè)新的業(yè)務(wù)數(shù)據(jù)要開始傳輸時(shí)，應(yīng)用程序會(huì)評(píng)估該應(yīng)用所需要耗用的帶寬，為它選擇一條最優(yōu)路徑（如負(fù)載最輕 的但非最短路徑雖不丟包但延時(shí)大），然后把這個(gè)應(yīng)用對(duì)應(yīng)的流，通過(guò)Controller安裝到交換機(jī)中，并跟選擇的路徑綁定在一起，從而整體上使鏈路帶寬 利用率達(dá)到最優(yōu)。

對(duì)帶寬的分配和路徑的計(jì)算是Google本次網(wǎng)絡(luò)改造的主要目標(biāo)也是亮點(diǎn)所在，所以值得深入分析一下。我反復(fù)研究了一下Google的這一套邏輯，理出大概的思路，分享如下。 最理想的情況下，當(dāng)然是能夠基于特定應(yīng)用程序來(lái)分配帶寬，但那樣的話會(huì)導(dǎo)致流表項(xiàng)是一個(gè)天文數(shù)字，既不可能也無(wú)必要。Google的做法很聰明：基于｛源數(shù) 據(jù)中心，目的數(shù)據(jù)中心，QoS｝來(lái)維護(hù)流表項(xiàng)，因?yàn)橥活悜?yīng)用程序的QoS優(yōu)先級(jí)（DSCP）都是一樣的，所以這樣做就等同于為所有的從一個(gè)數(shù)據(jù)中心發(fā)往 另外一個(gè)數(shù)據(jù)中心的同類別的數(shù)據(jù)匯聚成一條流。注意：?jiǎn)螚l流的出口并不是一個(gè)端口，而是一個(gè)ECMP組，芯片轉(zhuǎn)發(fā)時(shí)，會(huì)從ECMP組里面根據(jù)Hash選取 一條路徑轉(zhuǎn)發(fā)出去。

劃分出流之后，根據(jù)管理員配置的權(quán)重、優(yōu)先級(jí)等參數(shù)，使用一個(gè)叫做bandwidth的函數(shù)計(jì)算出要為這條流分配多少帶寬。為了公平起見，帶寬分配是有最小帶寬和最大帶寬的，既不會(huì)飽死，也不會(huì)餓死。TE算法有兩個(gè)輸入源，一個(gè)是Controller通過(guò)SDN Gateway報(bào)上來(lái)的拓?fù)浜玩溌非闆r，另一個(gè)就是bandwidth函數(shù)的輸出結(jié)果。TE算法要考慮多種因素，不僅僅是需要多少帶寬這么簡(jiǎn)單。

TE Server將計(jì)算出來(lái)的每個(gè)流映射到哪個(gè)tunnel，并且分配多少帶寬的信息通過(guò)SDN Gateway下發(fā)到Controller，再由Controller安裝到交換機(jī)的TE轉(zhuǎn)發(fā)表中（ACL），這些轉(zhuǎn)發(fā)表項(xiàng)的優(yōu)先級(jí)高于LPM路由表。 圖3是Google的TE架構(gòu)圖。

有心的讀者可能會(huì)注意到，既然有了TE，那還用BGP路由協(xié)議干什么？沒(méi)錯(cuò)，TE和BGP都可以為一條流生成轉(zhuǎn)發(fā)路徑，但TE生成的路徑放在ACL 表，BGP生成的放在路由表（LPM），進(jìn)來(lái)的報(bào)文如果匹配到ACL表項(xiàng)，會(huì)優(yōu)先使用ACL，匹配不到才會(huì)用路由表的結(jié)果。一臺(tái)交換機(jī)既要處理從內(nèi)部發(fā)到 別的數(shù)據(jù)中心的數(shù)據(jù)，又要處理從別的數(shù)據(jù)中心發(fā)到本地?cái)?shù)據(jù)中心內(nèi)部的數(shù)據(jù)。對(duì)于前者，需要使用ACL Flow表來(lái)進(jìn)行匹配查找，將報(bào)文封裝在Tunnel里面轉(zhuǎn)發(fā)去，轉(zhuǎn)發(fā)路徑是TE指定的，是最優(yōu)路徑。而對(duì)于后者，則是解封裝之后直接根據(jù)LPM路由表轉(zhuǎn) 發(fā)。還有路過(guò)的報(bào)文（從一個(gè)數(shù)據(jù)中心經(jīng)過(guò)本數(shù)據(jù)中心到另外一個(gè)數(shù)據(jù)中心），這種報(bào)文也是通過(guò)路由表轉(zhuǎn)發(fā)。

這種基于優(yōu)先級(jí)的OpenFlow 轉(zhuǎn)發(fā)表項(xiàng)的設(shè)計(jì)還有一個(gè)很大的好處，就是TE和傳統(tǒng)路由轉(zhuǎn)發(fā)可以獨(dú)立存在，這也是為什么B4網(wǎng)絡(luò)改造可以分階段進(jìn)行的原因。開始可以先用傳統(tǒng)路由表，后面 再把TE疊加上來(lái)。而且，就算是以后不想用TE時(shí)，也可以直接把TE給禁掉就行了，不需要對(duì)網(wǎng)絡(luò)做任何的改造。

SDN Gateway的作用

這里架構(gòu)中有一個(gè)角色是SDN Gateway，為什么要有這個(gè)角色呢？它對(duì)TE Server抽象出了OpenFlow和交換機(jī)的實(shí)現(xiàn)細(xì)節(jié)，對(duì)TE Server來(lái)說(shuō)看不到OpenFlow協(xié)議以及交換機(jī)具體實(shí)現(xiàn)。Controller報(bào)上來(lái)的鏈路狀態(tài)、帶寬、流信息經(jīng)過(guò)它的抽象之后送給TEServer。TE Server下發(fā)的轉(zhuǎn)發(fā)表項(xiàng)信息經(jīng)過(guò)SDN Gateway的翻譯之后，通過(guò)Controller送給交換機(jī)，安裝到芯片轉(zhuǎn)發(fā)表中。

B4網(wǎng)絡(luò)改造效果

經(jīng)過(guò)改造之后，據(jù)說(shuō)鏈路帶寬利用率提高了3倍以上，接近100%，鏈路成本大大降低，這應(yīng)該算是最大的成效了，也是當(dāng)初最主要的目標(biāo)，現(xiàn)在看來(lái)目標(biāo)是完成 了。另外的收獲還包括網(wǎng)絡(luò)更穩(wěn)定，對(duì)路徑失效的反應(yīng)更快，管理大大簡(jiǎn)化，也不再需要交換機(jī)使用大的包緩存，對(duì)交換機(jī)的要求降低。Google認(rèn)為 OpenFlow的能力已得到驗(yàn)證和肯定，包括對(duì)整個(gè)網(wǎng)絡(luò)的視圖可以看得很清楚，可以更好地來(lái)做Traffice Engineering，從而更好地進(jìn)行流量管控和規(guī)劃，更好地路由規(guī)劃，能夠清楚地了解網(wǎng)絡(luò)里面發(fā)生了什么事情，包括監(jiān)控和報(bào)警。按照Google的話 說(shuō)，超出了其最初的期望。 該案例對(duì)SDN的積極意義

Google這個(gè)基于SDN的網(wǎng)絡(luò)改造項(xiàng)目影響非常大，對(duì)SDN的推廣有著良好的示范作用，所以是ONF官網(wǎng)上僅有的兩個(gè)用戶案例之一（另外一個(gè)是NEC的一個(gè)醫(yī)院網(wǎng)絡(luò)的基于SDN的網(wǎng)絡(luò)虛擬化改造案例）。這個(gè)案例亮點(diǎn)極多，總結(jié)如下。

1. 這是第一個(gè)公開的使用分布式Controller的SDN應(yīng)用案例，讓更多的人了解到分布式Controller如何協(xié)同工作，以及工作的效果如何。

2. 這是第一個(gè)公開的用于數(shù)據(jù)中心互聯(lián)的SDN案例，它證明了即使是在Google這種規(guī)模的網(wǎng)絡(luò)中，SDN也完全適用，盡管這不能證明SDN在數(shù)據(jù)中心內(nèi)部也能用，但至少可以證明它可以用于大型網(wǎng)絡(luò)。只要技術(shù)得當(dāng)，可擴(kuò)展性問(wèn)題也完全可以解決。

3. QoS。流量工程一直是很多數(shù)據(jù)中心以及運(yùn)營(yíng)商網(wǎng)絡(luò)的重點(diǎn)之一，Google這個(gè)案例給大家做了一個(gè)很好的示范。事實(shí)上，據(jù)我了解，在Google之后， 又有不少數(shù)據(jù)中心使用SDN技術(shù)來(lái)解決數(shù)據(jù)中心互聯(lián)的流量工程問(wèn)題，比如美國(guó)的Vello公司跟國(guó)內(nèi)的盛科網(wǎng)絡(luò)合作推出的數(shù)據(jù)互聯(lián)方案就是其中之一，雖然 沒(méi)有Google的這么復(fù)雜，但也足以滿足其客戶的需要。

4. 這個(gè)案例也向大家演示了如何在SDN環(huán)境中運(yùn)行傳統(tǒng)的路由協(xié)議，讓大家了解到，SDN也并不都是靜態(tài)配置的，仍然會(huì)有動(dòng)態(tài)協(xié)議。

5. 在這個(gè)案例中，軟件起到了決定性的作用，從應(yīng)用程序到控制器，再到路由協(xié)議以及整個(gè)網(wǎng)絡(luò)的模擬測(cè)試平臺(tái)，都離不開Google強(qiáng)大的軟件能力。它充分展示了SDN時(shí)代，軟件對(duì)網(wǎng)絡(luò)的巨大影響力以及它所帶來(lái)的巨大價(jià)值。

Google的OpenFlow交換機(jī)使用了TTP的方式而不是標(biāo)準(zhǔn)的OpenFlow流表，但在接口上仍然遵循OpenFlow的要求，它有力地證明了要支持SDN，或者說(shuō)要支持OpenFlow，并不一定需要專門的OpenFlow芯片。包裝一下現(xiàn)有的芯片，就可以解決大部分問(wèn)題，就算有些問(wèn)題還不能解決， 在現(xiàn)有的芯片基礎(chǔ)上做一下優(yōu)化就可以了，而不需要推翻現(xiàn)有芯片架構(gòu)，重新設(shè)計(jì)一顆所謂的OpenFlow芯片。

6. 這個(gè)案例實(shí)現(xiàn)了Controller之間的選舉機(jī)制，OpenFlow標(biāo)準(zhǔn)本身并沒(méi)有定義如何選舉。這個(gè)案例在這方面做了嘗試。

OpenFlow的挑戰(zhàn)

作為一次完整的全方位的實(shí)踐，當(dāng)然不能只總結(jié)好的東西，也總結(jié)了OpenFlow仍然需要提高改進(jìn)的地方，包括OpenFlow協(xié)議仍然不成熟，Master Controller（或者說(shuō)leader）的選舉和控制面的責(zé)任劃分仍有很多挑戰(zhàn)，對(duì)于大型網(wǎng)絡(luò)流表項(xiàng)的下發(fā)會(huì)速度比較慢，到底哪些功能要留在交換機(jī) 上、哪些要移走還沒(méi)有一個(gè)很科學(xué)的劃分。但Google認(rèn)為，這些問(wèn)題都是可以克服的。

Google技術(shù)不走尋常路的特點(diǎn)也體現(xiàn)在它基于OpenFlow搭建的數(shù)據(jù)中心WAN網(wǎng)絡(luò)（B4） 中。雖然Google已在SIGCOMM上公布了自己的B4網(wǎng)絡(luò)技術(shù)細(xì)節(jié)，但很多人認(rèn)為太深?yuàn)W。本文將從專業(yè)的角度，深入B4網(wǎng)絡(luò)的各個(gè)層次，用通俗易懂的語(yǔ)言對(duì)其進(jìn)行全面解讀。