济南百度网站开发,seo推广的特点,杭州认证网站建设,腾冲网站建设的公司随着互联网和数据中心流量的爆炸式增长#xff0c;SDN已经逐步取代静态路由交换设备成为构建网络的主流方式#xff0c;本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版#xff0c;完整介绍了SDN的概念、原理、架构和实现方式。原文: Softwar… 随着互联网和数据中心流量的爆炸式增长SDN已经逐步取代静态路由交换设备成为构建网络的主流方式本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版完整介绍了SDN的概念、原理、架构和实现方式。原文: Software-Defined Networks: A Systems Approach[1] 序 当我在1993年看到第一个Mosaic网页浏览器时全身都起了鸡皮疙瘩显然有大事即将发生但当时并不知道有多大。后来互联网迅速大规模爆发数以千计ISP(Internet Service Provider, 互联网服务提供商)如雨后春笋般在各地出现每个都将互联网扩展到新的范围。他们需要做的就是将可互操作的部件(传统网络设备供应商出售的商用交换机、路由器、基站和接入点)连接在一起而且不需要征求中央控制机构的许可。早期路由器简单而直接只需要支持IP协议。去中心化的控制机制让互联网迅速发展。 路由器制造商面临两难境地: 销售简单直接的设备很难维持繁荣、有利可图的业务。此外如果由简单设备组成的大型网络易于远程管理那么所有的智能(和价值)都将由网络运营商提供而不是路由器制造商。因此设备商决定只提供最少的外部API(网络管理被认为是一个笑话)路由器被新特性塞满将所有价值保留在内部。到2000年代中期ISP使用的路由器非常复杂支持数百种协议源代码超过1亿行其复杂性是有史以来最大的电话交换机的十倍以上。互联网为这种复杂性付出了高昂的代价: 路由器臃肿、耗电量大、不可靠、难以保障安全而且贵得离谱。最糟的是很难改进(ISP需要请求设备商增加新功能)而且ISP不可能自己增加新功能。网络所有者抱怨路由器供应商的钳制研究机构警告说互联网已经僵化。 本书将介绍接下来发生的事情这是一个激动人心的故事。Larry, Carmelo, Brian, Thomas和Bruce通过具体的例子和开源代码清楚的展现那些拥有以及运营大型网络的人是如何开始编写自己的代码并构建自己的交换机和路由器的。一些人选择用更简单、更容易维护的自研设备取代路由器其他人则选择将软件从路由器移到远程集中控制平面。无论选择哪条路开源成为越来越重要的部分。开源在Linux、Apache、Mozilla和Kubernetes中已经证明了自己也就可以被信任用来运行我们的网络。 本书解释了SDN运动发生的原因。本质上这是对控制权的争夺大型网络的所有者和运营商控制了网络的运行方式从设备商那里夺取了创新的关键。SDN始于数据中心由于他们无法使用现成的网络设备构建足够大规模的可扩展网络因此他们购买交换芯片自己编写软件。是的这为他们节省了资金(通常是成本的五倍或更多)但更重要的是获得了控制权。他们雇佣大量软件工程师促进了网络新思想的寒武纪大爆发使网络更可靠可更快修复并且更好的控制流量。今天也就是2021年所有的大型数据中心公司都打造了自己的网络设备通过修改开源控制软件或者自己编写、提供软件来控制自己的网络他们已经掌握了主动权互联网服务提供商和5G运营商将是下一个。预计在十年内企业和校园网络将运行在开源控制软件上通过由云进行管理。这是很好的变化只有那些拥有和运营大规模网络的人才知道如何做到最好。 这种变化被称为软件定义网络(SDN, Software Defined Networking)是网络构建方式的一场革命转向由网络运营商自行开发和维护软件。本书作者从一开始就参与了这场革命非常清楚这场革命是如何以及为什么发生的。 本书也将帮助我们看到未来的网络会是什么样子。网络系统将是一个我们可以编程的平台而不是由一堆运行标准化互操作性协议的盒子组装起来。网络所有者将通过编写任何希望的行为决定网络如何工作网络专业的学生将学习如何为分布式系统编程而不是研究传统协议的神秘细节。 对于那些对编程感兴趣的人来说网络又重新变得有趣起来这本书是一个很好的开始。 Nick McKeown 斯坦福大学, 加利福尼亚 前言 互联网正处于转型之中从捆绑专有设备转变为将网络硬件(变成通用商业硬件)与控制软件(可在云中扩展)分离开来。这种转变通常被称为软件定义网络(SDN)但由于其对市场的颠覆性从技术基础和短期工程决策中理清业务定位是一个挑战。本书希望读者需要理解的最重要的事情是基于SDN的网络是运行在商业硬件上的可伸缩分布式系统。 任何上过基础网络课程的人都知道协议栈是描述网络的规范框架无论协议栈是七层还是只有三层它塑造和限制了我们思考计算机网络的方式教材的编排也依此组织。SDN提出了另一种世界观一种伴随着新的软件栈的世界观。本书围绕这个新协议栈进行组织目的是自上而下展示SDN不会留下任何读者也许会怀疑只能用神奇的专有代码来填补的重大空白。你可以在本书最后做一些实际的编程练习以证明其软件栈是真实且完整的。 实现这一目标的重要方面是开放源代码。我们很大程度上是利用了两个社区组织的优势他们是这方面的领导者。一个是*开放计算项目(OCP, Open Compute Project)它积极指定和认证可以运行SDN软件栈的商品硬件(例如裸金属交换机)。第二个是开放网络基金会(ONF, Open Networking Foundation)*它正在积极构建可以集成到端到端解决方案中的软件组件。这个领域还有许多其他参与者从设备供应商到网络运营商、初创公司、标准机构和其他开源项目每个人都对SDN是什么和不是什么给出了不同的解释。我们讨论这些不同的视角并解释它们是如何适应更大的规划的但我们不会让这些不同点妨碍我们介绍SDN本身的全部内容。只有时间才能告诉我们SDN旅程将带我们走向何方但我们相信了解机会的可能范围非常重要。 本书假定读者对互联网有大致了解不过对交换机和路由器在转发以太网帧和IP包方面所起的作用有更深入的了解会更有帮助。链接到相关的背景信息以帮助弥合任何差距。 本书是一个演进中的工作会不断添加更新、澄清和新的材料。例如最新版本(v2.0)包含了关于网络虚拟化(第8章)和接入网络(第9章)的新章节。我们渴望听到反馈和建议以便继续改进本书。 感谢 本书所描述的软件要归功于ONF工程团队以及合作开源社区的辛勤工作感谢他们的贡献特别感谢Yi Tseng, Max Pudelko和Charles Chan感谢他们对相关学习教程的贡献本书将其囊括进来作为实践练习。同时感谢Charles Chan, Jennifer Rexford, Nick McKeown, Kentaro Ebisawa, Motonori Shindo和Sina Ebrahimi的评论和反馈。 封面图片是东京的Ueno地铁站由Athena Lam[2]发表在Unsplash[3]上。 Larry Peterson, Carmelo Cascone, Brian O’Connor, Thomas Vachuska, and Bruce Davie 2021年11月 第1章 概述 软件定义网络(SDN)是关于如何实现网络的一种方法对创新的速度有很大的影响因此这一方法非常关键。SDN并不直接解决路由、拥塞控制、流量工程、安全、移动性、可靠性或实时通信等方面的任何技术挑战但又确实为创建和部署这些问题的创新解决方案提供了新的机会。本书将讨论SDN到底是在业务和技术方面如何实现这一目标。 我们的方法是系统化探索SDN也就是说我们将探索指导实现SDN的一系列设计原则(这是一个仍在进行中的发展过程)而不只是谈论SDN的单点解决方案。我们的方法强调概念(将抽象引入网络是SDN最初案例的关键部分)但为了使讨论具体化我们还借鉴了过去六年来实现开源平台集合的经验这些平台被用于向生产网络(包括一级网络运营商)交付基于SDN的解决方案。 对软件栈的关注是本书的中心主题。由于SDN是一种构建网络的方法因此需要一组软件和硬件工件来将该方法付诸实践。我们使用的开源例子可以在GitHub上找到本书还提供了代码和实际编程练习的链接。 在深入讨论细节之前先了解一下SDN的起源故事很有帮助SDN最初是计算机科学研究社区解决互联网僵化问题的一项努力目标是使网络能够加快创新。这段历史在Feamster、Rexford和Zegura的一篇文章中有很好的描述。 延伸阅读: N. Feamster, J. Rexford, and E. Zegura. The Road to SDN: An Intellectual History of Programmable Networks[4]. SIGCOMM CCR, April 2014. 我们给这段历史加上两个脚注。第一个是2001年国家科学院的一份报告该报告将互联网的僵化问题作为主要挑战从而引起了关注。在这一过程中这份报告促成了一项长达20年的研发工作。这项研究的成果现在正直接影响着云提供商、企业和互联网服务提供商部署的网络。 延伸阅读: Looking Over the Fence at Networks: A Neighbor’s View of Networking Research[5]. The National Academies Press, 2001. 第二个是Scott Shenker对SDN智能化场景所作的标志性演讲。理解Shenker演讲的中心论点: 构建和运营网络的实践迫切需要抽象来帮助管理复杂性是理解本书中描述的系统、平台、工具和接口的关键。 延伸阅读: S. Shenker. The Future of Networking and the Past of Protocols[6]. Open Networking Summit, October 2011. 1.1 市场前景(Market Landscape) 要充分认识SDN的作用和最终影响首先要看市场格局。SDN在某种程度上被认为是一种改变市场的方式其灵感来自于计算机行业在过去几十年所经历的转变。 计算机行业在历史上是一个*垂直市场(vertical market)*这意味着想要解决某些问题(例如财务、设计、分析)的客户需要从单一供应商(通常是像IBM这样的大型主机公司)购买垂直集成的解决方案包括从底层硬件(包括处理器芯片)到运行在硬件上的操作系统再到应用程序本身的所有内容。 图1. 将垂直主机市场转变为水平市场在每个层级上都有开放接口和多种选择。 如图1所示微处理器(如Intel x86和Motorola 68000)和开源操作系统(如BSD Unix和Linux)的引入帮助将垂直市场转变为水平市场开放接口刺激了各个层面的创新。 当SDN被视为变革性倡议时是在网络产业中刺激同样变革的尝试正如2001年国家科学院的报告所观察到的网络已经僵化了。如图2所示最终目标是建立一个水平生态系统在由商用硅交换芯片构建的裸金属交换机上启用多个网络操作系统从而实现丰富的网络应用市场[1]。 [1] 术语bare-metal起源于服务器指没有安装操作系统或管理程序的机器。通过类比该术语适用于没有绑定操作系统或网络应用程序的交换机交换机的软硬件分离是SDN的核心。 图2. 垂直路由器市场向水平市场转变每个层级都有开放接口和多种选择。 这种转变的价值显而易见打开垂直整合、封闭、专有的市场可以为创新创造机会。或者换句话说通过开放接口有可能将控制权从销售网络设备的供应商转移到建设网络以满足用户需求的网络运营商。 为了更深入理解这一机会我们需要深入了解技术细节(将在下一节介绍)但认识到SDN作为改变网络行业的方式的背景故事是重要的起点。 1.2 技术前景(Technical Landscape) 要理解SDN是一种系统方法而不是单点解决方案这样有助于为方法的核心定义设计原则。构建设计空间是这部分的目标但重要的是最终状态不止一种。每个网络运营商可以自由选择不同的设计点并相应构建自己的网络。 也就是说本书着重描述SDN原则的最完整应用有时也被称为标准SDN(pure play SDN)。考虑到SDN的全部意义在于颠覆现有垂直市场因此现有供应商将提供与他们的既定商业模式相一致并且易于采用的混合解决方案。我们有时称这些混合解决方案为SDN-lite它们利用了SDN的某些方面但不是全部。除了指出这些部分解决方案的存在之外我们不打算以百科全书式的方式来介绍它们。我们的目标是描绘SDN的全部潜力并以当今最先进的技术所允许的尽可能多的深度来做到这一点。 1.2.1 分离控制平面和数据平面 SDN背后的重要思想是网络有不同的控制平面和数据平面这两个平面的分离应该被编码在开放接口中。用最基本的术语来说控制平面决定网络的行为而数据平面负责在单个数据包上实现该行为。例如控制平面的一个工作是确定数据包通过网络应该遵循的路由规则(也许通过运行BGP、OSPF、RIP这样的路由协议实现)数据平面的工作是根据路由规则转发数据包对于每个包交换机逐跳做出转发决策。 实践中分离控制面和数据面表现为并行但不同的数据结构: 控制面维护包含所有辅助信息的路由表在给定时间选择最好的路由(例如考虑可选路径各自成本以及任何策略约束)数据面维护转发表优化快速数据包处理(例如决定任何到达端口i的目的地址为D的数据包都应该通过端口j转发新目的地址为D)。路由表通常被称为*路由信息库(RIB, Routing Information Base)转发表通常被称为转发信息库(FIB, Forwarding Information Base)*如图3所示。 图3. 控制面(及其对应的RIB)与数据面(及其对应的FIB)解耦。 解耦网络控制平面和数据平面的价值没有争议这是网络中的成熟实践在SDN之前封闭/专有路由器就采用了这种级别的模块化。但是SDN的第一个原则是控制平面和数据平面之间的接口应该是定义良好且开放的这种强大的模块化通常被称为解耦它使每个平面由不同的参与方负责成为可能。 原则上解耦意味着网络运营商应该能够从供应商X处购买控制平面从供应商Y处购买数据平面。尽管这一切并没有立即发生但解耦的一个自然后果是数据平面组件(即交换机)成为通用包转发设备(通常称为裸金属交换机)所有智能都在软件中实现并在控制平面中运行[2]。这正是发生在计算机行业的事情微处理器成为了通用商业化产品。第4章更详细介绍了裸金属交换机。 [2] 根据我们的统计今天有超过15个开源和专有的解耦控制平面可用。 解耦控制平面和数据平面意味着需要定义良好的转发抽象也就是说需要一种通用的方式让控制平面指示数据平面以特定方式转发数据包。请记住解耦不应该限制交换机供应商如何实现数据平面(例如其转发表的确切形式或转发数据包的过程)这种转发抽象不应该假定(或依赖)某个数据平面的实现。 2008年引入的OpenFlow是最早的支持解耦的接口[3]。尽管它在SDN发展过程中起到了巨大作用但被证明只是今天定义SDN的一小部分。将SDN与OpenFlow等同起来明显低估了SDN的价值但它是一个重要的里程碑因为它引入了流规则(Flow Rules)作为一种简单但强大的方式来指定转发行为。 [3] OpenFlow实际上并不是第一个这样做的但它是最吸引人的。早期工作包括Ipsilon的GSMP和IETF的ForCES。 流规则是一组匹配规则和对应的动作(Match-Action pair)任何和规则匹配的数据包都应该执行相应的动作。例如一个简单的流规则可能指定任何目的地址为D的数据包在输出端口i上转发。原始的OpenFlow规范允许图4中所示的报头字段包含在规则的Match部分中。例如一个Match可能指定数据包的MAC报头Type字段等于0x800(表示帧携带IP数据包)它的IP报头DstAddr字段包含某些子网(例如192.12.69/24)。 图4. 原生OpenFlow规范匹配报文字段。 原生动作包括将数据包转发到一个或多个端口以及丢弃包或者将数据包发送到控制面从而将任何需要控制面进一步处理的数据包发送给控制器(controller)(该术语代表在控制面中负责控制交换机的进程)。随着时间的推移支持的操作集变得更加复杂稍后将继续介绍。 基于流规则抽象每个交换机维护一个流表来保存控制器传给它的流规则集。实际上流表是本节开始介绍的转发表的OpenFlow抽象。OpenFlow还定义了一个安全协议通过该协议可以在控制器和交换机之间传递流规则从而可以在交换机之外运行控制器如图5所示。 图5. 控制器将流规则安全的传递给启用了OpenFlow的交换机交换机维护流表。 随着时间的推移OpenFlow规范变得越来越复杂(当然其定义比之前介绍的精确得多)但最初的想法很简单。在当时(2008年)在传统的转发路径之外建立一个包含“OpenFlow选项”的交换机的想法非常激进是通过研究项目提出的。事实上最初的OpenFlow出版物是作为对研究界的行动呼吁而撰写的。 延伸阅读: N. McKeown, et. al. OpenFlow: Enabling Innovation in Campus Networks[7]. SIGCOMM CCR, March 2008. 今天OpenFlow规范已经经历多次修订并且正在用更灵活(即可编程)的替代方案来取代。我们将在第四章继续探讨OpenFlow和P4(另一种编程语言)。 在本节最后我们提醒注意两个相关但截然不同的概念: 控制(Control) 和 配置(Configuration) 。OpenFlow(以及一般的SDN)的思想是定义控制数据平面的接口这意味着需要对链路和交换机故障以及其他数据平面事件做出实时决策。如果数据面报告了故障控制面通常需要在毫秒内了解这个故障并提供补救(例如下发新的Match/Action流规则)否则SDN所暗示的解耦将不可行[4]。 [4] 还有一些事件需要在亚毫秒响应时间内关注。在这种情况下有必要在数据平面中实施补救措施然后通知控制平面让它有机会重新编程数据平面。OpenFlow中的快速故障转移组就是一个例子。 同时运维人员习惯于自己配置交换机和路由器在历史上他们一直使用命令行接口(CLI)或(不太常见的)像SNMP这样的管理协议来完成。回头看一下图3它对应于到RIB的北向接口(与RIB和FIB之间的接口相反)。该接口能够配置新的路由这在表面上似乎相当于配置新的流规则。如果交换机仅仅暴露了可编程配置界面而不是传统的CLI会被认为是支持SDN(SDN-capable)的吗? 答案可能是否定的最终需要在通用性和性能上都达到目标。虽然定义良好的可编程配置接口肯定是对传统CLI的改进但目的是修改控制平面的各种设置(如RIB条目)和其他设备参数(如端口速率/模式)而不是修改数据平面的FIB。因此这样的配置接口即不太可能支持控制/数据平面接口隐含的全部可编程性又不太可能支持控制/数据平面解耦所需的实时控制回路。简而言之SDN的发展势头的一个副作用是改善了交换机和路由器供应商公开的配置接口(我们将在第5章中描述这种接口的最先进技术)但这样做并不能替代SDN所需要的控制粒度。 需要说明的是交换机中的所有元素都需要配置。数据平面需要配置端口速率等内容平台需要配置风扇、LED和其他外围设备交换机软件需要知道在客户端连接时应该使用什么证书以及应该设置什么日志级别。控制平面组件也需要配置例如路由代理需要知道它的IP地址、相邻节点以及是否有静态路由。关键区别在于目的定量来说是更新速度: 配置意味着每天可能有数千次更新而控制意味着每秒可能有数千次更新。 1.2.2 控制平面: 中心化 vs 分布式 在解耦控制平面和数据平面之后接下来要考虑的是如何实现控制平面。一种选择是在交换机上运行实现控制面的软件。这样做意味着每个交换机都作为自治设备运行与整个网络中的对等交换机通信以构建本地路由表。为了方便起见已经存在一组可用于此目的的协议: BGP、OSPF、RIP等。这正是过去30多年来互联网一直采用的分布式控制平面。 这种场景自有其价值。由于解耦带来了使用商用硅交换芯片构建低成本裸金属交换机的可能性网络运营商可以从裸金属交换机供应商购买硬件然后从其他供应商购买适当的控制平面软件甚至可能使用这些软件的开源版本。这样做可能会降低成本和复杂性(因为只需要将所需的控制模块加载到设备上)但不一定能实现SDN所承诺的创新速度。因为运营商仍然停留在缓慢的标准化过程中这是今天的标准化协议所暗示的也没能实现SDN先驱们所设想的新的网络抽象(例如Shenker在上面的演讲中提到的)。 另一种选择是控制平面完全独立于数据平面并在逻辑上集中管理这是SDN的第二个设计原则。这意味着控制平面是部署在交换机之外的例如可以在云上运行控制器。为了完整起见我们注意到也可以采用混合方法在云托管的控制器中一些控制功能运行在交换机上一些运行在交换机之外。 我们说逻辑集中是因为收集状态的控制器需要维护全局数据结构(相对于在每个交换机上维护路由表)这个数据结构的实现仍然可以分布在多个服务器上通过云的最佳实践实现服务的水平扩展这对于可伸缩性和可用性都很重要其中关键是这两个平面是独立配置和扩展的。如果需要增加数据平面容量可以增加裸金属交换机。如果控制平面需要更多容量可以添加计算服务器(或者更可能的是虚拟机)。 图6. 网络操作系统(NOS)托管一组控制应用程序并为底层网络数据平面提供逻辑上集中的控制点。 图6描述了与分布式数据平面相关联的集中式控制平面但是更进一步还引入了这种方法所隐含的关键组件: *网络操作系统(Network Operating System, NOS)。服务器操作系统(如Linux, iOS、Android、Windows)提供了一组高级抽象可以更容易实现应用程序(例如,用户可以读取和写入文件而不是直接访问磁盘驱动器)NOS与此类似可以更容易实现网络控制功能也称为控制应用程序(Control Apps)*。 NOS背后的思想是抽象交换机细节并向应用开发人员提供网络分布(Network Map) 抽象。NOS检测底层网络变化(例如交换机、端口和连接的可用状态)而控制应用只是在这个抽象上实现想要的行为。这意味着NOS承担了收集网络状态的负担(分布式算法中最困难的部分例如链路状态和距离向量路由协议等)而应用可以免费使用相关抽象并在图上运行简单的最短路径算法并将构建的流规则加载到底层交换机。下面是关于链路状态(Link-State)和距离矢量路由算法(Distance-Vector routing algorithms)的在线介绍。 延伸阅读: Routing[8]. Computer Networks: A Systems Approach, 2020. 通过集中化相关逻辑可以实现以前在分布式网络中不可能实现的事情: 计算全局优化解决方案。正如在后面章节中讨论的那样已经公布的来自云供应商的证据证实了这种优势。多年来大家都很清楚互联网完全分布式的方法并不适合全局优化但直到SDN还没有真正可行的替代方案。SDN使这种可能性成为现实这就是提供集中式网络抽象的力量。 收集网络状态的想法是SDN和NOS所扮演角色的核心。我们不讨论收集网络遥测数据的所有使用方式例如解决配置错误或做长期规划但我们会谈论可能需要控制平面立即做出反应的精确控制一个明显的例子是每个端口上发送和接收的字节/数据包的数量。像OpenFlow这样的协议定义了向NOS报告此类统计报告的方法此外还为NOS提供了基于其收集的信息配置新流规则的方法。 中心化控制平面还有一个相关好处随着我们讨论SDN用例这个好处将变得更加清晰。逻辑集中的控制平面提供了单一的网络公开API。将可编程API放在单个交换机和路由器上的想法已经出现了几十年但没有产生多大影响相比之下对于整个交换机或路由器集合的中心API可以支持各种各样新用例。其中包括网络虚拟化、网络自动化和网络验证。以自动化为例将BGP配置这样的事情自动化是相当困难的因为很难推断当一组BGP节点开始彼此交互时如何回应。但是如果中央控制平面公开了API可以通过API实现创建一个连接以下端点集的隔离网络那么将该请求作为自动化配置系统的一部分就相当合理了。这正是许多现代云中的情况其中网络资源和策略的供应可以与所有其他类型的操作(如绑定虚拟机或容器)一起自动化。 回到集中式控制平面与分布式控制平面的最初问题后者的支持者往往基于互联网首先采用分布式路由协议的历史原因: 规模化和容错。需要注意的是任何集中式解决方案都会导致瓶颈也就是单点故障。在服务器集群上分布式部署集中化控制平面可以缓解这两个问题因为基于分布式系统开发的技术可以确保此类集群的高可用性和可伸缩性。 关于控制平面集中化的第二个问题是由于控制平面是远程的(即在交换机之外)两个平面之间的链接增加了脆弱的攻击面。相反的观点是非SDN网络已经有(并依赖)带外管理网络所以这种攻击面由来已久。控制器可以使用这些管理网络就像其他管理软件一样。还有一种观点认为少量的集中式控制器比大量的分布式控制器所呈现的攻击面更小。可以这么说虽然意见不同但肯定有很多人支持中心化方法。 控制域(Domain of Control) 本节的集中式vs分布式框架旨在描述SDN设计空间的一个维度而不是表明网络运营商面临非此即彼的情况。有许多因素会影响给定运营商在这个问题上的决定但首先要确定SDN应用的域的范围。我们将在第2章中讨论示例用例但是网络的自然发展突出了这个思考过程。 从历史上看每个交换机都有一个控制平面实例它们在同一个机器上运行。当简单的路由器发展为机架式路由器时M个线卡通常对应有N个控制平面实例在独立的硬件上运行并通过管理网络相互通信。随着机架式路由器从普通交换机发展为多机架结构SDN提出了一种设计将转发元素集中在一个可以运行在任何地方的控制平面下并构建一个分布式系统。这样一个系统的优势在于可以使用现代技术来进行状态分发和管理而不用受制于标准关键是找到能够有可能使用集中式逻辑控制平面优化性能的域。本书介绍了SDN可以提供提供价值的几个这样的领域。 1.2.3 数据平面: 可编程与固定功能 设计空间的最后一个维度是考虑数据平面交换机是可编程的还是固定功能的我们需要多说一点交换机的实现从而理解这意味着什么。 前面我们用一个简单模型讨论交换机交换机的主要处理逻辑是从输入端口接收数据包查找目的地址的FIB(或者使用OpenFlow的术语流表)然后根据匹配的表项将数据包输出到端口或端口组这是低端交换机的合理实现策略(通用处理器上可以通过软件实现这一主处理循环)但高性能交换机采用基于硬件的转发流水线。 我们将在第4章深入介绍处理流水线但目前重要的特征是该流水线是否仅限于匹配数据包报头中的固定字段集(例如图4所示字段)并执行固定的操作或者是否将匹配的位模式和要执行的动作动态编程到交换机中。前者被称为*固定功能流水线(fixed-function pipelines)后者被称为可编程流水线(programmable pipelines)*。但首先我们必须回答这个问题: 转发流水线到底是什么? 一种方式是考虑转发流水线而不是单个流表就像前一节介绍的那样交换机实际上实现了一系列流表每个表项关注一个头字段的子集也许跟某一个流规则相关联(例如一个表项匹配MAC头一个匹配IP报头等等)给定数据包被多个流表按顺序处理这就是流水线并最终决定如何转发。图7基于OpenFlow规范给出了这种流表流水线的一般示意图。其思想是在数据包流经流水线时收集一组操作并在最后阶段作执行。 图7. OpenFlow转发流水线简单示意图。 乍一看似乎并不重要因为如图4所示的头字段都是众所周知的交换机很容易对每个包计算偏移量(例如表0匹配MAC头字段表1尝试匹配IP字段等等)。在这一点上SDN的最初想法是有意不涉及数据平面并完全专注于可编程开放控制平面但早期实施SDN控制器的经验暴露出两个问题。 第一个问题是随着SDN从研究实验阶段逐渐成熟成为传统专有交换机的可行替代品性能变得越来越重要。虽然流规则足以说明控制器想要编程到交换机中的转发行为但交换机不一定有能力以有效方式实现该功能。为了确保高转发性能流表使用高度优化的数据结构来实现这些数据结构需要专门的内存比如*三元内容寻址内存(TCAM, Ternary Content Addressable Memory)*。结果是只支持有限数量的条目这意味着控制器必须谨慎使用。 简而言之控制器必须知道流水线的详细信息以便配置一组交换机可以映射到硬件的流规则。因此许多控制应用程序隐式的绑定到特定的转发流水线。这类似于编写只能在x86处理器上运行的Java或Python程序并且不容易移植到ARM处理器上。事实证明对转发流水线有更多的控制是必要的因为我们不想将自己限制在单个供应商的流水线上还需要抽象方法来指定流水线的行为从而可以映射到任何给定交换机的物理流水线上。 第二个问题是协议栈以意想不到的方式发生了变化这意味着可能需要匹配的所有报头字段都是公开的这一假设是有缺陷的。例如虽然OpenFlow(以及早期的转发流水线)正确的包含了对VLAN标记的支持这是在企业网络中创建虚拟网络的基础但4096个可能的VLAN不足以支撑云可能承载的所有租户。 为了解决这个问题IETF引入了一种新的封装称为*虚拟可扩展LAN(VXLAN, Virtual Extensible LAN)*。与之前的方法(将虚拟以太网帧封装在另一个以太网帧中)不同VXLAN将虚拟以太网帧封装在UDP包中。图8显示了VXLAN报头以及交换机为了做出转发决定可能必须处理的所有包报头。 图8. VXLAN报头封装在UDP/IP报文中。 向OpenFlow添加对VXLAN的支持已经足够困难了因为标准的批准需要时间但是向固定功能的转发流水线添加对VXLAN的支持则是更为耗时: 需要改变硬件 有人可能会说有了VXLAN我们现在就完成了协议栈的变更但这是不可能的。例如当与HTTP一起使用时QUIC正逐渐成为TCP的替代方案。另一个即将出现的例子是MPLS vs SRv6。甚至VXLAN在某些情况下也被一种称为GENEVE的更灵活的新封装所取代。 可编程转发流水线加上可用于对流水线进行编程的高级语言是对这两个问题的一个可行应对。这两者都是在最近几年出现的以协议独立交换体系架构(PISA, Protocol Independent Switching Architecture) 和P4 编程语言的形式出现。我们将在第4章中更详细讨论这两个问题但目前最大的收获是SDN已经超越了其作为控制平面编程手段的最初目标。今天SDN还囊括了可编程数据平面的可能性。 1.3 SDN: 定义 综上所述SDN的初始定义很简单: 控制平面和转发平面在物理上相互隔离一个控制平面可以控制多台转发设备的网络。 -- 来自Nick McKeown 2013年题为软件定义网络的演讲。 这是第1.2.1节和第1.2.2节大段内容的简洁表述。从最初的定义开始SDN就被不同的利益相关方解释为更少(例如对网络设备的可编程配置接口被称为SDN)和更多(例如SDN还包括具有可编程转发流水线的交换机)本书以更广阔的视角涵盖了整个领域。 另一种定义SDN的方法是把它看作两个阶段。阶段1中网络运营商获得了控制平面的所有权现在在阶段2中他们正在控制如何在数据平面中处理数据包。第二阶段仍处于开发阶段但正如Nick McKeown所假设的那样理想的最终状态是: 网络(理想情况下)将更多的被编程更少的被运维操作。 也就是说SDN不仅仅是将控制权从设备商转移到运营商最终它是将控制权从设备商转移到运营商再转移到用户。这是一个长期目标其灵感来自于商用服务器和开源软件对计算机行业的贡献。但是我们仍然有很长的路要走所以我们在第10章中对SDN旅程的下一阶段进行了适度的预测。 延伸阅读: N. McKeown. FutureNet 2019[9]. October 2019. 你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。 微信公众号DeepNoMind 参考资料 [1] Software-Defined Networks: A Systems Approach: https://sdn.systemsapproach.org/index.html [2] Athena Lam: https://unsplash.com/thecupandtheroad [3] Unsplash: https://unsplash.com [4] The Road to SDN: An Intellectual History of Programmable Networks: https://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000012.pdf [5] Looking Over the Fence at Networks: A Neighbor’s View of Networking Research: https://www.nap.edu/read/10183/chapter/1 [6] The Future of Networking and the Past of Protocols: https://www.youtube.com/watch?vYHeyuD89n1Y [7] OpenFlow: Enabling Innovation in Campus Networks: http://ccr.sigcomm.org/online/files/p69-v38n2n-mckeown.pdf [8] Routing: https://book.systemsapproach.org/internetworking/routing.html [9] FutureNet 2019: https://www.vmware.com/futurenet/2019-event - END - 本文由 mdnice 多平台发布
