1. 驱动方式不同
ONOS白皮书中写道，一个操作系统应该具备下述功能：
l 为用户管理有限的资源。
l 隔离和保护NOS用户。需要操作系统能复用多个应用和多个设备。
l 提供一个可用的抽象层让用户灵活的使用操作系统所管理的服务和资源，并且无需了解网络的复杂性。
l 为外部操作系统提供安全保障。
l 提供敏捷高效的服务，那么用户就不需要创建、重建相同的服务。
这些都是网络应用所需要的。通常控制器的所控制的范围十分局限，通常设置为控制一个设备。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能，例如可以提供高效敏捷的抽象层，能够将不同的控制器使用者隔离开来，能够提供有价值的服务等等。ONOS是根据服务提供商的特点和需求进行软件架构设计的。因此ONOS是需求驱动下的产物。
相比而言，目前围绕SDN的炒作更多的是来自设备供应商。OpenDaylight是由思科和IBM 联合其合作伙伴，以及竞争对手建立的组织。其初创成员包括：微软、Big Switch（已退出）、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商，和ONF不同的是OpenDaylight是由大厂商控制的并且削弱了用户的声音。并且它还可能会出于利益问题将部分功能同设备锁定，这并不是SDN的初衷。我们所期望的便是看到所有参与其中的人能共同推动SDN的进步。
2.面向对象不同
ONOS和OpenDaylight代表的阵营不同，
面向对象也不同。ONOS的设计理念是能在任何硬件（包括白牌机）上灵活的创建服务并且大规模部署，因其可靠性强，性能好，灵活度高的特点适用于面向服务
提供商和企业骨干网。它不仅可以满足运营商提供敏捷和灵活的需求，并且有可能使其摆脱设备供应商的束缚，因此很多运营商愿意接受ONOS。而最近发布的2.0版本的OpenDaylight以及来自其成员企业的支持给其带来了新的发展势头，但是因其成员关系，其在很大层面上受设备商的制约。因此OpenDaylight是设备商在一定程度上为了维护自己阵营的利益的产物，其主要面向对象也是设备商。
3.架构不同
ONOS架构设计伊始就将服务提供商放在首位。
ONOS架构：
向左转|向右转
OpenDaylight氦版本架构：
向左转|向右转
ONOS白皮书中写道，一个操作系统应该具备下述功能：
l 为用户管理有限的资源。
l 隔离和保护NOS用户。需要操作系统能复用多个应用和多个设备。
l 提供一个可用的抽象层让用户灵活的使用操作系统所管理的服务和资源，并且无需了解网络的复杂性。
l 为外部操作系统提供安全保障。
l 提供敏捷高效的服务，那么用户就不需要创建、重建相同的服务。
这些都是网络应用所需要的。通常控制器的所控制的范围十分局限，通常设置为控制一个设备。ONOS具备一个操作系统所具备的所有功能，不仅仅是控制器的功能，例如可以提供高效敏捷的抽象层，能够将不同的控制器使用者隔离开来，能够提供有价值的服务等等。ONOS是根据服务提供商的特点和需求进行软件架构设计的。因此ONOS是需求驱动下的产物。
相比而言，目前围绕SDN的炒作更多的是来自设备供应商。OpenDaylight是由思科和IBM 联合其合作伙伴，以及竞争对手建立的组织。其初创成员包括：微软、Big Switch（已退出）、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商，和ONF不同的是OpenDaylight是由大厂商控制的并且削弱了用户的声音。并且它还可能会出于利益问题将部分功能同设备锁定，这并不是SDN的初衷。我们所期望的便是看到所有参与其中的人能共同推动SDN的进步。
2.面向对象不同
ONOS和OpenDaylight代表的阵营不同，
面向对象也不同。ONOS的设计理念是能在任何硬件（包括白牌机）上灵活的创建服务并且大规模部署，因其可靠性强，性能好，灵活度高的特点适用于面向服务
提供商和企业骨干网。它不仅可以满足运营商提供敏捷和灵活的需求，并且有可能使其摆脱设备供应商的束缚，因此很多运营商愿意接受ONOS。而最近发布的2.0版本的OpenDaylight以及来自其成员企业的支持给其带来了新的发展势头，但是因其成员关系，其在很大层面上受设备商的制约。因此OpenDaylight是设备商在一定程度上为了维护自己阵营的利益的产物，其主要面向对象也是设备商。
3.架构不同
ONOS架构设计伊始就将服务提供商放在首位。
ONOS架构：
向左转|向右转
OpenDaylight氦版本架构：
向左转|向右转
温馨提示：内容为网友见解，仅供参考
第1个回答 2016-04-12
ONOS和ODL分别由运营商和厂商主导，所代表的利益不同，也就分别选择了两种不同的SDN演进方式。前者更贴近于SDN诞生之初时狭义的SDN概念，即通过OpenFlow将控制平面和转发平面完全分离，网络设备只是进行转发的黑盒子，通过Controller完成一切计算。ONOS所选择的理念与运营商自己的利益息息相关，只有将控制能力拿到自己手里，才能在整条产业链上逐步摆脱设备厂商的控制。通过使用更为廉价的转发设备替代原有的厂商设备，一方面在眼下增加自己与设备厂商的议价砝码，另一方面长远看能大大降低网络的建设和维护成本。相比较而言，ODL则采取了更为平缓的SDN演进方式，从理念上更为贴近广义的SDN，即不局限于OpenFlow协议，不局限于完全将控制平面从转发设备上剥离，通过已有的网络协议将部分的控制逻辑放到Controller上。这样的理念使广义的SDN技术的落地更容易成为现实，一方面通过保护运营商、企业等设备厂商客户的既有投资，使客户可以真正感受到SDN技术的实际效果。另一方面，通过在现有设备上扩展已有的网络协议，厂商能够使自己的设备在不用伤筋动骨就能保有竞争力，避免自己在SDN的革命中被迅速甩下。
从技术上讲，SDN Controller实际上解决的是南向与设备的通信问题和北向向APP提供的资源问题，网络运营者根据自己网络的业务特点提出的控制逻辑则需要开发APP来实现。从南向接口上看，ONOS目前成熟的南向接口只有OpenFlow，而ODL Helium版则支持OpenFlow、OVS-DB、MP-BGP、PCEP、NETCONF/YANG等极为丰富的南向接口以连接不同类型的设备。从北向接口上看，ODL采用的MD-SAL使得设备资源可以通过YANG model直接转换为RESTConf API，而ONOS还在某种程度上停留在ODL最初版本使用的AD-SAL架构，API需要在plugin设计时单独考量。当然除此之外，Controller的性能与Scale out也是必须面对的问题。对此，ONOS确实抓住了ODL尚未解决的问题，从一开始就从这两方面抢占先机，拨人眼球。不过从二者实现上都采用了JAVA的Karaf框架来看，性能与Scale out问题在根本上也不会存在先天的差别，面对海量计算采用Cluster会是最终的解决方法，而实际上两个控制器都提供了相应的Cluster部署方案。唯一的问题可能是ODL还需要应对多种南向接口带来的额外消耗，但ODL提供的是南向接口的可选能力，实际部署上也很少会出现多种协议共存的情况。
但值得一提的是，尽管ONOS主推OpenFlow，但在其Wiki上也列出了合作厂商正在ONOS上开发PCEP、TL1等南向接口，所以也许不久之后我们就会看到ONOS也开始支持各种各样的南向接口了
从技术上讲，SDN Controller实际上解决的是南向与设备的通信问题和北向向APP提供的资源问题，网络运营者根据自己网络的业务特点提出的控制逻辑则需要开发APP来实现。从南向接口上看，ONOS目前成熟的南向接口只有OpenFlow，而ODL Helium版则支持OpenFlow、OVS-DB、MP-BGP、PCEP、NETCONF/YANG等极为丰富的南向接口以连接不同类型的设备。从北向接口上看，ODL采用的MD-SAL使得设备资源可以通过YANG model直接转换为RESTConf API，而ONOS还在某种程度上停留在ODL最初版本使用的AD-SAL架构，API需要在plugin设计时单独考量。当然除此之外，Controller的性能与Scale out也是必须面对的问题。对此，ONOS确实抓住了ODL尚未解决的问题，从一开始就从这两方面抢占先机，拨人眼球。不过从二者实现上都采用了JAVA的Karaf框架来看，性能与Scale out问题在根本上也不会存在先天的差别，面对海量计算采用Cluster会是最终的解决方法，而实际上两个控制器都提供了相应的Cluster部署方案。唯一的问题可能是ODL还需要应对多种南向接口带来的额外消耗，但ODL提供的是南向接口的可选能力，实际部署上也很少会出现多种协议共存的情况。
但值得一提的是，尽管ONOS主推OpenFlow，但在其Wiki上也列出了合作厂商正在ONOS上开发PCEP、TL1等南向接口，所以也许不久之后我们就会看到ONOS也开始支持各种各样的南向接口了
相似回答
