P4與OpenFlow之間的差異(翻譯)

Origin from: Clarifying the differences between P4 and OpenFlow

幾個人曾問過 P4 與 OpenFlow 之間的差異是什麼。P4 只是另一種版本的 OpenFlow嗎？在此文章我們將會解釋為何 P4 比起 OpenFlow 可以解決一個更為普遍的問題。在 P4 中，OpenFlow 是眾多可能的程式之一來描述 forwarding plane 怎麼運行。P4 不是如某些人建議的那樣是 OpenFlow 2.0。雖然他們都專注於在開放式 forwarding plane，P4 解決了網路中的那些需要程式化data plane的不同需求。

早在 2007 年，當 OpenFlow 第一次被提出，我們希望透過一種軟體 control planes 的方式來遠端控制許多不同的 switches。我們發現到在大部分的網路中 switch 都做相同的事情：Ethernet, IPv4, Access Control Lists (ACLs), VLANs 諸如此類。如果我們能定義一種標準且開放的介面來建立 switch 內的 forwarding tables (查詢Ethernet address的hash tables和用於ACL中IPv4與wildcard查詢的longest-prefix match tables)，我們便可以創造 control planes 來控制來自各種不同供應商的 switch。這個想法很簡單 (雖然一些供應商害怕商品化他們的 switch 產品並且多少會威脅到他們的利潤)。主要目標是使那些想要創造更好網路control planes的人更容易達成。我們可以看見這確實有效，如同今日許多大型 data centers透過自製的control planes中利用部分或是全部的開放式data plane介面所建立而成的。

重要的是記得 OpenFlow 是假定 switch 有固定並已知的行為且通常描述於switch ASIC晶片的數據表中。傳統的高性能switch晶片能支援固定的協定因為他們直接在矽晶片中實現了IEEE與IETF 標準協定。你不能改變他們的行為或是新增新的協議或是用新方法來測量或控制數據 (今日在固定功能ASIC中新增一個協議需要花上四年的時間！) 因此第一版的 OpenFlow 只能夠建立常見的四種協定表 (Ethernet, VLANs, IPv4, ACLs)。隨著需求增長，越來越多種的header被加進 OpenFlow 中，像是IPv6、MPLS 與 VXLAN。 今天 OpenFlow 允許我們在 forwarding entries 增加或刪除約五十種不同的header種類。Switch供應商可以使用Open Networking Foundation (ONF)中的Table Type Patterns (TTP)標準來告知control plane支援哪些headers。OpenFlow 並不是真正控制 switch 的行為，而是給了我們一個建立一套已知表格的方法。

你可能已經認識 OpenFlow 並想知道它是否會支援越來越多的 headers 。這是很多人所擔心的問題。是因於 switch 晶片特性使 OpenFlow 強制妥協。這種 Switch 晶片是不可以邊程的特性我們視為理所當然。如果他們要是可編程，我們便不需要像是OpenFlow這種固定的 protocol 。 反之，我們可以簡單的告訴 switch 如何處理封包以及要保留哪些 tables 。程式設計師可以定義任何有意義的 API 來填充 switches 中建立的 tables。

那麼為什麼 switch 的晶片是固定功能的呢？ 這是一個很好的問題，是這些網路中視為“常規的智慧” (或神聖不可侵犯)常常重新探討的問題之一。在過去可以編程的 switch 晶片只能約以固定式的ASICs(記得NPUs?)的1/10或1/100的速度處理封包。但是今天在市場上已有與最快速固定式 switch 處理速度近乎相同的可配置晶片。我們進一步的展示文章 – 可編程的switch達到跟固定式運行速度一樣快。我們稱呼這種可編程的晶片為“PISA”(Protocol Independent Switch Architecture)。如果可編程 PISA 晶片運行的跟固定式的一樣快，那麼我們便能夠開闢一個可以定義 switch 如何處理封包的新網路時代。此外，如果我們定義一個語言來設計快速的switch也可以使用相同的語言來設計較慢的 switches 像是使用NPUs、 FPGAs 或是軟體 switch (如vSwitch)。我們認為如果我們能找到一種語言來編程網路中的每一台 switch，那麼 switch 間的互通性幾乎立刻實現 – 能夠以相同的方式對所有 switch 進行編程。甚至也能使用相同的語言來明確描述固定式的ASICs switch，而不是必須依賴以英文理解不明確的數據表 (例如在標準手冊中理解SHOULD與MAY意義)。

所以在2013年，考慮到這些目標，來自Google, Intel, Microsoft, Stanford, Princeton,以及 Barefoot 的團隊開始設計P4 language。

P4 成為這種“bottom-up”網路模式領頭。P4 給予我們能夠告訴 switch 該怎麼做以及該如何處理封包的能力而不是讓 switch 限制我們能夠做的事情。P4 讓我們能定義 switch 能辨識怎樣的 header (或是“parse”)， 如何根據每個 header 來 match，以及該根據每個header該採取怎樣的action。舉例來說，我們可能會告訴 switch 使用longest-prefix match 處理 IPv4 headers的32-bit destination address，將它送至next hop，確認TTL並減少之，更新checksum最後重新封裝新的Ethernet header。協定只是一個在P4中被陳述的程式。 P4 精準明確的指出 headers 該如何 match 且該實行什麼樣的 actions。事實上, 你可以直接編譯 P4 的程式來直接產生一個可以執行的 switch – 已經存在的 open-source 編譯器用來測試新的 switch 功能。一些公司已經加入了P4.org 協助社群發展，部分也展示了P4 解決方案並提供客戶工具集。

因此藉由先指定轉發的行為然後填充我們定義的 table，P4 讓我們以“top-down”的方式來控制 switch。此外，P4 編譯器通常也會自動產生用來填充 table用的 API。這使今天能夠廢除 switch 晶片的固定封閉的API。而不是讓switch晶片商為我們定義API並綁定我們使用供應商的下個晶片，P4 讓我們能定義必須填充 switch 用的 API。我們說P4是“top-down”是因為它讓網路架構師、程式設計師以及開發者主宰而不是那些晶片供應商。

OpenFlow 對於處於支援OpenFlow固定式以及可程式化 switch 的混合網路來說是絕對仍然有用。事實上，已經有個名為 openflow.p4 用來設計PISA支援 OpenFlow 的P4程式可以使用。換句話說，OpenFlow在P4語言中只是一個程序。如此 OpenFlow 與 P4 可以同時在網路中相互運作。然而 OpenFlow 是被設計來將 SDN networks 中 control plane 與 forwarding plane 分離，P4 則是設計來程式化任何 switch 或 router 的行為，而不管是透過OS的本機控制或是遠端 SDN controller所控制。

沒有特別的理由認為P4將會讓 OpenFlow 在不久之後過時。市場上仍有大量固定式ASICs switch並且其中很多可以透過OpenFlow進行控制。事實上，隨著愈多的固定式switch晶片透過TTPs標準設計，就有更好理由認為 OpenFlow 會存在一段時間。P4 提供了一種建構可編程與固定式switch混合網路的無縫方式並讓我們能以軟體的方式引進新的功能與協定而不是需要等待新的硬體。而 P4 設計師能保有與他人區分的獨特功能，而不是必須與晶片供應商分享所有東西。