ONOS와 ODL은 각각 사업자와 제조업체가 주도하고 서로 다른 이해관계를 대표하므로 서로 다른 두 가지 SDN 진화 방법을 선택했습니다. 전자는 SDN이 처음 탄생했을 때의 좁은 SDN 개념에 더 가깝습니다. 즉, OpenFlow를 통해 제어 평면과 전달 평면이 완전히 분리되어 있습니다. 네트워크 장비는 전달을 위한 블랙박스일 뿐이며 모든 계산은 Controller를 통해 완료됩니다. . ONOS가 선택한 개념은 운영자의 이익과 밀접하게 관련되어 있습니다. 제어 기능을 자체적으로 활용해야만 전체 산업 체인에서 장비 제조업체의 통제를 점차적으로 없앨 수 있습니다. 원래 제조업체의 장비를 교체하기 위해 더 저렴한 포워딩 장비를 사용함으로써 한편으로는 현재 장비 제조업체와의 협상력을 높일 수 있고 다른 한편으로는 장기적으로 네트워크 구축 및 유지 관리 비용을 크게 줄일 수 있습니다. 이에 비해 ODL은 보다 완만한 SDN 진화 접근 방식을 채택하고 개념적으로 광범위한 SDN에 더 가깝습니다. 즉, OpenFlow 프로토콜에 국한되지 않고 전달 장치에서 제어 평면을 완전히 분리하는 데 국한되지 않습니다. 프로토콜은 컨트롤러에 제어 로직의 일부를 넣습니다. 이 개념은 광범위한 SDN 기술의 구현을 보다 쉽게 현실화하며, 한편으로는 사업자, 기업 등 장비 제조업체의 기존 투자를 보호하여 고객이 SDN 기술의 실제 효과를 실제로 느낄 수 있도록 합니다. 반면, 제조업체는 기존 장비에서 기존 네트워크 프로토콜을 확장함으로써 비용을 들이지 않고 장비 경쟁력을 유지하고 SDN 혁명에서 빠르게 뒤처지는 것을 방지할 수 있습니다.
기술적으로 SDN 컨트롤러는 실제로 디바이스와의 사우스바운드 통신 문제와 노스바운드 APP에서 제공하는 리소스 문제를 해결합니다. 네트워크 사업자가 자체 네트워크의 비즈니스 특성을 기반으로 제안하는 제어 로직에는 APP 개발이 필요합니다. 그것을 달성하기 위해. 사우스바운드 인터페이스의 관점에서 ONOS의 유일한 성숙한 사우스바운드 인터페이스는 OpenFlow인 반면, ODL Helium 버전은 OpenFlow, OVS-DB, MP-BGP, PCEP, NETCONF/YANG 등과 같은 광범위한 사우스바운드 인터페이스를 지원합니다. 다양한 종류의 장비를 연결하세요. 노스바운드 인터페이스의 관점에서 볼 때 ODL에서 사용하는 MD-SAL을 사용하면 YANG 모델을 통해 장치 리소스를 RESTConf API로 직접 변환할 수 있지만 ONOS는 ODL의 원래 버전에서 사용된 AD-SAL 아키텍처에 어느 정도 남아 있습니다. , API는 플러그인에서 개별적으로 설계되어야 합니다. 물론, 이 외에도 Controller의 성능과 확장성도 반드시 직면해야 할 문제입니다. 이런 점에서 ONOS는 실제로 ODL의 해결되지 않은 문제를 파악하고 처음부터 이 두 가지 측면을 주도해 사람들의 관심을 끌었습니다. 그러나 두 구현 모두 JAVA의 Karaf 프레임워크를 사용한다는 사실로 판단하면 성능과 확장 문제 사이에 근본적인 차이가 없습니다. 실제로 클러스터는 대규모 컴퓨팅에 대한 최종 솔루션이 될 것입니다. 실제로 두 컨트롤러는 해당 클러스터 배포 솔루션을 제공합니다. 유일한 문제는 ODL이 여러 사우스바운드 인터페이스로 인한 추가 소비도 처리해야 한다는 점일 수 있지만 ODL은 사우스바운드 인터페이스의 선택적 기능을 제공하며 실제 배포에 여러 프로토콜이 존재하는 경우는 거의 없습니다.
그러나 ONOS가 주로 OpenFlow를 홍보하지만 Wiki에는 ONOS에서 PCEP 및 TL1과 같은 사우스바운드 인터페이스를 개발하는 파트너 공급업체도 나열되어 있으므로 ONOS도 곧 시작될 것입니다. 다양한 사우스바운드 인터페이스 지원