前不久一個(gè)研究SDN的博士生和博主抱怨說：現(xiàn)在開源的SDN控制器性能都好差啊，每秒鐘2K個(gè)新流就會(huì)提示packet-in太多太防，停止工作妻顶。博主問他是如何定義一個(gè)流的，他說用TCP 5 tuple蜒车。博主又問他是怎么產(chǎn)生那么密集的packet-in的讳嘱，他說是用一臺(tái)服務(wù)器直接向SDN控制器發(fā)packet-in。博主接著問那臺(tái)服務(wù)器和SDN控制器的配置酿愧，他說服務(wù)器是8核沥潭，SDN控制器是4核腥泥。博主沒有繼續(xù)問更多的問題鳄厌，而是在想：是什么原因讓人們?cè)O(shè)計(jì)出這樣的實(shí)驗(yàn)？如果這個(gè)實(shí)驗(yàn)的數(shù)據(jù)正確，那么又意味著什么呢臂聋？

直到今天，不少人對(duì)SDN和OpenFlow都抱有兩個(gè)誤解话侄。第一闹获，采用OpenFlow的SDN控制器是在per flow的更新流表。第二颜懊，每個(gè)flow有自己的生命周期蓝角，控制器只為active flow更新流表，其余的表項(xiàng)則會(huì)被刪除饭冬。之所以是誤解使鹅，是因?yàn)槿魏我粋€(gè)版本的OpenFlow標(biāo)準(zhǔn)都沒有說per flow的更新，更沒有說只為active flow更新流表昌抠。事實(shí)上患朱，OpenFlow僅僅定義了控制器和交換機(jī)之間的一種接口，根本沒提要如何使用這些接口炊苫。

一個(gè)非常有趣的問題是：人們?yōu)槭裁磿?huì)對(duì)SDN和OpenFlow有以上的誤解裁厅？首先，OpenFlow這個(gè)名字非常糟糕侨艾，它本身似乎在暗示人們這個(gè)協(xié)議是per flow的执虹，但事實(shí)根本不是這樣。如果有機(jī)會(huì)為這個(gè)協(xié)議重新起名唠梨，OpenTable會(huì)更合適袋励，因?yàn)樗举|(zhì)上是開放了交換機(jī)里的各種流表，SDN控制器可以編輯這些流表当叭。

另外OpenFlow協(xié)議本身需要交換機(jī)采取match+action的方式進(jìn)行轉(zhuǎn)發(fā)茬故，而不是傳統(tǒng)的2層+3層+TCAM的轉(zhuǎn)發(fā)方式。這個(gè)轉(zhuǎn)發(fā)方式的轉(zhuǎn)變是造成人們產(chǎn)生以上誤解的一個(gè)重要原因蚁鳖。在早期的OpenFlow實(shí)踐中磺芭，人們發(fā)現(xiàn)在現(xiàn)有的硬件ASIC上很難采取wildcard match+action的轉(zhuǎn)發(fā)方式。最立竿見影的在硬件上部署SDN的方案是僅僅利用ASIC上的TCAM表醉箕，因?yàn)檫@張表支持wildcard match钾腺，支持drop，forward讥裤，broadcast放棒，copy to CPU等多種action。TCAM表與OpenFlow協(xié)議的轉(zhuǎn)發(fā)方式有著最直接的對(duì)應(yīng)的關(guān)系坞琴。于是市場(chǎng)上就出現(xiàn)了早期的支持OpenFlow的交換機(jī)：它們支持OpenFlow協(xié)議哨查，將OpenFlow的每一個(gè)Flow Modification Message轉(zhuǎn)變?yōu)橄鄳?yīng)的TCAM表項(xiàng)。這對(duì)SDN和OpenFlow的普及有非常積極的影響剧辐。但它有一個(gè)問題：TCAM實(shí)在是有些貴寒亥，導(dǎo)致即便到了今天邮府，最成熟的ASIC也只支持3K-4K的TCAM表項(xiàng)，這么小的表最多只能做做demo溉奕，規(guī)模部署根本是天方夜譚褂傀。天才的SDN先驅(qū)們想到一個(gè)辦法來克服TCAM表過小的問題，那就是采用reactive的方式來編寫TCAM加勤。通俗來說就是：只保存那些active流的表項(xiàng)仙辟，那些不再active的表項(xiàng)都會(huì)因?yàn)槌瑫r(shí)而被刪除。具體的做法是：對(duì)于每個(gè)新流的第一個(gè)包鳄梅，交換機(jī)不知道該如何處理叠国，于是交換機(jī)會(huì)向控制器發(fā)送一個(gè)packet-in，控制器收到這個(gè)packet-in之后戴尸，計(jì)算路徑并通過Flow_Mod告訴各個(gè)交換機(jī)如何轉(zhuǎn)發(fā)這個(gè)新流粟焊。如果與這個(gè)流相關(guān)的各個(gè)表項(xiàng)在一段時(shí)間內(nèi)沒有見到新包，這個(gè)流被認(rèn)為已經(jīng)結(jié)束孙蒙，相關(guān)的表項(xiàng)被從TCAM表中清除项棠。這個(gè)reactive的辦法確實(shí)從一定程度上解決了TCAM表過小的問題。不過SDN的后繼者們卻忘記了TCAM過小是因挎峦，reactive是果香追。如果一個(gè)初學(xué)者剛剛讀完OpenFlow spec，他可能會(huì)想當(dāng)然的以為SDN by design就是reactive的坦胶，而忽視了去探尋reactive的原因透典。事實(shí)上OpenFlow spec和是不是reactive沒有任何關(guān)系。

歷史講到這里迁央，我們?cè)俜祷仡^看看文章開始的那個(gè)實(shí)驗(yàn)掷匠。不難發(fā)現(xiàn)，實(shí)驗(yàn)設(shè)計(jì)者在潛意識(shí)中就想當(dāng)然的認(rèn)為OpenFlow是per flow的并且是reactive的岖圈！帶著這樣的假設(shè)設(shè)計(jì)實(shí)驗(yàn)本身就不科學(xué)。很遺憾钙皮，這兩個(gè)不正確的假設(shè)仍然在不少SDN研究者的腦子里根深蒂固蜂科，于是在實(shí)驗(yàn)中，他們會(huì)依靠產(chǎn)生不同的TCP 5 tuple來模擬大量新流短条。在工業(yè)界中导匣，這樣的誤解會(huì)少很多，因?yàn)樵谠O(shè)計(jì)任何一個(gè)SDN產(chǎn)品之前茸时，人們會(huì)評(píng)估設(shè)計(jì)的瓶頸：如果每一個(gè)新的TCP 5 tuple都會(huì)引起packet-in的話贡定，SDN控制器肯定會(huì)成為系統(tǒng)瓶頸，這種系統(tǒng)設(shè)計(jì)會(huì)被毫無疑問的在第一時(shí)間拋棄可都。我們從來沒有聽說過哪個(gè)廠商公布他們的控制器處理packet-in的能力缓待，不是因?yàn)檫@是他們的機(jī)密蚓耽，而是因?yàn)橄到y(tǒng)的穩(wěn)定程度在設(shè)計(jì)上就與新流產(chǎn)生的速度無關(guān)，根本就沒有人關(guān)心這個(gè)測(cè)試結(jié)果旋炒。

分析到這里步悠，我們已經(jīng)知道reactive的模式雖然在一定程度上解決了由于TCAM過小帶來的問題，但也讓SDN控制器成為了系統(tǒng)的瓶頸瘫镇。如果文章最初的那個(gè)實(shí)驗(yàn)數(shù)據(jù)是正確的鼎兽，那么reactive的SDN控制器根本無法控制大規(guī)模的網(wǎng)絡(luò)和流量。在這種情況下铣除，也許會(huì)有人建議去研究如何提高SDN控制器的性能谚咬，使其不再成為瓶頸。但這樣便是典型的舍本逐末尚粘，解決一個(gè)本來可以不存在的問題择卦。試想，如果TCAM足夠大背苦，人們還會(huì)采用reactive的方式來設(shè)計(jì)SDN系統(tǒng)嗎互捌？顯然不會(huì)。與之相對(duì)應(yīng)行剂，proactive會(huì)成為一個(gè)更合理的方式秕噪，即：在新流還沒有來到之前，就把相應(yīng)的表項(xiàng)編輯好厚宰，這樣腌巾，新流出現(xiàn)就不會(huì)引起packet-in了。

看到這里铲觉，也許有朋友會(huì)問：1) SDN控制器怎么知道會(huì)有什么流產(chǎn)生澈蝙？2)?TCAM只有那么大，如果在新流產(chǎn)生之前就主動(dòng)的編輯好流表撵幽，怎么裝得下灯荧？

其實(shí)這兩個(gè)問題都是偽問題，之所以把它們列在這里是為了讓文章的邏輯保持連貫盐杂。提出問題1的人仍然在局限在SDN是per flow的誤解里面逗载。除非人為的調(diào)度，SDN控制器永遠(yuǎn)不會(huì)聰明到能夠猜出會(huì)有什么新流產(chǎn)生链烈。但是沒關(guān)系厉斟，問題的關(guān)鍵不在于知道會(huì)有什么新流產(chǎn)生，而在于知道各個(gè)設(shè)備在哪里强衡〔粱啵互聯(lián)網(wǎng)發(fā)展到今天，從來都不是per flow轉(zhuǎn)發(fā)，而是per device轉(zhuǎn)發(fā)感挥！傳統(tǒng)的二層交換機(jī)需要學(xué)習(xí)(vlan, mac)到port的映射缩搅，其實(shí)就是在學(xué)習(xí)各個(gè)device在哪里。只要知道m(xù)ac1在port1链快，不管什么flow誉己，只要是去mac1的就轉(zhuǎn)發(fā)到port1。同樣的邏輯可以非常自然的推廣到SDN里面域蜗，控制器可以學(xué)習(xí)各個(gè)device在哪里巨双，并且告知網(wǎng)絡(luò)中的交換機(jī)們?nèi)绾芜_(dá)到各個(gè)設(shè)備。學(xué)習(xí)的渠道可以很多霉祸，比如ARP筑累，LLDP，LACP等等丝蹭。學(xué)習(xí)mac不過癮慢宗，還可以學(xué)IP”即總之镜沽，如果把per flow的mental model轉(zhuǎn)變?yōu)閜er device的mental model，SDN系統(tǒng)設(shè)計(jì)的一切都會(huì)變得自然很多贱田。

問題2是一個(gè)更大的偽問題缅茉。正如在之前的段落中介紹的那樣，SDN的先驅(qū)們非常理想化的設(shè)計(jì)了OpenFlow協(xié)議男摧，后來發(fā)現(xiàn)只有昂貴TCAM才能夠和OpenFlow協(xié)議產(chǎn)生比較直接的對(duì)應(yīng)蔬墩，于是OpenFlow和TCAM才成為難兄難弟，總是成雙成對(duì)的出現(xiàn)耗拓。問題是：我們的目的是用集中控制的方式簡(jiǎn)化網(wǎng)絡(luò)管理拇颅，為什么一定要用TCAM？又為什么一定要用OpenFlow乔询？這才觸及到問題的本質(zhì)樟插。

博主的答案是：我們不一定要用TCAM，我們也不一定要用OpenFlow竿刁。一切都是design choice岸夯，只有不同的選擇，沒有最好的選擇们妥。比較有代表性的是學(xué)院派和工業(yè)界的選擇。學(xué)院派以Nick McKeown教授為代表勉吻，主張徹底重新設(shè)計(jì)硬件交換芯片[link]监婶，使其完全適應(yīng)OpenFlow協(xié)議。工業(yè)界的做法沒有那么激進(jìn)：cisco設(shè)計(jì)了ACI和OpFlex，讓協(xié)議適應(yīng)硬件ASIC惑惶；BigSwitch沿用了OpenFlow煮盼，但是只使用TCAM存放復(fù)雜的規(guī)則，而用L2和L3的表來存放一般的轉(zhuǎn)發(fā)規(guī)則带污，在最大程度上規(guī)避了TCAM大小的局限僵控。在多方的共同努力之下，SDN和OpenFlow設(shè)計(jì)之初的種種限制正在成為歷史鱼冀，reactive的系統(tǒng)設(shè)計(jì)也完成了它的歷史使命”ㄆ疲現(xiàn)在實(shí)用的proactive的SDN系統(tǒng)大概長(zhǎng)這個(gè)樣子：1) SDN控制器不斷學(xué)習(xí)網(wǎng)絡(luò)中的各種設(shè)備，包括交換機(jī)千绪，鏈路充易，服務(wù)器，虛擬機(jī)等等荸型，2) 管理員通過某種語言配置業(yè)務(wù)關(guān)系盹靴，比如multi-tier application和service chaining。3) SDN控制器翻譯用戶配置并且通過南向接口編輯交換機(jī)中的L2瑞妇，L3表稿静，這里的表項(xiàng)不是per flow的，而是per device的辕狰。SDN控制器同樣通過南向接口將租戶的業(yè)務(wù)邏輯轉(zhuǎn)變?yōu)門CAM表項(xiàng)改备，這里的表項(xiàng)更復(fù)雜，可能需要匹配source+destination以及L4的某些字段柳琢。?

采用proactive的方式設(shè)計(jì)SDN系統(tǒng)還有一個(gè)更大的好處是它極大的簡(jiǎn)化了High Availability(HA)的設(shè)計(jì)绍妨，讓SDN控制器不再成為整個(gè)系統(tǒng)的單點(diǎn)故障(single point of failure)。以后的文章會(huì)對(duì)這一點(diǎn)進(jìn)行深入討論柬脸。

講了這么多他去，博主只是在傳達(dá)一個(gè)信息：采用reactive的方式設(shè)計(jì)SDN系統(tǒng)是有歷史原因的。現(xiàn)在這些原因都已經(jīng)不再存在倒堕，proactive的SDN系統(tǒng)設(shè)計(jì)已經(jīng)成為主流灾测。