OpenFlow v1.0緩存
v1.0協議消息列表以下:async
分爲三類消息:Controller-to-switch,asynchronous和symmertric。ide
v1.0(包含至少一個流表,每一個流表包含多個流表項)流表項構成: ui
頭字段 | 計數器 | 行動 |
In Port,Source Address,Destination Address... | Per Table:Active Entries[0],Packet Lookups[0]...this Per Flow:Received Packets[10]...spa |
Forward/Drop |
... | ... | ... |
頭字段:3d
內容 | 說明 |
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頭的代碼 |
計數器:code
1.各流表的Per Table計數器:orm
內容 | 比特數 |
Active Entries | 32 |
Packet Lookups | 64 |
Packet Matches | 64 |
2.各物理端口的Per Port計數器:blog
內容 | 比特數 |
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,交換機向控制器下報告本身的端口狀態