O m ´odulo de pol´ıticas e a integrac¸˜ao com o Merlin

Neste trabalho, uma pol´ıtica ´e um conjunto de regras, em blocos de c ´odigo ou j´a compiladas, que define um comportamento que a rede subjacente deve respeitar. A biblioteca possui um m ´odulo de pol´ıticas que abrange a integrac¸˜ao com o Merlin.

Durante a etapa de transcompilac¸˜ao das diretivas Havox em pol´ıticas Merlin, ´e necess´ario remover as m´ascaras de sub-rede dos prefixos de rede nos atributos de correspondˆencia por enderec¸o IP de origem e de destino. A raz˜ao disso ´e porque o Merlin n˜ao opera com enderec¸os contendo m´ascaras. Ao final da transcompilac¸˜ao, o c ´odigo Merlin gerado ter´a todos os enderec¸os IP dos atributos, se houver, sem as suas m´ascaras. Estas ser˜ao recuperadas depois, na etapa de tratamento.

Passada a etapa de transcompilac¸˜ao das diretivas da DSL do Havox, o c ´odigo Merlin gerado ´e gravado em um arquivo no sistema de arquivos local. Esse ar- quivo ´e submetido para o compilador do Merlin, o qual ir´a gerar regras OpenFlow primitivas impressas em stdout. Como essas regras s˜ao textuais, ´e realizado um parsing das mesmas e posterior estruturac¸˜ao em objetos4_.

Depois da estruturac¸˜ao, as regras passam por um processo de tratamento cujas etapas podem ou n˜ao ser executadas, de acordo com os parˆametros que o usu´ario fornece na requisic¸˜ao `a API do Havox. S˜ao elas:

4_{No escopo da programac¸˜ao orientada a objetos, um objeto ´e uma instˆancia de uma classe, que}

por sua vez representa um conjunto de objetos com caracter´ısticas similares. Objetos guardam estados pr ´oprios e possuem atributos e m´etodos de acordo com a implementac¸˜ao de suas classes.

Sobrescrita de atributos: O pr ´oprio framework Merlin ainda n˜ao ´e plenamente est´avel em sua vers˜ao corrente. Dependendo das pol´ıticas que ser˜ao com- piladas, s˜ao geradas regras com atributos conflitantes no predicado, o que requer uma correc¸˜ao da sa´ıda. Esta etapa identifica e permite que os atri- butos sejam reescritos, caso a opc¸˜ao para tal seja passada. Caso contr´ario, o primeiro valor atribu´ıdo ´e usado. Um exemplo de caso em que isso acontece ´e quando uma pol´ıtica contendo um atributo de enderec¸o IP de destino ´e compilada. As regras geradas vir˜ao tanto com o enderec¸o IP do host de destino quanto com o enderec¸o IP de destino passado pela diretiva. Por´em, em todos os testes realizados, o enderec¸o IP do host sempre vem antes do enderec¸o vindo da diretiva. Se este parˆametro estiver definido como falso, o enderec¸o IP do host ser´a considerado. Se definido como verdadeiro, o valor do atributo ´e sobrescrito ap ´os a leitura do enderec¸o vindo da diretiva.

Substituic¸˜ao de ac¸ ˜oes de encaminhamento: O padr˜ao do Merlin ´e gerar regras cujas ac¸ ˜oes de repasse sejam para enfileiramento dos pacotes nas sa´ıdas especificadas dos switches (ac¸˜ao enqueue(<porta>, <fila>)), o que d´a su- porte a QoS (qualidade de servic¸o, do inglˆes Quality of Service) do protocolo OpenFlow quando h´a filas configuradas. Como este trabalho ainda ´e uma prova de conceito, o recurso de filas ainda n˜ao ´e utilizado, portanto esta etapa substitui as ocorrˆencias de ac¸˜ao de enfileiramento por ac¸˜ao de enca- minhamento simples (output(<porta>)).

Expans˜ao de predicados: Subconjuntos de regras geradas pelo Merlin que cor- respondem a um determinado fluxo de pacotes s˜ao identificados interna- mente por IDs de VLAN, que atuam como r ´otulos ´unicos para cada tipo de tr´afego. Nos switches de entrada, as primeiras regras s˜ao formadas por predicados completos com todos os atributos a serem avaliados do pa- cote. Quando h´a uma correspondˆencia, al´em da ac¸˜ao de encaminhamento, o Merlin tamb´em aplica ao pacote uma ac¸˜ao de definic¸˜ao de ID de VLAN (set vlan id(<n´umero>)) com um valor ´unico e arbitr´ario. Ao sair do switch de entrada, os pacotes daquele fluxo passam a ter o atributo vlan id defini- dos e os switches seguintes do caminho avaliar˜ao apenas esse atributo para identificar o fluxo. No switch de sa´ıda, o atributo vlan id ´e apagado (ac¸˜ao set vlan id(null)) e os pacotes do fluxo s˜ao encaminhados para o host devido. Esta etapa expande todas as regras para que usem o predicado completo nas correspondˆencias, em vez do ID de VLAN. As Tabelas 3.3 e 3.4 exemplificam um caso de uso sem e com expans˜ao das regras, com trˆes

switches s1, s2 e s3 interligados e hosts conectados a s1 e s3, de entrada e sa´ıda do fluxo, respectivamente. Para fins de entendimento, foram usados atributos gen´ericos a, b e c e nomes em vez de n ´umeros como parˆametro das ac¸ ˜oes output. Esta etapa foi projetada visando trabalhos futuros, quando se pretende usar a biblioteca Havox para exportar regras OpenFlow para outras plataformas diferentes do RouteFlow e que podem n˜ao implementar o suporte a IDs de VLAN. O RouteFlow mesmo n˜ao implementa VLANs em sua vers˜ao original. Por´em, para este trabalho, o c ´odigo-fonte do RouteFlow foi aprimorado para que contemplasse esse suporte.

Traduc¸˜ao de sintaxe das regras: Conforme mencionado, um dos intuitos deste trabalho ´e que a ferramenta cerne da arquitetura, a biblioteca Havox, seja modular e tenha capacidade para ser integrada a diferentes arquiteturas e casos de uso. As regras OpenFlow estruturadas podem ser traduzidas para quaisquer sintaxes conhecidas, desde que as l ´ogicas de traduc¸˜ao sejam implementadas. Nesta prova de conceito, tendo em vista a arquitetura como um todo, o padr˜ao estabelecido ´e a sintaxe compat´ıvel com o RouteFlow.

Switch Regra n˜ao expandida

s1 a = 1 and b = 2 and c = 3 -> set vlan id(10) and output(s2) s2 vlan id = 10 -> output(s3)

s3 vlan id = 10 -> set vlan id(null) and output(host) Tabela 3.3: Regras n˜ao expandidas usando IDs de VLAN. Switch Regra expandida

s1 a = 1 and b = 2 and c = 3 -> output(s2) s2 a = 1 and b = 2 and c = 3 -> output(s3) s3 a = 1 and b = 2 and c = 3 -> output(host) Tabela 3.4: Regras expandidas sem o uso de IDs de VLAN.

Todas as etapas de tratamento citadas s˜ao opcionais e dependem dos argumen- tos fornecidos `a API do Havox. Independentemente dos argumentos, ´e executado um tratamento adicional para a recuperac¸˜ao das m´ascaras de sub-rede dos prefi- xos de rede dos atributos de enderec¸amento IP das regras.

A lista de redes alcanc¸´aveis, se populada, ´e iterada para cada regra que conte- nha atributos de enderec¸amento IP. O valor do atributo ´e avaliado para verificar se est´a contido dentro da faixa de enderec¸os de cada prefixo da lista. O prefixo que contiver ser´a usado no lugar do valor do atributo de enderec¸o IP de origem

ou de destino, o que far´a com que a informac¸˜ao de m´ascara seja recuperada para a regra.

O Merlin automaticamente inclui atributos de enderec¸o IP de origem e de destino em todas as regras, visto que o framework foi idealizado para operar em redes institucionais, mesmo que tal atributo n˜ao tenha vindo por diretiva. Isso ocorre porque o Merlin usa os enderec¸os IP do host de origem e do host de destino para classificar o tr´afego, supondo que os pacotes sejam criados e entregues nos hosts. Numa rede institucional funciona dessa maneira, mas esse n˜ao ´e o modus operandi da Internet, cujos pacotes podem ter origens e destinos diversos. Para este trabalho, esses atributos de enderec¸amento IP adicionados pelo Merlin s˜ao considerados inv´alidos.

O tratamento da m´ascara de sub-rede tamb´em elimina os atributos de cor- respondˆencia por enderec¸os IP inv´alidos. Os valores s˜ao identificados como inv´alidos quando n˜ao constam na lista de redes alcanc¸´aveis. O resultado final do tratamento s˜ao regras que s ´o possuir˜ao correspondˆencia por enderec¸os IP de origem ou destino se de fato esses atributos vieram das diretivas.

Findados os passos de tratamento, o conjunto final de regras especiais ´e ex- portado pela API em formato de mensagem JSON.