01C h a p t e r

認識SDN

本章重點

1.1 什麼是 SDN

1.2 SDN不是什麼

1.3 SDN架構

1.4 SDN發展歷史

1.5 對 SDN的誤解

1.6 不該被遺忘的 SDN先烈

01

2

認識SDN 1.1 什麼是 SDN

SDN是 Software Defined Network的縮寫，譯成中文就是軟體定義網路。當然，筆

者如果就只是這樣簡單來解釋一下 SDN，大概會被罵得狗血淋頭，Google/百度大

家都會用，這幾個單字國中生都能翻譯出來。

在 2013年的 ONS大會上，有人開玩笑說 SDN = Stanford Defined Network，或

Sexy Defined Network，或 Still Don't kNow。玩笑的背後隱藏的含義就是：大家對

SDN的理解不太一致，並且對 SDN前景的看法也不一致。

筆者在十幾年的通訊技術職業生涯中，總結出了一條快速學習新技術的經驗，在 IT

技術領域，特別是通訊領域，對一項新技術的命名是非常嚴謹的，很多技術的名字

都非常精準到位，如果能把該技術的名字領悟透徹，對了解該技術的幫助很大，例

如 VLAN、STP、OSPF、MPLS等都是其中的典型代表，均能絕佳展現這些技術的

內涵精髓。筆者非常喜歡在研究一項新技術的時候，先把該技術的名字研究清楚，

SDN也不例外。

網路上關於 SDN的爭論鋪天蓋地，褒貶不一。在質疑 SDN的聲音中：

█ 最常聽到的就是——「我為什麼需要 SDN？有什麼是 SDN能做到而傳統網

路做不到的？」

█ 具體到轉接面，通常是——「SDN交換機本質上也不過是把傳統交換晶片包

裝一下而已，有什麼轉接行為是傳統交換機無法支援的？」

█ 具體到控制面，通常是——「傳統交換機是用網管軟體或者指令來進行管理

的，SDN交換機無非是換成 Controller（控制器）來管理而已，有什麼本質

上的區別？」

1.3

7

SDN

架構

1.3 SDN架構

說了這麼多，「什麼是 SDN」不如用一張圖表示還較直觀。前面講過了，SDN不是

一項具體的技術，而是一種網路設計理念、一種網路架構，請看圖 1-1圖解 SDN

架構。

※ 圖 1-1

讓我們具體解釋一下圖 1-1。

1. 網路設備（Network Devices）

這裡的網路設備其實可以是抽象的轉接面（Forwarding Plane或者另外一

個名字 Data Plane），而不一定是硬體交換機，也可以是虛擬交換機，例如

OVS，當然也可以是別的實體設備，例如路由器。所有的轉接表項，都儲存

在網路設備裡面，使用者資料封包在這裡面被處理、轉接。

6. Automation

5. Services

4. Northbound

3. Controllers

2. Southbound

1. Network Devices

2.1

23

網路商業發展趨勢

服器虛擬化在未來一兩年 IT部署和管理領域的 12大優先順序事件排名第三

（圖 2-1）。如何有效地管理這些數量龐大的虛擬機器和虛擬網路是一個很大

的問題。

█ 新的應用架構。資料顯示，現在有超過 60%的組織正在大量部署基於服務

和基於 Web的應用，這些應用促使資料中心要建立大量伺服器到伺服器間

的通訊連接，而且也要求不同應用之間要相互隔離。資料中心從傳統基於資

料轉接的模式轉換到了基於服務的遞交模式，這使得資料中心變得更趨於動

態、複雜，傳統的網路架構不再適合。

█ 雲端運算。事實上，雲端運算是近幾年 IT領域發展最迅速的技術。它要求

企業能夠使用更加敏捷有效的技術，來快速回應雲端運算的商業需求，也對

網路架構提出了新的需求。

█ BYOD。BYOD是 Bring Your Own Device的意思，就是說現在有越來越多的

員工攜帶自己的 IT設備到公司上班，包括筆記型電腦、平板電腦、智慧型

手機等，這為現有企業無線網路的流量、安全、管理帶來了更大的壓力。

※ 圖 2-1

主動的訊息安全防護

提高資料備份和恢復能力

日益增加的伺服器虛擬化

管理資料增加

資料中心合併

桌面虛擬化

使用雲端基礎架構服務

大量應用程式佈署和升級

在新的行動裝置上的 app佈署

提高協作能力

29%

27%

26%

25%

24%

22%

22%

22%

20%

20%

2.3

27

SDN

如何來解決這些問題

2.3 SDN 如何來解決這些問題

很多人嘗試了多種不同的方式來解決現有網路中的這些問題。SDN是其中之一，

也是目前看來最被認可的、影響力最大的一種方式。

SDN解決這些問題的核心，是改變傳統網路對資料流程進行控制的方式。在傳統

網路中，封包從來源轉接到目的的過程中，封包的轉接行為是逐條獨立控制的，獨

立地進行配置，有自己特定的處理能力和配置方式，這種控制是完全分散式的，如

圖 2-3所示。

※ 圖 2-3

而 SDN則透過把每台設備的控制面從設備裡面剝離出來，放到一個統一的外部伺

服器，由這個伺服器透過統一的指令來集中管理轉接路徑上的所有設備，這個集中

控制器知道所有必需的資訊，而且這個控制器可以透過提供開放的 API被上層應用

程式通過程式設計控制。這樣可以消除大量手動配置的過程，引入靈活性，增加管

理員對全網的整體視圖，提高商業部署的效率。

例如在網路虛擬化中，當要增加一個新的租戶或者為一個租戶增加一個新的虛擬機

器的時候，透過雲端運算管理平臺（例如 OpenStack或者 CloudStack），只要管理

員把該租戶或者虛擬機器的屬性填寫好，雲端運算管理平臺自動計算所有需要的資

源和配置，對涉及的網路資源部分，可以在內部透過調用 Controller的 API，自動

Packet DesinationControl Control

Control

Control

Control

2.5

33

讓我們來看兩個案例

※ 圖 2-5

以下是筆者跟該客戶技術人員的問答。

問：在沒有引入 SDN 之前，你們的防 DDoS 攻擊方案是怎麼樣的？

答：傳統的資料中心防 DDoS攻擊方案通常是這樣的，在資料中心入口設備上，

透過 Netflow將資料流程的一些統計資料和特徵資料送到一個遠端的伺服器進行分

析，伺服器透過分析檢測到某些封包屬於 DDoS攻擊封包，然後將封包的特徵告

訴資料中心入口設備，該設備透過 BGP協定將所有發往受害者設備的封包都對應

到一條黑洞路由，導致這些封包都被丟掉，透過這種方式來緩解攻擊造成的影響。

這種方式的問題在於在被攻擊的這段時間內，所有發往被攻擊設備的封包都會被丟

掉，不管是非法的還是合法的，導致一段時間內該設備不可達，這是一種純粹基於

目的 IP的方案。而我們現在的做法不是直接把所有封包丟掉，而是送到一個資料

03

40

SDN

相關組織及利益紛爭

商顧問委員會，裡面的成員都來自全球著名的半導體廠商，盛科網路和華為是僅有

的中國大陸地區公司，這個委員會專門負責針對 SDN轉接面晶片的設計方向提供

專業的建議甚至直接提供方案。

其中的工作和討論群組之下分了很多小組，表 3-1列出了目前所有工作組的名稱和

他們的職責。

※ 表 3-1

工 作 組 職 責

Architecture and Framework

負責技術框架性的定義，決定技術方向。

Configuration and Management

負責 OpenFlow 設備中配置管理標準的定義，OF-Config 1.0、1.1就是這個工作組制定的。

Extensibility負責 OpenFlow 標準的制定。為什麼名字叫 extensibility 而不是

specification 之類的？筆者猜測原因應該是他們把 OpenFlow 1.0作為一個基礎標準，所有後續的都算是擴展標準。

Forwarding Abstraction

負責轉接面抽象的工作，可視為試圖從實作各異的轉接晶片中提取

出一些共通性，來標準化硬體轉接。這是一個很重要的工作組。之

前 TTP 的概念就是他們提出的，後面章節我們會詳細介紹 TTP，這是 ONF 在 SDN 轉接面做的一次標準化嘗試，看起來很不錯。

Nick Mckeown 現在似乎很關注這個工作組的工作，後面會提到。

Testing and Interoperability

負責組織 SDN 設備和軟體的測試，包括標準一致性的測試和互聯

互通測試，每年的 Plugfest 測試就是他們負責組織的。在 2013 年

8 月，這個工作組開始推出了基於 OpenFlow 1.0.1 的測試規範，

用來測試各個廠商的 Controller 和 Switch 的標準符合度。

Market Education 這個工作組負責 SDN 的全球推廣活動，組織各種論壇、討論會。

Migration這是一個新成立的工作組，目前還沒有什麼產出，從官網介紹來

看，這個工作組負責尋找一些方式，說明網路使用者從傳統網路向

SDN 網路的系統轉換。

3.1

49

ON

F

︵Open N

etworking Foundation

︶

3.2

49

OD

L

︵OpenD

ayLight

︶

※ 表 3-3

異 同 點 ONF ODL

性質 網路使用者為主 設備商和軟體商為主

成立時間 2011 年 2013 年

宗旨制定 SDN 標準，推動 SDN產業化

打造統一開放的 SDN 平臺，

推動 SDN 產業化

工作重點

制定唯一的南向介面標準

OpenFlow，制定硬體轉接行

為標準

不制定任何標準，而是打造

一個 SDN 系統平臺，利用現

有的一些技術標準作為南向

介面

跟 OpenFlow 的關係OpenFlow 是其唯一的南向介

面標準

OpenFlow 只是南向介面標準

中的一個

北向介面

目前沒有做任何北向介面標

準化的工作，而且不傾向於

標準化北向介面

定義了一套北向介面 API

轉接面的工作通過 OpenFlow 定義了轉接

面標準行為

不涉及任何轉接面工作，對

轉接面不做任何假設和規定

3.2.4 ODL 和 ONF 的利益衝突

從表 3-3的對比來看，ONF和 ODL其實是兩個並行的組織，兩者之間有重疊，

但是更多的是差異。之前 ONF的執行總監 Dan Pitt在 ODL成立之初接受記者採

訪的時候說，ONF 是制定 SDN 的標準，ODL是執行他們的標準，兩者並不矛

盾，但是現在看來並非如此。ONF制定了 OpenFlow標準，但是 ODL並不是只

實作 OpenFlow一個標準，他們實作的遠比 OpenFlow多得多，而且有些理念是

跟 OpenFlow相衝突的，例如 ODL並不假定轉接面是有統一標準的，更不假定

03

54

SDN

相關組織及利益紛爭

03

54

SDN

相關組織及利益紛爭

再來看看 ODL要打造的這個系統平臺的架構（圖 3-2），兩者何其相像。

從架構圖可以看出，OpenDayLight這個系統平臺包括三部分，最上面的北向介面

以及內置的應用程式和服務、中間核心的網路和平臺服務部分，以及最下層的南向

介面。

※ 圖 3-2

北向介面使用了現在很流行的 REST API介面，可以很靈活地支援各種應用程式。

REST是近年來影響力最大的 Web服務設計模式，新浪微博、微信都支援 REST介

面。除了使用者介面，OpenDayLight專案的參與者也都貢獻了不少自己的應用程

式和平臺服務，例如：Radware公司的防 DDoS攻擊應用、NEC的虛擬租戶網路

（VTN）、IBM的分散式覆蓋虛擬乙太網（DOVE）、VMware公司的網路虛擬化平臺

（NVP）等。

南向介面包括 OpenFlow以及很多其他介面，OpenFlow只是這個平臺中一個很小

的部分，圖 3-2中沒有列出來的南向介面還包括 SNMP、LISP、XMPP、PCEP、

OF-Config、Net-Config、BGP-LS等，還允許廠商定義私有的介面。OpenDayLight

3.1

59

ON

F

︵Open N

etworking Foundation

︶

3.4

59

NFV

︵Netw

ork Function Virtualization

︶

和卸載，而不需要安裝新的硬體設備。這麼說有點抽象，我們看看 NFV標準化組

織的白皮書裡面提供的一種示意圖（圖 3-3）。

圖 3-3的左邊是目前電信業者網路中的設備部署情況，我們可以看到有各式各樣獨

立的實體設備。而圖 3-3的右半部分只有三種類型的設備，分別是一堆同類型的伺

服器、一堆同類型的存放裝置、一堆同類型的交換機。左邊那些設備都到哪裡去

了？都透過軟體虛擬到右邊的三種類型的設備中去了。

※ 圖 3-3

3.1

65

ON

F

︵Open N

etworking Foundation

︶

3.6

65

IETF3.6 IETF

SDN這麼熱門的事，沒有 IETF參與看起來有些奇怪。事實上，無論從利益還是技

術層面，IETF不可能不參與的，但是看起來 IETF現在沒什麼章法，像是被逼應戰。

3.6.1 Softwre Driven Network

IETF 在 筆 者 看 來 就 是 一 個 SDN 的 攪 局 者（IETF 的 核 心 是 誰？ Cisco、

Juniper！），從他們推出自己的 SDN概念就能看出些端倪。他們的 SDN中的 D

不是 Defined，而是 Driven，他們還就這個名字跟 ONF的 SDN的區別做了一個比

較，如圖 3-6所示。

※ 圖 3-6

什麼意思呢？就是說把 SDN改了個名字，也許將 D從 Defined改成 Driven是一個

good idea，怎麼說呢？因為 Defined意味著軟體和應用程式唯一的作用就是用來

控制資料轉接面，而 Driven則更高階，它涵蓋了控制面和資料轉接面，根據轉接

04

104

詳解OpenFlow

有人會問，那麼這種 NDM方案跟做一個傳統交換機有什麼區別？區別就在於 NDM

方案雖然用了傳統表項，但是它的架構是 SDN架構（控制面和轉接面分離），而且

控制面和轉接面的介面仍然是 OpenFlow介面。換句話說，從外部表現來看，這就

是一台 OpenFlow交換機（在應用比較傳統的情況下，如果有些非常規的查閱 Key

組合，那就滿足不了）。

圖 4-6是最早的時候某公司提出的 NDM方案（那個時候還叫 TTP）流程圖，這個

流程其實是標準的傳統交換晶片的處理流程（裡面的 QoS就是 ACL表），所謂的

多級流程表就是用圖中的這些表組合起來的。

※ 圖 4-6

Interface Table

L2 ACL

MPLS ACL

L3 ACL

Mac Table

MPLS Table

Route TableTunnel Encap

Interface Table

L2 ACL

MPLS ACL

L3 ACL

Ingress Egress

相對於其他各種臨時方案，筆者更傾向於這種 NDM方案，因為它不需要等待新的

晶片研發，即可快速做出產品，成本跟普通交換機等同，而且關鍵是能滿足現在

很多應用的需求（這也是 TTP被提出的主要目的）。從現在的 SDN部署情況來看，

更多的部署是為了利用 SDN架構的管理方便性、簡單性、控制和轉接分離，而

不是利用 OpenFlow的靈活性（當然也有，但是目前比較少）。筆者就碰到過不少

這樣的案例，後面「SDN應用案例分析」一章，我們會就其中的典型案例做一下

分析。

Interface Table

Tunnel Encap

Interface Table

L2 ACL

Ingress Egress

L2 ACLMac Table

L3 ACL L3 ACLRoute Table

MPLS ACL

MPLS ACL

MPLS Table