OpenFlow v1.0
v1.0協議消息列表如下：
分為三類消息：Controller-to-switch，asynchronous和symmertric。
v1.0（包含至少一個流表，每個流表包含多個流表項）流表項構成：
| 頭字段 | 計數器 | 行動 |
| In Port,Source Address,Destination Address... | Per Table:Active Entries[0],Packet Lookups[0]... Per Flow:Received Packets[10]... |
Forward/Drop |
| ... | ... | ... |
頭字段：
| 內容 | 說明 |
| In port | 入端口 |
| Ethernet source address | 以太網幀的源以太網地址 |
| Ethernet destination address | 以太網幀的目標以太網地址 |
| Ethernet type | 以太網幀的類型字段 |
| Vlan id | Vlan標簽的VID |
| Vlan priority | |
| IP source address | IP源地址 |
| IP destination address | IP目的地址 |
| IP protocol | IP頭的協議字段 |
| ToS | IP頭的ToS字段 |
| Transport source port/ICMP type | TCP/UDP的源端口號；ICMP頭的類型 |
| Transport destination port/ICMP code | TCP/UDP的目的端口號；ICMP頭的代碼 |
計數器：
1.各流表的Per Table計數器：
| 內容 | 比特數 |
| Active Entries | 32 |
| Packet Lookups | 64 |
| Packet Matches | 64 |
2.各物理端口的Per Port計數器：
| 內容 | 比特數 |
| Received Packets | 64 |
| Received Bytes | 64 |
| Duration(msec) | 32 |
| Duration(usec) | 32 |
3.各流表項的Per Flow計數器：
| 內容 | 比特數 |
| Transmit Packets | 64 |
| Transmit Bytes | 64 |
| Transmit Overrun Errors | 64 |
4.各隊列的Per Queue計數器：
| 內容 | 比特數 |
| Received Packets | 64 |
| Transmitted Packets | 64 |
| Received Bytes | 64 |
| Transmitted Bytes | 64 |
| Receive Drops | 64 |
| Transmit Drops | 64 |
| Receive Errors | 64 |
| Transmit Errors | 64 |
| Receive Frame Alignment Errors | 64 |
| Receive Overrun Errors | 64 |
| Receive CRC Errors | 64 |
| Collisions | 64 |
行動：
Forward,Drop,Enqueue,Modify-Field。
v1.0數據包只能與一個流表的一個流表項匹配。而v1.1以上數據包可以與多個流表的一個流表項匹配。
v1.1流表項構成：
匹配字段（即v1.0的頭字段），計數器，指令。
指令：對與流表項匹配的數據包所執行的命令，提供了執行行動，在之后批量執行的行動集中添加及刪除行動、寫入元數據等功能，移動到已指定流表的動作等指令。
五種指令如下：
1.Apply-Actions：不變更行動集，僅執行指定的行動列表。用於在2個流表中傳遞並修改數據包或執行同一類型的多個行動時。
2.Clear-Actions：清楚行動集中的所有行動。
3.Write-Actions：將指定的多個行動合並到當前的行動集中，行動集中已存在同一類型時將其覆蓋，不存在同一類型時進行添加。
4.Write-Metadata：寫入元數據中。
5.Goto-Table：Goto語句。移動到流水線后方連接的流表中，不能跳轉到現有位置前方的流表中。最后的流表中不能包含Goto語句。
v1.3流表項構成：
匹配字段，優先級，計數器，指令，超時，Cookie。
下面是OF1.3的數據包結構：
消息格式：of協議數據包由OF Header 和OF Message兩部分組成：
Header結構：
1 struct ofp_header { 2 uint8_t version; /*OFP_VERSION.*/ 3 uint8_t type; /*One of the OFPT_constants.*/ 4 uint16_t length; /*Length including this ofp_header.*/ 5 uint32_t xid; /*Transaction id associated with this packet.*/ 6 };
Message結構與具體消息類型有關，上面的type類型有以下幾種：
1 enum ofp_type { 2 /* Immutable messages. */ 3 OFPT_HELLO=0, /* Symmetric message */ 4 OFPT_ERROR=1, /* Symmetric message */ 5 OFPT_ECHO_REQUEST=2, /* Symmetric message */ 6 OFPT_ECHO_REPLY=3, /* Symmetric message */ 7 OFPT_VENDOR=4, /* Symmetric message */ 8 9 /* Switch configuration messages. */ 10 OFPT_FEATURES_REQUEST=5, /* Controller/switch message */ 11 OFPT_FEATURES_REPLY=6, /* Controller/switch message */ 12 OFPT_GET_CONFIG_REQUEST=7, /* Controller/switch message */ 13 OFPT_GET_CONFIG_REPLY=8, /* Controller/switch message */ 14 OFPT_SET_CONFIG=9, /* Controller/switch message */ 15 16 /* Asynchronous messages. */ 17 OFPT_PACKET_IN=10, /* Async message */ 18 OFPT_FLOW_REMOVED=11, /* Async message */ 19 OFPT_PORT_STATUS=12, /* Async message */ 20 21 /* Controller command messages. */ 22 OFPT_PACKET_OUT=13, /* Controller/switch message */ 23 OFPT_FLOW_MOD=14, /* Controller/switch message */ 24 OFPT_GROUP_MOD=15, /* Controller/switch message */ 25 OFPT_PORT_MOD=16, /* Controller/switch message */ 26 OFPT_TABLE_MOD=17, /* Controller/switch message */ 27 28 /*Multipart messages.*/ 29 OFPT_MULTIPART_REQUEST=18, /* Controller/switch message */ 30 OFPT_MULTIPART_REPLY=19, /* Controller/switch message */ 31 32 /* Barrier messages. */ 33 OFPT_BARRIER_REQUEST=20, /* Controller/switch message */ 34 OFPT_BARRIER_REPLY=21, /* Controller/switch message */ 35 36 /* Queue Configuration messages. */ 37 OFPT_QUEUE_GET_CONFIG_REQUEST=22, /* Controller/switch message */ 38 OFPT_QUEUE_GET_CONFIG_REPLY=23, /* Controller/switch message */ 39 40 /* Controller role change request messages. */ 41 OFPT_ROLE_REQUEST=24, /* Controller/switch message */ 42 OFPT_ROLE_REPLY=25, /* Controller/switch message */ 43 44 /* Asynchronous message configuration. */ 45 OFPT_GET_ASYNC_REQUEST=26, /* Controller/switch message */ 46 OFPT_GET_ASYNC_REPLY=27, /* Controller/switch message */ 47 OFPT_SET_ASYNC=28, /* Controller/switch message */ 48 49 /* Meters and rate limiters configuration messages. */ 50 OFPT_METER_MOD=29, /* Controller/switch message */ 51 };
控制器與交換機溝通交流過程:
1.hello消息
當交換機連接到控制器時，交換機與控制器會相互發送hello包，而hello消息中只包含of Header，of Header中的version字段為發送方支持的最高版本的of協議版本。如果兩者協議版本兼容，則建立of連接，否則發送error消息，斷開連接。交換機向控制器發送的Hello消息如下所示：
2.features消息
連接建立后，控制器向交換機發送一個features Request消息查詢交換機的特性，features request消息也只包含of Header，交換機接受到該消息之后會返回一個features reply消息，這個消息就包含Header和Message。ps:request和reply兩個消息的Transaction ID是一樣的。
控制器向交換機發送的OFPT_FEATURES_REQUEST消息：
交換機向控制器響應的OFPT_FEATURES_REPLY消息：
reply消息分析：
[0:8]為header(version、type、length、xid)
[8:32]長度24byte為sw的features，包含如下：
datapath_id：交換機的標識符，低48位是一個MAC地址，高16位是自定義的。
n_buffers：一次最多緩存的數據包數量。
n_tables：表示交換機支持的流表數量。每個流表可以設置不同的通配符和不同數量的流表項。控制器和交換機第一次通信的時候，控制器會從feature_reply消息中找出交換機支持多少流表，如果控制器還想了解大小、類型和流表查詢的順序，就發送一個ofpst_table stats請求，交換機必須按照數據包遍歷流表的順序把這些流表回復給控制器，並且精確匹配流表排在通配流表前。
auxiliary_id：標識輔助連接。
capabilities：所支持的功能。交換機的一些詳細信息。
reserved：保留字段。
3.OFPT_MULTIPART_*消息：
1）OFPMP_PORT_DESC：用於傳遞端口信息
控制器向交換機發送請求端口信息OFPT_MULTIPART_REQUEST，OFPMP_PORT_DESC：
交換機向控制器發送端口回應信息，包括local以及其他連接端口，OFPT_MULTIPART_REPLY，OFPMP_PORT_DESC：
2）OFPMP_DESC：描述交換機的一些額外信息
控制器請求交換機的一些額外信息，OFPT_MULTIPART_REQUEST，OFPMP_DESC：
交換機向控制器回送一些額外信息，OFPT_MULTIPART_REPLY，OFPMP_DESC：
3）OFPMP_TABLE_FEATURES：獲取流表信息
控制器請求交換機的流表信息，OFPT_MULTIPART_REQUEST，OFPMP_TABLE_FEATURES：
交換機回送給控制器自己的流表信息，table_id表示第幾級流表，OFPT_MULTIPART_REPLY，OFPMP_TABLE_FEATURES[Malformed Packet]：
4.config消息
Of交換機中需要控制器配置的屬性有兩個flags和miss_send_len。Flags用來指示交換機如何處理IP分片數據包；miss_send_len用來表示當一個交換機無法處理數據，將數據上報給控制器時發送的最大字節數。與轉發action中的output中定義的max_len字段一致。
控制器向交換機發送OFPT_GET_CONFIG_REQUEST消息：
消息解釋：為了確保配置項已經被寫入交換機，控制器會在發送了SET_CONFIG消息之后立即發送一個BARRIER_REQUEST消息，這個消息的作用就是讓交換機執行完這個消息之前的所有命令再執行此消息之后的請求，確保交換機的flags和miss send length屬性設置成功。當然是有BARRIER_REPLAY消息的。
而SET_CONFIG消息是沒有應答消息的，控制器在設置完交換機屬性之后會發送GET_CONFIG_REQUEST消息查詢交換機的屬性。這個消息也是只有of_header的。交換機接收到此消息之會返回一個GET_CONFIG_REPLAY消息。
交換機向控制器發送OFPT_BARRIER_REPLY：
交換機向控制器發送OFPT_GET_CONFIG_REPLY：
5.role消息
一個交換機可能同時與多個處於同等地位的控制器相連。多個控制器處於Slave狀態，至多一個控制器處於 Master 狀態。每一個控制器都會通過一個OFPT_ROLE_REQUEST消息與交換機交流它的角色，並且交換機必須記住每一個連接的控制器的角色。控制器可能在任何時刻改變自己角色。
控制器向交換機下發OFPT_ROLE_REQUEST消息：
消息解釋：這里Role表示該控制器是master角色。
交換機向控制器下發OFPT_ROLE_REPLY消息：
6.flow_mod消息
Flow-Mod消息用於添加、刪除、修改openflow交換機的流表項信息；Flow-Mod消息共有5種類型：ADD、DEKETE、DELETE-STRICT、MODIFY、MODIFY_STRICT。
ADD類型消息用來添加一條新的流表項（flow entry）
DELETE類型消息用來刪除所有符合一定條件的流表項
DELETE‐STRICT類型消息用來刪除某一條指定的流表項
MODIFY類型消息用來修改所有符合一定條件的流表項
MODIFY‐STRICT類型息用來修改某一條指定的流表項
ps：Flow-Mod消息對應修改的是流表中的流表項（flow entry）而不是整個流表（flow table）。
控制器向交換機下發OFPT_FLOW_MOD之DELETE消息：
消息解釋：
Cookie為控制器定義流表項標識符
Command是flow-mod的類型，可以是ADD、DELETE、DELETE-STRICT、MODIFY、MODIFY-STRCT；
Ldle_timeout是流表項的空閑超時時間；
Hard_timeout是流表項的最大生存時間；
Priority為流表項的優先級，交換機優先匹配高優先級的流表項；
Buffer_id為交換機中的緩沖區ID，flow-mod消息可以指定一個緩沖區的ID，該緩沖區的數據包會按照此flow-mod消息的action列處理。如果是手動下發的流，buffer_id應填-1，即0xffff,告訴交換機這個數據包並沒有緩存在隊列中。
Out_port為刪除流表的flow_mod消息提供的額外的匹配參數。
Flags為flow-mod命令的一些標志位，可以用來指示流表刪除后是否發送flow-removed消息，添加流表時是否檢查流表重復項，添加的流表項是否為應急流表項。
當OFPFF_SEND_FLOW_REM 被設置的時候，表項超時刪除會觸發一條表項刪除的信息。
當OFPFF_CHECK_OVERLAP 被設置的時候，交換機必須檢查同優先級的表項之間是否有匹配范圍的沖突。
當OFPFF_EMERG_被設置的時候，交換機將表項當作緊急表項，只有當與控制器連接斷的時候才啟用。
控制器向交換機下發OFPT_FLOW_MOD之ADD消息，這里output是指向controller：
7.group_mode消息
這里抓取了四個OFPT_GROUP_MODE消息，還不知道干嘛的？
四個消息分別如下所示：
8.PACKET_OUT消息
Packet-out消息的應用場景：
指定某一個數據包的處理方法
讓交換機產生一個數據包並按照action流表處理。
典型應用：鏈路發現
控制器向一個交換機發送packet-out消息，buffer_id=-1，data段為某種特殊數據包，actions為從交換機的某個端口進行轉發，如果發出這個數據包的端口另一端也連接一個openflow交換機，對端的交換機會產生一個packet-in消息將這個特殊的數據包包上交給控制器，從而控制器他側到一條鏈路的存在（控制器實現鏈路發現，就是依靠packet-out消息）。
當控制器斷電或者交換機與控制器之間的連接斷開，則交換機會尋找備用控制器，當無法找到備用控制器時便會進入緊急模式（交換機初始化時也是在這個模式下），在緊急模式下，交換機默認將所有接受到的數據包丟棄。
控制器向交換機下發OFPT_PACKET_OUT消息：
協議解釋：
buffer_id為交換機中緩存數據的buffer_id（同flow-mod）；特別注意的是當buffer_id為”-1”的時候，指定的緩沖區為packet-out消息的data段。
In_port為packet-out消息提供額外的匹配信息，當packet-out的buffer_id=-1，並且action流表中指定了output=TABLE的動作，in_port將作為data段數據包的額外匹配信息進行流表查詢。
action_len指定了action列表的長度，用來區分actions和data段Data為一個緩沖區，可以存儲一個以太網幀。
9.PACKET_IN消息
Packet-in事件在以下兩種情況下會被觸發：
1.當交換機收到一個數據包后，並未與流表中匹配成功，那么交換機就會將數據封裝在Packer-in消息中，發送給控制器處理。此時數據包會被緩存在交換機中等待處理。
2.交換機流表所指示的action列表中包含轉發給控制器的動作（Output=Controller），此時數據不會被緩存在控制器中。
交換機向控制器遞交OFPT_PACKET_IN消息：
協議解釋：
buffer_id是packet-in消息所攜帶的數據包在交換機中的緩存ID
Total_len為data段的長度
In_port數據包進入交換機的入端口號
Reason為packet-in事件的產生原因
同時，從reason的消息格式也可以看出觸發packet-in的兩種情況：OFPR_NO_MATCH和OFPR_ACTION。
10.echo消息
查詢連接狀態，確保通信通暢。當沒有其他的數據包進行交換時，controller會定期循環給sw發送OFPT_ECHO_REQUEST。
控制器向交換機發送OFPT_ECHO_REQUEST消息：
交換機向控制器發送OFPT_ECHO_REPLY消息：
11.OFPT_PORT_STATUS，交換機向控制器下報告自己的端口狀態
