Construção de uma Rede em Malha Sem fio com suporte a Openflow

Transcrição

1 Construção de uma Rede em Malha Sem fio com suporte a Openflow Italo Valcy 1,2, Ibirisol Fontes 1,2, Gustavo Bittencourt 1 1 Departamento de Ciência da Computação Universidade Federal da Bahia (UFBA) Av. Adhemar de Barros, s/n Campus Ondina Salvador, BA Brasil 2 Ponto de Presença da RNP na Bahia Rede Nacional de Ensino e Pesquisa (RNP) Av. Adhemar de Barros, s/n Campus Ondina Salvador, BA Brasil {italo, ibirisol, gustavo}@dcc.ufba.br Resumo. As redes em malha sem fio possuem uma série de propriedades particulares, as quais, quando combinadas com o novo paradigma de redes definidas por software, através do protocolo OpenFlow, requerem ainda mais atenção. Diversos desafios tecnológicos inerentes ao próprio tipo da rede, além dos requisitos das aplicações que a utilizarão, devem ser tratados, muitas vezes de forma empírica, para que a rede possa ser eficiente, robusta e, na prática, de implementação viável. Este trabalho apresenta um relato de experiência na montagem de uma rede em malha sem fio com suporte a OpenFlow, apresentado os principais desafios que devem ser levados em conta na construção de redes desse tipo. 1. Introdução Uma rede em malha sem fio é uma rede sem fio com múltiplos saltos, na qual cada nó pode comunicar-se com os outros nós da rede, seja de forma direta ou através do encaminhamento de tráfego por nós intermediários [3]. Esse tipo de rede é ideal quando é preciso manter a conectividade entre os nós de forma dinâmica, com uma rede auto-organizável e com crescimento orgânico [4]. Um exemplo de aplicação que necessita de uma rede com essas características é a rede utilizada pelo projeto SPACES-4D 1, na qual as câmeras de monitoramento do projeto serão instaladas em diversas localidades, muitas delas sem infraestrutura de rede, e a imagem de cada câmera será transportada até uma central de análise. Nessa rede, além das métricas de roteamento das redes em malha sem fio convencionais, deve-se levar em consideração métricas inerentes à aplicação que está sendo executada (e.g. priorização de tráfego definido pela aplicação, políticas de roteamento customizadas pelo administrador da aplicação, etc.). Diferentes protocolos de roteamento para redes em malha sem fio, tais como AODV ou OLSR, tem sido propostos. Não obstante, o conjunto de funcionalidades providas por esses protocolos é restrito e difícil de estender, limitando a definição de novas estratégias de engenharia de tráfego para criação de políticas de roteamento customizadas. No contexto de redes cabeadas, o novo paradigma de redes definidas por software (SDN, 1 SPACES-4D (Sistema Participativo de Gestão e Monitoramento de Cidades e Serviços Públicos usando rastreamento com câmeras 4D) é um projeto promovido pelo Governo Federal e organizado pela RNP, que vislumbra a integração entre sistemas de monitoramento (câmeras de vigilância) e conteúdos multimídias gerados por usuários comuns de Internet.

2 do inglês Software-Defined Networking) majoritariamente implementado através da tecnologia OpenFlow [6], é bem conhecido, aceito e com utilizações práticas. Para redes sem fio, alguns trabalhos de pesquisa tem sido realizados [3], porém utilizando infra-estrutura que na prática é difícil de ser implementada. Um outro aspecto coberto no paradigma de SDN, que viabiliza os estudos para experimentação de novos protocolos, é a separação entre o tráfego de produção e o tráfego de experimentação propriamente dito. No contexto do projeto SPACES, o tráfego de produção caracteriza-se pela transmissão das imagens geradas pelas câmeras, nesse momento utilizadas para monitoramento pela equipe de vigilância. Ao passo que o tráfego de experimentação utiliza métricas customizadas para rotear os fluxos de vídeo ao longo da rede, priorizando determinados fluxos em detrimento de outros. Por exemplo, quando um alvo sai do alcance de uma câmera e passa a ser melhor observado por outra, deve-se priorizar o tráfego dessa nova câmera, pois a carga gerada pela anterior pode prejudicar o rendimento da rede (e.g. causando maior atraso no fluxo mais importante o fluxo da câmera que possui o alvo a seu alcance). Nesse trabalho, apresentaremos um relato de experiência na montagem de uma rede em malha sem fio com suporte a OpenFlow, a fim de viabilizar a experimentação de estratégias de roteamento com métricas customizadas, apresentando os principais desafios que devem ser levados em conta na construção de redes desse tipo. 2. Desafios para construção da rede 2.1. Limites de hardware e software Os nós que compõem uma rede mesh possuem, em geral, capacidade de hardware bastante limitada (e.g. baixa velocidade de CPU, pouca memória, restrições de energia elétrica disponível, etc.). No cenário que construímos, por exemplo, cada nó é baseado em uma versão modificada do Linux (OpenWRT), com processador Broadcom de 200 Mhz, 16 MB de memória RAM e 4 MB de memória flash. Essas características reforçam a necessidade pela eficiência no processamento de pacotes encaminhados por um nó, a fim de aumentar o rendimento da rede (throughput) e também sua eficiência energética. Utilizar a tecnologia Openflow para controlar o plano de encaminhamento (datapath) desse tipo de nó, o qual geralmente não é implementado em hardware (e.g. TCAM), pode tornar-se um gargalo na rede [3]. Dessa maneira, as tabelas de regras Openflow devem ser simples (com poucos campos de casamento), evitando um alto custo de processamento por fluxo. Uma outra decisão importante é sobre o tipo de implementação Openflow a ser utilizada por cada nó mesh do projeto. Nós avaliamos a utilização do switch de referência Openflow [2], que executa em espaço de usuário, e também do OpenVSwitch [7], que executa em nível de kernel. A execução em espaço de usuário causa uma sobrecarga maior devido às constantes cópias de dados na memória entre o espaço de usuário e kernel, necessárias pela implementação do datapath. Por outro lado a implementação do Open- VSwitch, por ser construído com diversas funcionalidades além do Openflow, mostrou-se inviável devido às limitações de espaço em memória flash e RAM dos equipamentos disponíveis.

3 2.2. Sinalização OpenFlow O OpenFlow pressupõe a existência de conectividade IP entre os nós da rede, que apenas encaminham o tráfego, e o controlador, que possui toda a inteligência da rede e define como cada fluxo deve ser encaminhado pelos nós [6]. Existem duas formas de estabelecer esse canal de sinalização OpenFlow: usar a mesma rede de dados para a troca de mensagens do protocolo Openflow (gerenciamento in-band) ou configurar uma outra rede específica concorrente à rede de dados (gerenciamento out-of-band). O método in-band possui o desafio de necessitar das funcionalidades de roteamento IP para conexão do nó ao controlador, ao passo que essas funcionalidades serão providas pelo próprio controlador quando o canal estiver estabelecido. Para resolver essa impasse do ovo e da galinha, as implementações de switches OpenFlow [2, 7] comumente pré-configuram um conjunto de regras para repassar mensagens do protocolo OpenFlow adiante, na esperança que elas em determinado momento alcancem o controlador. Esse repasse das mensagens deve ocorrer em modo inundação (flooding), encaminhando inclusive para a porta de entrada, que em nós sem fio é a mesma porta de saída. Essa característica pode levar a criação de loops na rede e, portanto, as implementações avaliadas não estão preparadas para operar corretamente nesse cenário. Ao partir para uma solução de gerenciamento out-of-band, pode-se implementála com diferentes estratégias: i) ligação Ethernet cabeada até cada nó mesh sem fio, ii) utilização de redes virtuais, com diferentes SSIDs, para separação entre o tráfego de controle e de dados, ou ainda iii) utilizar nós mesh com dois radios independentes. Para as propostas que usam a rede sem fio (ii, iii), protocolos de roteamento convencionais, tais como OLSR [5], podem ser usados. Não obstante, todas essas propostas possuem desvantagens relevantes que podem inviabilizar seu uso. Uma das desvantagens está na sobrecarga adicional de roteamento que essa rede concorrente pode inserir em cada nó [3] e no nível de interferência do canal sem fio causado em cada nó [8]. Ademais, na prática é pouco viável instalar uma rede Ethernet cabeada em um ambiente out-door ou adquirir nós com dois rádios sem fios independentes. A implantação de múltiplos SSIDs, ambos no modo IBSS 2, em um único rádio sem fio, não é suportada pela maioria dos chipsets que avaliamos Operação dos nós sem fio como switches O openflow foi criado inicialmente para ser implementado em switches e roteadores, construídos com um hardware especializado e de alto desempenho (e.g. ASIC, TCAM), no qual um elemento simples (datapath) encaminha pacotes entre portas, conforme definido pelo controlador [6]. Entretanto, é possível criar switches com suporte a OpenFlow a partir de servidores Linux convencionais, placas NetFPGA, sistemas de virtualização. Nesses casos, é comum que cada adaptador de rede possua seu próprio endereço de identificação (endereço MAC), porém todos eles devem ser aceitos para acesso ao switch. Para resolver essa questão, as implementações do Openflow disponíveis configuram as interfaces que fazem parte de um datapath em modo promiscuo 3. Outros protocolos de roteamento para 2 O modo IBSS (Independent Basic Service Set), também conhecido como modo Ad-Hoc, permite a criação de uma rede sem fio sem a necessidade de um ponto de acesso central (AP) na rede. Mais informações: 3 Modo de operação do adaptador de rede onde alguns filtros em nível de hardware são desabilitados e o adaptador passa a aceitar também o tráfego que não é destinado a ele, encaminhando-os para tratamento no

4 redes ad-hoc tratam isso configurando o mesmo endereço do adaptador wireless (MAC) para todos os nós [5]. Ambas as soluções, todavia, pelo fato de remover um filtro de hardware que evita processamento adicional a nível de software, acabam por impactar no desempenho dos nós mesh sem fio. O impacto é ainda mais crítico em nós mesh sem fio, cujos recursos de hardware são limitados. Outra características de switches Openflow é que o encaminhamento de pacotes entre portas, comumente usa como saída uma porta diferente da porta de entrada. No caso de nós mesh sem fio, a porta de saída quase sempre será a mesma porta de entrada (adaptador sem fio). Somando-se a isso o fato intrínseco de existência de conectividade entre os nós, faz-se essencial a existência de mecanismos de controle de loops, de forma a manter a rede funcional. 3. Montagem da rede de experimentação 3.1. Preparação dos nós SPACES No ambiente que foi montado para o projeto SPACES, cada nó mesh é composto por um roteador sem fio (Linksys WRT54GL, com um adaptador sem fio Broadcom BCM5352), protegido por sua respectiva caixa hermética, e uma câmera IP (Zavio D6111) conectada a esse roteador (via cabo de cobre, padrão IEEE 802.3). O projeto prevê também a utilização de antenas wifi de largo alcance nos roteadores sem fio, porém as antenas não foram conectadas nesse primeiro momento pela escolha de montagem da rede em um ambiente indoor. Toda a comunicação entre os nós SPACES, além do acesso aos fluxos de vídeo das câmeras, será feito via rede sem fio em malha, formada por nós estacionários. Mesmo nesse ambiente indoor, uma dificuldade inicial observada foi a falta de pontos de energia nos locais escolhidos para instalação de cada nó mesh. Nesses locais, que haviam sido reservados anteriormente para conexão de câmeras IP com suporte a PoE, havia passagem de apenas um cabo U/UTP Cat 6 para cada ponto. Por outro lado, precisávamos conectar dois equipamentos com demanda elétrica de corrente contínua, a câmera e o roteador wireless, dos quais apenas a câmera possuía suporte a PoE. Diante desse cenário, e baseados em trabalhos anteriores [1], a solução adotada foi a criação de um protótipo de injeção de energia para os equipamentos, em conformidade com o padrão IEEE 802.3af, porém adaptado para nossa necessidade. A norma IEEE 802.3af (PoE, do inglês Power over Ethernet) descreve uma maneira padrão de transmitir energia elétrica junto aos dados em redes Ethernet. O protótipo desenvolvido difere do padrão PoE, pois utiliza dois pares ociosos do padrão Ethernet 100Base-TX para conectar dois equipamentos distintos, injetando tensão DC a partir da própria fonte de cada equipamento. O roteador sem fio, para que pudesse ser transformado em um nó mesh com suporte a Openflow, passou pela substituição de seu firmware original por uma imagem customizada do OpenWRT 4. A geração da imagem do OpenWRT ideal para os nós SPACES requisitou diversos testes e compilações do sistema. Primeiro foi avaliada a versão précompilada do OpenWRT com suporte a Openflow (kernel ), construída pelos membros do consórcio Openflow, porém nessa versão a rede sem fio não funcionava em sistema operacional. 4 O OpenWRT é uma distribuição customizada do Linux criada especialmente para ser executada em hardware especializado, com diversas otimizações no kernel e apenas os sistemas essenciais para funcionamento do ambiente. Mais informações:

5 modo IBSS. Em seguida o OpenWRT foi compilado com o kernel 2.4 e o firmware proprietário 5 do adaptador sem fio (wl), pois esse firmware permite a criação de múltiplos ESSIDs, por outro lado, ele não disponibiliza acesso à API nl80211 do kernel, que permite obter informações detalhadas sobre a camada física em adaptadores sem fio (e.g. lista de vizinhos associados, nível de sinal de cada associação, etc.). Após alguns testes, verificamos que mesmo possibilitando a criação de múltiplos ESSIDs, apenas um deles poderá ser configurado em modo IBSS. Além disso, ao configurar um SSID em modo IBSS, nenhum outro SSID poderia ser criado. Por fim, compilamos o OpenWRT com o kernel , no qual o problema de conectividade entre nós IBSS foi corrigido, o OpenFlow funcionou corretamente e a API nl80211 estava disponível Configuração da rede Openflow Devido aos problemas na criação de redes virtuais (múltiplos SSID) e a dificuldade na utilização do modo in-band (ver Seção 2.2), optou-se por em um primeiro momento, utilizar a conexão Ethernet que alimenta os switches (pares de dados) como meio para configuração out-of-band do canal de sinalização entre o switch e o controlador. De fato, essa configuração não é adequada ao projeto e já está sendo trabalhada pelo grupo. OFCTL Figura 1. Topologia lógica da rede Openflow A Figura 1 mostra a topologia lógica de conectividade entre os nós e entre cada nó e o controlador. Nessa figura, o controlador Openflow (OFCTL) é apresentado como um servidor convencional (Dell XXX, com Debian Linux 7.0) e os nós mesh são representados como pontos de acesso sem fio (Linksys WRT54GL com OpenWRT Backfire e Openflow), formando uma rede com conectividade total (full-mesh). 4. Resultados preliminares Como forma de validar toda a configuração realizada nos nós mesh sem fio, foram realizados experimentos de teste de conectividade entre os equipamentos e transmissão do fluxo de vídeo das câmeras instaladas em cada nó mesh, utilizando em ambos a rede gerenciada pelo OpenFlow. Para viabilizar esses testes, foi desenvolvida uma aplicação OpenFlow simples que, tomando como premissa o conhecimento da topologia da rede, envia os dados de um 5 Foi necessário corrigir um bug nessa versão do kernel, no subsistema de processamento de parâmetros do adaptador (ioctl), necessário para o funcionamento do OpenFlow

6 fluxo por um caminho pré-definido na rede. Além disso, a tabela de fluxos dos switches openflow são alimentadas com regras granulares, a fim de evitar situações de loop. O código da aplicação foi escrito em python 6, utilizando a API do Openflow disponível para o controlador POX Conclusão Os desafios encontrados na criação de uma rede mesh sem fio com suporte a Openflow, mostram uma vasta gama de questões que devem ser levadas em conta na utilização dessas tecnologias para experimentação ou para atendimento de requisitos das aplicações. As importantes observações levantadas nesse trabalho, em termos práticos, servem de base para a construção de cenários semelhantes bem como apontam limitações tecnológicas que podem ser exploradas. Utilizar estratégias mais viáveis para ambientes reais (e.g. gerenciamento in-band) e avaliar o desempenho e robustez da solução implantada, fazem parte de um trabalho futuro que já está sendo desenvolvido. Referências [1] C. V. N. Albuquerque, D. C. M. Saade, D. G. Passos, Douglas Vidal Teixeira, Julius Leite, Luciana Esteves Neves, and Luiz Claudio Schara Magalhaes. Gt-mesh relatorio tecnico 3 - avaliacao dos resultados do prototipo. Technical report, RNP, [2] The OpenFlow Consortium. Openflow website. openwrt/. Último acesso: abril de [3] Peter Dely, Andreas Kassler, and Nico Bayer. Openflow for wireless mesh networks. In Computer Communications and Networks (ICCCN), 2011 Proceedings of 20th International Conference on, pages 1 6. IEEE, [4] E. Hossain and K.K. Leung. Wireless Mesh Networks: Architectures and Protocols. Springer Science+Business Media, LLC, [5] P. Jacquet, P. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum, and L. Viennot. Optimized link state routing protocol for ad hoc networks. In IEEE International Multi Topic Conference (IEEE INMIC). Technology for the 21st Century. Proceedings, [6] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69 74, March [7] Ben Pfaff, Justin Pettit, Teemu Koponen, Keith Amidon, Martin Casado, and Scott Shenker. Extending networking into the virtualization layer. Proc. HotNets (October 2009), [8] Krishna N. Ramachandran, E. M. Belding, K. C. Almeroth, and M. M. Buddhikot. Interference-aware channel assignment in multi-radio wireless mesh networks. In IEEE International Conference on Computer Communications (INFOCOM),