Openstack neutron：SDN现状

目录

- SDN现状

- （一）SDN现状

- SDN诞生的背景

- SDN的介绍

- （二）SDN领域的相关组织和发展现状

- 1、ONF

- 2、OpenDaylight

- 3、 IETF

- 4、ETSI

SDN现状

（一）SDN现状

SDN诞生的背景

SDN技术其实要从更往前一点的技术说起，也就是传统（现在主流）TCP/IP协议，得益于TCP/IP的巨大成功，出现 IP over Everything、Everything over IP，以至于大学时期计算机网络课程的内容的基本上就是围绕着TCP/IP协议在讲。直到SDN的出现。

那个时候讲网络的典型模型，总是会有一个这样的结构。

图 2

TCP/IP模型下的网络通信

基本上就是在讲应用的数据如何一层一层地封装、一层一层的解封装最后传到应用的手中。也都会举那个的著名的邮差的例子，协助理解在这样一个分层的架构中数据的处理过程。在这个过程中，每一层都有每一层的处理机制。三层设备代表着路由器、二层设备代表为交换机。路由的重点在如何选路、如何转发，并就以此展开，各种路由协议之间差异。交换的重点在数据帧的转发、组播、广播、接入的安全。每一层都有每一层任务，每一层都有不同处理规则。而所有不同厂家、不同类型的设备之间都通过标准的协议进行交互。

而在这种背景下，网络的设计方案也按照设备功能的不同划分出不同的层级。每个层级都由大量专门的硬件设备实现特定的转发任务。交换机负责二层的转发，端口的连接、准入、二层广播。路由器负责与其他网络的连接、选路、NAT等操作。除此之外网络中还存在着大量FW、IPS、IDS等专用硬件设备，执行某一类特定的任务。

如果有新业务需求需要增加新的流量类型、或者要修改协议的解析方式、则要么更换设备、要么添加新的设备。所以网络功能升级往往都是以年为单位，层级化组网、扁平化组网、新增二层特性等等。设备厂家通过在网络中加入新的设备来推动用户网络的更新换代。

图 3

08年某网络厂家的数据中心外联区网络设计方案

这种情况带来的是像思科这样的厂家在一波IT发展的浪潮中迅速崛起。各个厂家争相在自己的设备中加入各种独有的特性，响应使用的需求，同时屏蔽其他的竞争对手。也让思科这样的厂家一时分光无限，赚取巨额的利润。

但是这样的架构带来的问题也非常突出。

1.传统的网络中同一层面上所有的节点都是平等，需要建立特定（二层、三层）的邻居关系之后在设备之间以广播或者组播的方式传递设备内部的转发表，才能实现基础的互联互通。

图 4

这种去中心化的结构中每一台设备都是智能的，保证了网络不会因为单个设备的实效而网络整体失效。但是带来的问题也非常显著。所有交换机和路由器都需要管理和单独配置，大量复杂和重复的工作。这种方式当网络规模小时还能勉强接受，而一旦中型网络中有上百台设备需要配置，而大型网络中有上万台设备需要配置时，维护工作就变得不可接受了。而每当网络中路由信息发生变更的时候，则要迎来整网的收敛，更新的信息要以广播或者组播的方式洪泛全网。当然，通过良好的规划，能够将这一范围控制在尽量小的范围内。但是协议交互带来的效率低下的问题无法解决，想要灵活地实现网络的调整，几乎完全不现实。

有一些网络管理软件的厂家也宣称能够极大地简化这一工作量，一定程度上实现设备的自动发现、配置批量下发。此类软件往往通过标准的snmp、或者是telnet、ssh，通过模块化的配置管理命令和文件实现管理功能。在面临多个厂家、多个种类型的设备混合组网的情况下，效果往往要打折扣，因为硬件厂家的相对封闭，基本很难完全获取所有设备的配置和状态信息。更别提自动实现流量选路优化、路由变更、地址池增删等自动化的管理功能。

图 5

某网管软件的网络设备管理功能

不同厂家的之间CLI配置命令不同，甚至同一厂家，不同软件版本之间的配置都有差异。网管提供的信息也不同。想弥补这之间的差异，要靠大量的人力和经验。

除此之外，还有一个非常突出的问题是，在一个大型的网路中，用户很难对网络中流量的走向、流量的类型有一个直观的认知。网管人员很难知道其关心的数据究竟是怎么在网络中穿梭的，只能靠假设和尽量减少路由的复杂程度，对路由信息进行削减。这直接导致网络故障难以定位，逐步排查问题非常困难，费时费力。

2.传统设备为了满足转发性能的需求，大量的功能（例如二层、三层数据包的处理、加密解密等）都是直接通过硬件芯片来完成。这样能设计出转发性能非常强劲，而且延迟非常低的网络设备。但是ASIC芯片的功能出厂之后就已经被固定了。想要加入新的功能、新的业务只能重新设计芯片，一般ASIC从设计、定型整个生命周期为5-10年，想设计一块新的ASIC芯片快一点也至少需要2年。这中间新的业务需求都只能憋着。

图 6

理解CPU与ASIC的关系，对理解交换机的控制和数据层面非常有帮助，国外有一篇博客写得很通俗易懂。提炼出来就是：

图 7

• ASIC芯片收到包之后，会先读取二层帧中的以太网类型字段，从而得出包的类型，不同类型的包通过不同的协议进行解析。如：arp、IPv4、IPv6、IPX等。
• 如果遇到诸如以太网类型为0x0800（IPv4数据包）、目的地址为路由器的地址或者组播地址（如：224.0.0.5）的数据包时，ASIC芯片会将数据包通过内部的PCIe总线转发给CPU，CPU再对数据包进行处理。
• 这个时候CPU会根据包中的信息进行相应的操作，如：更新路由表、ARP表、回应报文等。回应的报文也同样再通过ASIC芯片转发出去。
• 如果是一般的数据包，需要通过三层或者二层转发去目的地时，则ASIC芯片会直接通过查询路由表、MAC地址表然后从交换机上相应的端口转发出去。
• 整个过程中CPU充当交换机的大脑，也就是传统交换机的控制层面，用来运行内置的各种复杂的协议和功能。而ASIC则是根据已知的规则执行转发操作，充当的是交换机内部的数据层面。

当然，详细展开的话的，其实还有很多内容，包括用来各种表所用的内存的类型、协议的识别等。但其实理解了这个之后，对了解SDN控制和数据层面的分离就很容易了。

博客原文地址如下，有兴趣的可以去看看 ：

http://thenetworksherpa.com/data-control-plane-separation-sortof/

3.厂家对用户的锁定

虽然标准的TCP/IP、OSPF、spanning-tree 等能够满足一般网络最基本的通讯需求，实现各个厂家的设备互联互通。看似一片和谐、非常开放。但额外的功能的都是要付钱的而且很容易被厂家绑定。比如：思科将交换机和路由器内部软件的版本分为lan base、ip base、ip service、Advance IP service等，不同的版本支持的功能特性又不同，如lan base仅支持基本的二层转发的功能，连静态路由都不支持，而ip base版本支持一些基本常用的路由协议如rip,igrp等，而ip service版本则支持cisco拥有的全部路由协议如ospf,eigrp,IS-IS等。

图 8

这一块隐性的开销容易被忽视

除此之外，还有支持语音的IP voice、支持安全特性的security等等版本的软件。如果一个企业几个分支之间需要通过隧道互联，而且企业内部有一些话机需要路由器作为小型的语音的网关的话，则需要付出昂贵的license费用，并且各个分支都必须要用到同一厂家的设备。特别是有一个细节是，在相当长的一段时间内，使用思科路由器的VPN一类安全加密功能时，不能选使用诸如：AES128、AES256之类的加密算法，只能使用加密性较差的DES。当时我还一度以为是配置错误，后来才了解到是因为美国对中国的出口技术限制，导致在中国公开销售的ios内将这一部分的功能屏蔽，即使有钱也无法使用。这还是只是整个IT行业的冰山一角，由此可以知道，传统的网络厂家，在保证技术优势的情况下，给终端用户带来的极大的不便和高昂的成本。

这种为新功能、兼容性买单的现象对于有及大量设备采购需求的运营商来说尤为突出。

SDN的介绍

所以当最开始openflow协议想要建立一种标准的设备的控制协议时，立即获得大家的亲睐，特别是深受其苦的运营商。

SDN的理念很简单，核心是：1、控制层面和数据层面的分离，实现集中化的控制；2、开放的可编程接口，以灵活实现业务需求；3、实现网络配置和管理的自动化。

在一个典型的SDN架构中，通常包含以下角色：

图 9

网络设备：既包括了传统网络厂家的交换机、路由器（如：cisco、huawei、juniper等），也包括了各种软件的插件（如：linux bridge、ovs、dvr等），这些设备依旧承担流量的转发工作。

控制器：这是SDN的精髓了，传统设备的控制层面的功能全部被集中到了控制器，每一个网络设备不再单独运行各种协议、计算路径等，只需要接收控制器下发转表和配置。控制器用来与网络设备通信的协议，则被称为南向协议，包括：openflow、OF-CONFIG、POF、OVS DB、snmp等，主要用于将网络设备运行所需要的各种配置下发给网络设备。基于控制器的功能开发的各种上层应用，则是通过北向接口与控制器进行通信。

应用：可以是网络管理软件、也可以说各种业务系统、编排等。

这很好的解决了上面的问题：

1、所有的设备可以通过南向协议进行统一配置，底层的差异被抹去。

2、新的业务需要新的协议或者处理方式，可通过开放的编程接口灵活实现

3、底层的差异被抹掉后，厂家无法再控制用户，用户咸鱼翻身。

由此可以看出,SDN并不是说的不要物理设备了,也不是一单纯的部署一个neutron或者ODL控制器.其核心的理念是：业务通过网络开放的接口来实现全网的统一控制，最终实现网络配合业务的敏捷和高自动化。其上面的业务可以有很多种，可以是网络直播、可以是自动选路、也可以是双十一开始前的自动巡检。其下的设备也可以包括传统的路由器、Openflow交换机、OpenvSwitch等。而很多SDN的厂家都在中间搞事情。

（二）SDN领域的相关组织和发展现状

1、ONF

开放网络基金会(Open Networking Foundation)2011年由 德国电信, Facebook, Google, Microsoft, Verizon, 和 Yahoo!创立，这其中绝大多数的成员都是用户单位。ONF主要工作就是制定了openflow、OF-Config这两个的用于SDN控制器和网络设备之间通信的标准协议。SDN控制器使用openflow协议可以直接向转发设备推送转发规则，使得全网的设备都能具备可编程性以能够及时响应业务的需求。由此也可以看出ONF组织把重点放在了控制平面与数据平面之间的交互上。除此之外，ONF组织还通过技术顾问组和芯片厂商顾问委员会来推动SDN相关的标准交换机和芯片的发展。

这些都与ONF的目标息息相关，该组织的核心诉求可以用一句话来概括：通过推动SDN标准的落地，来实现使用“标准”的协议在“标准”的硬件上，通过编程接口实现各种网络的功能，最终摆脱硬件厂家的束缚（重点）。这里面标准的协议就是openflow，标准交换机即良好支持sdn的白牌交换机。其中白牌交换机的核心即使其中的SDN芯片，其要求具备超高的转发性能，同时可编程，这是传统的ASIC芯片和np芯片都无法同时满足的要求。

如果这一目标最终成真，将彻底地改变计算机网络这一行业。那么任意厂家生产的白牌交换机都将能完全满足这些大型用户的使用需求，传统网络厂家这么多年建立起来竞争壁垒将不复存在，这也是这些企业大力推进SDN标准化的原因之一。当然这也绝对是传统的网络设备厂家（如，思科、juniper等）愿意见到的，并直接导致了ODL这一组织的崛起。

图 11

ONF组织主要支持的ONOS是一个开源的SDN控制器平台，

“而获得ONF支持的ONOS（开放网络操作系统）则被运营商们寄予众望。ONOS，是由最早创造发明SDN技术的斯坦福、伯克利等知名大学联合运营商、设备制造商发起的非营利性开源社区组织，其目标是创建一个运营商级的开源SDN网络操作系统，满足运营商网络迁移到SDN的需求。有分析师指出，很多运营商愿意接受ONOS，因为它可以为运营商提供敏捷和灵活性，并且有可能使其摆脱设备供应商的束缚。”

2、OpenDaylight

网络行业的巨头们自然不会愿意看到ONF在SDN领域一统江湖，那他们将在行业内变得毫无话语权，最终沦为低附加值的代工工厂，但是又无法逆SDN的潮流而行。因此另起炉灶建立了另一个开源的SDN项目:ODL（Open Daylight）。与ONF不同，OpenDaylight是由思科和IBM 联合其合作伙伴建立。其初创成员包括：微软、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商。这其中一个重要角色就是思科，思科不仅占据着组织重要的话语权，并且因为在控制器中强行加入思科自己控制器的代码而与Big switch产生分歧，最终直接导致Big switch这一曾经ODL组织的铂金会员的退出。

ODL的诉求是尽量在现有交换机设备的基础上，实现网络控制和转发层面的分离，以及网络功能的接口化和可编程化。所以在ODL的架构中，SDN控制器的南向协议不仅支持了标准的openflow协议，还包括其他协议以及部分厂家的专用接口等。各个厂家也都在自己的交换机中加入有自己特色的东西，而非纯的openflow实现。

因此ODL架构在保留底层硬件设备复杂性的同时，尽可能地将网络功能抽象成网络应用的接口，供用户使用，而不需用户去关心底层复杂的配置。

ODL组织也在积极推动着SDN技术的快速发展，其因为有各大厂家的强力加持，发展速度非常的快，几乎3个月就能推出一个新的版本。

图 12

ODL拥有一套模块化、可插拔灵活地控制平台作为核心，这个控制平台基于Java开发，理论上可以运行在任何支持Java的平台上，其官方文档推荐的最佳运行环境是最新的Linux（Ubuntu 12.04+）及JVM1.7+。

ODL控制平台引入了SAL，SAL北向连接功能模块，以插件的形式为之提供底层设备服务，南向连接多种协议，屏蔽不同协议的差异性，为上层功能模块提供一致性服务，使得上层模块与下层模块之间的调用相互隔离。SAL可自动适配底层不同设备，使开发者专注于业务应用的开发。

类似淘宝这样地超大型网络，也花费了大量的精力在底层设备的适配上。不同厂家、不同设备、甚至不同软件版本都有着配置的差异。这其中涉及到ovsdb、openflow、OF-Config、snmp、SSH、CLI等等。只有花费大量的经历完成底层操作可行后，才能实现底层设备的抽象化。业务的调整、上线不需要关心底层的差异。并最终实现网络的自动化运维、管理。

这些工作对于一般小的企业来说基本等于不可能，甚至对于一些运营商来说都难以实现。这也是为什么当前ODL稳定性差，BUG较多的原因之一。如今各个核心的网络厂家都参与进来之后，从源头开始解决这一问题后，情况也许能够有改观，但是这里面的坑不是一时半会能够填完的。

图 13

ONF和ODL之间的争锋，其实代表了两种SDN思路之间的对抗，究竟会谁胜谁败现在还很难说。ONF强调统一的协议和统一的硬件，消除专用的系统和设备，开放网络能力平台，是理想情况下SDN该有的形态。而现实是各个网络厂家们明显会押注在ODL上，缺少传统硬件厂家的支持，ONF能够发展到什么地步还不清楚。从架构上来说，一旦openflow从标准到技术到设备完全普及之后，显然ONF的架构将比ODL这种解决方案的架构更加优秀。但是目前看来未来一段时间内主流的解决方案将是ODL。

3、 IETF

IETF是互联网工程任务组（Internet Engineering Task Force）的简写。IETF成立于1985年年底，是全球互联网最具权威的技术标准化组织，主要任务是负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。

早在SDN提出之前，IETF就对很多类似SDN的方法和技术进行了探索研究，与ONF相比较，IETF的相关工作更多的是由网络设备厂商主导，聚焦于SDN相关功能和技术如何在网络中实现的细节上。

在IETF第85次会议上召开了IRS BoF会议，关于IRS问题的描述、需求、应用场景和架构模型等方向的草案文稿已超过10篇，会议讨论同意成立IRS WG，并将研究组命名为I2RS（Interface to the Routing System）。I2RS的研究草案提出的支持的SDN体系架构如图7-3所示。

I2RS主张在现有的网络层协议基础上，增加插件（plug-in），并在网络与应用层之间增加SDN Orchestrator进行能力开放的封装，而不是直接采用OpenFlow进行能力开放，目的是尽量保留和重用现有的各种路由协议和IP网络技术。I2RS的路由系统需要发布网络拓扑和状态，通过网络元数据进行计算选路，并将相关结果传递给各设备的控制平面。I2RS接口的使用者可能是管理应用、网络控制器或者对网络定制的用户应用，目前I2RS工作组还没有形成RFC和工作组文稿。

4、ETSI

2012年10月，AT&T、英国电信BT、德国电信、Orange等7家运营商在欧洲电信标准协会（ETSI）发起成立了一个新的网络功能虚拟化标准工作组NFV ISG（Network Functions Virtualisation Industry Specification Group），目前已有52家网络运营商、电信设备供应商、IT设备供应商，以及技术供应商参加。

NFV的研究和标准化进度分两个阶段，2013年为第一阶段，主要是定义针对部分网络的功能虚拟化标准，如IMS和EPC核心网络，并从基本网络功能、网络设备的虚拟化开始着手。NFV的第一次会议于2013年1月15日至17日召开，这次会议明确了NFV的工作目标是制定支持虚拟功能硬件和软件基础设施的要求和架构规范，以及发展网络功能的指南，第一批规范将于2013年年底前完成。第二个阶段到2014年年底结束，将涵盖所有的核心网和接入网络中网元的功能虚拟化标准。

ETSI NFV的重点是网络功能的虚拟化，并且在架构中体现了更多的运营商的思路，包括在南向协议中加入了ForCES、PCE-P等协议。

http://www.c-fol.net/news/content/31/201604/20160428083652.html

http://www.sdnlab.com/3991.html

中国电信CTNet-2025网络架构白皮书