傳統網路要靠後了，新型網路來了，SDN真的來了，SDN介紹三

前面我們說到，SDN憑藉著轉控分離的網路架構，解決了很多傳統網路中難以解決的難題，但是問題來了，這種架構怎麼實現呢？我們的控制中心如何獲取實時路況，並且下發命令給各個交警呢？

我們的革命者們同時也開發了一個新的協議：openflow，該協議用於調度中心和交警之間進行溝通，並指導轉發器進行轉發。具體來說，openflow需要解決以下3個問題：

1：建立調度中心和交警之間的溝通通道

首先，調度中心和交警之間需要有一條順暢並且安全的溝通通道，所以openflow協議規定了控制器和轉發器之間必須要有一條三層可達的鏈路，通過該鏈路建立TCP連接，並採用了安全的演算法進行加密（比如TLS）。同時，鏈路需要通過定時的Hello進行保活，保證鏈路出現問題時能及時發現。

2：從交警那裡收集各個路口的路況

由於是統一管理，每個路口的性能指標需要規範化，比如路口一共有幾條分叉路口（埠），每條路有多寬，能承擔多少車流量（帶寬），每條路是不是有事故導致通行不暢（鏈路故障），每條路目前的車流量大小（鏈路佔用率）以及路口的調度能力（設備表項大小）等。這些數據必須以統一的格式上傳調度中心。同時，如果哪個路口修了新的路，也需要將上述指標主動上報給調度中心。

這部分內容很好實現，只需要定義一個標準的消息格式即可。

3：告訴交警如何指揮車輛

前面我們說過，交警只需要聽從調度中心的命令即可，但是如果針對每一輛車調度中心都要給交警下發一個指令未免也太效率低下了。於是革命者們想了一個法子，讓調度中心給每個交警一張表，這張表的內容簡單來說就是：

交警們收到這張表，就直接根據車輛信息直接進行指揮，同時記錄下每種車輛的數量用於統計本路口的指標。這樣一來，就不用每輛車都需要調度中心直接下命令，交警直接可以自己進行指揮。

可以看到，這張表無疑就是整個openflow協議的核心，我們稱之為流表。

在openflow協議提出之初，革命者們的初衷很簡單，傳統網路中各種各樣的轉發協議太複雜了，我們就根據流量本身的屬性，針對每種流量在定義一個動作，這種方式無疑會大大簡化設備上的轉發流程，於是在openflow1.0版本中，流表是長這樣的：

在匹配域中裝著車輛的各種信息，在最初的想法中，革命者是想通過一個可擴展的數據結構使流表可以匹配任何數量和種類的車輛信息（比如TLV架構）。

可是理想很豐滿，現實很骨感，openflow1.0推出後，遇到了一系列的阻礙，其中最主要的兩個問題就是轉發效率和成本的問題，怎麼回事呢？

原來現在交通指揮已經智能化了，交警們拿到這張表以後，首先會把這張表存到一個智能終端（轉發晶元），指揮交通時，直接使用智能終端進行指揮，這台智能終端主要的成本就在存儲流表的存儲器（TCAM）上。以前，需要儲存的表都比較小，如路由表僅包含目的IP、下一跳、出介面等幾項。而這次的新表要求能匹配任意的車輛信息。

我們舉個例子：如果交警僅關注車輛從哪裡來（SIP），和到哪裡去（DIP），假設車輛可能會從A、B、C三個地方來，可能會到a、b、c三個地方去。則我們需要幾條表項呢？我想表應該是這樣的：

我需要9條表項就可以包含所有的車輛情況（Aa、Ab、Ac、Ba、Bb、Bc、Ca、Cb、Cc），而如果現在交警還需要關注車輛所屬的城市（假設車輛可能來自m城市或者n城市），那麼簡單算一下，我們就需要18條表項來包含所有的車輛情況（Aam、Abm、Acm、Bam、Bbm、Bcm、Cam、Cbm、Ccm、Aan、Abn、Acn、Ban、Bbn、Bcn、Can、Cbn、Ccn）

可以看到，隨著需要匹配的欄位數量的增加，表項數目會指數級的增加。這無疑增加了需要的存儲器大小，交警查看這些表項的時間也會增加，從而導致了成本增高以及轉發效率的降低。

為了解決這個問題，革命者在openflow1.1版本中，引入了多表的機制。還是以上面例子繼續說，剛才我們說假設車輛可能會從A、B、C三個地方來，可能會到a、b、c三個地方去則需要9條表項，我們現在把這個表分成兩個表：、

表二：

先匹配表一：車輛從哪裡來，再去匹配表二：車輛要去哪裡。可以看到，表一加上表二已經可以包含所有車輛的情況，但是表項的數量卻減少為6條，表項數量從乘法關係變成了加法關係。

這樣無疑大幅減少了流表的大小，表項數量的減少同時也降低了交警查表所需要的時間。一舉解決了成本和查表效率的問題。

在後續的openflow1.2、openflow1.3和openflow1.4版本中，革命者們還做了一系列優化，包括增加了大量可以匹配的車輛信息，同時也增加了調度中心的數量，保證在一個調度中心故障的情況下交警依然可以從其他調度中心獲得指令等。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！