ONSC - OPENFLOW NAME SYSTEM CACHE

ONSC - OPENFLOW NAME SYSTEM CACHE Yuri Silva Paludo 1 Rafael Bohrer Ávila 2 Resumo: As redes IPs compõem a maioria das redes locais de computadores encontradas atualmente e cada vez mais dispositivos estão conectados e buscam os serviços oferecidos por essas redes. Um dos serviços mais comuns e mais utilizados nessas redes é o serviço de DNS (Domain Name System). Este trabalho apresenta uma solução que utiliza a arquitetura de redes definidas por software para realizar cache do serviço de DNS em uma rede local. São explorados os conceitos e tecnologias dessas duas arquiteturas, assim como a realização de testes na solução proposta. Foi realizada uma coleta de dados para obter informações do comportamento do serviço de DNS, e assim, foram utilizadas simulações com essa solução para verificar como a utilização das redes definidas por software pode reduzir o volume de tráfico DNS presente na rede. Palavras-chave: Redes Definidas por Software. Protocolo OpenFlow. Redes Virtuais. Domain Name System. 1 INTRODUÇÃO As redes de computadores têm se tornado maiores e mais complexas. Entretanto, durante anos, as camadas intermediárias na pilha de protocolos das redes de computadores se tornaram ossificadas, como por exemplo, o desenvolvimento do Internet Protocol (IP), enquanto outras partes da pilha de protocolos foram evoluindo e o protocolo IP se manteve o mesmo (REX- FORD; DOVROLIS, 2010). Utilizando o conceito de Redes Virtuais, um conceito largamente difundido na indústria e na comunidade acadêmica, foi proposta uma nova arquitetura de rede que possa facilitar o desenvolvimento e testes de novos protocolos e prover novas funcionalidades para a rede. Ainda há outras características e aplicações que estão sendo desenvolvidas e descobertas. Essa nova arquitetura é chamada de Redes Definidas por Software. O tema de Redes Definidas por Software (do inglês, Software-Defined Networking - SDN) é recente e, atualmente, o foco principal das pesquisas realizadas com esse tema está relacionado em como utilizar esse novo conceito para resolver problemas das redes de computadores tradicionais. O protocolo OpenFlow foi desenvolvido para trabalhar com a arquitetura SDN, e é reconhecido como o padrão nesse segmento (BAKSHI, 2013). Neste trabalho é utilizada a arquitetura de SDN para realizar cache de consultas DNS. Além do grande aumento na utilização de dispositivos móveis como smartphones e tables, dispositivos do nosso dia-a-dia têm cada vez mais a capacidade e a necessidade de se conectarem à rede e acessar algum serviço nela disponível. 1 Aluno do curso de Ciência da Computação. Email: yuris.plus@gmail.com 2 Orientador, professor da Unisinos. Email: rbavila@unisinos.br

2 Ao realizar melhorias no serviço de DNS, ao mesmo tempo estamos trazendo benefícios para uma grande quantidade de serviços e aplicações que utilizam o DNS. Alguns desses serviços, como por exemplo a descoberta de serviços, utilizam o DNS em suas operações mais simples e dependem do seu bom funcionamento. Este trabalho tem como objetivo propor uma solução para a redução de tráfego DNS em redes ethernet utilizando o conceito de SDN. Assim como apresentar outros benefícios que uma solução baseada em Redes Definidas por Software podem trazer para o serviço de DNS. O presente trabalho está organizado da seguinte forma: Na seção seguinte são apresentados os conceitos dos dois assuntos que guiam esse trabalho, redes definidas por software e DNS, destacando os protocolos e pontos principais de cada um. Na seção três é feito um estudo de três artigos relacionados com os temas desse trabalho, apresentando os conceitos utilizados nesses artigos. Seção 4 contempla a solução oferecida por este trabalho, onde cada etapa da solução é detalhadamente explicada e exemplificada. As seções seguintes, 5 e 6, mostram respectivamente como foram realizados os experimentos dessa solução e os resultados alcançados. Por fim, na última seção apresentamos a conclusão desse artigo. 2 FUNDAMENTAÇÃO TEÓRICA Está seção apresenta os conceitos e tecnologias que serão abordados durante o desenvolvimento deste trabalho. As duas áreas centrais desse trabalho são: Redes Definidas por Software e a arquitetura e mensagens DNS, sendo assim, as próximas subseções explicam os conceitos e características dessas áreas que serão de relevância ao longo desse artigo. 2.1 Redes Definidas por Software (SDN) Redes Definidas por Software é uma nova arquitetura de rede que evoluiu da ideia de redes virtuais (OPEN NETWORKING FOUNDATION, 2012). A principal diferença nessa arquitetura se comparada às redes de computadores tradicionais é que o plano de dados e o plano de controle são separados e a inteligência da rede (plano de controle) é logicamente centralizada. Algumas das vantagens dessa arquitetura é prover as redes de computadores de uma capacidade sem precedentes de serem programadas, automatizadas e controladas, permitindo que as rede se tornem mais escaláveis e flexíveis conforme a necessidade (LIMONCELLI, 2012). Como o plano de dados e o plano de controle são separados, é necessária alguma forma padronizada de comunicação entre eles e, por essa razão, a ONF (Open Networking Foundation) propõe a utilização de um protocolo que defina a interface de comunicação em uma rede SDN. Esse protocolo é o OpenFlow e será descrito mais adiante neste artigo (OPEN NETWORKING FOUNDATION, 2012). Segundo a ONF alguns dos principais objetivos da arquitetura SDN são: Aumentar a segurança e a disponibilidade da rede como resultado do controle e gerenci-

Camada de Infraestrutura Camada de Controle Controlador SDN Camada de Aplicação 3 Figura 1 Arquitetura Básica das Redes Definidas por Software Aplicação SDN 1 Aplicação SDN 2 Aplicação SDN 3 SDN Northbound Interface (NBI) Serviço de Rede 1 Serviço de Rede 2 Serviço de Rede 3 Serviço de Rede 4 Serviço de Rede 5 Serviço de Rede N SDN Control Data Plane Interface (CDPI) Elemento de Rede Elemento de Rede Elemento de Rede Elemento de Rede Elemento de Rede Fonte: Elaborada pelo autor. amento centralizado (centralizado não quer dizer em um único equipamento); Prover uma interface aberta e padronizada para que as aplicações possam controlar algumas propriedades da rede e possam dela se beneficiar; Acelerar a inovação no desenvolvimento de novas aplicações, permitindo que os operadores de redes programem a rede em tempo real conforme a sua aplicação; Centralizar o gerenciamento e o controle dos dispositivos de rede independentemente do seu fabricante. 2.1.1 Arquitetura SDN A arquitetura SDN é dividida em três camadas (ou planos), sendo cada uma delas responsável por funcionalidades específicas. As três camadas são: Camada de Aplicação (Application Layer), Camada de Controle (Control Layer) e Camada de Infraestrutura (Infrastructure Layer), na Figura 1 é apresentado como essas camadas se relacionam e em seguida será explicado o funcionamento de cada uma. A camada de aplicação (ou Application Plane) é onde as aplicações que vão usufruir da rede se encontram. Essas aplicações informam ao controlador os seus requisitos e como esperam que a rede se comporte. É esperado (e recomendado pela ONF) que os controladores possuam uma interface aberta e padronizada, e assim, as aplicações possam enviar informações para o controlador independentemente da marca do equipamento.

Camada de Infraestrutura Camada de Controle Controlador SDN Camada de Aplicação 4 Figura 2 Arquitetura das Redes Definidas por Software Aplicação SDN 1 Lógica da Aplicação SDN Aplicação SDN 2 Lógica da Aplicação SDN Aplicação SDN 3 Lógica da Aplicação SDN NBI Driver NBI Driver NBI Driver SDN Northbound Interface (NBI) Northbound Interface Agent Lógica de Controle SDN Control Data Plane Interface Driver SDN Control Data Plane Interface (CDPI) Elemento de Rede CDPI Agent Elemento de Rede CDPI Agent Elemento de Rede CDPI Agent Processamento e Encaminhamento Processamento e Encaminhamento Processamento e Encaminhamento Fonte: Elaborada pelo autor. A camada que contém a inteligência da rede é a camada de controle (ou Control Plane). É nela que fica localizado o controlador da rede, que tem como principal função executar o plano de controle da rede. Para executar o plano de controle é necessário controlar os outros elementos (como comutadores e roteadores) da rede. Para isso deve ser utilizada uma forma padronizada e independente do fabricante do equipamento. Atualmente na arquitetura SDN a ONF recomenda a utilização do protocolo OpenFlow (OPEN NETWORKING FOUNDATION, 2013a). A camada de infraestrutura (ou Data Plane) é onde o plano de dados é executado e assim é nessa camada que grande parte dos dispositivos da rede se encontram. Esses equipamentos são responsáveis por processar e encaminhar os pacotes conforme forem recebendo instruções do plano de controle. É recomendado também que a comunicação entre o controlador e os equipamentos situados na camada de infraestrutura utilize um padrão aberto (OPEN NETWORKING FOUNDATION, 2013a). 2.1.2 Componentes da Arquitetura SDN A arquitetura SDN apresenta diversos componentes que são distribuídos nas camadas supracitadas. Neste momento serão descritos os principais componentes dessa arquitetura e também mostrar como eles se relacionam. A Figura 2 ilustra como os componentes se relacionam na arquitetura SDN. Para facilitar o entendimento, a Figura 2 é similar à Figura 1, mas agora os componentes e suas relações são apresentadas. O primeiro componente que é identificado no topo da Figura 2 é uma Aplicação SDN (em

5 inglês SDN Application), que basicamente é dividida em duas partes: a primeira delas é uma aplicação que precisa utilizar os recursos da rede; a segunda é chamada de NBI Driver (Northbound Interface), que além de prover uma interface entre a aplicação SDN e o controlador SDN, também provê uma visão abstrata da rede para a aplicação SDN (OPEN NETWORKING FOUNDATION, 2012). O elemento central na arquitetura SDN é o Controlador (em inglês, Controller). É nele que toda a lógica da rede está localizada e centralizada. Apesar do plano de controle estar centralizado no controlador, não significa que ele é composto por apenas um equipamento. O controlador possui uma visão completa da rede e, por ter controle total dos equipamentos que executam o plano de dados, é possível utilizá-lo para aplicar diversas características em uma rede, como por exemplo controle de acesso, qualidade de serviço (em inglês, Quality of Service - QoS), controle de tráfego e outros. O controlador é responsável por traduzir e transferir os requisitos das aplicações SDN para os equipamentos localizados na camada de infraestrutura. Para isso, o controlador é dividido em três partes: Agente NBI (do inglês NBI Agent), SDN Control Logic e o CDPI driver (Control to Data-Plane Interface). O NBI Agent contém a interface para receber as informações das aplicações SDN, o SDN Control Logic é a inteligência da rede e onde o processamento do plano de controle é executado. E por fim, o CDPI driver é a parte responsável por se comunicar com os componentes na camada de infraestrutura (OPEN NETWORKING FOUNDATION, 2013a). Na camada de infraestrutura estão localizados os equipamentos responsáveis por processar e encaminhar os pacotes da rede, onde um ou mais desses equipamentos podem representar um dispositivo lógico da rede, também conhecido como SDN Datapaths, ou de forma mais genérica um NE, Network Element. Essa representação lógica pode abranger todos ou uma parte do substrato da rede. Um SDN Datapath pode ser dividido em duas partes, a primeira é o CDPI Agent responsável pela interface de comunicação com o controlador (normalmente utilizando o protocolo OpenFlow); a segunda é o encaminhamento e processamento de pacotes. 2.1.3 Protocolo OpenFlow O OpenFlow é um dos protocolos de comunicação utilizado entre os elementos situados na camada de controle e os elementos na camada de infraestrutura. De forma geral essa comunicação ocorre entre o controlador da rede e um equipamento que entenda o protocolo Open- Flow, normalmente chamado de OpenFlow Switch. O OpenFlow Switch possui uma interface (a CDPI) chamada OpenFlow Channel que se comunica com o controlador e é através dela que o controlador pode manipular as informações contidas no OpenFlow Switch. O OpenFlow Switch possui alguns termos e elementos específicos. A Figura 3 apresenta a relação entre os seguintes elementos: Flow Entry : Um elemento contido no OpenFlow Switch que especifica uma regra de casamento com pacotes que são direcionados a esse equipamento. Um Flow Entry pode

Camada de Infraestrutura Camada de Controle 6 Figura 3 Arquitetura do OpenFlow Switch Controlador SDN Protocolo OpenFlow OpenFlow Switch Pipeline Flow Table 1 OpenFlow Channel Flow Table 2 Flow Table N Flow Entry 1 Flow Entry 2.. Flow Entry N Flow Entry 1 Flow Entry 2.. Flow Entry N Flow Entry 1 Flow Entry 2.. Flow Entry N Fonte: Elaborada pelo autor. contar com uma série de campos para casar com os pacotes. Flow Table : É a estrutura que normalmente é utilizada para armazenar, organizar e classificar os Flow Entries. Pipeline : É um conjunto de Flow Tables conectadas que provê o casamento, o encaminhamento e as modificações necessárias nos pacotes em um OpenFlow Switch. O OpenFlow Switch utiliza o conceito de identificação de fluxo (flow identity), podendo identificar pacotes utilizando alguns campos já conhecidos, como endereço IP, endereço MAC, porta do TCP e vários outros campos. Após a identificação do pacote (caso o pacote case com algum Flow Entry de alguma Flow Table) é executada uma ação correspondente definida na Flow Table (OPEN NETWORKING FOUNDATION, 2013a). Uma das grandes vantagens apresentadas pela ONF é que uma arquitetura SDN que utiliza o protocolo OpenFlow pode prover um controle bastante granular da rede (com os Flow Entries), permitindo que a rede se adapte de maneira eficiente a alterações em tempo real. 2.2 Domain Name System O DNS (Domain Name System) é um sistema de resolução de nomes organizado de forma hierárquica, delegando a responsabilidade de administração de cada domínio a uma determina instituição (INTERNET ENGINEERING TASK FORCE, 1987). Esse sistema tem como principal característica traduzir um determinado nome fornecido por um usuário para um endereço

7 IP ou vice-versa. Com o tamanho das redes atuais esse serviço é praticamente indispensável e facilita o acesso aos recursos disponíveis na rede. Para informações mais detalhadas sobre o funcionamento do DNS consulte a RFC1034. Esses domínios são divididos basicamente em dos tipos, top-level domain (TLD) e secondlevel domain (SLD). Os top-level domains são mantidos pela IANA (Internet Assigned Numbers Authority) e grande parte desses domínios são de utilização genérica, como com, edu, gov e outros, além de domínios geográficos que referenciam código de países como br (Brasil), jp (Japão), ca (Canada) entre outros. Abaixo dos top-level domains estão os second-level domains. Esses domínios normalmente estão destinados a empresas e organizações. Um exemplo de domínio second-level domain é unisinos.br, logo a universidade UNISINOS possui responsabilidade administrativa por esse domínio, podendo cadastrar novos nomes a ele sem a necessidade de uma autorização externa (INTERNET ENGINEERING TASK FORCE, 1987). 2.2.1 Resolução de Nomes Quando uma resolução de nome é solicitada, primeiramente é necessário encontrar o servidor responsável pelo nome requerido. Após encontrar o servidor responsável pelo domínio, é preciso que esse servidor consulte a sua base de registro para informar o endereço IP do endereço enviado na requisição (INTERNET ENGINEERING TASK FORCE, 1987). Esses registros são chamados de registros de recursos (em inglês, RR - Resource Records) e são compostos por um conjunto de cinco campos apresentados no seguinte formato: < Nomedo-Registro TTL Tipo Classe Dados>. A seguir são apresentadas as definições de cada um dos campos (CRICKET LIU, 2006): Nome do Registro : Nome do domínio que deve ser um nome FQDN (Fully Qualified Domain Name). TTL : Campo Time To Live, esse campo é utilizado para determinar quanto tempo um determinado registro DNS deve ser mantido em cache. Após expirado esse tempo o registro deve ser descartado, e caso seja necessário consultá-lo novamente, deve ser realizada uma nova consulta DNS. Tipo : Existem diversos tipos de registros e cada um deles é utilizado para um recurso específico. Os tipos de registros mais comuns são: A - Tipo de registro mais comum, estabelece o mapeamento entre o nome canônico e o endereço IPv4 de um dispositivo. PTR - Pointer, utilizado para fazer o mapeamento reverso, do endereço IP para o nome. MX - Mail Exchanger, mapeamento para o servidor de email do domínio.

8 NS - Name Server, mapeamento para o endereço do servidor DNS que tem autoridade para responder requisições sobre o domínio. Classe : A classe massivamente utilizada é a classe IN, correspondendo aos protocolos Internet. Dados : Contém os dados do registro. No caso de um registro do tipo "A", vai conter o endereço IP relacionado ao nome. 3 TRABALHOS RELACIONADOS Nesta seção serão apresentados outros trabalhos relacionados a SDN e, após uma pesquisa de diversos trabalhos, os trabalhos descritos nessa seção utilizam conceitos e ideias semelhantes utilizadas neste artigo. A explanação desses trabalhos tem como objetivo fundamentar o presente estudo, assim como mostrar que tipo de pesquisa a comunidade científica vem desenvolvendo com a arquitetura SDN. 3.1 Extending Open vswitch to L4-L7 service aware OpenFlow Switch Este artigo propõe uma metodologia para expandir as funcionalidades de um switch virtual baseada em OpenFlow. A especificação atual dos switches OpenFlow contempla as camadas 2 e 3 no modelo OSI Open Systems Interconnection model. Nesse artigo os autores apresentam uma metodologia para fornecer funcionalidades nas camadas superiores do modelo OSI, abrangendo as camadas de 4 a 7. O método proposto pelos autores é essencialmente dividido em 3 partes: Extensão das ações do Open vswitch Como dito anteriormente o OpenFlow suporta apenas ações referentes às camadas 2 e 3 do modelo OSI, sendo assim é necessário modificar os código do Open vswitch para suportar novas ações. O Open vswitch suporta 2 tipos de Flow Entries, userspace flows (contidos no userspace) e datapath flows ou kernel flows (contidos no kernel space). Caso um determinado pacote não encontre nenhuma ação no kernel space, o pacote é primeiramente encaminhado para o userspace e após processado, será adicionada uma ação no kernel space que possa atendê-lo. Além disso, também é necessária a criação de estruturas que possam suportar as novas ações. Caso essa nova ação gere qualquer alteração ao extrair informações dos pacotes ou na busca por Flow Entries, também é preciso adicionar alterações Open vswitch. Adicionar novas ações ao ovs-ofctl Para adicionar novos Flow Entries é preciso alterar a mensagem responsável por adicionar novos Flow Entries. Para isso, os autores propõem um modulo chamado ovs-ofctl, que será responsável por construir um comando chamado

9 Figura 4 Visão geral no processamento do pipeline Fonte: (GORJA; KURAPATI, 2014) add_flow, que por sua vez constroí a mensagem utilizando o flow_mod (mensagem padrão do OpenFlow). No caso do Open vswitch ainda são necessárias alterações de mais algumas funções, a fim de tornar as mensagens geradas com o add_flow compatíveis com flow_mod. Processamento do Pipeline Este modelo considera que múltiplas aplicações podem estar disponíveis no controlador, como IPSec, Firewall e etc, e os switches OpenFlow só executam ações que são suportadas pelo controlador ao qual estão conectados. A Figura 4 mostra que cada uma das aplicações tem a sua respectiva tabela dentro do Pipeline, sendo assim cada aplicação utiliza e gerencia suas próprias tabelas dentro e ao longo da execução do Pipeline. Caso um pacote não consiga casar com nenhum Flow Entry de uma determinada Flow Table, ele será enviado ao controlador, onde o pacote será encaminhado para a aplicação que possa atendê-lo. 3.2 A Software Defined Networking Architecture for Transport Networks No trabalho desenvolvido por Sadasivarao et al. (2013) é proposta uma arquitetura para abstrair a transferência de dados em switches virtuais programáveis. Nessa solução é utilizado

10 o paradigma de redes definidas por software, enquanto o protocolo OpenFlow é utilizado para realizar o controle dos switches virtuais. Como estudo de caso utilizado pelo artigo é implementado um switch virtual óptico que utiliza o protocolo OpenFlow para gerenciar uma pequena rede óptica de transporte de dados. Para gerenciar essa rede é proposta uma extensão ao protocolo OpenFlow, apresentando como a capacidade de programação e flexibilidade da arquitetura SDN pode resolver alguns problemas que os provedores de serviços enfrentam atualmente no backbone das suas redes. O switch virtual é chamado de OTS (Open Transport Switch) e representa os NE (Network Elements) na arquitetura SDN. Um OTS é composto por três blocos diferentes. São eles: Discovery Agent : É responsável por descobrir e registrar os recursos disponíveis em um controlador SDN, além de notificar o controlador quando o estado de um NE se altera. A descoberta e registro de recursos utilizam respectivamente as mensagens OFPT_FEATURES_REQUEST e OFPT_FEATURES_REPLAY, enquanto uma notificação utiliza uma mensagem Modify State. Control Agent : Responsável por monitorar e propagar notificações e alarmes para o controlador, permitindo que o administrador da rede monitore a rede obtendo uma visão mais completa do seu estado atual. É possível que tanto o Discovery Agent e o Control Agent enviem a mesma notificação ao controlador. Dataplane Agent : Responsável por programar o Network Element, criando, atualizando e removendo Flow Entries das Flow Tables, recebendo do controlador uma mensagem do tipo OFPT_FLOW_MOD. A Figura 5 mostra como a extensibilidade do protocolo OpenFlow é utilizada para provisionar e desfazer os circuitos de rede, e assim, criando redes virtuais que utilizam os parâmetros propostos pelos autores, como: tipo de circuito, taxa de transmissão do serviço e latência. Os autores concluem o artigo dizendo que a virtualização de redes utilizando o OTS permite a construção de redes sobrepostas (overlay network), habilitando as aplicações SDN a programarem a rede conforme a necessidade dos seus serviços independentemente dos protocolos utilizados nas camadas subjacentes. 3.3 Floodless Service Discovery Model based on Software-Defined Network Este artigo apresenta uma abordagem de descoberta de serviço que utiliza redes definidas por software com o objetivo de diminuir o broadcast em redes ethernet. O trabalho destaca que os principais motivos para evitar o broadcast em redes ethernet são: A utilização de broadcast consome uma parte significante dos recursos de uma rede;

11 Figura 5 Extensão do protocolo OpenFlow utilizada pelo OTS struct ofp_id { // Host ID - IP Address of the Node uint32_t node; // Flow ID maintained by the Controller uintt32_t label; }; struct ofp_xconn { struct ofp_header header; // OFPT_VENDOR uint32_t vendor; // Vendor ID uint8_t pad[4]; struct ofp_id src; // Source of the flow struct ofp_id dst; // Destination of the flow uint32_t rate; // Rate of service (Mpbs) uint8_t latency; //Latency - 0 to 255 // Unidirectional 1 Bidirectional = 2 uint8_t directional; uint8_t pad_extra[1]; // ADD_XCONN = 0xFF REM_XCONN = 0xFE struct ofp_action_header actions[0]; }; OFP_ASSERT(sizeof(struct ofp_xconn) == 40); Fonte: (WANG et al., 2013) O protocolo STP (Spanning Tree Protocol) é utilizado em redes ethernet para evitar loops na rede. Entretanto, o grande volume de tráfego próximo do nó raiz da árvore STP aumenta a chance de recálculo no protocolo Spanning Tree; Qualquer equipamento conectado à rede pode adquirir informações dos outros equipamentos utilizando broadcast, o que pode acarretar em problemas de segurança. Em especial sobre o primeiro item citado, o artigo utiliza como referência um relatório da Cisco que recomenda o tamanho máximo de um domínio broadcast dependendo dos protocolos utilizados na rede. O relatório recomenda que o número máximo de hosts em um rede IP deve ser de 500, enquanto que em redes que utilizam os protocolos NetBIOS ou AppleTalk o número máximo recomendado de hosts é de 200. De acordo com o artigo, os protocolos ARP (Address Resolution Protocol) e DHCP (Dynamic Host Configuration Protocol) são as maiores fontes de broadcast em uma rede ethernet. E por essa razão foram desenvolvidos dois componentes (ARP e DHCP) para tratar os pacotes broadcast gerados por esses protocolos. Seguindo a proposta de reduzir o broadcast na rede, as mensagens DHCP_DISCOVERY são direcionadas para o controlador através do secure channel. Em seguida, ao receber o pacote o componente DHCP é acionado e a partir desse momento o componente se comporta como um servidor DHCP tradicional, como é exibido no fluxograma completo na Figura 6. Assim como o componente DHCP, o componente ARP recebe as mensagens que teriam como destino o endereço broadcast da rede. A Figura 7 ilustra como o componente ARP realiza um trabalho similar de aprendizagem de endereços MAC assim como um switch ethernet. Os autores concluem o artigo esclarecendo os motivos da baixa escalabilidade em redes ethernet. E assim, propõem o FSDM baseado em uma arquitetura SDN para resolver o pro-

12 Figura 6 FSDM: Componente DHCP Fonte: (WANG et al., 2013) Figura 7 FSDM: Componente ARP Fonte: (WANG et al., 2013)

13 blema de escalabilidade, eliminando o flooding na rede. Como último item, é apresentado um modelo matemático que comprova a eficiência do FSDM, mostrando comparações entre uma rede ethernet tradicional e uma rede que utiliza o FSDM. 3.3.1 Conclusão dos Trabalhos Relacionados No cômputo geral, os trabalhos selecionados apresentaram métodos de estender o protocolo OpenFlow, assim como a utilização de arquitetura SDN em conjunto com outros protocolos. O trabalho de Gorja e Kurapati (2014) mostra uma metodologia para expandir as funcionalidades de um OpenFlow Switch com o objetivo de atender diferentes camadas do modelo OSI. Além disso, o trabalho de Wang et al. (2013) mostra como é possível integrar a arquitetura SDN com os protocolos já existentes em redes de computadores tradicionais, trazendo assim melhorias e novas funcionalidades à rede como um todo. Nas próximas seções são utilizadas as ideias e conceitos extraídos desses trabalhos para apresentar um sistema de cache de consultas DNS. 4 SOLUÇÃO PROPOSTA Nesta seção são utilizados os conceitos de redes definidas por software e DNS com o propósito de desenvolver uma arquitetura que realize cache de consultas DNS nos switches OpenFlow. A solução proposta foi batizada de ONSc - OpenFlow Name System cache. Nas seções seguintes serão apresentadas a sua arquitetura e os comportamentos que essa solução pode adotar e também o que é necessário estender na arquitetura SDN para implementá-la. 4.1 Visão Geral O ONSc propõe uma solução que deve ser capaz de receber as requisições DNS e armazenálas em um cache nos switches OpenFlow. O cache existente nos switches irá conter o resultado de consultas DNS previamente realizadas e, por está razão, é necessário estender alguns elementos na arquitetura SDN. As informações armazenadas no cache dos switches OpenFlow serão utilizadas pelos clientes da rede que enviarem uma requisição DNS que chega ao switch. Quando as informações contidas no cache dos switches forem utilizadas, é esperado uma redução no volume de tráfego DNS existente na rede e também uma resposta mais rápida a informação solicitada. 4.2 Arquitetura A arquitetura ONSc é dividida entre as camadas da arquitetura SDN, o servidor DNS e a extensão proposta para alguns elementos SDN. Assim como a arquitetura SDN, a arquitetura

14 do ONSc divide os elementos nas camadas de aplicação, controle e infraestrutura, além de um elemento externo que é o servidor DNS. Apesar do ONSc poder trabalhar em dois comportamentos diferentes, ambos tem como objetivo realizar o cache de consultas DNS. Uma consulta DNS é adicionada como um Flow Entry no switch OpenFlow, assim esse Flow Entry representa o cache da solução. Grande parte da solução ONSc fica localizada no controlador, que por sua vez deve ser capaz de manipular Flow Entries nos switches OpenFlow. A seguir são descritos os 4 elementos que fazem parte da arquitetura ONSc, e em seguida, na Figura 8, é apresentado como esses elementos se relacionam entre si. NS Cache Switch : O NS Cache Switch ou NS-CS é um switch OpenFlow com as extensões necessárias para realizar o casamento dos campos do protocolo DNS. NS Cache Controller : O NS Cache Controller ou NS-CC é um controlador OpenFlow com as extensões necessárias para suportar os novos campos do protocolo DNS. É no NS-CC que as decisões de quais requisições DNS devem ser armazenadas em cache, enviando ao NS-CS mensagens para manipular os Flow Entries. DNS Server : É o servidor DNS disponível na rede. Apesar de ser um elemento que não sofre nenhuma alteração na arquitetura ONSc, ele é indispensável para o funcionamento da solução em seu formato tradicional. NS Cache Manager : O NS Cache Manager ou NS-CM é uma aplicação SDN que interage com o controlador. Essa aplicação pode armazenar informações em uma base de dados com informações sobre a utilização do serviço de DNS. De posse destas informações o administrador da rede pode decidir qual o comportamento mais adequado para o funcionamento do ONSc. Assim como grande parte das soluções que utilizam o modelo SDN, o funcionamento do ONSc está dividido nas três camadas da arquitetura SDN. A comunicação entre o NS-CC e o NS-CS é realizada utilizando o protocolo OpenFlow, enquanto a comunicação entre a o NS- CM e o NS-CC deve utilizar uma API (Application Programming Interface) que ainda não é padronizada pela ONF, e que depende da implementação do NBI Driver utilizado na camada de aplicação e do NBI Agent disponível na camada de controle. Antes de detalhar o funcionamento da solução em si, é importante destacar dois pontos. O primeiro que deve ser levado em consideração é que todos os switches utilizados nessa solução já possuem a capacidade de aprendizagem na camada 2, ou seja, funcionam da mesma forma que um switch tradicional em relação à identificação de endereços na camada 2. O segundo ponto é relacionado ao comportamento padrão do protocolo OpenFlow, quando um Flow Entry é adicionado a um switch OpenFlow, o valor do campo idle_timeout é 60 segundos. Entretanto, para todas as mensagens do tipo ofp_flow_mod cujo objetivo é adicionar uma entrada com informação de cache DNS, o valor campo idle_timeout deve

Camada de Infraestrutura Camada de Controle Camada de Aplicação 15 Figura 8 Arquitetura ONSc (OpenFlow Name System cache) NS-CM Name System Cache Manager NS-CM SDN Northbound Interface (NBI) NS-CC Name System Cache Controller DNS NS-CC Troca de mensagens OpenFlow NS-CS Name System Cache Switch DNS Server DNS NS-CS NS-CS NS-CS Tráfego TCP/IP Tradicional Fonte: Elaborada pelo autor. ser igual ao valor do TTL da requisição DNS e não deve ser possível que esse campo seja atualizado pelo OpenFlow (utilizando o campo hard_timeout). 4.3 Extensão do protocolo OpenFlow Como dito anteriormente, a arquitetura SDN atua principalmente nas camadas dois e três do modelo OSI, abrangendo grande parte dos protocolos residentes nessas camadas. Entretanto, como a solução ONSc tem como principal função realizar cache de requisições DNS, é preciso estender a arquitetura SDN para suportar as particularidades desse protocolo. A extensibilidade dos elementos é um dos diferenciais da arquitetura SDN, e na ONF (Open Network Foundaton) existe um grupo de trabalho exclusivo nessa área (Extensibility Working Group). No momento da escrita desse artigo, esse grupo de trabalho dividiu a extensibilidade em doze partes: Flow Entry Notifications, Role Status, Flow Entry Eviction, Vacancy Events, Bundle, Table Synchronisation, Group Notifcations, Bad Flow Entry Priority Error, Set Async Config Error, PBB UCA Header Field, Duplicate Instruction Error e Multipart Timeout Errors (OPEN NETWORKING FOUNDATION, 2013b). Apesar dos vários pontos da arquitetura que podem ser estendidos para a implementação da solução, apenas os seguintes campos precisão ser estendidos: Flow Entry Notifications Extension e PBB UCA Header Field Extension. O Flow Entry Notifications Extension permite ao controlador monitorar alterações nas Flow Tables (OPEN NETWORKING FOUNDATION, 2013c), enquanto o PBB UCA Header Field Extension é responsável por prover novos campos para casamento (OPEN NETWORKING FOUNDATION, 2013d). A Figura 9 mostra um modelo de estrutura utilizando o OXM (OpenFlow Extensible Match). Essa estrutura tem como objetivo mapear os campos existentes em um registro de DNS a fim

16 Figura 9 Estrutura OXM para o protocolo DNS struct ofp_id { // Endereco IP do host. Campo de 4 bytes. uint32_t node_address; // Flow ID mantido pelo controlador. Campo de 4 bytes. uint32_t flow_id; }; struct ofp_xdns { // Cabecalho do OpenFlow Protocol. Campo de 8 bytes. struct ofp_header header; // Identificacao do vendor. Campo de 4 bytes. uint32_t vendor; // Origem do Flow. Campo de 8 bytes. struct ofp_id flow_source; // Destino do Flow. Campo de 8 bytes. struct ofp_id flow_destination; // Campo "Name" de um RR. Campo de 256 bytes. char[256] resource_name; // Campo "TTL" de um RR. Campo de 4 bytes. uint32_t resource_ttl; // Campo "Type" de um RR. Campo de 2 bytes. uint16_t resource_type; // Campo "Class" de um RR. Campo de 2 bytes. uint16_t resource_class; // Campo "RData"de um RR. Campo de 4 bytes. uint32_t resource_data; }; // Testa se a struct montada anteriormente tem 304 bytes. OFP_ASSERT(sizeof(struct ofp_xdns) == 304); Fonte: Elaborada pelo autor. de permitir a usabilidade e casamento desses campos. 4.4 Funcionamento Antes de iniciar a descrição do funcionamento dessa solução, é relevante citar que ela pode funcionar com dois comportamentos diferentes. Independente do comportamento da solução, não é necessária a inclusão ou remoção de nenhum dos componentes da arquitetura citada na seção anterior. Os dois comportamentos suportados pela solução são: Comportamento Adaptativo e Comportamento Proativo. Apesar dos comportamentos apresentarem modos diferentes de funcionamento, ambos têm como objetivo realizar cache de requisições DNS. Cada comportamento apresenta as suas vantagens e desvantagens, levando em conta fatores como o número de mensagens de controle, latência introduzida na utilização do serviço, quantidade de requisições DNS atendidas pelo cache e outros. Além disso, essa arquitetura possibilita também um sistema de cache distribuído e hierarquizado, pois caso a resposta da requisição DNS não seja encontrada no primeiro switch é possível que ao longo do caminho outro switch já possua essa resposta em cache.

17 4.4.1 Comportamento Adaptativo O comportamento adaptativo tem funcionamento similar às redes reativas. Esse tipo de rede age de acordo com os eventos e acontecimentos que ocorrem na rede. Assim que um determinado evento ocorre, é possível que uma ação correspondente seja realizada. De uma forma geral redes reativas tendem a se adaptar às necessidades aparentes da rede, mas esse tempo de adaptação muitas vezes não é desejável (ou é difícil de se alcançar) para certa classe de aplicações. Quando aplicamos o conceito de comportamento adaptativo no ONSc temos uma solução que inicialmente não atende a nenhuma requisição DNS utilizando cache, pois o cache dos switches está vazio. Entretanto, conforme as requisições DNS são respondidas pelo servidor, os switches começam a armazenar essas respostas no cache das respostas que passam por ele. A Figura 10 exibe como é o funcionamento do ONSc quando trabalha no modo adaptativo. 1. Host01 : Envia requisição DNS para o SW01; 2. SW01 : Recebe requisição DNS de Host01. Como não possui regra para a porta 53 UDP (User Datagram Protocol), encaminha o pacote para o Controller01; 3. Controller01 : Recebe o pacote de SW01. Nesse ponto o controlador deve enviar duas mensagens ofp_flow_mod e uma mensagem ofp_packet_out ao SW01: Mensagem 1: Adiciona um Flow Entry com a regra de casamento: porta de destino 53 do protocolo UDP, e ação de encaminhar pacotes para o endereço IP do servidor DNS; Mensagem 2: Adiciona um Flow Entry com a regra de casamento: porta de origem 53 do protocolo UDP e endereço IP do servidor DNS como origem, e ação de encaminhar pacotes para o controlador; Mensagem 3: Envia uma mensagem ofp_packet_out com o objetivo de informar o switch OpenFlow que deve encaminhar o pacote por uma determinada porta; 4. SW01 : Recebe mensagens ofp_flow_mod. Encaminha pacote para o servidor DNS; 5. DNS01 : Recebe pacote de requisição DNS. Responde a requisição DNS; 6. SW01 : Recebe a resposta da requisição DNS. De acordo com o Flow Entry adicionado anteriormente, encaminha o pacote para o Controller01, e por aprendizado (de camada 2) encaminha o Host01; 7. Controller01 : Recebe resposta da requisição DNS. Envia uma mensagem ofp_flow_mod para adicionar um Flow Entry ao SW01, com o objetivo de criar um cache da resposta da requisição DNS. A regra de casamento adicionada é construída com os seis campos de uma resposta de requisição DNS: Name, Type, Class, Time to live, Data length e Addr.

18 Figura 10 Comportamento Adaptativo do ONSc DNS01 Controller01 3 2 SW01 1 Host01 Host01 Controller01 SW01 Host01: Cliente do DNS Controller01: Name System Cache Controller SW01: Name System Cache Switch 3 DNS01: DNS Server 3 4 DNS01 Tráfego TCP/IP Tradicional 5 Tráfego OpenFlow 6 6 7 Fonte: Elaborada pelo autor. 4.4.2 Comportamento Proativo No comportamento proativo a rede é configurada previamente pelo administrador, antes ou durante a utilização da mesma pelos clientes da rede. O importante nesse conceito é que a rede não se autoconfigura, ou seja, é necessária uma configuração manual para que a mesma funcione de forma adequada. Na arquitetura ONSc o funcionamento proativo pode ser observado nos passos listados a seguir e na Figura 11. Inicialmente o NS-CM envia ao NS-CC uma lista de quais endereços que devem ser armazenados no cache dos switches, e assim, o NS-CC realiza a instalação dos Flow Entries nos NS-CS. Logo, quando um cliente iniciar uma requisição DNS ela será respondida pelo primeiro switch que possua a sua resposta no cache. 1. Manager01 : Envia ao Controller01 as informações de configuração que cada switch deve receber, neste caso, quais Flow Entries devem ser enviados para cada switch; 2. Controller01 : Envia n+1 mensagens ofp_flow_mod ao SW01, onde n é o número de Flow Entries que devem ser utilizados como entradas de cache, e uma mensagem Flow Entry com a regra de casamento: porta de destino 53 do protocolo UDP, e ação de encaminhar pacotes para o endereço IP do servidor DNS; 3. Host01 : Envia requisição DNS para o SW01;

19 Figura 11 Comportamento Proativo do ONSc Manager01 1 DNS01 Controller01 2 2 2 2 SW01 Host01 Host01 Controller01 SW01 Host01: Cliente do DNS Manager01: Name System Cache Manager Manager01 Controller01: Name System Cache Controller SW01: Name System Cache Switch 4 4 4 3 4 DNS01: DNS Server 5 DNS01 Tráfego TCP/IP Tradicional 6 Tráfego OpenFlow Requisição atendida 4 Condição do passo 4 Fonte: Elaborada pelo autor. 4. SW01 : Recebe requisição DNS de Host01. Caso a resposta da requisição já esteja em cache, envia a resposta ao Host01 e a requisição foi atendida. Caso contrário, encaminha o pacote para para o servidor DNS conforme regra de casamento adicionada no passo 2; 5. DNS01 : Recebe pacote de requisição DNS. Responde a requisição DNS; 6. SW01 : Recebe a resposta da requisição DNS. Por aprendizado (de camada 2) encaminha a resposta da requisição para o Host01. 5 EXPERIMENTOS REALIZAD1OS Nesta seção são apresentados como os experimentos e simulações com a solução proposta foram realizados. As interações que aparecem no ONSc foram simuladas utilizando ferramentas disponíveis na plataforma Linux, como o tcpdump, dig e outras. Além disso, também foi utilizado o simulador Mininet (MININET, 2014) para realizar as operações que envolviam a arquitetura DNS e o protocolo OpenFlow. Durante a elaboração da proposta deste projeto foi realizada uma pesquisa para verificar a viabilidade de implementação das extensões propostas para o ONSc. O resultado dessa, revelou que havia uma forma singela e claramente documentada para realizar a implementação. Entretanto, ao longo da escrita do artigo diversas tentativas foram realizadas, porém as implementações de switches OpenFlow disponíveis, como o user-space do Mininet e o Open

20 Figura 12 Topologia da Rede Ponto de Coleta 1 Interface 1 do Roteador 1 Todo o tráfego Ponto de Coleta 2 Interface 1 do Roteador 1 Tráfego DNS Internet Rede - 10.10.8.0/24 Máquina Cliente x50 Rede 10.10.0.0/16 Rede - 10.10.100.0/24 Rede - 10.10.9.0/24 Máquina Cliente x50 Roteador 1 Servidores NFS Rede - 10.10.10.0/24 Máquina Cliente x30 Servidor DNS Rede - 10.10.200.0/24 Servidores HTTP DMZ x10 Fonte: Elaborada pelo autor. vswitch (OPEN VSWITCH, 2014), não implementam o conjunto completo de extensões documentado. Devido a impossibilidade de implementar as extensões nos ambientes testados, os autores optaram por realizar os experimentos e simulações descritos nesta seção com o objetivo de validar a solução proposta neste artigo. 5.1 Coleta de Dados Com o objetivo de coletar dados para o artigo foi realizada uma captura de dados que possa trazer informações relevantes para o desenvolvimento deste trabalho. Durante o período de 32 dias (de 11/09/2014 até 13/10/2014) foram realizados 2 tipos de coletas na rede apresentada na Figura 12. A rede escolhida está localizada dentro de uma universidade, porém por fazer parte de um projeto do governo federal distribuído em outras universidades do país, essa rede em particular possui características de uma rede corporativa. A rede apresentada possui uma variedade de serviços disponíveis, como servidores NFS(Network File System), servidor DNS, servidores HTTP (Hypertext Transfer Protocol) e outros serviços. Contando também com aproximadamente 130 máquinas clientes e servidores na DMZ (demilitarized zone) que utilizam essa infraestrutura. Além disso, podemos visualizar na topologia que foram definidos 2 pontos de coletas de dados, abaixo descrevemos cada tipo de coleta realizada: Ponto de Coleta 1 : Total de tráfego na interface 1 do Roteador1. Esse ponto de coleta foi selecionado pois permite capturar todo o tráfego da rede, garantindo assim que nenhuma