【OpenEvent 事件框架與框架中事件實(shí)例的實(shí)現(xiàn)綜述4700字】

OpenEvent事件框架與框架中事件實(shí)例的實(shí)現(xiàn)綜述目錄TOC\o"1-2"\h\u201891.1通信協(xié)議 1105621.1.1事件請求 1281181.1.2事件請求回復(fù) 2241941.2控制器端的實(shí)現(xiàn) 2256551.3交換機(jī)端的實(shí)現(xiàn) 31.1通信協(xié)議OpenEvent事件框架定義了一系列的OpenFlow消息，用于控制器與交換機(jī)之間對事件請求、事件請求回復(fù)和事件上報(bào)。所有的消息均屬于OpenFlow自定義類型消息。這一類消息是預(yù)留給設(shè)備制造商或者其他使用者實(shí)現(xiàn)自定義OpenFlow擴(kuò)展的預(yù)留接口。OpenFlow自定義類型消息需要包含制造商或擴(kuò)展開發(fā)者的32位使用者ID。子類型部分表示廠商或開發(fā)者對屬于同一使用者ID下各類型消息的分類。OpenFlow對自定義類型消息內(nèi)容部分的格式，以及控制器與交換機(jī)對此類消息的處理方式完全沒有規(guī)定，可以自主擴(kuò)展。OpenEvent中的消息均用使用者ID0xEBCC3118來區(qū)分。該框架中包含三大類消息:事件請求、事件請求回復(fù)、事件報(bào)告。這三大類消息用子類型來區(qū)分。事件請求用于控制器對交換機(jī)上的事件進(jìn)行操作；事件請求回復(fù)用于交換機(jī)向控制器回復(fù)事件請求的執(zhí)行結(jié)果；事件報(bào)告用于交換機(jī)在某一事件發(fā)生時(shí)，向控制器報(bào)告該事件的發(fā)生以及該事件中指定的統(tǒng)計(jì)數(shù)據(jù)。1.1.1事件請求事件請求消息由控制器向交換機(jī)發(fā)出，用于描述控制器對交換機(jī)上的事件的添加、刪除或者修改配置的請求。事件請求消息的子類型為0?！爸芷谛浴?PERIODIC)標(biāo)志用于指示該事件是否可以重復(fù)被觸發(fā)。當(dāng)該標(biāo)志被設(shè)為1時(shí)，該事件具有周期性，每當(dāng)事件的觸發(fā)條件被滿足時(shí)，該事件都會被觸發(fā)，并上報(bào)控制器;設(shè)為2時(shí)，該事件為一次性事件，僅在第一次滿足觸發(fā)條件時(shí)被觸發(fā)。事件ID為該事件在交換機(jī)中的唯一標(biāo)識符。事件類型表示該事件所屬的類型，為目前已經(jīng)定義和實(shí)現(xiàn)的兩類事件指定了事件類型的值，其他的值可以供將來定義的事件類型使用。目前，事件請求分為三種類型，由請求類型域的值來指定。這三種請求類型為:添加事件請求、修改事件請求、刪除事件請求。添加事件請求使用請求類型0?？刂破魍ㄟ^向交換機(jī)發(fā)送添加事件請求來要求交換機(jī)安裝并監(jiān)測一個(gè)新的事件。在添加事件請求中，事件ID總是被設(shè)為0,以表示這個(gè)事件的ID還沒有被確定。交換機(jī)應(yīng)當(dāng)為該新安裝的事件指定一個(gè)非0、在該交換機(jī)中唯一的事件ID，并在回復(fù)中上報(bào)。其他必要的對該事件的配置在請求的消息體部分指定，消息體部分的格式與解釋方式由各類具體的事件來規(guī)定。修改事件請求的請求類型為1。控制器通過向交換機(jī)發(fā)送修改事件請求來修改一個(gè)交換機(jī)上已經(jīng)存在的事件的配置。在請求中，控制器必須在事件ID和類型部分給出所要修改的事件的正確的ID和類型。如果在交換機(jī)中，事件ID所對應(yīng)的事件不存在或者事件類型與控制器給出的不符，交換機(jī)將拒絕執(zhí)行該請求并在回復(fù)中報(bào)告錯(cuò)誤。與添加事件請求類似，修改事件請求的消息體部分由具體的事件類型指定，一般應(yīng)包含修改后的事件配置。刪除事件請求使用的請求類型為2。刪除事件請求用于控制器要求交換機(jī)刪除一個(gè)已經(jīng)安裝的事件。與修改事件請求類似，刪除事件請求需要正確地給出被刪除的事件的ID和事件類型。如果與ID對應(yīng)的事件不存在或者類型不符，該請求也不會被執(zhí)行，并且交換機(jī)將給出出錯(cuò)信息。刪除事件請求的消息體為空。1.1.2事件請求回復(fù)事件請求回復(fù)消息由交換機(jī)向控制器發(fā)出，用于回復(fù)控制器發(fā)出的事件請求。事件請求回復(fù)消息與它所回復(fù)的事件請求具有相同的OpenFlow事務(wù)ID。事件請求回復(fù)消息的子類型為1，事件請求回復(fù)消息應(yīng)當(dāng)包含交換機(jī)執(zhí)行其所回復(fù)的事件請求的執(zhí)行結(jié)果。事件類型部分應(yīng)當(dāng)與所回復(fù)的事件請求中指定的事件類型相同。對于事件ID部分，若所回復(fù)的事件請求是添加事件，那么事件請求中的事件ID為0，交換機(jī)成功添加事件后，應(yīng)當(dāng)將生成的事件ID填入事件ID部分。若事件請求中給出的事件ID不為0，而請求執(zhí)行成功，那么回復(fù)中的事件ID應(yīng)當(dāng)與請求中的相同。如果請求執(zhí)行失敗，事件ID應(yīng)當(dāng)被設(shè)為特殊值EVENT_ID_ERROR=0xFFFFFFF0以表示在執(zhí)行事件請求時(shí)發(fā)生了錯(cuò)誤。消息體部分由具體的事件類型指定，也可以為空。1.2控制器端的實(shí)現(xiàn)在Ryu控制器提供的框架下實(shí)現(xiàn)了OpenEvent的控制器端。Ryu控制器是一個(gè)用Python語言實(shí)現(xiàn)的開源OpenFlow控制器，它提供了一個(gè)基本的OpenFlow消息處理框架與大量基于該框架的應(yīng)用。Ryu的整體架構(gòu)采用事件-處理者模型。Ryu控制器運(yùn)行時(shí)，最基本的OpenFlow消息處理模塊以及用戶指定的應(yīng)用將會運(yùn)行。Ryu控制器中的每個(gè)應(yīng)用都包含若干個(gè)事件處理的數(shù)，對某類事件進(jìn)行處理。應(yīng)用也可以產(chǎn)生各種類型的事件，并發(fā)送給其他應(yīng)用。一個(gè)事件會被運(yùn)行中的所有對該類事件進(jìn)行處理的應(yīng)用處理。OpenFlow處理模塊是運(yùn)行Ryu控制器時(shí)必然會運(yùn)行的應(yīng)用，該應(yīng)用負(fù)責(zé)接收OpenFlow消息并根據(jù)OpenFlow協(xié)議解碼這些消息，并產(chǎn)生相應(yīng)的事件，同時(shí)負(fù)責(zé)編碼并發(fā)送控制器向交換機(jī)發(fā)送的OpenFlow消息。OpenEvent的控制器端實(shí)現(xiàn)為Ryu框架下的一個(gè)應(yīng)用，負(fù)責(zé)處理OpenEvent框架與事件相關(guān)的OpenFlow消息，包括編碼并發(fā)送事件請求和接收并解碼事件請求回復(fù)與事件報(bào)告，并產(chǎn)生事件以通知其他應(yīng)用兩部分。為實(shí)現(xiàn)接收并解碼的功能，該應(yīng)用注冊了個(gè)外理收到OnenFlow自定義類型消息事件的函數(shù)，該函數(shù)檢查收到的自定義類型消息的ExperimenterID是否是我們指定的0xEBCC3118，如果符合，則進(jìn)行進(jìn)一步的解碼;如果不符合，則處理到此為止。進(jìn)一步的解碼中，該函數(shù)根據(jù)消息的子類型與消息中指定的事件類型進(jìn)一步調(diào)用各類具體的消息的解碼函數(shù)。對于事件請求回復(fù)，解碼函數(shù)從消息中提取出事件類型、事件狀態(tài)、事件ID以及消息體，并產(chǎn)生一個(gè)“收到事件請求回復(fù)”的事件，通知其他可能需要處理這個(gè)消息的應(yīng)用。對于事件報(bào)告，解碼函數(shù)從消息中提取出事件ID、事件類型，以及該事件類型規(guī)定的各種交換機(jī)的統(tǒng)計(jì)數(shù)據(jù)。對于端口統(tǒng)計(jì)事件，統(tǒng)計(jì)數(shù)據(jù)包括該端口在指定的時(shí)間間隔內(nèi)發(fā)送與接收的數(shù)據(jù)包數(shù)量與字節(jié)數(shù)，以及該端口發(fā)送和接收的總數(shù)據(jù)包數(shù)量和字節(jié)數(shù);對于流表項(xiàng)統(tǒng)計(jì)事件，上報(bào)的統(tǒng)計(jì)數(shù)據(jù)包括滿足觸發(fā)條件的所有流表項(xiàng)分別的存在時(shí)長、在指定時(shí)間間隔內(nèi)匹配的數(shù)據(jù)包數(shù)量和字節(jié)數(shù)、流表項(xiàng)存在期間匹配的數(shù)據(jù)包總數(shù)和字節(jié)總數(shù)等。解碼函數(shù)提取出事件ID、事件類型和統(tǒng)計(jì)數(shù)據(jù)之后，產(chǎn)生“收到事件報(bào)告”的事件，發(fā)送給可能需要處理這一事件報(bào)告的其他應(yīng)用。對于編碼并發(fā)送部分，該應(yīng)用提供接口讓其他的應(yīng)用給定事件請求的類型、事件類型、事件ID以及消息體，對這些信息編碼成為可以通過OpenFlow連接發(fā)送的消息。1.3交換機(jī)端的實(shí)現(xiàn)OpenEvent的交換機(jī)端的功能除了對于事件相關(guān)的各種OpenFlow消息的編碼與解碼之外，還包括對自身已安裝的事件的維護(hù)、監(jiān)測和上報(bào)。為實(shí)現(xiàn)OpenEvent的交換機(jī)端，對OpenvSwitch”的多個(gè)模塊做了改動(dòng)，以實(shí)現(xiàn)OpenEvent所需要的功能。OpenvSwitch解碼OpenFlow消息時(shí)首先根據(jù)其頭部的類型這一屬性查找所屬類型，再根據(jù)消息體的頭部一些指明細(xì)分類型的屬性查找到細(xì)分類型，再調(diào)用各細(xì)分類型的解碼函數(shù)。編碼OpenFlow消息時(shí)，OpenvSwitch也根據(jù)消息所屬的細(xì)分類型調(diào)用對應(yīng)的編碼函數(shù)。對于自定義類型消息，OpenvSwitch將具有不同使用者ID與或同一使用者ID，但子類型不同的消息視為不同細(xì)分類型，對于每一類細(xì)分類型的消息，需要在OpenvSwitch中注冊，并指明編碼與解碼的函數(shù)。為了讓OpenEven的消息能夠正確地在OpenSwitch中被編碼和解碼，為OpenEvent的三類消息:事件請求、事件請求回復(fù)、事件報(bào)告注冊了三種細(xì)分類型，以及相應(yīng)的編碼與解碼函數(shù)。對于事件請求，OpenvSwitch收到控制器發(fā)來的OpenEvent事件請求后，首先根據(jù)消息的頭部調(diào)用對應(yīng)的事件請求的解碼函數(shù)。該解碼函數(shù)繼續(xù)讀取事件請求的消息體部分，根據(jù)請求的類型與請求的事件類型進(jìn)一步調(diào)用針對各類具體事件的解碼函數(shù)，完成對事件請求的解碼之后，根據(jù)請求的內(nèi)容調(diào)用請求處理模塊中處理相應(yīng)請求的功能。對于事件請求回復(fù)，實(shí)現(xiàn)了對事件請求回復(fù)消息的編碼函數(shù)，當(dāng)請求處理模塊完成了對事件請求的處理之后，調(diào)用對應(yīng)的編碼函數(shù)。該編碼函數(shù)讀取請求處理的結(jié)果、對應(yīng)請求的事務(wù)ID、請求的事件類型與事件ID以及其他必要的信息編碼成事件請求回復(fù)消息，發(fā)送給控制器。對于事件報(bào)告，事件被觸發(fā)時(shí)，事件監(jiān)測與上報(bào)模塊首先監(jiān)測到，并調(diào)用被觸發(fā)事件對應(yīng)的編碼事件報(bào)告消息體的編碼函數(shù)。針對目前已經(jīng)定義的端口統(tǒng)計(jì)事件與流統(tǒng)計(jì)事件定義并實(shí)現(xiàn)了對應(yīng)的編碼函數(shù)。然后，編碼與解碼模塊將消息體與OpenFlow頭部一同編碼成完整的事件報(bào)告，發(fā)送給控制器。OpenSwitch中，每一臺交換機(jī)中已安裝的事件由一個(gè)列表維護(hù)，每一個(gè)事件在列表中有一條對應(yīng)的記錄，該記錄包含其事件類型、事件ID、安裝時(shí)間、上次觸發(fā)時(shí)間、已被觸發(fā)的次數(shù)，以及由于事件類型不同而具有不同結(jié)構(gòu)的事件配置。請求處理模塊接收到添加事件的請求后，首先根據(jù)控制器對該事件的配置構(gòu)建一條新的事件記錄，如果該事件合法，可以成功添加，請求處理模塊為該事件生成一個(gè)新的事件ID，插入到事件列表中，并返回添加成功的結(jié)果，讓編碼與解碼模塊去回復(fù)給控制器;如果添加失敗(例如，端口統(tǒng)計(jì)事件中指定了不存在的端口編號)，請求處理模塊返回相應(yīng)的錯(cuò)誤信息，由編碼與解碼模塊在對請求的回復(fù)中報(bào)告這一錯(cuò)誤信息。對于修改事件請求，請求處理模塊首先檢查控制器給定的事件類型與事件ID所對應(yīng)的事件在列表中是否存在。如果事件ID對應(yīng)的事件在列表中不存在，請求處理模塊返回“事件不存在”錯(cuò)誤;如果事件ID對應(yīng)的事件在列表中存在，但其事件類型與控制器給定的事件類型不相同，請求處理模塊返回“事件類型錯(cuò)誤”的錯(cuò)誤信息。然后，請求處理模塊判斷控制器對該事件給出的修改后配置是否合法，如果合法，則修改事件列表中的對應(yīng)記錄，將它的配置改為控制器指定的新配置，并返回修改成功的結(jié)果;若控制器給定的修改后配置不合法，則請求處理模塊返回相應(yīng)的錯(cuò)誤信息，并且事件配置保持不變。對于刪除事件請求，處理的原則與方法與修改事件請求類似。OpenvSwitch中，一臺交換機(jī)可以分為待機(jī)和喚醒兩個(gè)狀態(tài)，當(dāng)交換機(jī)待機(jī)時(shí)，它運(yùn)行ofproto_wait函數(shù)等待被喚醒?？赡艿膯拘言虬ㄊ盏絆penFlow消息內(nèi)核模塊部分調(diào)用了一個(gè)upcall事先設(shè)定的定時(shí)器超時(shí)等。當(dāng)交換機(jī)被喚醒時(shí)，運(yùn)行ofproto_run函數(shù)來調(diào)用檢查各個(gè)模塊是否有需要處理的請求和事件。為了在OpenvSwitch上實(shí)現(xiàn)對事件的檢查和上報(bào)，在交換機(jī)的待機(jī)狀態(tài)下添加了eventwait函數(shù)以在應(yīng)當(dāng)檢查事件是否發(fā)生時(shí)喚醒交換機(jī)，以及ofproto_eventrun函數(shù)以遍歷事件列表，查看每一個(gè)事件是否應(yīng)當(dāng)被檢查。對于應(yīng)當(dāng)檢查的事件，交換機(jī)對事件的類型調(diào)用相應(yīng)的檢查函數(shù)，讀取事件中規(guī)定的統(tǒng)計(jì)數(shù)據(jù)并檢查是否達(dá)到或超過了規(guī)定闕值，滿足了觸發(fā)條件。對于滿足了觸發(fā)條件的事件，對事件報(bào)告的編碼函數(shù)將被調(diào)用。在交換機(jī)中，根據(jù)檢查事件是否發(fā)生的時(shí)機(jī)，將事件分為計(jì)數(shù)器觸發(fā)與定時(shí)器觸發(fā)兩類。計(jì)數(shù)器觸發(fā)的事件將在交換機(jī)中設(shè)定一個(gè)計(jì)數(shù)器，當(dāng)此計(jì)數(shù)器的計(jì)數(shù)值達(dá)到一定極限時(shí)，交換機(jī)將被喚醒，并檢查對應(yīng)的事件是否滿足了觸發(fā)條件。定時(shí)器觸發(fā)的事件將在交換機(jī)中設(shè)定一個(gè)定時(shí)器，當(dāng)定時(shí)器達(dá)到其超時(shí)時(shí)間時(shí)，交換機(jī)被喚醒，并檢查對應(yīng)的事件是否被觸發(fā)。檢查完成后，無論該事件是否被觸發(fā)，若該事件依然存在，計(jì)數(shù)器或定時(shí)器會復(fù)位，以等待下一次檢查。當(dāng)一個(gè)事件被刪除時(shí)，其對應(yīng)的計(jì)數(shù)器或定時(shí)器也被刪除。目前定義的端口統(tǒng)計(jì)事件與流統(tǒng)計(jì)事件均為定時(shí)器觸發(fā)。eventwait函數(shù)負(fù)責(zé)等待事件對應(yīng)的計(jì)數(shù)器的計(jì)數(shù)值到達(dá)極限時(shí)或定時(shí)器到達(dá)超時(shí)時(shí)間時(shí)喚醒交換機(jī)，讓交換機(jī)調(diào)用ofprotoeventrun函數(shù)ofprotoeventrun函數(shù)在運(yùn)行時(shí)，對事件列表進(jìn)行遍歷，檢查每一個(gè)事件的計(jì)數(shù)器是否到達(dá)極限值或者定時(shí)器是否超時(shí)。對于計(jì)數(shù)器到達(dá)極限值或定時(shí)器超時(shí)的事件，ofproto_eventrun將對該事件調(diào)