本文介绍了 Software Define Network (SDN) 的理论和发展，考察了 SDN 落地的现状，提出了一些见解。

SDN：理论与发展

起源于斯坦福 Clean Slate 的 Software Define Network, SDN 旨在重塑互联网，于 2009 年 SIGCOMM 会议由 Nick McKeown 推出。最大的标准制定委员会是 Open Network Foundation，ONF。如下图所示，SDN 的核心思想就是从完整的控制平面和数据平面耦合的网络设备（交换机、路由器、防火墙等）的分布式网络中将控制平面和数据平面分离，通过开放南向接口（OpFlex、OpenFlow、NETCONF）为新的决策控制平面提供统一的网络抽象模型（事件级别而非配置级别），控制器通过适配各种南向接口，提供数据存储、事件监听和远程调用并将此模型暴露给北向接口（RPC、RESTCONF）以达到较高的可编程性，实现从传统的基于动态网络协议的转发（协议定义网络）到基于应用程序的网络转发（软件定义网络 SDN，或者程序定义网络 ADN）的转变，即 Configure flows(but not configuration) from global view。

[理想的 SDN] 那么所谓软件定义网络的软件提供了什么呢？首先它干掉了网络的面向协议性：再也没有 ARP、ICMP、DHCP、RIP、OSPF、EIGRP 了，现在统一基于流进行应用处理，其次增强了新功能：基于北向接口提供的网络抽象可提供像无线、负载均衡、安全（集中式控制系统能做到非常精细的安全控制，也是 SDN 最早诞生的诱因之一）、网路监控、阻塞延迟测量和管理、LLDP 拓扑发现等基于应用的服务，这些服务可作为控制器的 Application 集中运行，也可以通过 RPC 或 RestFul 接口远程调用，部署和扩展性非常灵活。除了传统网络业务，SDN 可以和企业业务更方便的集成，比如实现定制化的网络接入管理，基于复杂策略的网络连通等等。

Why SDN will Shape Networking？

SDN 可以类比为网络应用的 OS (NetworkOS)，对比从 IBM 大型机特定硬件、操作系统、软件的过去，以及操作系统对硬件的抽象、管理，以及基于 OS API 支持软件的小型机的现在，抽象总是封装了困难的、底层的逻辑，带来了高层的灵活性。对于网络而言，NetworkOS 封装的是像 OSPF（RFC2328）和分布式系统这种复杂的，但是可以共用的组件，而留给高层的，则是简单的 Dijkstra’s Algorithm 算法。

从概念上来看，SDN 物理的和虚拟的交换机通过南向协议和控制器通信以查询和更新转发表，控制器通过北向协议通过监听、事件回调等实现网络抽象的管理和维护，可以看到，这里的控制器扮演了新的集中式的控制平面的角色，相比较旧的通过协议交互的分布式控制平面，新集中式控制平面摒弃了大部分网络协议，而是基于应用程序实现转发行为，以提供对于网络更加灵活的控制。

但是在实际实践中，交换机很难将旧有基于协议的控制和转发数据平面完全分离，一部分是因为厂商利益的原因不愿意解绑，且仅在高端设备提供 SDN 能力，另一部分是因为实现一个新的高可用的转发控制系统较为复杂，SDN 从业者更希望混用原来网络设备以及复用设备控制层能力（比如 Learning、STP、EtherChannel、DHCP、BGP 等），所以妥协的一种方案是网络设备做薄控制层，而控制器提供厚控制层，两者通过 SSH 和 SNMP 等协议通信，互相配合实现 SDN 提供可编程能力 —— 这种妥协能保证传统网络设备功能可靠工作，比如根据 OpenStack 等 SDN 应用动态部署网络，但因为还是基于网络协议分布式通信，因此网络抽象性较差，且网络协议提供的事件有限，所以和新控制平面交互性欠缺，这直接导致了网络可编程性不足。

我把这种模式称之为 APDN - Application & Protocol Define Network，和 SDN 不同，但和传统网络模型类似，对网络的抽象仅暴露在配置而非事件级别，上层数据流仅仅是单向从北到南的：仅仅有配置完命令后可供查询的状态信息，而没有类似 debug 模式丰富的网络事件（路由匹配、阻断、过滤、网络协议交互）通知（理论上 SDN 数据平面找不到匹配可通知控制器，而这种实际的不彻底的控制平面分离导致数据转发行为是分层控制的，就像双重领导，控制器大领导 Application 只负责下发宏观决策，设备控制平面小领导 Protocol 负责执行决策和具体转发行为，只有网络阻塞、中断等大事才上报 Application，导致上层控制能力较差 —— 不是说控制能力差，而是说缺乏交互性，这种做法就好像为每个独立的设备按照业务配置了一个 CCIE 管理整个网络，CCIE 配置好设备后，设备独立转发，CCIE 需要不断的主动查询设备（或通过鸡肋的 SNMP trap）才能知道当前网络状态，即配置大部分还是一次性的、静态的，仅根据业务需求扩展，传统的网络模型没有改变），尚称不上变革。

这种方式类似于 IETF 提出的 Interface to Routing System - I2RS，将路由协议和策略配置相关的放在集中式 Controller 中，Controller 通过设备反馈的事件、拓扑变化、流量统计来动态下发路由状态、策略到各个设备，而路由计算等仍在设备上，考虑到 OpenFlow 仅仅在现在网络中扮演者部分角色，且最成功的 Google B4 案例业务并不复杂，所以 I2RS 的做法是否恰当仍有讨论的空间。

简而言之，SDN 提供了一种合适程度的对于网络的抽象（网络事件层），以提供了更高的可编程性。因为应用程序暴露到了 L3 层次（IP 地址和端口号），因此在现在互联网架构下，我们仅能在 L2- L3 层改进现有网络。因为这种更频繁的网络事件通告和更深的转发控制能力，我们通过减少而非像 L2 in L3 之类的隧道方案去隐藏复杂性，可以有效的基于 SDN 控制器的抽象模型，在北向 API 中使用简单的代码实现丰富的网络应用功能。

Software-Defined Networking：A Comprehensive Survey by Diego Kreutz，Fernando etc. 是 SDN 领域的一篇很重要的综述文献。

现实的 SDN 生态

在这么多年的发展中，因为各方利益交错，网络产业并没有形成类似于计算的 wintel 联盟。SDN 标志性的转发控制平面分离，以及基于此的开放、非面向协议、可编程性和集中控制，各种解决方案的实现不同。

从设备商和网工视角看，SDN 最大变革在于开放控制平面，损害了公司利益。

从开发者和用户角度看，SDN 需要更高可编程性，此外最好集中控制，但至于是否面向协议则存在摇摆，传统协议容易兼容，且受到检验，且可以复用。 [现实的 SDN] 从最保守的 CISCO ACI 拒绝转控分离，但提供了基于策略的更高可编程性以满足用户需求到最开放的 OpenFlow/OVS 分离、开放、非协议、集中控制到可编程性但 OF 芯片难做，功能实现受限，纯软件 OVS 性能差，每一种方案都不是银弹。在这两个极端中间，一些厂商虽然转控分离，但本质还是设备商，想要分 CISCO 一杯羹，做自己的传统网络栈的面向协议的控制平面配合白盒交换机出售。总之，在目前的网络设备格局下，SDN 成了一锅大杂烩，比较实际的方案是基于 ODL 这种集成了各种南向和北向协议的控制器通过各种南向协议：CLI、NETCONF、SNMP、OVSDB 等来操纵传统不分离平面交换机和白牌交换机或者软件交换机以暴露北向接口实现统一接口下的网络应用开发。

现有 SDN 要么应用于新建网络，要么就是旧有面向协议的网络复杂到一定地步，不得不引入 SDN 加以改造。总的来说，从管理员手工配置到基于协议自动配置，在上一个十年网络已经变得非常自动化，CCNP、CCIE 等管理手动和自动网络设备技能的证书备受热捧，而逐步的，像 CISCO 这样的公司开始垄断、阻碍网络创新和发展，在这个十年，从协议自动配置到应用程序“手工”配置，SDN 将会让网络更加智能，和业务联系更加紧密，会更加促进网络软件发展和创新。

SDN 的主要落地和实现

SDN 的主要落地实现一般在数据中心，又称之为 Software-Defined DataCenter，SDN-DCN，比如 Cisco 的 Application Centric Infrastructure, ACI SDN 解决方案：Application Policy Infrastructure Controller，APIC 应用策略和基础设施控制器（控制平面）通过控制 ACI Fabric ACI 构造完成 SDN 架构。ACI Fabric 由一颗倒着的树组成，其中包含 Spine Node 和 Leaf Node，这些 Node 可以是物理的或者虚拟的（OVS，Vmware VDS，Cisco AVS 等），APIC 通过 GUI/CLI/REST API/Python Scripts 配置、管理策略下发接口，通过 OpFlex 将策略推送给 ACL Leaf/vLeaf（不包括 ACI Spine） 的 Policy Element PE 模块，后者将策略转换为其能够理解的配置并部署在设备中。ACI Spine、Leaf、vLeaf 的转发不受 APIC 控制。在 ACI Fabric 内部，其通过 VXLAN Overlay 转发实现 L3 互联，在 Spine 和 leaf 之间一般是物理全互联。注意，ACI 并不是一个停留在配置层的低网络抽象，但也没有到达网络事件抽象层，ACI 在硬件中集成了策略驱动：南向接口 OpFlex，北向接口提供的是 Python + RESTful 实现 SDN，虽然可编程性不足，且私有软件协议和接口很难成为主流，但胜在独立的 NXOS 以及基于 NXOS 的 APIC 软件稳定，且硬件性能和可靠性好。

Vmware 的解决方案主要偏向软件层，NSX 包含数据平面 —— vSphere 中的 VDS 虚拟分布式交换机中部署，在已有物理架构上建立 L2 overlay；控制平面 —— 控制器部署在奇数实例集群中，包括控制 VM，提供路由控制平台允许 ESXi 本地转发，动态路由，为 Edge VM 提供南北向路由等；管理平台 —— 支持交换机、路由、Edge 服务、安全服务、分布式防火墙配置和编排，支持扩展第三方组件。VMWare 的方式更像是思科的极端，除去 NSX Manager 这个 Controller，网络设备都是软件实现（OpenVSwitch 交换机等）的，性能稍差但是可扩展性以及性价比都很高 —— 类似于 OpenStack 自己的 Neutron 网络实现。

除了数据中心以外，SDN-WAN 广域网的 Google B4 项目 数据中心广域网互联，也是 SDN 落地的另外一种实现。B4 通过 OpenFlow 协议在广域网中通过 SDN 技术操作自研的转发设备 OS、控制器对流量转发，极大提升了带宽利用率。

SDWAN 的另一个非常大的市场就是企业 VPN 互联，基于 SDWAN 控制器可实现智能选路，节省专线成本，提升链接利用率和可靠性。

诺基亚爱立信的 Nuage Network 也是 SD-WAN（广义的）的一种解决方案，其强调基于 MPLS VPN 实现策略引擎的管控：Fw、Wifi、LB、QoS 等。

此外，SDN-LAN（管理和编排、WiFI、物联网）、云计算（OpenStack 云计算平台实现的是网络虚拟化，这和 SDN 没有直接关系 —— OpenStack 的路由是基于 Linux 的 Router 做的，防火墙则基于 iptables 做的，交换则是通过 Linux Bridge/OVS 的 Underlay + VxLAN/GRE 等 Overlay 实现的，如下图所示，虽然也有集中性的控制器，不过确实和 SDN 关系不大，交换机还是有自身控制平面负责独立转发，控制器仅仅用于调度和策略管理。不过虚拟化网络确实可以使用 SDN 架构来实现，不过不是必须）。

网络虚拟化可以是纯软件方案，比如 OpenStack 的 OVS 实现，用软网络管理软服务器，也可以是纯硬件实现的网络，也可以是折中的：在云平台配置虚拟机的时候，网络通过 Neutron API 调度 ODL 来配置硬件交换机，包括下发安全策略、QoS、接口等。这种做法体现了 SDN 的集中控制特性，不过却没有控制平面和管理平面的分离，更像是 I2RS，网络抽象能力不足，可编程性不足，不过胜在逻辑简单，能充分利用硬件性能和功能实现虚拟机所需的网络虚拟化，因此是一种较为不错的网络虚拟化落地方案（不是 SDN 方案）。

Ps. SDN 和云平台无关，云平台（OpenStack、Docker、K8S）让计算服务的创建、分配和调度更加便捷，扩容更加便利，云平台的网络系统是 SDN 的应用之一，而 SDN 的意义并不在让网络的创建和分配更加便捷，毕竟动态协议基本上两条命令敲完就行，比手动配置快多了，而在于从面向协议到面向软件：提供了新的、开放的网络抽象和模型，以促使网络调度和控制更贴近业务且智能（云平台提供了和物理机几乎一致的虚拟机，不过可以动态变更配置，跨地区组网，并没有提供新的计算抽象和模型）。

软件定义安全（如下图所示是一个基于 SDN 交换机的 DDoS 处理策略，RR 抽样检测到 DDoS 攻击后，通过 NETCONF 告知防火墙 RT11 和 21 改变 BGP 路由表，将到目的地址 IP 重定向到 OpenFlow 防火墙，后者将目的 IP 改写为特殊值，并对源目的进行过滤，将正常流量发送回边界路由器，在直连路由器上，对此特殊目的 IP 继续导向 OpenFlow 交换机以修改目的 IP 为正确 IP，这种方案避免了传统 DDoS 修改 BGP 路由导致的路由黑洞，也避免了手动 ACL 规则的繁琐和低效率）、NFV 配合使用，都是 SDN 潜在的应用场景。

如下是一个基本的 SDN 控制器的功能模块组成，包括南向 API（OpenFlow，OF-Config，BGP-LS，XMPP，PECE） 和北向 API 接口（Java RPC，REST/HTTP，RESTCONF，NETCONF，AMQP 等），Controller 层提供的基础服务：交换机管理（状态、配置），流表生成（根据流表内容生成流表项目），转发管理（流表发送到指定设备），网络拓扑管理（发现网络拓扑，获取主机信息等），路由发现服务（根据路由算法提供路由服务），数据包分析（分析传输到控制器的数据包信息）和统计管理（转发设备流表使用次数，数据包收发次数，流量大小等），以及更高级的防火墙（网络安全保证），流量管理（流量平衡），虚拟和租户网络，编排（SDN 主要功能，对全网统一编排）和可视化界面，测试等。对于这些服务，一般的 Controller 包含了权限验证，数据库、日志、存储、缓冲、线程和模块管理等模块，以及集群和高可用实现。