OpenFlow控制器與OpenFlow交換機之間的通信

OpenFlow控制器與OpenFlow交換機之間的通信1.建?安全通道OpenFlow控制器是通過安全通道和OpenFlow交換機進?通信的，安全通道由控制??絡建?，不受OpenFlow交換機中的流表項OpenFlow中，安全通道通過TLS來實現(xiàn)，控制器與交換機之間通過服務器證書和客戶機證書進?認證。在?些OpenFlow版本中（1.1及以上），控制器和交換機之間的連接有時也會通過TCP明?來實現(xiàn)。OpenFlow控制器啟動后，對指定端?進?監(jiān)聽，默認的TCP端?為6633，后更改為6653。通過三次握?后，連接建?。2.消息OpenFlow消息由64?特（8字節(jié)）組成，所有的OpenFlow消息都是從OpenFlow頭開始，圖2-1為OpenFlow頭格式。圖2-1.png各字段及其含義字段?特數(shù)內(nèi)容versiontype8OpenFlow的協(xié)議版本號消息類型（見2.1）8lengthxid1632該頭中包含的?位字節(jié)數(shù)分配給數(shù)據(jù)包的id2.1OpenFlow消息類型表2-1（參考1.3版本）類型名稱OFPT_HELLOHello消息OFPT_ERRORError消息OFPT_ECHO_REQUESTOFPT_ECHO_REPLYEcho請求消息Echo響應消息OFPT_EXPERIMENTEROFPT_FEATURES_REQUESTOFPT_FEATURES_REPLYExperimenter消息Features請求消息Features響應消息OFPT_GET_CONFIG_REQUEST類型GET_CONFIG請求消息GET_CONFIG響應消息SET_CONFIG消息Packet-In消息名稱OFPT_GET_CONFIG_REPLYOFPT_SET_CONFIGOFPT_PACKET_INOFPT_FLOW_REMOVEDOFPT_PORT_STATUSFlow-Remove消息Port-Status消息OFPT_PACKET_OUTPacket-Out消息OFPT_FLOW_MODFlow-Mod消息OFPT_GROUP_MODGROUP_MOD消息PORT-MOD消息OFPT_PORT_MODOFPT_TABLE_MODTABLE_MOD消息MULTIPART請求消息MULTIPART響應消息BARRIER請求消息BARRIER響應消息OFPT_MULTIPART_REQUESTOFPT_MULTIPART_REPLYOFPT_BARRIER_REQUESTOFPT_BARRIER_REPLYOFPT_QUERU_GET_CONFIG_REQUESTOFPT_QUEUE_GET_CONFIG_REPLYOFPT_ROLE_REQUESTOFPT_ROLE_REPLEQUERU_GET_CONFIG請求消息QUERU_GET_CONFIG響應消息Role請求消息Role響應消息OFPT_GET_ASYNC_REQUESTOFPT_GET_ASYNC_REPLYOFPT_SET_ASYNCGET_ASYNC請求消息GET_ASYNC響應消息SET_ASYNC消息OFPT_METER_MODMETER消息OFPT_HELLO消息OpenFlow交換機與OpenFlow控制器建?安全通道后，會相互發(fā)送hello包。hello消息僅有OpenFlow頭構成。且由交換機連向路由?的：?于OpenFlow協(xié)議版本的協(xié)商。內(nèi)容：發(fā)送雙?各??持的最?版本協(xié)議。結果：選擇雙??持的最低協(xié)議版本。成功：建?連接。失?。喊l(fā)送OFPT_ERROR,終?連接。Features消息（握?過程）通過互發(fā)hello消息建?連接后，執(zhí)?控制器和交換機之間的握?過程?？刂破魍ㄟ^握?過程了解交換機的相關配置信息，即可以對交換機進?控制。

發(fā)送數(shù)據(jù)：OFPT_FEATURES_REQUEST(Features請求)接收數(shù)據(jù)：OFPT_FEATURES_REPLY(Features響應)Features請求消息type=5只包含openflow頭Features響應消息type=6Features響應消息格式（如圖2-2所?）圖2-2.png各個字段的含義字段datapath_idn_buffersn_tablespad?特數(shù)內(nèi)容64OpenFlow中將各交換機稱為datapath，datapath_id是唯?識別datapath的ID32交換機可以同時緩存的數(shù)據(jù)包的最?個數(shù)交換機中?持的流表數(shù)量?于64位對其的填充824capabilitiesactions32?持的容量32?持的?動ports長度可變OpenFlow1.3之后廢除，在此不再介紹對于Features消息，每?次交換機連接到控制器，都會收到控制器的features_request，當交換機將features_reply回復給控制器后，控制器就會對交換機有了全?的了解，從?為交換機提供控制信息。OFPT_PACKET_IN消息為了將到達OpenFlow交換機的數(shù)據(jù)包發(fā)送?控制器，使?Packet-In消息，當存在：不存在與流表項?致，即沒有流表進?匹配時（Table-miss）匹配的流表項存在發(fā)送?控制器的?為時可發(fā)送Packet-In消息，包含在Packet-In中的數(shù)據(jù)可能是很多種類型，ARP和ICMP為最常見類型。如果是?播包，控制器就會將其包裝，封裝成Packet-Out數(shù)據(jù)包，將其發(fā)送給交換機，讓其進?泛洪處理（flood），即將數(shù)據(jù)包發(fā)往除in_port之外的所有端?。OFPT_PACKET_OUT消息作?：通過控制器發(fā)送交換機希望發(fā)送的數(shù)據(jù)例?：當?個沒有匹配上流表項的數(shù)據(jù)上報控制器時，控制器可以下發(fā)packet_out，指定交換機對該數(shù)據(jù)包做泛洪或丟棄動作。若OpenFlow交換機的緩存中已存在數(shù)據(jù)包，?OpenFlow控制器發(fā)出發(fā)送數(shù)據(jù)包的命令時，該消息指定表?響應數(shù)據(jù)包的buffer_id。使?Packet-out還可以將OpenFlow控制器創(chuàng)建的數(shù)據(jù)包發(fā)送給交換機，此時，buffer_id設置為-1.在Packet-out消息后添加數(shù)據(jù)包數(shù)據(jù)。OFPT_FLOW_MOD消息Flow-Mod消息是由OpenFlow控制器對OpenFlow交換機設置流表項的消息?？蓪α鞅眄椷M?添加、刪除、變更設置等操作。Flow體命令種類如下：名稱內(nèi)容OFPFC_ADD添加流表項OFPFC_MODIFY變更匹配的流表項設置（OpenFlow1.2版本以上刪除此項）僅變更完全匹配的流表項設置OFPFC_MODIFY_STRICTOFPFC_DELETE刪除匹配的流表項OFPFC_DELETE_STRICT僅刪除完全匹配的流表項ofp_flow_mod_command={0:"OFPFC_ADD",#Newflow1:"OFPFC_MODIFY",#Modifyallmatchingflows2:"OFPFC_MODIFY_STRICT",#Modifyentrystrictlymatchingwildcards3:"OFPFC_DELETE",#Deleteallmatchingflows4:"OFPFC_DELETE_STRICT"}#StrictlymatchwildcardsandpriorityOFPT_FLOW_MOD由header+match+flow_mod+action構成。flow_mod=of.ofp_header(type=14,length=72)/of.ofp_flow_wildcards(OFPFW_NW_TOS=1,OFPFW_DL_VLAN_PCP=1,OFPFW_NW_DST_MASK=0,OFPFW_NW_SRC_MASK=0,OFPFW_TP_DST=1,OFPFW_TP_SRC=1,OFPFW_NW_PROTO=1,OFPFW_DL_TYPE=1,OFPFW_DL_VLAN=1,OFPFW_IN_PORT=1,OFPFW_DL_DST=1,OFPFW_DL_SRC=1)\/of.ofp_match(in_port=msg.payload.payload.payload.in_port,dl_src=pkt_parsed.src,dl_dst=pkt_parsed.dst,dl_type=pkt_parsed.type,dl_vlan=pkt_parsed.payload.vlan,nw_tos=pkt_parsed.payload.tos,nw_proto=pkt_to,nw_src=pkt_parsed.payload.src,nw_dst=pkt_parsed.payload.dst,tp_src=0,tp_dst=0)\/of.ofp_flow_mod(cookie=0,command=0,idle_timeout=10,hard_timeout=30,out_port=msg.payload.payload.payload.payload.port,buffer_id=buffer_id,flags=1)OFP_HEADER見2.消息中OpenFlow頭結構。MATCH（數(shù)據(jù)包匹配）這個數(shù)據(jù)結構會出現(xiàn)在?乎所有重要的數(shù)據(jù)包中，因為他存的就是控制信息。如有packet_in引發(fā)的下發(fā)流表，則match部分應對應填上對應的數(shù)據(jù)，這樣下發(fā)的流表才是正確的。但是在下發(fā)的時候還需要注意許多細節(jié)，?如：并不是所有的數(shù)據(jù)包都有vlan_tag。如0x0800就是純IP，并沒有攜帶vlan_tag，所以填充式應根據(jù)packet_in的具體情況填充。并不是所有的數(shù)據(jù)都有四層端?，所以四層的源端?，?的端?都不是任何時候都能由packet_in去填充的。不去管就好了，默認的會填充?個默認值，匹配的時候不去匹配4層端?就沒有問題。WILDCARDS(通配符)在of1.0中這?的0，1意義跟我們平時接觸的如??掩碼等意義相反，如OFPFW_NW_DST_MASK=0則表?全匹配?標IP。如果為63，則表?不匹配IP。在1.3的時候，這個邏輯改成了正常與的邏輯。即1為使能匹配，0為默認不匹配。因匹配字段在1.2版本之后變化較?，請??查看OpenFlow協(xié)議。Flow-Mod消息的?動信息Flow-Mod消息的?動信息結構如圖2-3所?：圖2-3.png相關代碼如下：classofp_flow_mod(Packet):name="OpenFlowFlowModify"fields_desc=[BitField("cookie",0,64),#Opaquecontroller-issuedidentifierShortEnumField("command",0,ofp_flow_mod_command),ShortField("idle_timeout",60),ShortField("hard_timeout",0),ShortField("priority",0),IntField("buffer_id",0),ShortField("out_port",0),#flagsareimportant,the1<<0bitisOFPFF_SEND_FLOW_REM,sendOFPT_FLOW_REMOVED#1<<1bitisOFPFF_CHECK_OVERLAP,checkingiftheentries'fieldoverlaps(amongsamepriority)#1<<2bitisOFPFF_EMERG,usedonlyswitchdisconnectedwithcontroller)ShortField("flags",0)]各字段及其含義：?特字段內(nèi)容數(shù)command16表?Flow-Mod消息動作的ofp_flow_mod_command(具體參看上表具體命令)如果與流表項匹配的數(shù)據(jù)包超過idle_timeout的時間還未到，則刪除流表項idle_timeo16uthard_time16out流表項添加的時間超過hard_timeout則刪除priority1632多個流表項與數(shù)據(jù)包匹配時的優(yōu)先級buffer_idOpenFlow交換機?側(cè)保存的數(shù)據(jù)包的緩存ID僅在DELETE及DELETE_STRICT命令中使?，該值已指定時，僅刪除?動中描述了與該數(shù)值?致的輸出物理端?的流表項out_portflags1616標志。長度可變actions?動描述部分例如：如果要添加?條新流，command=0。兩個時間參數(shù)idle_timeout&hard_timeout：idle_timeout:如值為20，則某條流在20秒之內(nèi)沒有被匹配，則刪除。hard_timeout:如值為30，則30秒到達的時候，?定刪除這條流，即使他還活躍，能被匹配。priority:priority是流的優(yōu)先級的字段，字數(shù)越?則優(yōu)先級越?，存放在號數(shù)越?的table中。buffer_id:由交換機指定的buffei_id,準確的說是由dpid指定的。如果是?動下發(fā)的流，buffer_id應填-1，即0xffff,告訴交換機這個數(shù)據(jù)包并沒有緩存在隊列中。out_port:指定流的出?,有?些端?是很特殊的，如flood，local等。具體分類如下：ofp_port={0xff00:"OFPP_MAX",0xfff8:"OFPP_IN_PORT",0xfff9:"OFPP_TABLE",0xfffa:"OFPP_NORMAL",0xfffb:"OFPP_FLOOD",0xfffc:"OFPP_ALL",0xfffd:"OFPP_CONTROLLER",0xfffe:"OFPP_LOCAL",0xffff:"OFPP_NONE"}如果不清楚端?是多少，最好填寫flood，即0xfffb。flags：若?特殊?途，置為1，這樣可以讓交換機在刪除?條流時給交換機上報flow_removed信息。action：每?條流都必須指定action，若沒有指定，交換機會默認執(zhí)?drop操作。action的兩種類型?動。1.必備?動：Forward，Drop2.選擇?動：Set-Queue，Set-Field等。具體action類型如下：ofp_action_type={0:"OFPAT_OUTPUT",1:"OFPAT_SET_VLAN_VID",2:"OFPAT_SET_VLAN_PCP",3:"OFPAT_STRIP_VLAN",4:"OFPAT_SET_DL_SRC",5:"OFPAT_SET_DL_DST",6:"OFPAT_SET_NW_SRC",7:"OFPAT_SET_NW_DST",8:"OFPAT_SET_NW_TOS",9:"OFPAT_SET_TP_SRC",10:"OFPAT_SET_TP_DST",11:"OFPAT_ENQUEUE"}各字段及其含義：名稱內(nèi)容OFPAT_OUTPUT輸出?交換機物理端?設置802.1Q的VLANid設置802.1Q的PCP清除802.1Q的頭OFPAT_SET_VLAN_VIDOFPAT_SET_VLAN_PCPOFPAT_STRIP_VLANOFPAT_SET_DL_SRCOFPAT_SET_DL_DSTOFPAT_SET_NW_SRCOFPAT_SET_NW_DSTOFPAT_SET_NW_TOSOFPAT_SET_TP_SRCOFPAT_SET_TP_DSTOFPAT_ENQUEUE設置發(fā)送源以太?地址設置發(fā)送?標以太?地址設置發(fā)送源IPV4地址設置發(fā)送?標IPV4地址設置IPV4的TOS字段設置TCP/UDP的發(fā)送源端?號或ICMP類型\設置TCP/UDP的?標端?號或ICMP代碼輸出?隊列Flow-Removed消息如果flow-mod的flags置為1，則在該流表失效后會回復控制器OFPT_LFOW_REMOVED消息。結構如圖2-4所?：圖2-4.png作?：在流失效的時候回復控制器，并攜帶若?統(tǒng)計數(shù)據(jù)。classofp_flow_removed(Packet):name="OpenFlowflowremoved"fields_desc=[BitField("cookie",0,64),#在控制器中使?，與flow-mod消息數(shù)值相同。BitField("priority",0,16),#流表項的優(yōu)先級，與flow-mod相同。BitField("reason",0,8),#流表項刪除理由。ByteField("pad",None),#?于32位對齊。BitField("duration_sec",0,32),#流表項有效時間。BitField("duration_nsec",0,32),#流表項有效時間。BitField("idle_timeout",0,16),#idle超時時間。ByteField("pad",0),#?于64位對齊。BitField("packet_count",0,64),#與流表項匹配的數(shù)據(jù)包數(shù)。BitField("byte_count",0,64)，#匹配的數(shù)據(jù)包總字節(jié)數(shù)。]Error消息Error消息的作?是通知出現(xiàn)了某種錯誤，OpenFlow交換機和OpenFlow控制器都可以發(fā)送Error消息。錯誤消息類型：名稱（type）內(nèi)容OFPET_HELLO_FAILEDOFPET_BAD_REQUESTOFPET_BAD_ACTIONHello協(xié)議失敗?法解讀請求?動的描述中包含錯誤變更流表項時發(fā)?錯誤Port-Mod請求失敗隊列操作失敗OFPET_FLOW_MOD_FAILEDOFPET_PORT_MOD_FAILEDOFPET_QUEUE_OP_FAILED具體的type與其對應的相關代碼：ofp_hello_failed_code={0:"OFPHFC_INCOMPATIBLE",1:"OFPHFC_EPERM"}ofp_bad_request_code={0:"OFPBRC_BAD_VERSION",1:"OFPBRC_BAD_TYPE",2:"OFPBRC_BAD_STAT",3:"OFPBRC_BAD_VENDOR",4:"OFPBRC_BAD_SUBTYPE",5:"OFPBRC_EPERM",6:"OFPBRC_BAD_LEN",7:"OFPBRC_BUFFER_EMPTY",8:"OFPBRC_BUFFER_UNKNOWN"}ofp_bad_action_code={0:"OFPBAC_BAD_TYPE",1:"OFPBAC_BAD_LEN",2:"OFPBAC_BAD_VENDOR",3:"OFPBAC_BAD_VENDOR_TYPE",