Aula 05 - Funcionamento do Openflow, seus Componentes e versoes

Prévia do material em texto

Redes De�nidas por Software
Aula 05: Funcionamento do Open�ow, seus Componentes e
Versões
Apresentação
O OpenFlow é um padrão/protocolo voltado para redes SDNs. Existem diversas versões do OpenFlow, às quais novas
funcionalidades vão sendo inseridas. Sua �nalidade é proporcionar uma forma de os pesquisadores executarem
protocolos experimentais em redes SDN.
Na unidade anterior, vimos alguns controladores SDNs. Nesta, veremos como os controladores atuam nos dispositivos
por meio do OpenFlow.
Assim, conheceremos seu funcionamento baseado em um switch Ethernet, com uma tabela de �uxo interna, e uma
interface padronizada para interagir adicionando e removendo entradas de �uxo.
Objetivos
Identi�car os principais componentes de um computador OpenFlow;
Listar possíveis exemplos de regras e ações realizadas pelo OpenFlow.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Fonte: blog.pantuza.com
javascript:void(0);
Após apresentarmos o conceito das SDNs, Kleis (2015) aponta as seguintes dúvidas mais comuns:
 Padrão/Protocolo OpenFlow
O padrão/protocolo OpenFlow é a implementação mais difundida para Redes De�nidas por Software (SDNs; do inglês,
Software De�ned Networking) que encontramos. Ele foi criado originalmente na Universidade de Stanford, como código
aberto (ou seja, diferentes fabricantes podem implementá-lo em seus switches). Ele surgiu inicialmente da necessidade de
se executarem protocolos, ou ideias, experimentais na rede acadêmica (rede de universidades). Isso porque, conforme
apresentado na Unidade 1, uma das vantagens da SDN é a possibilidade de facilitar o teste de novos protocolos na rede,
de maneira rápida e sem grandes alterações, pois sua ideia se apoia no fato de se separar o tráfego de produção do
tráfego experimental.
Saiba mais
Além do meio acadêmico, com o tempo a indústria também passou a adotar o OpenFlow/SDN como forma de aumento da
funcionalidade da rede, pois apresenta uma redução de custo e complexidade de hardware exigida.
Como ocorre a comunicação entre o
controlador e os dispositivos?
Quais con�gurações um dispositivo de
rede deve oferecer?
Qual é o formato das mensagens
enviadas pelo controlador?
A peça fundamental da SDN que responde a essas questões é o protocolo OpenFlow, que, como o nome já diz, consiste
em um conjunto de regras e padrões.
O OpenFlow foi proposto para padronizar a comunicação entre os switches e o controlador baseado em software em uma
arquitetura SDN. Os autores identi�caram que é difícil para a comunidade de pesquisa em rede testar novas ideias em
hardware. Isso acontece porque o código-fonte do software em execução nos switches não pode ser modi�cado; portanto,
a infraestrutura de rede �cou “ossi�cada” (MCKEOWN et al., 2008), pois novas ideias de rede não podem ser testadas em
con�gurações de tráfego realistas.
Ao identi�carem recursos comuns nas tabelas de �uxo dos switches Ethernet, os autores fornecem um protocolo
padronizado para controlar a tabela de �uxo de um switch por meio de software. O OpenFlow viabiliza um meio de
controlar um switch sem exigir que os fornecedores exponham o código de seus dispositivos. A partir disso, diversas
versões do OpenFlow já foram e continuam sendo desenvolvidas, cada uma agregando uma nova feature (característica),
vista como necessária para tratar ou facilitar determinado problema.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Versões do OpenFlow
 Clique no botão acima.
Versões do OpenFlow
A seguir, apresentaremos um histórico das versões do OpenFlow:
Versão 0.2.0 – 2008;
Versão 1.0.0 – 2009;
Versão 1.1.0 – 2011;
Versão 1.2 – 2011;
Versão 1.3.0 – 2012;
Versão 1.4.0 – 2013;
Versão 1.5.0 – 2014;
Versão 1.5.1 – 2015;
Versão 1.6 – 2016 (acessível apenas para membros da Open Network Foundation – ONF).
A primeira versão do OpenFlow (0.2.0) atualmente está obsoleta. A mais utilizada quando aprendemos OpenFlow,
ou somos apresentados a ele, é a 1.0.0, justamente porque foi a mais divulgada e implementada. Esta é que será
levada em consideração nas próximas seções ao demonstrarmos conceitos básicos do protocolo, quando não
informarmos de qual versão se trata.
 
ATENÇÃO:
Devido à variedade de versões, deve-se consultar as especi�cações do equipamento para ver qual ou quais
versões ele suporta. Muitos equipamentos suportam até determinada versão do OpenFlow (p. ex., 1.0.0) e não
adianta tentar rodar uma superior (como 1.3.0). Ou seja, não basta que o equipamento “entenda” OpenFlow, deve-
se veri�car qual versão o equipamento suporta.
 
O OpenFlow encontra-se em constante evolução e é mantido pela Open Network Foundation (ONF). Na verdade,
dentro da ONF o Extensibility WG (Working Group) é responsável por manter e modi�car o OpenFlow. O trabalho
realizado no Extensibility WG é de primordial importância se concretizar a promessa da SDN de introdução mais
rápida de inovações de rede.
O processo no WG para cada proposta contém quatro fases:
1. apresentação da proposta inicial;
2. incubação;
3. prototipagem; e
4. uma revisão �nal feita pela ONF.
Durante a fase de apresentação da proposta, um estudo de caso é apresentado ao lado de um conjunto de
soluções técnicas. A fase de incubação se dá quando o texto da especi�cação real da proposta é escrito, revisado
e aprovado. Um protótipo de código aberto da proposta é implementado, revisado e aprovado durante a fase de
prototipagem. Todas as aprovações são feitas durante uma das teleconferências semanais, por consenso
aproximado (o qual é alcançado após cada opinião ter sido expressa e discutida), e há uma ausência de grandes
objeções (TOURRILHES et al., 2014). O estudo de casos para SDN é a força motriz por trás da evolução do
OpenFlow, e o número desses estudos baseados no OpenFlow tem crescido com o passar dos anos.
Um objetivo da ONF em utilizar essa abordagem é promover implementações no mercado. O forte ecossistema
de código aberto construído em torno da versão 1.0 do OpenFlow é uma das razões de seu sucesso e
longevidade. Ao formar o Extensibility WG, uma das �nalidades era reduzir a lacuna entre a comunidade de código
aberto fora da ONF, os fornecedores e o processo de especi�cação. O Extensibility WG convidou diversos
desenvolvedores para o processo de especi�cação e de�niu muitos recursos experimentais de implementações
de código aberto ou de fornecedores em versões mais novas do OpenFlow. O processo de especi�cação também
foi alterado para exigir prototipação de código aberto de novos recursos, a �m de que a comunidade
experimentasse a implementação de novos recursos antes que a padronização fosse concluída (TOURRILHES et
al., 2014).
Você, porém, pode estar se perguntando: “O que muda de uma versão para outra?” ou “Por que há tantas
versões?”.
Na verdade, isso está relacionado aos estudos de casos de que falamos anteriormente. Todos eles utilizam o
OpenFlow para atender aos seus requisitos. Dessa forma, seria possível desenvolver uma solução pontual para
cada um deles, abordando apenas um estudo de caso especí�co. Tal abordagem levaria a uma proliferação de
protocolos especializados, um para cada estudo de caso, e a uma proliferação de interfaces para con�gurar esses
protocolos.
O intuito, porém, é que se consiga abordar um grande conjunto de estudo de casos e políticas com o mínimo de
duplicação de esforços, utilizando-se uma estrutura genérica e de�nida com base nos elementos comuns aos
estudos de casos tratados. Daí a grande quantidade de versões existentes.
No Quadro 5.1, consideramos alguns elementos da estrutura do SDN, em que se diferenciam as versões do
OpenFlow até a versão 1.5, conforme apontam Tourrilhes et al. (2014).
Quadro 5.1 Elementos SDN e Mudanças na Especi�cação do OpenFlow Relacionadas a Eles
Elemento
SDN Melhorias na Especificação do Switch OpenFlow
Versão do
OpenFlow
Centralização
lógica
Mecanismo de seleção de função (multicontrolador)
Filtragem de eventos (multicontrolador)
Monitoramento de �uxo (multicontrolador)1.2
1.3
1.4
Northbound API Filas de prioridade por porta – por aplicação QoS
Por medidor de vazão – por aplicação QoS
Campo de ID de túnel – suporte para sobreposição em portas lógicas
1.0
1.3
1.3
Programabilidade Grupos – eles estão reutilizando ações de �uxo
Campos extensíveis comuns aos cabeçalhos de correspondência e
reescrita
Recursos da tabela (expressão de capacidade)
1.1
1.2
1.3
Um plano de controle logicamente centralizado é um desvio dos protocolos de rede tradicionais que são
principalmente distribuídos. No entanto, a experiência mostrou que alguns problemas de engenharia de tráfego,
como QoS (KIM et al., 2010) e balanceamento de carga adaptativa (SCHLANSKER et al. 2010; CURTIS et al., 2011),
podem ser mais bem-resolvidos com uma visão global da rede e de suas políticas. Muitos outros aspectos da
rede também podem bene�ciar-se da otimização global.
Essa centralização signi�ca que o controlador precisa ser capaz de controlar totalmente todos os dispositivos de
rede dentro do domínio da política. Isso também signi�ca que os dispositivos de rede devem oferecer APIs (do
inglês, Application Programming Interface, interface de programação de aplicativos) para o controlador derivar a
topologia e implementar o monitoramento e o controle de recursos de rede em vários dispositivos.
Um controlador �sicamente centralizado não é desejável do ponto de vista da con�abilidade e do desempenho.
Na maioria dos casos, o controlador precisa ter uma implementação distribuída, o que a torna mais complexa do
que ter tudo em uma única instância. No entanto, a distribuição da função de controle pode ser dissociada da
topologia de rede real, e isso permite adaptar a arquitetura de distribuição à implementação do controlador e aos
requisitos de implantação.
A centralização do plano de controle oferece uma maneira mais fácil de expor uma API da rede para aplicações
que não sejam de rede e middleware. Essa API é comumente chamada de API NorthBound, apresentada em
Unidades anteriores. Nas redes existentes, a infraestrutura de rede e os aplicativos não oferecem uma boa
maneira de trocar informações relevantes. Aplicativos e dispositivos de rede não podem comunicar-se
diretamente, por exemplo, adicionando metadados a pacotes, porque geralmente os aplicativos não são
con�áveis. A API Northbound de�ne um local central na infraestrutura em que as políticas de aplicativos globais e
as políticas de rede podem ser mediadas.
A API do NorthBound é praticamente independente do protocolo OpenFlow, já que as duas APIs estão em um nível
diferente de abstração. No entanto, todos os elementos oferecidos pela API do NorthBound precisarão ser
traduzidos para os recursos do OpenFlow, e o OpenFlow deve suportar os requisitos do aplicativo.
A estrutura SDN deve ser �exível o su�ciente para lidar com todos os tipos de dispositivos de rede, em vez de uma
API por tipo de dispositivo. Isso signi�ca lidar com dispositivos de hardware e software, dispositivos de
encaminhamento simples e dispositivos com comportamento complexo. Ter uma estrutura comum signi�ca que
os programas complexos de construir podem ser mais facilmente rede�nidos para um contexto diferente. Logo,
podem ser comuns muitos desenvolvimentos e ferramentas de gerenciamento, como as de inspeção e
depuração. A API deve ser projetada como um todo e ser consistente. Ela precisa conter o mínimo de conceitos
possível e reutilizar as mesmas técnicas e objetos. Os recursos têm de ser facilmente compostos. A API deve
permitir um feedback completo e integrar visibilidade e controle juntos, para que a programação possa realmente
ser adaptativa.
A visibilidade tem sido historicamente mais desa�adora do que o controle, mas os programas podem apenas
reagir e se adaptar às coisas que são vistas. O paradigma de programação do OpenFlow é baseado em tabelas e
ações de �uxo. Não há estruturas de processamento especializadas, e quase tudo é feito em uma tabela de �uxo
usando ações. A grande maioria das estruturas de�nidas no OpenFlow tem contadores de estatísticas para
aumentar a visibilidade.
Entradas de fluxo Várias tabelas de entradas de �uxo
Tabelas de saída – processamento de saída usando entradas de �uxo
Ação de encapsulamento usando entradas de �uxo
1.1
1.5
1.5
A API do OpenFlow precisa oferecer controle �exível e visibilidade do processamento de pacotes que é dissociado
das de�nições de protocolo. A API deve ativar o recolhimento de camadas de rede, conforme necessário. O
processamento de pacotes tem de ser ativado em qualquer granularidade desejada, tão �na ou grossa quanto
desejado e adequada para a implantação.
 Componentes de um Computador OpenFlow
Um comutador OpenFlow consiste, no mínimo, destas três partes:
Tabela de �uxos: Entre os componentes de um switch (comutador) OpenFlow, há a tabela de �uxos, que contém a
lista de ações correspondentes. Ela conta com 12 campos utilizados para a classi�cação de um �uxo, uma ação para
cada �uxo e contadores.
Canal seguro: O canal seguro está relacionado à conexão entre o switch e controlador e o próprio protocolo
OpenFlow.
Protocolo OpenFlow: O protocolo OpenFlow fornece uma via aberta e padronizada de um controlador para se
comunicar com um switch. Especi�ca-se uma interface-padrão, pela qual as entradas na tabela de �uxo podem ser
de�nidas externamente.
A Figura 5.1 ilustra esses componentes.
 Figura 5.1: Comutador OpenFlow idealizado. Fonte: Couto (2017).
A tabela de �uxos é comandada pelo controlador remoto via um canal seguro.
É útil categorizar os comutadores em switches OpenFlow dedicados, que não suportam processamento normal de
Camada 2 e Camada 3, e switches OpenFlow-enabled, que são comutadores Ethernet comerciais, de �nalidade geral,
habilitados para OpenFlow, aos quais o protocolo OpenFlow e as interfaces foram adicionados como um novo recurso.
Conforme apresenta Kleis (2015), o switch OpenFlow dedicado deve ser capaz de realizar estas três ações para os �uxos
de dados entrantes:
1. Encaminhar o �uxo de pacotes para uma porta (ou portas) especí�ca(s);
2. Encapsular e encaminhar �uxo de pacotes para o controlador;
3. Descartar o �uxo de pacotes.
A ação 1 permite que os pacotes sejam roteados pela rede. Na maioria dos switches, espera-se que isso ocorra na taxa
de dados suportada pelo equipamento.
Com a ação 2, o pacote é entregue ao canal seguro, onde é encapsulado e enviado para um controlador. É
normalmente usado para o primeiro pacote em um novo �uxo; então um controlador pode decidir se este deve ser
adicionado à tabela de �uxos. Ou, em alguns experimentos, ele poderia ser usado para encaminhar todos os pacotes para
um controlador para o processamento.
A ação 3 pode ser realizada para segurança, a �m de se reduzirem ataques de negação de serviço ou o tráfego espúrio
de hosts �nais.
Cada entrada de �uxo tem uma ação simples associada a ela.
Tabela de Fluxos
A tabela de �uxos é a parte essencial de um Switch OpenFlow. Uma entrada na tabela de �uxo possui três campos:
1. Uma regra, que de�ne no �uxo de mensagens qual campo entre os possíveis devo veri�car;
2. A ação, que de�ne como os pacotes devem ser processados; e
3. Estatísticas, que acompanham o número de pacotes e bytes para cada �uxo, bem como o tempo desde que o
último pacote correspondeu ao �uxo (para ajudar na remoção de �uxos inativos). Podemos ver a composição da
tabela de �uxos na Figura 5.2.
 Figura 5.2 Entrada da tabela de fluxos. Fonte: Couto (2017).
Os campos do cabeçalho são comparados na regra quando o �uxo de pacotes entra no switch OpenFlow. Eles serão
apresentados mais adiante. A Figura 5.3 demonstra o procedimento de recepção de �uxo de mensagens por um switch
OpenFlow.
 Figura 5.3 Procedimento de recepção e tratamento de fluxo de pacotes em um switch OpenFlow. Fonte: Couto (2017).
Segundo Scarpati (2013):
Ao �uxo de pacotes entrantes serão aplicadas as ações de acordo com a correspondência/regra (match) de campos no
cabeçalho. Conforme Figura5.4, temos internamente no switch, de forma mais detalhada:
 Figura 5.4 Procedimento de recepção e tratamento de fluxo de pacotes em um switch OpenFlow em mais detalhes. Fonte: Couto (2017).
Os switches usam a tabela de �uxos para encaminhar pacotes. Uma tabela de �uxo é uma lista de entradas de �uxo. Cada
entrada tem campos de correspondência (regra), contadores (estatísticas) e ações. Os pacotes de entrada são
comparados com os campos de correspondência (regra) de cada entrada, e, se houver uma correspondência, o pacote é
processado de acordo com a ação contida nessa entrada. Contadores são usados para manter estatísticas sobre pacotes.
O pacote também pode ser encapsulado e enviado para o controlador.
Um switch compatível com OpenFlow deve ser capaz de encaminhar pacotes de acordo com as regras de�nidas na tabela
de �uxo. A Figura 5.4 mostra uma descrição de alto nível de como um dispositivo de rede processa um pacote. As regras
da tabela de �uxo regem a comunicação entre o comutador e o controlador. Internamente, para processar cada pacote,
um switch usa a memória endereçável de conteúdo Ternário (TCAM; do inglês, Ternary Content Addressable Memory) e a
memória de acesso aleatório (RAM; do inglês, Random Access Memory).
Atenção
TCAM é uma memória de especializada e de alta velocidade, que pode procurar conteúdos em um simples ciclo de clock. Ele
é comumente encontrado em equipamentos de rede, como roteadores e switches de alto desempenho, pois seu objetivo é
aumentar a velocidade de busca de rotas, classi�cação de pacotes, encaminhamento de pacotes e comandos baseados em
lista de controle de acesso.
"o termo “ternário” refere-se à capacidade da memória de armazenar e consultar
dados usando três entradas diferentes: 0, 1 e X. A entrada “X”, muitas vezes referida
como um estado “não importa” ou “curinga”, permite que o TCAM realize pesquisas
mais amplas com base na correspondência de padrões, ao contrário do CAM binário,
que realiza pesquisas de correspondência exata usando apenas 0s e 1s."
- (SCARPATI, 2013.)
De�nição de �uxos no OpenFlow v .1.0.0
Atualmente, a especi�cação mais utilizada é a versão 1.0.0. Um comutador que suporta a especi�cação OpenFlow 1.0.0
utiliza 12 campos de cabeçalho presentes no cabeçalho e na carga útil dos pacotes Ethernet que entram no comutador.
Um ou mais desses campos serão confrontados à regra na tabela de �uxo para indicar a ação a se tomar. O Quadro 5.2
mostra os campos do cabeçalho. Um pacote pode ter correspondência a uma entrada de �uxo especí�ca na tabela de
�uxo usando um ou mais campos de seu cabeçalho. Um campo na tabela de �uxo pode ter o valor de ANY e
corresponderá a todos os pacotes. A Tabela 5.2 apresenta os campos de�nidos na versão 1.0.0. do OpenFlow.
 Quadro 5.2 Campos de Cabeçalho de uma Entrada para OpenFlow 1.0.0. Fonte: Couto (2017).
Ações de um comutador OpenFlow
Quando temos uma correspondência de um campo do cabeçalho com alguma regra em uma entrada da tabela de �uxos,
a ação especi�cada deve ser realizada.
As ações que podem ser executadas sobre o pacote se dividem em dois grupos:
obrigatórias – devem ser implementadas por todos os switches OpenFlow;
opcionais – o switch deve informar ao controlador quais ações opcionais ele implementa.
Cada entrada da tabela está relacionada a uma ou mais ações. Se para determinada entrada não existir uma ação
especí�ca, os pacotes desse �uxo serão descartados.
A seguir, apresentamos uma lista das ações realizadas pelo comutador OpenFlow, segundo Kleis (2015):
Encaminhamento
Obrigatório
ALL – envia o pacote para todas as interfaces, exceto a de entrada;
CONTROLLER –encapsula e envia o pacote para o controlador;
LOCAL – envia o pacote para a pilha de rede local;
TABLE – realiza ações na tabela de �uxos;
IN\_PORT – envia o pacote para a porta de entrada;
Opcional
NORMAL – processa o pacote utilizando um encaminhamento tradicional;
FLOOD – inunda o pacote, sem incluir a interface de entrada.
En�leirar (opcional) – encaminha o pacote através de uma �la relacionada a uma porta;
Descartar (obrigatória);
Modi�car campo (opcional):
Setar Vlan ID;
Setar Vlan Priority;
Separar o cabeçalho da Vlan;
Modi�car endereço MAC (Media Access Control) de origem;
Modi�car endereço MAC de destino;
Modi�car endereço IP de origem;
Modi�car endereço IP de destino;
Modi�car ToS;
Modi�car a porta de transporte de origem;
Modi�car a porta de transporte de destino.
 Figura 5.5 Como um pacote é processado por um Switch OpenFlow 1.0.0. Fonte: Lara et al. (2014).
Conforme Couto (2017):
1. O pacote chega ao comutador e é analisado;
2. Cabeçalhos do quadro são extraídos e geram um packet lookup header, que representa o conjunto de todos os
cabeçalhos extraídos.
3. Esse conjunto de cabeçalhos extraídos é enviado para um sistema que realiza a correspondência dos quadros.
4. O Packet lookup header é comparado com os cabeçalhos contidos na tabela de �uxos.
Os cabeçalhos são colocados em ordem decrescente de prioridade.
5A. A lista de ações referente ao cabeçalho encontrado é executada.
5B. Se não foi encontrada nenhuma regra para os cabeçalhos selecionados, os primeiros 200 bytes do quadro são
enviados ao controlador.
O controlador decide o que fazer com o pacote e instala novas regras no switch.
 Canal Seguro
É por meio de um canal seguro que o controlador irá con�gurar e
gerenciar o switch OpenFlow. A con�dencialidade recomendada nessa
comunicação surge devido ao fato de que a conexão entre switch e
controlador pode ser realizada se aproveitando uma rede já em produção,
ou seja, o OpenFlow não exige uma conexão física direta e exclusiva entre
switch e controlador para funcionar – daí a preocupação com a
segurança.
O protocolo OpenFlow tem suporte para 3 tipos de mensagens:
Controlador-switch – Geradas pelo controlador para gerenciar e inspecionar o estado de um switch;
Assíncronas – Geradas pelo switch para atualizar o controlador sobre eventos da rede e mudanças no estado do
switch;
Simétricas – Podem ser geradas tanto pelo controlador quanto pelo switch, sendo enviadas sem solicitação.
Kleis (2015) assim classi�ca os subgrupos de mensagens:
Controlador-Switch
Características (Features) –
o controlador requisita as
características do switch;
Con�guração (Con�guration)
– usada para solicitar
con�gurações do switch;
Modi�cação de estado
(Modify-State) – usada para
adicionar, deletar e modi�car a
tabela de �uxos, bem como
para setar propriedades nas
portas do switch;
Leitura de estado (Read-
State) – coleta estatísticas;
Envio de pacote (Send-
Packet) – utilizado para enviar
pacotes por determinada porta
do switch;
Assíncrona
Entrada de pacotes (Packet-
In) – utilizada quando �uxos
não classi�cados entram no
switch;
Remoção de �uxo (Flow-
Removed) – mensagem enviada
para o controlador, quando um
�uxo é removido da tabela;
Estado da porta (Port-Status)
– mensagem enviada para o
controlador sempre que há
mudanças nas con�gurações
das portas;
Erro (Error) – noti�cação de
erro(s);
Simétrica
Hello – mensagens trocadas
entre o controlador e o switch
quando uma conexão é
estabelecida;
Echo – mensagens usadas
para identi�cação de latência,
largura de banda e existência de
conectividade;
Vendor – provê uma forma-
padrão para os I oferecerem
funcionalidades adicionais.
Barreira (Barrier) – usada
para garantir que as
dependências foram atendidas
ou receber noti�cações de
operações �nalizadas;
Assim, os dois entram em acordo sobre qual versão utilizar casos as versões sejam compatíveis. Se incompatíveis, uma
mensagem de erro (ERROR) é gerada, e a conexão entre eles é encerrada.
 Exemplos de Regras e Ações Realizadas
 Clique no botão acima.
Exemplos de Regras e Ações Realizadas
Na Figura 5.6, temos um resumo das entradas da tabela de �uxo.
Eisencraft et al. (2017) apresentam a seguir alguns exemplos de uso entre regras e campos de cabeçalho
empregados em switch OpenFlow:
Na Figura 5.7, temos que todosos pacotes destinados ao endereço 51.6.0.8 devem ser repassados para a
interface de saída (porta) 6 do switch. Lembrando que o * informa que aquele(s) campo(s) não será(serão)
levado(s) em consideração para aplicação da Ação.
 Figura 5.6 Tabela de fluxos. Fonte: Eisencraft et al. 2017.
No exemplo 2, Figura 5.8, temos duas formas de ações implementadas como um �rewall. Na primeira temos a
regra de não repassar (bloquear) todos os pacotes destinados à porta TCP 81. Enquanto, na segunda, todos os
pacotes enviados pelo host 128.119.1.1 devem ser descartados.
Na Figura 5.9, temos o exemplo de repasse baseado no endereço físico MAC. Assim, todos os quadros de
camada 2 do endereço MAC 22:A7:23:11:E1:02 devem ser repassados para a interface de saída 6 do switch.
 Figura 5.7 Exemplo 1: Repasse. Fonte: Eisencraft et al. (2017).
 Figura 5.8 Exemplo 2: Firewall. Figura 5.8. Fonte: Eisencraft et al. (2017).
 Figura 5.9 Exemplo 3: Repasse camada 2. Fonte: Eisencraft et al. (2017).
 Fonte: Shutterstock.
 Conclusão
O protocolo OpenFlow é uma peça importante para todo o funcionamento e a padronização de uma rede SDN. A partir
dele, dispositivos que desempenham funcionamento conforme uma SDN podem comunicar-se com o controlador.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Atividade
1. Por que há tantas versões do OpenFlow? Marque a alternativa correta:
a) Porque é possível a venda separada de uma versão comercial com possibilidade de suporte dos desenvolvedores.
b) Porque assim se pode conseguir uma versão que atenda à maior quantidade de uso em estudos de casos possível, sem
duplicação de esforços, utilizando-se uma estrutura genérica e definida.
c) Porque há um grande número de desenvolvedores, cada um com sua própria implementação.
d) Porque há o rápido desenvolvimento, que leva a pouco tempo de testes e, com isso, a um grande número de bugs a serem
corrigidos.
e) Porque existe uma determinação da própria ONF, que desenvolve o OpenFlow.
2. Se tivermos a seguinte regra “SRC=10.1.2.3, dest= *.*.*.* → para controlador”, ela signi�ca que:
a) Como o dest é qualquer um, sempre enviou os pacotes que chegam ao switch para o controlador.
b) Apenas quando tivermos a fonte sendo do IP 10.1.2.3 é que passaremos ao controlador.
c) Apenas quando tivermos o endereço MAC 10.1.2.3 como fonte é que passaremos ao controlador.
d) O pacote será descartado, pois o endereço de destino não é informado.
e) Apenas quando a fonte não for de 10.1.2.3 devemos encaminhar para o controlador.
3. Qual é o primeiro procedimento que acontece quando dois dispositivos, um switch OpenFlow e um controlador,
estabelecem uma conexão?
a) O controlador passa as informações de tabela de fluxos para o switch OpenFlow.
b) O switch OpenFlow repassa as informações de tabela de fluxos para o controlador.
c) Ambos os dispositivos trocam mensagens de HELLO.
d) Os dois passam à versão mais básica do OpenFlow, para depois prosseguirem.
e) O plano de dados do switch consulta o plano de controle, também do switch, e depois informa o controlador SDN.
4. Como seria um exemplo de regra para termos um comportamento de �rewall?
a) src = *.*.*.*, Porta TCP=81 → encaminhar controlador
b) src = *.*.*.*, Porta TCP=81 → drop
c) dest=10.3.4.5 → foward porta 2
d) src=10.3.2.5, Porta TCP=* → encapsular pacote
e) MAC dst=*, Porta TCP =80 → modificar campo
5. O que ocorre quando dois dispositivos não possuem versões do OpenFlow compatíveis?
a) A conexão entre os dispositivos é encerrada.
b) Ambos adotam a versão 0.2.0, que é mais básica possível.
c) O switch passa a operar normalmente como se não fosse um OpenFlow enabled.
d) O controlador exclui de sua rede o switch em questão.
e) O switch descarta todos os pacotes e não faz parte da rede.
6. São exemplos de ações desempenhadas por um switch OpenFlow:ações desempenhadas
a) Encaminhar, descartar e remontar.
b) Rotear, descartar, encaminhar e modificar.
c) Encaminhar, descartar modificar.
d) Descartar, controlar, encaminhar.
e) Rotear, empacotar, encaminhar e descartar.
Referências
CURTIS, Andrew R.; MOGUL, Jeffrey C.; TOURRILHES, Jean; YALAGANDULA, Praveen; SHARMA, Puneet; BANERJEE, Sujata.
Devo�ow: scaling �ow management for high performance networks. In: ACM SIGCOMM, 2011.
KIM, Wonho; SHARMA, Puneet; LEE, Jeongkeun; BANERJEE, Sujata; TOURRILHES, Jean; LEE, Sung Ju; YALAGANDULA, Praveen.
Automated and scalable QoS control for network convergence. Proceedings of USENIX INM/WREN 2010. San Jose, CA. April
2010.
KLEIS, E. G. Redes De�nidas por SW I: OpenFlow. 2015. Disponível em:
//www.teleco.com.br/tutoriais/tutorialsw1/pagina_4.asp. Acesso em: abril, 2019.
LARA, Adrian; KOLASANI, Anisha; RAMAMURTHY, Byrav. Network innovation using OpenFlow: a survey. IEEE Communications
Surveys & Tutorials, 2014.
MCKEOWN, Nick; PARULKAR, Guru; ANDERSON, Tom; PETERSON, Larry; SHENKER, Scott; TURNER, Jonathan; BALAKRISHNAN,
Hari; REXFORD, Jennifer. Open�ow: enabling innovation in campus networks. 2008.
javascript:void(0);
Notas de aula do professor Rodrigo de Souza Couto – Curso: Tópicos Especiais em Redes de Telecomunicações. Disponível
em: //www.lee.uerj.br/~rodrigo/sdnpel. Acesso em: abril, 2019.
Notas de aula dos professores Marcio Eisencraft, Cristiano Magalhaes Panazio e Phillip Mark Seymour Burt. Redes de
Comunicação. USP, 2017. Disponível em: https://edisciplinas.usp.br/course/view.php?id=36230. Acesso em: abril, 2019.
SCARPATI, Jessica. Ternary content-addressabel memory (TCAM). 2013. Disponível em:
https://searchnetworking.techtarget.com/de�nition/TCAM-ternary-content-addressable-memory. Acesso em: abril, 2019.
SCHLANSKER, Mike; TURNER, Yoshio; Tourrilhes, Jean; KARP, Alan. Ensemble routing for datacenter networks. Proc. of ANCS,
2010.
TOURRILHES, J.; SHARMA, P.; BANERJEE, S.; PETTIT, J. The Evolution of SDN and OpenFlow: a standards perspective. 2014.
Próxima aula
OpenvSwitch.
Explore mais
Assista ao video:
What Can OpenFlow Tables Do <https://www.youtube.com/watch?v=7R91K0d2r2E> .
javascript:void(0);
javascript:void(0);
https://www.youtube.com/watch?v=7R91K0d2r2E