《可编程数据平面：抽象、架构、算法与应用》是TechRxiv上一篇关于网络数据面编程的一篇综述性文章，内容非常全面详实。本译文有删改。

原始论文链接如下：https://doi.org/10.36227/techrxiv.12894677.v1
快速链接：

6 应用

当前，有一种趋势是将某些通用的信息处理功能转移到网络数据平面，这些功能以前要么完全在主机软件中实现，要么在专用的硬件设备中实现。可编程网络设备突然改变了一个dumb管道，该管道只将数据移动到一个完整的、复杂的数据处理流水线，能够在网络内以前所未有的速度转换数据。以这种方式卸载到网络上的应用包括监测和遥测、大规模数据处理和机器学习，甚至完整的键值存储。网络设备已经位于数据路径中，因此在这里卸载额外的功能可以最小化额外的、代价高昂的数据移动需求，并减少端到端处理延迟。此外，许多应用程序可能受益于网络的新可见性(例如，队列占用水平)，或通过在低功耗可编程网卡上运行传统计算任务来节省能源[127]。

人们可能想知道哪种类型的应用程序可以从可编程数据平面中获益最多[172]。是否有一个全面的方案来帮助确定何时考虑特定用例的数据平面实现？从最近的例子来看，我们看到典型的应用程序是这样的：

处理大量的网络绑定数据，或者在某种程度上需要强大网络的组件(例如，实现请求-响应模式)；
具有严格的延迟和/或吞吐量要求；
可以分解成一组简单的原语，这些原语很容易部分或全部在底层可编程数据平面设备公开的包处理原语之上实现。

一个典型的例子是测量/遥测应用，它允许运营商以线速检查通过网络的流量。今天，遥测主要发生在“网络之外”，例如，通过将通信流镜像到一个单独的中间件，提高了重要的性能和资源消耗问题。通过观察发现，许多测量任务可以简单的表示为Sketch,可以在可编程交换机实现在“网络内部”,导致在速度、延迟和资源消耗为代价的最小损失精度得到数量级的改善(83、187)。

下面，我们从文献中突出一些众所周知的数据平面卸载的例子，包括虚拟交换、网络内计算、遥测、分布式共识、弹性和高效转发，以及负载平衡。

6.1 监控、遥测和测量

数据平面卸载最有趣的应用可能与网络测量、遥测、监测和诊断有关。这是因为这些应用程序具有最适合基于数据平面的实现的所有特征，即庞大的流量规模和严格的性能要求。此外，一些应用程序可以使用在交换机中有效实现的Sketch来实现。当前最先进的技术包括将被监控的流量镜像到专用的代理服务器，涉及到将所有感兴趣的流量复制到外部链路的昂贵复制；因此，数据平面实现的效率增益是巨大的。在这种情况下，可编程数据平面可以成为游戏规则的改变者，提供对网络的深刻见解，甚至对终端主机，我们将在下面的讨论中讨论。

许多方法的核心在于提高网络行为的可见性。Jeyakumar等人[90]提出了一种解决方案，该方案不仅提高了终端主机的可见性，而且允许通过一个新的小数据包程序(TTP)接口快速引入新的数据平面功能。基于主动网络范式[57]的智能数据包研究[174]，最初提出用于交换机内网络管理和监控，终端主机将TTP嵌入到数据包中，可以主动查询和操作内部网络状态。该方法基于“分工”原则：交换机以线速在带内转发并执行TTP，终端主机对TTP暴露的网络状态进行灵活计算。作者还提出了一些促进带内网络遥测的用例描述。Kim等人在[107]中提出了带内网络遥测(INT)的总体框架。

作为向广义测量迈出的一步，工作的一个方向已经将Sketch视为网络分析的一个新的数据平面结构。利用概率、次线性数据结构的Sketch，是在大型输入数据集[12]上维持汇总统计和度量的有效方法。OpenSketch[205]提供了这样一个Sketch库，而UnivMon[130]引入了一个通用流方案，其中硬件中的一个通用Sketch以高速率预处理包记录，软件应用程序计算特定于应用程序的度量。最近，SketchVisor[83]提出了一个综合的网络测量框架，该框架在数据平面上用一条高流量负载下激活的快速路径来增强基于Sketch的测量，从而提供精度略有下降的高性能局部测量。

为了使网络监测系统更加灵活，研究人员已经寻找方法，支持网络运营商以更有表现力的方式直接编写网络测量查询，而不是依赖于特定的Sketch。然后可以编译这些查询，使其在可编程交换机上以线速运行。Marple[149]确定了一组固定的操作符，这些操作符可以编译成可编程硬件，并用于组成广泛的网络监控查询。这种方法为任何可以完全适应PFE的分析任务提供了出色的性能，但它也需要在设备的SRAM和ALU资源满时软件卸载。Sonata[75]改进了这种硬件限制模型，更智能地将查询划分为在PFE上执行的部分和在通用软件流处理器上执行的部分。由于软件流处理系统的处理能力有限，Sonata引入了一种迭代优化的方法，可以减少发送到软件的流量。然而，这种迭代的改进是以在交换机上使用大量SRAM和ALU资源为代价的，而且还需要放松查询的时间和逻辑约束。

网络内测量的进一步应用涉及严重打击检测[164,187]、流量矩阵估计[69]和TCP性能测量[66]。首先，HashPipe[187]完全在数据平面上实现重攻击检测。HashPipe实现了一个哈希表的流水线，它保留大量流的计数器，同时随着时间的推移驱逐较轻的流。其次，Gong等[69]指出，通过设计可行的流量测量规则(安装在SDN交换机的TCAM表项中)并对这些规则进行统计，也可以对流量矩阵进行细粒度估计。最后，Dapper[66]允许实时分析终端主机附近的TCP性能问题，即Hypervisor、网卡或TOR交换机。这使得操作者能够确定特定的连接是否受到发送方、网络或接收方的限制，并及时进行相应的干预。

最后，一项交叉研究发现，尽管由于资源限制，可编程交换机不适合实际和普遍的分析任务卸载，但对于加速和增强遥测系统是有用的。*Flow[188]不是将整个查询编译到一个可编程交换机，而是将所有查询通用的部分选择和分组逻辑放入硬件Match-Action流水线中。在*Flow中，可编程线速交换输出一流分组包向量(GPVs)到软件处理器。GPV包含一个流键值，例如IP五元组，和一个可变长度的数据包特征元组列表，例如时间戳和大小，来自该流中的数据包序列。GPV是通过一种新颖的网络内键值缓存产生的，该缓存可作为可编程交换机的一系列Match-Action表来实现。作者通过定制的高性能网络分析平台扩展了遥测系统[141]。

6.2 虚拟交换

虚拟网络在数据中心和云计算基础设施中被大量使用。云计算的核心是资源共享和多租户的思想：独立实例(例如，应用程序或租户)可以同时利用物理基础设施，包括它们的计算、存储和管理资源[110]。在物理集成的同时，网络虚拟化为每个租户实现了资源的逻辑隔离。虚拟交换机是位于服务器虚拟化层的网络组件，连接租户的计算和存储资源(例如，虚拟机(VM)，存储卷等)，在服务器、数据中心的其余部分和公共互联网[2,88,110]上预配置。

网络虚拟化和多租户通常在与物理服务器/管理程序共存的虚拟交换机上实现(例如，Open vSwitch[160])。使用流表级隔离，虚拟交换机中的流表被划分为每个租户的逻辑数据路径，这些逻辑数据路径填充了足够的流表条目，将租户的资源链接到一个公共的互连工作空间[2,88,110]。这个工作区实际上是一个通过隧道协议实现的overlay网络，例如VXLAN[5]。作为这种基于主机的虚拟交换机模型的替代方案，网络虚拟化的标记包也可以卸载到网卡[60,70]。

尽管虚拟网络的广泛部署[45,60,94]，提供足够的(逻辑和性能)隔离仍然是一个关键的挑战。例如，在[195]中报告了Open vSwitch[160]的严重隔离问题：攻击者不仅可以破坏虚拟机并攻击主机上的所有应用程序，而且还可以表现为蠕虫，并危及整个数据中心。另一个严重的性能隔离漏洞(也存在于OVS中)在[41,42]中被报道，它可以导致低资源的跨租户拒绝服务攻击。此类攻击可能会加剧人们对安全性和采用公共云的担忧[175]。Jin等人[91]首先指出了将虚拟交换机与hypervisor放在一起的安全性弱点，并提出了更强的隔离机制。作为回应，MTS[193]建议在虚拟机中放置每个租户的虚拟交换机，以增强安全性隔离。

6.3 网络内计算

网络内计算通常用于在数据中心实现的大规模机器学习和大数据框架面临的性能瓶颈和可伸缩性限制[7,49]。大数据/机器学习应用，如查询处理、图形处理和深度学习，表现出一种非常特殊的通信模式。首先，在许多这样的应用程序中，输出大小只是输入大小的一小部分，这些应用程序通常在处理过程中大量减少和聚合数据(例如，取输入的总和，或找到最小值)。因此，尽早应用这些函数有助于减少网络通信量和减少拥塞。其次，这些应用程序通常具有简单的算术/逻辑运算，这使得它们适合并行化和在可编程开关上执行。第三，在许多算法中，这些操作也是可交换的和可结合的，这意味着它们可以分别地、以任意顺序应用于输入数据的不同部分，而不会影响最终结果的正确性。

相应地，大多数大数据应用程序遵循Map-Reduce模式来实现大规模水平扩展：大规模计算实例首先被划分到许多边缘服务器上，这些服务器对更小的块进行部分处理，然后再聚合结果以获得最终结果。然而，这种多对少的通信模式在大多数网络设备中都得不到很好的支持，从而在基于数据中心的部署中造成了显著的性能瓶颈。

在边缘服务器上执行数据聚合的第一个尝试是camdop[40]，它支持在直连数据中心Fabric上的Map-Reduce应用程序的路径聚合，所有的流量都在服务器之间转发，而不需要交换机。虽然camdoo显著减少了网络流量并提高了性能，但它需要自定义的网络拓扑结构，并且与常见的数据中心基础设施不兼容。Netagg[134]是一个建议，通过在专用的中间件的网络层内实现路径上聚合来避免camdoo的限制。Netagg在大数据工作负载和框架(包括Apache Hadoop和Apache Solr search)中显著提高了作业完成时间。后来，SHArP[72]从网络计算堆栈中移除专用的“网络加速器”中间件，并提出了一种通用的可编程数据平面硬件架构，以有效减少数据，依赖于可扩展的网络树和流水线来减少数据中心大数据处理的延迟。

Liu等人通过提出他们称为IncBricks的最小抽象集奠定了一般网络内计算框架的基础[127]：一种基于可编程网络设备的具有基本计算原语的网络内缓存结构。[180]的作者进一步提出了相关的一般性问题，即如何克服由可编程交换机上提供的稀缺资源(如有限状态存储和有限类型的操作)所造成的限制，用于网络内的计算任务。它们确定了可以使用近似技术来掩盖可编程交换机的这些限制的通用构建块，然后实现几个拥塞控制和负载平衡协议的近似变体，如XCP、RCP和CONGA[11]，这些协议需要网络的显式支持。

网络内计算的最新创新是基于这样一种观察：网络本身也可以用作与网络或包处理无关的工作负载的加速器。特别是，机器学习和人工智能工作负载已经成为有望(部分)在网络中实现的候选者[171]。更具体地说，可编程网络设备可能是实现CPU的人工神经网络协同处理的合适引擎。N2Net[184]是网络内神经网络的一个例子，它基于部署在网络交换机和路由器中的交换芯片。另一个可以在网络中实现的有趣应用是字符串匹配，用于加速信息检索和语言处理用例。PPS[89]是一种可编程交换机的网络内字符串匹配实现。PPS编译器将一组关键字翻译成确定性有限自动机(Deterministic Finite Automata, DFA)，然后可以在硬件中以匹配操作表序列的形式实现。作者表明，最终的匹配吞吐量明显高于可比的软件实现。

6.4 分布式的一致性

可编程数据平面的另一个有趣的应用与分布式共识算法有关：控制器或交换机之间的协调，以便共同和可靠地执行计算，甚至在网络故障、任意通信延迟或拜占庭参与者的存在。应用程序包括Leader选择、时钟同步、状态复制、发布-订阅模式和通用的多次写键值存储。分布式共识或许可以看作是网络内计算的一个特例，但它仍然值得特别讨论，这不仅是因为它在过去几年里得到了大量的研究处理，还因为它展示了一个特殊的网络需求概况：一般的网络内计算大多是吞吐量限制的，而分布式共识则更多地面向延迟，经常对单个服务器到服务器的往返时间提出延迟要求(甚至更少，参见[92])。

NetPaxos[47]证明了在网络设备中实现传统的Paxos分布式共识协议[115,116]的可行性，或者使用某些OpenFlow扩展，或者通过对网络如何订购消息进行一些假设。尽管这两个协议都不能完全实现而不改变底层交换机固件，作者认为这样的改变在现有的硬件是可行的。Dang等人的[46]还展示了将Paxos卸载到数据平面可获得的性能优势，并描述了P4中的一个实现。

数据平面的带内机制和功能也可以用于分布式系统中其他组件的同步和协调，例如SDN控制器。Schiff等人[173]提出了一个基于数据平面交换中实现的原子事务的同步框架，并表明他们的方法允许在出现故障时实现基本一致原语。作者还讨论了一致策略组合的应用程序。

最近，NetChain[92]在单台服务器到服务器的往返时间(RTT)内提供了数据中心的无限制扩展，甚至更少(RTT的一半!)。这是通过允许可编程交换机完全在数据平面存储数据和处理查询来实现的，这消除了协调服务器上的查询处理，并将客户端感知到的端到端延迟降低到与他们自己的软件堆栈和网络延迟的处理延迟一样少。NetChain依赖于新的协议和算法，以保证强一致性和交换机故障处理。

与一致性相关的更多有趣的应用程序出现在键值存储的上下文中。例如，NetCache[93]在可编程硬件交换机中实现了一个小的键值存储缓存。交换机作为数据中心机架级的缓存工作，处理定向到机架服务器的请求。该实现处理了一致性问题，并展示了如何克服硬件的约束，以提供吞吐量和延迟改进。SwitchKV[122]通过实现一个通用的基于数据平面的键值查询加速器来概括这一思想，在系统吞吐量和延迟方面都有显著的改进。可编程网络交换机扮演着快速键值缓存的角色，它跟踪缓存的键，并根据包头中编码的查询键以线速将请求路由到适当的节点。数据平面缓存节点吸收最热点的查询，因此任何私有的键值存储后端服务器都是超载的。此外，*Flow[188]、Marple[149]和IncBricks[127]中出现了专门用于网络测量收集和聚合的交换机内键值存储。

也许，一个不太可能找到分布式共识协议的地方是可编程设备本身。然而，在一个典型的可编程交换机的其实是一个相当复杂的分布式设备，有多个Match-Action表、解析器、队列等，它们密切合作，以执行一致的、高性能的包处理。事实证明，始终如一地对该流水线使用修改是一项相当复杂的任务，迫切需要强有力的一致性保证。最近，BlueSwitch[76]提出了一种可编程的网络硬件设计，该设计支持事务性的包一致配置机制：所有流经数据路径的包都将遇到旧配置或新配置，不会出现两者不一致的混合。这将有助于避免经常困扰当今运营网络的黑洞和微循环等网络瞬变现象[71]。

6.5 弹性、健壮和高效的转发

数据平面的运行速度比通常由软件实现的典型控制平面快得多。这使得在故障下维持链接的功能转移到交换机上。与此同时，卸载控制平面并非易事。

[44]的作者观察到，典型的SDN工作负载由于控制平面和数据平面之间频繁的交互而造成了显著的通信开销。然而，一些控制平面的功能可以有效地从控制器转移到交换机本身。为了满足高性能网络的需要,作者提出并评估DevoFlow, 一个对OpenFlow模型的修改，打破了SDN控制平面和数据平面之间的紧密耦合，在不增加不必要的通信成本的情况下，维持了对前者有用的可见性。与传统的OpenFlow实现相比，对于普通的SDN应用程序，DevoFlow需要的流表条目明显较少，从而减少了控制器-交换机通信。Molero等人[143]进一步阐述了这个想法，并给出了一个将控制平面协议(如路由协议)完全卸载到数据平面的一般案例。由于传统路由协议的长时间收敛，作者证明了现代可编程交换机足够强大，可以直接在硬件上运行许多控制平面任务。作为概念的证明，作者在P4中实现了一个可编程数据平面的路径向量协议。它们的实现在链路故障的情况下迅速收敛，同时完全遵守类似bgp的路由策略。

文献对弹性数据平面的设计进行了深入的研究。为了提供高可用性、连接性和健壮性，可靠的网络必须实现带内网络遍历功能，例如，在存在链路故障的[29]中找到故障转移路径。在这里，与简单的无状态机制或基于包标记的机制相比，基于交换机动态状态的机制提供了有趣的优势。Liu等人[125]建议将维持基本网络连接的责任完全转移到数据平面，数据平面的运行速度比控制平面快得多。他们通过数据平面机制确保连接的方法依赖于链路反向路由，适用于处理Gafni和Bertsekas最初算法的操作问题，如消息丢失或任意延迟[64](另见[158])。

Holterbach等人[81]提供一种在数据平面中完全实现的自动数据驱动的快速重路由。他们的系统Blink运行在可编程线速交换机上，通过分析交换机内的TCP行为来检测远程中断。在发生故障的情况下，Blink可以快速恢复连接并通过备份路径重新路由流量，而不需要控制平面的参与。

6.6 负载均衡

与弹性路由相关，可编程数据平面提供了前所未有的灵活性和高性能，可以在多个转发路径、工作者或后端服务器之间动态负载均衡。例如，Hedera[9]也可以被看作是一个负载均衡器。其目的是利用水平扩展实现“资源池”原则[201]，使独立资源集合的行为像单个池资源一样，以利用统计复用、负载分配和提高故障恢复能力。

一个著名的例子是HULA[103]，一个使用可编程数据平面的可扩展负载均衡解决方案。HULA是由等成本多路径(ECMP)以及现有的拥塞感知负载均衡技术(如CONGA[11])的缺点所驱动的。由于交换机内存有限，这些方法只能在边缘交换机上维护一个拥塞跟踪状态子集，因此不能扩展。HULA是灵活和可扩展的，因为每个交换机仅为，通过相邻交换机到目的地的最佳路径，跟踪拥塞。负载平衡应用程序的另一个例子是SilkRoad[139]，它利用可编程交换ASIC来构建更快的负载平衡器。

除了多路径负载平衡器之外，MBalancer[33]还解决了键值存储上下文中的负载平衡问题。特别是，分布式键值存储常常必须处理高度倾斜的键流行度分布，这使得跨多个后端平衡负载非常困难。MBalancer是一种基于交换机的L7负载均衡方案，它通过识别数据平面上的热键(通常数量较少)，将这些热键复制到多个(或全部)Memcached服务器上，然后相应地调整交换机的转发表，从而将来自瓶颈Memcached服务器的请求卸载。

7 可编程交换机的分类

在图7和图8中，我们对整个调查中讨论的关键论文进行了广泛的分类。这种分类法在支持数据平面可编程性的基础贡献(图7)和在令人兴奋的用例和新奇的应用程序中采用可编程数据平面的相关工作(图8)之间进行划分。

此外，作为该调查的附件，一份针对对可编程数据平面技术领域感兴趣的学生、从业者和研究人员的注释阅读清单也可以在线获得[140]。

基础Foundations

1.架构/平台

a)软件: OVS [160], BESS [77], VPP [56], PISCES [178], NetBricks [157]

b)网络处理器: Netronome NFP [151], Intel XScale [86]

c)FPGA: NetFPGA [209], P4FPGA [200]

d)ASIC: Barefoot Tofino [21], Cavium XPliant [6], Intel Flexpipe [1]

2.抽象/创建块

a)Match-Action: Ethane [36], OpenFlow [138], RMT [31], P4 [30], PISCES [178]

b)数据流: Click [147], VPP [56], BESS [77], NetBricks [157]

c)状态: FAST [148], OpenState [23], NetBricks [157], Domino [185], SNAP [15], FlowBlaze [163]

3.算法

a)匹配: CuckooSwitch [208], FIB Compression [168], Online FIB Aggr. [26]

b)表更新: Hermes [38], ShadowSwitch [27]

c)调度: PPS [186], PIEO [183], Approx. Fair Queueing [181], Universal Sched. [142]

4.语言

a)定义规则: DevoFlow [44], Pyretic [62], NetCore [145], Maple [199], PFQ [28]

b)定义底层处理: Packet Programs [95], P4 [30], Domino [185], Netdiff [52]

图7：为可编程数据平面技术奠定了基础

应用Applications

1.监控: OpenSketch [205], Marple [149], Sonata [75], INT [107], *Flow [188]

2.交换: OVS [160], OVS Security [195], AccelNet [60], Network Virt. [110]

3.网内计算: Camdoop [40], IncBricks [127], NetAI [171], N2Net [184]

4.一致性: NetPaxos [47], Switchy Paxos [46], NetChain [92], NetCache [93]

5.弹性: Connectivity in the Data Plane [125], Blink [81], Hedera [9]

6.负载均衡: CONGA [11], SilkRoad [139], Hula [103], MBalancer [33]

图8所示建立在可编程数据平面之上的关键应用程序的分类

8 研究挑战

为了总结本次调查并分享我们的经验教训，下面，我们对该领域的主要开放问题和研究挑战进行了简短的讨论。

8.1 改进的抽象

哪些抽象在支持的功能、最终的性能和API的简单性之间提供了最佳的权衡?

第一个主要的研究挑战围绕着抽象概念展开。正如我们所看到的，整个可编程交换架构的变革都围绕着抽象。理想情况下，抽象应该足够简单，能够捕获适当数量的可配置数据平面功能，以实现高效的硬件和软件实现，但也应该足够深刻，允许更高层次在其上综合复杂的包处理行为。此外，这种抽象应该很容易通过安全高效的数据面API暴露给控制面[138,155]。它应该充分处理嵌入在数据平面中的全局状态，并提供定义良好的一致性模型[202]。它应该允许分析性能模型[18,144]和用于性能优化的自动程序转换[144]。它应该将静态语义与动态行为分开[167]。最后但也比较重要的是，它应该是一个简单的心智模型，这是网络运营商和程序员所熟悉的。毫无疑问，该领域的许多开放问题都与为数据平面功能找到正确的抽象有关。

8.2 有效的可重配置能力

如何在数据平面支持更有效但一致的可重构性?

一个相关的问题是对可重构性的支持。随着从OpenFlow的严格编程模型向更灵活的P4编程的转变，人们渴望公开交换机可能执行的处理功能的每个方面，以灵活和有效的方式重新配置，以适应不同的和不断变化的用例。

但进一步延伸到关键的数据包处理操作,和重构性,从可编程包解析[67]通用调度和排队方案(142、186)。

这并不局限于数据包处理策略在数据平面的表现方式，也包括采用包相关联的方法执行相应的处理动作，还包括进一步延伸到关键的数据包处理操作，和重构性，从可编程包解析[67]通用调度和排队方案(142、186)。特别的，在不中断数据包处理的情况下改变数据平面的运行时行为[188]仍然是一个开放的问题。

8.3 可扩展性

如何实现数据平面的高性能，特别是有状态的高性能数据平面?

需要扩展系统来处理大量的工作负载，这越来越促使设计者去探索更复杂的解决方案，来处理数据平面中已经存在的一些状态[93,139,180]。虽然无状态包处理方法目前相当稳定，但有状态方法仍处于起步阶段，还没有出现明显的赢家。有状态抽象的复杂性在于需要以程序员友好的方式解决状态管理问题(例如，一致性)，同时保证高性能。这是特别具有挑战性的事情，因为在包处理工作负载中，频繁地读写内存仍然是现代计算系统性能问题的主要来源之一[31,51]。

8.4 网络自动化

如何设计更自动化和自调节的网络，使其能够将高级策略映射到底层物理基础设施，并自动调整其配置和操作以适应不断变化的需求或故障?

目前网络的一个主要趋势是自动化。在过去的几年里，“自驱动”通信网络的愿景已经出现，它可以根据当前的工作量进行自我调整和优化。与这一趋势相关的还有“基于意图的网络”的概念，它描述了从高级业务策略的角度设计和操作网络的远景，并让网络以自动化、数据驱动、敏捷、安全和可验证的[34]方式处理低级别的问题关注点。高级网络编程语言的最新进展以高效的语言结构和模块化组合框架的形式，为实现基于意图的网络的愿景提供了重要的见解[62,95,108,146,199,206]。然而，如何最好地将数据平面功能暴露给提供最大编程自由的开发者，同时有效地掩盖底层的复杂性，仍然不是很清晰。理想情况下，“基于意图的数据平面编译器”应该积极地尝试找到，能够以最小的数据平面占用空间获得最高性能的数据平面表示形式[144]，这是建立在优化数据平面程序和性能推理的坚实理论基础之上的[18,144]。

8.5 验证与监控

如何设计有效的验证和监控框架，允许开发者或意图层(可证明的)测试网络状态和负载的正确性和性能?

数据平面编译，即从意图层向下映射到数据平面，只是硬币的一面。事实上，与自动调整网络以适应变化环境相关的挑战是验证配置更改的正确性和充分性的需要。为了关闭控制回路，一个向上的映射也是必要的，这将允许控制平面监视和验证数据平面的操作。事实上，一个观测的结果表明，网络架构应该从开始就需要考虑可验证性[108]，这可能需要定义新的抽象。一般来说，由于数据平面所起的重要作用，新型数据平面技术的成功与否将取决于它们所能提供的可靠性保证。

这些以及其他与抽象、性能、自动化和安全性相关的研究方向，将可能继续需要研究人员多年的关注，努力在不断变化的环境中找到改进的权衡和新的机会。

9 总结

由于数据包处理中对灵活性、可编程性和高性能的需求不断变化，需要新的想法和解决方案来快速和经济有效地来支持变化。一般的可编程网络和特别的可编程数据平面恰恰提供了这样一种廉价的替代方案，可以同时支持所有可能的包处理功能。因此，可编程网络也支持利基解决方案：由于市场规模小，供应商不值得实现的解决方案。虽然本调查所涉及的这一领域的现有工作已经非常广泛，但该领域仍在迅速发展，我们认可：网络可编程性仍处于起步阶段。