ONF开源白皮书：SDN解决方案案例——校园SDN

1 Aspen:实时媒体接口规范（ONF）

Aspen源于通信技术标准化社区的一个想法，它希望借助SDN更加高效地为用户提供服务。部署了统一标准通信基础设施的企业用户，通常会拥有一些管理分片，用来管理数据流的重要等级以及需要提供的QoS信息。这样，企业用户无需依靠所有数据包上的QoS标记，就可以掌握数据流的QoS状况。而前者管理起来可能会非常复杂，并且有可能应用不当。

为了解决上述问题，ONF指定了一个API，使得应用程序根据QoS的需求通知SDN控制器。针对这一问题，最初的关注焦点是诸如Microsoft Lync或Cisco Webex这类统一通信服务，但很快就扩展到处理常见的媒体应用。

ONF正在通过使用开源媒体播放器VLC展示Aspen概念的可行性并加以验证。ONF展示的应用场景包括安装网元仿真工具mininet，由OpenDaylight VTN接口进行通过OpenFlow协议管控网络，以创建一个实时网络媒体服务。在VLC这一实例中，VLC通过调用标准的实时媒体北向接口（ONF草案中提出）连接到网络中。

这次演示展示了VLC的wrapper脚本通过启动主机1和主机4之间的视频流模拟RTM视频服务。然后，在主机2与主机5之间发送UDP流量。之后，系统检测数据包标签，并发现视频流具有优先权，而UDP流量不具有。实验结果显示良好，验证了视频质量。接着，从实时媒体网络中删去会话信息，使视频流不再具有优先权，再次实验。结果显示，视频质量差，出现视频中断，丢包及图像抖动现象。

同样的效果可以在使用该系统的UC会话或其他网络密集型应用中看到，未来的系统扩展可以通过安全与认证功能，为基于VTN的实时媒体服务引入应用接口。但是，如果运营商允许所有服务请求更高的服务质量，也就失去了所谓的服务差异化。正如实验人员所说，目前只是验证了相关概念，离商业化还有很远。

2Atrium:一个基于SDN的开源BGP Peering路由（ONF）

Atrium通过在多厂商环境中构建应用程序，达到简化和加速开放SDN采用的目的。这一演示方案的特点是，采用社区开发的开源SDN分发器。它是一种开源SDN组件的集成堆栈，用来帮助网络运营商快速实现实际部署。

Atrium的第一个发行版本——Atrium 2015/A，包含了边界网关协议（BGP），开放网络操作系统（ONOS）及开源计算项目（OCP）组件。运行在控制器或交换机上的软件单元通过OpenFlow协议相互通信，为其他交换方案提供引入插件的机会。从而促进了互通的、基于硬件的OpenFlow交换机的开源生态系统的形成。

Atrium 2015/A整合了之前独立的开源组件。路由功能是运营商部署SDN所需的最基本应用功能。Atrium 2015/A包含了Quagga BGP协议，因为它是一种颇受欢迎的开源路由堆栈。Atrium 2015/A构建在ONOS上，因为Quagga运行在ONOS上，并且开放网络实验室（ON Lab）贡献了相关工程资源来协助实现内部目标接口与其他项目集成。

在方案演示中，OpenFlow交换机组的作用类似独立的路由器，根据它所掌握的信息来跟踪流量。集成路由器由包含Accton、Centec Networks、Corsa、Netronome、NoviFlow、Pica8及Quanta的交换机。尽管各厂商的交换机使用的技术不同，但都通过OpenFlow与ONOS SDN控制器通信。

Aspen旨在通过重新引入互操作性来解决各种交换机的差异。为了达到这一目的，控制器与被称为流目标的抽象层通信。这一观点认为，应用只需写入一次就可以多次使用。这样，就可以为不同业务流提供驱动器，并且可以根据情况去掉某个驱动器。

ONF成员企业以及其他未透露名称的企业，已经将Atrium移植到OpenDaylight平台，这是在为今年稍晚些时候的发布做准备，确保OpenDaylight获得最广泛的业界支持，并为包括NFV、校园及数据中心的各种应用场景提供接口。

Atrium 15/B预备在2015年发布，将支持对当前版本的持续升级，包括健壮性、稳定性及性能的提升，并增加某些之前遗漏的功能，如运行时间设定与静态路由。此外，Atrium 15/B将包含一个基于硬件的自动化测试基础设施。

3Boulder:实现北向接口标准化（ONF）

Boulder源于ONF与惠普支持的Inocybe Technologies公司发起的项目。它的目标是去除行业的碎片化，这样开发者开发的应用，就可以实现跨接口与平台的可移植性，并且通过intent实现北向接口标准化以支持应用兼容。

Boulder将语义消息传输视为具有主语、谓语、宾语的语法。比如，主语是终结点，谓语是变量，要做什么，宾语是对象类型。语法的运行就像Bob（主语）联系（谓语）Susan（宾语）这样简单。Boulder允许进一步在语法中定义背景，比如上下文与限制，但并没有演示。

尽管最初依赖OpenFlow协议，如今Boulder可以作为ONOS流的模式之一加以利用，并且可以使用OpenDaylight的事务处理能力。作为相对较早的概念验证阶段，消息传输语法是有限的，随着补充六个动词来标明日期，包括允许、拒绝、联系或重定向等基本语义。这一项目于2015年3月开始时尚不成熟，因此还不能使用Boulder开发应用。然而，毫无疑问，应用开发者希望写一次程序，就可以跨多个虚拟基础设施使用。

今年秋天，将会发布Boulder官方版本。与会者预期这将加速Boulder的发展，并加入到当前的演示方案中。

演示方案本身基于JavaScript，并解释了通过使用intent语法，应用如何映射在OpenDaylight与ONOS域上。在ONOS域中，应用通过Boulder发起初始请求，即使用六个动词中的某个向ONOS进行时引擎发起性能请求。接着，ONOS进行时引擎对Boulder做出性能响应，即将某个intent发送给进行时引擎，再将来自引擎的intent作为ONOS intent发送。

类似地，在基于OpenDaylight的演示方案中，接收到初始请求的Boulder，向位于OpenDaylight顶层的网络intent组成层发送性能请求，OpenDaylight向Boulder返回性能响应。Boulder将这种机制升级，成为在OpenDaylight NIC中的本地语法，它可以创建某个OpenDaylight语法，如一个允许或请求策略指令。

在目前的状态下，Boulder解决了两个控制平面的兼容性问题—ONOS与OpenDaylight，但是随着这一项目的发展，Boulder将会支持更多控制器，比如OpenStack。以这种方式扩展Boulder，已经超出了它当前的应用范围。在当前阶段，Boulder的主要目标是，让应用开发者编写一次程序，就可以在多个控制器上使用。