O projeto central do que muitas pessoas afirmariam ser verdadeiro em SDN é o protocolo de OpenFlow, que providencia os meios para um controle central gerenciar roteamento de rede. Diferente dos switchings e roteadores tradicionais, que “aprendem” o tipo de rede e a alcançabilidade ao adaptar trocas com elementos conectados e adjacentes, o SDN impõe regras mais avançadas baseadas em qualquer diretriz arbitrária que for requisitada.
A definição faz três pontos interdependentes, porém correlacionados. O primeiro ponto é que há um protocolo – OpenFlow – para controlar os dispositivos. O ponto dois é que há um mecanismo central para decidir como o roteador de rede deve ser. O ponto três é que há uma concepção de serviço por trás do que esse controle central decide. No mundo do SDN, vimos a polarização de soluções baseadas em quais desses pontos são os mais importantes. Você consegue construir SDN se você puder criar serviços – “NaaS” – independentemente de como é feito? É possível controles centrais de SDN, sem o OpenFlow?
O interessante do OpenDaylight é que o modelo de controle nesse contexto é que tem sido como uma experiência de abrir a mente.
O OpenDaylight (ODL) é de fato um modelo de controle, mas leva uma inclinação diferente no processo. Diferente do controle puro de SDN, o OpenDaylight pode teoricamente falar de infinitos números de controles de protocolos nas camadas de equipamentos e software de redes. O ODL também pode ser usado juntamente com o OpenFlow para controlar dispositivos que podem apoiar o protocolo de OpenFlow.
O OpenDaylight é essencialmente um mecanismo que opera entre os modelos NaaS e a infraestrutura. Se você possui modelos de NaaS que guiam para controles simples de conexão em IP e Ethernet, então não há OpenFlow envolvido pois você não precisa mudar modelos avançados por razões de NaaS. Isso faria com que a adoção ao OpenFlow fosse totalmente dependente da credibilidade de substituir switches para um switch ou roteador atualizado.
Com CimiCorp