Escolar Documentos
Profissional Documentos
Cultura Documentos
Apresentação
Nesta aula, veremos uma Rede De nida por Software, também referenciada como SDN (Sofwtare De ned Network), além
de seus componentes e, em principal, o paradigma SDN que está relacionado ao plano de controle e plano de dados.
Objetivos
Distinguir encaminhamento e roteamento;
Fonte: Shutterstock
Premissa
Na Aula 1, apresentamos o paradigma de Redes De nidas por Software. Aqui, explicaremos o funcionamento de uma
SDN. Antes, porém, devemos diferenciar bem alguns termos e conceitos para facilitar o entendimento. Assim sendo,
faremos uma breve revisão para reforçar aspectos contidos na Camada de Rede (do modelo de camadas OSI – Open
Systems Interconnection).
Paradigma SDN
Na SDN, o plano de controle é centralizado (e realizado pelo controlador), ao passo que o plano de dados permanece nos
dispositivos. Como ressalva, podemos ter também um plano de controle descentralizado, ou seja, mais de um controlador
realizando as ações de controle. No entanto, o que desejamos enfatizar agora é que na SDN os planos de dados e os de
controle estão em dispositivos diferentes, não importando a quantidade de elementos que desempenham a atividade.
Como podemos ver na gura acima, as funções de plano de controle e plano de dados estão sendo realizadas pelo switch,
enquanto na arquitetura SDN (à direita) a função de controle foi deslocada dos switches para outro elemento centralizador.
Este, embora não esteja indicado na gura, é o controlador da rede SDN, ou seja, uma espécie de “cérebro” da rede e
elemento principal da arquitetura.
Perceba a diferença entre as arquiteturas e onde estão ou atuam o plano de controle e o plano de dados.
Southbound (em uma tradução literal, “em direção ao sul”, em analogia a Northbound, “em direção ao norte”) é
algo que atua no sentido para o sul, do controlador para a infraestrutura, do controlador para os dispositivos. Ou
seja, Southbound e Northboud são as partes da arquitetura que tratam da comunicação entre controlador e
infraestrutura e controlador e aplicações, respectivamente.
Na forma de atuação, temos o signi cado de API (do inglês, Application Programming Interface; em português,
Interface de Programação de Aplicações). Podemos ver a API como uma forma de “ponte” capaz de conectar
sistemas diferentes, possibilitando benefícios na facilidade de troca de informações.
As APIs proporcionam a integração entre sistemas que podem possuir linguagem de programação totalmente
distinta, de maneira ágil e segura. Por exemplo, Google Maps e uma página de hotéis em que a localização
aparece no mapa. O Google Maps possui uma API que facilita a integração do seu serviço com algum aplicativo.
Para isso, basta seguir as orientações de como a API recebe e devolve solicitações, a m de que seu
funcionamento seja implementado corretamente na aplicação desenvolvida. Podemos também dizer Southbond
API ou Nortbound API, especi cando diretamente a API em questão.
A Southbound API facilita o controle e ciente da rede e permite que o controlador SDN faça dinamicamente
alterações, em tempo real, de acordo com as demandas e necessidades. O OpenFlow, desenvolvido pela Open
Networking Foundation (ONF), foi a primeira e provavelmente mais conhecida southbound interface (HU et al.,
2014). Além do OpenFlow, o Cisco OpFlex (a resposta da empresa ao OpenFlow) também é uma southbound API
bem-conhecida (HU et al., 2014).
Da mesma forma que temos a Southboubd API, temos a Northbound API, que está relacionada à interação entre
controlador e aplicações, conforme ilustra a gura abaixo:
Existem diversos controladores para o paradigma SDN. A maneira de como desenvolver aplicações SDN depende
muito da linguagem de programação em que o controlador foi desenvolvido, bem como sua arquitetura e
complexidade. Existem vários controladores disponíveis, como POX, NOX, Beacon e Floodlight, cada um com
suas particularidades (LINS, 2015).
Em resumo, a Northbound é a interface entre as aplicações e os controladores, a qual oferece visão abstrata da
rede e recebe diretamente desta as informações de comportamento e requisitos. A Northbound é implementada
de forma aberta, independente de fornecedor e com interoperabilidade.
A Southbound é a interface de nida entre um controlador e a infraestrutura, ou seja, um dispositivo SDN. Por meio
de uma linguagem como o Open ow, a API fornece o controle programático de todas as operações, capacidade
de noti cação, estatísticas de relatórios (LINS, 2015). Assim como a Northbound, a Southbound é implementada
de forma aberta, independente de fornecedor e com interoperabilidade.
Além disso, redes tradicionais são mais complexas e difíceis de se gerenciarem, pois, devido à sua arquitetura
convencional, elas necessitam que os operadores con gurem separadamente cada dispositivo de rede. No
entanto, essa tarefa torna-se difícil e suscetível a erros, porque os comandos de con gurações nos equipamentos
são de baixo nível e especí cos para cada fabricante. Por exemplo, não é possível con gurar da mesma forma um
equipamento Cisco e um equipamento Juniper.
Outra característica é que con gurações realizadas nos equipamentos não se adaptam conforme as condições
da rede. Redes tradicionais não se adaptam facilmente a mudanças de carga e falhas na rede. Isso acontece
devido à di culdade de realizar engenharia de tráfego, no uxo de mensagens recebido. Além disso, mudanças no
plano de controle são difíceis de se implementarem, pois, como as redes são integradas verticalmente, acaba
sendo necessário mudar o software de cada dispositivo de rede. Caso se deseje implementar ou incluir, por
exemplo, um novo protocolo de roteamento diferente, devido ao sistema operacional do dispositivo em questão,
essa tarefa acaba sendo di cultada.
Como característica geral, nas redes tradicionais temos muitos tipos de dispositivos de rede que coexistem:
Diferentes dispositivos e serviços. Fonte: Couto (2018).
Todas as aplicações podem utilizar a mesma informação provida pelo plano de controle;
Integração de diferentes aplicações pode ser mais fácil. Ex.: balanceamento de carga e
roteamento.
Para explicarmos o funcionamento do que cada plano faz, e o impacto causado por eles estarem separados, devemos
voltar um pouco e relembrar uma distinção importante entre as funções de repasse (ou encaminhamento) e roteamento
da Camada de Rede.
Logo,
Clique nos botões para ver as informações.
Encaminhamento
Quando um pacote (um dado) chega a uma porta de um roteador, o roteador deve movê-lo para uma porta de saída
apropriada. Por exemplo, na gura abaixo, ao chegar um pacote (mensagem), o dispositivo extrai a informação
relacionada ao endereço de destino, no caso (0111), consulta a tabela de encaminhamento e, a partir disso, veri ca
que para esse destino a porta de saída deve ser a 2. O encaminhamento é uma função implementada no plano de
dados.
Roteamento
A camada de Rede deve determinar a rota ou o caminho que será tomado pelos pacotes ao uírem de um emissor
para um receptor. Os algoritmos que calculam este caminho são chamados de algoritmos de roteamento. O
roteamento é implementado no plano de controle da Camada de Rede.
Roteamento e Encaminhamento
Clique no botão acima.
Roteamento e Encaminhamento
Os termos roteamento e encaminhamento muitas vezes são tratados por diversos autores como similares. No
entanto, apesar de serem próximos, devemos ter em mente sua diferença. Para deixarmos mais clara essa
distinção, podemos recorrer à seguinte analogia apresentada por Kurose (2017): consideramos um motorista que
está preparando uma viagem entre duas cidades, digamos cidade A e cidade B, na qual entre ambas temos
diversas ruas e cruzamentos. Podemos imaginar que encaminhamento é o processo de, ao estar em um
cruzamento, o motorista do carro deve determinar por qual rua ele deve deixar este cruzamento, enquanto
roteamento é o procedimento de planejamento da viagem desde A até B. O roteamento pode ser análogo a uma
consulta prévia do motorista a um mapa, e a seleção de uma rota dentre as muitas possíveis, antes de iniciar a
viagem.
Claramente o encaminhamento depende do roteamento, pois, de acordo com a rota estabelecida, ou seja, o
roteamento, o motorista seleciona a rua (direita, esquerda ou em frente) apropriada ao deixar um cruzamento.
Nessa analogia, as ruas podem ser vistas como possíveis portas do roteador, e o encaminhamento deve estar de
acordo com o caminho já estipulado (rota).
O elemento-chave é como o roteador sabe a qual porta ele deve encaminhar um pacote quando este chega ao
equipamento. Para isso, o roteador consulta a tabela de encaminhamento. Mais especi camente o roteador
examina um dos campos do cabeçalho do pacote – nesse caso, o endereço de destino desse pacote, e esse valor
é um índice na tabela de encaminhamento. Por exemplo, examinamos o pacote e temos o campo do cabeçalho
para endereço de destino o valor 0111. Esse campo terá uma linha equivalente na tabela de encaminhamento
relacionando este endereço a uma porta de saída do equipamento.
Outra diferença que temos entre roteamento e encaminhamento é a escala de tempo em que cada uma ocorre. O
roteamento leva muito mais tempo, na ordem de segundos, sendo frequentemente implementado via software. Já
o encaminhamento é bem mais rápido que o roteamento, na ordem de nanossegundos, sendo tipicamente
implementado em hardware.
Uma questão crucial é como que as tabelas de encaminhamento de um roteador são con guradas; isso expõe
uma importante interação entre o encaminhamento (no plano de dados) e o roteamento (no plano de controle).
Conforme a gura a seguir, o algoritmo de roteamento determina o conteúdo das tabelas de encaminhamento
dos roteadores. Nesse exemplo, um algoritmo de roteamento é executado em cada roteador, e as funções de
encaminhamento e roteamento estão contidas em um roteador. O algoritmo de roteamento de um roteador se
comunica com o algoritmo de roteamento de outro roteador para computar os valores de sua tabela de
encaminhamento. As formas com que essa comunicação ocorre, ou qual o conteúdo das mensagens trocadas
entre os roteadores, depende do tipo de algoritmo de roteamento utilizado.
Algoritmo de roteamento e valores na tabela de encaminhamento. Fonte: Kurose (2017).
A abordagem para implementar a funcionalidade de roteamento com cada roteador tendo um componente de
roteamento que se comunica com o componente de roteamento de outros roteadores, tem sido a abordagem
tradicional adotada pelos fabricantes em seus produtos, pelo menos até recentemente. A gura a seguir, mostra
uma abordagem alternativa na qual um controlador remoto sicamente separado dos roteadores calcula e
distribui as tabelas de encaminhamento a serem usadas por cada um dos roteadores. Observe que os
componentes do plano de dados em ambas as guras são idênticos.
A abordagem de plano de controle está no centro da Rede De nida por Software, em que a rede é "de nida por software"
porque o controlador é quem calcula as tabelas de encaminhamento e interage com os roteadores, sendo implementado
em software.
Logo, em SDN o plano de dados é separado do plano de controle, diferentemente da arquitetura de redes tradicional, em
que cada dispositivo possui o plano de dados e o plano de controle. Na SDN o plano de controle é remoto, e o plano de
dados permanece no dispositivo.
O plano de controle é o responsável pelo roteamento dos pacotes, ou seja, por qual rota os pacotes irão seguir, pela
montagem da tabela de encaminhamento; já o plano de dados é o responsável pelo encaminhamento de pacotes com
base em regras simples, associadas a cada entrada da tabela de encaminhamento do dispositivo. Alguns exemplos de
regras serão apresentados a seguir na seção Regras de casamento.
Regras de Casamento
Um dos pontos principais do funcionamento de SDNs é sua exibilidade, a qual está relacionada à forma como suas
decisões de encaminhamento operam.
Sabemos que a decisão de encaminhamento de um roteador de Internet tem sido tradicionalmente baseada apenas no
endereço de destino de um pacote, conforme exempli cado na Figura 3.7. O roteador consulta o cabeçalho do pacote de
destino e, a partir dele, extrai a informação de qual porta deve ser encaminhado o pacote para este prosseguir na rota
calculada.
Em SDN, as decisões de encaminhamento são baseadas em uxos, em vez de simplesmente o endereço de destino do
pacote. Fluxo é um conjunto de campos de um pacote atuando como critério de classi cação e um conjunto de ações a
ele associadas.
Na infraestrutura de rede SDN, o conjunto de equipamentos de rede são simples elementos de encaminhamento, os quais
não tomam decisões autônomas. Suas decisões são programadas pelo controlador e realizadas por meio de tabelas de
uxos ( owtables), que especi cam o comportamento para cada uxo. A de nição de uxo depende dos campos do
pacote.
Cada roteador contém uma tabela de uxo que é computada e distribuída por um controlador de roteamento logicamente
centralizado.
Conforme falamos, uxo é de nido pelos campos do cabeçalho, ou seja, é o conjunto de campos de um pacote (que agem
como critério de classi cação) e o conjunto de ações associadas.
Regras e ações OpenFlow. Fonte: Eisencraft.
Ao receber um uxo de mensagem, seus campos são analisados, e veri ca-se a existência de alguma regra de casamento.
Por exemplo, bloquear todos os pacotes endereçados à porta 81.
Fonte: Shutterstock
Conclusão
Nesta aula, apresentamos a de nição de SDN em mais detalhes e revisamos conceitos da Camada de Redes, como
roteamento e encaminhamento. Apresentamos as diferenças entre plano de controle e plano de dados, bem como as
vantagens de estarem separados na arquitetura SDN. Além disso, exempli camos como o encaminhamento de uxos
ocorre em SDNs.
Atividade
1. O que é a quebra da integração vertical?
CAMPOS, R. F. C. de. Balanceador de carga tolerante a faltas bizantinas. 2013. Dissertação (Mestrado em Segurança
Informática), Universidade de Lisboa. Faculdade de Ciências.
Notas
COUTO, R. S. Tópicos Especiais em Redes de Telecomunicações. Notas de aula. Disponível em:
//www.lee.uerj.br/~rodrigo/sdnpel. Acesso em: abril 2019.
EISENCRAFT, Marcio. Redes de Comunicação: aula 20. Notas de aula. Disponível em:
https://edisciplinas.usp.br/plugin le.php/3509205/mod_resource/content/0/PTC3450 – 201701- Aula20.pdf. Acesso em: abril
2019.
HU, F. et al. Network Innovation through OpenFlow and SDN: principles and design. CRC Press, 2014.
KREUTZ, D.; RAMOS, F. M. V.; VERÍSSIMO, P.; ROTHENBERG, C. E.; AZODOLMOLKY, S.; UHLIG, S. Software-De ned Networking:
a comprehensive survey. Proceedings of the IEEE, 2015.
KUROSE, J.; ROSS, K. Computer Networking: a top down approach. 7th. ed. 2017.
LINS, T. Redes De nidas por Software (Software De ned Networks) SDN. [Online]. Disponível em:
//www.decom.ufop.br/imobilis/redes-de nidas-por-software-software-de ned-networks-sdn/. Laboratório Imobilis Computação
Móvel. Acesso em: março, 2019.
PINHÃO, G. L. L.; GAMA, L. V.; COSTA, R.E.S. Trabalho da disciplina de Redes de Computadores I – UFRJ (2018.1). [Online].
Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2018-1/trabalhos-vf/sdn/. Acesso em: abril, 2019.
WIKIPEDIA – Middleboxes. Disponível em: https://en.wikipedia.org/wiki/Middlebox. Acesso em: abril 2019.
Próxima aula
Explore mais
Assista ao vídeo:
OBS.: O vídeo está em língua inglesa. Para facilitar o entendimento, ative a legenda ao acessá-lo.