Millions of Little Minions Using Packets for Low Latency Network Programming and Visibility

摘要

本文提出了一种实用的方法，可以快速地将新的dataplane功能引入网络:终端主机将小程序嵌入到包中，以主动查询和操作网络的内部状态。我们展示了这个“小数据包程序”(TPP)接口如何实现对网络行为（这是之前不具备的能力）的可见性，使它们能够与网络一起工作以实现所需的功能。

我们的设计充分利用了每个组件的最佳性能:(a)交换机以线速度执行小的数据包程序(最多5个指令)(b)端主机可以针对网络状态执行任意(且易于更新)的计算。通过实施三个不同的研究计划，我们证明了TPPs是有用的。在NetFPGA上使用硬件原型，我们以合理的成本展示了我们的设计是可行的。

引言

考虑一个拥有数千个交换机的大型数据中心网络。应用程序抱怨由于流完成时间要求高而导致流的一小部分流的性能不佳。作为一个操作者，您意识到这一症状可能是由于阻塞，或者来自竞争的交叉流量或糟糕的路由决策，或者可能是由于数据包在失败的链接上丢失。无论如何，您的目标是快速诊断这个问题。不幸的是，在今天的网络中广泛使用多路径路由，这意味着常常不能确定每个数据包所占用的确切路径;因此，将问题确定到单个交换机是相当困难的。更糟的是，如果阻塞是间歇性的，网络中的计数器以数分钟或数秒内的统计数据看起来“正常”。

如果可以在转发每个数据包的确切时间检查相关网络状态（如交换机ID，队列占用率，输入/输出端口，端口利用率和匹配的转发规则）以便在数据平面重新构建数据行为，那定位网络问题就比较直接。在上面的示例中，终端主机可以使用从数百万成功传递的数据包中获得的状态明确指出拥有高队列占用率（拥塞）的网络链路，或者使用交换机和端口ID来验证数据包是否被正确路由或使用路径信息来对导致由于链路故障导致分组丢失的网络链路进行定位测量。总之，将网络状态与特定分组相关联的能力将是无价的。是否可以检测数据包以访问和报告交换机状态？迄今为止，这种状态已被锁定在交换机内部。本文描述了一个简单的可编程接口，它使终端主机能够直接在数据平面中查询数据包中的交换机内存（计数器，转发表项等）。具体来说，小部分在它们的头文件中携带一个微小的数据包程序（TPP），它由几个指令组成，这些指令通过对交换机内存读取，写入或执行简单的协议无关计算。本文中的一个关键观察是具有这种可编程的

本文中的一个重要结果是，对这种可编程和快速访问网络状态的好处有利于广泛的网络任务 - 拥塞控制，测量，故障排除和验证 - 我们称之为数据平面任务。我们展示了TPP接口通过将终端上的预期功能重构以实现终端网络功能的快速部署：（a）在交换机上执行的简单TPPs（b）终端主机上的表达式程序

通过将TPPs与三种方法的对比来介绍新的数据平面功能：（1）为每项任务构建定制硬件，（2）构建可执行任意代码的交换机[33,36]，或（3）使用FPGA和网络处理器[26]。每种方法都有其自身的缺点：引入新的交换功能可能需要很多年;交换机硬件具有严格的性能要求，执行任意代码会影响性能;而FPGA和网络处理器在大规模时就太昂贵了[7]。相反，我们认为如果我们能够构建新硬件来支持一个简单的接口（如TPP），我们就可以利用终端主机通过软件开发实施许多复杂的任务。

在主动网络[33,36]中，TPPs可以被视为一个特定的合理点。在许多主动网络公式中，路由器执行主动控制网络行为的任意程序，例如路由，数据包压缩和（去）重复。相比之下，TPP指令非常简单，它们可以在线速转发数据包的时间内执行。如表1所示，只有少数TPP指令能够访问表2中的统计数据，足以实施多项以前的研究提议。

1.1目标

我们的主要目标是通过数据平面将网络状态展现给终端主机。为了使数据平面任务受益，任何接口都应该满足以下要求：

•速度：最近的一项研究显示，交换机CPU功能不强，无法处理数百个OpenFlow控制消息/秒[14]。我们的经验是，这些限制妨碍了一整套数据平面任务，因为它们在正常的数据包转发的过程中数据包进行处理。

•数据包级一致性：链路队列占用率和转发表等交换机状态随时间而变化。今天，我们缺乏获得这种状态的一致视野的手段，因为它涉及通过网络传输的每个数据包。

•简单设计和强大功能：为了值得付出努力，任何硬件设计都应该简单，充分表现出来，以实现多种有用任务，并且承受足够低的开销以实现线速工作。

本文介绍了一个特定的TPP接口，其设计主要由上述要求指导。

非目标：值得注意的是，我们的目标不是足够灵活来实现任何和所有数据平面网络任务。就目前来看，TPPs的表现力不足以实现每个数据包的调度。此外，我们的设计适用于由单一管理实体（例如，私有WAN和数据中心）拥有和运营的网络。我们不主张将网络状态暴露给连接到网络的不可信终端主机，但我们描述了避免执行不可信TPPs的机制（第4.3节）。最后，来自多个供应商的跨设备互操作性的详细设计超出了本文的范围，尽管我们讨论了一个似乎合理的方法（§8）。

1.2结果总结

通过软件实施和NetFPGA原型，本文表明TPPs在线路速率方面既有用又可行。而且，使用最近的数据[7]的分析表明，交换机硬件内的TPPs支持可以以可接受的成本实现。应用程序：我们通过使用TPPs接口重构许多最近的研究计划来展示TPP的优势。这些任务大致分为以下三类：

•拥塞控制：我们显示端主机通过使用TPPs周期性地查询网络链路利用率和队列大小，可以实现基于速率的拥塞控制算法（RCP），提供跨流量的最大/最小公平性。 我们进一步展示TPP接口如何实现超出RCP最初设计的最大 - 最小公平性的公平性度量（§2.2）。

•网络故障排除：TPP为终端主机提供详细的每个数据包对网络状态的可见性，可用于部署提出的称为NetSight[13]的故障排除平台。我们将介绍实施和部署Net Sight（由Net Sight引入的traceroute的概括）（§2.3）。

•网络控制：我们还演示了TPP提供的低延迟可视性如何使终端主机能够控制流量在网络路径上的流量负载平衡情况。我们通过端主机和仅支持TPP接口的网络之间重构CONGA [1]，这是一种在思科新ASIC中实现的网内负载均衡机制。

硬件：为了评估构建支持TPP的交换机的可行性，我们合成并构建了一个支持全TPP的四端口NetFPGA路由器（160MHz），可以在每个接口上以10Gb / s的速率交换最小大小的数据包。我们展示了在NetFPGA上增加TPP支持的硬件和延迟成本是最小的，并且认为同样会支持真正的交换机（§6）。我们发现实现高性能的关键是将TPP限制为每个数据包少量的指令（比如五个），因为它可以确保任何TPP在其传输时间的一小部分内执行。

软件：我们还在OpenvSwitch [31]中实现了TPP接口，我们用它来演示研究建议和示例。此外，我们还提供了一个强化安全性和访问控制的软件堆栈（§4），处理TPP组合，并且有一个有用的基元库以简化部署TPP应用程序的路径。 TPP的软件和硬件实现，在本文中运行实验和绘图的脚本以及描述更多TPP应用程序的本文的扩展版本均可在http://jvimal.github.io/tpp在线获得。

2 示例程序

我们使用可以使用TPP实现的数据平面任务示例开始我们的讨论，展示直接向数据平面中的终端主机公开网络状态的实用程序。这些任务中的每一个通常都需要新的特定于任务的硬件更改，然而，我们展示了如何重构每个任务，以便网络仅实现TPP，同时将复杂的任务特定功能委托给终端主机。我们将讨论以下任务：（i）微突发检测，（ii）基于速率的拥塞控制算法，（iii）网络故障排除平台，（iv）拥塞感知，分布式网络负载平衡器。

什么是TPP？ TPP是具有唯一标识头的任何以太网分组，其中包含指令，一些额外的空间（分组存储器）和可选的封装的以太网有效载荷（例如IP分组）。 TPP专门拥有其数据包空间，但也可通过地址访问交换机上的共享存储器（其SRAM和内部寄存器）。 TPP在每一跳都直接在数据平面执行，并像其他数据包一样被转发。 TPP使用表1中列出的非常小的指令集，并且我们将在第3节介绍空间开销。我们“滥用”术语，使用TPP来同时表示程序和携带它们的数据包。

我们使用伪汇编语言编写TPP，并使用分段地址空间命名各种寄存器，交换机RAM和数据包内存。我们使用可读标签编写地址，例如[Namespace：Statistic]或[Queue：QueueOccupancy]。我们假定这些地址在编译时被预先知道。例如，助记符[Queue：QueueOccupancy]可以指代一个地址0xb000，用于存储每个交换机上数据包输出队列的占用情况。

2.1微突发检测

考虑监测网络内链路队列占用情况以诊断短期拥塞事件（或“微爆炸事件”）的问题，直接量化incast的影响。在数据中心等低延迟网络中，队列占用率在几个RTT的时间范围内迅速变化。因此，观察和控制这种突发流量需要在时间尺度上可见的速度进行，比诸如我们今天拥有的SNMP或嵌入式Web服务器等机制快几个数量级，而这些机制最多只能运行数十秒。此外，即使监视机制很快，但不清楚要监视哪个队列，因为（i）基础路由可能改变，并且（ii）切换影响多路径路由的散列函数通常是专有的和未知的。

TPP可以为网络内的队列演变提供细粒度基于每RTT，甚至每个数据包的可视性。今天，交换机已经跟踪每个端口，每个队列占用内存管理。指令PUSH[Queue：QueueOccupancy]可用于将队列寄存器复制到数据包上。当数据包遍历每一跳时，数据包内存在每一跳都具有队列大小的快照。队列大小在诊断微小突发时非常有用，TPP可以为网络内的队列演变提供细粒度的每RTT，甚至每个数据包的可见性。今天，交换机已经跟踪每个端口，每个队列占用内存管理。指令PUSH [Queue：QueueOccupancy]可用于将队列寄存器复制到数据包上。当数据包遍历每一跳时，数据包内存在每一跳都具有队列大小的快照。队列大小在诊断微爆时非常有用，因为它们不是平均值。当数据包通过交换机时记录它们。图1a显示了一个样本数据包在通过网络时的状态。在图中，SP是堆栈指针，它指向数据包内存中可能存储新值的下一个偏移量。由于数据中心内的最大跳数很小（通常为5-7），因此终端主机会预先分配足够的数据包内存来存储队列大小。此外，endhost知道如何解释数据包中的值，以获得所有网络中的排队等待时间的细节。这个例子说明了endhosts软件如何使用访问数据平面状态的低延迟编程接口来测量难以在控制平面中观察到的数据平面行为。

图1a显示了Mininet [6]中的一个六节点哑铃形拓扑，其中每个节点向拓扑中的每个其他节点发送一个小的10kB消息。总应用程序级提供的负载是主机网络容量（100Mb / s）的30％。我们用TPP对每个数据包进行了检测，并在一台主机上收集了完全执行的携带网络状态的TPP。图1b显示了从该主机接收到的每个数据包中获得的网络中的6个队列的队列演变。

开销：实际的TPP由三条指令组成，每条指令分别读取交换机ID，端口号和队列大小，每个指令都是一个16位整数。如果网络的直径为5跳，那么每个TPP只为每个数据包增加一个54字节开销：TPP报头（参见§3.4）为12个字节，指令为12个字节，每个报文为6×5个字节以收集统计数据。

2.2基于速率的拥塞控制

虽然前面的例子显示了TPP如何帮助观察延迟峰值，但我们现在展示如何使用这种可见性来控制网络拥塞。拥塞控制可以说是一个数据平面任务，很多文章在设计更好的算法方面有许多想法，其中许多算法需要交换机支持。但是，TCP及其变体仍然是占主导地位的拥塞控制算法。许多拥塞控制算法（如XCP [20]，FCP [11]，RCP [9]等）通过监视指示拥塞和每几个RTT调整流量的状态来工作。我们现在展示终端主机如何使用TPP来部署一种新的拥塞控制算法，该算法享有网络内算法的许多好处，如速率控制协议（RCP）[9]。 RCP是一种拥塞控制算法，可快速分配链路容量以帮助流量快速完成。RCP路由器每个链路（容量C，无论流的数量如何）维持一个公平分享率R（t），周期性计算（每T秒）如下：

这里，y（t）是平均入口链路利用率，q（t）是平均队列大小，d是通过链路的流量的平均往返时间，a和b是可配置参数。每个路由器检查它的估计值R（t）是否小于流量的公平份额（在每个数据包的头部标明）;如果是这样，它使用R（t）替换共享报头值。

我们现在描述RCP *，这是RCP的终端主机实施。该实现由速率限制器和速率控制器组成，在每个流的末端主机上（因为RCP按照每个流的粒度运行）。网络控制平面为每个链接分配两个内存地址（链接：AppSpecific_0和链接：AppSpecific_1）以存储公平率。每个流量速率控制器分三个步骤定期（使用流量数据包或使用额外的探测数据包）查询和修改网络状态。

阶段1：收集。使用以下TPP，速率控制器会查询网络上每一跳的交换机ID，队列大小，链路利用率以及链路沿着路径的所有链路的公平分配率（及其版本号）。接收者只需将完全执行的TPP回复给发件人即可。网络每毫秒更新链接利用率计数器。如果需要，终端主机可以通过查询[Link：RX-Bytes]来更快地测量它们。

PUSH [开关：开关ID]

PUSH [链接：队列大小]

PUSH [链接：RX-Utilization]

PUSH [链接：AppSpecific_0]＃版本号

PUSH [链接：AppSpecific_1]＃Rfair

阶段2：计算。在第二阶段，每个发送者计算每个链路的公平分享率Rlink：使用阶段1中收集的样本，速率控制器计算路径上每个链路上的平均队列大小。然后，它使用RCP控制方程计算每个链路速率Rlink。

阶段3：更新。在最后阶段，每个流的速率控制器异步发送以下TPP以更新所有链路上的公平速率。为了确保由于并发更新而导致的正确性，我们使用CSTORE指令：

CSTORE [链接：AppSpecific_0]，\

[Packet：Hop [0]]，[Packet：Hop [1]]

STORE [链接：AppSpecific_1]，[Packet：Hop [2]]

PacketMemory：

Hop1：V_1，V_1 + 1，R_new_1，（*每个* 16位）

Hop2：V_2，V_2 + 1，R_new_2，...

其中Vi是终端主机用于派生更新的Rnewi的AppSpecific_0中的版本号，用于第i跳，从而确保一致性。 （CSTORE dst，只有当dst旧时才更新，新的更新dst，否则忽略TPP的其余部分。）请注意，在TPP中，版本号和公平比率在每一跳从数据包中读取内。

其他分配：尽管RCP最初设计为在竞争流中以最大最小公平的方式分配带宽，但Kelly等人[22]展示了如何调整RCP来为一个公平标准 - 一个公平性参数化的公平性频谱分配带宽。a是如下实现的：如果Ri是在流经过的第i条链路上计算出来的公平率，流使用以下公式计算他的速率：

a=1对应的是均衡的公平，当a趋向于无穷时，R为Ri中的最小值。这与最大-最小公平算法是一致的。

请注意，如果ASIC硬件设计用于RCP的最大最小版本，终端主机很难实现其他有用的公平性概念。然而，TPP有助于将公平性选择延迟到部署时间，因为终端主机可以根据等式2基于选择的a来聚合每个链路Ri。 （由于[35]中的原因，我们不建议具有不同a的流量共享相同的链路）。

图2显示Mininet中maxmin RCP *和比例公平RCP *的三个流的吞吐量：流'a'与流'b'和'c'共享一条链路（右图所示）。流量基本上是速率限制的UDP流，其中速率是使用控制算法确定的：Max-min公平应该在流间平均分配费率，而比例公平应该将1/3的链路分配给穿过两个链路的流，而2 / 3添加到仅遍历一个链接的流。

开销：对于图2中的实验，当我们将长时间存在的流数量从3变为30至99（平均超过三次），TPP控制数据包带来的带宽开销约为流量速率的1.0-6.0％。在同一个实验中，TCP的开销略低：0.8-2.4％。 RCP *开销与TCP的范围相同，因为每个流大致每RTT发送一次控制包。随着流量数n的增加，平均每流量速率减小为1/n，这导致每个流量的RTT增加（因为RTT与流量成反比）。因此，总开销不会爆炸。

写入是绝对必要的吗？ RCP *是写入网络状态的少数TPP应用程序之一。值得一提的是，这是否是绝对必要的。我们认为这是快速收敛的必要条件，因为RCP依赖于流经单个瓶颈链路的流量，这个链路同意一个在RCP中明确实施的共享速率。或者，如果快速收敛并不重要，那么流就可以以一种AIMD流行的方式收敛到它们的公平速率，而不需要写入网络状态。事实上，XCP实现了这种AIMD方法，但是[9]的实验表明XCP的收敛速度比RCP慢。

2.3网络故障排除框架

最近有设计用于故障排除网络的编程工具;毫无疑问，数据平面能见度对于故障排除者至关重要。例如，考虑验证网络转发规则与管理员指定的意图相匹配的任务[21,23]。随着转发规则的不断变化，这项任务变得非常困难，而且网络范围内的“一致”更新并不是一项微不足道的任务[32]。由于控制平面的路由状态视图与硬件中的实际转发状态之间可能存在不匹配（并且这种问题已在云提供商的生产网络中显示出来），因此验证更加复杂。因此，验证数据包是否被正确转发需要dataplane的帮助。

最近，研究人员提出了一个名为NetSight的平台[13]。 NetSight引入了“数据包历史记录”的概念，它是数据包通过网络的路径记录和应用于数据包的交换机转发状态。作者使用这种结构展示了如何构建四种不同的网络故障排除应用程序。我们首先展示如何有效地捕获NetSight平台核心的数据包历史记录。 NetSight通过插入控制器和网络之间的控制通道，使用唯一版本号对每个流条目进行标记，修改流条目以创建带有版本号标记的数据包头的截断副本（不影响数据包的正常转发），以及额外的元数据（例如，数据包的输入/输出端口）。这些截断的数据包副本由服务器重新组合以重建数据包历史记录。

我们可以通过在每个端主机（§4）插入下面显示的TPP来重构收集数据包历史记录的任务。在接收到所有跳中完成执行的TPP后，终端主机可以准确查看影响数据包转发的网络转发状态，而无需网络创建额外的数据包副本。

PUSH [开关：ID]

PUSH[PacketMetadata：MatchedEntryID]

PUSH[PacketMetadata：InputPort]

一旦终端主机构建了一个数据包历史记录，它就会被转发到收集器，并以多种方式使用它们。例如，如果最终主机存储历史记录，我们将获得与netshark相同的功能 - 一个跨服务器分布的整个网络范围的tcpdump。从存储的跟踪中，管理员可以使用任何查询语言（例如SQL）来提取相关的数据包历史记录，这可以提供与交互式网络调试器ndb相同的功能。另一个应用netwatch简单地使用分组历史来验证网络转发跟踪是否符合由控制平面指定的策略（例如，租户之间的隔离）。

开销：指令开销是12字节/分组和6字节的每跳数据。 TPP头和为10跳的存储空间，这是84字节/包。如果平均数据包大小为1000字节，如果我们在每个数据包中插入TPP，则这是8.4％的带宽开销。如果我们只为一部分数据包启用它，则开销将相应较低。

注意事项：尽管有其优点，但仅使用TPP存在缺陷，特别是如果网络以错误或不可逆方式转换数据包。我们可以通过发送将被丢弃到收集器的数据包来克服丢弃的数据包（我们在§2.5中描述了它是如何描述的）。其中一些假设（相信数据平面正常运行）也由NetSight制定，我们相信TPP的优势超过其缺点。例如，TPP可以收集更多的统计数据，例如链路利用率和队列占用率，以及数据包的转发历史记录。

2.4分布式负载平衡

我们现在展示终端主机如何使用TPP来探测网络拥塞，并使用这种详细的可见性以分布式方式来平衡流量。我们演示了CONGA的简化版本[1]，它是一种用于流量负载平衡的网络内部方案。 CONGA致力于通过让网络交换机维护路径级拥塞度量表（例如，量化的链路利用率）来最大化网络吞吐量并且以分布式方式最小化最大网络链路利用率。利用这些信息，交换机可以在最小负载路径上自发地发送小流量（“流量”），CONGA针对数据中心网络拓扑进行了优化;我们将好奇的读者引荐给[1]以了解更多细节。

conga的设计突出了与我们的讨论相关的两个好处。首先，它通过交换机标记包头上的量化拥塞信息来使用显式的可见性;其次，在往返时间间隔做出负载均衡决策，以快速检测并对网络拥塞做出反应;由于TPP也提供类似的好处，我们可以重构终端主机和网络之间的负载平衡任务，而不需要定制硬件（当然，除了支持TPP）。首先，我们要求网络安装端路由器可以根据包头值选择的多路径路由。这可以在控制平面的慢路径中通过编程当前许多交换机中用于多路径路由的“组表”来完成[29，§5.6.1]，其中通过对头部字段进行散列来引出输出端口（例如， VLAN标签）。这允许终端主机通过改变VLAN ID来选择网络路径。其次，我们需要终端主机来查询整个链路的利用率

通过将以下TPP插入到数据中心内主机的数据包子集中：

PUSH [链接：ID]

PUSH [链接：TX-Utilization]

PUSH [链接：TX-Bytes]

如果链路利用率未更新，我们查询链路：TX-Bytes来测量小拥塞事件。接收器将完全执行的TPP回送给发送者以传达拥塞。请注意，回显的TPP的标题还包含路径ID以及路径中每个链接上的链接利用率。第三，在完全执行的TPP中使用信息，终端主机可以建立一个表映射'Path i-Congestion Metric（mi）'，其中mi是路径i上每个交换机交换网络跳跃上的链路利用率的最大值或总和。 CONGA的作者指出，在最坏的情况下（对抗性）'sum'比'max'更接近最优;然而CONGA使用'max'，因为当交换机聚合路径拥塞时它不会导致溢出。对于TPP，这不是问题，可以推迟选择部署时间。最后，终端主机具有关于流和流程的完整上下文，因此每个终端主机可以通过适当地设置路径标记来选择流的路径。

开销：我们使用UDP流在软件中实施了概念验证原型（CONGA *）;图4再现了来自CONGA [1，图4]的一个例子。我们配置了交换机S0和S1来选择基于目的UDP端口的路径。从L0到L2的流量只使用一条路径，而从L1到L2的流量有两条路径。 L0和L1的UDP代理查询链路利用率，并且每两毫秒为两条路径聚合拥塞度量值。使用CONGA *，终端主机可以最大限度地提高满足两种流量需求的网络吞吐量，同时最大限度地降低最大链路利用率。在这个例子中，TPP包引入的开销很小（<总流量的1％）。

备注：请注意，网络和终端主机之间的功能是重构的;并非所有功能都完全驻留在最终主机上。网络实现TPP和多路径路由。终端主机仅仅完全用软件选择基于拥塞的路径。

2.5其他可能性

以上示例说明了单个TPP接口如何使终端主机实现许多任务。还有更多我们无法详细介绍的任务。为了空间的利益，我们将读者引用到本文的扩展版本，以获取更多关于以下某些任务的细节[28]。

测量：由于TPP可以读取网络状态，因此它们可以以简单的方式用于在快速时间尺度上测量任何网络统计量。由于TPP在数据平面中运行，它们处于一个独特的位置，可以揭示终端主机关心的特定数据包所经历的路径特征。

网络验证：TPP还有助于验证网络设备是否满足特定要求。例如，TPP提供的路径可见性有助于准确验证路由收敛时间是否在在可接受的值内。如果我们依靠端到端的可达性作为衡量融合的方式，那么今天的任务可能会非常具有挑战性，因为当路由发生变化时，备份路径仍然可以维持端到端的连接。而且，显式可见性可以简化故障定位。

快速网络更新：通过允许安全应用程序写入交换机的转发表，可以使网络更新速度非常快。这可以减少网络转发状态未收敛时的瞬态状态的时间窗口。例如，可以在半个往返时间内沿路径向所有交换机添加新路由，因为更新IP转发表只需要64位信息每跳：32位地址和32位网络掩码跳，足够小，可以在数据包内实现。

无线网络：TPP也可用于无线网络，其中接入点可以通过信道SNR等快速变化的状态对终端主机数据包进行注释。对这种快速变化的状态进行低延时访问对于网络诊断非常有用，允许终端主机区分因信道质量差而导致的充电损耗和损耗，并查询AP为特定分组选择的比特率。

3具有TPP功能的Switch的设计

在本节中，我们将讨论TPP指令，寻址方案以及TPP接口到交换机的语义以及交换机是否具有TPP功能的含义。网络交换机具有各种形式因素和实现；它们可以用软件（例如Click，Open vSwitch）或网络处理器（例如NetFPGA）或硬件ASIC来实现。交换机也可以由多个ASIC分层构建，如'基于机箱'的交换机[18，图3]。

TPP可以在上述的每种平台上执行。因此，支持TPP的交换机和终端主机拥有一个保留有用属性而不会影响性能损失的规范是非常有用的。我们通过约束指令顺序执行和原子性来实现这一点。

3.1交换机流水段的背景

我们从图5所示的交换执行环境的抽象模型开始。

数据包通过许多流水线模块从输入到输出流动。一旦数据包到达输入端口，数据平面将为数据包添加元数据（例如其入口端口号）。然后，数据包通过一个解析器，从数据包中提取字段并将其传递到包含多个匹配操作阶段的管道。这也被称为多匹配表模型[7]。例如，一个阶段可能使用解析字段来路由数据包（使用第2层MAC表，第3层最长前缀匹配表和灵活的TCAM表的组合）。最后，对数据包的任何修改都会被提交，并且数据包在交换机内存中排队。使用元数据（例如数据包的优先级），调度程序决定何时应该将数据包发送出在流水线早期确定的出站端口。出口阶段还包括一些匹配行动阶段。

3.2 TPP语义

TPP中的读/写指令访问两个不同的存储空间：交换机中的存储器（交换机存储器）以及数据包内的每跳临时空间（数据包存储器）。对于所有的交换机存储器，除了存储数据包内容的存储器之外，我们只是指由TPP遍历的存储器。对于所有的数据包内存，我们是指包中的TPP相关字段。现在，我们陈述访问两个存储空间的读/写指令的要求。

交换机内存：要在特定数据包穿过网络时显示有关特定数据包的统计信息，TPP中的指令有权访问用于转发数据包的值，这一点非常重要。对于只读值，此要求意味着由TPP读取到单个存储器位置必须是原子的，并且最终由转发逻辑写入相同的存储器位置。例如，如果TPP访问保存数据包输出端口的内存，则它必须返回与转发逻辑确定的端口相同的端口，而不是其他值。这就是我们所说的网络状态的“数据包一致”视图。

数据包存储器：由于指令可以使用PUSH和POP读取和写入数据包存储空间，写入数据包存储器必须按照TPP指定的顺序依次生效。 这保证了如果TPP将内存位置X，Y和Z上的值推送到数据包内存上，则终端主机将按照相同的顺序查看数据包中的值。 这并不要求以相同的顺序pop到X，Y和Z的读取。

3.3 TPP执行模型

TPP在数据平面管道中执行。要求TPP完全适合MTU，以避免ASIC处理碎片问题。这不是一个很大的限制，因为如果单个数据包没有足够的内存来查询所有需要的统计信息，则终端主机可以将复杂任务分解为多个较小的TPP。默认情况下，TPP在每一跳都执行，并且如果访问不存在的内存，则不执行指令。这确保TPP优雅地失败。此外，该平台可以自由地重新排序读取和写入，以便以任何顺序执行。但是，如果程序员由于数据风险保证指令顺序执行（例如，针对CEXEC，CSTORE），则他们必须确保TPP以流水线顺序访问存储器。对于绝大多数用例，我们认为这种限制并不严重。从实际的角度来看，这一要求确保了交换机流水线像大多数交换机一样保持前馈。

3.3.1统一内存映射IO

TPP可以访问交换机计算出的可寻址统计信息。统计信息可以广泛地命名为每个交换机（即全局），每个端口，每个队列和每个分组。表2显示了每个这些名称空间中的示例统计信息。这些统计数据可能分散在流水线的不同阶段，但TPP通过统一的地址空间访问它们。例如，交换机为每个可以编址的数据包保存元数据，如输入端口，选定的路由等。这些地址映射在将诸如[PacketMetadata：InputPort]之类的助记符转换为虚拟地址的TPP编译器之前是已知的。

3.3.2寻址数据包内存

内存使用堆栈指针和PUSH指令进行管理，该指令将值附加到预分配的数据包内存。 TPP也支持跳转寻址方案，类似于base：offset x86寻址模式。这里，base：offset是指位置base * hop_size + offset处的数据。因此，如果跳数为16字节，则指令“LOAD [Switch：SwitchID]，[Packet：hop [1]]”将把第一跳上的交换机ID复制到PacketMemory[1]，PacketMemory [17]第二跳等。偏移量是指令的一部分;基值（跳数）和每跳内存大小值位于TPP报头中。为了简化数据平面中的内存管理，终端主机必须在TPP中预分配足够的空间来保存每hop数据结构。

3.3.3同步指令

除了读写之外，并发编程环境中的有用指令是原子更新指令，例如条件存储器CSTORE，其在与指定值匹配的存储器位置上进行调节，如果更新失败则停止TPP中的后续指令。 也就是说，CSTORE [X]，[Packet：hop [Pre]]，[Packet：hop [Post]]的工作原理如下：

通过让CSTORE返回X的值，终端主机可以推断指令是否成功。 请注意，第二个和第三个操作数是从每一跳中的唯一位置读取的。 当交换机覆盖第二个操作数的值时，需要确保正确的语义。 以类似的方式，我们发现有用的条件执行（CEXEC）指令; 例如，可能需要仅在一台交换机上或在交换机的一个子集上（例如数据中心内的所有机架式交换机的顶部）执行网络任务。条件执行指令指定一个存储器地址，一个32位掩码和一个32位值（在数据包跳转中指定），指示交换机仅在（switch_value＆mask）==值时执行所有后续指令。 CEXEC检查失败后的所有指令都不会执行。

3.4解析：TPP数据包格式

如§2所述，TPP是任何以太网帧，我们可以从中唯一地标识TPP头，指令，数据包存储器和可选的有效负载。这允许终端主机以两种方式使用TPP：（i）通过将分组封装在以太网类型0x6666的TPP内，或者（ii）将TPP嵌入到目的地为端口的正常UDP分组中，从而在任何现有分组上捎带TPP 0x6666，这是TPP使能的路由器篡夺的特殊端口号。

图6a显示了两个解析图，描述了我们的原型使用TPP的两种方式。一个解析图描绘了一个数据包解析器的状态机，其中节点表示协议和边表示字段值匹配时的状态转换。我们使用与[7]中相同的惯例来展示我们可以解析TPP的两种方式。

3.5把它们放在一起：TCPU

TPP在一个小型处理器上执行，我们称之为TCPU。实现TCPU的一种简单方法是在入口匹配阶段结束时使用类似RISC的处理器，正如我们之前的文件[19，图5]中所描述的那样。这种简单的方法对于软件或低速硬件交换机可能是实用的，但在高速硬件交换机中可能不切实际，因为ASIC中的存储器通常分布在模块中。提供从每个模块到TCPU的读取和写入路径的布线复杂度在ASIC内变得非常昂贵，并且在机箱交换机中通过线卡是不可行的。我们通过两种方式克服了这个限制。首先，我们的执行模式允许在不同的ASIC存储单元上重新排序读写操作。其次，如果一个TPP不足，终端主机可以静态分析所需的TPP并将其分解为更小的TPP。例如，如果一个终端主机需要在所有交换机上的所有链路上利用链路利用率，则一个分组可以遍历，它可以实现下列顺序的TPP：（i）发送一个TPP来收集交换机标识并链接利用该链路所经过的链路的利用率，（ii）向TPP 1遍历的交换机上的每个交换机链路发送新的TPP，以收集剩余的统计数据。总结：

•通过让终端主机确保没有写后写或写后读冲突，可以按任意顺序执行单个数据包中的加载和存储。

•条件指令的操作数（如CSTORE和CEXEC）在执行后续指令之前或之后可用;当所有操作数可用时，CEXEC都可以执行。

通过允许指令不按顺序执行，我们可以通过在每个阶段复制其功能来将单个逻辑TCPU分布在ASIC上。每个阶段对于数据包中的每条指令都有一个执行单元，一个用于将执行单元连接到数据包存储器和本地的所有寄存器的交叉开关，以及对阶段本地存储器读/写端口的访问。从解码的指令中，该流水线段可以执行本流水段内的所有指令，一旦所有内存访问完成，数据包就会离开流水段。

复制执行单元可能看起来很昂贵，但ASIC中的大部分逻辑区域都是大容量存储器（用于数据包缓冲区，计数器等），因此执行单元的成本并不令人望而却步[7]。图7显示了如果我们其中一个匹配操作阶段的TCPU。

序列化PUSH / POP指令：最后，有很多技巧可以确保PUSH和POP指令在执行时的效果。由于PUSH /POP指令访问的数据包内存地址在被解析时会立即知道，因此可以将它们转换为等效的LOAD / STORE，然后可以不按顺序执行。例如，考虑以下TPP：

PUSH[PacketMetadata：OutputPort]

PUSH[PacketMetadata：InputPort]

PUSH [Stage1：Reg1]

POP [Stage3：Reg3]

解析指令后，可以将它们转换为与上述TPP等效的以下TPP：

LOAD[PacketMetadata：OutputPort]，[Packet：Hop [0]]

LOAD[PacketMetadata：InputPort]，[Packet：Hop [1]]

LOAD [Stage1：Reg1]，[Packet：Hop [2]]

STORE [Stage3：Reg3]，[Packet：Hop [2]]

现在，TPP将存储在两个寄存器中的值加载到以跳转寻址格式寻址的分组存储器中。注意，分组的输出端口在分组被路由之前是未知的，即在入口阶段结束时。执行过程如下：

•通过入口阶段1，元数据包含四条指令，它们访问的存储器地址（四个寄存器和三个数据包内存偏移量），数据包的hop，数据包的头，输入端口，CRC等。

•在阶段1，数据包的输入端口是已知的。阶段1执行第二条指令，并将输入端口值存储在数据包存储器的第二个字中。阶段1还执行第三条指令，将Reg1复制到数据包存储器的第三个字。

•在阶段3，执行第四条指令，将包存储器中的第3个字复制到Reg3中。

•入口阶段结束时，数据包的输出端口已经计算完毕，最后一级将数据包存储在ASIC数据包缓冲区之前，将输出端口号复制到数据包存储器的第一个字。

 

 4终端主机栈

现在我们已经看到了如何设计支持TPP的ASIC，我们研究了使用TPP实现复杂网络功能的终端主机所需的支持。由于TPP支持可以部署在网络堆栈（例如RCP拥塞控制）或单个服务器（如网络监控）或两者结合的广泛应用，因此我们将工作重点放在常见使用模式上。

终端主机架构：终端主机栈（图8）的目的是抽象出TPP的常见使用模式并实施TPP访问控制策略。 在每个终端主机上，我们都有一个TPP控制和数据平面代理。 控制平面是不在关键转发路径中的软件代理，并且在需要时与网络控制平面交互。 数据平面填充位于OS网络堆栈和网络接口之间的关键路径上，并可访问由端主机发送和接收的每个数据包。 该Shim负责透明地添加和删除应用程序生成的数据包中的TPP，并强制执行访问控制。

4.1控制平面

TPP控制平面（TPP-CP）是跟踪运行TPP应用程序和管理交换机内存的中心实体，并且在每个端主机上都有一个代理，用于跟踪在本地运行的启用TPP的应用程序。每个应用程序都分配有一组连续的可以读/写的内存地址。例如，RCP应用程序需要访问交换机内存字以存储每个链路上Rfair，并且它专门拥有该内存。该存储器访问控制信息与x86的全局描述符表相似，其中每个条目对应于一个段的开始和结束地址，并且相应地授予读/写存储器的权限。

TPP-CP导出一个API，授权应用程序可以使用该API将TPP按照一定的采样频率插入符合特定标准的数据包子集上。请注意，TPP-CP将知道调用者应用程序（例如，ndb），因此如果TPP访问非允许的内存位置，它可以拒绝API调用。 API定义如下：

add_tpp（filter，tpp_bytes，sample_frequency，priority）

其中filter是数据包过滤器（与iptables中的一样），tpp_bytes是已编译的TPP，sample_frequency是一个非负整数，指示采样频率：如果它是N，那么以TP = 1/N的概率标记TPP。如果N = 1，所有数据包都有TPP。该数据平面将所有TPP的列表与每个过滤器一起存储：这确保了多个应用程序（它们想要在所有IP数据包的1％上（例如）安装TPP）可以共存。 TPP-CP还配置数据平面以执行访问控制策略。每个内存访问策略都是一个元组：（appid，op，address_range）。值appid是64位数字，op是读取或写入，address_range是表示开始和结束地址的间隔。对TPP进行静态分析，以查看它是否访问允许的地址范围之外的存储器;如果是这样，那么API调用将返回一个失败，并且从不安装TPP。

4.2 数据平面

终端主机数据平面是软件包处理流水线，允许应用程序将TPP注入正在进行的数据包，从处理已执行的TPP返回结果，并执行访问控制策略。

插入：数据平面实现TPP-CPAPI add_tpp。它将传出与过滤器表匹配的数据包，并将TPP添加到第一个匹配项，或者如果没有匹配，则发送数据包。只有一个TPP被添加到任何数据包。数据平面中的插入模块还会在将数据包传递到网络堆栈之前剥离已完成TPP的传入数据包，因此应用程序无视TPP。

执行TPP的处理：数据平面还处理已完全执行的来自网络的传入数据包。它回应任何完成执行回到数据包的源IP地址的独立TPP。对于捎带的TPP，数据面将检查将应用程序ID映射到其聚合器的表，并将完成的TPP发送到特定于应用程序的聚合器。

4.3安全考虑

任何数据中心都有大量的软件可以产生网络流量，并且大部分软件不应该被信任来生成任意的TPP。毕竟，TPP可以读写各种交换机状态并影响分组路由。这引发了如何限制软件生成TPP的问题，以及如何为一些不完全可信的软件提供TPP带来的便利。我们现在讨论可能的机制来实施这种限制，假设交换机是可信的，并且在终端主机（如管理程序）上有一个可信的软件层。幸运的是，限制TPP是相对简单的，因为它归结为已经广泛部署的数据包过滤。正如不可信软件不应该欺骗IP地址或VLAN ID一样，它不应该能够发起TPP。执行此限制与根据协议和端口号进行过滤一样简单，这可以在所有入口交换机端口或管理程序中完成。在许多设置中，对大多数交换机状态的只读访问是无害的。（一个很大的例外是其他缓冲数据包的内容，TPP无法提供访问权限。）幸运的是，TPP相对适合静态分析，特别是因为TPP最多包含五条指令。因此，管理程序可以配置为使用写入指令删除任何TPP（或将指令写入交换机状态的某个子集）。或者，可以想象，管理程序使用TPP实现更高级别的服务（例如网络可见性），并通过受限制的API将它们展示给不可信的软件。

在高层次上，发送恶意TPP的受到破坏的管理程序与受感染的SDN控制器一样糟糕。不同之处在于，虚拟机管理程序通常分布在数据中心的每台计算机，并且可能会比SDN控制器提供更大的攻击面。因此，为了深入防御，控制平面需要能够完全禁用写指令（STORE，CSTORE）。我们介绍的大多数任务只需要读取网络状态。

4.4 TPP执行程序

虽然执行TPP的默认方式是从源到目的地执行所有hop，但我们已经构建了一个'TPP执行程序'库，它抽象出可以（i）可靠地执行TPP的常见方式，尽管TPP在网络中被丢弃，（ii）针对一个交换机，而不会发生从一端主机到另一端主机的完整往返行程，（iii）以分散 - 收集方式跨越交换机子集执行，等等。为了空间的利益，我们推迟了详细的讨论。

5实施

我们已经实现了TCPU所需的硬件和软件支持：10Gb / s NetFPGA平台上的分布式TCPU以及Open vSwitchLinux内核模块的软件TCPU。 NetFPGA硬件原型在每个端口都有一个四级流水线，每个级具有64 kbit块RAM和8个寄存器（即总共1Mbit RAM和128个寄存器）。我们能够综合160MHz的硬件模块，能够以40 Gb / s的总数据速率切换最小尺寸（64字节）的数据包。最终主机堆栈是一个相对直接的实现：我们实现了TPP-CP和TPP执行程序（仅支持可靠和分散 - 收集执行模式），作为运行在用户空间中的Python程序。软件数据平面是一个内核模块，充当网络堆栈和底层网络设备之间的中间部分，可以访问发送和接收路径上的所有网络数据包。为了过滤数据包以附加TPP，我们使用iptables对数据包进行分类并使用TPP编号对其进行标记，并且数据平面通过修改数据包来插入相应的TPP。

6评价

在§2中我们已经看到TPP如何启用许多数据平面应用程序。我们现在深入研究硬件和软件堆栈中每个组件性能的目标基准。

6.1硬件

每条指令的代价都由内存访问延迟所决定。只访问寄存器的指令在少于1个周期内完成。在NetFPGA上，我们使用单端口128位宽块RAM，其读取（或写入）延迟为1个周期。我们通过发送数百个4指令TPP从每个流水段读取时钟来测量每个阶段的总延迟，并发现每个流水段的总延迟正好是2个周期：因此，解析，执行和数据包重写都在一个时钟周期内完成，除了CSTORE需要1个周期执行（不包括从内存访问操作数的时间）。

实际交换机中的延迟时间是不同的：从与多个ASIC设计者的交流[6,8]中，我们了解到市场上的1GHzASIC芯片通常使用32-128位宽的单端口SRAM，并且每个操作具有2-5个周期的延迟（读/写）。这意味着在最坏的情况下，每个加载/存储指令会增加5个周期的延迟，而CSTORE会增加10个周期。因此，在最坏的情况下，如果每条指令都是CSTORE，TPP可以为流水线添加最大50ns的延迟;为了避免由于流水线延迟造成的吞吐量损失，我们可以增加50ns的缓冲（在1Tb / s时，整个交换机的吞吐量为6.25kB）。但是，实际成本可能较小，因为ASIC已经访问了可能被正在执行的TPP访问的存储器位置：例如，ASIC总是查找流条目并更新队列大小以进行内存记录，所以这些值不需要被读取两次。

尽管交换延迟成本与NetFPGA不同，但它们不会显着影响数据包处理延迟，因为在典型的工作负载中，排队和传播延迟在端到端延迟方面占主导地位，并且数量级要大得多。即使在交换机内，商用ASIC的卸载入口 - 出口延迟大约为每包500ns [3]。 最低延迟的ASIC在每个数据包大约200ns的范围内[16]。 因此，每个数据包额外50ns的最坏情况成本为数据包增加了至多10-25％的额外延迟。 表3总结了延迟成本。

模具面积：表4总结了NetFPGA的成本。与单级流水段路由器相比，根据接口数量计算，成本在30.1％以内。然而，门自身并不占总面积成本，因为逻辑仅占由存储器决定的总面积的一小部分。为了评估真实交换机的面积成本，我们使用了Bosshart等人的数据。 [7]。在他们的论文中，作者指出，总共7000个处理单元的额外区域 - 支持类似于TCPU的指令 - 分布在所有的流水阶段，占ASIC区域的不到7％[7，§5.4 ]。我们只需要5×64 = 320个TCPU，每个入口/出口管道每级指令一个;因此，面积成本不大（0.32％）。

6.2终端主机堆栈

终端主机堆栈中的关键组件是数据平面。在发送端，数据平面处理每个数据包，与过滤器列表匹配并附加TPP。我们使用运行Linux 3.12.6的4核Intel Core i7机器。

图9显示了单个TCP流的基线吞吐量，没有分段卸载，可以通过虚拟以太网链路实现，该虚拟以太网链路能够使用一个TCP流推动大约4Gb / s流量，以及使用20个流推动大约6.5Gb / s流量。在添加TPP之后，TCP流量的吞吐量降低，取决于（均匀随机）采样频率。如果采样频率是无限的，那么这些数据包都没有TPP，这表示我们设置中的最佳性能。正如我们所看到的，网络吞吐量并没有太大的变化，这表明增加/删除TPP的CPU开销很小。但是，由于头开销，应用程序吞吐量会成比例地降低。

表5显示了在三种不同的情况下，对数据平面中过滤器数量及其对网络吞吐量的影响：（i）'第一'表示我们创建始终匹配第一条规则的流量，（ii）'最后'表示流程总是匹配最后一条规则，并且（iii）“全部”意味着至少有一条流匹配每条规则。在“第一”和“最后”中，有10个TCP流。在'全部'中，有多少规则（至少有10个数据流）有多少个数据流。每个规则在TCP目标端口上匹配。正如我们所看到的，吞吐量最多可达10条规则。使用更多规则时，吞吐量确实下降，但过滤器链中第一个（最佳情况）和最后一个规则（最差情况）之间的匹配没有区别。使用1000个流量时，其他开销（上下文切换）会导致吞吐量低得多。

7局限性

虽然TPP可以帮助解决第2节讨论的各种任务，但由于两个原因，它们不是实现任意功能的灵丹妙药：（1）受限制的指令集;（2）受限制的编程模型，其中终端主机启动任务。由于我们没有提出“网络任务”的正式理论，下面的分类既不完整也不相互排斥;它只是一个例证。

需要按数据包计算的任务：TPP中的读写指令将终端主机限制为高吞吐量网络更新，但不限于任意网络计算。作为一个例子，考虑实施主动队列管理方案的任务，例如随机公平队列，静态优先级，动态优先队列（例如pFabric [2]）和公平队列。这些任务需要对每个数据包发送和丢弃时间表进行细粒度的控制，这可以通过专用硬件或FPGA更好地实现[34]。类似地，TPP没有足够的表现力来扫描特定标记的分组（例如，使用深度分组检查的有效负载分析）。其他方法（例如中间件软件或定制数据包处理器）可以更好地满足此类任务。

事件驱动的任务：在我们讨论的例子中，所有TPP都源自终端主机。这就限制了终端主机在网络中发生状态变化时执行需要精确定时通知的任务。例如，TPP本身不能用于实现流量控制机制（例如，优先级流量控制或PFC [15]）或反应拥塞通知（如量化拥塞通知[30]和FastLane [38]）。这些任务要求网络在队列占用达到某个阈值时发送特殊数据包。然而，这并不是阻止TPP的表现，因为终端主机可以主动将TPP注入到一部分数据包中，并迅速通知网络拥塞。

8讨论

在第2节中，我们展示了TPP如何使终端主机以低延迟访问网络状态，然后可以在此状态下执行某些功能。这很有吸引力，因为它可以在软件开发时间表上部署有趣的功能。我们现在讨论一些我们尚未涉及的重要问题。

处理设备异构性：这里有两个问题：指令编码和统计寻址。首先，指令不太可能作为硬连线逻辑在ASIC中实施，而是使用微指令，为平台特定设计增加一层间接寻址。其次，我们建议有两个地址空间：（i）标准化地址空间，其中大多数重要统计数据预先加载到已知位置，例如由OpenFlow标准[29]标识的地址空间，以及（ii）平台特定地址通过它可以访问特定于供应商和交换机类型的附加统计数据。为了与多个供应商打交道，TPP可以支持间接寻址方案，以便编译器可以使用平台特定的地址预载数据包存储空间。例如，要从第1跳的Broadcom ASIC和第2跳的Intel ASIC加载队列大小，编译器会在下面生成TPP，从带外获取Broadcom的0xff00和Intel的0xfe00。为了安全起见，整个TPP包裹在CEXEC周围，如下所示：

TPP编译器可以随时查询ASIC供应商ID并在特定跳跃的设备突然改变时更改地址。但是，间接寻址限制了TPP可以进行静态分析的程度。

MTU问题：捎带的TPP附加到网络边缘的数据包（终端主机或边界路由器）。因此，如果传入数据包已经处于MTU大小，则不会有添加TPP的余地。幸运的是，这不是一个大问题，因为许多交换机支持最大9000字节的MTU。今天，覆盖网络已经在为网络虚拟化添加头[1]。

9相关工作

TPP代表了可编程网络的广泛设计空间中的一个点，从主动网络提案[33,36]所制定的基本上任意的带内程序到以交换机为中心的可编程数据平面流水线[4,7,17​​,25]，以控制器为中心的带外建议，如OpenFlow [27]和简单网络管理协议（SNMP）。我们并不认为TPP方法是一个基本上新颖的想法，因为它是主动网络的具体实现。但是，我们一直在无情地简化终端主机和交换机之间的接口，使其达到最低限度。我们相信TPP在交换机硬件线速率可能性和终端主机执行各种有用任务的足够表现力之间取得了微妙的平衡。TPP表面上类似于Sprocket，它是Smart Packets中的汇编语言[33]。然而，Sprocket代表了设计领域中更具表现力的一点。它允许循环和较大的程序，这些程序很难在硬件上以线速实现。相比较而言，TPP是一个线性程序，其执行延迟是确定性的，很小，并且在编译时已知。 TPP完全在快速路径（即路由器ASIC）上执行，而Sprocket经过慢速路径（路由器CPU），其具有数量级较低的带宽。 TPP也类似于专利[5]中描述的用于ATM网络的读/写带内控制机制;但是，我们还广泛关注如何重构有用的数据平面任务，以及如何保护网络免受恶意TPP攻击的安全策略。沃尔夫等人[37]专注于设计支持通用指令的高性能主动网络路由器。目前还不清楚他们的模型是否允许终端主机获得一致的网络状态视图。而且，ASIC不太可能以合理的成本在当今的交换容量上进行通用计算。此外，诸如OpenFlow和简单网络管理协议（SNMP）之类的带外控制机制既不能满足数据平面任务的性能要求，也不能提供网络状态的数据包一致性视图。通过数据平面展示交换机统计信息已经做了大量工作，特别是改进拥塞管理和网络监控。一个例子是显式拥塞通知，其中当出口队列占用超过可配置阈值时，路由器在IP报头中记一位。另一个例子是IP记录路由，IP选项使路由器能够在数据包上插入接口IP地址。又一个例子是思科的嵌入式逻辑分析仪模块（ELAM）[10]，它在第2层和第3层阶段跟踪ASIC内的数据包路径，并生成网络控制层的摘要。我们不采用预测未来需求和设计特定解决方案的做法，而是采用更通用，独立于协议的方式来访问交换机状态。

10结论

我们着眼于快速将新的数据平面功能引入网络。我们展示了如何通过提供编程接口，使用哪些终端主机可以使用微小的数据包程序直接查询和操作网络状态。TPP同时支持：其中每个端主机参与一个任务（例如，RCP *拥塞控制）分布式编程模型，以及中央控制器可以监视和编程逻辑网络的集中式模型。我们证明了TPP使能够在终端主机有用的应用程序称为可能：那些可以与网络合作，获得了前所未有的可视性，将数据平面事件使用实际数据包来进行监测，明确的定位网络问题，不受控制平面不能及时提供这种状态的能力的限制以网络视角进行执行。