摘要——P4程序極大程度上的擴展了網絡的可編程性，但同時也增加了產生運行時故障的風險。如果不能迅速並恰當的處理這些運行時的故障，可能會對網絡的功能和性能造成極大的破壞。然而，目前缺少調試工具，使得對於管理員來說，P4程序的故障檢測顯得非常具有挑戰性並且錯綜複雜。本文致力於對P4的網絡中的運行時錯誤進行即時調試。本文提出了P4DB，這是一個通用的調試平臺，通過提供操作員友好的primitives，授權操作員在三個可見級別調試P4程序。通過P4DB，管理員可以使用watch（primitive）快速將調試範圍從網絡級別或設備級別縮小到table級別，然後使用break和next（primitive）將match-action table分解爲三個步驟，並逐步解決運行時錯誤。本文實現了P4DB原型，並根據數據平面，控制平面和控制通道評估了它的性能。在P4可編程數據平面上，P4DB只帶來了（1.3％〜13.8％）的吞吐量損失，並且僅僅增加了（0.6％〜11.9％）的延遲。
1 緒論
P4[1]是最近提出來的一門domain-specific的語言，它使得管理員能夠自己定義一個可編程數據平面的行爲。它把定製協議的實現與交換機底層代碼解耦合，從而允許管理員對網絡協議進行自由的創新。
爲了支持新的協議格式和操作，P4使管理員能夠在P4程序中定義各種可編程元素（element）。 管理員可以定製解析器（parser）來提取符合特定協議格式的頭部字段。在匹配動作表（MAT）中，管理員可以定義匹配字段和允許的複合動作（compound action）以及原子動作（primitive action）。此外，管理員還可以在控制流（control flow）中將多個MAT組織成一個複雜的有向無環圖（DAG）。並且，管理員可以聲明一些數據平面的變量，比如metadata，registers來執行復雜的協議操作。在運行時（例如...當交換機轉發數據包時）控制器可以管理MAT中的table entries。許多近期的研究工作[2][3]表明，P4可以極大程度地加速網絡協議和功能的創新。
但是，由於可操作的編程元素太多，P4程序與人類開發的所有其他軟件一樣，不可避免地容易出錯。這些錯誤可以主要分爲兩種類型。 一種是編譯時錯誤，可以在編譯時檢測到。另一種是在編譯時無法檢測到的運行時錯誤，它可能會在將程序部署到設備後導致各種各樣的錯誤行爲。本文專注於調試P4程序的運行時錯誤。
調試P4程序的運行時錯誤是一項相當困難的任務，並且面臨着以下挑戰：
Diversity（多樣性）。運行時錯誤可能發生在不同類型的任何可編程元素上。 例如，當定義predication表達式（例如...if-else語句）時，管理員可能將錯誤的metadata（元數據）誤認爲是正確的，在定義控制流程中出現邏輯錯誤等等。相應地，這些錯誤會在運行時造成各種各樣的錯誤行爲，例如格式錯誤的數據包，數據包丟失，數據包循環等。
Complexity（複雜性）。隨着P4程序的規模不斷擴大，管理員可能會因運行時錯誤故障排除的複雜性而不堪重負。拿gitHub 上的P4 repository[4]裏的switch.p4來舉個例子：switch.p4 包含了10K行代碼，129個MAT，76個predication expressions，以及340個符合動作。因此，當管理員想要找出數據包未按預期轉發的原因時，他必須轉儲MAT中的所有表條目並逐個排除和推斷錯誤。switch.p4中引用的動態metadata（元數據）更是進一步增加了故障檢測的複雜性。
Invisibility （不可視性）。在P4程序中，大多數可編程元素（如元數據，控制流，原子動作等）在運行時對管理員不可見，但卻對調試至關重要。例如，一旦將程序部署到設備上，控制流定義的邏輯，如“hard-coded logic”，就不能被管理員觀察到。因此，管理員不能直接看到數據包的MAT路徑（不同MAT之間數據包的蹤跡）。 可編程elements的這種不可見性必然加劇了在運行時調試程序的難度。
因此，隨着PDP的蓬勃發展，調試運行時錯誤正成爲一項複雜而富有挑戰性的任務。 但是，現有的調試工具主要專用於基於OpenFlow[5]的SDN，不能簡單地移植到P4網絡中來處理運行時的錯誤。其中一些是爲控制平面而設計的，由於它們無法驗證數據平面行爲，因此超出了本文的範圍。 其他的是爲數據平面設計的，可以分爲兩種類型：
（1）首先，諸如[6]，[7]，[8]，[9]，[10]，[11]等的調試工具基於運行時監測技術。它們僅僅關注流表項而不考慮其他可編程元素。而且因爲需要對數據平面進行監測，也產生了很大的性能方面的開銷。
（2）其他調試工具如[12]，[13]，[14]，[15]，[16]都基於靜態分析技術。由於靜態分析的侷限性，如果不對它們內部進行重新編程，它們無法自適應地對轉發行爲的變化建模。 它們通常將數據平面模型作爲輸入來生成探測數據包或模擬基線。因此，他們無法檢測到P4程序中的錯誤，並會導致假陽性的問題。
調試PDP是一個相當新的話題。 據我們所知，P4領域現有兩種調試工具。 但是，它們都不能用於解決運行時錯誤。文章[17]提出了一種靜態分析工具來驗證數據包的可達性和成形性。 但是，由於靜態分析的限制，此工具不能用於解決運行時錯誤。此外，BMv2項目中的軟件調試器用於查找開發階段的錯誤。 但是，保證仿真環境的正確性不能保證部署後的正確性。
本文介紹了一個通用調試平臺P4DB，它在設計上有以下三個創新點，以解決上述挑戰。
（1）debugging primitives（調試原語）爲管理員提供簡單易用的接口，簡化調試工作流程（complexity）。因此，管理員可以避免轉儲MAT中的所有表項並逐一排查錯誤。這些調試原語包括attach，detach，watch，break，next等。
（2）debugging snippets（調試片段）旨在反饋數據平面上各個可編程元素的狀態（Diversity＆Invisibility）並實現調試原語。本質上，調試片段是數據平面上的代碼段，可以靈活地插入P4程序中的某個特定位置，並在運行時向P4DB報告用戶感興趣的狀態。
（3）three-step decomposition，將MAT與其predication expression等效地分解爲預測步驟（predication step），匹配步驟（match step）和動作步驟(action step)（Diversity & Invisibility）三個步驟。 因此，管理員可以使用break和next原語以單步方式詳細檢查MAT的執行情況。
通過P4DB，管理員可以在三個不同級別的可見度下靈活地審查P4程序。
（1）網絡級可視性爲管理員提供指定流的網絡路徑。
（2）設備級可見性爲管理員提供運行時的P4程序中指定流的MAT路徑。
（3）表級可見性使管理員能夠在分解的MAT中一步一步看到數據包的處理。
因此，如圖1所示，在調試P4程序時，管理員可以使用watch原語將調試範圍從網絡級別快速縮小到某個特定的表級別。 然後可以使用break和next原語來分解一個MAT，並在運行時詳細觀察數據包的處理過程。
圖1：用P4DB調試一個PDP程序
本文的貢獻如下：
（1）就我們所知，P4DB是第一個用於解決P4網絡中的運行時錯誤的即時調試平臺。 我們通過一個真實世界的例子來證明P4DB的可行性和可用性。
（2）在P4DB中，我們提出了三個創新點，以（i）便於排除各種運行時錯誤，（ii）簡化調試工作流程，以及（iii）提供不同級別的可見性。
（3） 我們基於最近提出的兩個PDP實現了一個P4DB原型：P4專用PDP和虛擬層專用PDP。 我們對P4DB進行了全面評估。 結果表明，P4DB只需要很小的性能開銷。
2 相關工作
在撰寫本文時，很少有研究關注調試P4程序。在一篇技術報告[17]中，作者提出了一種可將P4編譯爲Datalog的靜態分析工具，以便在P4程序發生變化時自動更新此驗證模型。但是，由於靜態分析的限制，該工具無法處理運行時錯誤。 另外，如上所述，該工具也以P4程序爲輸入，不能解決假陽性問題。 相比之下，P4DB在運行時爲管理員提供了數據平面狀態的完整可見性，並且不只是針對任何特定類型的運行時錯誤。
BMv2 [4]中提供的軟件調試器使管理員可以在開發階段調試P4程序。 但是，此工具僅在開發階段提供粗粒度驗證，並且無法在部署後處理運行時錯誤。
如前所述，其他調試工具被提出用於在基於OpenFlow的SDN中調試數據平面，但是對於P4網絡不可行。 由於篇幅原因，我們只討論如下最相關的研究。
ndb [6]及其後繼者NetSight [7]似乎與P4DB提供交互式調試命令類似的想法。 例如，ndb提供了斷點原語。 然而，據作者說，斷點本質上是一個跟我們的watch原語類似的追蹤點。 保持斷點術語的原因是爲了保持對程序調試的熟悉程度。 相反，P4DB中的break原語關注MAT的行爲而不是數據包，並創新性地將MAT分解爲三個連續的步驟。 此外，P4DB還使得管理員能夠在中斷片段（break snippet）被觸發後以單步方式使用next原語來調試MAT。
此外，即使將ndb和NetSight中使用的流量壓縮技術考慮在內，他們仍然承受着爲數據平面上的每個數據包生成postcard流量的大量開銷。 而且他們還需要修改數據平面來實現調試器。 與ndb和NetSight相比，P4DB利用數據平面damper來有效抑制報告流量，並且不需要修改PDP的實施。來有效抑制報告流量，並且不需要修改PDP的實施。來有效抑制報告流量，並且不需要修改PDP的實現。
3 overview概覽
3.1 P4DB的設計理念
大多數錯誤都是由程序源代碼或其設計中的問題引起的。 因此，最有效的調試方法是讓程序員直接找到並查看正在發生的事情。在操作系統中，程序員可以將應用程序的源代碼加載到調試器（如gdb）中，然後將斷點插入源代碼並直接檢查運行時發生了什麼。在內部，一小段“trap code”將執行主體從程序切換到調試器，由gdb動態插入到程序中。
P4DB與操作系統中的gdb共享類似的基本思想。 雖然沒有陷阱指令可以讓管理員停止執行P4程序，但是在P4DB中，稱爲“調試片段”的“報告代碼”片段旨在報告可編程元素的狀態。實際上，一個調試片段是MAT的簡單DAG，用於報告用戶感興趣的流的數據平面狀態。此外，可以使用不同的調試片段組合來爲管理員實現用戶友好的debugging primitives（調試原語）。因此，操作員可以加載P4程序，使用調試原語將調試片段動態嵌入到程序中，並在運行時調試程序。這種使用調試片段來實現調試原語的方式使P4DB成爲一個通用的調試平臺，它可以用在基於RMT [18]和dRMT [19]等在內的各種MAT體系結構。
3.2 P4DB的普適性
首先，我們將說明最近提出的兩個PDP以及它們的優缺點。其次，我們將介紹基於各種PDP的P4DB可以使用的功能。
（1）The P4-specific PDP： P4-specific PDP是最廣泛採用的並且是定義PDP的先驅者。 在P4-specific PDP中，P4程序中使用的語言模型與硬件設備上的實現模型密切相關。因此，P4程序可以充分受益於硬件設備的高性能，而無需任何模型轉換的開銷[20]。但是，高級程序與低級硬件設備之間的緊密耦合也會導致每次操作員更改P4程序時，硬件設備的中斷和重新配置都是不可避免的。
（2）The Hypervisor-specific PDP：最近，hypervisor [21]和MPVisor [22]等Hypervisor-specific PDP提議通過在中間添加一層輕量級hypervisor來解耦高級P4程序和低級硬件設備。通過這種方式，雖然由於額外的hypervisor開銷，但可以在不中斷硬件設備的情況下修改P4程序。
（3）各種PDP上的特性：P4-specific PDP和Hypervisor-specific PDP都有各自的優點和缺點，除了可編程元素的通用可編程性外，還展示了其獨特功能。
因此，P4DB是設計爲一個普適的調試平臺，通過利用各種PDP提供的通用可編程性來呈現一般化的調試功能。同時，P4DB在用於調試特定的PDP時，還將各種PDP的獨特功能作爲特殊的調試功能。例如，基於Hypervisor-specific PDP，P4DB可以受益於不中斷的特性，同時還會受到模型轉換的性能開銷的影響。相反，基於P4特定PDP，P4DB提供高性能和語言兼容性，但面臨數據平面的中斷。 在4-F中將描述各種PDP的實現細節。
4 P4DB的設計
A. 系統架構
圖2展示了P4DB的體系結構。這個自動調試工具和命令行接口（CLI）調試工具是基於調試平臺提供的調試原語開發的。在本文中，我們將說明P4DB中的默認CLI調試工具。調試原語在內部由不同的調試片段組成實現。PDP程序管理器維護所有P4程序的狀態以及它們的運行實例。設備的重新配置將觸發PDP程序管理器重新編譯相應的P4程序。PDP模型管理器維護特定PDP模型和相應硬件設備的映射。調試消息服務維護數據平面調試片段與調試平臺之間的控制通道。
圖2：P4DB的架構
B. MAT的三步分解
在P4DB中，我們將一個MAT分解爲三個連續的步驟：predication step, match step 和 action step. prediction step（由兩個MAT實現）在功能上等同於control flow中約束MAT的if-else語句。類似地，match step（由一個MAT實現）將僅執行原始MAT的匹配邏輯而不執行任何動作。action step將僅執行action邏輯。
基於這種分解，P4DB可以在每個相應的分解步驟之後插入predication snippet, match snippet 以及 action snippet；由debugging snippet收集數據平面的狀態；分別顯示每個步驟的數據平面狀態。因此，操作員可以有序地使用三個next原語來驗證每個步驟的正確性。本文在5-F節將討論不同PDP模型的分解實現。
（1）爲什麼需要分解？MAT分解的原因相當簡單。 目前，預測邏輯，像MAT之間的“硬編碼邏輯”一樣被編譯，對於管理員而言是不可見的。 因此，及時predication是的編程是錯誤的，除了手動推斷數據包行爲外，沒有方便的方法來識別錯誤。
至於匹配和動作，它們緊密結合並隱藏在一個MAT中。 因此，管理員只能審查MAT的結果而不是行爲本身。在現實世界的調試案例中，知道（i）這個數據包匹配哪些字段，以及（ii）這個數據包執行哪些動作和參數，對於操作員排除MAT中的錯誤非常重要。因此，P4DB將MAT分解爲三個步驟，使管理員能夠直接看到哪些行爲應用於MAT中的哪個數據包。
（2）單步調試的模擬：實際上，雖然一個MAT可以分解爲三個步驟，但P4DB不能暫停對數據包的操作，然後逐個分解步驟。因此在P4DB中，我們設計了一個模擬的方式。我們的設計雖然是模擬的，但是合理的。P4DB的根本目的是讓管理員看到運行時出了什麼問題。在操作系統中，程序員只有在錯誤被觸發後才能看到錯誤的發生。
但是，在網絡系統中，P4程序中的錯誤再次發生可能由同一流程中的數百萬個數據包觸發。 換句話說，爲了觀察發生了什麼，不需要只跟隨一個數據包的執行。相反，P4DB專注於P4程序本身，並將數據包視爲錯誤的觸發器。只要同一個流中的一致數據包可以觸發該錯誤，P4DB就可以爲操作員提供模擬的單步調試。我們將在第7部分討論錯誤復發的可行性。
C. 調試原語Debugging Primitives
如圖3所示，我們設計了一套用戶友好的調試原語，以便管理員可以使用這些原語通過CLI以交互方式調試P4程序。調試原語通過調試片段的各種組合來實現。目前，有七個基本的基本原語; 然而，隨着調試片段的開發，將會有更多的調試原語來減少調試成本。
圖三：調試原語
attach 和detach原語可以在一些特定設備上動態地將調試器附加到/分離P4程序的實例。一個程序只能通過一個CLI進行調試，儘管操作員可以同時打開多個CLI來調試不同的程序。當管理員發出attach命令時，P4DB將加載P4程序的源代碼; 分析源代碼; 檢查硬件設備上的特定PDP模型並準備調試環境。
watch原語爲管理員提供了兩個不同級別的可視性。 一個是網絡級可見性，它將顯示指定流的網絡路徑。 另一個是設備級可見性，它將顯示指定流的MAT路徑。 在內部，P4DB會在交換機或所有交換機中插入一些watch片段，收集報告並顯示流量軌跡。
break和next基元一起使管理員能夠在表級可視性調試一個MAT。當管理員發出中斷原語時，P4DB內部分解MAT並插入中斷片段。一旦break片斷被指定的流程觸發，管理員可以發出next 原語來讓P4DB動態地將predication snippet安裝到分解的MAT中。然後管理員可以觀察predication的狀態。 之後，兩個next原語將分別安裝到match片段和action片段，並呈現匹配步驟和動作步驟的狀態。諸如rmbp和show之類的其他原始語言也很容易被完全描述。
D. 調試片段Debugging Snippets
（1）Debugging Snippets的設計：調試片段，通常由一個或多個MAT組成，匹配管理員指定的數據包流並將可編程元素的狀態報告給調試平臺。調試片段中的匹配規則由P4DB基於調試原語中的參數實例化。調試片段中的操作是根據調試片段的類型報告不同的可編程元素。一旦調試片段部署在數據平面上，它將與流量匹配，並使用生成摘要動作將報告流量發送到調試平臺。目前，有五種類型的調試片段。
Watch Snippet：Watch Snippet由一個MAT實現。Watch Snippet中的匹配規則根據watch原語中的參數設置。Watch Snippet中的動作設置爲報告兩種信息，其中包括（i）table entry, 通過該平臺可以區分不同的指定流；（ii）Watch Snippet的標識符，調試平臺通過它可以識別Watch Snippet的位置。
如圖4所示，當管理員使用watch原語觀察流量A和流量B。P4DB將爲每個MAT安裝一個Watch Snippet。如果兩個流都存在，那麼Watch Snippet會將流跟蹤報告給調試平臺。
圖4：watch snippets的設計
Break Snippet： Break Snippet和predication snippe，match snippet 和 action snippet，使管理員能夠以細粒度的方式調試MAT，如圖5所示。當管理員對一個MAT發出break原語時，P4DB將分解MAT並安裝Break Snippet。Break Snippet由一個MAT實現，並在指定流觸發時向調試平臺報告數據平面狀態，包括數據包頭，元數據等。
圖5：snippet的設計
Predication Snippet：predication step 和 match step之間的Predication Snippet由一個MAT實現以報告predication expression中引用的可編程元素。如果原始MAT沒有任何predication expression，則predication步驟將不做任何事情，而是將該流傳遞給match步驟。值得注意的是，指定的流將首先在Predication步驟中匹配，然後傳遞到 Predication Snippet，而正常流不會傳遞到Predication Snippet。在CLI中，P4DB提供了predication expression以及參考變量的值。因此，管理員可以檢查predication中的布爾表達式是否正確。
Match Snippet：由一個MAT實現的Match Snippet在匹配步驟中報告指定流的匹配字段和值。 通過Match Snippet，管理員可以檢查指定流程匹配哪個表項，並驗證匹配規則的正確性。 Match Snippet也僅處理指定調試的流。
Action Snippet：由一個MAT實現的Action Snippet向調試平臺報告數據包包頭，動作和動作參數。 通過Action Snippet，管理員可以驗證指定流是否按預期正確執行。 值得注意的是，Action 步驟將處理指定的流並將流傳遞給Action Snippet。 然後在Action Snippet中，指定的流程將觸發Action Snippet，以報告在Action步驟中採取了哪些動作和參數。 當P4DB安裝Action Snippet時，Action Snippet中的匹配規則和動作將被實例化。
（2）Debugging Snippets的管理：P4DB採用兩種方式來管理（安裝/刪除）調試片段。 一種是按需方式，另一種是主動方式。兩種實施都有其優點和缺點。 至於按需的方式，P4DB將不會安裝調試片段，直到操作員發出相應的調試原語，並在操作員發出另一個調試原語後刪除調試片段。例如，P4DB將刪除Predication Snippet並僅在管理員發出第二個next原語後安裝匹配片段。在P4DB中，以這種方式設計break snippet, predication snippet, match snippet and action snippet。這樣可以保證調試snippets始終由最新的的流量觸發，並實時顯示數據平面上的狀態。此外，這種方式也會減小性能開銷，因爲它不需要在P4程序中安裝所有相關的調試代碼片段。
至於主動的方式，一旦管理員發出調試原語，P4DB將安裝所有相關的debugging snippets。watch snippet以這種方式設計。當管理員發出watch原語時，P4DB將爲P4程序中的每個MAT安裝watch snippet。這種方式可能會因爲數據平面上運行的多個調試片段而增大性能開銷。 但是，如果指定的流太短而不能連續地調試，它可以收集更多的數據平面狀態。
E. 性能優化
網絡中，可能每秒鐘有數以百萬計的數據包通過數據平面。即使P4DB通過使用數據平面的調試片段爲管理員提供實時調試能力，但是如何降低性能開銷仍然是一項重要任務。實際上，調試片段的目的是（i）過濾指定的流和（ii）發送報告流量。因此，我們提出兩種設計來分別降低過濾和報告方面的性能開銷。
（1）過濾的放置：過濾的位置將直接影響數據平面的性能。在P4DB中，考慮到不同調試片段的折衷，採用兩種放置方式。
一種是將指定流的過濾規則放置在調試片段之外，例如，可以將過濾規則放置在匹配步驟中，然後匹配步驟將過濾指定流並將所選流傳遞給匹配片段。這樣，只有選定的流將傳遞到調試片段，而其他正常流量將繞過調試片段。從圖5中，我們可以看到預測片段，匹配片段和動作片段採用這種方式。 這種放置方式可以有效地降低性能開銷，但它在表達過濾規則方面存在限制。 因爲它要求被調試的流可以被調試片段之外的MAT完全匹配。
另一種方法是將過濾規則放置在調試代碼片段中，並使用調試片段本身來過濾指定的流。 這樣，所有流量，無論是否正在調試，都將通過調試代碼段和原始過程。 如圖4和圖5所示，watch snippet和break snippet採用這種實現方式。 儘管這種實現方式可能會爲過濾帶來額外的開銷，但它爲定製各種調試流的匹配規則提供了更大的靈活性。
（2）報告流量的message dapper：
F. 在不同的PDP上的實現
5 評估
6 可行性討論
7 結論
本文首次致力於在P4的網絡中對運行時錯誤進行即時調試。P4DB作爲一個通用的調試平臺，使管理員能夠以簡單和可見性調試各種運行時錯誤。在P4DB中，我們提出了三個創新點，包括（i）調試原語，（ii）調試片段，以及（iii）MAT的三步分解。評估結果表明，P4DB使管理員能夠解決P4網絡中的運行時錯誤，並且只會導致很小的性能開銷。 在未來的工作中，我們計劃豐富一系列調試原語並開發基於P4DB調試平臺的自動調試應用程序。
[1] Pat Bosshart and et al. P4: Programming protocol-independent packet processors. SIGCOMM Comput. Commun. Rev., 44(3):87–95, July 2014.
[2] Mojgan Ghasemi and et al. Dapper: Data plane performance diagnosis of tcp. In Proceedings of the Symposium on SDN Research, SOSR ’17, pages 61–74, New York, NY, USA, 2017. ACM. [3] Vibhaalakshmi Sivaraman and et al. Heavy-hitter detection entirely in the data plane. In Proceedings of the Symposium on SDN Research,SOSR ’17, pages 164–176, New York, NY, USA, 2017. ACM.
[4] Barefoot Networks. P4-bmv2. Website. https://github.com/p4lang/behavioral-model.
[5] Nick McKeown and et al. Openflow: Enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74, March 2008.
[6] Nikhil Handigol and et al. Where is the debugger for my software defined network? In Proceedings of the First Workshop on Hot Topics in Software Defined Networks, HotSDN ’12, pages 55–60, New York, NY, USA, 2012. ACM.
[7] Nikhil Handigol and et al. I know what your packet did last hop: Using packet histories to troubleshoot networks. In Proceedings of the 11th USENIX Conference on Networked Systems Design and Implementation, NSDI'14, pages 71–85, Berkeley, CA, USA, 2014. USENIX.
[8] Ramakrishnan Durairajan and et al. Controller-agnostic sdn debugging. In Proceedings of the 10th ACM International on Conference on Emerging Networking Experiments and Technologies, CoNEXT ’14, pages 227–234, New York, NY, USA, 2014. ACM.
[9] Peng Zhang and et al. Mind the gap: Monitoring the control-data plane consistency in software defined networks. In Proceedings of the 12th International on Conference on Emerging Networking EXperiments and Technologies, CoNEXT ’16, pages 19–33, NY, USA, 2016. ACM.
[10] Q. Zhi and et al. Med: The monitor-emulator-debugger for software defined networks. In IEEE INFOCOM 2016 - The 35th Annual IEEE International Conference on Computer Communications, pages 1–9, April 2016.
[11] Andreas Wundsam and et al. Ofrewind: Enabling record and replay troubleshooting for networks. In Proceedings of the 2011 USENIX Conference on USENIX Annual Technical Conference, USENIXATC’11, pages 29–29, Berkeley, CA, USA, 2011. USENIX Association.
[12] Hongyi Zeng and et al. Automatic test packet generation. IEEE/ACM Trans. Netw., 22(2):554–566, April 2014.
[13] Haohui Mai and et al. Debugging the data plane with anteater. In Proceedings of the ACM SIGCOMM 2011 Conference, SIGCOMM ’11, pages 290–301, New York, NY, USA, 2011. ACM.
[14] Peyman Kazemian and et al. Header space analysis: Static checking for networks. In Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation, NSDI’12, pages 9–9, Berkeley,
CA, USA, 2012. USENIX Association.
[15] K. Bu and et al. Is every flow on the right track?: Inspect sdn forwarding with rulescope. In IEEE INFOCOM 2016 - The 35th Annual IEEE International Conference on Computer Communications, pages 1–9,
April 2016.
[16] Peter Pereˇs´ıni and et al. Monocle: Dynamic, fine-grained data plane monitoring. In Proceedings of the 11th ACM Conference on Emerging Networking Experiments and Technologies, CoNEXT ’15, pages 32:1– 32:13, New York, NY, USA, 2015. ACM.
[17] Nick McKeown and et al. Automatically verifying reachability and wellformedness in p4 networks. Technical report, September 2016.
[18] Pat Bosshart and et al. Forwarding metamorphosis: Fast programmable match-action processing in hardware for sdn. In Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM, SIGCOMM ’13, pages 99– 110, New York, NY, USA, 2013. ACM.
[19] Sharad Chole and et al. drmt: Disaggregated programmable switching. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, SIGCOMM ’17, pages 1–14, New York, NY, USA, 2017. ACM.
[20] Barefoot Networks. Barefoot tofino. Website. https://barefootnetworks.com/technology/.