❶ ONOS與OpenDayLight有什麼本質區別
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也開始支持各種各樣的南向介面了