openflow 1.0
作為第一個公示版本的OpenFlow協(xié)議，of1.0協(xié)議相對而言比較基礎(chǔ)。of1.0的協(xié)議雖然表述的是單級流表的概念，但是在匹配流程圖中就披露出多級流表的設計意圖?；蛟Sopenflow協(xié)議從始至終都打算設計多級流表，只是受限于當時的研究進度，所以在of1.0中介紹的是單級流表。of1.0詳細介紹了設備解析數(shù)據(jù)包的過程，這也算是匹配中的一個環(huán)節(jié)吧。
交換機接收到數(shù)據(jù)包后按照流程解析數(shù)據(jù)包，然后利用解析后的頭部字段進行表查找。用于表查找的頭部字段依賴于數(shù)據(jù)包的類型。解析數(shù)據(jù)包的過程如下所示：
1、初始化包頭域，按照包頭域的組成一一設置每個字段，其中入端口是接收數(shù)據(jù)包的物理端口。
2、如果數(shù)據(jù)包類型是VLAN（0x8100），那么就使用VLAN ID和PCP字段進行表查找。解封以太網(wǎng)類型為下面的以太網(wǎng)類型解析做準備。
3、（可選）如果是ARP數(shù)據(jù)包（0x0806），那么匹配字段就可能包含IP源和目的地址。
4、如果是IP數(shù)據(jù)包（0x800），那么匹配字段就會包含IP首部。如果IP數(shù)據(jù)包的分段偏移量不為0或者設置了多個分段bit位，那么將所有傳輸端口設為0。如果IP數(shù)據(jù)包在IP協(xié)議族中的編號為6或17(分別是TCP或UDP類型），那么匹配字段包含傳輸端口。如果編號為1（ICMP數(shù)據(jù)包）則包含Type和Code字段。
數(shù)據(jù)包解析后就開始匹配，從table 0 開始匹配，如果匹配成功則對該數(shù)據(jù)包執(zhí)行相應的動作，更新相應的計數(shù)器。如果沒有找到匹配項則將數(shù)據(jù)包交給控制器。
?openflow 1.1 & 1.2
就匹配流程圖而言，1.1與1.2匹配過程是一樣的。從table0開始匹配，按照優(yōu)先級高低依次匹配該流表中的流表項。如果匹配不成功則由流表決定是發(fā)送給控制器、發(fā)送給后續(xù)流表，還是丟棄。如果匹配成功則更新計數(shù)器，指令集（更新動作集、匹配字段、元數(shù)據(jù)），并且由指令決定是否繼續(xù)查找后續(xù)流表，如果繼續(xù)查找則按照更新后的匹配字段進行匹配，如果不繼續(xù)查找流表則終止匹配并執(zhí)行動作集。
數(shù)據(jù)包只有與流表項中所有匹配項都匹配才算是匹配成功，如果一個流表的匹配項值為ANY則該流表項可以匹配包頭域中的任意值。
從of1.2版本及以后，數(shù)據(jù)包解析流程圖就略過了，畢竟隨著版本升級of協(xié)議難度也越來越大，所涉及的東西也越來越多了，想必有些內(nèi)容就不作贅述了。
?openflow 1.3 & 1.4
of1.3匹配流程圖與之前的版本相比多了一個table-miss流表項，事實上此前版本就已經(jīng)存在table-miss概念了，只是沒有在流程圖中呈現(xiàn)出來而已。of1.3和1.4版本的匹配流程一致，都如下所述。
首先解析進入設備的報文，然后從table 0開始匹配，按照優(yōu)先級高低依次匹配該流表中的流表項，一個報文在一個流表中只會匹配上一條流表項。通常根據(jù)報文的類型，報文頭的字段例如源MAC地址、目的MAC地址、源IP地址、目的IP地址等進行匹配，大部分匹配還支持掩碼進行更精確、靈活的匹配。也可以通過報文的入端口或元數(shù)據(jù)信息來進行報文的匹配，一個流表項中可以同時存在多個匹配項，一個報文需要同時匹配流表項中所有匹配項才能匹配該流表項。報文匹配按照現(xiàn)有的報文字段進行，比如前一個流表通過apply actions改變了該報文的某個字段，則下一個表項按修改后的字段進行匹配。如果匹配成功，則按照指令集里的動作更新動作集，或更新報文/匹配集字段，或更新元數(shù)據(jù)和計數(shù)器。根據(jù)指令是否繼續(xù)前往下一個流表，不繼續(xù)則終止匹配流程執(zhí)行動作集，如果指令要求繼續(xù)前往下一個流表則繼續(xù)匹配，下一個流表的ID需要比當前流表ID大。當報文匹配失敗了，如果存在無匹配流表項（table miss）就按照該表項執(zhí)行指令，一般是將報文轉(zhuǎn)發(fā)給控制器、丟棄或轉(zhuǎn)發(fā)給其他流表。如果沒有table miss表項則默認丟棄該報文。
?openflow 1.5
OpenFlow1.5協(xié)議的匹配流程幾乎沒有改變，只是細化了action set的執(zhí)行過程。其中著重細化了output動作。OpenFlow 1.5協(xié)議引進了Egress Tables，細化了output action，可以在輸出端口處理數(shù)據(jù)包。當一個數(shù)據(jù)包輸出到某個端口時，首先會從第一個egress table開始處理，由流表項定義處理方式并且轉(zhuǎn)發(fā)給其他egress table。
此外，1.5協(xié)議還添加了一個數(shù)據(jù)包類型識別流程。之前版本的OpenFlow協(xié)議中表明交換機默認處理以太網(wǎng)數(shù)據(jù)包，1.5版本中交換機還可以處理PPP數(shù)據(jù)包。不過1.5協(xié)議中的數(shù)據(jù)包類型識別流程還處于研究階段，每個交換機只能處理一種類型的數(shù)據(jù)包，相信后續(xù)協(xié)議中交換機必然可以同時處理多種數(shù)據(jù)包。
協(xié)議演進?
從OpenFlow1.0到1.5，OpenFlow匹配流程在不斷豐富，從中我們也可以琢磨出一絲OpenFlow協(xié)議的演進的痕跡。OpenFlow協(xié)議的發(fā)展演進一直都圍繞著兩個方面，一方面是增強控制面，讓系統(tǒng)功能更豐富、更靈活；另一方面是增強轉(zhuǎn)發(fā)層面，可以匹配更多的關(guān)鍵字，執(zhí)行更多的動作。每一個后續(xù)版本的OpenFlow協(xié)議都在前一版本的基礎(chǔ)上進行或多或少的改進，但是自OpenFlow1.1版本開始與之前版本不兼容，ONF為了保證產(chǎn)業(yè)界有一個穩(wěn)定發(fā)展的平臺，把OpenFlow1.0和1.3版本作為長期支持的穩(wěn)定版本，因此一段時間內(nèi)后續(xù)版本都要保持和穩(wěn)定版本的兼容。
1.0版本中只有單流表，為了避免單流表膨脹，1.1版本采用多級流表，以流水線的形式提高數(shù)據(jù)包匹配效率。由于OpenFlow將所有的控制協(xié)議都集中到控制器中，導致控制器成為眾矢之的，為了提高安全性和健壯性，1.2版本引進了多控制器的概念。為了處理多種類型的數(shù)據(jù)包，1.5版本添加了數(shù)據(jù)包類型識別流程。除此之外1.5還引進了egress table，原先由控制器指定output的相關(guān)操作，現(xiàn)在將這一功能下放到交換機中，一方面提高數(shù)據(jù)包的處理效率，另一方面改進OpenFlow“最初的偏激”。畢竟將所有控制功能都集中到控制器中是否合理還有待商榷，很明顯的是這樣的做法會導致控制器很累。OpenFlow正在一點一點摸索一個平衡點，既能保證控制器充分的控制器主權(quán)又讓交換機有一定的自主功能。或許，最初的OpenFlow十分理想化，但是在其不斷演進的過程中我們可以看出OpenFlow在不斷向?qū)嶋H應用場景靠攏。
