2、开放网络操作系统(ONOS)
然而，正获得业界广泛支持的并非只有OpenDaylight这一个开源控制器项目。最近几个月来，ON.Lab的开放网络操作系统(ONOS)项目也已引起了业界的广泛兴趣，且有了长足的进步。根据ON.Lab最新的一份简报透露，在ONOS打算解决的一些关键问题中，最明确的一个问题就是应用扩展。SDN控制器的可扩展性一直是众多网络所担心的一个问题，更是服务商尤其担心的问题。
为什么控制器的扩展会成为一个问题?因为在单个x86盒子上运行的控制器应用会受到诸如本地CPU、内存、总线架构和存储I/O等能力的限制。一旦单一系统出现性能瓶颈时，该应用不可能跳出盒子去运行。要想让只为单一盒子运行而设计的应用进行扩展，就需要一个规模更大的盒子。网络从业者都知道，这意味着需要一个颇具颠覆性的升级过程。将一个应用迁移到一个更大的盒子上是一种挑战，即便在虚拟计算环境中亦是如此。
分布式计算系统是通过将应用以跨多个系统的分布方式运行在一个逻辑架构中来解决扩展问题的。扩展应用就意味着要增加更多的系统，而不再只是升级单个的系统。
ONOS的目标是创建这样一个SDN控制器，它可以处理每秒高达100万条的路径设置，以及每秒多达600万次的网络状态操作。换句话说，ONOS控制器需要面对如何定义一个非常庞大的网络路径库及其变化的问题。单盒架构已经无法适应这样的需求，于是带有分布式控制器架构的ONOS就应运而生了。
这并不是说其他的SDN控制器架构不重视扩展的需求。有些SDN架构可通过创建多个SDN域，然后进行联邦治理来处理负载的分布问题。在这种架构中，每个域由一个单独的控制器集群来管理，控制器集群负责与其他的域交换数据，从而形成一个联邦。这不是分布式计算模式(+微信关注网络世界)，而是一连串管理各个域的集中化控制器集群彼此间相互通信而已。
而ONOS控制器架构则遵循着一种真正的分布式计算模式，这个集中的控制器操作系统是跨多个控制器节点分布的。乍一看似乎跟上述系统差别不大，但这微妙的差别却非常重要。有了ONOS，一个单一的、分布式的ONOS实例便可维持一个网络状态的统一的全局视图。
ONOS与ODL的明显差异化还表现在其目标客户群为服务商。虽然它并不排斥企业用户，但其中的很多网络架构看上去都与服务商的网络架构相似，ONOS也和众多的服务商一样拥有全球化规模和超高节点连接。ONOS还从一开始就宣称它会让厂商的最终用户们参与进来，这对ODL来说是个不小的冲击，因为业界一直在诟病后者太过于厂商驱动了。
虽然企业的IT部门不太可能采纳ONOS，但至少在今天看来，这种分布式控制器架构还是令人印象深刻的。感觉ODL存在SDN扩展瓶颈的企业也许会想在其环境中测试一下ONOS，看看这种架构能否满足他们的需求。
ONOS在2015年3月发布的第二版叫黑鸟(Blackbird)。ONOS的第3版叫红衣主教(Cardinal)，2015年6月2日起可用。ONOS意图让自己的发布周期比ODL更快(大约每季度一次)，尽管其中没有太多可以像ODL的主版本那样的“新的”内容。
ONOS的一些现实用例也已经可以看到，例如前不久在Internet2一些区段网络中的部署。参与ONOS的重要厂商和机构包括AT&T、NTT、SK电信、Ciena、思科、爱立信、富士通、华为、英特尔、NEC、开放网络基金会(OpenFlow的维护机构)、Infoblox和其他一些企业等。
ONOS另一个让人感兴趣的地方就是它与OPNFV[注]项目的关系，这一项目正在为服务商使用网络功能虚拟化[注](NFV)构建一个框架。ON.Lab在今年5月8日宣布已批准启动了一个项目，将打通OPNFV框架和ONOS。这样的合作非常及时，因为OPNFV也正处于初期阶段。双方的合作意味着ONOS有可能很好地映射到OPNFV的构建中去，如此而形成的平台将能够让服务商们既可以拥有扩展性，又可拥有功能性。
