| (22 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 5: | Linha 5: | ||
== Título da Idéia == | == Título da Idéia == | ||
SDN Controller: o que é, onde está implementado e situação em relação à redes de telecomunicações | |||
== Objetivos == | |||
*Avaliar o que se pode fazer com SDN | |||
*Avaliar as condições de implementação para redes de telecomunicações | |||
*Realizar considerações sobre a viabilidade da solução | |||
*Avaliar a possibilidade de estudo de SDN com a estrutura de Data Center. | |||
<br> | <br> | ||
== Conceito == | == Conceito == | ||
| Linha 19: | Linha 21: | ||
<br> | <br> | ||
Se pensarmos hoje, as redes tradicionais funcionam com base na informação por salto, ou seja, conforme o tráfego é recebido em cada um desses dispositivos - ele sozinho decide para onde enviá-lo, com base nas informações que recebe do resto da rede. | |||
Quando temos uma quantidade enorme de dispositivos para configurar, a automação é muito difícil, não confiável e cara. | |||
Dito isto, o SDN elimina a necessidade de gerenciar cada switch, roteador, firewall ou ponto de acesso individual. | |||
Se for necessário introduzir um novo serviço, por exemplo, a nova configuração só precisa ser concluída no controlador centralizado, que irá direcionar a rede de acordo com a configuração centralizada. Essa configuração centralizada é categorizada como uma política. <br> | |||
<br> | |||
O SDN propõe: | |||
*Uma separação clara do data plane (forwarding) e control plane. | |||
** Control plane define como os dados serão encaminhados (criação de tabela de roteamento, etc.) (software) | |||
** Data plane encaminha de fato os dados (hardware) | |||
*A abstração da lógica da rede de implementação de hardware em software. | |||
* A presença de um controlador de rede que coordena as decisões de encaminhamento de dispositivos de rede. <br> | |||
<br> | |||
<center>[[Arquivo:Sdn_vs.png]]</center><br> | |||
<br> | |||
<br> | |||
Além de questões da própria tecnologia (automação, eficiência, etc.) existe também a questão de que as empresas poderiam de uma forma dinâmica efetuar tarefas sem ter muito a influência em relação ao qual vendor vai se trabalhar no futuro. | |||
Para isso, existe um protocolo no qual os fabricantes podem conversar, permitindo que a comunicação entre essas camadas fosse de comum acordo. | |||
Relacionado a esse ponto foi iniciado a menção sobre o protocolo OpenFlow, de natureza opensource, onde todas as empresas poderiam desenvolver se baseando nesse protocolo. | |||
<br> | |||
O controlador mantém uma visão global do estado da rede, incluindo topologia de rede, carga de tráfego e falhas de link, e pode aproveitar essas informações para selecionar dinamicamente os caminhos de roteamento para cada fluxo da rede. | |||
Essa é uma abordagem diferente dos protocolos IP tradicionais, como OSPF, que direciona o tráfego ao longo do caminho mais curto usando certas métricas (link state). | |||
O SDN, portanto, além de facilitar o gerenciamento de redes que envolvem diferentes fornecedores, capacita mecanismos de tráfego que podem então responder em tempo real às mudanças na rede e oferecer suporte preciso com relação às decisões de roteamento. | |||
E, mesmo em redes SDN híbridas, os ISPs podem ter benefícios importantes. Ou seja, para o tráfego que atravessar pelo menos um nó SDN, será possível aplicar políticas sofisticadas envolvendo controle de acesso, ações de firewall, etc. | |||
<br> | |||
<center>''Sobre a aplicação de SDN em ISPs':''</center> | |||
A capacidade do Software Defined Networking (SDN) de ajustar dinamicamente o comportamento da rede e oferecer suporte a políticas de roteamento aprimoradas torna-se cada vez mais atraente, além dos Data Centers, onde SDN já ganhou enorme impulso. | |||
No entanto, a adoção mais ampla de SDN em redes ISP (Internet Service Provider) ainda é incerta devido a preocupações sobre a escalabilidade de um gerenciamento de tráfego centralizado em ambientes de grande escala. | |||
<br> | |||
Um dos principais desafios em redes SDN é manter um padrão próximo do roteamento ideal com uma reconfiguração razoável a sobrecarga. As reconfigurações não podem ser aplicadas a todos os SDN ao mesmo tempo. Assim, um congestionamento pode ocorrer durante a atualização de roteamento se o link designado para transportar um determinado trafego depois da atualização é atualizado antes do tráfego que deveria sair ter saído de fato. | |||
<br> | |||
<br> | |||
Por várias razões, reduzir as reconfigurações de roteamento são de particular importância para redes ISP. | |||
Primeiro, as redes ISP são tipicamente caracterizadas por grandes topologias que envolvem links de longa distância. | |||
Portanto, o problema de atualizações de roteamento não sincronizadas é nítido, especialmente em redes controladas centralmente, onde há um fator adicional da longa distância do switch para o controlador. Em segundo lugar, o tráfego é muito variável e difícil de estimar, enquanto as falhas ocorrem com frequência. | |||
Para lidar de forma eficiente com as variações repentinas do tráfego, o controlador tem que recalcular continuamente o roteamento. | |||
Por outro lado, esse é um requisito conflitante, uma vez que mudanças de caminho podem causar interrupções no serviço. | |||
Embora isso aconteça nos data centers, os ISPs são mais afetados devido ao aumento da pressão para fornecer um bom desempenho de QoS (quality of service - qualidade de serviço). | |||
<br> | <br> | ||
== Características e considerações da pesquisa == | |||
<br> | <br> | ||
SDN, portanto, vai fazer tudo através de software. | |||
Com o harware que temos hoje na rede da Algar Telecom é possível de utiliza-los para aplicações SDN, desde que eles tenham suporte à configurações realizadas à partir do controller, ou seja, desde que o hardware seja SDN Ready. <br> | |||
<br> | |||
<br> | |||
Se não tivéssemos 100% dos harwares compatíveis, só de ter alguns em alguns pontos importantes (onde tem mais fluxo, etc.) já proporcionaria uma melhora na rede, pois ali ele conseguiria ter um melhor controle, etc. Como segue na imagem abaixo: | |||
<center>[[Arquivo:Sdnhyb.png]]</center> | |||
<br> | A implementação de SDN na rede da Algar Telecom deverá ser feita de forma gradual, primeiro realizando experimentações onde o SDN já é forte: data centers, para depois ir expandido para a rede backbone da Algar Telecom. Como citado anteriormente, é importante ter a clareza de: onde começar implementando e quando implementar. | ||
Considerações para expandir SDN para a rede de telecomunicações: | |||
<br> | |||
<br> | |||
Quando se fala em OPEN, não necessariamente significa que é gratuito, portanto provavelmente haverá um custo por esta estrutura. | |||
O OpenFlow é o protocolo que suporta a plataforma, mas quem de fato é esta plataforma (controlador)? | |||
Vejamos: hoje temos um switch onde tem o software rodando, que por sua vez tem o control plane e data plane. | |||
Agora quero fazer o control plane ser trazido pro controlador. Como o fabricante do software não quer abrir a sua solução para que qualquer um mexa,( que envolve as particularidades da solução, interação do software com o harware, etc. ) muitas vezes o controlador também é do próprio fabricante. | |||
Portanto, de certa forma aguarda-se uma solução de SDN para ISPs, contudo, há a possibilidade de busca por soluções envolvendo open networking. | |||
O foco, portando, no momento, será de estudo em Open Networking. | |||
== Estudo Dirigido == | == Estudo Dirigido == | ||
| Linha 40: | Linha 95: | ||
<br> | <br> | ||
*Artigos: | |||
**One Step at a Time: Optimizing SDN Upgrades in ISP Networks | |||
**Optimizing Gradual SDN Upgrades in ISP Networks | |||
**Toward a Scalable, Robust, and QoS-Aware Virtual-Link Provisioning in SDN-Based ISP Networks | |||
*Sites: | |||
**[https://www.youtube.com/watch?v=RdCLmakGZL0&ab_channel=KevinWallaceTraining%2CLLC] | |||
**[https://www.forfusion.com/insights/guides/the-definitive-guide-to-software-defined-networking] | |||
**[https://www.ibm.com/services/network/sdn-versus-traditional-networking] | |||
**[http://www.inf.ufrgs.br/~granville/wp-content/papercite-data/pdf/07010546.pdf] | |||
**[https://www.ic.unicamp.br/~edmundo/MC822/mc822/MO655/Introdu%C3%A7%C3%A3o%20a%20SDN%20e%20OpenFlow.pdf] | |||
**[https://intelrendz.wordpress.com/2014/08/24/adaptation-of-software-defined-networking-sdn-by-internet-service-providers-isp/] | |||
<br> | <br> | ||
= Fase II - Ensino = | = Fase II - Ensino = | ||
| Linha 50: | Linha 115: | ||
== Conteúdo == | == Conteúdo == | ||
*Resumo: | |||
**[[Arquivo:Resumosdn.pdf]] | |||
<br> | |||
<br> | |||
== Apresentação == | == Apresentação == | ||
Edição atual tal como às 16h36min de 16 de novembro de 2021
Fase I - Estudo
Título da Idéia
SDN Controller: o que é, onde está implementado e situação em relação à redes de telecomunicações
Objetivos
- Avaliar o que se pode fazer com SDN
- Avaliar as condições de implementação para redes de telecomunicações
- Realizar considerações sobre a viabilidade da solução
- Avaliar a possibilidade de estudo de SDN com a estrutura de Data Center.
Conceito
Se pensarmos hoje, as redes tradicionais funcionam com base na informação por salto, ou seja, conforme o tráfego é recebido em cada um desses dispositivos - ele sozinho decide para onde enviá-lo, com base nas informações que recebe do resto da rede.
Quando temos uma quantidade enorme de dispositivos para configurar, a automação é muito difícil, não confiável e cara.
Dito isto, o SDN elimina a necessidade de gerenciar cada switch, roteador, firewall ou ponto de acesso individual.
Se for necessário introduzir um novo serviço, por exemplo, a nova configuração só precisa ser concluída no controlador centralizado, que irá direcionar a rede de acordo com a configuração centralizada. Essa configuração centralizada é categorizada como uma política.
O SDN propõe:
- Uma separação clara do data plane (forwarding) e control plane.
- Control plane define como os dados serão encaminhados (criação de tabela de roteamento, etc.) (software)
- Data plane encaminha de fato os dados (hardware)
- A abstração da lógica da rede de implementação de hardware em software.
- A presença de um controlador de rede que coordena as decisões de encaminhamento de dispositivos de rede.

Além de questões da própria tecnologia (automação, eficiência, etc.) existe também a questão de que as empresas poderiam de uma forma dinâmica efetuar tarefas sem ter muito a influência em relação ao qual vendor vai se trabalhar no futuro.
Para isso, existe um protocolo no qual os fabricantes podem conversar, permitindo que a comunicação entre essas camadas fosse de comum acordo.
Relacionado a esse ponto foi iniciado a menção sobre o protocolo OpenFlow, de natureza opensource, onde todas as empresas poderiam desenvolver se baseando nesse protocolo.
O controlador mantém uma visão global do estado da rede, incluindo topologia de rede, carga de tráfego e falhas de link, e pode aproveitar essas informações para selecionar dinamicamente os caminhos de roteamento para cada fluxo da rede.
Essa é uma abordagem diferente dos protocolos IP tradicionais, como OSPF, que direciona o tráfego ao longo do caminho mais curto usando certas métricas (link state).
O SDN, portanto, além de facilitar o gerenciamento de redes que envolvem diferentes fornecedores, capacita mecanismos de tráfego que podem então responder em tempo real às mudanças na rede e oferecer suporte preciso com relação às decisões de roteamento.
E, mesmo em redes SDN híbridas, os ISPs podem ter benefícios importantes. Ou seja, para o tráfego que atravessar pelo menos um nó SDN, será possível aplicar políticas sofisticadas envolvendo controle de acesso, ações de firewall, etc.
A capacidade do Software Defined Networking (SDN) de ajustar dinamicamente o comportamento da rede e oferecer suporte a políticas de roteamento aprimoradas torna-se cada vez mais atraente, além dos Data Centers, onde SDN já ganhou enorme impulso.
No entanto, a adoção mais ampla de SDN em redes ISP (Internet Service Provider) ainda é incerta devido a preocupações sobre a escalabilidade de um gerenciamento de tráfego centralizado em ambientes de grande escala.
Um dos principais desafios em redes SDN é manter um padrão próximo do roteamento ideal com uma reconfiguração razoável a sobrecarga. As reconfigurações não podem ser aplicadas a todos os SDN ao mesmo tempo. Assim, um congestionamento pode ocorrer durante a atualização de roteamento se o link designado para transportar um determinado trafego depois da atualização é atualizado antes do tráfego que deveria sair ter saído de fato.
Por várias razões, reduzir as reconfigurações de roteamento são de particular importância para redes ISP.
Primeiro, as redes ISP são tipicamente caracterizadas por grandes topologias que envolvem links de longa distância.
Portanto, o problema de atualizações de roteamento não sincronizadas é nítido, especialmente em redes controladas centralmente, onde há um fator adicional da longa distância do switch para o controlador. Em segundo lugar, o tráfego é muito variável e difícil de estimar, enquanto as falhas ocorrem com frequência.
Para lidar de forma eficiente com as variações repentinas do tráfego, o controlador tem que recalcular continuamente o roteamento.
Por outro lado, esse é um requisito conflitante, uma vez que mudanças de caminho podem causar interrupções no serviço.
Embora isso aconteça nos data centers, os ISPs são mais afetados devido ao aumento da pressão para fornecer um bom desempenho de QoS (quality of service - qualidade de serviço).
Características e considerações da pesquisa
SDN, portanto, vai fazer tudo através de software.
Com o harware que temos hoje na rede da Algar Telecom é possível de utiliza-los para aplicações SDN, desde que eles tenham suporte à configurações realizadas à partir do controller, ou seja, desde que o hardware seja SDN Ready.
Se não tivéssemos 100% dos harwares compatíveis, só de ter alguns em alguns pontos importantes (onde tem mais fluxo, etc.) já proporcionaria uma melhora na rede, pois ali ele conseguiria ter um melhor controle, etc. Como segue na imagem abaixo:

A implementação de SDN na rede da Algar Telecom deverá ser feita de forma gradual, primeiro realizando experimentações onde o SDN já é forte: data centers, para depois ir expandido para a rede backbone da Algar Telecom. Como citado anteriormente, é importante ter a clareza de: onde começar implementando e quando implementar.
Considerações para expandir SDN para a rede de telecomunicações:
Quando se fala em OPEN, não necessariamente significa que é gratuito, portanto provavelmente haverá um custo por esta estrutura.
O OpenFlow é o protocolo que suporta a plataforma, mas quem de fato é esta plataforma (controlador)?
Vejamos: hoje temos um switch onde tem o software rodando, que por sua vez tem o control plane e data plane.
Agora quero fazer o control plane ser trazido pro controlador. Como o fabricante do software não quer abrir a sua solução para que qualquer um mexa,( que envolve as particularidades da solução, interação do software com o harware, etc. ) muitas vezes o controlador também é do próprio fabricante.
Portanto, de certa forma aguarda-se uma solução de SDN para ISPs, contudo, há a possibilidade de busca por soluções envolvendo open networking.
O foco, portando, no momento, será de estudo em Open Networking.
Estudo Dirigido
- Artigos:
- One Step at a Time: Optimizing SDN Upgrades in ISP Networks
- Optimizing Gradual SDN Upgrades in ISP Networks
- Toward a Scalable, Robust, and QoS-Aware Virtual-Link Provisioning in SDN-Based ISP Networks
- Sites:
Fase II - Ensino
Conteúdo
- Resumo:
Apresentação
Apresente ao grupo (reunião, EAD, Blog, ...) Publique aqui
Metodologia
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
Fase III - Exemplo de Caso de Negócio
Product Backlog
Descreva os requisitos deste projeto
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
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.
Direcionadores chave para esta iniciativa
Descrever em tópicos o que esta iniciativa pode proporcionar
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
Alinhamento com Lei do Bem
- 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
- 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
- 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
- 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
Fase IV - Protótipo orientado ao Negócio
Escopo
Explique o escopo deste protótipo
Limitações
Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.
PoC
Desenvolva um PoC (Proof of Concept)
Privacidade (LGPD)
- Avaliar condições referentes à Lei Geral de Proteção de Dados
Detalhamento Técnico
Descreva especificamente os aspectos técnicos desta pesquisa
Cronograma Macro
Histórico
Responsável: fulano
Semana de dd à dd/mm/yyyy
Semana de dd à dd/mm/yyyy