Exibir código-fonte para SDN - Controlador

= Fase I - Estudo  =

<br> 

== Título da Idéia  ==

 Software Defined Network Controller - OpenDaylight

<br>

== Objetivos  ==

Pretende-se, com a realização desta pesquisa, um maior aprofundamento e entendimento do funcionamento e da implementação de um controlador SDN. Neste caso, pretende-se focar no estudo da plataforma OpenDaylight. O intuíto do projeto é integrar o controlador SDN OpenDaylight com o orquestrador e gerenciador de NFV chamado OSM (Open Source MANO). 

<br>

== Conceito  ==

<br> 


Existem várias novas tecnologias que atualmente sustentam o desenvolvimento das indústrias de telecomunicações, muitas dos quais são reunidos sob as redes móveis 5G. No centro desses desenvolvimento está a ''Network Functions Virtualisation'' (NFV), que permite uma mudança significativa na flexibilidade das redes móveis e sua capacidade de oferecer suporte a uma variedade muito maior de serviços, como dispositivos ''Internet of Things'' (IoT), bem como nas novas aplicações emergentes na indústria automotiva [1].

O poder do NFV é que ele permite a automação total de muitos processos que eram anteriormente manuais e lentos. Em contraste com processos manuais atuais, a implantação de funcionalidades específicas de serviço para onde quer que seja adequado na rede pode ser muito mais barato e rápido usando a automação total através do NFV. O NFV é, portanto, o componente chave da tecnologia que prevê uma explosão nos serviços com 5G. Claro, o NFV não se restringe ao acesso móvel e essa automação de processos terá um impacto semelhante sobre toda a rede [1].

De acordo com a arquitetura do framework MANO, o NFV pode ser dividido em três partes:

1. '''O NFVI e VIMs / WIMs'''. A primeira parte é a infraestrutura do NFV (NFVI), que hospeda máquinas virtuais e/ou contêineres e os conecta com links virtuais (VLs). O "Virtualized Infrastructure Manager" (VIM) é responsável por controlar e gerenciar os recursos virtualizados de computação, armazenamento e rede do NFVI-PoP, enquanto o "WAN Infrastructure Manager" (WIM) é usado para estabelecer conectividade entre os NFVI-PoP. O VIM é geralmente implementado usando um controlador de nuvem baseado no OpenStack. Ele faz interface com as implementações de referência NFVO / VNFM usando a API OpenStack. O OpenStack permite segregar os recursos em zonas de disponibilidade para diferentes locatários e instanciar a criação / migração / exclusão de VMs e CTs (serviço de computação), armazenamento de imagens de disco (serviço de imagem) e o gerenciamento das interfaces de rede da VM / CT e conectividade de rede (serviço de rede). O WIM pode ser executado por controladores SDN de transporte dedicados (por exemplo, OpenDaylight, ONOS, Ryu), encarregados de gerenciar o pacote e as tecnologias ópticas. No entanto, a principal limitação dessa abordagem é que atualmente a interface entre o NFVO e o WIM não é amplamente implementada e ainda carece de maturidade [2].

2. '''VNFs, NSs e fatias de rede.''' A segunda parte é a coleção dos próprios VNFs, incluindo composição de VNFs em serviços de rede (NSs), e a composição e compartilhamento de NSs para formar o "network slicing". Os VNFs são composições interconectadas de VMs específicas e/ou contêineres hospedados no NFVI [1].

3. '''Gerenciamento e Orquestração (MANO).''' A terceira parte é a gestão e orquestração do sistema que controla o ciclo de vida dos VNFs, NSs e ''network slicing'', controla e mantém suas configurações e monitora sua saúde e seu desempenho [1].


Nos casos em que o VIM não suporta nativamente o gerenciamento de '''''underlay networking''''', O OSM é capaz de fornecer a funcionalidade de manipulação da conectividade com a ajuda de um controlador SDN, que gerencia uma malha na qual os nós de computação do VIM estão conectados. Esta funcionalidade exclusiva do OSM, chamada '''''SDN Assist''''', permite que o OSM[1]:

1. Forneça a conectividade do plano de dados que o VIM não pode gerenciar.

2. Trate o conjunto VIM + SDN Assist como um único VIM "aprimorado", para que, a partir de perspectiva do usuário, eles se comportarão como uma função regular de gerência única de uma determinada plataforma de infraestrutura virtual.


Para funcionar corretamente, é um pré-requisito ter um delineamento claro entre o conhecimento e responsabilidade do VIM e do controlador SDN:

O VIM ficará encarregado de implantar as VMs e as '''''overlay networks''''', além de fornecer a OSM as informações sobre os nós e interfaces atribuídos às VMs [1].

O controlador SDN será responsável por criar a '''''underlay network''''', tomando como condição limite os switches e as portas a serem conectados à mesma rede. A topologia de comutação interna do datacenter será conhecida pelo controlador SDN, alimentado como parte do provisionamento de atividades (ou seja, antes de qualquer processo de instanciação) [1].

O Open Source MANO é uma solução para essa terceira parte do NFV e isso dá ao OSM seu escopo geral. OSM visa apoiar a maior variedade de NFVI, VIMs, WIMs, bem como a maior variedade possível de VNFs, NSs e "network slicing". Além de cobrir a maior variedade possível de NFVI e funções hospedadas e serviços, o OSM é um sistema de orquestração e gerenciamento que gerencia o ciclo de vida, aspectos de configuração e vida útil das funções hospedadas.

Entretanto, este estudo será focado na ferramenta de SDN, o controlador OpenDaylight. Como supracitado, o OpenDaylight é o controlador que irá interagir com o OSM para gerenciar e controlar os pacotes e tecnologias da rede óptica.

'''''Software Defined Network (SDN)'''''

A rede definida por software (SDN), é um paradigma de rede emergente que dá esperança de mudar os limites das infraestruturas das redes atuais. Primeiro, o SDN quebra a integração vertical, separando o controle da rede lógica (o plano de controle) dos roteadores e comutadores que encaminham o tráfego (o plano de dados). Segundo, com a separação dos planos de controle e dados, os ''switches'' da rede  tornam-se dispositivos de encaminhamento simples e o controle é implementado em um controlador logicamente centralizado (ou sistema operacional de rede), simplificando a aplicação de políticas, (re)configuração e evolução de redes. Um visão simplificada dessa arquitetura é mostrada na Figura 1. É importante enfatizar que um modelo programático logicamente centralizado não implica em um sistema fisicamente centralizado. De fato, a necessidade de garantir níveis adequados de desempenho, escalabilidade e confiabilidade impediriam tal solução. Ao invés disso, redes SDN recorrem à sistemas de plano de controle fisicamente distribuídos [3].

A separação do plano de controle e do plano de dados pode ser realizado por meio de uma programação bem definida de uma interface entre os ''switches'' da rede e o controlador SDN. O controlador exerce controle direto sobre o estado nos elementos do plano de dados através do uso de uma ''application programming interface'' (API), como mostrado na Figura 2. O exemplo mais notável de uma API é o OpenFlow. Um ''switch'' OpenFlow possui uma ou mais tabelas de regras de manipulação de pacotes (''flow table''). Cada regra corresponde a um subconjunto do tráfego e executa certas ações (descartar, encaminhar, modificar, etc.) nos pacotes em trânsito. Dependendo das regras instaladas pela aplicação de um controlador, um ''switch'' OpenFlow pode - instruído pelo controlador - comportar-se como um roteador, ''switch'', ''firewall'' ou desempenhar outras funções (por exemplo, balanceador de carga, modelador de tráfego e, em geral, os de uma caixa intermediária).

De acordo com Diego et al. (2014), o SDN pode ser definido como uma arquitetura de redes apoiada nos quatro pilares a seguir [3]:

1) Os planos de controle e dados são dissociados. A funcionalidade de controle é removida dos dispositivos de rede que se tornarão simples elementos de encaminhamento (pacote);

2) As decisões de encaminhamento são baseadas no fluxo de dados, e não no seu destino. Um fluxo é amplamente definido por um conjunto de valores de campos de um pacote que age como um critério de correspondência (filtro) e um conjunto de ações (instruções). No contexto SDN / OpenFlow, um fluxo é uma sequência de pacotes entre uma origem e um destino. Todos os pacotes de um fluxo recebem políticas de serviço idênticas nos dispositivos de encaminhamento. A abstração de fluxo permite unificar o comportamento de diferentes tipos de dispositivos de rede, incluindo roteadores, ''switchs'', ''firewalls'' e ''middleboxes''. A programação do fluxo permite flexibilidade sem precedentes, limitada apenas aos recursos das tabelas de fluxo implementadas;

3) A lógica de controle é movida para uma entidade externa, o chamado ''SDN Controller'' ou ''Network Operating System'' (NOS). O NOS é uma plataforma de software que roda em servidores com a utilização de virtualização e fornece os recursos e abstrações essenciais para facilitar a programação dos dispositivos de encaminhamento com base em uma visão de rede abstrata e logicamente centralizada. Portanto, seu objetivo é semelhante ao de um sistema operacional tradicional;

4) A rede é programável através da utilização de aplicações de software que ficam em execução no NOS e interagem com os dispositivos do plano de dados. Isso é uma característica fundamental do SDN, considerada como seu principal valor proposição.


<br>

== Características&nbsp;  ==

<br> 

 Informe sobre as particularidades, aspectos e atributos desta idéia.

<br> 

<br> 

== Estudo Dirigido  ==

<br> 

'''''SDN Controller'''''

Uma arquitetura SDN pode ser descrita como uma composição de diferentes camadas, como mostra Figura 1 (b). Cada camada tem suas próprias funções específicas. Embora alguns deles estejam sempre presentes em uma implantação SDN, como a ''south API'', NOS, ''north API'' e aplicativos de rede, outros podem estar presentes apenas em implantações específicas, como ''hypervisors'' ou virtualização baseada em linguagens [3]. Esta pesquisa é focada em ''SDN Controller'' ou NOS, e, portanto, será feito uma descrição detalhada apenas da camada referente a este tema.

COLOCAR FIGURA 1

''''' Camada 4: Network Operating Systems (NOS) / Controlador '''''

A SDN promete facilitar o gerenciamento da rede e aliviar o ônus da solução de problemas de rede por meio do controle logicamente centralizado oferecido pela ''network operating system'' (NOS). Como nos sistemas operacionais tradicionais, o objetivo do NOS é fornecer abstrações, serviços essenciais e interfaces de programação de aplicativos (APIs) para desenvolvedores. Além disso, o NOS também pode fornecer funcionalidades genéricas como: estado da rede e informações de topologia de rede; descoberta de dispositivos; e a distribuição da configuração de rede. Com os NOSs, para definir políticas de rede, um desenvolvedor não precisa mais se preocupar com os detalhes de baixo nível da distribuição de dados entre os elementos de roteamento, por exemplo. É possível que esses sistemas criem um novo ambiente capaz de promover a inovação em um ritmo mais rápido, reduzindo a complexidade inerente à criação de novos protocolos e aplicativos de rede [3].

Um NOS (ou controlador) é um elemento crítico em uma arquitetura SDN, pois é a peça principal de suporte para a lógica de controle (aplicativos) para gerar a configuração de rede com base nas políticas definidas pelo operador de rede. Semelhante a um sistema operacional tradicional, a plataforma de controle abstrai os detalhes de níveis inferiores de conexão e interação com dispositivos de encaminhamento (i.e., de materializar as políticas de rede) [3].

'''''Arquitetura e design'''''

Do ponto de vista da arquitetura, um dos pontos mais relevantes é se a plataforma do ''SDN Controller'' é centralizada ou distribuída. Esse é um dos principais eixos de design das plataformas de controle SDN, assim, este aspecto será discutido a seguir.

'''Centralizado vs. Distribuído'''

Um controlador centralizado é uma entidade única que gerencia todos os dispositivos de encaminhamento da rede. Naturalmente, representa um único ponto de falha e pode ter limitações de escala. Um único controlador pode não ser suficiente para gerenciar uma rede com um grande número de elementos do plano de dados. Esses controladores são baseados em projetos com ''multithreaded'' para explorar o paralelismo das arquiteturas de computadores com vários núcleos. Como exemplo, o ''Beacon'' pode lidar com mais de 12 milhões de fluxos por segundo usando nós de computação grandes de provedores de nuvem, como a ''Amazon'' [3].

Ao contrário do design centralizado, um sistema operacional de rede distribuído pode ser ampliado, potencialmente, para atender aos requisitos de qualquer ambiente, de pequenas a grandes redes. Um controlador distribuído pode ser um ''cluster'' centralizado de nós ou um conjunto de elementos fisicamente distribuídos. Embora a primeira alternativa possa oferecer alta taxa de transferência para ''data centers'' muito densos, a última pode ser mais resistente a diferentes tipos de falhas lógicas e físicas. Um provedor de nuvem que abranja vários ''data centers'' interconectados por uma rede de área ampla pode exigir uma abordagem híbrida, com agrupamentos de controladores dentro de cada ''data center'' e nós de controlador distribuído entre os diferentes ''sites'' [3].


A maioria dos controladores distribuídos oferece semântica de consistência fraca, o que significa que as atualizações de dados em nós distintos acabarão sendo atualizadas em todos os nós do controlador. Isso implica que existe um período de tempo em que nós distintos podem ler valores diferentes (valor antigo ou novo valor) para uma mesma propriedade. A consistência forte, por outro lado, garante que todos os nós do controlador leiam o valor da propriedade mais atualizado após uma operação de gravação. Apesar de seu impacto no desempenho do sistema, uma forte consistência oferece uma interface mais simples para os desenvolvedores de aplicativos. Até o momento, apenas Onix, ONOS e SMaRtLight fornecem esse modelo de consistência de dados [3].

Outra propriedade comum dos controladores distribuídos é a tolerância a falhas. Quando um nó falha, outro nó vizinho deve assumir as funções e os dispositivos do nó com falha. Até o momento, apesar de alguns controladores tolerarem falhas de travamento, eles não toleram falhas arbitrárias, o que significa que qualquer nó com um comportamento anormal não será substituído por um potencialmente bem comportado [3].

'''''Dissecando as plataformas de SDN Controller'''''

Para fornecer uma melhor visão geral da arquitetura e entender o design de um sistema operacional de rede, a Tabela I resume algumas das propriedades de arquitetura e design mais relevantes dos controladores SDN e plataformas de controle. A tabela foca nos elementos, serviços e interfaces de uma seleção de controladores e plataformas de controle que se encontram bem documentados. Cada linha da tabela representa um componente considerado importante em uma plataforma de controle modular e escalável [3].

COLOCAR TABELA I

'''''Core controller functions'''''

As funções básicas de serviço de rede são consideradas as funcionalidades essenciais que todos os controladores devem fornecer. Como analogia, essas funções são como serviços básicos de sistemas operacionais, como execução de programas, controle de operações de I/O, comunicações, proteção e assim por diante. Esses serviços são usados por outros serviços no nível do sistema operacional e aplicativos do usuário. De maneira semelhante, funções como topologia, estatísticas, notificações e gerenciamento de dispositivos, juntamente com o encaminhamento de caminho mais curto e mecanismos de segurança, são funcionalidades essenciais de controle de rede que os aplicativos de rede podem usar na construção de sua lógica. Por exemplo, o gerente de notificações deve poder receber, processar e encaminhar eventos (por exemplo, notificações de alarme, alarmes de segurança, alterações de estado). Os mecanismos de segurança são outro exemplo, pois são componentes críticos para fornecer isolamento básico e aplicação de segurança entre serviços e aplicativos. Por exemplo, regras geradas por serviços de alta prioridade não devem ser substituídas por regras criadas por aplicativos com uma prioridade mais baixa [3].

'''''Southbound'''''

No nível inferior das plataformas de controle, as ''southbound'' APIs podem ser vistas como uma camada de drivers de dispositivo. Eles fornecem uma interface comum para as camadas superiores, permitindo que uma plataforma de controle use ''southbound'' APIs diferentes (por exemplo, OpenFlow, OVSDB, ForCES) e plugins de protocolo para gerenciar dispositivos físicos ou virtuais existentes ou novos (por exemplo, SNMP, BGP, NetConf). Isso é essencial para compatibilidade com versões anteriores e heterogeneidade, ou seja, para permitir vários protocolos e conectores de gerenciamento de dispositivos. Portanto, no plano de dados, uma mistura de dispositivos físicos, dispositivos virtuais (por exemplo, Open vSwitch, vRouter) e uma variedade de interfaces de dispositivos (por exemplo, OpenFlow, OVSDB, of-config, NetConf e SNMP) podem coexistir. A maioria dos controladores suporta apenas o OpenFlow como uma ''southbound'' API. Ainda assim, alguns deles, como OpenDaylight, Onix e HP VAN SDN Controller, oferecem uma gama mais ampla de ''southbound'' APIs e/ou plugins de protocolo [3].

O OpenDaylight vai um passo além, fornecendo um ''Service Layer Abstraction'' (SLA) que permite que várias ''southbound'' APIs e protocolos coexistam na plataforma de controle. Por exemplo, sua arquitetura original foi projetada para suportar pelo menos sete protocolos e plugins diferentes: OpenFlow, OVSDB, NETCONF, PCEP, SNMP, BGP e LISP Flow Mapping. Portanto, o OpenDaylight é uma das poucas plataformas de controle que estão sendo concebidas para suportar uma integração mais ampla de tecnologias em uma única plataforma de controle [3].

'''''OpenDaylight'''''

Um controlador SDN reúne dois mundos diferentes - engenharia de redes e de software. Portanto, ele deve funcionar não apenas como uma plataforma na entrega da solução, mas também como uma "fundação" no desenvolvimento de aplicativos. A arquitetura do software do controlador OpenDaylight define padrões de criação e interação de aplicativos (APIs e RPC), serviços de aplicativos ''underlying'' (por exemplo, roteamento de mensagens, formatação e armazenamento de dados) e, finalmente, levou a novas ferramentas de desenvolvimento para um ambiente voltado para colaboração de código aberto [4].

'''''Model-Driven Network Management/Programmability'''''

Os protocolos escolhidos pelo OpenDaylight foram o NETCONF e o RESTCONF, e o modelo de linguagem escolhido foi o YANG.

O NETCONF é um protocolo de gerenciamento de rede do IETF que define a configuração e os conceitos operacionais do ''data store'', assim como o conjunto de operações criar, recuperar, atualizar, excluir (CRUD) que podem ser usadas para acessar esses ''data stores''. Além das operações CRUD dos ''data stores'', o NETCONF também oferece suporte ao ''Remote Procedure Call'' (RPC) e operações de notificação. As operações NETCONF são realizadas sobre uma camada simples de chamada (RPC). O NETCONF usa uma codificação de dados baseada em XML para a configuração e dados operacionais, bem como para suas mensagens de protocolo [4].

RESTCONF é um protocolo semelhante ao REST que fornece uma interface programática sobre HTTP para acessar dados definidos em YANG, usando os ''data stores'' definidos pelo NETCONF. Os dados de configuração e de estado são expostos como recursos que podem ser recuperados com o método HTTP GET. Os recursos que representam dados de configuração podem ser modificados com os métodos HTTP DELETE, PATCH, POST e PUT. Os dados são codificados em XML ou JSON [4].

O YANG foi originalmente desenvolvido para modelar dados de configuração e estado em dispositivos de rede, mas também pode ser usado para descrever outras construções de rede, como serviços, políticas, protocolos ou assinantes. YANG é estruturado em árvore ao invés de orientado a objetos; os dados são estruturados em uma árvore e podem conter tipos complexos, como listas e uniões. Além das definições de dados, o YANG suporta construções para modelar ''Remote Procedure Calls'' (RPCs) and ''Notifications'', o que o torna adequado para uso como um Interface Description Language (IDL) em um sistema orientado a modelos [4].

Referências:

[1] OSM scope, functionality, operation and integration guidelines. 2019.

[2] Disponível em <https://futurenetworks.ieee.org/tech-focus/may-2018/converged-fixed-mobile-access>. Acessado dia 09/09/2019.

[3] Software-Defined Networking: A Comprehensive Survey. 

[4] OpenDaylight: Towards a Model-Driven SDN Controller Architecture


<br>

= Fase II - Ensino  =

<br> 

== Conteúdo  ==

 Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
 Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável

<br> 

== Apresentação  ==

 Apresente ao grupo (reunião, EAD, Blog, ...)
 Publique aqui

<br>

== Metodologia ==
<br>

 Descrevas as metodologias usadas. Alguns exemplos:

 Estratégia de Job Rotation
 Estudos básicos para conhecimento do potencial
 Estudos básicos para entendimento sobre o problema
 Estudos para dar base aos pesquisadores
 Benchmarking com empresas estrangeiras 
 Aceleradoras de empresas
 Adoção de novas tecnologias
 Utilização da proposta de soluções Open-source
 Priorização no desenvolvimento interno
 Foco na não dependência de fornecedores
 Prática de formação dos talentos necessários 
<br>

= Fase III - Exemplo de Caso de Negócio<br>  =

<br> 

== Benefícios para quem for oferecer esta solução  ==

     Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias

<br> 

<br>

== Benefícios para o usuário  ==

     Descrever em tópicos os benefícios para os usuários desta solução.
     Pode se inspirar no Canvas.

<br> 

== Direcionadores chave para esta iniciativa  ==

     Descrever em tópicos o que esta iniciativa pode proporcionar

<br><br> 

== Possíveis modelos de negócios  ==

     Descrever em tópicos os possíveis modelos de negócios

== Business Case  ==

     Descrever um exemplo de negócio que permita avaliar a solução comercialmente

<br>

== Alinhamento com Lei do Bem ==
<br>

* Projeto possui algum elemento tecnologicamente novo ou inovador? 
 Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada
<br>

* Projeto possui barreira ou desafio tecnológico superável? 
 Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese
<br>

* Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico? 
 Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto
<br>

* Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?
 Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
 Anexar cópia do contrato
<br>

= Fase IV - Protótipo orientado ao Negócio  =

<br> 

== Escopo  ==

<br> 

 Explique o escopo deste protótipo

<br>

== Product Backlog  ==

<br> 

 Descreva os requisitos deste projeto
<br>

== Limitações  ==

<br> 

 Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

<br> 

== PoC  ==

<br> 

 Desenvolva um PoC (Proof of Concept)

<br> 

== Detalhamento Técnico  ==

<br> 

 Descreva especificamente os aspectos técnicos desta pesquisa

<br> 

<br> 

<br> 

<br> 

= Cronograma Macro  =

<br> 

= Histórico  =
<br>

* 28/02/2020: Bilel começa a participar com Sergio deste projeto
* '''05/10/2020''': Daniel Lima e Adailson serão convidados a participar deste projeto porque Nelson e Gilberto estão sobrecarregados com OOPT e Network Slicing.

<br> 

<br>

= Pesquisadores  =
* Enock Cabral Almeida Vieira
* Fernando Bagliano Junior
* Flávio Moretti Morais
* Gilberto Tadayoshi
* Nelson Orozimbo de Resende
* Raoni Exaltacao Masson
* Sergio Henrique Corgozinho

<br>