接續前文，這次將說明Group Table的組成要素、Group種類、交換機與Controller溝通的方式，並介紹如何透過Controller來設定Group Table內容，以及在設定過程中非常重要的Liveness機制。
了解Group Table的操作訊息
知道OpenFlow Channel所傳送的訊息種類後，接著說明與Group Table相關的訊息長相。
這裡，就以程式的方式來呈現：
從中可以看出來，對於Group Table可實行的操作訊息分為新增、修改及刪除等三種，這些動作是指對Group Table新增、修改，或是刪除Group Entry。
要先了解的是，Group可以是包含零個或是多個Action Bucket。沒有Action Bucket的Group，當然就沒有辦法針對網路封包做任何的動作，因為沒有定義好的動作指令。而這樣的動作指令也可以簡單到只是單純地把網路封包直接轉發給其他的交換機。
這些動作指令事實上會需要額外的檢查，以確保這些動作指令是有效的。如果動作指令是無效的，或者不被支援，那麼交換機必須回傳一個ofp_error_msg資料，而裡面的值是OFPET_BAD_ACTION。
接下來，針對上述三種不同的Group Table操作訊息來做詳細介紹。
新增操作
新增Group Entry的操作指令為OFPGC_ADD。當新增某一個Group Entry到Group Table，如果這筆Group Entry在指定的Group Table已經存在，交換機收到指令時，就沒有辦法真的去執行這個操作，此時交換機必須回傳一個ofp_error_msg，而其內容為OFPET_GROUP_MOD_FAILED，以及OFPGMFC_GROUP_EXISTS錯誤訊息。
修改操作
若要針對指定Group Table的某一筆Group Entry做修改，則必須傳送OFPGC_MODIFY訊息。
其做法事實上是把原本已經存在的Group Entry先移除，然後再新增一筆修改過後的Group Entry放入到指定的Group Table之中。
在修改的過程中，可能會發生多種不同的錯誤情況，根據這些情況，交換機會發送多種不同的錯誤訊息，而無論哪種錯誤訊息被回傳，交換機一定會回傳一個一個ofp_error_msg錯誤訊息，內容為OFPET_GROUP_MOD_FAILED。
至於額外傳送的錯誤碼以及相關的情況為何，可參考表1的說明。
表1 額外傳送的錯誤碼及情況說明
最後一種錯誤OFPGMFC_WATCH_UNSUPPORTED，也可能發生於當指定了watch_port或watch_group到任何一個不支援Liveness的Group之中。
刪除操作
與刪除操作相關的指令是OFPGC_DELETE。發送刪除操作需求時，如果指定的Group並不存在於Group Table內，將沒有任何的錯誤訊息會回傳，也不會發生任何的動作。
如果存在的話，則會刪除相對應的Group，在動作清單中所有包含這個Group的Flow Entry也將被刪除。
當要刪除Group的時候，其實也不需要指定Group的類型，而也因為刪除這個動作並不像新增或是修改一樣會新增一筆新的Group到Group Table，所以這裡可能出現的錯誤訊息當然也少很多。如果想要一次刪除所有的Goup，可以在Group Value之中指定OFPG_ALL這個值。
某些交換機可以支援讓Group彼此之間串在一起，例如當Group要轉發給另外一個Group的時候，甚至於更複雜的設定環境。
如果交換機沒有支援這種設定時，就會回傳OFPGMFC_CHAINING_UNSUPPORTED錯誤碼。而交換機也必須去檢查當要把Group串在一起時是否會造成迴圈，如果對Group的操作形成迴圈，交換機就會回傳OFPGMFC_LOOP錯誤碼。
另外一個需要注意的情況是，若要刪除一個Group，可是這個Group可能還是有被其他的Groups所參考（Reference）的時候，就不能刪除這一個Group，必須回傳OFPGMFC_CHAINED_GROUP此一錯誤碼。
認識Liveness機制
最後來談談先前所提到的Liveness機制。稍早介紹過，Group有四種類型：All、Select、Indirect以及Fast Failover，主要是根據要如何執行內部的動作指令來做區分。
其中提到，如果是Fast Failover類型的Group，必須實作Liveness機制，用來決定要執行哪一個Action Bucket的內容。雖然其他種類的Group並不需要Liveness機制，但依然可以實作這樣的機制。假若沒有實作Liveness機制，Group的修改動作就會失敗。
基本上，這個機制與OpenFlow協定無關，管理人員必須寫程式來提供這個機制，然後決定一個埠（Port）的Live狀態，這個狀態可以透過設定OFPPS_LIVE這個Flag來完成，這樣的機制也許可以透過像是Spanning Tree或KeepAlive機制來完成。
如果OFPPS_LIVE這個值沒有被設定，或是有其他的Liveness機制認為這個埠是Offline，或者OFPPC_PORT_DOWN被設定，或是OFPPS_LINK_DOWN被設定起來的話，都必須將這個埠看成是非Live的狀態。
換做是Bucket，如果watch_port並不是OFPP_ANY而且這個埠是Live的情況，或是watch_group並不是OFPG_ANY而且這個Group是Live，那麼這個Bucket就被視為是Live。
最後，如果一個Group之中，有至少一個Bucket是Live，則這整個Group都算是Live。
結語
本文介紹了Group Table的組成要素、Group的種類，又說明了交換機如何與Controller做溝通，如何透過這個溝通的管道來管理Group Table中的內容。
接著說明在管理過程中有哪些錯誤碼可能會遇到，最後則是以Liveness機制做結尾，讓大家對於整個Group Table有一個完整的認知。
＜本文作者：胡凱智，目前在Solera Holdings Inc.擔任亞太區首席技術長，曾於美商Mozilla擔任全球技術專案總監，並在趨勢科技任職七年多，有兩年美國矽谷工作經驗，在美國專利局擁有軟體專利。讀者交流建議：https://www.facebook.com/khu.page＞