YaNFD-paper阅读

YaNFD: Yet another Named Data Networking Forwarding Daemon

0. 摘要：

开发了 YaNFD 作为 NDN 的新软件数据包转发器。 YaNFD 实现了与现有 NDN 应用程序和转发器的兼容性，以及高吞吐量。 YaNFD 具有多线程转发功能，与现有实现相比，代码库更小、更精简，并且可以使用现有的 NDN 转发器管理实用程序和协议进行管理。在本文中，我们讨论了我们的实现，包括它与以前的转发器的不同之处，基于它们在多年的开发和使用过程中获得的经验教训。
此外，我们还展示了从零开始为 NDN 开发新转发器的经验中吸取的经验教训。

1. 介绍:

​ 命名数据网络 [32] (NDN) 网络架构的开发是为了响应互联网流量从主机到主机通信（例如，文件传输和电子邮件）到内容检索（例如，流视频）的逐渐转变。 NDN 将 IP 的无状态、基于推送的模型替换为对命名的、安全的数据片段的有状态、基于拉取的请求。 因为 NDN 将语义上有意义的应用层标识符下推到网络层，所以主机标识符不用于请求内容，从而消除了它们在核心转发过程中的使用。
​ 由于 NDN 的有状态转发机制需要与 IP 的无状态转发截然不同的数据平面架构，因此需要新的数据包转发器实现。 由于NDN仍在开发中，这些转发器不是在硬件（在路由器上）或内核（在终端主机上）中实现的，因为它们用于 IP - 相反，它们作为用户空间软件运行。
​ 多年来，NDN 中用于实验和开发的主要转发器一直是 NDN 转发守护进程 (NFD) [24]。 NFD 是第一批专门为 NDN 设计的转发器之一，它的开发产生了许多创新的解决方案来解决 NDN 的状态转发平面引入的问题。 然而，NFD在某些场景下受限于其复杂的单线程转发实现和重量级的存储和编译需求。 因此，针对物联网或高速网络核心等具有不同需求的其他场景开发了新的转发器。 尽管如此，直到最近，还没有尝试为通用计算边缘（例如个人计算机和家庭路由器）提供 NFD 的替代品。 一个例外是最近在 [5] 中报告的一项工作，它扩展了 NFD 以提供多线程支持，并证明了对 NFD 的显着改进。
​ 鉴于有机会为计算边缘创建更高效的 NDN 转发器，我们从头开始设计了一个新的转发器，称为 YaNFD 1。YaNFD 不继承 NFD 的任何代码，而是用现代高级编程语言 Go 编写的。
​ 从头开始设计 YaNFD 让我们有机会评估 NFD 中的哪些功能对于 NDN 转发是必要的，以及我们可以安全地丢弃或替换哪些功能。 因此，我们简化了 NDN 转发管道，并避免了许多因将现有代码库改编为仍在积极开发中的规范 [20] 而产生的陷阱。 我们的评估表明，YaNFD 能够实现比 NFD 更好的性能，同时具有显着更小的代码库和存储空间。 此外，我们进一步证明了 NDN 的多线程转发不仅速度更快，而且设计起来非常可行且易于实现。

2. 背景

​ 在本节中，我们将概述命名数据网络 (NDN) 架构（第 2.1 节）和现有的 NDN 软件数据包转发器，包括从这些转发器中吸取的经验教训（第 2.2 节）。

2.1 命名数据网络

​ 命名数据网络 (NDN) 是一种网络架构，它与当今 Internet 上使用的 IP 网络架构完全不同 [16, 32]。 NDN是一种以信息为中心的网络（ICN）架构，意味着它推动了语义上有意义的应用层中使用的内容标识符向下延伸到网络层。 这允许直接在内容“名称”上执行转发，而不是可能不相关的主机标识符。
​ NDN 的设计提供了许多好处和优化 [32]，这需要应用层解决方法或基于主机标识符（例如 IP）的架构中的复杂方案。 这些包括隐式多路径转发、隐式多播、隐式多宿主、环路检测、网络内缓存和语义上有意义的安全策略，可以使用相同的机制保护传输和存储中的数据[33]。
​ 与 IP 中使用的无状态转发平面相比，其中许多功能是通过 NDN 使用有状态转发平面 [31] 启用的。 这个有状态的转发平面由几个具有不同用途的数据结构组成：

• 待处理兴趣表 (PIT) 跟踪未完成的内容请求（称为“兴趣”），这些请求通过返回内容片段（在“数据”包中发送）来满足。 数据包可以匹配名称与其名称完全匹配或前缀的兴趣。 精确匹配是默认行为 [20]，但可以通过添加标志字段为特定兴趣启用前缀匹配。 PIT 还用于聚合对相同内容名称的请求，并允许通过在每个兴趣包中包含随机生成的“nonce”字段来检测循环。
• 转发信息库 (FIB) 在转发过程中提供对 NDN 分层内容名称的最长前缀匹配。 它的匹配行为类似于 IP 设备中的转发表。
• 路由信息库 (RIB) 存储和聚合从各种来源（包括路由协议、手动设置的路由和应用程序通告）获知的内容的路由。 它的内容会定期“扁平化”到 FIB 中，以便在转发过程中进行快速查找，而不需要解析更大、更复杂的 RIB。
• 内容存储(CS) 缓存最近转发的数据包，以便它们可用于满足相同或相似内容的未来兴趣（使用精确或最长前缀匹配，如在PIT 中）。
• Dead Nonce List (DNL) 为兴趣包提供长期循环检测。 已“过期”的 PIT 条目的名称和随机数被移动到 DNL 以减少 PIT 的存储开销。 与 PIT 类似，它将兴趣的名称和随机生成的“nonce”字段与存储的记录进行比较，如果匹配则将其删除。
  然而，在大多数 NDN 转发器中，这种匹配是使用概率散列来执行的，以进一步减少存储和查找开销。
• 策略表指示哪个“转发策略”将对给定前缀做出转发决策（使用最长前缀匹配）。 转发策略基于每个数据包做出转发决策。 它们作为集成到转发器中的模块运行，以允许应用程序灵活地转发它们的兴趣。 策略确定将在哪些下一跳兴趣发送，甚至可以选择丢弃兴趣而不进一步转发。 这可以为任意名称前缀设置策略选择，允许为网络中的每个应用程序（或应用程序的一部分）设置最佳转发策略，而不是像IP的数据包那样采用一刀切的方法。在当前的转发器中，必须在网络中的每个转发器上单独更改策略设置。

​ 转发的数据包在“face”上发送和接收，在 NDN 中，face可以是与同一主机上的生产者或消费者应用程序的本地连接，也可以是通过物理接口或覆盖隧道到远程转发器的连接。 这允许转发器对所有连接进行类似的处理，大大简化了转发逻辑。

2.2 现存的转发器

​ NDN 项目已经积极开发和使用了十多年，在此期间，已经开发了多个软件数据包转发器来支持研究和软件开发。 我们依次评估这些转发器中的每一个，讨论它们的优缺点，以及我们从每个转发器的开发和使用中获得的经验教训。

2.2.1 CCNx。 在 NDN 项目的最初几年，现有的用于 ICN 内容的 CCNx 转发器 [8] 被用于研发工作。 然而，由于 NDN 项目不断变化的需求以及随着架构得到更多使用而吸取的经验教训，因此决定实施一个新的转发器，称为 NFD（稍后将讨论）。 CCNx 做了几项创新，后来被纳入 NFD，例如将 PIT、FIB 和 CS 组合成一个数据结构，称为“名称树”。 但是，由于 NDN 协议和转发规范与 CCNx 使用的规范不同，CCNx 现在与 NDN 规范不兼容。

2.2.2 NFD。 命名数据网络转发守护进程（或 NFD）[24] 被设计为 NDN 的通用软件数据包转发器，于 2014 年开始实施。
NFD 是 NDN 项目事实上的“官方”转发器，多年来随着 NDN 架构和规范的变化而得到广泛的维护和重构。 值得注意的是，虽然 NFD 是 NDN 协议的参考实现，但它并不是协议的规范，是一个单独的文档 [20]。 因此，仅仅因为 NFD 以某种方式运行，这并不要求每个其他转发器都以相同的方式运行以兼容 NDN 协议。 这种差异也可以被认为如下：协议规范规定了与 NDN 兼容的“什么”必须和可以做什么，而 NFD 实现提供了一种“如何”实现这种行为的方式。
NFD 的设计考虑了灵活性，是当前通用边缘环境（例如个人计算机）的首选转发器，并用于官方公共 NDN 项目测试平台 [21]。 此外，NFD 的设计已被广泛记录 [3]。
NFD 最显着的限制之一是它仅在其整个转发管道中使用单个线程，包括接收数据包、处理它们，然后再次将它们发送出去——这可能会限制其转发吞吐量。 此外，大多数管理层操作并在主转发线程中执行（RIB 管理除外）。 此外，NFD 在设计时考虑了模块化，因此具有许多通用接口，这些接口很少扩展到一两个具体实现之外。 例如，NFD 的face系统非常精细，理论上可以轻松地交换链路层服务和底层传输机制。
然而，在撰写本文时，只有一个链接服务的具体实现已添加到 NFD（NDNLPv2 链接服务 [23]）中，尽管多年来其设计已得到改进，但转发器中的其他组件已实现 期望与 NDNLPv2 兼容的链接服务，这与 NFD 的face系统中真正模块化的理想背道而驰。 这些设计目标还使 NFD 代码库变得相当复杂，令新开发人员望而生畏，可能会阻止他们改进 NFD 或在需要更改实现的场景中使用它。
尽管上述问题在 NFD 代码库中普遍存在，但可以从 NFD 的创新和开发过程中汲取到许多好的经验教训。 NFD 代码库的一般结构很好地隔离了不相关的组件组，例如将转发层与face层分开。 此外，在某些情况下，模块化做得很好并且经常用于提供新功能，例如转发策略系统——这个扩展点多年来被广泛使用，特别是在研究文献中 [1, 6, 17, 18 ]。 此外，NFD 将多个数据结构 [31]（即 FIB、PIT、策略表和测量表）集成到单个数据结构中，如 CCNx 的名称树，以减少存储开销 [3]。

2.2.3 ndn-lite。 尽管 NFD 具有多功能性，但它在资源需求和编译开销方面可能相当“重量级”。
这对于在功率和内存方面存在重大系统限制的移动和受限边缘设备来说并不理想。 这些限制导致了 ndn-lite [19] 转发器的发展。 鉴于移动设备和相关设备的限制，ndn-lite 做出了几个旨在简化转发器设计和代码库的设计决策。 ndn-lite 和其他转发器之间最显着的区别是 ndn-lite 与使用它的本地应用程序在同一线程中运行，而不是作为通过基于套接字的face与应用程序通信的单独进程。 虽然这意味着单个转发器只能支持单个应用程序，但它还允许消除维护和使用到/来自所述应用程序的转发器的网络连接的开销。
ndn-lite 所做的另一个简化是从转发管道中删除否定确认（或“Nacks”）。当上游转发器由于某种原因（例如没有匹配的路由、链接太拥塞或兴趣与另一个最近的兴趣重复）无法进一步转发兴趣时，会发送 Nacks。 Nacks 通过添加必须单独处理的第三种类型的数据包来增加 NDN 转发管道的复杂性。 事实上，有人建议 Nacks，作为 NDN 转发管道的后期添加，由于数据包排序 [15] 以意想不到的方式影响转发。 此外，还存在与使用网络层 Nacks [7] 相关的安全问题。相反，超时可以用作需要从消费者应用程序重新传输兴趣的指示。

​ 从 ndn-lite 的简化设计中，我们可以了解到，去除过多的特征和过于复杂的设计方面（例如错误的模块化和过多的网络层管道）可以减少转发器代码库的大小和复杂性，从而使设计更加清晰和增加 如果将来的情况需要进行此类更改，则易于修改。 此外，通过缩小转发器设计运行的场景范围，可以做出更好的假设，从而优化转发器性能并减少转发开销。

2.2.4 NDN-DPDK。 虽然 NFD 在设计时考虑了研发，但如上所述，它可能会遇到大规模的性能问题。 因此，随着 NDN 走向更大规模的部署，它将无法跟上核心网络的需求。 NDN-DPDK [28] 转发器专为高吞吐量网络而设计，能够以高达 100 Gbps 的速率转发 NDN 流量，同时在通用但高性能的计算硬件上运行。 NDN-DPDK 通过使用数据平面开发套件 (DPDK) [10] 系统处理接收到的数据包，能够显着优于其他转发器。 使用 DPDK 允许转发器绕过操作系统的网络堆栈，直接在用户空间执行高速网络数据包处理。
为了实现高性能转发，NDN-DPDK 进行了多项设计改进，包括使用多个转发线程、每个物理接口上的输入和输出单独线程以及更高效的查找算法。
当使用多个线程时，最重要的考虑因素之一是每个传入数据包将被“分派”到哪个转发线程。 NDN-DPDK 根据其名称的第一个 𝑘 组件（默认为 2）的哈希的低位来调度兴趣包——这种方案似乎与 [29] 非常相似。 由于兴趣包的转发状态仅存储在处理它的线程中，因此满足兴趣包的数据包必须分派到它们满足的兴趣包之前被分派到的同一线程。 鉴于在许多情况下，兴趣包可以通过名称“长”（就组件数量而言）的数据包来满足，NDN-DPDK 不能简单地对数据包执行类似的基于前缀的调度，就像它对兴趣包所做的那样 ，同时仍然满足其性能目标。
相反，它必须依靠“PIT 令牌”——附加到传出兴趣包并与它们各自令人满意的数据包一起返回的信息片段——来指示哪个线程应该处理数据包。 如果相邻转发器没有将 PIT 令牌附加到返回的数据包，NDN-DPDK 将无法处理它们并且此类数据包将被丢弃，需要在相邻转发器中支持此功能。

​ 然而，虽然 NDN-DPDK 能够高速转发数据包，但其系统要求使其无法在网络边缘使用。 也就是说，NDN-DPDK 不能在没有 DPDK 的情况下运行，此时，DPDK 仅支持以全转发速度运行的 NIC 设备子集 [11、25]——这些特定的 NIC 可能不存在于边缘系统上。 此外，为了实现高水平的性能，NDN-DPDK 在无限循环中运行 DPDK 轮询模式驱动程序 (PMD)，没有休眠，导致至少一个内核始终保持 100% 左右的 CPU 负载。 这在边缘环境中是不可行的，因为功耗和噪声增加的明显原因，以及降低其他应用程序的性能并可能损害用户体验。

2.2.5 MW-NFD。 Multi-Worker NFD (MW-NFD) [5] 是从 NFD 代码库的一个分支开发的 NDN 转发器。与 NFD 的单线程转发架构相比，MW-NFD 修改了 NFD 的设计以利用多线程进行转发。 MWNFD 创建一组“工作”线程来执行 NDN 的有状态数据包转发，以及为每个面创建一个输入线程。 但是，它负责将face传输到工作线程，而不是像 NDN-DPDK 中那样为每个面分配一个单独的输出线程。MW-NFD 使用与 NDN-DPDK 类似的短名称前缀调度系统（基于 第一个 𝑘 命名组件，并且默认使用 𝑘 = 2 个组件）并使用 PIT 令牌调度返回的数据包。 然而，与 NDN-DPDK 不同的是，PIT 令牌更喜欢但不是必需的，如果接收到的数据包没有附加的 PIT 令牌 [12]，它将回退到数据包的前缀调度。
在对 NFD 代码库进行修改后，MW-NFD 的作者能够证明转发速度是他们在 NFD 中使用类似流量所能达到的速度的 13 倍。 同时，它们的转发器保持与 NFD 以及与 NFD 通信的现有 NDN 应用程序的兼容性，允许它与 NFD 节点运行在同一 NDN 网络中，并为 NDN 应用程序提供相同的通信接口使用。
MW-NFD 进行了多种设计选择以允许多线程转发，包括跨线程分片数据结构——即，它们对每个工作线程的 PIT、CS、FIB 和测量表进行分片。 这需要他们开发机制以跨线程将数据正确分离为单独的数据结构，例如通过前缀分隔 FIB 条目。 然而，虽然 MW-NFD 解决了 NFD 的主要性能瓶颈，即仅使用单线程进行转发，但它继承了 NFD 代码库的许多其他限制，例如错误的模块化和复杂的代码库。 此外，MW-NFD 在其输入线程中使用接近 100% 的 CPU 利用率轮询。 即使在空闲时间，这也会对边缘设备产生重大的性能和功耗影响。

3. DESIGN

​ 如 2.2 节所述，YaNFD 的设计很大程度上受到了多个先前 NDN 转发器的设计的启发。 以上，我们试图从多年来实施和使用 NDN 转发器的经验中提取“经验教训”。 我们使用这些，以及在同一时间框架内对 NDN 协议的改进和优化，来指导我们新的 NDN 转发器的设计。在本节中，我们将讨论 NDN 使用的转发管道，然后继续布局我们的新转发器的设计，以及提供与现有 NDN 转发器相比为何做出不同设计决策的理由。

3.1 NDN转发管道

YaNFD 的转发管道大致遵循 NFD 的转发管道的设计，如 NFD 的“开发人员指南”[3] 中详细描述的。 但是，我们修改了这些管道以适应多个线程本地的使用，而不是全局的数据结构。 此外，我们修改了管道，以使用队列（利用 Go 的“通道”功能）在转发管道的不同组件之间传递数据包，而不是直接调用函数。 我们还使用通道来处理超时和类似事件，而不是 NFD 中的回调。与其他网络数据路径相比，NDN 的转发管道是不寻常的，尤其是 IP 中的那些，因为它们是有状态的，数据包专门“满足”主机先前转发的特定兴趣。 此外，NDN 的转发管道与这些现有管道不同，因为对于不同类型的数据包（即前面提到的兴趣包和数据包），网络层的转发行为不同，而不是为所有数据平面数据包提供统一的转发管道 . 我们现在提供在 YaNFD 中实现的 NDN 转发管道的高级概述，源自 [31] 和 [3]。

3.1.1 兴趣管道。

​ 当我们的转发器收到一个兴趣包时，它首先确定兴趣包的“跳数限制”字段（类似于 IP 的 TTL 字段）是否已达到零——如果是，则将其丢弃； 否则，该字段将减一。 接下来，它检查是否在非本地face上收到了兴趣，如果是，是否是本地管理命令——如果发现这样的“范围违规”，兴趣将被丢弃。 在此之后，兴趣的名称和随机数首先与死随机数列表 (DNL) 进行比较——如果在 DNL 中找到匹配项，则兴趣将被丢弃，因为这表明它正在循环 2。接下来，如果转发提示 [4] 字段存在于兴趣中，我们的转发器检查其中包含的名称是否与转发器中配置的生产者区域匹配——如果是，则转发提示字段将从兴趣中删除； 否则，该字段保持不变。
​ 执行这些检查后，我们的转发器将兴趣添加到其待定兴趣表 (PIT)。 如果发现 PIT 中已经存在匹配条目，则转发器检查 PIT 条目中是否已经存在与兴趣相同的随机数的不同face的传入face记录； 如果是这样，兴趣点将作为重复项被丢弃——如果为同一个传入face找到相同的随机数，则不会发生丢弃，因为这被视为重传而不是循环。 接下来，将取消 PIT 条目的“过期计时器”，防止 PIT 条目过期。
​ 如果 PIT 条目中没有现有的传入face记录，则将兴趣的名称与转发器的内容存储 (CS) 中的条目进行比较，以确定是否有缓存的数据包可用于满足 兴趣无需进一步转发。 如果是这样，这个缓存的数据包将在兴趣到达的face上返回——兴趣将被认为是满足的，并且 PIT 条目的到期计时器将重新启动。 否则，将在 PIT 条目中添加或更新传入face的传入face记录，并且兴趣将继续在管道中。

​ 最后，转发器确定将兴趣发送到哪个face。 如果兴趣包包含一个指示它应该发送到哪个face的字段（称为“NextHopFaceId”），转发器将使用该面。 否则，兴趣名称将与转发信息库 (FIB) 进行比较以找到适当的下一跳，然后传递到转发策略层，该层根据其特定策略的策略转发兴趣包 3. 如果在 FIB 中找不到匹配的前缀，则兴趣包将被丢弃 4.考虑到不同名称的临时本地兴趣更新 PIT 中的不同条目，有很多机会并行处理兴趣。 同时，在 PIT 之外，主要兴趣转发管道中的所有数据结构交互都是只读的，为并行化提供了极好的机会，例如通过使用读写器锁定的共享全局数据结构 [9]。

3.1.2 数据管道。

​ 数据包遵循它们满足的兴趣的反向转发路径。 在执行与兴趣相似的本地/非本地范围检查后，将数据包与 PIT 进行比较，找到所有匹配的条目（如果没有找到，数据包将被丢弃，尽管设置可以允许此类“未经请求的”数据包 为将来的兴趣缓存）。 如果找到多个匹配的 PIT 条目，则数据包将被转发到每个匹配的 PIT 条目中列出的所有下游面。 如果只找到一个匹配的 PIT 条目，则允许控制与兴趣名称匹配的最特定命名空间的转发策略来控制数据包的转发，因为转发策略之间不存在冲突的风险。
​ 数据包被缓存在 CS 中，以允许它们满足未来对相同或相似内容的兴趣。 与数据包匹配的 PIT 条目将被标记为满意，但不会立即删除 - 相反，它们将在其到期计时器到期时被删除，以允许将兴趣名称和随机数迁移到 DNL [3]。
​ 与兴趣管道不同，数据管道涉及对全局数据结构（包括 CS 和 PIT）的更多写入访问。 因此，提供并行数据管道的问题更加复杂，必须通过分片数据结构等机制来处理。我们已经在 YaNFD 的设计中解决了这些并行化障碍，如以下部分所述。

3.2 设计概述

​ YaNFD 设计的高级概述如图 1 所示。
​ 我们的设计具有用户可配置数量的转发线程（默认情况下，八个），每个face两个线程：一个用于接收（输入）和一个用于发送（输出），以及一个单独的管理线程。 我们从 NFD 继承了链路服务/传输模块化拆分（如图所示），因为这种设计允许转发器对每种类型的传输（例如，UDP、Unix 流或以太网）进行相同的处理。 在这个设计中，链路服务提供了作为链路协议一部分的通用特性——目前，我们实现了 NDNLPv2，它提供了可选的分片/重组、hopbyhop 可靠性（在撰写本文时尚未实现）、拥塞标记和其他特性 [23]。 同时，transport负责特定于接口的操作，例如从套接字或以太网数据包捕获句柄读取和写入。链接服务通过散列兴趣包的完整名称和通过数据包的 PIT 令牌将接收到的数据包传递到适当的转发线程。 YaNFD 生成的 PIT 令牌包含线程 ID 和数据包满足的特定 PIT 条目的标识符。 数据包按相应的转发线程接收的顺序排队等待处理，然后将执行其转发计算，包括在将数据包推送到适当的传出face线程队列之前将兴趣包传递给适当的转发策略， 然后它将使用其链接服务和特定于传输的机制来处理和发送数据包。

3.2.1 兴趣包分配逻辑。

​ 值得注意的是，我们的设计与 NDN-DPDK 和 MW-NFD 的不同之处在于它使用整个兴趣名称的散列来调度数据包，而不仅仅是固定长度前缀的散列。 这是因为我们假设，当大部分流量用于相同前缀时，仅使用第一个 𝑘 名称组件可能无法有效地在多个转发线程之间平均分配工作，特别是考虑到两个转发器的默认值 𝑘 有多短。 虽然作为 NDN-DPDK 的目标部署环境的核心路由器可能会在任何给定时间转发各种流量，但在边缘，很可能会在短时间内发出对相同前缀下的内容的请求 时间（例如，命名数据网络组织内 /net/named-data 下的请求）。 在执行批量数据传输时，这种行为将特别显着，其中一个大对象被分成许多段，当使用 NDN-DPDK 的调度方案时，所有这些都可能通过相同的转发线程转发。
​ 此外，由于可以通过了解散列算法（或从上游发送的 PIT 令牌对其进行逆向工程）来预测哪个转发线程将处理给定的短前缀，因此攻击者更容易通过在给定条件下发送兴趣包来选择性地过载给定的转发线程 字首。 使用全名散列，需要检查每个生成的兴趣名称是否散列到希望重载的给定线程，因为即使对于名称非常相似的兴趣，这也会有所不同。 同时，使用基于前缀的散列，可以尽可能快地在给定前缀下发送兴趣包，比对全名散列转发器执行相同的攻击需要更少的计算能力。 因此，我们在 YaNFD 中采用了不同的方法，并使用全名来进行兴趣调度。

3.2.2 全局和线程特定的数据结构。

​ 鉴于 YaNFD 中的每个转发线程都需要能够尽可能地在不阻塞其他转发线程的情况下运行，我们试图尽可能多地消除转发线程之间的可变共享状态。 在这方面，虽然 FIB 和 Strategy 表更改相对不频繁，并且仅用于转发线程的只读查找，但 PIT、Content Store 和 Dead Nonce List 被频繁修改。 同时，测量表可以通过对其中包含的值使用原子更新来实现无锁。 因此，我们将 FIB 和 Strategy 表（组合成一个基于树的数据结构以减少存储开销）以及 Measurements 表全局化。 同时，我们给每个转发线程一个单独的 PIT、Content Store 和 Dead Nonce List（前两个组合成一个基于树的数据结构以减少存储开销） 6.当需要对全局 FIB 策略表进行更新时，我们单独的管理线程将使用读写器锁 [9] 将其锁定为不被转发线程读取。 在更新 FIB 条目期间，从各种来源（例如，由管理员静态设置或源自路由协议或应用程序公告）获得的路由将被“扁平化”并从 RIB 下推到 FIB。

​ 此外，转发策略需要在转发线程之间进行分片，以避免锁定策略层中的数据结构。 如果不同线程中的转发策略需要交互，可以使用全局Measurements Table，允许无锁读写。
尽管 IP 转发平面比 NDN 转发平面要简单得多，但我们上面讨论的为 NDN 开发多线程转发平面的许多问题都可以与过去开发多线程 IP 转发器的努力进行比较。
特别是，两个转发平面都涉及必须以原子方式更新的共享数据结构，例如 NDN 中的 Pending Interest Table、FIB、Content Store 和 Strategy 表以及 IP 中的 FIB。