摘要
P4是一門編寫協議無關的包處理器的高級語言。P4與SDN控制協議聯合在一起工作，比如OpenFlow。在OpenFlow當前的協議形態中，它精確地指定了供它操作的協議頭。這個協議頭集合已經在短短的幾年時間中，從12個域增長到了41個域，這同時也增加了協議的複雜性，但是仍然沒有提供添加新的自定義首部的靈活性。
在這篇論文中我們將P4作爲一個展示了OpenFlow在未來應該如何演進的草案協議而提出。我們有如下三個目標：
1.匹配域的重配置能力：在交換機被部署之後，開發者應該能夠改變交換機處理數據包的方式；
2.協議無關性：交換機不應該被綁定在任何特定的網絡協議上；
3.目標無關性：開發者應該能夠在不關注底層特定硬件設備的前提下描述包處理功能。
我們以下將會以如何使用P4配置交換機來添加一個新的分層次的標籤爲例，講解以上三個目標。
第一章 介紹
軟件定義網絡（SDN）給予網絡運營者對他們的網絡進行可編程控制的能力。在軟件定義網絡中，控制平面與轉發平面物理隔離，並且一個控制平面可以控制多個轉發設備。同時，轉發設備可以通過多種方式被編程，它們都擁有一個通用的、開放的、廠商無關的接口（比如OpenFlow）。這一點也使得一個控制平面能夠控制來自不同硬件和軟件廠商的轉發設備。
表1-1 OpenFlow標準支持的匹配域
OpenFlow接口一開始很簡單，只抽象了單個規則表，並且表中只能在數據包特定的十二個首部區域上進行匹配（比如MAC地址、IP地址、載荷協議類型、TCP/UDP端口等等）。在過去的幾年中，協議標準已經演進得越來越複雜（如表1-1），歸結起來就是支持匹配越來越多的首部區域和支持多級的規則表，由此能夠允許交換機向控制器暴露出它們更多的能力。
新首部區域的增多過程沒有表露出任何即將結束的跡象。例如，數據中心網絡的運營者越來越想要使用新的包封裝形式（比如NVGRE、VXLAN和STT），他們採取部署軟件交換機的方式來達到這個目的，因爲軟件交換機更容易擴展新的功能。相比重複地擴展OpenFlow的協議標準，我們認爲未來的交換機應該爲包解析和首部域匹配支持靈活的機制，允許控制器應用通過一個通用的開放的接口利用交換機的這些能力（例如新的“OpenFlow 2.0”接口）。比起如今的OpenFlow 1.x標準，上述這樣一個通用的可擴展的方法將是更簡單、更優雅也更不會過時的。
近段時間的芯片設計方案表明，這樣的靈活性可以在定製的ASIC上實現太比特級的速率[1,2,3]。編寫這種新一代的交換芯片是非常不容易的。每一個芯片有其自身的低級接口，類似於微碼編程。在本篇論文中，我們概述了一種編寫協議無關的包處理器（P4）的高級語言的設計。圖1-1展示了P4和已有的協議接口之間的關係。P4用來配置交換機。告訴它們應該如何處理數據包。已有的協議接口（例如OpenFlow）負責將轉發表送入固定功能的交換機。P4爲編程控制網絡提升了抽象等級，作爲一個控制器與交換機之間的普通接口進行工作。換言之，我們相信未來幾代的OpenFlow協議應該允許控制器“告訴交換機如何去做”，而不受固有的交換機設計的侷限。關鍵的挑戰是要找到一個折衷點，它要能夠平衡“能夠靈活表達多種控制意願的特性需求”與“在大範圍的軟硬件交換機上實現的低難度”要求。
圖 1-1 P4是一門交換機配置語言
在設計P4的時候，我們有三個主要的目標：
1.重配置能力：控制器應該能夠重新定義數據包的包解析過程和對首部區域的處理過程；
2.協議無關性：交換機不應該與特定的包格式綁定。相反地，控制器應該能夠指定：
1)一個能提取出特定名稱和類型的首部區域的包解析器
2)一個類型化的用於處理這些首部區域的“匹配 – 動作”表的集合
3.目標無關性：正如C開發者不需要知道底層具體是什麼CPU在工作一樣，控制器的開發者不必知道底層交換機的細節。而是P4編譯器在將目標無關的P4描述轉換成目標相關的用來配置交換機的程序時，才應該去考慮交換機的能力。
本文的行文思路如下：我們從介紹一個抽象的交換機轉發模型開始。然後我們講解了當下對一門描述協議無關的包處理過程的語言的需求。我們接着舉一個簡單而又有積極性的例子，這個例子講述的是一個網絡的運營者想要支持一個新的數據包首部區域，並且分多個階段去處理數據包。我們通過這個例子來探索P4程序是如何指定首部、包解析器、多個“匹配 - 動作”表和多個表之間的控制流程的。最後，我們討論P4編譯器如何將P4程序映射到目標交換機上。
其他相關研究。2011年，Yadav et al. [4]爲OpenFlow提出了一種抽象轉發模型，但沒有強調編譯器這一角色。Kangaroo [1] 提出了可編程包解析的概念。最近，Song [5] 提出了協議無關轉發（POF），它參考了我們協議無關的目標，但是它的關注點更偏向於網絡處理器（NP）。ONF提出了流表編寫模式（TTP），用來表達交換機的匹配能力[6]。近期有關NOSIX[7] 的一些工作也參考了我們“匹配 – 轉發”表這一靈活的設計標準，但沒有考慮到協議無關性，也沒有提出一門能夠指定解析器、規則表和控制流程的語言。近期的其他一些工作提出了一種可編程接口，服務於數據平面的監控、擁塞控制和隊列管理[8, 9]。模塊化的路由器Click [10] 支持軟件層面靈活的包處理，但沒法將這些處理程序映射到大量的目標硬件交換設備上。
第二章 抽象的轉發模型
在我們的抽象模型中（圖2-1），交換機通過一個可編程的解析器和隨後的多階段的“匹配 – 執行動作”的流程組合轉發數據包，其中“匹配 – 執行動作”的過程可以是串行的、並行的或者是二者結合的。源於對OpenFlow的探索，我們的模型包含了三個一般化。首先，OpenFlow假設有一個固定的包解析器，在這一點上我們的模型能夠支持可編程的解析器，允許定義新的協議首部。第二，OpenFlow假設“匹配 – 執行動作”的各個階段是串行的，在這一點上我們的模型允許它們是並行的或串行的。第三，我們的模型假設“動作”是使用交換機所支持的協議無關的原語編寫而成的。
我們的抽象模型將數據包如何在不同的轉發設備上（例如以太網交換機、負載均衡器、路由器）被不同的技術（例如固定功能的ASIC交換芯片、NPU、可重配置的交換機、軟件交換機、FPGA）進行處理的問題一般化了。這就使我們能夠發明一門通用的語言來描繪如何根據我們通用的抽象模型處理數據包。因此，開發者可以開發目標無依賴的程序，開發者可以映射這個程序到大量不同的轉發設備中，這些設備覆蓋從相當慢的軟件交換機到最快速的基於ASIC芯片的交換機。
這個轉發模型受兩類操作控制：配置和下發。配置操作編寫了包解析器，設置了“匹配 – 執行動作”各階段的順序，指定了每個階段要處理的協議首部區域。配置操作決定了支持哪種網絡協議，也決定了交換機可能會如何處理數據包。下發操作將表項添加到“匹配 – 動作”表中，或從其中移除。其中，表本身是在配置操作的時候指定好的。下發操作決定了在任意給定時刻應用到數據包上的執行策略。
出於這篇論文的講述目的，我們假設配置和下發是兩個獨立的階段。特別地，交換機不需要在配置的階段處理數據包。同時，我們期望未來的具體實現能夠允許數據包無論是在部分配置完成還是完全配置好的時候，都能夠被處理，也即允許在配置升級的時候，包處理過程沒有任何的暫停。我們的模型慎重考慮和鼓勵實現不打斷轉發過程的重配置。
顯而易見，配置階段對於固定功能的ASIC來說是沒有意義的；對於這類交換機，P4編譯器的工作是簡單地檢查芯片是否能夠支持P4程序。相反地，正如[2, 3]中所描述，我們的目標是把握快速可重配置的包處理流水線的一般趨勢。
到達的數據包首先被包解析器處理。我們假設數據包的數據內容是與包首部分開緩存的，並且不能夠用來進行匹配。解析器從包首部中找出並提取某些區域，這也即定義了交換機所支持的協議。這個模型沒有對協議首部的含義做任何假設，僅僅是解析後的數據包的表現形式定義了一個首部區域的集合，“匹配 – 執行動作”的過程就在這個集合上進行。
提取出來的首部區域接下來會被傳遞到“匹配 – 動作”表。這個表被分爲入口表和出口表兩部分。雖然兩個表都可能會修改包首部，但是入口的“匹配 – 動作”決定了是數據包將去往哪一個出口，也決定了數據包將被放入哪一個隊列。基於入口的處理結果，數據包可能會被轉發、複製（爲了組播、SPAN端口監控或發往控制平面）、丟棄或觸發流量控制。出口的“匹配 – 動作”在包首部上爲每一個動作目標單獨做一輪修改，比如在組播複製數據包的時候所做的。動作表（計數器、流量監管器policer等）可以與一條流關聯起來，追蹤其每一幀的狀態。
圖 2-1 抽象轉發模型
數據包可以在其被處理的不同階段之間攜帶額外的信息，稱作metadata元數據。元數據可以同等地被當成一個數據包首部區域。元數據的一些例子有入端口號、傳輸目的地和隊列、用於數據包調度的時間戳，以及在表與表之間傳遞的數據，這些數據不涉及改變數據包解析後的表現，比如虛網標識號。
排隊策略的處理方式同當前OpenFlow的一樣：通過一個動作將一個數據包映射到一個隊列中，這個隊列是爲了接收特定服務策略而配置的。服務策略（例如最低速率、DRR輪詢）的選擇是交換機配置的一部分。
儘管超出了本文的範圍，動作原語可以加入模型中，從而允許開發人員實現新的或已有的擁塞控制協議。例如，交換機可能會被編程去基於新的條件設置ECN比特位，或者交換機可能會使用“匹配 – 動作”表實現一個私有專用的擁塞控制機制。
第三章 一門編程語言
我們使用上述的抽象轉發模型來定義一門語言，用以表達交換機將如何被配置，數據包將如何被處理。本文的主要目標是提出這門P4編程語言。儘管如此，我們意識到在這個領域以後可能會有多種語言誕生，並且他們可能都包含了我們在這裏描述到的通用特性。比如，這樣的語言需要一種方式來表達解析器是如何被編程的，由此解析器能夠知道它應該處理什麼樣的數據包格式；因此開發者需要一種方法來聲明什麼樣的首部類型是可能會出現並被處理的。例如，開發者可以指明IPv4首部的格式，以及什麼樣的首部可能合法地遵循了IP首部。通過聲明合法的首部類型促進了P4中的定義解析。相似地，開發者需要表達數據報首部將如何被處理。例如，TTL字段必須被遞減和檢測，新的隧道首部可能需要被添加，校驗和可能需要重新校驗。這促使P4作爲一種必要的控制流程序，通過使用已聲明的首部類型和動作的原語集合，來描述首部區域的處理過程。
我們可以使用像Click這樣的語言，Click使用C++編寫成的模塊構建交換機。Click是極富表現力的，非常適合表達數據包在CPU內核中應該如何被處理。但它不完全符合我們的需求。我們需要一門能夠將“解析 – 匹配 – 動作”流水線映射到指定的硬件上的語言。另外，Click不是爲控制器 – 交換機架構而設計的，因此不允許開發者描述當被修改的時候能夠動態下發更新的“匹配 – 動作”表。最後一點，Click使人們更難以推斷出限制併發運行的依賴。我們後續將討論這一依賴。
一門數據包處理語言必須允許開發者暗示或明示首部區域之間任何串行化的依賴。這種依賴決定了哪些表可以並行執行。例如，由於IP路由表和ARP表之間的數據依賴，它們是需要串行執行的。依賴可以通過分析TDGs表依賴圖而識別；這些圖描述了輸入的首部區域、動作和表之間的控制流程。圖3-1展示了一個二層/三層交換的表依賴圖的例子。
這引領我們提出一種兩步編譯過程。在頂層，開發者使用必要的能描繪P4控制流的語言來編寫數據包的處理程序；在這一層之下，編譯器將對P4的描述翻譯成TDG表依賴圖，以促進依賴的分析，然後編譯器將會把TDG映射到具體的交換機對象上。P4的設計可以讓P4程序翻譯到TDG的過程更加容易。總的來說，P4可以被認爲是Click的普適性和OpenFlow 1.0的不靈活性一個折衷點。Click的普適性讓依賴的推測和映射到硬件的過程變得困難；OpenFlow 1.0的不靈活性讓重配置協議的處理過程變得不可能。
圖 3-1 二層/三層交換的TDG表依賴圖
第四章 P4語言示例
我們通過深入地測試一個簡單的例子來探索P4。許多網絡的部署分爲邊緣和核心兩種；終端主機直接連接在邊緣設備上，邊緣設備之間通過後方的高帶寬核心網互聯。所有的協議都設計去支持這樣的架構（比如MPLS[11]和PortLand[12]），主要目的是簡化核心網的轉發工作。
考慮到一個簡單二層網絡的部署，邊緣的TOR交換設備通過兩層的核心連接在一起。我們假設終端主機的數量在不斷增長，並且核心層的二層轉發表即將存滿溢出。MPLS是一個簡化核心層的選擇，但實現一個多標籤的分佈式標籤協議是一項困難到令人怯步的任務。PortLand看起來看有趣，但是它要求重寫MAC地址（這可能破壞已有的網絡調試工具的正常工作），並且要求有新的客戶端來回應ARP請求。
P4是我們能夠表達一種個性化的解決方案，同時只需要對網絡架構做出做小限度的改變。我們將這個方案稱爲mTag：它結合了PortLand的分層路由思想和類似MPLS的簡單標籤。穿過核心層的路由路徑被編碼成四個單字節的區域，四個區域組成一個32位的標籤。這個32位的標籤可以攜帶“源路徑”或目的地的定位（就像PortLand的Pseudo僞裝MAC一樣）。每一個核心交換機只需要檢查標籤裏的一個字節就可以進行交換轉發。儘管標籤可以由終端主機的網卡添加，但是在我們這個例子中，標籤由第一個TOR交換機添加。
這個簡單的mTag例子將我們的注意力集中到P4語言上。實踐中實現整個交換功能的P4程序將比這複雜很多倍。
4.1 P4概念
P4程序包含以下關鍵元素的定義：
1.首部Headers：首部的定義描述了一系列首部區域的順序和結構。它包含區域長度的規範，約束了區域數據的取值。
2.解析器Parsers：解析器的定義描述瞭如何識別數據包內的首部和有效的首部順序。
3.表Tables：“匹配 – 動作”表是執行數據包處理的機制。P4程序定義的首部區域可能會用於匹配，或者在其上執行特定的動作。
4.動作Actions：P4支持通過更簡單的協議無關的原語構造複雜的執行動作。這些複雜的動作可以在“匹配 – 動作”表中使用。
5.控制程序Control Programs：控制程序決定了“匹配 – 動作”表處理數據包的順序。一個簡單又必要的程序描述了“匹配 – 動作”表之間的控制流。
接下來，我們將展示P4中的這些元素，每一個是如何在一個理想化的mTag處理器的定義上起作用的。
4.2 首部格式
從首部格式的規範開始設計。有幾種特定領域語言也提出了首部格式的設計[13, 14, 15]；P4借用了許多他們的想法。通常地，每一個首部的詳細闡述都是通過聲明一個各首部區域名稱和長度的有序列表來完成。可選的首部區域註解允許我們約束區域的取值範圍或可變長區域的最大長度。例如，標準的以太網和VLAN首部被詳細闡述如下：
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
header ethernet { fields { dst_addr : 48; // width in bits src_addr : 48; ethertype : 16; } } header vlan { fields { pcp : 3; cfi : 1; vid : 12; ethertype : 16; } } |
mTag首部可以直接添加，而不必替換已有的這些聲明。首部區域名稱表明核心層有兩層的匯聚。每一個核心交換機都被編寫了一些規則來檢查這些字節中的某一個。具體檢查哪一個字節，是由交換機在層次中所處的位置和數據流的方向（上或下）決定的。
Shell
|
1 2 3 4 5 6 7 8 9 |
header mTag { fields { up1 : 8; up2 : 8; down1 : 8; down2 : 8; ethertype : 16; } } |
4.3 數據包解析器
P4假設底層交換機可以實現一個狀態機，這個狀態機能夠自頭至尾橫貫數據包的各個首部，隨着狀態機的行進提取首部區域的值。提取出來的首部區域值被送入“匹配 – 動作”表進行處理。
P4把狀態機直接描述成從一個首部到下一個首部的過渡轉移的集合。每一個過渡轉移可能會被當前首部中的值觸發。例如，我們按如下內容描述mTag狀態機：
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
parser start { ethernet; } parser ethernet { switch(ethertype) { case 0x8100: vlan; case 0x9100: vlan; case 0x800: ipv4; // Other cases } } parser vlan { switch(ethertype) { case 0xaaaa: mTag; case 0x800: ipv4; // Other cases } } parser mTag { switch(ethertype) { case 0x800: ipv4; // Other cases } } |
數據包的解析從start狀態開始，一直行進直到到達了明確的stop狀態或是遭遇到無法處理的情況（這可能被標記成錯誤）。在到達了對應下一個首部的狀態時，狀態機根據首部的規範描述提取出首部，然後根據狀態機的下一個過渡轉移繼續向前行進。提取出來的首部被送往交換機流水線後半部分的“匹配 – 執行動作”的處理過程。
mTag的解析器是非常簡單的：它只有四種狀態。真實網絡中的解析器會要求有比這多上許多的狀態；例如，Gibb et. al. [16, Figure 3(e)] 定義的那個解析器就擴展到了一百多種狀態。
4.4 表的規範
接下來，開發者需要描述定義好的首部區域將在“匹配 – 執行動作”階段如何進行匹配（比如它們應該被精確匹配，範圍匹配還是通配符匹配），以及當成功匹配之後將執行什麼動作。
在我們簡單的mTag例子中，邊緣交換機匹配二層目的地和VLAN ID，然後選擇一個mTag添加到首部中。開發者定義一張表來匹配這兩個首部區域，以及執行一個添加mTag首部的動作（見後文）。其中的reads屬性聲明瞭要匹配哪些首部區域，同時限定了匹配類型（精確匹配、三重匹配等）。actions屬性列出了“匹配 – 動作”表可能會對數據包執行的動作。動作將會在本文後續部分講解。max_size屬性指明瞭“匹配 – 動作”表需要能夠支持多少條表項。
表的規範允許P4編譯器決定存儲表需要多大的存儲空間，以及在什麼樣的存儲器（比如TCAM或SRAM）上實現這個表。
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 |
table mTag_table { reads { ethernet.dst_addr : exact; vlan.vid : exact; } actions { // At runtime, entries are programmed with params // for the mTag action. See below. add_mTag; } max_size : 20000; } |
爲了展示的完整性和後續討論的便利，我們在此展示其他表的簡短定義，這些表將在控制程序一節（§4.6）中引用。
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
table source_check { // Verify mtag only on ports to the core reads { mtag : valid; // Was mtag parsed? metadata.ingress_port : exact; } actions { // Each table entry specifies *one* action // If inappropriate mTag, send to CPU fault_to_cpu; // If mtag found, strip and record in metadata strip_mtag; // Otherwise, allow the packet to continue pass; } max_size : 64; // One rule per port } table local_switching { // Reads destination and checks if local // If miss occurs, goto mtag table. } table egress_check { // Verify egress is resolved // Do not retag packets received with tag // Reads egress and whether packet was mTagged } |
4.5 動作的規範
P4定義了一個基本動作的集合，可以利用它們構造複雜的動作。每個P4程序都聲明瞭一個動作功能的集合，動作功能由動作原語編寫而成；這些動作功能簡化的表的規範和下發。P4假設一個動作功能中的原語是並行執行的。（沒有並行執行能力的交換設備可能會模擬並行的過程。）
適用於上述的add_mTag動作的實現如下：
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
action add_mTag(up1, up2, down1, down2, egr_spec) { add_header(mTag); // Copy VLAN ethertype to mTag copy_field(mTag.ethertype, vlan.ethertype); // Set VLAN’s ethertype to signal mTag set_field(vlan.ethertype, 0xaaaa); set_field(mTag.up1, up1); set_field(mTag.up2, up2); set_field(mTag.down1, down1); set_field(mTag.down2, down2); // Set the destination egress port as well set_field(metadata.egress_spec, egr_spec); } |
如果某個動作需要有輸入參數（例如mTag中的up1值），參數將會在運行時由匹配表提供。
在這個例子中，交換機將mTag標籤插入在VLAN標籤之後，複製VLAN標籤的Ethertype字段到mTag中，以指明後續載荷是什麼協議的封包，然後設置VLAN標籤的Ethertype字段爲0xaaaa，表明其後跟隨的是mTag標籤。在邊緣交換機上執行的相反動作沒有展示出來，這些動作將會從數據包中剝去mTag標籤。
P4的基本動作包括：
1.Set_field：將首部中的某一特定區域設置爲特定的值，支持帶掩碼的設置；
2.Copy_field：將一個首部區域的值拷貝到另一首部區域中；
3.Add_header：添加一個有效的特定的首部（以及它所有的首部區域）；
4.Remove_header：從數據包中刪除（pop取出）一個首部（以及它所有的首部區域）；
5.Increment：遞增或遞減一個首部區域的值；
6.Checksum：計算首部區域的一些集合的校驗和（比如IPv4校驗和）。
我們期望大多數交換設備上的實現將會約束動作的處理，只允許與特定的數據包格式相一致的首部修改操作。
4.6 控制程序
一旦表和動作被定義好，接下來僅剩的任務就是指定從一個錶轉移到下一個表的控制流。控制流作爲一個程序通過一個函數、條件和表的引用組成的集合進行指定。
圖 4-1 mTag例子的控制流程
圖4-1爲邊緣交換機上的mTag實現展示了一個期望的控制流的圖形化表示。在包解析之後，source_check表確認接收到的數據包和入端口是否一致。例如，mTag只應該存在於連接到核心交換機的端口上。source_check也會從數據包中剝去mTag標籤，同時在元數據中記錄數據包是否擁有mTag標籤。流水線中後續的表可能會可能會匹配這個元數據以避免再次往數據包中添加標籤。
local_switching表稍後將會被運行。如果沒有匹配上，就意味着這個數據包的目的地不是連接在同一個交換機上的主機。在這種情況下，mTag_table表（上述定義的）將會用來匹配這個數據包。本地和送往核心層的轉發控制都可以被egress_check表處理。這個表將會在轉發目的地未知的情況下，上送一個通知到SDN控制層。
這一包處理流水線的必要描述如下：
Shell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
control main() { // Verify mTag state and port are consistent table(source_check);
// If no error from source_check, continue if (!defined(metadata.ingress_error)) { // Attempt to switch to end hosts table(local_switching);
if (!defined(metadata.egress_spec)) { // Not a known local host; try mtagging table(mTag_table); }
// Check for unknown egress state or // bad retagging with mTag. table(egress_check); } } |
第五章 編譯P4程序
爲了讓網絡能夠實現我們的P4程序，我們需要編譯器來把目標無關的描述映射到目標交換機的特定硬件或軟件平臺上。完成這個工作涉及分配目標的資源並且爲設備生成合適的配置。
5.1 編譯包解析器
對於有可編程包解析器的設備，編譯器將解析器描述翻譯成解析狀態機。對於固定的解析器，編譯器僅僅確認解析器描述與目標設備的解析器是一致的。生成一個狀態機的細節和有關狀態表項的細節，可以在[16]中找到。
表5-1展示了上述解析器（§4.3）中vlan和mTag部分的狀態表項。每一條表項指明瞭當前的狀態、用於匹配的區域的值以及即將跳轉的下一狀態。爲了展示的簡潔性，其他行被忽略。
表 5-1 mTag例子的解析器狀態表項
|
Current State |
Lookup Value |
Next State |
|
Vlan |
0xaaaa |
mTag |
|
Vlan |
0x800 |
ipv4 |
|
Vlan |
* |
stop |
|
mTag |
0x800 |
ipv4 |
|
mTag |
* |
stop |
5.2 編譯控制程序
§4.6中必要的控制流描述是一種方便的指定交換機的邏輯轉發行爲的方法，但它不能明確地表示出表之間的依賴和併發執行的機會。因此我們部署一個編譯器來分析控制程序，幫助我們識別依賴以及尋找能夠併發處理首部區域的機會。最終，編譯器爲交換設備生成目標配置。目標設備有很多種可能，例如軟件交換機[17]、多核軟件交換機[18]、NPU[19]、固定功能的交換機[20]，或是可重配置的匹配表（RMT）流水線[2]。
正如§3中所討論的，編譯器遵循兩階段的編譯過程。它首先把P4控制程序轉換成TDG表依賴圖描述這樣的一箇中間結果，編譯器分析這個描述以查明表之間的依賴。針對特定目標設備的第二步將會把這個依賴圖映射到交換設備的特定資源上。
我們簡單地梳理一下mTag這個例子將如何被映射到不同種類的交換設備中：
1.軟件交換機：
軟件交換機提供了完整的靈活性：表的數量、表的配置和解析都是在軟件的控制之下。編譯器直接將mTag表圖映射到交換機的表中。編譯器使用表類型信息來限制表的寬度、長度和每張表的匹配準則（例如精確匹配，範圍匹配或通配符匹配）。編譯器也可能通過軟件數據結構來優化三重匹配或者前綴匹配。
2.內含RAM和TCAM的硬件交換機：
編譯器可以配置哈希散列，使用RAM來對邊緣交換機的mTag_table表執行有效的精確匹配。而核心層的mTag轉發表是要匹配標籤比特位的一個子集，它將被映射到TCAM中去執行匹配。
3.支持並行的規則表的交換機：
編譯器能夠檢測數據依賴，然後安排各個表是串行執行還是並行執行。在mTag例子中，mTag_table表和local_switching表可以並行執行直到設置mTag動作的執行。
4.在流水線的末端才執行動作的交換機：
對於只在流水線的末端才執行動作的交換機。編譯器可以告訴中間的步驟生成元數據，在最終的執行中使用。在mTag例子中，無論是mTag標籤的添加還是移除，都能在元數據中表現出來。
5.只能容納少量表的交換機：
編譯器可以將大量的P4表映射到較少量的物理表中。在mTag例子中，本地交換表可以與mTag表結合起來。當控制器在運行時安裝了新的規則，編譯器的規則翻譯器可以將原本應寫入兩個P4表中的規則重新編寫，生成在單個物理表中的規則。
第六章 總結
SDN的願望是單個控制平面可以直接控制整個交換設備網絡。OpenFlow通過提供單一的廠商無依賴的API來支持這個目標。儘管如此，目前的OpenFlow面向的是那些認識預定義的首部區域集合、使用小的預定義動作集來處理數據包的固定功能的交換機。控制平面不能夠表達數據包應該如何被處理以最佳地匹配控制應用的需求。
我們所提出的，是向更靈活的交換設備邁進的一步。這些設備的功能在領域中是特定的，也可能是可變的。開發者決定轉發平面如何處理數據包，同時不用擔心底層的實現細節是否支持。編譯器將一個命令程序轉換成TDG表依賴圖，這張圖可以被映射到許多特定的目標交換設備上，包括優化了的硬件實現。
我們強調，這僅僅只是第一步，這是一個爲OpenFlow 2.0而設計的草案協議，供大家討論。在這個提案中，交換設備仍有幾個方面有待定義（例如擁塞控制原語、排隊策略、流量監控）。儘管如此，我們相信創造一門配置語言的這種方法，將會引領我們實現具有更強靈活性的未來交換設備，也將會釋放軟件定義網絡的潛能。
參考文獻
[1] C. Kozanitis, J. Huber, S. Singh, and G. Varghese, “Leaping multiple headers in a single bound: Wire-speed parsing using the Kangaroo system,” in IEEE INFOCOM, pp. 830–838, 2010.
[2] P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McKeown, M. Izzard, F. Mujica, and M. Horowitz, “Forwarding metamorphosis: Fast programmable match-action processing in hardware for SDN,” in ACM SIGCOMM, 2013.
[3] “Intel Ethernet Switch Silicon FM6000.” http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ethernet-switchfm6000-sdn-paper.pdf.
[4] N. Yadav and D. Cohn, “OpenFlow Primitive Set.”http://goo.gl/6qwbg, July 2011.
[5] H. Song, “Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane,” in SIGCOMM HotSDN Workshop, Aug. 2013.
[6] “Openflow forwarding abstractions working group charter.” http://goo.gl/TtLtw0, Apr. 2013.
[7] M. Raju, A. Wundsam, and M. Yu, “NOSIX: A lightweight portability layer for the SDN OS,” ACM SIGCOMM Computer Communications Review, 2014.
[8] V. Jeyakumar, M. Alizadeh, C. Kim, and D. Mazieres, “Tiny packet programs for low-latency network control and monitoring,” in ACM SIGCOMM HotNets Workshop, Nov. 2013.
[9] A. Sivaraman, K. Winstein, S. Subramanian, and H. Balakrishnan, “No silver bullet: Extending SDN to the data plane,” in ACM SIGCOMM HotNets Workshop, Nov. 2013.
[10] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “The Click modular router,” ACM Transactions on Computer Systems, vol. 18, pp. 263–297, Aug. 2000.
[11] “Multiprotocol Label Switching Charter.” http://datatracker.ietf.org/wg/mpls/charter/.
[12] R. Niranjan Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri, S. Radhakrishnan, V. Subramanya, and A. Vahdat, “PortLand: A scalable fault-tolerant layer 2 data center network fabric,” in ACM SIGCOMM, pp. 39–50, Aug. 2009.
[13] P. McCann and S. Chandra, “PacketTypes: Abstract specificationa of network protocol messages,” in ACM SIGCOMM, pp. 321–333, Aug. 2000.
[14] G. Back, “DataScript - A specification and scripting language for binary data,” in Generative Programming and Component Engineering, vol. 2487, pp. 66–77, Lecture Notes in Computer Science, 2002.
[15] K. Fisher and R. Gruber, “PADS: A domain specific language for processing ad hoc data,” in ACM Conference on Programming Language Design and Implementation, pp. 295–304, June 2005.
[16] G. Gibb, G. Varghese, M. Horowitz, and N. McKeown, “Design principles for packet parsers,” in ANCS, pp. 13–24, 2013.
[17] “Open vSwitch website.” http://www.openvswitch.org.
[18] D. Zhou, B. Fan, H. Lim, M. Kaminsky, and D. G. Andersen, “Scalable, high performance Ethernet forwarding with CuckooSwitch,” in CoNext, pp. 97–108, 2013.
[19] “EZChip 240-Gigabit Network Processor for Carrier Ethernet Applications.” http://www.ezchip.com/p_np5.htm.
[20] “Broadcom BCM56850 Series.” https://www.broadcom.com/products/Switching/Data-Center/BCM56850-Series.