[[134417]]

這里，所謂OpenFlow網絡指的是相互連接的一組OpenFlow交換機的集合，并且這些交換機全部置于一個OpenFlow Controller或一個OpenFlow Controller的集群的管理之下。OpenFlow網絡的路由服務指的是單純地將一個數據包(Packet)從一個主機(Host)送到另一個主機，而不是三層IP路由協議1:1的實現。而主機也即是路由的目的地，可以是物理服務器或虛擬機(VM, Virtual Machine)。按照SDN的數據平面和控制平面相分離的模式和集中式管理的系統結構，OpenFlow網絡的路由完全是由OpenFlow Controller根據用戶的路由策略(Policy)生成并安裝到每個OpenFlow交換機的Flow Table和Group Table的Flow Entry和Group Entry的集合來定義的。因此，本文假設讀者朋友對OpenFlow交換機和OpenFlow Controller的基本概念有所了解，可參考ONF(Open Network Foundation)給出的“OpenFlow Switch Specification”相關章節。本文的討論也以此文獻給出的定義作為基礎。

總體思路

主機和OpenFlow網絡的連接方式直接影響OpenFlow網絡的路由設置，本文的討論包括三種最一般的情況：第一，主機和OpenFlow網絡的交換機的端口直接相連，這是最簡單的情況;第二，主機通過二層網絡接入OpenFlow網絡;第三，主機途徑多個IP子網最終通過路由器和OpenFlow網絡相連，主機接入的網絡以及中間經過的網絡都是傳統的IP網絡，使用傳統的路由協議，如OSPF或BGP。為了敘述的方便，第一種連接方式和第二種連接方式下的主機看做OpenFlow網絡的內部主機，而第三種連接方式下的主機看做OpenFlow網絡的外部主機。所謂“外部”，這是因為OpenFlow網絡無法直接“感知”到主機的存在。如圖1所示。主機A與邊緣交換機(Edge Switch)ES1的端口3連接(第一種方式)，主機B通過二層鏈路網絡(1.1.1.0/24)和邊緣交換機ES2的端口2連接(第二種方式)，主機 C連入外部的IP網絡(3.3.3.0/24)，路由器R是OpenFlow內部主機和外部主機通信的中介(第三種方式)，和邊緣交換機ES3的端口2連接。

實現OpenFlow路由服務總的思路是：獲取主機的信息及其接入OpenFlow網絡的信息，計算主機之間的路徑，對于路徑上的每個交換機,通過下發的OpenFlow消息，改變它的Flow Table和Group Table來定義其轉發行為，最終實現主機到主機的路由和通信。這些基本上都是OpenFlow Controller或在它之上的網絡應用的功能。下文的討論將不加區分的統統視為OpenFlow Controller的功能。

主機和接入

為了實現主機之間的路由與通信，OpenFlow Controller必須首先獲取主機的相關信息。對于OpenFlow網絡的內部主機，需要獲取的信息包括：主機的IP地址，接入OpenFlow網絡的邊緣交換機及端口，以及主機的MAC地址。除了人工靜態配置之外，網絡的Orchestration系統可提供主機的IP地址和接入到OpenFlow 網絡的交換機及其端口，網絡的Orchestration系統管理服務器和虛擬機在網絡上的部署。比如，在云計算的數據中心，網絡管理員可以通過 OpenStack這樣的Orchestration系統為客戶定制IP子網。這樣，IP子網中每個主機的IP地址和相連接的交換機及其端口的數據通過 OpenStack的插件傳遞給Controller。而主機的MAC地址就需借助于ARP來動態獲取。例如，在圖1中，假設有一個發往主機A的數據包，但不知道主機A的MAC地址。此時，Controller可通過packet_out消息令邊緣交換機ES1向端口3發送一個ARP請求，交換機ES1接收到主機A的回復報文后，因為它的Flow Table中沒有和ARP報文匹配的Flow Entry，所以，缺省地，ES1將這個ARP回復報文打包成packet_in消息，發送給OpenFlow Controller。OpenFlow Controller解析這個報文，即可得到主機A的MAC地址。

對于OpenFlow網絡的外部主機，OpenFlow Controller必須知道：和OpenFlow網絡直接相連的路由器的IP地址和MAC地址，連接路由器的OpenFlow網絡的邊緣交換機和端口，外部主機所在子網的IP地址(Prefix)和掩碼。路由器的IP地址和MAC地址，以及接入OpenFlow網絡的邊緣交換機和端口可按照上文描述的方式得到。而獲取外部主機的IP子網的地址和掩碼的功能則是由虛擬路由器(Virtual Router)來完成的。如圖1所示，主機C所在的子網的IP地址和掩碼(3.3.3.0/24)經過傳統的分布式IP路由系統最終傳遞給路由器R。通過 In Band或Out Of Band的方式，R和虛擬路由器事先建立了會話，如BGP會話，并交換路由可達信息。于是，虛擬路由器得到3.3.3.0/24的可達信息后，最終遞交給 OpenFlow Controller。有一些開源的程序可用來實現虛擬路由器，如Xorp、Quagga、ExaBGP等。一般地，虛擬路由器和外部的路由器的會話使用 BGP協議。關于虛擬路由器的細節不是本文討論的重點。

拓撲和路徑

控制平面和數據平面的分離，形成以OpenFlow Controller為中心的集中的控制平臺。OpenFlow網絡中所有的交換機都在OpenFlow Controller的監管之下，于是，OpenFlow Controller就有機會掌握全局的網絡拓撲視圖以及每個交換機的狀態。這樣，OpenFlow Controller就能夠更聰明地按照用戶的路由策略來及時調整每個交換機的轉發行為，從而更容易的實現如流量工程(Traffic Engineering)和快速故障恢復(Fail Over)這樣的高級功能。這也是SDN的優勢之所在。

一般地，OpenFlow Controller借助LLDP(Link Layer Discovery Protocol)協議發現OpenFlow交換機之間的連接狀態。LLDP協議廣泛地用于網絡設備廣播自己的ID，能力(Capabilities)和鄰居。LLDP具有專用的MAC廣播地址和EtherType，這樣，OpenFlow Controller可以輕而易舉的識別LLDP報文。網絡拓撲的發現由OpenFlow Controller發起，OpenFlow Controller推送給每個OpenFlow交換機一個packet_out消息，指示交換機向所有的端口發出LLDP報文。與此同時，收到LLDP 報文的交換機也會向它的所有的端口發送LLDP報文。然而，收到LLDP報文的交換機的Flow Table中沒有和LLDP報文匹配的Flow Entry。因此，它就把收到的LLDP報文封裝為packet_in消息發送給OpenFlow Controller。OpenFow Controller分析這些LLDP的報文，就能夠知道交換機之間誰和誰通過哪個端口連接在一起。最終，OpenFlow Controller得到網絡的完整的拓撲結構。

在OpenFlow網絡的路由服務中，發現拓撲的目的是為了計算從一個邊緣交換機到另一個邊緣交換機之間的路徑。為了討論的方便，我們假設路由服務僅使用最短路徑(Shortest Path)的策略。盡管這是最簡單的情況，但可以舉一反三地靈活運用這里給出的基本的原理和方法，實現更高級的更有價值的網絡路由策略。網絡的拓撲表現在數據結構上，就是一個圖(Graph)。眾所周知，給定一個像網絡拓撲的那樣的圖，計算兩點之間的最短路徑的算法就是大名鼎鼎的Dijkstra’s Algorithm。對于圖中一個源節點，該算法可一次計算出到達所有其他節點的最短路徑。算法的細節請參考Wikipedia的文檔：http://en.wikipedia.org/wiki/Dijkstra’s_algorithm。兩點之間的最短路徑也許并非只有一條，可能存在多條，我對此算法稍作擴展，能夠計算出兩點之間的所有最短路徑。我的另一篇博客給出了這一擴展算法的C++實現，可直接編譯運行。得到多條最短路徑，就可以實現類似于ECMP的流量均衡(Traffic Ba lance)的路由策略。

對應于圖1的情況，OpenFlow Controller使用Dijkstra’s Algorithm得到主機A到主機B經過OpenFlow網絡中的路徑如下，其中的數字代表入端口或出端口。

Path(A, B): (3, ES1, 1) -> (1, ES2, 2)

同樣地，主機A到主機C和主機C到主機B的路徑如下：

Path(A, C): (3, ES1, 2) -> (2, SW0, 1) -> (1, ES3, 2)

Path(C, B)：(2, ES3, 1) -> (1, SW0, 3) -> (3, ES2, 2)

當然，相反方向路徑如Path(B, C)、Path(C, A)和Path(B, A)的計算自然也不在話下。

#p#

轉發和路由

有了主機和接入到邊緣交換機的信息，也能夠算出邊緣交換機到邊緣交換機的路徑。實現路由服務的最后一步是OpenFlow Controller向連接主機或子網的路徑上的每個OpenFlow交換機下發Flow Entries，改變交換機的轉發行為，以達到主機間通信的目的。如對于連接從主機A到主機B的路徑Path(A, B)，下發到ES1和ES2的Flow Entry分別是：

Switch ES1: 
 
match: src_ip = 2.2.2.2/32, dst_ip = 1.1.1.0/24, in_port = 3 
 
action: out_port = 1 
 
Switch ES2: 
 
match: src_ip = 2.2.2.2/32, dst_ip = 1.1.1.0/24, in_port = 1 
 
action: out_port = 2; eth_dst = 00:00:00:00:00:01 

這樣，從主機A發往主機B的一個IP數據包就可以依次經過交換機ES1和ES2到達網絡1.1.1.0/24。請注意，下發給交換機ES2的Flow Entry的action中，將把匹配到的數據包的目的MAC地址eth_dst更新為主機B的MAC地址。這樣，數據包才會被二層(Ethernet) 網絡正確地轉發到主機B。否則，數據包將被丟棄。

同樣地，內部主機A到外部主機C的路由可由下面的Flow Entry來定義：

Switch ES1: 
 
match: src_ip = 2.2.2.2/32, dst_ip = 3.3.3.0/24, in_port = 3 
 
action: out_port = 2 
 
Switch SW0: 
 
match: src_ip = 2.2.2.2/32, dst_ip = 3.3.3.0/24, in_port = 2 
 
action: out_port = 1 
 
Switch ES3: 
 
match: src_ip = 2.2.2.2/32, dst_ip = 3.3.3.0/24, in_port = 1 
 
action: out_port = 2; eth_dst = 00:00:00:00:00:03 

不難發現，OpenFlow網絡把發往外部主機的數據包只送到相關的路由器，如上面例子中的路由器R。剩下的路由就交給外部的網絡了，因為外部網絡超出了OpenFlow Controller的控制范圍。

最好，再看一個相反方向的從外部主機C到內部主機B的路由的實現：

Switch ES3: 
 
match: src_ip = 3.3.3.0/24, dst_ip = 1.1.1.0/24, in_port = 2 
 
action: out_port = 1 
 
Switch SW0: 
 
match: src_ip = 3.3.3.0/24, dst_ip = 1.1.1.0/24, in_port = 1 
 
action: out_port = 3 
 
Switch ES2: 
 
match: src_ip = 3.3.3.0/24, dst_ip = 1.1.1.0/24, in_port = 3 
 
action: out_port = 2; eth_dst = 00:00:00:00:00:01 

需要指出的是，上文給出的下發到OpenFlow交換機的Flow Entries只是OpenFlow Controller實現路由服務的一種可能的方案，這里只是用來示例。而不同的OpenFlow Controller下發的Flow Entries會有所不同，但基本的原理應是大同小異。

我想，OpenFlow網絡的路由服務的主要優點在于實現的靈活性，可根據實際的需求做具體的定制，而不受限于已有的路由協議標準和硬件基礎設施的制約。正是有了SDN數據平面和管理平面的分隔，這種網絡可編程的(Programable)靈活性才可能成為現實。

參考文獻

1. DEMYSTIFYING ROUTING SERVICES IN SOFTWARE-DEFINED NETWORKING @ http://www.aricent.com/sites/default/files/pdfs/Aricent-Demystifying-Routing-Services-SDN-Whitepaper.pdfa