Conj. Ações
Conj. Ações
Prioridade Campos Instrução Contadores Timeout Cookie
Prioridade Campos Instrução Contadores Timeout Cookie
Prioridade Campos Instrução Contadores Timeout Cookie
Adaptado de [Jammal et al., 2014, p.78].
Figura 2.2: Arquitetura básica do OpenFlow
Comutadores compatíveis com OpenFlow podem ser separados em dois tipos prin- cipais: OpenFlow-exclusivo e OpenFlow-híbrido (Foundation [2013]). Os comutadores OpenFlow-exclusivo fornecem apenas operações definidas no protocolo OpenFlow, ou seja, todo o fluxo de pacotes é processado pelo controlador OpenFlow. Comutado- res híbridos suportam o protocolo OpenFlow (em algum nível) mas também realizam operações normais de comutação em camada 2 (enlace) e/ou camada 3 (rede).
Um comutador OpenFlow possui uma sequência de tabelas de encaminhamento, como mostrado na figura 2.2, que definem como os quadros são tratados ([Foundation, 2013, p.13-26]). Cabe ao controlador definir como estas tabelas são preenchidas e assim definir como os fluxos se comportam na rede. O controlador cria entradas na tabela, que são aplicadas caso os cabeçalhos do pacote casem com um seguinte padrão. No comutador há um processo de verificação que analisa cada tabela buscando uma regra para o quadro recebido. Três situações podem ocorrer a partir deste processo: (a) o fluxo é casado a uma regra e esta é aplicada; (2) pode haver uma regra padrão quando não existe uma coincidência nas tabelas de encaminhamento ou (3) o quadro pode ser descartado. A regra padrão normalmente consiste em enviar o quadro para o controlador, gerando o evento PacketIn descrito a seguir. Este processo é mostrado na
2.2. O Protocolo OpenFlow 13
Quadro recebido pelo comutador Coincidência na tabela n? Começa na tabela 0 Existe entrada para table-miss flow? Não Descartar quadro recebido Não Atualizar contadores Executar instruções:
• atualizar conjunto de ações • atualizar pacote/campos • atualizar metadados Sim Ir para tabela n? Executar conjunto de ações Não Sim Adaptado de [Foundation, 2013, p.16].
Figura 2.3: Fluxograma detalhando o fluxo de pacotes em um comutador OpenFlow a partir da versão 1.3.0
figura 2.3.
Cada entrada na tabela de fluxos possui uma ou mais ações associadas. Estas ações (Guedes et al. [2012]) permitem encaminhar um pacote para um porto (ou por- tos) específico(s) do comutador, alterar uma parte do cabeçalho do pacote antes de encaminhá-lo, descartá-lo, encaminhar para o controlador o pacote para inspeção ou permitir que o controlador crie novos pacotes que são encaminhados à rede.
2.2.1
Controladores
Os controladores são responsáveis por programar as tabelas de fluxos dos comutadores. Existem diversos tipos de controladores SDN, como o Beacon, Floodlight, HyperFlow, Maestro, NOX, ONIX, OpenDayLight, POX, Ryu, Trema, entre outros (Gude et al. [2008], Erickson [2013], Cai et al. [2013], Koponen et al. [2010], Shah et al. [2013], Tootoonchian & Ganjali [2010], Kreutz et al. [2014]).
O POX é uma plataforma de desenvolvimento de aplicações de controle de redes SDN que roda em Python (versão 2.7 ou superior). Esta plataforma foi desenvolvida com base na especificação 1.0 do OpenFlow, com algumas adaptações para a versão 1.1. Esta é uma plataforma muito utilizada na criação de protótipos.
Com o POX é possível definir um conjunto de funções, onde cada uma responde ao evento que foi registrado. Estes tratadores de eventos executam de forma não
preemptiva. O POX oferece um amplo conjunto de eventos como:
• ConnectionUp, ConnectionDown: ocorrem, respectivamente, quando um comu- tador OpenFlow conecta-se ou desconecta-se do controlador;
• PacketIn: evento acionado quando o comutador recebe um quadro desconhecido, ou seja, este quadro que não casa com nenhuma regra instalada. Este fluxo é, então, encaminhado para o controlador;
• FlowRemoved : evento chamado quando um fluxo já programado no comutador é removido;
• RawStatsReply, QueueStatsReceived, AggregateFlowStatsReceived, TableStatsRe- ceived, PortStatsReceived, FlowStatsReceived : são a resposta do comutador a uma demanda de informações sobre os fluxos de dados feita pelo controlador;
• FeaturesReceived, PortStatus, SwitchDescReceived : são respostas do comutador a uma demanda de informações sobre o estado ou características do comutador feita pelo controlador.
2.3
Limitações de SDN
Apesar de ser vantajoso separar fisicamente os planos de controle e dados, como vimos anteriormente, esta arquitetura traz limitações inerentes. Por exemplo, a separação do plano de dados do plano de controle, em geral, cria uma penalidade de desempenho em termos de atrasos adicionais para operações de controle, como no caso das configu- rações de fluxos pelo controlador, para a descoberta de topologia e na recuperação de falhas. Além disto, a centralização do plano de controle insinua a possibilidade de pro- blemas com a escalabilidade e com a confiabilidade do controlador, criando o dilema da existência de um ponto de falha único com as dificuldades adicionais na implementação de um sistema de controle distribuído.
Em uma rede atual de alto desempenho e com muitos usuários, temos que con- siderar três elementos: o desempenho, a capacidade de programação e a flexibilidade. O desempenho refere-se especificamente à velocidade de processamento do nó de rede considerando tanto a vazão quanto a latência. A utilização de uma abordagem SDN implica no acréscimo de uma latência adicional resultante da tomada de decisão pelo controlador3. A programação implica na capacidade de mudar ou aceitar um novo
3
2.3. Limitações de SDN 15
conjunto de funções e algoritmos, a fim de alterar o comportamento funcional do dis- positivo. Já a flexibilidade é a capacidade de adaptação dos sistemas para suportar novos recursos não previstos. A abordagem SDN acrescenta flexibilidade ao contexto do encaminhamento de dados ao mesmo tempo que suas APIs abertas facilitam o processo de adaptação. Contudo, muitas vezes os programas dos controladores são executados em servidores de uso geral e usam linguagem de alto nível, como o Python. Mesmo utilizando controladores com executáveis compilados, como no NOX, uma rede SDN tem dificuldade em lidar reativamente com os fluxos de pacotes em enlaces de altíssima velocidade, ou seja, redes de 100Gbps ou mais (Sezer et al. [2013]). Portanto, novas abordagens são necessárias para tratar estes elementos em redes de alta velocidade. Uma forma de diminuir a latência é, sempre que possível, computar antecipadamente as regras de encaminhamento, fazendo uma instalação proativa destas regras, ao invés da forma reativa, quando a regra é criada na chegada do primeiro pacote do fluxo.
Implementações de SDN em hardware estão sendo testadas com base em requi- sitos cada vez mais estritos de desempenho. Nos operadores de telefonia, as restrições para recuperação de uma falha de um nó ou enlace são da ordem de 50 milissegundos em função do tráfego de voz ([Farrel & Bryskin, 2005, p.94]). Esta é uma limitação importante, pois restringe o tempo para obter uma resposta do controlador central. Diversas iniciativas utilizando processadores de uso geral, NPU/NFP (Network flow processors - processadores de fluxo de rede), PLDs (Programmable logic devices), FP- GAs (Field Programmable Gate Arrays) e ASICs (Application-specific integrated cir- cuits) estão sendo testadas para melhorar o desempenho em ambientes com SDN (Sezer et al. [2013]). Indícios apontam para a necessidade de adoção de uma solução híbrida como indicado por diversos autores (Ozdag [2012]; Bosshart et al. [2013]; Doo et al. [2012]; Narayanan et al. [2012]; Bosshart et al. [2014]).
Mesmo quando não existe esta limitação do tráfego de voz, ainda existe o pro- blema dos dispositivos de rede perderem a conectividade com o controlador central, se o enlace primário com ele falhar. Isto implica na necessidade de se manter parte da inteligência nos dispositivos e/ou instalar caminhos alternativos pré-computados para os nós da rede. Esta abordagem pode permitir melhorar o desempenho e permitir que pelo menos parte das funcionalidades continuem funcionando independente da conexão com o controlador, porém isto gera maior complexidade de programação.
2.4
Conclusões
Como vimos, o protocolo OpenFlow é um protocolo capaz de permitir o controle do plano de dados dos equipamentos de comutação em uma rede cabeada. Diversas apli- cações estão baseadas neste protocolo, contudo ainda existem desafios para esta arqui- tetura quando analisamos requisitos de desempenho, segurança e interoperabilidade.
As abordagens SDN típicas, como o OpenFlow, não apresentam mecanismos ca- pazes de lidar com as complexidades do ambiente de rede sem fio. Novas maneiras de se pensar as abordagens SDN são necessárias para tratar as complexidades das redes sem fio, como apresentaremos no capítulo 3, a seguir.