Openflow協(xié)議通信流程解讀

1、Openflow協(xié)議通信流程解讀前言接觸了這么久的SDN，Openflow協(xié)議前前后后也讀過好多遍，但是一直沒有時(shí)間總結(jié)一下自己的一些見解?，F(xiàn)在有時(shí)間了，就寫一寫自己對(duì)Openflow協(xié)議通信流程的一些理解。SDN中Switch和controller在SDN中很重要的兩個(gè)實(shí)體是Switch跟Controller。Controller在網(wǎng)絡(luò)中相當(dāng)于上帝，可以知道網(wǎng)絡(luò)中所有的消息，可以給交換機(jī)下發(fā)指令。Switch就是一個(gè)實(shí)現(xiàn)Controller指令的實(shí)體，只不過這個(gè)交換機(jī)跟傳統(tǒng)的交換機(jī)不一樣，他的轉(zhuǎn)發(fā)規(guī)則由流表指定，而流表由控制器發(fā)送。switch組成與傳統(tǒng)交換機(jī)的差異switch組成switc

2、h由一個(gè)Secure Channel和一個(gè)flow table組成，of1.3之后table變成多級(jí)流表，有256級(jí)。而of1.0中table只在table0中。· Secure Channel是與控制器通信的模塊，switch和controller之間的連接時(shí)通過socket連接實(shí)現(xiàn)。· Flow table里面存放這數(shù)據(jù)的轉(zhuǎn)發(fā)規(guī)則，是switch的交換轉(zhuǎn)發(fā)模塊。數(shù)據(jù)進(jìn)入switch之后，在table中尋找對(duì)應(yīng)的flow進(jìn)行匹配，并執(zhí)行相應(yīng)的action，若無匹配的flow則產(chǎn)生packet_in（后面有講）of中sw與傳統(tǒng)交換機(jī)的差異· 匹配層次高達(dá)4層，可以

3、匹配到端口，而傳統(tǒng)交換機(jī)只是2層的設(shè)備。· 運(yùn)行of協(xié)議，實(shí)現(xiàn)許多路由器的功能，比如組播。· 求補(bǔ)充?。ㄈ绻阒?，請(qǐng)告訴我，非常感謝?。﹐penflow的switch可以從以下方式獲得· 實(shí)體of交換機(jī)，目前市場(chǎng)上有一些廠商已經(jīng)制造出of交換機(jī)，但是普遍反映價(jià)格較貴！性能最好。· 在實(shí)體機(jī)上安裝OVS，OVS可以使計(jì)算機(jī)變成一個(gè)openflow交換機(jī)。性能相對(duì)穩(wěn)定。· 使用mininet模擬環(huán)境?？梢源罱ㄔS多交換機(jī)，任意拓?fù)?，搭建拓?fù)渚唧w教程本博客有一篇。性能依賴虛擬機(jī)的性能。controller組成控制器有許多種，不同的語言，如python

4、寫的pox,ryu，如java寫的floodlight等等。從功能層面controller分為以下幾個(gè)模塊：· 底層通信模塊：openflow中目前controller與switch之間使用的是socket連接，所以控制器底層的通信是socket。· openflow協(xié)議。socket收到的數(shù)據(jù)的處理規(guī)則需按照openflow協(xié)議去處理。· 上層應(yīng)用：根據(jù)openflow協(xié)議處理后的數(shù)據(jù)，開發(fā)上層應(yīng)用，比如pox中就l2_learning,l3_learning等應(yīng)用。更多的應(yīng)用需要用戶自己去開發(fā)。Openflow通信流程以下教程環(huán)境為：mininet+自編簡(jiǎn)單控

5、制器建立連接首先啟動(dòng)mininet，mininet會(huì)自行啟動(dòng)一個(gè)default拓?fù)?，你也可以自己建立你的拓?fù)?。sw建立完成之后，會(huì)像controllerIP:controllerport發(fā)送數(shù)據(jù)。controller啟動(dòng)之后，監(jiān)聽指定端口，默認(rèn)6633，但是好像以后的都改了，因?yàn)樵摱丝诒黄渌麉f(xié)議占用。3次握手之后，建立連接，這個(gè)是底層的通信，是整一套系統(tǒng)的基礎(chǔ)設(shè)施。OFPT_HELLO創(chuàng)建socket之后，sw跟controller會(huì)彼此發(fā)送hello數(shù)據(jù)包。· 目的：協(xié)議協(xié)商。· 內(nèi)容：本方支持的最高版本的協(xié)議· 成果：使用雙方都支持的最低版本協(xié)議。·

6、 成功：建立連接· 失?。篛FPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),終止連接。OFPT_ERROR說到OFPT_ERROR,我們不妨先了解一下。ofp_error_type = 0: "OFPET_HELLO_FAILED", 1: "OFPET_BAD_REQUEST", 2: "OFPET_BAD_ACTION", 3: "OFPET_FLOW_MOD_FAILED", 4: "OFPET_PORT_MOD_FAILED", 5: &q

7、uot;OFPET_QUEUE_OP_FAILED"錯(cuò)誤類型如上所示。對(duì)應(yīng)的type還會(huì)有對(duì)應(yīng)的code.所以報(bào)錯(cuò)的格式為：OFPT_ERRORTYPE: CODE:PAYLOAD具體的錯(cuò)誤信息。如 TYPE:0 CODE:0為：*OFPHFC_INCOMPATIBLE*具體對(duì)應(yīng)的關(guān)系，請(qǐng)自行查看OF協(xié)議。OFPT_ECHO· 分類：對(duì)稱信息 OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY· 作用：查詢連接狀態(tài)，確保通信通暢。當(dāng)沒有其他的數(shù)據(jù)包進(jìn)行交換時(shí)，controller會(huì)定期循環(huán)給sw發(fā)送OFPT_ECHO_REQUEST。OFPT_F

8、EATURES當(dāng)sw跟controller完成連接之后，控制器會(huì)向交換機(jī)下發(fā)OFPT_FEATYRES_REQUEST的數(shù)據(jù)包，目的是請(qǐng)求交換機(jī)的信息。· 發(fā)送時(shí)間：連接建立完成之后· 發(fā)送數(shù)據(jù)：OFPT_FEATURES_REQUEST· 對(duì)稱數(shù)據(jù)：OFPT_FEATURES_REPLY· 目的：獲取交換機(jī)的信息OFPT_FEATURES_REQUEST· TYPE=5· Without dataOFPT_FEATURES_REPLY· TYPE =6· 0:8為header· 8:32長(zhǎng)度24byte

9、為sw的features· 32:長(zhǎng)度與端口數(shù)成正比，存放port的信息。每一個(gè)port信息長(zhǎng)度為48byte。· class ofp_features_reply(Packet):· name = "OpenFlow Switch Features Reply"· fields_desc= BitFieldLenField('datapath_id', None, 64, length_of='varfield'),· BitFieldLenField('n_buffers'

10、, None, 32, length_of='varfield'),· XByteField("n_tables", 0),· X3BytesField("pad", 0),· #features· BitField("NOT DEFINED", 0, 24),· BitField("OFPC_ARP_MATCH_IP", 0, 1), #1<<7 Match IP address in ARP packets· BitFiel

11、d("OFPC_QUEUE_STATS", 0, 1), #1<<6 Queue statistics· BitField("OFPC_IP_STREAM", 0, 1), #1<<5 Can reassemble IP fragments· BitField("OFPC_RESERVED", 0, 1), #1<<4 Reserved, must be zero· BitField("OFPC_STP", 0, 1), #1<<3 80

12、2.1d spanning tree· BitField("OFPC_PORT_STATS", 0, 1), #1<<2 Port statistics· BitField("OFPC_TABLE_STATS", 0, 1), #1<<1 Table statistics· BitField("OFPC_FLOW_STATS", 0, 1), #1<<0 Flow statistics· BitFieldLenField('actions',

13、None, 32, length_of='varfield'),· bind_layers( ofp_header, ofp_features_reply, type=6 )以上的結(jié)構(gòu)是交換機(jī)的features,緊跟在后面的是端口的結(jié)構(gòu)：class ofp_phy_port(Packet): name = "OpenFlow Port" fields_desc= ShortEnumField("port_no", 0, ofp_port), MACField("hw_addr", "00:00:00

14、:00:00:00"), StrFixedLenField("port_name", None, length=16), BitField("not_defined", 0, 25), BitField("OFPPC_NO_PACKET_IN", 0, 1), BitField("OFPPC_NO_FWD", 0, 1), BitField("OFPPC_NO_FLOOD", 0, 1), BitField("OFPPC_NO_RECV_STP",0, 1), Bi

15、tField("OFPPC_NO_RECV", 0, 1), BitField("OFPPC_NO_STP", 0, 1), BitField("OFPPC_PORT_DOWN", 0, 1), #uint32_t for state BitField("else", 0, 31), BitField("OFPPS_LINK_DOWN", 0, 1), #uint32_t for Current features BitField("not_defined", 0, 20),

16、 BitField("OFPPF_PAUSE_ASYM", 0, 1), BitField("OFPPF_PAUSE", 0, 1), BitField("OFPPF_AUTONEG", 0, 1), BitField("OFPPF_FIBER", 0, 1), BitField("OFPPF_COPPER", 0, 1), BitField("OFPPF_10GB_FD", 0, 1), BitField("OFPPF_1GB_FD", 0, 1), B

17、itField("OFPPF_1GB_HD", 0, 1), BitField("OFPPF_100MB_FD", 0, 1), BitField("OFPPF_100MB_HD", 0, 1), BitField("OFPPF_10MB_FD", 0, 1), BitField("OFPPF_10MB_HD", 0, 1), #uint32_t for features being advised by the port BitField("advertised", 0,

18、32), #uint32_t for features supported by the port BitField("supported", 0, 32), #uint32_t for features advertised by peer BitField("peer", 0, 32)交換機(jī)和端口的配置信息在整一個(gè)通信過程起著至關(guān)的作用，因?yàn)樗嘘P(guān)于的操作都需要從features里面提取相關(guān)的信息，如dpid,port_no，等在整個(gè)通信過程中多次被用到的重要數(shù)據(jù)。所以，對(duì)這兩個(gè)數(shù)據(jù)結(jié)構(gòu)了然于心，對(duì)于研究openflow來說，至關(guān)重要。每一次交換機(jī)連

19、到控制器，都會(huì)收到控制器的features_request,當(dāng)sw將自己的features回復(fù)給控制器之后，控制器就對(duì)交換機(jī)有了一個(gè)全面的了解，從而為后面的控制提供的控制信息。OFPT_PACKET_IN在控制器獲取完交換機(jī)的特性之后，交換機(jī)開始處理數(shù)據(jù)。對(duì)于進(jìn)入交換機(jī)而沒有匹配流表，不知道如何操作的數(shù)據(jù)包，交換機(jī)會(huì)將其封裝在packet_in中發(fā)給controller。包含在packet_in中的數(shù)據(jù)可能是很多種類型，arp和icmp是最常見的類型。當(dāng)然產(chǎn)生packet_in的原因不止一種，產(chǎn)生packet_in的原因主要有一下兩種：· OFPR_NO_MATCH· OF

20、PR_ACTION無法匹配的數(shù)據(jù)包會(huì)產(chǎn)生packet_in,action也可以指定將數(shù)據(jù)包發(fā)給packet_in,也就是說我們可以利用這一點(diǎn)，將需要的數(shù)據(jù)包發(fā)給控制器。packet_in事件之后，一般會(huì)觸發(fā)兩類事件：· packet_out· flow_mod如果是廣播包，如arp，控制器一般會(huì)將其包裝起來，封裝成packet_out數(shù)據(jù)包，將其發(fā)給交換機(jī)，讓其flood,flood操作是將數(shù)據(jù)包往除去in_port以外的所有端口發(fā)送數(shù)據(jù)包。OFPT_PACKET_OUT很多人不是特別了解packet_out的作用。· 作用：通過控制器發(fā)送交換機(jī)希望發(fā)送的數(shù)據(jù)&#

21、183; 例子：arp在廣播的時(shí)候，在ofsw中不能直接將arp廣播，而是，將其封裝在packet_out里面，交換機(jī)泛洪的是packet_out。我個(gè)人觀點(diǎn)，這個(gè)數(shù)據(jù)包，是一個(gè)兼容性之的數(shù)據(jù)包，為了實(shí)現(xiàn)信令，不得不處理arp，但是arp又不能直接處理，所以將其封裝在packet_out,從而能夠在of的sw中傳播，從而在openflow里實(shí)現(xiàn)arp等IP網(wǎng)的功能。OFPT_FLOW_MODOFPT_FLOW_MOD是整一個(gè)Openflow協(xié)議中最重要的數(shù)據(jù)結(jié)構(gòu)，沒有之一。OFPT_FLOW_MOD由header+match+flow_mod+action組成。為了操作簡(jiǎn)單，以下的結(jié)構(gòu)是將wi

22、ldcards和match分開的形式，形成兩個(gè)結(jié)構(gòu)，在編程的時(shí)候能更方便一些。由于這個(gè)數(shù)據(jù)包很重要，所以，我將把這個(gè)數(shù)據(jù)包仔細(xì)拆分解讀。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, OFP

23、FW_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

24、.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_HEADERheader是所有數(shù)據(jù)包的報(bào)頭，有三個(gè)參數(shù)：· type:類型· length:整個(gè)數(shù)據(jù)包的長(zhǎng)度· xid：數(shù)據(jù)包的編號(hào)比如

25、ofp_flow_mod的type就是14，具體的哪一種數(shù)據(jù)的類型將在文章最后給出。length最基本長(zhǎng)度為72，每一個(gè)action長(zhǎng)度為8。所以長(zhǎng)度必定為8的倍數(shù)才是一個(gè)正確的數(shù)據(jù)長(zhǎng)度。WILDCARDS這是從match域提取出來的前32bit。在of1.0中這里的0，1意義跟我們平時(shí)接觸的如子網(wǎng)掩碼等意義相反，如OFPFW_NW_DST_MASK=0則表示全匹配目標(biāo)IP。如果為63，則表示不匹配IP。為什么拿這個(gè)舉例？原因就在于，他的長(zhǎng)度是6bit，最大是63，需要將數(shù)值轉(zhuǎn)變成對(duì)應(yīng)2進(jìn)制數(shù)值才是我們想要的匹配規(guī)則，且注意，1是忽略，0是匹配。如果wildcards全0，則表示由match精

26、確指定，即所有12元組都匹配。當(dāng)然高興的是，在1.3的時(shí)候，這個(gè)邏輯改成了正常的與邏輯。即1為使能匹配，0為默認(rèn)不匹配。MATCH這個(gè)數(shù)據(jù)結(jié)構(gòu)會(huì)出現(xiàn)在幾乎所有重要的數(shù)據(jù)包中，因?yàn)樗娴木褪强刂菩畔?。如有packet_in引發(fā)的下發(fā)流表，則match部分應(yīng)對(duì)應(yīng)填上對(duì)應(yīng)的數(shù)據(jù)，這樣下發(fā)的流表才是正確的。但是在下發(fā)的時(shí)候還需要注意許多細(xì)節(jié)，比如：· 并不是所有的數(shù)據(jù)包都有vlan_tag。如0×0800就是純IP，并沒有攜帶vlan_tag，所以填充式應(yīng)根據(jù)packet_in的具體情況填充。· 并不是所有的數(shù)據(jù)都有四層端口，所以四層的源端口，目的端口都不是任何時(shí)候都能由

27、packet_in去填充的。不去管就好了，默認(rèn)的會(huì)填充一個(gè)默認(rèn)值，匹配的時(shí)候不去匹配4層端口就沒有問題。FLOW_MOD這里面的信息也是至關(guān)重要的。class ofp_flow_mod(Packet): name = "OpenFlow Flow Modify" fields_desc= BitField("cookie", 0, 64), #Opaque controller-issued identifier ShortEnumField("command", 0, ofp_flow_mod_command), ShortFiel

28、d("idle_timeout", 60), ShortField("hard_timeout", 0), ShortField("priority", 0), IntField("buffer_id", 0), ShortField("out_port", 0), #flags are important, the 1<<0 bit is OFPFF_SEND_FLOW_REM, send OFPT_FLOW_REMOVED #1<<1 bit is OFPFF_CHE

29、CK_OVERLAP, checking if the entries' field overlaps(among same priority) #1<<2 bit is OFPFF_EMERG, used only switch disconnected with controller) ShortField("flags", 0)command里面的類型決定了flow_mod的操作是添加，修改還是刪除等。類型如下ofp_flow_mod_command = 0: "OFPFC_ADD", # New flow 1: "O

30、FPFC_MODIFY", # Modify all matching flows 2: "OFPFC_MODIFY_STRICT", # Modify entry strictly matching wildcards 3: "OFPFC_DELETE", # Delete all matching flows 4: "OFPFC_DELETE_STRICT" # Strictly match wildcards and priority例如：如果要添加一條新流，command=0。兩個(gè)時(shí)間參數(shù)idle_timeout &

31、amp; idle_timeout：· idle_timeout:如值為10，則某條流在10秒之內(nèi)沒有被匹配，則刪除，可以稱之為活躍時(shí)間吧。· hard_timeout:如值為30，則30秒到達(dá)的時(shí)候，一定刪除這條流，即使他還活躍，即被匹配。prioritypriority是流的優(yōu)先級(jí)的字段，字?jǐn)?shù)越大則優(yōu)先級(jí)越高，存放在號(hào)數(shù)越小的table中。buffer_id由交換機(jī)指定的buffei_id,準(zhǔn)確的說是由dpid指定的。如果是手動(dòng)下發(fā)的流，buffer_id應(yīng)填-1，即0xffff,告訴交換機(jī)這個(gè)數(shù)據(jù)包并沒有緩存在隊(duì)列中。out_port指定流的出口，但是這個(gè)出口并不是直

32、接指導(dǎo)流轉(zhuǎn)發(fā)的，至少我是這么覺得，指導(dǎo)流轉(zhuǎn)發(fā)的出口會(huì)在action里面添加，這個(gè)端口是為了在flow_removed的時(shí)候查詢，并返回控制器的作用。（求糾正?。┯幸恍┒丝谑呛芴厥獾模鏵lood，local等。具體分類如下：ofp_port = 0xff00: "OFPP_MAX", 0xfff8: "OFPP_IN_PORT", 0xfff9: "OFPP_TABLE", 0xfffa: "OFPP_NORMAL", 0xfffb: "OFPP_FLOOD", 0xfffc: "OF

33、PP_ALL", 0xfffd: "OFPP_CONTROLLER", 0xfffe: "OFPP_LOCAL", 0xffff: "OFPP_NONE"如果你不知道端口是多少，最好填flood,也就是0xfffb。flags在上面的注釋中也說得比較清楚了。如果沒有特殊用處，請(qǐng)將他置1，因?yàn)檫@樣能讓交換機(jī)在刪除一條流的時(shí)候給交換機(jī)上報(bào)flow_removed信息。ACTIONaction是openflow里面最重要的結(jié)構(gòu)。對(duì)，他也是最重要的。每一條流都必須指定必要的action,不然匹配上之后，沒有指定action，交換機(jī)會(huì)

34、默認(rèn)執(zhí)行drop操作。action有2種類型：· 必備行動(dòng): Forward and Drop· 選擇行動(dòng):FLOOD,NALMAL 等如添加output就是一個(gè)必須要添加的action.每一個(gè)action最好有一個(gè)action_header(),然后再接一個(gè)實(shí)體。如：ofp_action_header(type=0)/ofp_action_output(type =0, port =oxfffb,len =8)具體的action類型如下：ofp_action_type = 0: "OFPAT_OUTPUT", 1: "OFPAT_SET_VL

35、AN_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_

36、TP_DST", 11: "OFPAT_ENQUEUE" action不僅僅會(huì)出現(xiàn)在flow_mod中，也會(huì)出現(xiàn)在如stats_reply中。OFPT_BARRIER_REQUEST && REPLY這個(gè)數(shù)據(jù)包可以的作用很簡(jiǎn)單，交換機(jī)在收到OFPT_BARRIER_REQUEST的時(shí)候，會(huì)回復(fù)控制器一個(gè)OFPT_BARRIER_REPLY。我們默認(rèn)數(shù)據(jù)下發(fā)的順序不會(huì)在傳輸中發(fā)生變化，在進(jìn)入消息隊(duì)列之后處理也是按照FIFO進(jìn)行的，那么只要在flow_mod之后發(fā)送這個(gè)數(shù)據(jù)，當(dāng)收到reply之后，交換機(jī)默認(rèn)flow已經(jīng)寫成功。也許你會(huì)問他只是保證了fl

37、ow_mod命令執(zhí)行了，寫入的結(jié)果如何并沒有保證，如何確定確實(shí)寫入流表了呢？· 如果非邏輯錯(cuò)誤，那么交換機(jī)在處理flow_mod的時(shí)候會(huì)報(bào)錯(cuò)。所以我們會(huì)知道寫入結(jié)果。· 如果是邏輯錯(cuò)誤，那么會(huì)寫進(jìn)去，但是邏輯錯(cuò)誤應(yīng)該是人的問題，所以barrier還是有他的功能的。OFPT_FLOW_REMOVED如果flow_mod的flags填成1，則該流在失效之后會(huì)回復(fù)控制器一條OFPT_FLOW_REMOVED信息。· 結(jié)構(gòu)：header()/wildcards()/match()/flow_removed()· 作用：在流失效的時(shí)候回復(fù)控制器，并攜帶若干統(tǒng)計(jì)數(shù)據(jù)

38、。· class ofp_flow_removed(Packet):· name = "Openflow flow removed"· fields_desc = BitField("cookie", 0, 64),· BitField("priority", 0,16),· BitField("reason", 0, 8),· ByteField("pad", None),· BitField("duration_

39、sec", 0, 32),· BitField("duration_nsec", 0, 32),· BitField("idle_timeout", 0, 16),· ByteField("pad", 0),· ByteField("pad", 0),· BitField("packet_count", 0, 64),· BitField("byte_count", 0, 64) 其實(shí)的duration_s

40、ec是流存在的時(shí)間，單位為秒，duration_nsec單位為納秒。OFPT_STATS_REQUEST && REPLY以上的數(shù)據(jù)都是通信過程中必須的部分。還有一些數(shù)據(jù)包是為了某些目的而設(shè)計(jì)的，如OFPT_STATS_REQUEST && REPLY可以獲得統(tǒng)計(jì)信息，我們可以利用統(tǒng)計(jì)信息做的事情就太多了。如：負(fù)載平衡， 流量監(jiān)控等基于流量的操作。OFPT_STATS_REQUESTOFPT_STATS_REQUEST類型有很多，回復(fù)的類型也很多。class ofp_stats_request(Packet): name = "OpenFlow Sta

41、ts Request" fields_desc= ShortEnumField("type", 0, ofp_stats_types), ShortField("flag", 0)Type· 0:請(qǐng)求交換機(jī)版本信息，制造商家等信息。· 1:單流請(qǐng)求信息· 2:多流請(qǐng)求信息· 3:流表請(qǐng)求信息· 4:端口信息請(qǐng)求· 5:隊(duì)列請(qǐng)求信息· 6:vendor請(qǐng)求信息，有時(shí)候沒有定義。· msg = 0: of.ofp_header(type = 16, length = 1

42、2)/of.ofp_stats_request(type = 0), #Type of OFPST_DESC (0) · 1: of.ofp_header(type = 16, length = 56)/of.ofp_stats_request(type =1)/ofp_flow_wildcards/ofp_match/of.ofp_flow_stats_request(out_port = ofp_flow_mod.out_port), #flow stats· 2: of.ofp_header(type = 16, length =56)/of.ofp_stats_re

43、quest(type = 2)/ofp_flow_wildcards/of.ofp_match/of.ofp_aggregate_stats_request(), # aggregate stats request· 3: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 3), #Type of OFPST_TABLE (0) · 4: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type = 4)/of.ofp_por

44、t_stats_request(port_no = port), # port stats request · 5: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type =5)/of.ofp_queue_stats_request(), #queue request· 6: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 0xffff) #vendor request OFPT_STATS_REPLY每一種請(qǐng)求信息都會(huì)

45、對(duì)應(yīng)一種回復(fù)信息。我們只介紹最重要的flow_stats_reply。· 結(jié)構(gòu)：header(type=17)/reply_header()/flow_stats/wildcards/match/ flow_stats_data· 作用：攜帶流的統(tǒng)計(jì)信息，如通過的數(shù)據(jù)包個(gè)數(shù)，字節(jié)數(shù)。ofp_flow_stats(body4:8)里面會(huì)有的table_id字段表明該流存放在哪一個(gè)流表里。flow_stats_data里面有packet_count和byte_count是最有價(jià)值的字段，流量統(tǒng)計(jì)就是由這兩個(gè)字段提供的信息。如想統(tǒng)計(jì)某條流的速率：前后兩個(gè)reply的字節(jié)數(shù)相減除以

46、duration_time只差就可以求得速率由速率我們可以做很多基于流量的app，如流量監(jiān)控，負(fù)載均衡等等。值得注意的是，在這些數(shù)據(jù)之后，其實(shí)還有一些action,但是目前我還沒有查看這些action到底是干什么用的。后續(xù)寫到這里，我使用到的數(shù)據(jù)包都寫了一遍，其他的報(bào)文其實(shí)道理也是一樣的。如OFPT_GET_CONFIG_REQUEST和REPLY，道理應(yīng)該和stats一樣，只是數(shù)據(jù)結(jié)構(gòu)不一樣罷了。不再多說。最后把我們用的一些比較多的信息帖出來讓大家更好的學(xué)習(xí)。ERROR在調(diào)試的過程中遇到錯(cuò)誤是再所難免的，前面也提到了error的結(jié)構(gòu)。這里就貼一下type跟code吧。Typeofp_erro

47、r_type = 0: "OFPET_HELLO_FAILED", 1: "OFPET_BAD_REQUEST", 2: "OFPET_BAD_ACTION", 3: "OFPET_FLOW_MOD_FAILED", 4: "OFPET_PORT_MOD_FAILED", 5: "OFPET_QUEUE_OP_FAILED"Code：ofp_hello_failed_code = 0: "OFPHFC_INCOMPATIBLE", 1: "OFP

48、HFC_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"

49、, 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", 4: "OFPBAC_BAD_OUT_PORT", 6: "OFPBAC_BAD_ARGUMENT", 7: "OFPBAC_EPERM", #pe

50、rmissions error 8: "OFPBAC_TOOMANY", 9: "OFPBAC_BAD_QUEUE"ofp_flow_mod_failed_code = 0: "OFPFMFC_ALL_TABLES_FULL", 1: "OFPFMFC_OVERLAP", 2: "OFPFMFC_EPERM", 3: "OFPFMFC_BAD_EMERG_TIMEOUT", 4: "OFPFMFC_BAD_COMMAND", 5: "OFPFMF

51、C_UNSUPPORT"ofp_port_mod_failed_code = 0: "OFPPMFC_BAD_PORT", 1: "OFPPFMC_BAD_HW_ADDR"ofp_queue_op_failed_code = 0: "OFPQOFC_BAD_PORT", 1: "OFPQOFC_BAD_QUEUE"第二章 理論基礎(chǔ)2.1軟件定義網(wǎng)絡(luò)SDN軟件定義網(wǎng)絡(luò)（英語：Software-defined networking，縮寫為SDN），一種網(wǎng)絡(luò)虛擬化（Network virtualization）

52、技術(shù)，由美國(guó)史丹佛大學(xué)Clean State提出。利用OpenFlow協(xié)定，把路由器的控制平面（control plane）從數(shù)據(jù)平面（data plane）中分離出來，以軟件方式實(shí)做。這個(gè)架構(gòu)可以讓網(wǎng)絡(luò)管理員，在不更動(dòng)硬件裝置的前提下，以中央控制方式，用程式重新規(guī)劃網(wǎng)絡(luò)，為控制網(wǎng)絡(luò)流量提供了新的方法，也提供了核心網(wǎng)絡(luò)及應(yīng)用創(chuàng)新的良好平臺(tái)。2.2 openflow網(wǎng)絡(luò)架構(gòu)OpenFlow網(wǎng)絡(luò)由OpenFlow交換機(jī)、FlowVisor和Controller三部分組成。OpenFlow交換機(jī)進(jìn)行數(shù)據(jù)層的轉(zhuǎn)發(fā)；FlowVisor對(duì)網(wǎng)絡(luò)進(jìn)行虛擬化；Controller對(duì)網(wǎng)絡(luò)進(jìn)行集中控制，實(shí)現(xiàn)控制層的功能。如下圖所示：2.2.1 openflow交換機(jī)OpenFlow交換機(jī)由流表、安全通