作者：英特尔亚太研发有限公司
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Linux开源网络全栈详解：从DPDK到OpenFlow试读：
前言
自1991年Linux 诞生，时间已经走过了接近三个十年。即将而立之年的 Linux早已没有了初生时的稚气，正在各个领域展示自己成熟的魅力。
以Linux为基础，也衍生出了各种开源生态，比如网络，比如存储。而生态离不开形形色色的开源项目，在人人谈开源的今天，一个又一个知名的开源项目正在全球野蛮生长。当然，本书的主题仅限于Linux开源网络生态，面对其中一个又一个扑面而来而又快速更迭的新项目新名词，我们会有一定的紧迫感想去了解这些他们背后的故事，也会有一定的动力去踏上Linux开源网络世界之旅。面对这样的一段旅途，我们心底浮现的最为愉悦的开场白或许应该是“说实话，我学习的热情从来都没有低落过。Just for Fun.”，正如Linus在自己的自传《Just for Fun》中所希望的那样。
面对Linux开源网络这么一个庞大而又杂乱的世界，让人最为惴惴不安的问题或许是：我该如何更快更好的适应这个全新的世界？人工智能与机器学习领域里研究的一个很重要的问题是“为什么我们小时候有人牵一匹马告诉我们那是马，于是之后我们看到其他的马就知道那是马了？”针对这个问题的一个结论是：我们头脑里形成了一个生物关系的拓扑，我们所认知的各种生物都会放进这个拓扑的结构里，而我们随着年纪不断成长的过程就是形成并完善各种各样或树形或环形等拓扑的过程，并以此来认知我们所面对的各种新事物。
由此可见，或许我们认知Linux开源网络世界最快也最为自然的方式就是努力在脑海里形成它的拓扑，并不断的进行细化。比如这个生态里包括了什么样的层次，每个层次里又有什么样的项目去实现，各个项目又实现了哪些服务以及功能，这些功能又是以什么样的方式实现的，等等，对于我们感兴趣的项目又可以更为细致的去勾勒它其中的脉络。就好似我们头脑里形成的有关一个城市的地图，它有哪些区，区里又有哪些标志建筑以及街道，对于我们熟悉的地方可以将它的周围进行放大细化，甚至于一个微不足道的角落。
本书的组织形式
本书的内容组织正是为了尽一切能力帮助读者能够形成有关 Linux 开源网络世界比较细致的拓扑。首先是前两章，对Linux开源网络的生态以及Linux本身对网络的支持与实现进行了阐述，希望能够帮助读者对Linux开源网络有个全面的基本的认识和了解。
第1章主要基于Linux基金会划分的开源网络技术层次框架，对Linux开源网络生态进行整体的介绍。此外，也介绍了网络有关的开源组织与标准架构。
第2章详尽的介绍了Linux虚拟网络的实现，包括Linux环境下一些网络设备的虚拟化形式，以及组建虚拟化网络时涉及到的主要技术，为更深一步对Linux开源网络生态下的开源项目展开讨论打下基础。
然后第3～7章的内容对Linux开源网络生态各个层次中处于主导地位的、较为流行的项目进行介绍。按照认识的发展规律，通过前面两章的介绍我们已经对Linux开源网络世界有了全局的认识和了解，接下来就可以以兴趣或工作需要为导向，选择一个项目进行深入的钻研和分析。这些章节的内容也是希望能够尽量帮助读者形成对相应项目的比较细致的拓扑，并不求对所有实现细节的详尽分析。
网络数据平面的性能开销复杂多样且彼此关联，第3章即对相关的优化技术与项目进行讨论，包括DPDK、OVS-DPDK、FD.IO等。
第4章讨论网络的控制面，并介绍主要开源 SDN（软件定义网络）控制器，包括OpenDaylight与Tungsten Fabric等。
第5章与第6章分别对OpenStack与Kubernetes两种主要云平台中的网络支持进行讨论。没有网络，任何虚拟机或者容器都将只是这个虚拟世界中的孤岛，不知道自己生存的价值。
第7章讨论网络世界中的大脑——编排器。内容主要涵盖两种开源的编排器，包括ONAP与OPNFV。
感谢
作为英特尔的开源技术中心，参与各个Linux开源网络项目的开发与推广是再为自然不过的事情。除了为各个开源项目的完善与稳定贡献更多的思考和代码，我们也希望能通过这本书让更多的人更快捷的融入Linux开源网络世界的大家庭。
如果没有 Sandra Rivera（英特尔高级副总裁兼网络平台事业部总经理）、Imad Sousou（英特尔公司副总裁兼系统软件产品部总经理）、Mark Skarpness（英特尔系统软件产品部副总裁兼数据中心系统软件总经理）、Timmy Labatte（网络平台事业部副总裁兼软件工程总经理）、练丽萍（英特尔系统软件产品部网络与存储研发总监）、冯晓焰（英特尔系统软件产品部安卓系统工程研发总监）、周林（网络平台事业部中国区软件开发总监）、梁冰（英特尔系统软件产品部市场总监）、王庆（英特尔系统软件产品部网络与存储研发经理）的支持，这本书不可能完成，谨在此感谢他们的关怀与帮助。
也要感谢本书的编辑孙学瑛老师与宋亚东老师，从选题到最后的定稿，整个过程中，都给予我们无私的帮助和指导。
然后要感谢参与各章内容编写的各位同事，他们是郭瑞景、陆连浩、秦凯伦、徐琛杰、应若愚、丁亮、朱礼波、黄海滨、任桥伟、梁存铭、胡雪焜、胡嘉瑜、王潇、何少鹏、姚磊、倪红军、吴菁菁、陈兆彦。为了本书的顺利完成，他们付出了很多努力。
最后感谢所有对Linux开源网络技术抱有兴趣或从事各个Linux开源网络项目工作的人，没有你们的源码与大量技术资料，本书便会成为无源之水。作者第1章 Linux开源网络
在人人谈开源的今天，看着一个又一个知名的开源项目在全球快速发展，开发者会非常想去了解这些开源项目。囿于本书的主题，我们只会努力去对Linux开源网络道出个一二三来。1.1 开源网络组织1.1.1 云计算与三大基金会
在形形色色的开源组织里，有三个巨无霸的角色，就是Linux基金会、OpenStack基金会和Apache基金会。而三大基金会又与盛极一时的云计算有着千丝万缕的关系。
整体而言，云计算的开源体系可以分为硬件、容器/虚拟化与虚拟化管理、跨容器和资源调度的管理和应用。在这几个领域里，Linux基金会关注硬件、容器及资源调度管理，在虚拟化层面，也有KVM和Xen等为人熟知的项目。在容器方面，Linux基金会和Docker联合发起了OCI（Open Container Initiative）；在跨容器和资源调度管理上，Linux 基金会和 Kubernetes 发起了 CNCF（Cloud Native Computing Foundation）。相比之下，OpenStack基金会更为聚焦，专注于虚拟化管理。（1）Linux基金会
Linux基金会的核心目标是推动Linux的发展。我们耳熟能详的Xen、KVM、CNCF等，都来自Linux基金会。
Linux基金会采用的是会员制，分为银级、金级、白金级三个等级，白金级是最高等级。Linux 基金会的会员数量不胜枚举，不过由于白金级高达50万美元的年费门槛，白金级会员却是一份短名单，仅包括思科、富士通、惠普、华为、IBM、Intel、NEC、甲骨文、高通、三星和微软等知名企业。
值得一提的是，作为白金级会员的华为，在Linux基金会成功建立了一个项目——OpenSDS，这是首个由我国主导的 Linux 基金会项目。OpenSDS 旨在为不同的云、容器、虚拟化等环境创建一个通用开放的SDS（Software Defined Storage）解决方案，提供灵活的按需供给的数据存储服务。
另外，2018年3月，由英特尔开源技术中心中国团队主导的车载虚拟化项目ACRN也被Linux基金会接受并发布。ACRN是一个专为物联网和嵌入式设备设计的管理程序，目标是创建一个灵活小巧的虚拟机管理系统。通过基于 Linux 的服务操作系统，ACRN 可以同时运行多个客户操作系统，如 Android、Linux其他发行版或RTOS，使其成为许多场景的理想选择。（2）OpenStack基金会
近些年，在开源的世界，OpenStack应该是最为红火的面孔之一。OpenStack基金会就是围绕OpenStack项目发展而来的。2012年9月，在OpenStack发行了第6个版本Folsom的时候，非营利组织OpenStack基金会成立。OpenStack基金会最初拥有24名成员，共获得了1000万美元的赞助基金，由RackSpace的Jonathan Bryce担任常务董事。OpenStack社区决定OpenStack项目从此以后都由OpenStack基金会管理。
OpenStack基金会的职责为推进OpenStack的开发、发布以及能作为云操作系统被采纳，并服务于来自全球的所有28000名个人会员。
OpenStack基金会的目标是为OpenStack开发者、用户和整个生态系统提供服务，并通过资源共享，推进 OpenStack 公有云和私有云的发展，辅助技术提供商在OpenStack中集成新兴技术，帮助开发者开发出更好的云计算软件。
OpenStack 基金会在成立之初就设立了专门的技术委员会，用来指导 OpenStack技术相关的工作。对于技术问题讨论、某项技术决策和未来技术展望，技术委员会负责提供指导性建议和意见。除此之外，技术委员会还要确保OpenStack项目的公开性、透明性、普遍性、融合性和高质量。
一般情况下，OpenStack技术委员会由13位成员组成，他们完全是由OpenStack社区中有过代码贡献的开发者投票选举出来的，通常任职6个月后需要重选。有趣的是，其中的6位成员是在每年秋天选举产生的，另外7位是在每年春季选举产生的，通过时间错开保持了该委员会成员的稳定性和延续性。技术委员会成员候选人的唯一条件是，该候选人必须是OpenStack基金会的个人成员，除此之外无其他要求。而且，技术委员会成员也可以同时在OpenStack基金会其他部门兼任职位。
而随着越来越多的用户在生产环境中使用OpenStack，以及OpenStack生态圈里越来越多的合作伙伴在云中支持OpenStack，社区指导用户使用和产品发展的使命就变得越来越重要。鉴于此，OpenStack用户委员会应运而生。
OpenStack用户委员会的主要任务是收集和归纳用户需求，并向董事会和技术委员会报告；以用户反馈的方式向开发团队提供指导；跟踪OpenStack部署和使用，并在用户中分享经验和案例；与各地OpenStack用户组一起在全球推广OpenStack。（3）Apache基金会
Apache基金会简称为ASF，在它支持的Apache项目与子项目中，所发行的软件产品都需要遵循Apache许可证。
对于开发者来说，在Apache的生态世界中，有“贡献者→提交者→成员”这样的成长路径。积极为Apache社区贡献代码、补丁或文档就能成为贡献者。通过会员的指定，能够成为提交者，就会拥有一些“特权”。提交者中的优秀分子可以“毕业”成为成员。
Apache 基金会为孵化项目提供组织、法律和财务方面的支持，目前其已经监管了数百个开源项目，包括Apache HTTP Server、Apache Hadoop、Apache Tomcat等。其中，Kylin就是中国首个Apache顶级项目。1.1.2 LFN
为了解决项目太多、协调性太差，从而导致的整个生态系统不协调的问题，2018年年初，ONAP、OPNFV、OpenDaylight、FD.IO、PDNA和SNAS等Linux基金会旗下的六大网络开源项目聚集在一起，创立了用于跨项目合作的 LFN（LF Networking Fund）。
LFN 的这六大创始开源项目，覆盖了从数据平面到控制平面、编排、自动化、端到端测试等领域，为跨项目协作提供了一个平台。通过统一的董事会管理，LFN消除不同项目之间的重叠或冗余，创建更高效的流程，加快开源网络的发展进程。
LFN 仅仅为各个项目之间的合作提供一个平台，其中的每个项目都将继续保持技术独立和发布蓝图，六个项目的技术指导委员会（TSC）保持不变，但是将由一个技术咨询委员会（TAC）监管。此外，还有一个营销顾问委员会（MAC），统一负责六个项目的市场活动。
新的组织结构解决了各个成员项目之间重复收费的问题，在LFN成立之前，成员想要加入任何一个项目都需要缴纳会员费，但是LFN成立之后只需要缴纳LFN的会员费，就可以参加已经加入及未来即将加入的任何LFN项目。1.2 网络标准及架构1.2.1 OpenFlow
作为SDN的主要实现方式，OpenFlow发展史就是SDN的发展史，对整个SDN的发展起着功不可没的作用。1.OpenFlow起源
OpenFlow起源于斯坦福大学的Clean Slate项目组，Clean Slate项目的最终目的非常大胆，是要“重新发明因特网（Reinvent the Internet）”，改变被认为已经略显不合时宜且难以进化发展的现有网络基础架构。
Clean Slate项目的学术主任（Faculty Director）——Nick McKeown教授，与他的学生Martin Casado发现，如果将传统网络设备的数据平面（Data Plane，数据转发）和控制平面（Control Plane，路由控制）相分离，通过集中式的控制器（Controller）以标准化的接口对各种网络设备进行管理和配置，那么将为网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。于是，他们于2008年4月在ACM Communications Review发表了题为OpenFlow:enabling innovation in campus networks的论文，首次提出了OpenFlow的概念。
OpenFlow将控制逻辑从网络设备中剥离出来，形成了如图1-1所示的控制转发分离架构。图1-1 OpenFlow控制转发分离架构
在OpenFlow发展的初期，为了达到更好利用现有硬件的目的，需要网络设备中内置一种稀有且昂贵的特殊内存TCAM（Ternary Content-Addressable Memory）来保存流表。
设计OpenFlow 的初衷是无须更改已搭载TCAM 的网络设备硬件，仅通过软件升级即可实现网络行为变更，能够一边考虑应用现有架构，一边构建虚拟网络，也是OpenFlow广受业界关注的原因所在。
TCAM 在初期的 OpenFlow 设计思想中占有非常重要的地位，很多网络设备中也确实都搭载了TCAM,Nick McKeown教授的论文中就有这样的表述：“目前最先进的以太网交换机和路由器都包含一个能够以线速实现防火墙、NAT、QoS 等功能并收集统计信息的流表（通常是基于TCAM 构建），而我们正是利用了这一点。”2.OpenFlow版本变迁
OpenFlow 自产生以来，一直由开放网络基金会（ONF,Open Networking Foundation，一个致力于开放标准和 SDN 应用的用户主导型组织）管理，OpenFlow协议也经历了很多个版本。
2009年年底发布的1.0版本相对比较弱，只是奠定了OpenFlow协议的基调，它反映的是早期学者对网络设备的一种理想模型假设。这种假设认为交换机有很大的TCAM表项。
但是这种假设脱离了实际，TCAM 表项资源非常宝贵，能够保存的流表非常有限，很难满足现实生产环境的需要。
分别于2011年2月与5月发布的OpenFlow1.1和1.2版本增加了很多特性，其中最重要的是引入了Group和Multi Table概念。Group是对一个或者多个端口的抽象，应用于组播或者广播，多个流表可以引用同一个组。Multi Table指的是多级流表。Group和Multi Table的提出可以很大地减少流表数量，更加贴近实际的交换机模型。
OpenFlow 1.3于2012年发布，是对1.1和1.2版本的升级，特性变得更为丰富，主要增加了 Meter 和 QOS，可以对网络带宽进行限速并进行有效的管理，从而保证服务质量。3.OpenFlow设计思路
OpenFlow协议的思路是网络设备维护一个FlowTable，并且只通过FlowTable对报文进行处理，FlowTable本身的生成、维护和下发完全由外置的控制器实现。此外，OpenFlow 交换机把传统网络中完全由交换机或路由器控制的报文转发，转换为由交换机和控制器共同完成，从而实现报文转发与路由控制的分离。控制器则通过事先规定好的接口操作OpenFlow交换机中的流表，达到数据转发的目的。
在 OpenFlow 交换机中，包含了安全通道、多级流表和组表。通过安全通道，OpenFlow 交换机可以和控制器建立基于 OpenFlow 协议的连接；而流表则用来匹配OpenFlow交换机收到的报文；组表用来定义流表需要执行的动作。4.FlowTable
OpenFlow 通过用户定义的或预设的规则匹配和处理网络包。一条 OpenFlow 的规则由匹配域、优先级、处理指令和统计数据等字段组成，如图1-2所示。图1-2 OpenFlow规则
在一条规则中，可以根据网络包在L2、L3或者L4等网络报文头的任意字段进行匹配，比如以太网帧的源MAC地址、IP包的协议类型和IP地址或者TCP/UDP的端口号等。目前OpenFlow的规范中还规定了Switch设备厂商可以有选择性地支持通配符进行匹配。OpenFlow未来还计划支持对整个数据包的任意字段进行匹配。
所有OpenFlow的规则都被组织在不同的FlowTable中，而在同一个FlowTable中，按规则的优先级进行先后匹配。一个 OpenFlow Switch 可以包含一个或者多个FlowTable，从0开始依次编号排列。
OpenFlow规范中定义了流水线式的处理流程，如图1-3所示。当网络数据包进入Switch后，必须从table 0开始依次匹配，table可以按从小到大的次序越级跳转，但不能从某一table向前跳转至编号更小的table。当数据包成功匹配一条规则后，将首先更新该规则对应的统计数据（如成功匹配数据包总数目和总字节数等），然后根据规则中的指令进行相应操作，比如跳转至后续某一table继续处理，修改或立即执行该数据包对应的Action Set等。当数据包已经处于最后一个table时，其对应的Action Set中的所有Action将被执行，包括转发至某一端口、修改数据包的某一字段、丢弃数据包等。OpenFlow规范对目前所支持的Instructions和Actions进行了完整详细的说明和定义。图1-3 数据包处理流程5.OpenFlow通信通道
OpenFlow 协议主要通过对不同类型消息的处理来实现控制器与交换机之间的路由控制。目前，OpenFlow 主要支持三种消息类型，分别是 Controller-to-Switch、Asynchronous（异步消息）及Symmetric（对称消息）。
● Controller-to-Switch：指由 Controller 发起，Switch 接收并处理的消息，主要包括Features、Configuration、Modify-State、Read-Stats和Barrier等消息。这些消息主要由Controller对Switch进行状态查询和修改配置等操作。
● Asynchronous：由Switch发送给Controller，用来通知Switch上发生的某些异步事件的消息，主要包括Packet-in、Flow-Removed、Port-Status和Error等。例如，当某一条规则因为超时而被删除时，Switch 将自动发送一条Flow-Removed消息通知Controller，以方便Controller进行相应的操作，比如重新设置相关规则。
● Symmetric：主要用来建立连接，检测对方是否在线等，都是些双向对称的消息，包括Hello、Echo与厂商自定义消息。
Hello、Features、Echo又分别包含了Request与Reply消息，每一对Request与Reply的Transaction ID相同，交换机通过ID进行识别对应事件端口。图1-4所示即为在通常的交换机事件发生时，主要经过的几个交互步骤。图1-4 OpenFlow交换机与控制器的交互过程6.OpenFlow应用
随着OpenFlow以及SDN的发展和推广，其研究和应用领域也得到了不断拓展，比如网络虚拟化、安全和访问控制、负载均衡、绿色节能，以及与传统网络设备交互和整合等。下面重点介绍网络虚拟化和负载均衡。（1）网络虚拟化——FlowVisor
网络虚拟化的本质是对底层网络的物理拓扑进行抽象，在逻辑上对网络资源进行分片或整合，从而满足各种应用对于网络的不同需求。为了达到这个目的，FlowVisor实现了一个特殊的OpenFlow Controller，可以看作其他不同用户或应用的Controller与网络设备之间的一层代理，如图1-5所示。因此，不同用户或应用可以使用自己的Controller来定义不同的网络拓扑，同时FlowVisor又可以保证这些Controller之间能够互相隔离且互不影响。图1-5 FlowVisor
FlowVisor 不仅是一个典型的 OpenFlow 应用案例，同时还是一个很好的研究平台，目前已经有很多基于FlowVisor的研究和应用。（2）负载均衡——Aster*x
传统的负载均衡方案一般需要在服务器集群的入口处，通过一个gateway监测、统计服务器的工作负载，并据此将用户请求动态地分配到负载相对较轻的服务器上。既然网络中的所有网络设备都可以通过OpenFlow进行集中式的控制和管理，同时服务器的负载又可以及时地反馈给OpenFlow Controller，那么OpenFlow就非常适合做负载均衡的工作。
如图1-6所示，基于OpenFlow的负载均衡模型Aster*x通过Host Manager和Net Manager来分别监测服务器和网络的工作负载，然后将这些信息反馈给FlowManager，这样 Flow Manager 就可以根据这些实时的负载信息，重新定义网络设备上的OpenFlow规则，从而将用户请求（即网络包）按照服务器的能力进行调整和分发。图1-6 Aster*x1.2.2 SDN
基于OpenFlow为网络带来的可编程的特性，斯坦福的Nick McKeown教授和他的团队进一步提出了SDN（Software Defined Network，软件定义网络）的概念。
SDN 将控制功能从交换机中剥离出来，形成了一个统一的、集中式的控制平面，而交换机只保留了简单的转发功能，从而形成了转发平面（数据平面）。通过控制平面对数据平面的集中化控制，SDN 为网络提供了开放的编程接口，并实现了灵活的可编程能力，从而使网络能够真正地被软件定义，达到按需定制服务、简化网络运维、灵活管理调度的目标。
在SDN中，网络设备只负责单纯的数据转发，可以采用通用的硬件。如果将网络中所有的网络设备视为被管理的硬件资源，参考操作系统的设计原理，则可以抽象出一个网络操作系统（Network OS）的概念。这个网络操作系统一方面抽象了底层网络设备的具体细节，负责与网络硬件进行交互，实现对硬件的编程控制和接口操作，同时还为上层应用访问网络设备提供了统一的管理视图和编程接口。基于这个网络操作系统，用户可以开发各种网络应用程序，通过软件定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无须关心底层网络的物理拓扑结构。1.SDN架构
SDN 采用了如图1-7所示的基本架构，集中式的控制平面和分布式的转发平面相互分离，控制平面利用控制器、转发通信接口对转发平面上的网络设备进行集中式管理。图1-7 SDN基本架构
● 基础设施层（Infrastructure Layer）：主要承担数据转发功能，由各种网络设备构成，如数据中心的网络路由器，支持OpenFlow 的硬件交换机等。
● 控制层（Control Layer）：网络转发的控制管理平面，负责管理网络的基础设施，主要组成部分为SDN控制器。SDN控制器是整个网络的大脑、控制中心，主要功能是按照配置的业务逻辑，产生对应的数据平面的流转发规则，通过下发给网络设备，控制其进行数据转发。
● 应用层（Application Layer）：指商业应用。开发者可以通过SDN控制器提供的北向接口，如 REST 接口实现应用和网络的联动，例如网络拓扑的可视化、监控等。
● 南向接口（Sorthbound Interface）:SDN 控制器对网络的控制主要通过OpenFlow、NetConf等南向接口实现，包括链路发现、拓扑管理、策略制定、表项下发等。其中，链路发现和拓扑管理主要是控制其利用南向接口的上行通道对底层交换设备上报信息进行统一的监控和统计，而策略制定和表项下发则是控制器利用南向接口的下行通道对网络设备进行统一的控制。
● 北向接口（Northbound Interface）：北向接口是通过控制器向上层应用开放的接口，其目标是使得应用能够便利地调用底层的网络资源和能力。因为北向接口是直接为应用服务的，因此其设计需要密切联系应用的业务需求，比如需要从用户、运营商或产品的角度去考量。
在SDN发展初期，控制平面的表现形式更多是以单实例的控制器出现，实现SDN的协议也以 OpenFlow 为主，因此 SDN控制器更多指的是 OpenFlow 控制器。随着SDN的发展，ONF也在白皮书中提出了SDN的架构标准。广义的SDN支持丰富的南向协议，包括OpenFlow、NetConf、OVSDB、BGPLS、PCEP及厂商协议等，可实现灵活可编程和灵活部署，支持网络虚拟化、SR路由、智能分析和调度。
与南向接口方面已有OpenFlow等国际标准不同，目前还缺少业界公认的北向接口标准。因此，北向接口的协议制定成为当前SDN领域竞争的一大焦点，不同的参与者或从各种角度提出了很多方案。据悉，目前至少有20种控制器，每种控制器都会对外提供北向接口，用于上层应用开发和资源编排。当然，对于上层的应用开发者来说，RESTful API是比较乐于采用的北向接口形式。2.SDN实现
SDN需要某种方法使控制平面能够与数据平面进行通信。OpenFlow就是这样一种方法机制，但OpenFlow并非实现SDN的唯一途径。（1）IETF定义的开放SDN架构
如图1-8所示，IETF定义的开放SDN架构的核心思路是重用当前的技术而不是OpenFlow，比如利用Netconf和已有的设备接口。IETF的Netconf使用XML来配置设备，旨在减少与自动化设备配置有关的编程工作量。这种架构充分地利用了现有设备，能够更大限度地保护已有的投资。图1-8 IETF定义的开放SDN架构（2）Overlay网络技术
如图1-9所示，是在现行的物理 IP 网络基础上建立叠加逻辑网络（Overlay Logical Network），屏蔽底层物理网络差异，实现网络资源的虚拟化，使得多个逻辑上彼此隔离的网络分区，以及多种异构的虚拟网络可以在同一共享的物理网络基础设施上共存。图1-9 Overlay网络
在网络技术领域，Overlay 是一种网络架构上叠加的虚拟化技术模式，是指建立在已有网络上的虚拟网，由逻辑节点和逻辑链路构成。其大体框架是对基础的物理IP 网络不进行大规模修改的条件下，实现应用在网络上的承载，并能与其他网络业务分离。
Overlay 网络的主要思想可被归纳为解耦、独立、控制三个方面。解耦是指将网络的控制从网络物理硬件中脱离出来，交给虚拟化的Overlay逻辑网络处理。
独立是指Overlay网络承载于物理IP网络之上，因此只要IP可达，那么相应的虚拟化网络就可以被部署，而无须对原有物理网络架构（例如原有的网络硬件、原有的服务器虚拟化解决方案、原有的网络管理系统、原有的IP地址等）做出任何改变。Overlay网络可以便捷地在现网上部署和实施，这是它最大的优势。
控制是指叠加的逻辑网络将以软件可编程的方式被统一控制，网络资源可以和计算资源、存储资源一起被统一调度和按需交付。
Overlay网络叠加的实现方案包括VXLAN、NVGRE、NVP等，主要由虚拟化技术厂商主导，比如VMware在其虚拟化平台中实现了VxLAN技术、微软在其虚拟化平台中实现了NVGRE技术，其中最典型的代表是Nicira公司提出的NVP（Network Virtualization Platform，网络虚拟化平台）。NVP支持在现有的网络基础设施上利用隧道技术屏蔽底层物理网络的实现细节，实现了网络虚拟化，并利用逻辑上集中的软件进行统一管控，实现网络资源的按需调度。
Overlay 网络叠加方案与虚拟化的整合比较便捷，但是在实际应用中，效果会受到底层网络质量的影响。同时，基于网络叠加的技术也会增加网络架构的复杂度，并降低数据的处理性能。
Overlay与SDN可以说天生就是适合互相结合的技术组合。对Overlay网络中的虚拟机进行管理和控制，而SDN恰好可以完美地做到这一点。（3）基于专用接口
基于专用接口的方案的实现思路是不改变传统网络的实现机制和工作方式，通过对网络设备的操作系统进行升级改造，在网络设备上开发出专用的 API 接口，管理人员可以通过 API 接口实现网络设备的统一配置管理和下发，改变原先需要一台台设备登录配置的手工操作方式，同时这些接口也可供用户开发网络应用，实现网络设备的可编程。典型的基于专用接口的SDN实现方案是的思科ONE架构。1.2.3 P4
现有的SDN解决方案将控制平面与转发平面分离，并提供了控制平面的可编程能力。而事实上，这种通过软件编程实现的控制平面的功能，在传统的高级交换机和路由器上也都能实现，差别只是厂商把这些功能固化在了硬件中，第三方难以介入进行定制或二次开发。虽然一些高级设备提供了 SDK，以便用户能够进行一定程度的定制，但也必须受厂商制定的规范限制，能做的事情十分有限。目前SDN所做的就是打破这些限制，让设备和网络更加灵活，让用户不被厂商的规范所绑定，从而拥有无限的可能。
现有的SDN解决方案为用户开放的是控制平面的可编程能力，那么转发平面又如何呢？在正常情况下，对于转发设备来说，数据包的解析转发流程是由设备转发芯片固化的，所以设备在协议的支持方面并不具备扩展能力。并且，厂商扩展转发芯片所支持的协议特性，甚至开发新的转发芯片以支持新的协议，代价非常高，需要将之前的硬件重新设计，这样势必导致更新的成本居高不下、时间周期长等一系列问题。所以，在一定程度上，这种将支持的协议与功能同硬件绑定的模式限制了网络的快速发展。
因此，新一代的SDN解决方案必须让转发平面也具有可编程能力，让软件能够真正定义网络和网络设备。而P4（Programming Protocol-Independent Packet Processors）正是为用户提供了这种能力，打破了硬件设备对转发平面的限制，让数据包的解析和转发流程也能通过编程去控制，使得网络及设备自上而下地真正向用户开放。
P4 起源于由 Nick 教授等联合发布的一篇论文 P4: Programming Protocol-Independent Packet Processors，该论文在SDN领域引起了极大的反响和关注度。Nick教授等人又发布了“The P4 Language Specification”“Barefoot白皮书”等文件。再之后，ONF成立了开源项目PIF，为P4提供配套的中间表示IR。
P4是一门主要用于数据平面的编程语言，可简单地将 P4 语言与 C 语言进行对比：
● C语言程序代码-> gcc 或其他编译器-> 可执行文件，运行在 x86 CPU、ARM等目标上。
● P4语言代码-> P4 编译器-> 硬件或其他形式输出，运行在CPU、FPGA、ASIC 等目标上。
P4解决数据平面的可编程问题，OpenFlow是解决控制平面的可编程问题。它们的关系如图1-10所示。图1-10 OpenFlow与P4的关系
由于 P4的定位是高级编程语言，所以 P4可以定义任意自己想要的配置。它可以让设备与SDN控制器通过OpenFlow通信，也可以通过本地的交换机操作系统控制，一切皆由P4程序设计而定。在P4语言中，OpenFlow只是一个程序，两者可以协同工作，事实上也已经有了使用 P4语言编写的实现 OpenFlow 功能的程序openflow.p4。
如图1-11所示为P4的架构，P4语言具有下面三个特性：
● 协议无关性：网络设备不与任何特定的网络协议绑定，用户可以使用P4语言描述任何网络数据平面的协议和数据包处理行为。
● 目标无关性：用户不需要关心底层硬件的细节就可实现对数据包处理方式的编程描述。这一特性通过P4前后端编译器实现，前端编译器将P4高级语言程序转换成中间表示IR，后端编译器将IR编译成设备配置，自动配置目标设备。
● 可重构性：允许用户随时改变包解析和处理的程序，并在编译后配置交换机，真正实现现场可重配能力。
为了实现上述特性，P4语言的编译器采用了模块化的设计，各个模块之间的输入输出都采用标准格式的配置文件，如p4c-bm模块的输出可以作为载入到bmv2模块中的JSON格式配置文件。图1-11 P4的架构
P4编译器本质上是将在P4程序中表达的数据平面的逻辑翻译成一个在特定可编程数据包处理硬件上的具体物理配置。因此，编译器后端部分自然与其支持的硬件目标紧密结合，而其前端部分则可以在各个P4可编程目标之间通用。这就意味着一个P4程序的具体实现可根据被编译的目标而改变。
P4语言联盟是一个P4开源社区，由工业界和学术界成员组成。它有两个目标：定义P4语言的正式规范，维持开放源码的P4开发工具和P4的参考程序。
P4语言联盟发布了一个P4参考程序“switch.p4”，它能实现各种流行的标准数据平面协议和功能，包括L2和L3（IPv4和IPv6）转发、虚拟局域网（vLAN）、生成树协议（STP）、等价多路径、链路聚合、虚拟路由和转发（VRF）、IP组播、多协议标签交换、各类隧道协议（如虚拟可扩展局域网、通用路由封装、IP-in-IP和Q-in-Q）、数据包镜像、服务质量控制、访问控制、RPF验证、传输协议（TCP、UDP等）。1.2.4 ETSI的NFV参考架构
由于电信运营商网络包括大量的专有硬件设备，如果运营商想要推出一个新的网络服务，如负载均衡或防火墙，就往往需要购置各种新硬件，之后再为这些新硬件匹配合适的空间和电力。能否以软件的方式解决这些问题？NFV（网络功能虚拟化）应运而生。
NFV 由运营商联盟提出，为了加速部署新的网络服务，运营商倾向于放弃笨重且昂贵的专用网络设备，转而使用标准的IT虚拟化技术拆分网络功能模块，如DNS、NAT、Firewall等。通过将硬件与虚拟化技术结合，NFV可以实现所有的网络功能。
一些运营商在欧洲通信标准协会ETSI（European Telecommunications Standards Institute）成立了NFV工作组（ETSI ISG NFV），开展网络功能虚拟化研究、标准制定和产业推动工作，致力于将虚拟化技术应用于电信领域。
NFV 系统中软件、虚拟层和网络功能分层解耦，打破了电信行业原有的“黑盒化”封闭系统，降低了电信准入门槛，有利于打造更具活力的生态系统，从根本上改变了 CT 的发展生态。一方面，充分解耦后的碎片化网络对运营商的管理和运维带来了巨大的挑战，这需要依赖新型的管理系统；另一方面，NFV 给网络带来极大的灵活性和敏捷性，但这依赖于新的管理系统和自动化编排系统。
如图1-12所示为ETSI NFV标准框架。图1-12 ETSI NFV标准框架
其中，NFV infrastructure（NFVI）、MANO和VNF（Virtual Network Function）是顶层的概念实体。
NFVI包含了虚拟化层（Hypervisor或容器管理系统，如Docker）及物理资源，如交换机、存储设备等。NFVI可以跨越若干个物理位置进行部署，为这些物理站点提供数据连接的网络也成为NFVI的一部分。
VNF与NFV虽然是三个同样的字母调换了顺序，但含义截然不同。NFV是一种虚拟化技术或概念，解决了将网络功能部署在通用硬件上的问题；而VNF指的是具体的虚拟网络功能，提供某种网络服务，是一种软件，利用NFVI提供的基础设施部署在虚拟机、容器或物理机中。相对于VNF，传统的基于硬件的网元可以称为PNF。VNF和PNF能够单独或混合组网，形成Service Chain，提供特定场景下所需的E2E（End-to-End）网络服务。
MANO提供了NFV的整体管理和编排，向上接入OSS/BSS（运营支撑系统/业务支撑系统），由NFVO（NFV Orchestrator）、VNFM（VNF Manager）及VIM（Virtualised Infrastructure Manager）虚拟化基础设施管理器三者共同组成。
编排（Orchestration）一词最早出现于艺术领域，指的是按照一定的目的对各种音乐、舞蹈元素进行排列，以期达到最好的效果。而引申到网络的范畴，编排则指以用户需求为目的，将各种网络服务单元进行有序的安排和组织，生成能够满足用户要求的服务。在NFV架构中，凡是带“O”的组件都有一定的编排作用，各个VNF、PNF 及其他各类资源只有在合理编排下，在正确的时间做正确的事情，整个系统才能发挥应有的作用。
VIM 主要负责基础设施层虚拟化资源和硬件资源的管理、监控和故障上报，并面向上层 VNFM 和 NFVO 提供虚拟化资源池，负责虚拟机和虚拟网络的创建和管理，OpenStack和VMware都可以作为VIM。VNFM负责 VNF 的生命周期管理，如上线、下线，状态监控。VNFM基于VNFD（VNF Descriptor，描述一个VNF模块部署与操作行为的配置模板）来管理VNF。NFVO负责NS（Network Service）生命周期的管理和全局资源调度。1.3 Linux开源网络生态
乱花渐欲迷人眼，Linux开源网络世界基本上可以用图1-13理个明白。
试读结束[说明：试读内容隐藏了图片]