摘要——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/.