The Road to SDN: An Intellectual History of Programmable Networks

• 文章名称：The Road to SDN: An Intellectual History of Programmable Networks
• 文章来源：Feamster N , Rexford J , Zegura E . The Road to SDN[J]. Queue, 2013, 11(12):20-40.

ABSTRACT：

软件定义网络（SDN）是一项令人兴奋的技术，它使我们能够创新设计和管理网络，尽管这项技术似乎是突然出现的，但SDN是使计算机网络更具可编程性的长期努力的一部分。本文追溯了可编程网络（包括主动网络）的发展历史，早期分离控制和数据平面的努力，以及最近在OpenFlow和网络操作系统方面的工作。我们强调关键概念，以及推动每项创新的技术推动和应用拉动。在此过程中，我们揭穿了关于这些技术的常见神话和误解，并澄清了SDN与网络虚拟化等相关技术之间的关系

1. Introduction：

计算机网络复杂且难以管理，这些网络有很多种设备，从路由器和交换机到防火墙、网络地址转换器、服务器负载均衡器和入侵检测系统等中间盒。路由器和交换机运行复杂的分布式控制软件，通常是封闭和专有的，实现了经过多年标准化和互操作性测试的网络协议。网络管理员通常使用不同供应商甚至同一供应商的不同产品的配置接口来配置单个网络设备，尽管一些网络管理工具为配置网络提供了一个中心优势，但这些系统仍然在各个协议、机制和配置接口的级别上运行。这种运营模式减缓了创新速度，增加了复杂性，并抬高了运营网络的资本和运营成本。

软件定义网络（SDN）正在改变我们设计和管理网络的方式。

SDN有两个定义特征。首先，SDN将控制平面（决定如何处理流量）与数据平面（根据控制平面所做的决定转发流量）分离。其次，SDN合并控制平面，这样一个软件控制程序就可以控制多个数据平面元素。SDN控制平面通过定义良好的应用程序编程接口（API）对网络数据平面元素（即路由器、交换机和其他中间盒）中的状态进行直接控制。

OpenFlow就是这样一个API的突出例子。OpenFlow交换机有一个或多个数据包处理规则表，每个规则匹配一个子集的流量，并对与规则匹配的流量执行某些操作，包括丢弃、转发或泛洪。根据控制器应用程序安装的规则，OpenFlow交换机的行为可以类似于路由器、交换机、防火墙、网络地址转换器或介于两者之间的东西。

在过去的几年里，SDN在工业界获得了巨大的吸引力——许多商业交换机支持OpenFlow API。最初支持OpenFlow的供应商包括HP、NEC和Pronto，此后这个列表急剧扩展，并且出现了许多不同的控制器平台。程序员使用这些平台创建了许多应用程序，如动态访问控制、服务器负载平衡、网络虚拟化、节能网络、无缝虚拟机迁移和用户移动。早期的商业成功，如谷歌的广域交通管理系统和Nicira的网络虚拟化平台，已经引起了业界的极大关注。世界上最大的信息技术公司（例如云提供商、运营商、设备供应商和金融服务公司）加入了SDN行业联盟，如开放式网络基金会和Open Daylight方案。

尽管在过去的几年中，人们对SDN的兴奋已经变得更加明显，但SDN背后的许多想法都是在过去的二十年（或更长时间）里发展起来的。在某些方面，SDN重新考虑了早期电话网络的想法，该网络使用控制和数据平面的明确分离来简化网络管理和新服务的部署。然而，像OpenFlow这样的开放接口使得控制器平台和应用程序的创新比为狭窄的电话服务范围而设计的封闭网络的创新更多。在其他方面，SDN类似于过去对主动网络的研究，它阐述了可编程网络的愿景，尽管重点是可编程数据平面，SDN还涉及到以前在计算机网络中分离控制平面和数据平面的工作。

在这篇文章中，我们展示了可编程网络的知识历史，最终形成了今天的SDN。我们捕捉到了关键思想的演变、当今的应用“拉动”和技术“推动”，以及有助于指导下一组SDN创新的经验教训。在此过程中，我们揭穿了关于每一项技术的神话和误解，并澄清了SDN与相关技术（如网络虚拟化）之间的关系。我们的历史始于20年前，就在互联网腾飞之际，互联网惊人的成功加剧了管理和发展网络基础设施的挑战。我们专注于网络社区的创新（无论是研究人员、标准机构还是公司），尽管我们认识到，在某些情况下，这些创新是由其他领域的进步推动的，包括分布式系统、操作系统和编程语言，创建可编程网络基础设施的努力也显然与支持高速可编程分组处理的长线程有关。

在我们开始我们的故事之前，我们提醒读者，任何历史都是不完整的，比单一的故事情节可能暗示的更微妙。特别是，我们在本文中描述的大部分工作都是在使用术语“SDN”之前完成的，该术语是在一篇关于斯坦福OpenFlow项目的文章中创造的。术语“SDN”的词源本身就很复杂，尽管该术语最初用于描述斯坦福的OpenFlow项目，但此后该定义扩展到包括更广泛的一系列技术（这个词有时甚至被行业营销部门用来描述史丹福SDN项目之前不相关的想法）。因此，我们没有试图将项目之间的直接影响归因于项目之间，而是强调了想法的演变和想法之间的关系。它们代表了SDN的定义特征，不管它们是否直接影响到特定的后续研究，这些早期的一些想法可能没有直接影响到后来的想法，但我们认为，我们所概述的概念之间的联系是值得注意的，过去的这些项目可能会为未来的可持续发展网络提供新的教训。

2. The Road to SDN：

业界的目标是使计算机网络更具可编程性有助于网络管理的创新，并降低部署新服务的障碍。在本节中，我们将回顾可编程网络的早期工作，将历史分为三个阶段，如图1所示。

每个阶段对历史都有自己的贡献：

• （1）主动网络（从20世纪90年代中期到21世纪初），它在网络中引入了可编程功能，以实现更大的创新
• （2）控制和数据平面分离（从2001年到2007年左右），开发了控制和数据平面之间的开放接口
• （3）OpenFlow API和网络操作系统（2007年至2010年左右），代表了广泛采用开放接口的第一个实例，并开发了使控制数据平面分离具有可扩展性和实用性的方法。

网络虚拟化在SDN的历史演进过程中扮演着重要的角色，它在SDN出现之前就已经有了实质性的发展，但作为SDN最早的重要用例之一，网络虚拟化已经扎根于SDN之上。我们在第3节讨论了网络虚拟化及其与SDN的关系。

2.1 Active Networking

20世纪90年代初到中期，互联网蓬勃发展，其应用及吸引力远远超过了早期的文件传输和科学家电子邮件应用程序，更多样化的应用程序和更广泛的公众使用，吸引了渴望测试和部署改进网络服务的新想法的研究人员。为此，研究人员在小型实验室环境中设计并测试新的网络协议，并在大型网络上模拟行为，如果动机和资金持续存在，他们会将想法提交给互联网工程特别工作组（IETF）以使这些协议标准化。

标准化过程缓慢，最终使许多研究人员感到沮丧。于是，一些网络研究人员采用了一种开放网络控制的替代方法，大致是基于对独立PC重新编程相对容易的类比。具体地说，传统网络在任何意义上都不是“可编程”的，主动网络代表了一种激进的网络控制方法，通过设想一个编程接口（或网络api）来公开各个网络节点上的资源（例如，处理、存储和数据包队列），并支持构建应用于子集的定制功能。这种方法遭到许多互联网社区人士的憎恨，他们主张网络核心的简单性对互联网的成功至关重要。

主动网络研究计划探索了传统互联网协议栈通过IP或异步传输模式（ATM）提供服务的根本替代方案，ATM是20世纪90年代早期的另一种主要网络方式。leanslate网络架构方法随后在美国的GENI（网络创新的全球环境）和NSF Find（未来互联网设计）和欧洲的EU Fire（未来互联网研究和实验倡议）等项目中进行。

欧洲联盟——活跃的网络社区追求两种编程模式：

• 胶囊模型，其中在节点处执行的代码在数据包中的带内携带
• 可编程路由器、交换机模型，其中在节点处执行的代码由带外机制建立。

胶囊模型与主动网络联系最为密切。胶囊设想在网络上安装新的数据平面功能，在数据包中携带代码（如先前在分组无线电上的工作[88]），并使用缓存来提高代码分发的效率，而可编程路由器将可扩展性的决定直接交给网络运营商。

Technology push and use pull

鼓励主动联网的“技术推动”包括：

• 降低计算成本，使其能够在网络中投入更多的处理
• 在诸如Java的编程语言方面提供了平台可移植性和一些代码执行安全性
• 虚拟机技术保护主机，一种保护主机（在本例中是活动节点）和其他进程不受程序错误影响的机器技术

一些活跃的网络研究项目也利用了快速代码编译和形式化方法的进步，主动网络生态系统中的一个重要催化剂是资助机构的利益，特别是美国国防高级研究计划署（DARPA）从20世纪90年代中期到21世纪初创建和支持的主动网络计划。虽然并不是所有主动网络的研究工作都是由DARPA资助的，但该资助计划支持了一系列的项目，也许更重要的是，鼓励了术语和主动网络组件集的融合，从而使项目能够为GRE的整个计划做出贡献，这个整体的贡献要大于各个部分的总和。

主动网络计划强调演示和项目的互操作性，并依赖着开发工作的水平。在没有近期使用案例的情况下，一个融资机构的大胆一致的推动也可能导致一定程度的对积极网络的怀疑，这种网络通常是健康的，但可能接近敌对状态，并且可能掩盖了这项工作以及后来为提供网络可编程性所做的努力。当时文献中描述的用于主动网络的“使用拉”与今天用于激励SDN的示例非常相似。当前的问题包括网络服务提供商对开发和部署新的网络服务（所谓的网络僵化）所需的时间表感到失望，第三方对增值的兴趣，动态满足特定应用程序或网络的需求的精细控制。

对于网络环境，研究人员希望有一个能支持大规模实验的平台。此外，许多早期关于主动网络的论文都提到了包括防火墙、代理和转码器在内的中间盒的激增，每一个中间盒都必须单独部署，并且需要一个不同的（通常是特定于供应商的）编程模型。主动网络提供了对这些中间盒的统一控制，最终可以取代管理和控制这些中间盒的临时、一次性方法[74]。

有趣的是，早期的文献预示了当前网络功能虚拟化（NFV）的趋势，这也旨在为具有复杂的中间盒功能的网络提供一个统一的控制框架。

Intellectual contributions

主动网络提供了与SDN相关的智慧贡献。我们特别注意到三个方面：

• 网络中的可编程功能，以降低创新的障碍。

主动网络的研究开创了可编程网络的概念，以此来降低网络创新的障碍。SDN最初的动机通常是认为在生产网络中很难创新，并要求增加可编程性，SDN的早期愿景大多集中在控制平面可编程性上，而主动网络则更多地集中在数据平面可编程性上。也就是说，数据平面的可编程性在控制平面的努力下继续发展，数据平面的可编程性在新兴的NFV计划中再次走到了前列。

最近有关SDN的工作正在探索SDN协议（如OpenFlow）的演进，以支持更广泛的数据平面功能。此外，在OpenFlow和其他SDN技术（如FlowVisor）的设计文档中，将实验流量与源于主动网络的正常流量隔离的概念也出现在了前面和中心位置。

• 网络虚拟化，以及基于数据包头对软件程序进行多路分解的能力。

这需要支持多个编程模型的实验，这导致了对网络虚拟化的研究。主动网络产生了一个架构框架，描述了这样一个平台的组件，该平台的关键组件是一个管理共享资源的共享节点操作系统（Nodeos），一组执行环境（EES），每个环境定义一个用于数据包操作的虚拟机，以及一组在给定EE中工作以提供端到端服务，将数据包定向到依赖于头字段的特定EE上的快速模式匹配，和对适当EE的解复用。有趣的是，该模型是在Planetlab体系结构中进行的，根据该体系结构，在虚拟执行环境中运行不同的实验，数据包在其数据包头上被解复用到适当的执行环境中。将数据包分解到不同的虚拟执行环境中也被应用于虚拟化可编程硬件数据平面的设计[5]。

• 为MiddleBox编排提供统一架构的构想。

尽管在主动网络研究计划中，这一设想从未完全实现，但早期的设计文件指出，需要将广泛的中间盒功能与通用、安全的编程框架统一起来。尽管这一设想可能没有直接影响到最近关于NFV的工作，但随着我们进一步应用基于SDN的控制和协调中间盒，从主动网络研究中得到的各种教训可能会被证明是有用的。

Myths and misconceptions

主动网络包括这样一个概念，即网络API将可用于发起和接收数据包的最终用户，尽管大多数研究界人士认识到，最终用户网络程序员将是罕见的。认为数据包必然携带最终用户编写的Java代码的错误观念使主动网络研究与实际网络相去甚远，并且本质上不安全，主动网络在当时也因为无法提供实际的性能和安全性而受到批评。虽然性能并不是主动网络研究界（专注于架构、编程模型和平台）的首要考虑因素，但也有一些旨在构建高性能主动路由器的努力。类似地，虽然安全性在许多早期项目中没有得到充分的解决，但是安全主动网络环境体系结构项目是一个显著的例外。

In search of pragmatism

尽管主动网络提出了可编程网络的设想，但这些技术并未得到广泛应用，许多因素推动了技术的采用（或缺乏）。可能主动网络面临的最大障碍之一是不能立即解决问题或有一个清晰的部署路径。主动网络研究工作的一个重要教训是，数据平面的“杀手级”应用很难想象，社区提供了各种可以从网络处理中受益的应用，包括信息融合、缓存和内容分发、网络管理和特定于应用的服务质量。不幸的是，尽管性能优势可以在实验室中量化，但这些应用领域中没有一个能够充分满足紧迫需求的解决方案。接下来的工作我们将在下一小节中描述，从他们所解决的问题的范围来看，是比较温和的——只关注路由和配置管理。除了范围更窄之外，下一阶段的研究还开发了一些技术，对控制平面和数据平面的功能进行了明确的区分和分离。这种分离最终使人们有可能专注于控制平面的创新，这不仅需要进行重大改革，而且（因为它通常在软件中实现）比数据平面的创新障碍更低。

2.2 Separating Control and Data Planes

在21世纪初，流量不断增加，更加强调网络的可靠性、可预测性，性能导致网络运营商寻求更好的方法来实现某些网络管理功能，例如控制用于传输流量的路径（通常称为流量工程）。使用传统路由协议执行流量工程的方法充其量是原始的，运营商对这些方法的失望得到了一个小型、位置优越的研究人员社区的认可，他们要么为骨干网络运营商工作，要么定期与骨干网络运营商互动。这些研究人员探索了实用的、短期的方法，这些方法要么是标准驱动的，要么是使用现有协议立即部署的。具体来说，传统路由器和交换机体现了控制和数据平面之间的紧密集成，这种耦合使得各种网络管理任务，如调试配置问题和预测或控制路由行为，变得非常具有挑战性。为了应对这些挑战，各种分离数据和控制平面的努力开始出现。

Technology push and use pull

随着互联网在20世纪90年代的蓬勃发展，骨干网的链路速度迅速增长，领先的设备供应商直接在硬件上实现包转发逻辑，独立于控制平面软件。此外，互联网服务提供商（ISP）正在努力管理其网络不断扩大的规模和范围，以及对更高可靠性和新服务（如虚拟专用网络）的需求。与这两种趋势并行的是，商品计算平台的快速发展意味着服务器的内存和处理资源通常比一年或两年前部署的路由器的控制平面处理器要多得多。

这些趋势催生了两项创新：

• 控制和数据平面之间的开放接口，例如由因特网工程工作队（IETF）标准化的Forces（转发和控制元件分离）接口和Linux中Kernellevel包转发功能的Netlink接口；
• 以及网络的逻辑集中控制，如IETF的路由控制平台（RCP）和软路由器架构以及路径计算单元（PCE）协议所示。

这些创新是由行业对ISP网络中路由管理技术的需求推动的，一些早期关于分离数据和控制平面的建议也来自学术界，包括ATM网络和主动网络。

与早期关于主动网络的研究相比，这些项目侧重于网络管理中的紧迫问题，重点是：

• 网络管理员（而不是最终用户和研究人员）的创新
• 控制平面（而不是数据平面）的可编程性
• 网络范围的可见性和控制（而不是设备级别配置）。

网络管理应用包括：根据当前的流量负载选择更好的网络路径，在计划的路由更改期间最小化瞬时中断，使客户网络对流量有更大的控制，以及重定向或丢弃可疑的攻击流量。

一些控制应用程序使用传统路由器在运营的ISP网络中运行，包括部署的智能路由服务控制点（IRSCP），以在AT&T的第1层骨干网络中为虚拟专用网络客户提供增值服务。虽然这段时间的大部分工作都集中在管理单个ISP内的路由，但一些工作也提出了实现跨多个管理域的灵活路由控制的方法。

将控制功能从网络设备转移到单独的服务器上是有意义的，因为网络管理，顾名思义，是一种网络范围的活动。逻辑上集中的路由控制器是通过开源路由软件的出现而实现的，它降低了创建原型实现的障碍。服务器技术的进步意味着单个商品服务器可以存储所有的路由状态，并计算大型ISP网络的所有路由决策，这反过来又启用了简单的主备份复制策略，其中备份服务器存储与主服务器相同的状态并执行相同的计算，以确保控制器的可靠性。

Intellectual contributions

最初分离控制平面和数据平面的尝试是相对实用的，但它们代表了一种与因特网传统上紧密耦合的路径计算和包转发的重大概念性背离。将网络的控制平面和数据平面分开的努力产生了几个概念，这些概念在随后的SDN设计中得到了推广。

• 使用数据平面的开放接口进行逻辑集中控制

IETF的Forces工作组提出了一个标准的、开放的数据平面接口，以实现控制平面软件的创新。软路由器使用ForCES API允许单独的控制器在数据平面中安装转发表条目，从而能够从路由器中完全删除控制功能。不幸的是，主要路由器供应商没有采用ForCES，这妨碍了增量部署。RCP没有等待新的、开放的API出现，而是使用现有的标准控制平面协议（边界网关协议）在传统路由器中安装转发表条目，从而实现即时部署。OpenFlow还面临着类似的向后兼容性挑战和限制——特别是，最初的OpenFlow规范依赖于与商品交换机硬件功能的向后兼容性。

• 分布式状态管理

逻辑集中式路由控制器面临着涉及分布式状态管理的挑战——必须复制逻辑上集中的控制器以应对控制器故障，但复制可能会导致副本之间的状态不一致。研究人员探索了可能的故障场景和一致性要求，至少在路由控制的情况下，控制器副本不需要一般的状态管理协议，因为每个副本最终都会计算相同的路由（在学习相同的拓扑和路由信息之后）和路由协议收敛期间的暂时中断，即使使用传统协议也可以接受。为了更好的可伸缩性，每个控制器实例可以负责拓扑的单独部分，然后这些控制器实例可以相互交换路由信息，以确保一致的决策。几年后，在分布式SDN控制器的背景下，构建分布式控制器的挑战将再次出现——分布式SDN控制器面临着支持任意控制器应用的更普遍的问题，需要更复杂的分布式状态管理解决方案。

Myths and misconceptions

当这些新的架构被提出时，批评者以健康的怀疑态度看待它们，经常激烈地争论逻辑上集中的路由控制将违反“命运共享”，因为控制器可能独立于负责转发流量的设备而失败。许多网络运营商和研究人员认为，将控制平面和数据平面分离是一个固有的坏主意，因为最初没有明确说明如果控制器出现故障，这些网络将如何继续正确运行。怀疑论者还担心，逻辑上的集中控制从概念上简单的路由器模型转移到了实现分布式共识的路由器上，它们最终都对网络状态有一个共同的看法（例如，通过洪泛）。在逻辑集中控制中，每个路由器对路由选择过程的结果只有一个纯本地视图，事实上当这些项目扎根时，即使是传统的分布式路由解决方案也已经违反了这些原则。将包转发逻辑移入硬件意味着路由器的控制平面软件可能独立于数据平面而失败，类似地，分布式路由协议采用可伸缩技术，如OSPF区域和BGP路由反射器，其中网络中一个区域的路由器对其他区域的路由信息的可见性有限。

正如我们在下一节中所讨论的，控制平面和数据平面的分离有些自相矛盾，使得研究人员能够更清楚地思考分布式状态管理：控制平面和数据平面的分离促进了状态管理层的出现网络状态的一致视图。

In search of generality

主流设备供应商几乎没有动力采用像ForCES这样的标准数据平面API，因为开放API可以使新的进入者进入市场。因此，需要依赖现有的路由协议来控制数据平面，这对可编程控制器能够支持的应用范围造成了很大的限制。传统的IP路由协议计算目标IP地址块的路由，而不是基于更大范围的头字段（例如，MAC和IP地址、TCP和UDP端口号）提供更大范围的功能（例如，丢弃、泛洪或修改数据包），就像OpenFlow。最后，虽然行业原型和标准化工作取得了一些进展，但普遍采用仍然是难以捉摸的，为了拓宽控制和数据平面分离的视野，研究人员开始探索逻辑集中控制的全新体系结构。

4D项目主张四个主要层：

• 数据平面（用于基于可配置规则处理分组）
• 发现平面（用于收集拓扑和流量测量）
• 传播平面（用于安装分组处理规则）
• 决策平面（由逻辑上集中的控制器组成，这些控制器将网络级目标转换为分组处理状态）

几个小组开始设计和建造系统，将这种高层次的方法应用于新的应用领域，超出了路线控制。具体而言，Ethane项目及其直接前身Sane为企业网络中的访问控制创建了一个逻辑上集中的、流级的解决方案。Ethane根据高级安全策略将交换机减少到由控制器填充的流表，Ethane项目及其在斯坦福计算机科学系的运行部署为创建OpenFlow奠定了基础。特别是，Ethane中的简单交换机设计成为了最初OpenFlow API的基础。

2.3 OpenFlow and Network OSes

2000年代中期，受实验基础设施成功的鼓励，研究人员和资助机构对大规模网络实验的想法产生了兴趣，政府为大型“仪器”单独提供资金，这些大型“仪器”以前是留给其他学科建造昂贵的共享基础设施，如对撞机和望远镜。这种热情的一个结果是创建了全球网络创新环境（GENI），由NSF资助的GENI项目办公室和欧盟消防计划。

也有批评者指出，对基础设施的这一大笔投资并没有与使用它的精心构思的想法相匹配。在此过程中，斯坦福大学的一组研究人员创建了一个全新的项目，并将重点放在更本地化、更易处理的规模上——校园网。在OpenFlow出现之前，SDN的基本思想面临着完全可编程网络和实用主义之间的紧张关系，后者将使RealWorld部署成为可能。

OpenFlow在这两个目标之间取得了平衡，它启用了比早期路由控制器更多的功能，并通过在商品交换机中越来越多地使用商用硅芯片组来构建现有的交换机硬件。尽管依赖现有的交换机硬件在一定程度上限制了灵活性，但OpenFlow几乎可以立即部署，这使得SDN的移动既实用又大胆。

OpenFlow API的创建之后，紧接着是NOX这样的控制器平台的设计，它支持创建许多新的控制应用程序。OpenFlow交换机有一个数据包处理规则表，其中每个规则都有一个模式（与数据包头中的位匹配）、一个操作列表（例如，丢弃、溢出、转发特定接口、修改头字段或将数据包发送到控制器）、一组计数器（用于跟踪字节和数据包的数量）和优先级（消除具有重叠模式的规则之间的歧义）。在接收到数据包时，OpenFlow交换机识别最高优先级匹配规则，执行相关操作，并递增计数器。

Technology push and use pull

Intellectual contributions

Myths and misconceptions

In search of control programs and use cases

3. Network Virtualization：

在本节中，我们将讨论网络虚拟化，这是SDN早期的一个突出的“用例”。

网络虚拟化表示从底层物理设备分离的网络的抽象，网络虚拟化允许多个虚拟网络在共享基础设施上运行，并且每个虚拟网络可以具有比底层物理网络更简单（更抽象）的拓扑。例如，虚拟局域网（VLAN）提供了一个跨越多个物理子网的单一LAN的假象，多个VLAN可以在相同的交换机和路由器集合上运行。

尽管网络虚拟化在概念上独立于SDN，但近年来这两种技术之间的关系变得更加密切。在讨论网络虚拟化之前，我们有三个注意事项：

首先，一个完整的网络虚拟化历史将需要一个单独的调查，我们专注于网络虚拟化的发展，这些发展与可编程网络的创新直接相关。

第二，虽然网络虚拟化作为sdn的一个用例已经获得了显著的地位，但这个概念早于现代SDN，事实上已经与可编程网络并行发展。这两种技术实际上是紧密耦合的——可编程网络通常被认为是共享基础设施的机制（在数据中心的多个租户之间，在校园的管理组之间，或者在实验设施中进行实验），并支持不同于物理网络的逻辑网络拓扑，这两者都是网络虚拟化的核心原则。

最后，“网络虚拟化”的精确定义是难以捉摸的，对于我们讨论的一些机制（例如切片）是否代表网络虚拟化的形式，专家们自然不同意。在本文中，我们定义了网络虚拟化的范围，以包括任何有助于在底层物理网络基础设施上托管虚拟网络的技术。

Network Virtualization before SDN

多年来，网络设备一直支持以VLAN和虚拟专用网的形式创建虚拟网络。但是，只有网络管理员才能创建这些虚拟网络，并且这些虚拟网络仅限于运行现有的网络协议，因此逐步部署新技术被证明是困难的。相反，研究人员和实践者求助于运行覆盖网络，其中一小组升级的节点使用隧道在遗留网络的基础上形成自己的拓扑。在覆盖网络中，升级后的节点运行自己的控制平面协议，并通过封装数据包、通过传统网络发送数据包和在另一端解封装数据流（和控制平面消息）来相互引导数据流。Mbone（用于多播）、6bone（用于ipv6）和X-bone是早期的突出例子。

这些早期的覆盖网络由运行特殊协议的专用节点组成，希望能刺激对网络基础设施的改进。覆盖网络的概念很快扩展到包括任何安装和运行特殊应用程序的终端主机，这是受到早期对等文件共享应用程序（如Napster和Gnutella）成功推动的。除了对点对点协议的重要研究外，网络研究界重新开始了使用覆盖网络作为改善网络基础设施的方法的研究，例如弹性覆盖网络的研究，在该网络中形成了少量的通信主机集合对网络故障和性能问题作出快速反应的覆盖层。

与主动网络相比，覆盖网络不需要网络设备的任何特殊支持，也不需要互联网服务提供商的合作，因此部署起来容易得多。

为了降低实验覆盖网络的障碍，研究人员开始构建虚拟实验基础设施，如Planetlab，允许多个研究人员在共享和分布式主机集合上运行自己的覆盖网络。有趣的是，Planetlab本身是一种“可编程路由器/交换机”的主动网络形式，但它使用的是一组服务器而不是网络节点，并为程序员提供了一个传统的操作系统（即Linux）。这些设计决策刺激了分布式系统研究社区的采用，导致在这个社区中原型系统实验的角色显著增加，基于共享实验平台在促进实验系统研究方面的成功，研究人员开始提倡创建共享实验平台，推动对虚拟拓扑的支持。该虚拟拓扑可以在底层网络中运行自定义协议，以使实际的实验，以运行流量并排运行。

在这个模型中，网络设备本身“托管”了虚拟拓扑，回到了早期的Tempest体系结构，其中多个虚拟ATM网络可以在同一组物理交换机上共存。Tempest体系结构甚至允许交换机转发行为使用软件控制器定义，为控制和数据平面分离工作做铺垫。

GENI倡议将虚拟化和可编程网络基础设施的概念扩展到更大的范围，为网络和分布式系统的研究建立了一个国家实验基础设施。除了实验性的基础设施，一些研究人员认为网络虚拟化可以成为未来互联网的基础，使多个网络架构同时共存（每个架构都针对不同的应用或需求进行了优化，或者由不同的业务实体运营），并随着时间的推移而发展以满足不断变化的需求。

Relationship of Network Virtualization to SDN

网络虚拟化（从逻辑网络的角度对物理网络进行抽象）显然不需要SDN。同样，SDN（逻辑集中控制平面与底层数据平面的分离）并不意味着网络虚拟化。然而，有趣的是，网络虚拟化和SDN之间的共生关系已经出现，这已经开始催化几个新的研究领域。

SDN和网络虚拟化主要有三种关系：

• SDN作为网络虚拟化的一种支持技术

云计算使网络虚拟化变得突出，因为云提供商需要一种方式，允许多个客户（或“租户”）共享同一网络基础设施。Nicira的网络虚拟化平台（Network Virtualization Platform，NVP）提供了这种抽象，而不需要底层网络硬件的任何支持,解决方案是使用覆盖网络为每个租户提供连接其所有虚拟机的单个交换机的抽象。然而，与先前在覆盖网络上的工作相比，每个覆盖节点实际上是物理网络的一个扩展——一个软件交换机（如Open vSwitch），它封装了发送到其他服务器上运行的虚拟机的流量。逻辑集中式控制器在这些虚拟交换机中安装规则，以控制如何封装数据包，并在虚拟机移动到新位置时更新这些规则。

• 网络虚拟化用于评估和测试SDN

将SDN控制应用程序与底层数据平面分离的能力，使得在将SDN控制应用程序部署到操作网络之前，可以在虚拟环境中测试和评估SDN控制应用程序。Mininet使用基于进程的虚拟化在同一物理（或虚拟）机上运行多个虚拟OpenFlow交换机、终端主机和SDN控制器，每个控制器都作为单个进程。使用基于进程的虚拟化允许Mininet模拟一个网络，在一台机器上有数百个主机和交换机。在这样的环境中，研究人员或网络运营商可以开发控制逻辑，并在生产数据平面的全面仿真上轻松地对其进行测试。一旦对控制平面进行了评估、测试和调试，就可以将其部署到实际的生产网络上。

• 虚拟化（切片）SDN

在传统网络中，虚拟化路由器或交换机是很复杂的，因为每个虚拟组件都需要运行自己的Controlplane软件实例，相比之下虚拟化“哑”SDN交换机要简单得多。FlowVisor系统使校园能够支持在承载生产流量的相同物理设备上进行联网研究的试验台，其主要思想是将业务流空间划分为“片”（Planetlab的早期工作中引入的概念），其中每个片有一个网络资源共享，由不同的SDN控制器管理。FlowVisor作为Hypervisor运行，向每个SDN控制器和底层交换机传递OpenFlow。

最近的工作建议对家庭网络进行分层控制，以允许不同的第三方服务提供商（如智能电网运营商）在网络上部署服务，而无需安装自己的基础设施，最近的工作也提出了用自己的逻辑拓扑和地址空间来表示软件定义网络的每个“片段”的方法。

Myths and misconceptions

人们经常提到所谓的“SDN的好处”——比如分摊物理资源的成本，或者在实际上来自网络虚拟化的多租户环境中动态地重新配置网络。尽管SDN有助于网络虚拟化，因此可能使其中一些功能更易于实现，但必须认识到SDN提供的功能（即数据和控制平面的分离，分布式网络状态的抽象）不能直接提供这些好处。

Exploring a broader range of use cases

尽管SDN在早期已经取得了一些实际的成功，并且确实提供了支持网络虚拟化的特定用例所急需的技术，但是需要做更多的工作来改进现有的基础设施，并探索SDN解决更广泛的用例集问题的潜力。尽管早期的SDN部署主要集中在大学校园、数据中心和私人骨干网，但最近的工作探索了SDN的应用和扩展，使其扩展到更广泛的网络设置，包括家庭网络、企业网络、Internet交换点，蜂窝核心网络，蜂窝和WiFi无线接入网络，以及终端主机应用和网络的联合管理。每一个这样的环境都会带来许多新的机遇和挑战，社区将在未来几年中探索这些机遇和挑战。

4. Conclusion：

本文介绍了可编程网络的发展历史——可编程网络的概念最初形成为主动网络，支持许多与SDN相同的愿景，但缺乏明确的用例和增量部署路径。在主动网络研究项目时代之后，钟摆从视觉转向实用主义，以数据和控制平面分离的形式，使网络更易于管理，这项工作主要集中在路由网络流量的更好的方法上，这比以前关于主动网络的工作要细得多。最终，关于OpenFlow和网络操作系统的工作在愿景和实用主义之间取得了正确的平衡，这项工作提倡对广泛的应用进行网络范围的控制，但仅依赖于交换芯片组的现有能力。现有交换机硬件的向后兼容性吸引了许多设备供应商，他们要求在不断增长的数据中心网络市场上展开竞争，当SDN在网络虚拟化中发现了一个引人注目的用例时，广泛、清晰的愿景与广泛采用的实用策略之间的平衡得到了重视。

随着可持续发展网络的不断发展，我们相信历史有重要的教训要讲。

首先，SDN技术将在“使用拉动”的基础上生存或消亡。尽管SDN通常被认为是所有网络问题的解决方案，但值得记住的是，SDN只是一个更容易解决网络管理问题的工具，SDN仅仅是把开发新应用程序和解决长期问题的能力交给我们，在这方面，我们的工作才刚刚开始。如果过去有任何迹象表明，这些新技术的发展将需要在多个时间尺度上进行创新，从长期大胆的愿景（如积极的网络）到近期创造性的问题解决（如专注于分离控制和数据平面的工作）。

第二，远见和实用主义之间的平衡仍然脆弱。SDN的大胆设想提倡各种各样的控制应用程序，然而OpenFlow对数据平面的控制仅限于包头字段上的原始匹配操作。我们应该记住，OpenFlow的最初设计是由快速采用的愿望驱动的，而不是最初的原则。支持广泛的网络服务需要更复杂的方法来分析和操作流量（例如，深度数据包检查，数据包的压缩、加密和转码），使用商品服务器（例如，x86机器）或可编程硬件（例如，FPGAS，网络处理器和/或GPU）。有趣的是，对更复杂的数据平面功能（如网络功能虚拟化）的重新兴趣，让哈肯回到了先前关于主动网络的工作中，使我们的故事更为全面。保持SDN的大胆设想需要我们继续“开箱即用”地思考网络编程的最佳方法，而不受当前技术的限制。与其简单地按照当前的OpenFlow协议设计SDN应用程序，我们应该考虑我们希望对数据平面进行什么样的控制，并用实际的部署策略来平衡这一愿景。