作者简介：程国振 职位：助理研究员 单位：国家数字交换系统工程技术研究中心(NDSC) 研究方向：软件定义网络、网络功能虚拟化、网络先进防御，创新型网络体系

摘要
软件定义网络因其控制平面与转发平面分离的体系使得网络具备快速创新、敏捷编程以及易于管理等特性而备受关注。控制平面被转移到单独的主机或服务器上形成控制器。软件定义网络的核心，控制器因支撑着大量网络应用的运行以及控制着网络的行为而成为学术界和工业界的研究热点。本文从控制器框架、可编程性、控制模块的管理和编排、控制器的分布式部署等方面进行综述，希望为SDN研究入门人员提供参考，也希望通过写一些技术文章，结识一些志同道合的童鞋。

一、引言

近年来，软件定义网络(Software-Defined Networking (SDN))因其对互联网的快速创新能力、敏捷可编程特性以及天然的可管理性等优点而备受瞩目。SDN思想是将完成决策功能的控制平面从网络设备中迁移到独立的主机或商业服务器中形成控制器，而网络设备仅完成简单的分组转发的数据平面。SDN避免了网络设备的复杂性，开放了网络控制逻辑，使得网络变得更具扩展和演进特性。因此，学术界和工业界都对SDN解决当前互联网面临的诸多问题寄予厚望。

SDN一词首先被提出是2009年在麻省理工学院的一篇科技评论中[1]。但在此之前SDN的思想已经被研究和验证。A. Greenberg等[2]对网络功能重新抽象，提出一种4D网络体系，旨在分离网络设备中的决策逻辑和转发逻辑，使得路由和交换设备仅完成转发功能。Tesseract[3]是4D网络体系的控制平面的实现与验证。M. Caesar [4]等设计并实现了一种路由控制器平台(Routing Control Platform, RCP)。RCP是逻辑上的集中式设备，将路由控制与IP转发分离，以实现路由扩展性。Ethane[5]将控制与转发分离的思想应用于企业网中以解决日益繁杂的企业网管理问题。而OpenFlow[6]则使得控制器南向接口更具规范化，即控制器模块生成的流表项通过OpenFlow协议下发到OpenFlow交换机中，而交换机状态数据也通过OpenFlow协议上报到控制器。然而，与此相反，控制器北向接口由于缺乏统一的标准约束，而呈现出多样化发展趋势。

如图 1所示，控制器作为SDN的核心组成，负责在网络设备与控制模块之间提供桥梁作用。它向上提供编程接口使得网络控制模块能够操作底层网络设备；向下则与网络设备交互，掌握全局网络视图。同时屏蔽底层网络设备，网络状态等维护任务，因此，控制器又被称为网络操作系统(Network Operate System, NOS)。

图 1 软件定义网络架构

研究人员已经对控制器进行了大量研究和设计，以使其更具可扩展性，更可靠以及更高效。目前，根据当前研究现状，控制器研究主要从以下方面进行。

• 控制平面可扩展架构。集中式控制器可以应对小型网络，但随着SDN网络发展，SDN网络被赋予更多的期望，逐渐扩展到更大规模的网络中，例如WAN[7][8]，控制器也逐渐采用分布式结构。
• 控制平面编程接口。编程接口是控制器对底层物理网络的高层抽象的体现。友好的编程接口不仅有益于激发程序员参与到控制器应用程序的开发中，而且可降低管理员配置网络策略的难度，避免管理员直接操作底层网络管理规则。
• 控制平面开放模式。虽然SDN将控制逻辑开放，但是怎么设计开放模式能够激励第三方参与控制模块的开发，并加快实现网络创新，是SDN需要解决的另一问题。控制器应用开放模式只有既能使参与者获得利益，又能体现参与者之间的公平竞争，才能实现网络核心功能的快速创新。
• 功能组合问题。控制逻辑开放后，控制器将承载大量控制模块实例，这些模块可能由不同组织开发，但功能可能相似或重叠。现实中，复杂而完整的网络处理流程需要简单而细粒度的控制模块组合而成，如何组合不同的控制模块，使得网络处理流程更优，也是控制器设计面临的严峻问题。
• 网络更新一致性。随着控制器逐渐演变为分布式控制架构，控制器需要全局网络视图，当底层网络拓扑等网络状态变化时，如链路故障，如何调整网络设备和新旧策略，保证网络更新的全局一致性，是控制器需要解决的问题之一。
• 控制平面的全网布局。该问题主要解决控制器实例如何在全网范围内放置的问题，使得控制开销最小，且交换机-控制器延迟最低，实现全网范围内的最优控制。它可以看作控制平面可扩展性研究的分支。

首个控制器——NOX[9]实现以来，关于控制器的研究和开发已经积累了大量成果。从单线程到利用高性能多核平台的多线程实现，从集中式到分布式，从静态分布式到动态分布式控制器，控制器一直是SDN领域的研究热点之一。虽然研究人员对SDN网络研究进展进行了大量概述，但还没有专门针对控制器的研究综述，本文对控制器当前研究现状、存在的问题、解决方案以及未来可能的研究方向等方面展开讨论。

本文结构如下：第2节从控制器架构的角度分析了其演变过程，以及现有控制器的特点。第3节综述了当前基于控制器的编程语言扩展研究。第4节论述了控制器接口开放模式，以及不同控制应用程序的编排组合问题。第5节讨论了控制器到交换机的映射的一致性问题。第6节讨论了控制平面在全网范围内的布局研究问题。第7节简介了SDN安全。

二、控制器架构

SDN诞生之初主要适用于小型网络中，例如，校园网和企业网等，因此，控制器被设计为集中式控制。但是随着SDN网络的发展，其被部署于更大型的网络，集中式控制器逐渐成为网络瓶颈，使得研究人员提出了分布式控制器。本节讨论控制器机构研究，主要包括控制器中存在的问题以及当前的解决方案。

2.1 集中式控制器

(一) 单线程

NOX[9]是首个实现的SDN控制器，NOX的思想来自于计算机结构。在计算机早期，编程通常是机器语言，没有对底层物理资源进行任何通用抽象，这使得编程很难编写、调试和跟踪定位。现代操作系统通过提供对简单资源抽象(内存、存储和通信)和信息(文件和目录)的控制访问使得编程更容易。这些抽象使得程序能够在兼容不同硬件资源，并以更安全、高效的执行不同任务。而目前的网络就像没有操作系统的计算机，采用依赖于网络的组件配置完成类似于传统机器语言编程的功能。因此，NOX通过抽象网络资源控制接口，设计网络操作系统，提供对整个网络的统一集中的编程接口。

网络操作系统并不直接控制网络，它仅提供对网络的编程接口，运行于其上的应用程序则直接观察控制网络。如图 2所示是文献[9]给出的基于NOX的部署结构。NOX运行于单独的PC服务器，其通过OpenFlow交换机接入OpenFlow使能的交换机网络。NOX收集整个网络的网络状态视图，并将其存储在网络视图数据库之中。NOX的网络视图包括交换机网络拓扑，用户、主机、中间件以及其他网络元素，提供的各种服务等。基于NOX接口实现的各种应用程序通过访问网络视图数据库，生成控制命令，并发送到相应OpenFlow交换机中。

图 2 基于NOX的网络部署

NOX对上层应用程序提供统一的基于事件的编程接口，将网络各种状态改变提供事件句柄(Event handler)，方便上层应用程序调用。一些事件可能直接生成OpenFlow消息，例如，交换机加入网络(Switch join)，交换机离开网络(Switch leave)，分组接收等。另一些事件则是由NOX应用程序在处理底层事件过程中产生的。另外，NOX提供一组基础应用收集整个网络的网络视图并保持网络命名空间。因为网络视图必须在所有NOX控制实例之间保持一致，因此，当探测到网络变化时，需要更新网络状态数据库。对于大量应用程序均可能需要的更基础的功能，NOX开发了系统库提供高效的共用功能，例如，快速报文分类，路由等。

然而，NOX作为最早的基于OpenFlow的SDN控制器实现，简化了企业网的管理，但是它是单线程设计，不能利用当前高性能的计算平台，例如，多核平台。因此，大量基于多线程的控制器被设计和开发，一部分是改进NOX，如POX[10]，NOX-MT[11]等，另一部分则从性能、扩展性等不同角度全新设计实现，如Masterto[12]，Beacon[13]。

(二) 多线程

(1) Maestro
在每条流的初始化阶段，SDN网络的控制器需要与其负责的所有相关交换机通信，因此，控制器易成为性能瓶颈。OpenFlow控制器NOX基于事件机制实现了控制功能开发的简化模型，但其是单线程的，未考虑并行特性。Maestro[12]从可扩展性的角度，在保证简单编程接口的同时，设计并开发了多线程控制器。

图 3 Maestro控制器结构

如图 3所示为Maestro的结构给出了三个执行流程。Maestro通过与每个交换机的TCP连接向交换机网络发送或从其接收OpenFlow消息。那么“Input Stage”和“Output Stage”分别处理底层套接字缓存的读取和写入，并将原始OpenFlow消息转化为高层次数据结构或相反的方向转换。这些底层功能随着OpenFlow协议标准更新。而上层功能则以应用程序的形式不断地更新和重新实现。编程人员可以灵活修改这些应用程序的行为，或添加新的应用程序。图 3中的应用程序包括“Discovery”，“IntradomainRouting”，“Authentication”和“RouteFlow”。

交换机加入网络中时会建立与Maestro的TCP连接，“Discovery”应用周期性地发送探测消息，并通过LLDP发现并识别交换机。“Discovery”通过接收来自交换机的对探测报文的回应发现整个网络的拓扑结构。而当拓扑改变时，“Discovery”会调用“IntradomainRouting”应用修改路由表信息。

当Maestro接收到一个流请求时，该请求消息首先通过认证是否违反安全策略。如果符合安全策略，“RouteFlow”应用将为其计算一条最短路径，生成配置输出到目的交换机中，请求报文发送回初始交换机中。

上述三个执行流程并行运行，为实现公共数据结构——路由表的一致性，路由表更新延迟提交。即，当“IntradomainRouting”路由表更新时，若“RouteFlow ”应用已经启动，则“RouteFlow ”仍然使用原来的路由表信息，而当“RouteFlow ”下次启动时访问更新后的路由表信息。

Maestro将应用程序编排为执行流程(execution path)，并使用有向无环图(Directed Acyclic Graph, DAG)抽象建模。DAG的节点标识应用程序，DAG的边标识数据流向。执行流程的添加通过配置一个DAG实例，并扩展一个新的线程运行DAG实例。

为了管理不同的任务，Maestro设计了任务管理器提供统一接口管理所有未决的计算。任何具有计算消耗的任务均实现为一个任务，并为每个任务分配一个线程。为了在多线程之间兼顾公平与效率，任务管理器采用“pull”的方式管理工作线程，即，IO缓存队列与线程分离形成缓存池和工作线程池，当某队列不空时，可以随机“pull”空闲线程或轻负载线程处理该队列中的消息。虽然该设计需要维护缓存池的多线程同步的额外开销，但是其实现了更加公平的线程调度和多线程的负载均衡，提高了工作效率。

(2) Beacon
与Maestro 类似，Beacon也是基于Java开发的开放源代码控制器。但是，与其主要用于研究和试验不同，Beacon更加注重生产环境的应用。因此，Beacon致力于提高应用程序的开发效率和处理性能。另外，由于Beacon基于OSGi开发，应用程序以“束”(bundle)的形式在系统运行时地被添加或停止。

首先，为了实现代码重用及提供更友好的编程接口，Beacon采用了控制反转容器(Inversion of Control, IoC)框架—Spring。开发过程中只需要创建对象的实例，并将一个对象作为另一对象的属性分配以实现彼此的关联。IoC框架允许开发人员采用XML配置文件或Java注解的方式创建对象和关联多个对象，降低了开发人员的开发时间。另外，Spring的Web框架在Web和REST请求之间映射，简化方法调用，执行请求和响应的数据类型与Java对象之间的自动转化。

Beacon提供基于事件的API接口，任何应用程序均可以注册监听器接收各种事件。应用程序可以调用IBeaconProvider实现与OpenFlow交换机之间交互。监听器可以注册当交换机添加或删除时被通告(IOFSwitchListener)，或执行交换机初始化(IOFInitializerListener)，以及接收特定OpenFlow消息类型(IOFMessageListener)。另外，Beacon还包括实现了OpenFlow 1.0标准协议的OpenFlowJ库，用于管理设备的设备管理接口(IDeviceManager)处理设备相关的事件，用户探测交换机网络的接口(ITopology)处理拓扑变化事件(例如，链路消失)，提供最短路服务的接口(IRoutingEngine)等。

其次，与现有控制器实现的另一不同点是Beacon可以在运行时启动新的应用程序，停止正在运行的应用程序。为了实现运行时启动或停止应用程序，Beacon采用OSGi规范实现框架—Equinox。OSGi定义了“束”，即JAR文件，标识了ID，与其它束之间的依赖关系以及规定向外部提供的可供外部使用的程序包。开发人员可以定制上述内容。

Beacon利用了OSGi规范中服务注册的组件实现服务提供者与服务消费者之间的联系。如图 4所示，服务提供者输出服务接口，服务消费者请求并接收满足服务需求的实例。任何服务实例均可随着其它服务的运行或停止而动态变化。

图 4 Beacon服务注册

最后，在性能方面，如图 5所示Beacon采用多线程机制，应用程序通过注册监听特定消息类型的OpenFlow消息，如PacketIn消息，对于监听相同消息类型的应用程序形成处理流水线(pipeline)。消息被解析后依次经过流水线上的应用程序处理。Beacon采用“Run-to-completion”模式读取消息，具体如图 5所示。Beacon可以配置线程池大小，对交换机的连接请求通过轮训的方式选择线程，每个交换机固定一个线程处理，因此该设计无需同步锁。Beacon采用批量模式读取消息，以减少用户态程序访问套接字的次数，提高性能。与其它开源集中式控制器相比，实验证明Beacon在吞吐量，处理延迟以及多线程扩展性方面最优。

图 5 Beacon 多线程示例

(3) 基于Beacon的扩展
Floodlight[14]是基于Beacon内核开发的另一款由开源社区维护的控制器。另外，Volkan Yazıcı等[15]将Beacon扩展为分布式控制器应用于组播网络中。FlowScale[16]则部分采用了Beacon模块。由于这些控制器都起源于Beacon，所以其实现细节不再综述。

另外，其它较著名的多线程控制器还有Ryu[17]，Trema[18]，Mul[19]，SNAC[20]，RouteFlow[21]等，这里不再一一描述它们的结构和功能。

2.2 分布式控制器

(一) 静态分布式控制

基于OpenFlow的SDN网络最初设计与实现为了简化而假设单个控制器。然而，随着部署OpenFlow的商业网络的规模和数量的增加，仅靠单个控制器对整个网络控制可能是不可行的。主要原因如下：首先，到达集中式控制器的控制流量的规模随着交换机数量增加；其次，如果网络半径过大，无论控制器被放置在哪里，总有一些交换机会遭受较长延迟；最后，由于系统受到控制器处理能力的限制，流设置时间会随着需求增长而明显增加。

(1) HyperFlow
A. Tootoonchian等[22]设计并实现了HyperFlow，一种基于事件的分布式OpenFlow控制器，允许网络提供商部署任意数量的控制器。HyperFlow既提供了可扩展性，也保持了网络控制逻辑上的中心化：所有的控制器共享一致的网络视图，响应本地服务请求，无需主动地与任何远程节点通信，因此最小化了流配置时间。另外，HyperFlow无须更改OpenFlow标准，并且只需要对当前控制应用程序做最小的修改。HyperFlow保证无环转发，并对网络分割以及组件失效具有弹性。而且，HyperFlow可以添加管理区以独立的管理OpenFlow网络。

HyperFlow是OpenFlow的第一个分布式控制平面。它实现为NOX[9]上的一个应用程序。如图 6所示为HyperFlow的总体框架。它作为应用程序运行于安装NOX的控制器之上，负责控制器网络状态视图的同步(通过传播本地产生的控制事件)，将到达其它控制器管理的交换机的OpeFlow命令重定向到目标控制器上，并重定向来自交换机的响应到发起请求的控制器。跨控制器的通信采用事件传播系统。所有控制器都维护一个全局一致的网络视图，并运行相同的应用程序。每个交换机连接到距离其最近的控制器上。若控制器失败，受影响的奇偶阿虎安吉必须重构到另一控制器上。每个控制器直接管理其控制域内的交换机，间接地查询不在其控制域中的交换机。

图 6 HyperFlow框架

为了获得网络状态视图的一致性，每个控制器中的HyperFlow控制应用实例有选择地发布事件，通过publish/subscribe系统改变系统状态。其它控制器重放所有发布的事件并重构网络状态。由于控制器中网络视图的任何改变均是由一个网络事件触发的，单个网络事件可能影响多个应用的状态，所以状态同步的控制流随着应用的增加而上升。但是，HyperFlow将限制事件的数量，因为仅有很少一部分网络事件会改变网络视图，例如packet_In事件。为了传播网络事件，HyperFlow基于WheelFS实现了分布式发布/订阅系统。每个运行HyperFlow程序的NOX控制器订阅控制通道、数据通道以及自身的发布/订阅系统。事件发布到数据通道，周期性地控制器通告发送到控制通道。

(2) FlowVisor
FlowVisor解决如何在商业计算机网络中进行新型业务实验的问题。FlowVisor通过切分网络资源并将每一个切片的控制部分转移到单个控制器中，使OpenFlow网络中可以部署多个控制器。FlowVisor通过将不同实验者的不同控制逻辑映射到不同的控制器中，使得实验者可以在孤立的切片上尝试自己的想法。这与现有实验床如VINI[23]和Emulab[24]等需要大量专业化的硬件或特殊的服务器不同，FlowVisor是在商业计算机网络中切分网络资源形成切片。

FlowVisor 在转发平面与控制平面之间引入了一个软件切片层(slicing layer)，并采用OpenFlow实现了该切片层，用以切分控制消息。FlowVisor与VLANs不同，VLANs仅能隔离不同类型的流量，而不能控制转发平面。FlowVisor设计了策略语言以映射流到切片，通过修改该映射，用户能够方便地尝试新的业务或服务，当控制消息穿越切片层时，Flowvisor阻塞并重写控制消息，一个切片的行为不会影响另一个切片，保证各实验安全并存与商业化网络中。如图 7所示，Doug代表用户，使用VoIP、HTTP和Game业务，Alice、Bob和Cathy分别是三个实验者，分别向管理员请求自己的实验拓扑、带宽和流空间(flowspace)。

图 7 FlowVisor 示意图

Flowvisor首次基于OpenFlow实现了用户可定义的控制逻辑，在商业网中支持业务实验，为实验提供了真实可靠的用户流量，但也不可避免地增加了网络设备的负担。Flowvisor的流空间划分不是真正意义上的虚拟化，ON.lab后来推出了OVX，解决了这一问题。

(3) Onix
如图 8所示，Onix则是Nicra公司开发的一种分布式控制器框架。开发人员可以基于Onix提供的API开发自己的控制器逻辑并部署在服务器集群中。Onix将SDN网络抽象为四种组件。首先是物理设备，即网络交换机或路由器，或者任何支持Onix接口的网络单元。通过这些接口，上层控制程序可读取网络单元的状态信息。

图 8 Onix 系统架构

其次是连接设备，即物理设备与Onix的通信的控制信道。这种控制信道可以是带内建立也可以是带外建立。连接设备必须支持双向通信，传统路由协议允许在连接设备之上。

再次是Onix，Onix是运行于物理服务器集群之上的分布式系统。每个服务器运行一个Onix实例。Onix负责向控制逻辑提供网络状态访问接口。为了扩展到更大规模的网络以及考虑生产部署过程中的弹性需求，一个Onix实例负责分发网络状态到集群中的其它Onix实例。

最后是控制逻辑，控制逻辑基于Onix API实现并运行于Onix之上，控制网络单元以期望的行为运行。

基于上述四个基本组件，Onix向控制逻辑定义了通用的API接口。该接口的核心是读写网络元素的状态信息，这些状态信息存储在特殊的数据结构模型中，Onix称为NIB (Network Information Base)，存储整个网络中所有网络元素的视图。

与其它分布式控制逻辑不同，Onix定义了良好的控制接口，且已被应用于生产环境中。Onix可以通过部署新的控制实例实现控制逻辑的扩展，但是控制实例与其交换节点的映射是静态的，当网络负载分布不均衡时，难以实现控制实例间的负载均衡，即不能灵活地从负载较重的控制实例向负载较轻的控制实例转移负载。

(4) Kandoo
OpenFlow网络仅对控制平面编程，而当前频繁而资源耗尽型的事件。例如，流到达(PacketIn)和全网统计收集事件，为控制平面带来了巨大的压力，限制了OpenFlow网络的可扩展性(scalability)[30]。尽管可以通过主动地推送网络状态而减少流到达事件，但该方法不适用于其它事件，如全网统计收集。当前方法要么认为是SDN网络的固有缺陷，要么试图修改交换机解决问题。相反，DIFANE[29]和DevoFlow[30]向交换机上引入了一种新的功能来降低频繁事件并降低控制平面上的负载。而修改了交换机，需要修改协议标准。
Kandoo则是在不修改交换机的前提下保持扩展性的框架。Kandoo有两层控制器，如图 9所示，其中底层是一组控制器，相互不连接，没有网络知识视图，顶层是一个逻辑上集中式的控制器，维护全局网络视图。所有底层控制器向上连接顶层控制器。底层控制器仅运行靠近数据平面的本地控制应用(也就是，能够利用单个交换机状态完成的功能)。这些控制器处理的大多数频繁事件，有效地向顶层屏蔽了大量本地消息，降低了顶层控制器的开销。

图 9 Kandoo两层控制器框架

Kandoo的设计可以使网络管理员根据需要复制本地控制器，并缓解上层控制器的负载。因为现实中，顶层控制器是实现扩展性的瓶颈。实际评估表明与常规OpenFlow网络相比较，一个由Kandoo控制的网络的控制信道消耗要低一个数量级。
Kandoo中根控制器通过一个简单的消息通道和过滤组件实现订阅本地控制器的特定事件。一旦该本地控制器接收到根控制器订阅的消息，它会将该消息转给根控制器进一步处理。因此，Kandoo将极大地限制了到达根控制器的消息。但是，Kandoo采用双层控制器架构会增加全局事件的处理延迟，因为这些事件会先经过本地控制器，然后再转到根控制器。
以上综述的分布式控制器分别从不同角度实现了控制器东西向接口的扩展，然而，上述设计方案的控制器与交换机之间的映射都是静态配置的，当网络负载分布发生变化时，例如，某一控制域的流量突然增大，导致该域控制器超载，需要网络管理员重新调整交换机的域归属。缺乏灵活性。因此，设计具有根据网络负载分布情况的自适应调整数据平面到控制平面的映射，有利于实现控制平面的负载均衡。

(二) 动态分布式控制

（1）ElastiCon
分布式控制用以解决软件定义网络中集中式控制器面临的扩展性和可靠性问题。然而，分布式控制器的一个关键缺陷是交换机和控制器的映射是静态配置 (statically configured)的，其结果是导致控制器之间的负载分布不均衡。Advait Dixit等[31]设计了ElastiCon，一种弹性分布式控制器体系(elastic distributed controller architecture)，在该体系中，控制器池中控制器的数量可以根据流量状态和负载动态地增加或减少。为了可以完成负载迁移，提出了一种新的交换迁移协议。

图 10给出了ElastiCon框架。它主要有三部分组成，负载测量模块、负载适应决策模块和行动集合。分布式控制器之间通过分布式数据仓库共享信息。首先，我们需要周期性地通过优化交换机到控制器的映射实现负载均衡。其次，如果负载超过现有控制器的最大能力，我们需要通过添加新的控制器以增加资源池，并触发交换迁移以应用新的控制器资源。相似地，当负载降低到一个特定的水平时，我们需要相应地缩小资源池。所有这些动作涉及到测量和监控控制器负载以及决定哪些交换机迁移的算法。

图 10 ElastiCon 架构

ElastiCon首次提出在分布式控制器与交换机之间采用动态映射以更大程度地增强网络的扩展性。然而，关于弹性分布式控制器研究还存在以下问题：
作为核心部件，负载适应决策模块采用基于窗口的双门限方法，即在决策窗口内，当负载超过上、下门限时，采取增加新控制器、删除已有控制器或迁移交换机的动作。虽然方法简单，但是该方法过于粗放，难以实现精细控制。另外，ElastiCon没有明确迁移交换机决策算法，仅指出可在相邻控制域之间迁移交换机。
（2）ONOS
ONOS是ON.Lab推出的开源网络操作系统，对彪ODL。ON.Lab是斯坦福大学和MIT联合创建的实验室，后来一批服务提供商、运营商以及设备商赞助。它们推出了几个产品，名气最大的还是ONOS。ONOS致力于构建可扩展、高可用、高性能的电信级网络操作系统。2014年的HotSDN大会上，ON.Lab发表了一篇介绍ONOS的文章[]。ONOS是一个多模块的项目，每个模块是一个OSGi bundles。其架构设计实现代码模块化，易于引入新的功能集合；可配置，可以在运行时加载或卸载不同的特性或功能；隔离原则，子系统之间具有清晰的边界；协议无关性，系统本身以及其上层应用不应该被绑定到特定的协议库或实现。

ONOS是由多个子项目组成的，其中每个子项目均有自己的代码树，且可以分别独立地构建。ONOS源码由Maven的层次POM文件来管理和构建(现在也支持Buck构建了)。每个子项目拥有自己的pom.xml，中间目录具有聚合的父pom.xml文件。后者包含了这些子项目的所有依赖和配置，可以构建相互独立的子项目。ONOS根目录包含最顶层的pom文件用于构建整个项目以及所有的模块。ONOS使用Apache Karaf 作为其OSGi框架。除了启动时的依赖解析和运行时的动态模块加载。

ONOS划分为如下几个部分：面向网络（ network-facing）的协议相关模块，用于网络交互；协议无关的系统内核（core），用于跟踪并维护网络状态的信息；应用程序（applications），接收内核提供的信息，并基于此，执行相应的动作。

在层次化的架构中，以上三部分构成不同层次(tier)，面向网络的模块通过南向(southbound)API与内核交互(也就是，面向网络的模块向内核提供（provider）网络状态信息)，而应用程序通过北向(northbound)API交互（也就是，应用程序接收内核维护的网络状态信息，是信息的消费者）。南向接口定义了协议中立(protocol-neutral)方法来传递网络状态信息到内核，而内核通过面向网络的模块与底层网络进行交互。北向接口向应用程序提供描述网络组件和属性的抽象，使得上层应用程序可以以上层策略(policy)的形式定义其期望的动作和行为。

如果ONOS需要支持一种新协议，只需在南向接口之上构建一个新的面向网络的模块，并作为插件加载到系统中即可。

正如前文所述，如图 11是ONOS按功能分层级的系统图。

图 11 ONOS层级架构

把ONOS归类为动态分布式平面是因为其可以动态启动、停止它的实例。它的分布式机制如图 12所示。

图 12 分布式机制

提到SDN控制器就不得不说OpenDaylight了，但是笔者确实没有专门研究过ODL，这里就不班门弄斧了(SDNLab上有一大波ODL的入门文章)。

三、编程语言

随着网络规模不断地变大，网络设备变得更加复杂，针对这些网络设备的配置管理需求往往需要管理员转化成底层语言或规范，导致配置网络设备复杂而易错，运营商难以灵活修改网络管理策略。基于流的管理语言(FML)[32]设计了一种高层协议语言。FML采用逻辑编程抽象表达策略。其规则类似于Datalog集合。

Andreas Voellmy 等[33]基于OpenFlow设备设计了一种高层编程语言系统——Nettle。Nettle采用函数式高级语言Haskell编写完成，高级语言使得编程模型更具表现性，基于此开发新网络应用更加容易。Nettle借鉴了函数反应式编程(functional reactive programming, FRP)。图 13给出了Nettle的软件架构。最底层是OF交换机，在其上层是Haskell系统，Haskell系统上面运行由Haskell语言编程实现的OpenFlow协议。该软件栈上层是FRP范例的实例化。FRP是一个语言族，向编程交互式系统提供具有表现力的以及理论化的方法。FRP已经成功应用于计算机动画，机器人以及控制系统等领域。

在FRP层上，Nettle实现了一种扩展性的领域规范语言(domain-specific language, DSL)。基于此可定义不同的网络抽象。正如Andreas Voellmy所述，Nettle可以采用DSL实现访问控制、流量工程以及域间协议等。这些上层应用将很大程度上降低网络设备管理和控制代价。

图 13 Nettle架构

集中式管理虽然简单，却以牺牲控制平面的扩展性为代价。针对Nettle的扩展性问题，McNettle[34]提供了一种运行于多核系统的编程框架。与当前的分布式控制器实现相比，McNettle不仅实现了高扩展能力，同时保持了集中控制的简单编程模型。
Maple[35]则是Andreas Voellmy为简化基于SDN的应用编程，封装底层细节而开发的编程模型。它允许程序员使用标准编程语言设计任意的集中式算法，称为算法策略，以控制整个网络的行为。Maple提供了程序员定义的集中式策略处理所有进入网络的报文，因此，避免了高层策略向分布式交换机流表或规则的转换。Maple的优点是提供了一种编程模式使得程序员可以利用高层算法应用定义网络范围的转发行为。为此，Maple引入两个组件使得该编程模式更具扩展性。首先，它引入了一种新颖的SDN优化器从普通控制程序中发现可重用转发决策。其次，优化器开发了跟踪树(trace tree)的数据结构记录针对特定报文并由程序员定义的函数调用，然后将结果和推广到其它报文，以减少OF交换机中的流表数。

Andrew D. Ferguson等[36]提出了一种控制SDN的API接口实现——PANE，实现用户参与和共享网络。PANE可以将读写操作权限授权给端用户或应用程序。PANE提供面向用户的API，通过权限委托将控制与网络视图分离，通过层次化的冲突拆解函数( HFT [37])实现了不同网络共享租户之间的策略冲突。

与Nettle语言系统类似，Frenetic[43]是普林斯顿大学针对目前网络应用开发靠近底层，难以实现模块化编程而设计的基于OF交换机网络的控制器语言系统。Frenetic提供高级语言开发分布式交换机控制程序，声明式查询语言实现分类和聚合网络流量，函数反应式组合库实现对高层分组转发策略的描述。这些组件使得Frenetic易于实现模块和代码重用。Frenetic主要围绕两级抽象展开。首先，Frenetic定义构建和操作网络流的源码级操作集；其次，Frenetic设计并实现了运行时系统处理所有关于安装或卸载底层交换机规则的细节。

上述系统规范了SDN控制器的北向接口，简化了网络控制程序的开发和维护，降低了网络管理的代价。然而，目前管理一个网络往往需要大量并行任务，从路由到流量监控，到访问控制，到服务器负载均衡，SDN控制器应用虽然可以实现这些不同的任务，并通过生成流表控制网络节点，但当前的SDN控制平台缺乏对这些应用模块的有效组织。Christopher Monsanto 等[44]基于Python语言实现了Pyretic语言系统简化控制器应用模块的协同和编排。Pyretic系统定义了模块间组合操作符，实现一系列策略的编排实现流量的转发和排队。组合操作符包括并行组合操作符和串行组合操作符，前者允许多个策略针对某一目标报文集合并行处理，后者则允许策略对某目标报文模式进行串行化的生效。另外，Pyretic定义了抽象拓扑的概念，以控制不同模块操作网络节点的权限，例如，可以隐藏某些节点。为了使得程序员能够扩展报文的虚拟匹配域，用以底层报文与高层原数据建立关联，Pyretic定义了抽象报文模型。

四、SDN功能组合

控制与数据平面的分离开放了控制逻辑，使得除设备制造商之外的第三方可以开发并部署各自的控制模块。与SDN控制器南向接口采用OpenFlow协议标准化不同，北向接口则没有统一的开放标准，所以如何开放控制逻辑成为研究热点问题之一。

目前对于在网络中的什么位置部署基本交换逻辑是清晰的，但是对于如何部署完成更多任务的“富”功能却是未知的。传统网络主要采取以下三种方法向网络中添加各种控制功能。首先是嵌入在端系统上，例如，加密、个人防火墙等，但该方法仅针对个性化一站式服务。其次是中间件应用。它可以部署在任何需要的位置，并所有经过的报文。并根据功能需求，添加不同的中间件。但是使用单位需要考虑将其部署在需要的位置。最后，向交换机或路由器中添加功能。网络设备提供者可以频繁的向设备中以固件的形式添加新的功能特征。直接向交换机或路由器中添加新的高级功能可以减少固件的数量。然而这也同时提高了网络规划的难度——高级功能固件放置位置。网络经营者需要考虑整个网络代价、能耗以及网络脆弱性等情况。

软件定义网络提供了面向网络流的可编程控制，中间件的部署问题在SDN中不存在，因为网络流量可以被编程控制转发到任何中间件所在的位置。策略存储在逻辑上集中的控制平面，但在其下发到可编程控制平面时被执行。

文献[42]给出了一种基于SDN网络的可通过众包 (Outsourcing)的形式向网络中添加功能的架构——Jingling。在该模型中，网络仅完成数据转发；任何额外的处理通过网络外部所谓“功能特征提供者”(Feature Providers, FPs)完成。FPs提供并管理功能特征，通过测量和移动实现对用户需求的响应，提供自动化的故障恢复。企业可降低费用和管理复杂性，通过FP规范提高功能特征集在服务中的机会。模型的核心是一个策略组件和一个功能特征API (FAPI)。策略规定功能特征而不是位置，并可使功能特征放在任意位置。FAPI在企业和FP的控制平面完成通信以共享策略和配置功能特征。网络功能的众包模式由很多优点，首先，它允许一个企业网络变得简单化，仅需要维护一些该企业需要的特定功能，无需担心购买、部署和维护大量中间件以及包含复杂功能的交换机。其次，它允许外部FP更专注于其擅长的业务，以提供更好服务获得更多客户。最后，通过不同FP之间的竞争，它激发了服务的提升。

因此众包模式使得任何人均可提供一种服务，无需考虑网络位置，功能可以添加在任何位置，并被任何需要的客户调用。如图 14所示为Jingling的体系架构，它包括三方利益相关人：企业、服务提供商(Internet Service Provider, ISP)，功能特征提供商(FP)。在网络中，企业与FP之间不可能位于相邻位置，因此需要ISP提供的网络通信。企业网管理员配置策略确定应用某功能特征到特定流量。策略被安装在企业控制平面或者企业网控制器上，企业网控制器包括转化单元和拓扑监控单元，前者基于已配置的功能特征集和当前网络拓扑将策略映射为网络配置，当发生诸如链路和交换机添加、删除或故障等网络拓扑变化更新网络配置。该控制器同时维护拓扑和策略信息数据库。

资源管理器(Resource Manager, RM)之于FP就像企业网控制器之于企业一样。RM配置FP的资源以生成处理流水线(Processing pipelines)以实现功能特征组合。RM的结构与企业网管理器类似。来自企业网控制器的策略存储在RＭ的策略数据库中，并将其翻译成网络配置。当前已配置的功能信息则存储在功能特征数据库中。管理组件则负责创建、删除以及迁移功能特征实例。当功能特征实例或网络状态改变后，网络配置需要更新。

图 14 精灵体系结构

综上所述，文献[42]提出了一种开放北向接口的众包模型，然而实现众包模式的开放模型仍有很多问题有待解决。首先，虽然SDN网络可以根据需要完成网络流重定向，然而，如何根据功能特征实例位置重定向网络流量而使网络开销最小仍需研究。其次，众包模式使得任何实体或个人参与网络功能的开发和部署成为现实，可以预想，将来网络中势必存在具有相同功能的实例大量存在，因此，企业如何从众多网络实例中选择最佳实例的问题仍需要仅以步探索。再次，FP部署功能实例一般需要根据请求历史实现功能实例的迁移，例如，将功能实例迁移到网络的请求密集区以降低通信成本和响应时延。对于如何实现这种基于功能实例的迁移模型目前还没有研究。最后，功能特征客户的一条策略可能需要一组网络功能实例协同完成，因此，需要根据策略需求从全网范围内选择最佳的一组实例组合形成处理流水线。

开放的控制逻辑接口使得SDN控制器中运行各种控制功能实例，建立良好的网络功能组织模型不仅有利于编程接口规范化，促进控制功能的创新和繁荣，而且有利于协同不同功能实例，达到网络效用最大化。文献[43]设计了一种功能组合模型——Frenetic，该模型通过解决OpenFlow规则中的冲突实现模块间的组合。文献[44]提出的另一系统——Pyretic则从简化编程，实现SDN网络的功能组合。这两种系统均从实现网络功能组合的可编程特性出发根据用户的编程约束转化并执行指定的组合操作。文献[45]则从多种控制功能之间资源争用为出发点，提出了Corybantic系统，通过协调各控制模块之间的资源冲突实现控制功能模块的组合。但是该系统仅致力于解决资源争用冲突，并在集中式单控制器实现，并未考虑分布式控制器条件下的功能组合问题。

五、策略更新一致性

配置变化是网络不稳定的主要原因之一。它导致网络资源消耗，性能下降甚至安全问题。即使最初和最终的配置都是正确的，更新过程也经常经过很多中间配置阶段。这些阶段可能导致错误的网络行为。

Mark Reitblatt等[46]引入网络更新一致性的概念，保证配置转换过程中各种网络行为的一致性。Mark Reitblatt定义了两个层次的一致性抽象，报文级和流级。报文级一致性是使进入网络的所有报文都基于一致的全局网络配置来处理。流级一致性是报文级一致性的推广。它是保证相同流的所有报文采用相同的网络配置来处理。流级一致性可应用于HTTP 负载均衡中，因为同一TCP连接的所有报文需要到达同一服务器处理。保证在从初始配置转移到新配置过程中的每包(per-packet consistency)或每流(per-flow consistency)是由初始配置或新配置处理，但不是有两者混合处理。在集中式场景中，他们提出了一种两阶段(two-phase) 每包一致更新算法，首先安装新配置到内部端口，然后更新到输入端口中。

从分布式系统的角度研究SDN的代表性工作之一是onix[25]，一种能够扩展控制应用的控制平面平台。其主要贡献是从控制逻辑中分离网络状态分布任务，允许应用开发者可以在一致性(consistency)、持久性(durability)和扩展性(scalability)之间取得折中。然而，Onix期望开发者提供检测和解析由并发控制引起的网络状态冲突的必要逻辑。在工作[47]中，Levin等研究了SDN中逻辑上中心化的抽象，并指出该设计对网络视图强一致性的内在支持。它们用一个分布式负载均衡的控制应用证明了该设计的性能。

在文献[46]的基础上，文献[48]的焦点如何设计一个支持并发和策略组合的更一般的一致性的分布式控制平面。它基于二元语义(all-or-nothing semantics)的事物型接口(transactional interface)提供一种更好的策略组合抽象：策略更新要么提交，要么丢弃。在前者情况下，策略保证在整个网络的组合一致性。在后者情况下，任何报文都不会受其影响。最终，控制程序逻辑无语担心易错的同步或锁任务，而保持业务逻辑为中心的轻量级。

关于SDN更新一致性的研究是一个热门，本文也只是给出了几个代表性的研究论文，后续我也会专门写一篇SDN一致性的文章。

六、SDN控制平面部署研究

SDN控制平面部署的研究感觉是“新瓶装老酒”的感觉，方法都是经典的方法，因此，这方面的研究个人认为，不愠不火(不同观点者勿喷)。

SDN控制平面从集中式控制转向分布式控制面临的首要问题是在给定的网络中部署多少控制器以及这些控制器放置在什么位置。该问题归结为控制器部署问题[39]。Brandon Heller等[39]基于最小化控制器-交换机的交互延迟首次研究SDN中控制器部署问题。

理论上该问题与定位问题相同，在以部署对象数量为输入的情况下属于NP-hard问题。设图，边权重代表传播延迟，代表节点到节点的最短路。节点数量，控制器放置方案的平均传播延迟为

对应地，该问题与最小化-均值一样，其目标是从所有可能的控制器部署方案中搜索部署方案，使得，且最小化。关于该方法的求解方法概述，可以参考文献[49]。

控制器部署方案最坏情况下的延迟定义为最大化交换机-控制器传播延迟：

该问题是求解最小化延迟和控制器布局量之间的鞍点。与之相关的优化问题为最小化-中心[50]。

与上述建模方法不同，文献[39]则是在延迟上限内部署控制器使得控制器内节点数量最大化；该问题基于任意重叠集合的一般形式为最大化覆盖问题。设数量以及一组集合，其中。目标是搜索一个的子集，使得最大化，且。每个集合包含所有在延迟上限内的节点[51]。

然而，该工作使用遍历算法枚举每种方案以得到精确结果。通过对不同目标的情况下的结果比较，作者发现，在中等规模的网络中，仅考虑延迟的情况下，一个控制器已经足够应对整个网络的请求。目前，文献[39]指出控制器部署研究可能的方向如下
可用性：全分布式控制器的一大优点是提高网络的可用性以及故障的容忍性。然而，路由波动、BGP“wedgies”以及增大路由收敛时间等问题使得全分布式控制难以实施。网络可用性问题等价于部署控制器以最大化故障容忍度，或者最小化到达个最近控制器的距离，即-neighbor和 -centers 问题。

状态分布式：控制平面的解耦使得诸如DHT和Paxos等面向状态的方法可以代替传统面向消息的方法。然而，如何在网络中合理布局控制逻辑以最优化全部事件响应延迟并保持分布式状态信息的一致性需要深入研究或借鉴现有分布式系统研究成果。

控制器选择：数据平面与控制平面解耦合引发了如何保持控制器与转发设备的映射问题。以最小化延迟的控制器部署为起点，研究人员可设计动态算法实现控制器到交换机的均衡映射。

总之，控制器部署方案为SDN经营者和应用设计者提供有益的指导。事实上，没有通用的部署规则能够应用于所有网络中。而且，每当经营者添加控制器，他们都需要重新运行部署算法重新部署。然而，该结论是基于控制器与交换机之间静态映射为条件得出的，通过控制器-交换机之间的动态映射可以增量式地放大或收缩控制网络，或者在控制器之间均衡交换机负载。

七、控制器安全

关于SDN安全是近几年的研究热点，也是笔者最近的研究重点。近几年的四大顶级安全会议均有SDN安全方面的相关论文。SDN的安全研究可以归为两类：SDN自身的安全研究和基于SDN的网络安全技术研究。后续我也会专门撰文扯一扯SDN安全问题，这里先简单地介绍下，埋个伏笔。引用下文章[]的总结图，说明下SDN面临的安全问题，虽然是几年前的研究，总结的还是挺全面的。

图 15 SDN面临的安全问题

其中一些安全问题还是很要命的，例如，DOS攻击，较明显的就是Packet-In洪泛，直接把控制器致瘫。关于SDN的防御研究，尤其是针对控制器的防御加固，也由一些，较早一点的FortNOX[52]，后续的Rosemary[53]，以及去年的SE-Floodlight[54]，大家可以去下载相关论文去拜读下。基本思路差不多，应用程序与控制器内核分离，应用程序调用内核需要分级，调用过程需要认证等，将主机操作系统那套设计原则拿过来。总体感觉，若按照这些文章的设计思路，基本要重构原有的控制器代码了，如果能够提供相关的安全框架设计，而不必大范围地修改已有控制器代码，岂不更好。

最后，介绍几个SDN安全研究比较活跃的科学家：Guofei Gu[55]，SRI International的Phillip Porras[56]以及Seungwon Shin[57]等。

参考文献
[1]MIT technology review. 2009. http://www2.technologyreview.com/article/412194/tr10- software-defined-networking/.
[2]A. Greenberg, G. Hjalmtysson, D. A. Maltz, et al., “A clean slate 4D approach to network control and management,” in SIGCOMM CCR, 2005.
[3]H. Yan, D. A. Maltz, T.S. Eugene Ng, et al., Tesseract: A 4D Network Control Plane, in NSDI 2007
[4]M. Caesar, D. Caldwell, Nick Feamster, et al. Design and Implementation of a Routing Control Platform, in NSDI 2005
[5]M. Casado, M. J. Freedman, and S. Shenker, “Ethane: Taking Control of the Enterprise,” in ACM SIGCOMM, 2007.
[6]N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, et al., “Openflow: enabling innovation in campus networks,” SIGCOMM CCR, 2008.
[7]Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, “B4: Experience with a Globally-Deployed Software Defined WAN,” in Proc. of ACM SIGCOMM, Augest, 2013, 3-14.
[8]Chi-Yao Hong, Srikanth Kandula, Ratul Mahajan, Ming Zhang, Vijay Gill, Mohan Nanduri, Roger Wattenhofer, “Achieving High Utilization with Software-Driven WAN,” in Proc. of ACM SIGCOMM, Augest, 2013, 15-26.
[9]N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. Mckeown, and S. Shenker, “NOX: Towards an Operating System for Networks,” in SIGCOMM CCR, 2008.
[10]POX. http://www.noxrepo.org/pox/about-pox/.
[11]Amin Tootoonchian, Sergey Gorbunov, Yashar Ganjali, Martìn Casado, Rob Sherwood. On Controller Performance in Software-Defined Networks. Hot-ICE 2012.
[12]Z. Cai, A. L. Cox, and T. S. E. Ng, “Maestro: A system for scalable OpenFlow control,” Tech. Rep. TR10-11, CS Department, Rice University, Dec. 2010.
[13]David Erickson, "The Beacon OpenFlow Controller," In Proc. 1st Workshop on Hot Topics in Software Defined Networking (HotSDN 2013), pages 13-18, Hong Kong, 2013. ACM Press.
[14]Floodlight. http://floodlight.openflowhub.org/.
[15]Volkan Yazıcı et al. Controlling a Software-Defined Network via Distributed Controllers. In NEM Summit, 2012.
[16]FlowScale. http://www.openflowhub.org/display/FlowScale/FlowScale+Home.
[17]Ryu. 2014. http://osrg.github.com/ryu/.
[18]Trema. 2014. http://trema.github.com/trema/.
[19]Mul. 2014. http://sourceforge.net/projects/mul/.
[20]SNAC. 2014. http://www.openflow.org/wp/snac
[21]Nascimento M, Rothenberg C, Salvador M, Corrêa C, Lucena S, Magalhães M. Virtual routers as a service: The RouteFlow approach leveraging software-defined networks. In: Proc. of the 6th Int’l Conf. on Future Internet Technologies (CFI). Seoul: ACM Press, 2011. 34−37.
[22]A. Tootoonchian and Y. Ganjali, “HyperFlow: A Distributed Control Plane for OpenFlow,” in INM/WREN, 2010.
[23]A. Bavier, N. Feamster, M. Huang, L. Peterson, and J. Rexford. In vini veritas: realistic and controlled network experimentation. In SIGCOMM ’06, pages 3–14, New York, NY, USA, 2006. ACM.
[24]B. White and J. L. et al. An integrated experimental environment for distributed systems and networks. In Proc. of the Fifth Symposium on Operating Systems Design and Implementation, pages 255–270, Boston, MA, Dec. 2002. USENIX Association.
[25]Teemu Koponen, Martin Casado, Natasha Gude, Jeremy Stribling, Leon Poutievski, Min Zhu, Rajiv Ramanathan, Yuichiro Iwata, Hiroaki Inoue, Takayuki Hama, and Scott Shenker. Onix: a distributed control platform for large-scale production networks. In Proc. OSDI 2010, pages 351-364, Berkeley, 2010. USENIX Association.
[26]C. A. B. Macapuna, C. E. Rothenberg, and F. Magalh. In-packet bloom filter based data center networking with distributed openfow controllers. In Proceedings of IEEE International Workshop on Management of Emerging Networks and Services, pages 584-588, 2010.
[27]A.-W. Tam, K. Xi, and H. Chao. Use of devolved controllers in data center networks. In Processings of the IEEE Computer Communications Workshops, pages 596-601, 2011.
[28]Soheil Hassas Yeganeh and Yashar Ganjali. Kandoo: a framework for efficient and scalable offloading of control applications. In Proc. 1st Workshop on Hot Topics in Software Defined Networking (HotSDN 2012), pages 19-24, New York, 2012. ACM Press.
[29]A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, and S. Banerjee. DevoFlow: scaling flow management for high-performance networks. In Proceedings of the ACM SIGCOMM 2011 conference, pages 254-265, 2011.
[30]M. Yu, J. Rexford, M. J. Freedman, and J. Wang. Scalable flow-based networking with DIFANE. In Proceedings of the ACM SIGCOMM 2010 conference, pages 351-362, 2010.
[31]A. Dixit, F. Hao, S. Mukherjee, T. Lakshman, R. Kompella, "Towards an Elastic Distributed SDN Controller," In Proc. 1st Workshop on Hot Topics in Software Defined Networking (HotSDN 2013), pages 7-12, Hong Kong, 2013. ACM Press.
[32]Hinrichs, T.L., Gude, N.S., Casado, M., Mitchell, J.C., Shenker, S., “Practical declarative network management,” In: WREN ’09: Proceedings of the 1st ACM workshop on Research on enterprise networking. pp. 1–10. ACM, New York, NY, USA (2009).
[33]Andreas Voellmy et al. Nettle: Taking the sting out of programming network routers. PADL, 2011.
[34]Andreas Voellmy et al. Scalable software defined network controllers. In SIGCOMM, 2012.
[35]Andreas Voellmy, Junchang Wang, Y. Richard Yang et al. Maple: Simplifying SDN Programming using Algorithmic Policies. In proc. Of SIGCOMM’13, Aug, 2013, Hong kong, China, 87-98.
[36]Andrew D. Ferguson, Arjun Guha, Chen Liang et al. Participatory Networking: An API for Application Control of SDNs. In proc. Of SIGCOMM’13, Aug, 2013, Hong kong, China.
[37]Andrew D. Ferguson, Arjun Guha, Chen Liang et al. Hierarchical Policies for Software Defined Networks. In proc. Of ACM SIGCOMM HotSDN’12, Aug, 2012, Helsinki, Finland.
[38]Arjun Guha, Mark Reitblatt, and Nate Foster. Machine-verified network controllers. In PLDI, 2013.
[39]Brandon Heller, Rob Sherwood, and Nick McKeown. The controller placement problem. In Proc. 1st Workshop on Hot Topics in Software Defined Networking (HotSDN 2012), pages 7-12, New York, 2012. ACM Press.
[40]Stefan Schmid, Jukka Suomela, "Exploiting Locality in Distributed SDN Control," In Proc. 1st Workshop on Hot Topics in Software Defined Networking (HotSDN 2013), pages 121-126, Hong Kong, 2013. ACM Press.
[41][16] Christopher Monsanto, Nate Foster, Rob Harrison, and David Walker. A compiler and run-time system for network programming languages. In POPL, 2012.
[42]Glen Gibb, Hongyi Zeng, Nick McKeown, Outsourcing Network Functionality. HotSDN'12, August, 2012, Helsinki, Finland, 73-78.
[43]N. Foster, R. Harrison, M. J. Freedman, C. Monsanto, J. Rexford, A. Story, and D. Walker. Frenetic: A Network Programming Language. In Proc. ICFP, pages 279–291, 2011.
[44]C. Monsanto, J. Reich, N. Foster, J. Rexford, and D. Walker. Composing Software-Defined Networks. In USENIX NSDI, 2013.
[45]J. C. Mogul, A. AuYoung, S. Banerjee, et al, "Corybantic: Towards the Modular Composition of SDN Control Programs" Hotnets'13 November, 2013, 1-7.
[46]Mark Reitblatt, Nate Foster, et. al., "Abstractions for Network Update," SIGCOMM'12, August, 2012, Helsinki, Finland.
[47]J. P. John, E. Katz-Bassett, A. Krishnamurthy, T. Anderson, and A. Venkataramani, “Consensus routing: The Internet as a distributed system,” in NSDI, Apr 2008.
[48]Marco Canini, Petr Kuznetsov, et. al., "Software Transactional Networking: Concurrent and Consistent Policy Composition," HotSDN'13, August, 2013, Hong Kong, China.
[49]M. Shindler. Approximation algorithms for the metric k-median problem. Written Qualifying Exam Paper, University of California, Los Angeles. Cited on, page 44.
[50]V. Vazirani. Approximation algorithms. Springer Verlag, 2001.
[51]D. Hochba. Approximation algorithms for np-hard problems. ACM SIGACT News, 28(2):40–52, 1997.
[52]Seungwon Shin, Vinod Yegneswaran, Martin Fong, Mabry Tyson, Guofei Gu. “A security enforcement kernel for OpenFlow networks”, ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (SIGCOMM-HotSDN), Helsinki, Finland, August 2012
[53]Seungwon Shin, Yongjoo Song, Taekyung Lee, Sangho Lee, Jaewoong Chung, Phillip Porras, Vinod Yegneswaran, Jisung Noh and Brent Byunghoon Kang, “Rosemary: A Robust, Secure, and High-performance Network Operating System”, ACM Conference on Computer and Communications Security (CCS), Scottsdale, Arizona, USA, Nov., 2014
[54]Phillip Porras, Steven Cheung, Martin Fong, et al., Securing the Software-Defined Network Control Layer. ACM NDSS ’15, 8-11 February 2015, San Diego, CA, USA.
[55]Guofei Gu‘s website: http://faculty.cs.tamu.edu/guofei/
[56]Phillip Porras’s website: http://www.csl.sri.com/users/porras/
[57]Seungwon Shin’s website: http://nss.kaist.ac.kr/?page_id=29