现代路由器体系结构与IPv6

几年前，我被邀请担任某种形式的大使-从路由器供应商和硬件的世界，到协议设计师和软件的世界-至少部分原因是，到目前为止，我已经在硬件世界做了很多年的协议专家。

我没有拿出看似合理的借口，导致在IETF 94举行的IEPG会议上进行了一次简短的演讲，后来又参加了IETF 104的一次技术深度潜水。最近，我被要求将这些想法写成一篇博客文章，并放大与IPv6相关的考虑因素。这就是那个帖子。

我们将主要讨论转发硬件及其与网络层的关系，但为了实现这一点，我想从路由器的卡通草图开始。我们将考虑使用哪些类别的处理器和设计来转发数据包，然后将重点放在其中一种处理器和设计上，更详细地介绍其优点和局限性，最后考虑其对网络层协议(尤其是IPv6)的影响。

一个不言而喻的事实是，在计算领域，最简单的方法是使用通用计算机，但当您需要大规模解决特定问题时，您会求助于专门构建的硬件。这可能是出于成本、性能或两者兼而有之的原因。

例如显卡，不起眼的图形卡已经成长为图形处理器，数据中心服务器，它剥离了台式机所需的便利设施，但这只会给数据中心操作员带来额外的成本、热量、体积、故障点和…负担。路由器。

在通用和专用之间的最佳位置也是不断变化的，这一点也是真实的。

在这篇文章中，我们将考虑使用特制的硅片进行转发的路由器，而不是使用通用处理器。

当我开始从事这项业务时，所有的东西都是使用通用处理器(68000，信不信由你，甚至IBM RT PC--“4MIP，充足的CPU！”)转发的。永远铭刻在我的记忆中，尽管演讲者的名字将保持不变)。然而，在几年内，我们开始看到第一个定制的转发芯片，现在有了一个庞大的转发硬件生态系统，它们的价位不同，针对不同的网络利基市场；其中一些是定制的，尽管越来越多的是商用硅。我不打算详细介绍每一种变体，甚至不打算列举它们；我们在这里要做的是一个具有代表性的概述。

我们可以将其视为控制平面和转发平面，转发平面被细分为用于制定和执行转发决策的逻辑(在Juniper我们将其称为数据包转发引擎或PFE)以及几个PFE之间的互连(通常称为交换矩阵)。

较小的路由器可能只有一个PFE，或者可能完全跳过结构部分，因为这是一个卡通路由器，所以我不担心如何实际连接到物理介质这一至关重要的因素。正如我们将看到的，这些简化是可以的，因为我们将重点放在PFE部分。

但首先，让我们花一点时间来看看控制平面(我没办法，我大部分时间都在控制平面上工作)。它通常由两个通用处理器组成，如果系统是在没有冗余的情况下构建的，则只有一个处理器。它们在我们的漫画中被标记为“路由引擎”，或RE(像往常一样，不同的供应商对它们有不同的称呼，但每个人都有某种控制平面处理器)。它们以某种方式连接到转发硬件，通常通过以太网(这是标有“背板”的盒子，顺便说一句，它不是互连线卡的交换矩阵)。

在转发平面一侧(标记为‘Line Card’的盒子堆栈)，我们有一个或多个嵌入式控制处理器(另一个通用处理器)集合，管理一个或多个PFE。

RE上的CPU运行路由协议、管理协议、用户界面等。它们是路由器中最重的处理器。它们甚至可能和一台典型笔记本电脑中的CPU一样强大！或者不是，出于各种原因-笔记本电脑制造商没有路由器的相同认证要求，此外，路由器的工作最终是传输数据包。

协议是亏损的领导者，没有人通过运行协议赚钱。机箱中占用的每立方厘米体积、控制平面消耗的功率和散热的焦耳都是创收接口…无法提供的。因此，制造商面临的压力是供应不超过所需的数量。但我离题了。

关于RES，主要要知道的是它们不会转发数据包：即使是中小型路由器的接口速度与进出RES的可用带宽之间也存在数量级的不匹配。我们可以在这篇文章的其余部分忽略他们。

让我们轻而易举地越过结构，我将无耻地将其过度简化为连接所有PFE的无限速度的互连，并看看PFE做了什么以及如何做。在最高级别，它们转发数据包。这需要：

L2和L3分析和功能-找出它是谁的数据包，应该如何处理它，应该把它送到哪里。

数据包缓冲-将数据包存储在内存中(这可以是片上或片外)，直到有空间传输它。

排队和调度-决定哪些数据包应该按照什么顺序进行，以实现公平性和实时传输保证。当队列累积时，路由器必须确定保留哪些数据包和丢弃哪些数据包(此决策应以支持优先级较高的数据包的方式进行)。

硬件实现可以是微可编程的、表驱动的或硬编码的。它们可以完全集成在单个芯片上，也可以将不同的功能分离到不同的设备上。

让我们考虑一些转发体系结构类型(通常，这不是详尽的)：

一端是转发数据包最灵活但效率最低的，我们有通用处理器。它提供了最方便的编程模型，几乎每个人都很熟悉。在低容量和(相对)低性能的应用程序中，或者在数据包转发只是正在完成的工作的一小部分的应用程序中，它们扮演着不同的角色。但是，尽管它们在转发数据包的速度和可用于此目的的编程模型方面都有了显著的进步，但当性能受到威胁时，它们不能与专用硬件相提并论。

当你考虑TANSTAAFL的铁律时，就很容易看出这一点：没有免费午餐这回事。要使通用处理器在所有应用程序中都有用，它们必须具有满足所有应用程序要求的指令集和统一内存模型。这会耗费金钱、空间和电力。为什么您要在路由器中花费空间在一个令人惊叹的浮点单元或图形处理指令上，而这些指令永远不会使用？你不需要。通用处理器是一个令人惊叹的各行各业的高手，但它仍然是无能为力的高手。

频谱的其余部分牺牲了通用处理器的各种灵活性，取而代之的是性能。当把戏做得好的时候，我们只会牺牲我们本来不需要的灵活性。说“不，我的路由器不需要图形处理指令”可能是显而易见的，但大多数情况下，它更难，需要一个水晶球来预测未来。

举个键(不是双关语)为例，内存模型是一个重要的区别。通用处理器通常会提供一个包含整个数据包的缓冲区；它们可以检查所需的任何字节。更专业的转发处理器通常可以(非常)快速地访问前1n个字节，但要么没有访问权限，要么支付罚款，达到n+1或更高。因此，当处理器结束时，必须有人回答“多少字节的关键数据才够？”，即使他们确实感觉被问到“一段字符串有多长？”

它们有大量(ISH)内核，可能带有专门用于数据包处理的指令集。它们可以提供类似于通用处理器的编程模型，或者更适合于分组处理的编程模型。它们的时钟速度可能较低，分支预测和线程化等花哨功能也较少。但是，因为它们专门处理一种工作负载，即数据包处理，所以这没问题-空间最好用来提供更多的内核。

对于路由器而言，重要的性能并不在于您能够以多快的速度完成单个相对较大的作业。更确切地说，它是指运行许多小作业的速度，其中每个作业都在处理单个数据包。

对于这些，处理步骤在某种程度上是固定的：有固定数量的阶段；每个阶段都有相同的时间分配，每个阶段将其工作结果传递给下一个阶段。在一定范围内，这些阶段可以是可编程的。与通用处理器相比，它们可编程的词汇表可能非常专用，后者针对现有数据包头中的字段和结构进行定制。

有人可能会认为最不灵活的实现将缺乏竞争力，但其成本、能源和性能优势是如此巨大(与通用处理器相比，高达数量级)，以至于事实上，它们在整个行业都有广泛的应用。

如果你要买一台路由器，对于许多应用程序来说，主要问题是：它能满足我现在的需求吗？要花多少钱？它有多大？它能消耗多少能量？它有多可靠？“它有多经得起未来考验”的问题可能根本不会排在榜单的首位。因此，尽管作为一个软件人，我认为一切都应该是最大限度地可编程的，但作为一个实用主义者，我认为商业现实意味着这可能永远不会是这样的。

发生在PFE中的转发通常被称为“快速路径”。当数据包不能通过快速路径转发时，无论出于什么原因，我们都有两个选择：丢弃它，或者将其转送到“慢速路径”软件转发，可能是在嵌入式控制处理器中。

对于协议设计人员来说，这似乎是一个有吸引力的选择：偶尔出现的异常数据包不会造成任何伤害，对吧？当我们考虑规模时，问题就会出现。

即使控制处理器完全专用于转发(实际上并非如此)，它也不太可能维持与其配对的硬件转发芯片的转发速率的0.1%。请记住，控制处理器是一个“亏损领导者”。它足够强大，可以完成管理转发硬件、引导它、下载转发表等工作，但是它没有配置为数据包转发野兽。也不应该是--这是转发硬件的工作。(当数据包被传送到RE时，类似的注意事项也适用。)。

显然，这并不意味着协议永远不会改变和发展，这并不意味着，这对它来说是不可接受的。但这到底是什么意思呢？

好消息是，即使是最基本的转发器也是相当可编程的-在一定范围内。诀窍是要理解这些限制是什么，并且不要意外地越过它们。

故意跨越它们是另一回事，因为你必须这样做--有时你不打破一些鸡蛋就做不了煎蛋卷。但是，如果我的协议要求将数据包传送到慢速路径，而您的协议可以完成相同的工作，但可以保持在快速路径上，我想我知道谁的协议会在市场上获胜，而这不是我的协议。

对于协议设计人员来说，没有万能的流程图，但以下是协议设计人员应该牢记的一些原则。

我们提到的限制之一是关键数据大小。这是转发处理器在快速内存中可用的数据，而数据包的其余部分则缓存在相对较慢的内存中，处理器无法访问这些内存，或者需要付出相当大的代价。因此，要维持吞吐量，转发决策所需的一切都必须适合关键数据-L2标头、L3标头(包括任何扩展标头、隧道标头等)，以及负载平衡熵所需的任何较高层标头。如果特定处理器的关键数据是256字节，那么在头链命中字节257之前，一切都是正常的。

尽管“每个人都知道”，字段大小是否为2的幂，甚至单词是否对齐并不重要。

不过，字段的固定位置并不重要，而且总标头长度为32位的倍数是有帮助的。这意味着必须逐跳解析的报头中的TLV是昂贵的。

对于协议设计人员来说，将可选的TLV字段添加到所有东西中是非常诱人的-谁不喜欢面向未来的呢？答案是，那些必须检查快速路径上是否存在TLV的人，以及潜在地解析数量不确定的TLV的人，就是这样的人！

协议的另一个主要错误是报头没有显式指定后续报头的类型。这是一个问题，因为流水线处理器通常在开始任何查找之前解析数据包，并且插入到此解析过程中的任何附加间接都可能代价高昂。

特别是在流水线处理器中，如果报头的处理顺序与它们在数据包中的显示顺序不同，或者如果处理给定的报头需要引用不同的报头，这将是一个问题。标头应该是独立的。通常，每个报头都应该提供路由当前数据包所需的信息，或者它应该提供解释后续报头的上下文。

由于可能存在对现有标头的硬件支持，因此在可能的情况下，最好以一种新颖的方式使用已建立的标头，而不是发明新的标头。不过，需要注意的是，新颖性必须符合报头的语义；您不能将以前用作(比方说)校验和的字段说“哦，这现在是一个地址”，然后期望一个令人满意的结果。但是，取一个现有的地址，并选择以一种新的方式解释它，可能会奏效。SR-MPLS(RFC 8660)就是一个很好的例子。

等价多路径(ECMP)和链路聚合组(LAG)被广泛使用；为了将流分配给ECMP或LAG成员，路由器必须能够使用某些熵源来识别流。很重要的一点是，可以很容易地找到这些熵源，并且它们出现在关键数据中-如果头部变得太大，以至于熵(例如，来自传输头部)被推入数据包体缓冲中，这就是一个问题。保持熵源靠近数据包的顶部并且彼此靠近(从字面上的位数和协议栈的角度)都是很有帮助的。

考虑一些偏离这些指导原则的实际示例，多协议标签交换(MPLS)并没有指定MPLS堆栈之外的报头类型，它必须基于控制平面随标签值一起提供的信息进行推断。BER(RFC 8279)可以生成最多524字节的报头。IPv6段路由报头(RFC 8754)携带可选的TLV，处理器必须准备好解析这些TLV，尽管至少将它们放在报头的末尾是足够礼貌的。SRv6(RFC 8402)还在IPv6地址中嵌入“指令”；这些指令的解析受控制平面信息的影响，并影响后续报头的处理。

MPLS插图还应该用来证明，即使协议设计对于硅来说不是理想的，它仍然可以取得巨大的成功！

上面的分析是从一个角度出发的，即在网络核心或核心附近的高性能路由器，也就是大规模地传输大量数据包。当然，这并不是整个世界都是这样的，但正如那首古老的小曲所说的那样，

主机是从东海岸到西海岸的主机，没有人与靠近的主机交谈，除非不靠近的主机忙、挂起或死了。

这里的重点是，除非有某种原因可以保证协议或扩展只在有限的本地环境中部署，否则明智的做法是假设它将在BIG-I互联网上运行。当这种情况发生时，它的数据包将由我们谈论的那些高性能路由器来处理。

另一方面，并不是每台路由器都是核心路由器，其他角色的路由器可能会花费更多资源来提供功能(例如，隧道终止或加密)。这很好，只要有问题的特性的架构使得它们只在提供时产生成本即可。

在某些方面，IPv6被设计为比IPv4更适合处理器的协议；特别是，IPv4报头是可变长度的，而IPv6报头是固定长度的。那很有帮助。它还组织其选项，使得转接路由器甚至不需要尝试解析仅与目的节点相关的选项。

在其他方面，IPv6带来了比IPv4更大的挑战：由于其更大的可扩展性，IPv6有更多的选择。IPv6报头链可能会变得相当大，可以想象，当报头超出用于转发引擎存储它们的快速存储器的容量时，足以触发上述的一些问题。

对于一些在其芯片设计中没有将IPv6作为一等公民的旧设备，任何类型的扩展报头都是有问题的，它们会将数据包移出快速路径，或者以其他方式降低通过转发器的数据包速率。

(过去几年制造的)较新的设备有可能解决这个问题，但是即使芯片能够工作，在其上运行的微码可能会滞后；因此，具有扩展报头的IPv6数据包的吞吐量仍然很渺茫。

这就引出了另一个问题--假设我们对协议引入一个扩展。硅片需要多长时间才能赶上？

答案有点棘手，但过于简单化的猜测是“也许是几年？”

这是过度简化的原因有很多因素，包括现有的硅片可能已经足够灵活，可以用新的微码支持我们的扩展，还有鸡和蛋的考虑，你的扩展可能需要硅片支持才能流行，但硅片可能不想支持它，除非它变得流行起来。正是出于后一个原因，应该仔细考虑前面部分中的指导方针。

正如我们已经看到的，一旦硅被烘焙，尽管路由器的能力不一定是板上钉钉的，但它们至少是扎根在一些相当坚固的泥土中，所以引入一种全新的网络层协议是一个令人望而生畏的前景。

对IPv6来说，好消息是它的设计是合理的：在线速下处理它没有根本的障碍。

我们面临的持续挑战是实现和部署微码以利用硬件的功能。我希望在后续的博客文章中进一步探讨这一点。

感谢布莱恩·彼得森(Brian Petersen)，他的早期工作就是基于他的博客。还要感谢弗兰克·布罗克纳(Frank Brockners)和Toerless Eckert，他们是我在IETF 104的共同小组成员。最后，感谢我的杜松同事杰夫·利比(Jeff Libby)和罗恩·博尼卡(Ron Bonica)，他们让我保持诚实。当然，所有的错误都是我自己的。

John Scudder是Juniper Networks的杰出工程师，专注于路由协议设计和标准化。