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