Etapa 3 – Simulações e Análise dos Resultados A) Montagem dos ambientes de testes:
3 PONTO DE TROCA DE TRÁFEGO
Os pontos de troca de tráfego, também conhecidos como PTT, foram criados para a troca de tráfego sem fins lucrativos entre seus participantes (GETSCHKO, 2002).
Em 1986 surgiu a NFSNet (National Science Foundation Network) com cinco centros de supercomputação da NFS. A NFS se tornou o primeiro backbone Internet de porte, conectando diversas redes regionais.
Primariamente, a Internet era formada por grandes 4 backbones sendo:
MILNET (1984) – Data Defense Network;
NFSNet (1986) – National Science Foundation Network;
NSI (1986) – Nasa Sciense Internet;
ESNet (1988) – Energy Science Network.
A interligação destes quatro backbones norte-americanos ocorre em dois pontos específicos:
FIX-E – Federal Internet Exchange East em Maryland no College Park;
FIX-W – Federal Internet Exchange West em Mountain View no Moffet Field,
centro da NASA (National Aeronautics and Space Administration);
Sendo assim, em Junho de 1989 constituíram-se os primeiros pontos de troca de tráfego oficiais da Internet.
Conforme GETSCHKO (2002) em 1990, houve um crescimento de tráfego não acadêmico na Internet, gerando a necessidade de criar um ponto de troca de tráfego comercial. Desta forma, a CERFNet, PSINet e AlterNet criaram em Santa Clara na Califórnia a organização sem fins lucrativos para operar o CIX (Commercial Internet
Exchange).
O CIX foi o primeiro ponto de troca de tráfego aberto, sem restrições quanto a natureza do tráfego.
No Brasil, o primeiro PTT multilateral apareceu em 1996, com o PTT na ANSP/FAPESP, oriundos da área acadêmica, bem como o PTT bilateral entre a RNP e Embratel (GETSCHKO, 2002).
O ponto de troca de tráfego brasileiro é gerido pelo CGI (Comitê Gestor da Internet no Brasil). Sua missão é promover a troca de tráfego entre redes que compõem a Internet Brasileira.
Segundo PTT (2012) uma das vantagens do ponto de troca de tráfego, é permitir que o tráfego percorra um menor caminho dentro da Internet, proporcionando melhor desempenho e qualidade de serviço para o tráfego.
O PTT brasileiro gerido pelo CGI é chamado de PTTMetro (Ponto de Troca de Tráfego Metro), que é uma rede metropolitana com fins comerciais e acadêmicos com gerência centralizada.
O PTTMetro gerido pelo CGI, está presente em 20 localidades espalhadas no Brasil.
Pode-se observar na Figura 2 as localidades geográficas:
Figura 2 – Pontos de Presença dos PTT’s brasileiros
Para obter a referência do volume de tráfego tratado pelo PTTMetro, foram consultados os gráficos fornecidos no site do PTTMetro.
A Figura 3 mostra o tráfego agregado tratado por cada um dos PTT’s:
Figura 3 – Tráfego agregado dos PTT’s brasileiros – PTTMetro
Fonte: PTT (2012)
Os dados do gráfico acima foram atualizados em 11/11/2012 às 12:35h.
Dentre os pontos de presença visualizados acima, após avaliarmos o tráfego agregado de utilização dos PTT’s, pode-se observar que a localidade com maior volume de tráfego é o de São Paulo, portanto, para avaliarmos o histórico e volumetria de dados, usaremos o PTT citado.
A Figura 4 apresenta o gráfico anual com a amostragem mensal do volume de dados tratado pelo PTT Metro São Paulo.
Figura 4 – Histórico de tráfego mensal (gráfico anual) – PTTMetro São Paulo
Fonte: PTT (2012)
Os dados do gráfico acima foram atualizados em 11/11/2012 às 12:35h.
Ao longo de um ano, podemos observar um crescimento aproximado de 135% na utilização deste PTT, sendo que o tráfego em Outubro de 2011 era aproximadamente 30Gbps/s subindo para cerca de 70Gbps/s no mesmo período em 2012.
Na Figura 5 é apresentado o gráfico decenal com a amostragem anual do volume de dados tratado pelo PTTMetro São Paulo.
Figura 5 – Histórico de tráfego anual (gráfico decenal) – PTTMetro São Paulo
Fonte: PTT (2012)
Com base nos dados gráficos da Figura 5, ao longo dos anos, pode-se observar uma considerável evolução da quantidade de tráfego. Isso significa que o uso de aplicações na Internet e o uso do PTT está aumentando. Ao comparar o ano de 2008 com o ano de 2012, notaremos um aumento de 3.300% na utilização do PTTMetro São Paulo, sendo que em 2008 o tráfego médio era de 2Gbps/s e em 2012 o tráfego médio é de 67Gbps/s.
Observado a quantidade de tráfego e histórico nos gráficos acima, o PTT mostra-se um ponto viável de mostra-ser estudado e explorado para o objetivo desta dismostra-sertação.
O trabalho de SOUSA (2009) usa o PTT como meio de troca de tráfego entre Sistemas Autônomos para a priorização de aplicações sensíveis a latência. Em seu estudo, ele usa os jogos para demonstrar como o PTT pode atuar minimizando o número de saltos na Internet e otimizar os parâmetros de qualidade como latência, variação da latência e perda de pacotes.
Estudando a estrutura interna de encaminhamento de tráfego do PTTMetro segundo REIS (2010), observa-se uma peculiaridade em relação à implementação do OpenFlow neste ambiente, sendo seu encaminhamento de dados feito todo em camada 2 através de switches.
Na Figura 6 é apresentada a concepção básica de interconexão dos provedores de serviços com um determinado PTT.
Figura 6 – PTT – Modelo Switch Único – Matrix de Comutação
Fonte: REIS (2010)
Na Figura 7, pode-se ver a concepção básica de interconexão de provedores de serviços utilizando o modelo PTTMetro, modelo em que os switches podem pertencer a um único sítio ou serem remotamente conectados.
Seguindo a concepção de interconexão do modelo para PTT, o PTTMetro foi projetado atendendo a topologia Figura 7, notando-se o acesso feito em camadas, constituído de camada de acesso e camada central. Esta estrutura também é conhecida como IXP (Internet Exchange Point).
Figura 7 – PTT – Modelo Rede Metro Ethernet – Matrix de Comutação
Fonte: REIS (2010)
De acordo com REIS (2010), sem a utilização dos pontos de troca de tráfego na Internet, os dados são encaminhados obedecendo a política de roteamento existente na Internet através do protocolo BGP.
Segundo WHITE (2008), o protocolo BGP é baseado no algoritmo Path Vector e a computação do melhor caminho é realizada através da avaliação de vários atributos como Local Preference, AS_PATH, ORIGIN, origem da rota, Interna ou Externa ao Sistema Autônomo, MED e métrica do prefixo entre outros atributos, porém, dentro da ordem de seleção de prefixos, menos significantes.
A Figura 8, mostra o fluxo de dados na Internet sem o uso de um PTT.
Percebe-se que para que o AS B alcance o AS C, é necessário cruzar o ISP A, outros Sistemas Autônomos na Internet, chegar no ISP A e então ao AS C.
Figura 8 – PTT Regional – Comunicação entre AS’s sem PTT
Fonte: REIS (2010)
Quando existe a presença de um PTT conforme mostrado na Figura 9, o fluxo de dados é encaminhado ao PTT alcançando o AS destino com menos saltos percorrendo um menor caminho entre a origem AS B e o destino AS C.
Desta forma, segundo REIS (2010), é possível diminuir a latência de transmissão, o custo e aumentar a qualidade, pois evita passar por Sistemas Autônomos intermediários.
Figura 9 – PTT Regional – Comunicação entre AS’s com PTT
Fonte: REIS (2010)
Outra entidade que provê recursos de ponto de troca de tráfego no Brasil é a RNP (Rede Nacional de Pesquisas), porém está fora do escopo de estudo desta dissertação.
4 OPENFLOW
O OpenFlow, é um padrão criado por pesquisadores da Universidade de Stanford, que foi concebido inicialmente para eliminar as deficiências encontradas na realização de novos testes de protocolos, arquiteturas e outros experimentos, uma vez não terem um ambiente real que pudesse fornecer a confiabilidade e as características de uma rede de dados real de produção (MCKEOWN et al., 2011).
O OpenFlow propõe um modelo de compartilhamento de switches já existentes em uma rede de computadores, permitindo que as aplicações que estejam em funcionamento continuem funcionais, adicionando a possibilidade de realizar testes necessários em tais switches com novas aplicações através do compartilhamento de recursos (MCKEOWN et al., 2008).
O modelo descrito no OpenFlow, permite realizar a separação do plano de controle com o plano de dados, tornando os elementos de rede simples equipamentos comutadores de pacotes, tendo como unidade de controle, um servidor ou dispositivo externo, denominado Controlador OpenFlow, que é responsável por todas as funções de inteligência do switch (MCKEOWN et al., 2011).
A Figura 10 ilustra o fluxo de comunicação entre os elementos do OpenFlow.
Figura 10 – Arquitetura do OpenFlow
Assim como o OpenFlow, existem outros padrões como o Forwarding and
Control Element Separation (ForCES) no qual DORIA et al. (2010) descreve o
protocolo de comunicação para padronização das mensagens entre o plano de controle e o plano de dados através de linguagem XML (eXtensible Markup
Language).
A proposta de separação do plano de controle e do plano de dados foi apresentada por YANG (2004), que descreve a arquitetura entre estes planos e posteriormente teve a padronização do protocolo e mensagens conforme (DORIA et al., 2010).
Porém ao analisar as propostas de YANG (2004) e DORIA et al. (2010), elas se mostram limitadas devido a suportarem somente o tráfego IPv4 e IPv6, não sendo extensíveis a outros protocolos e endereçamentos de camadas 2 e 4, bem como aplicações MPLS, VPN, etc.
HARES (2012) descreve em seu trabalho as diferenças entre os padrões OpenFlow e ForCES que por não ser o foco desta dissertação, não será explorado.
O OpenFlow segue o conceito de uma rede de computadores programável, no qual os elementos desta rede podem responder ao protocolo OpenFlow e armazenar tabelas de fluxos, controladas através de um controlador OpenFlow.
Serão apresentados a seguir a descrição dos elementos pertencentes ao OpenFlow, segundo OFN (2012a) e outros trabalhos referenciados.
4.1 Componentes do Switch OpenFlow
Segundo OFN (2012a), um switch OpenFlow é composto por uma ou mais tabelas de fluxo ou flow tables ou um grupo de tabelas ou group table que realizam pesquisas e encaminhamento, e um canal OpenFlow para um controlador externo conforme a Figura 11.
Figura 11 – Switch OpenFlow
Fonte: OFN (2012a)
O Controlador gerencia o switch via o protocolo OpenFlow. Com o uso deste protocolo, o controlador pode adicionar, atualizar e apagar as entradas de fluxos.
O critério de busca inicia na primeira tabela e pode continuar para as tabelas adicionais. As entradas de fluxos são eleitas pela ordem de prioridade. Caso uma entrada seja encontrada, a instrução associada com o fluxo específico é executada. Caso a entrada não seja encontrada, a saída depende da configuração do switch que pode encaminhar o pacote para o controlador através do canal seguro, descartar ou ainda continuar com a leitura da próxima tabela de fluxo. OFN (2012a)
Conforme descrito em OFN (2012a), instruções associadas a cada entrada de fluxo descrevem o encaminhamento de pacotes, modificação de pacotes, processamento de tabelas de grupo ou processamento em pilha.
4.1.1 Tabela de fluxos
Segundo OFN (2012a), a tabela de fluxos armazena regras, ações e contadores que são associados a determinado fluxo.
Tais regras são criadas através da n tuple que são constituídas dos campos de cabeçalho de cada pacote, de acordo com o suporte de campos e protocolos que cada versão do OpenFlow implementa.
A todo fluxo é associada uma ação que indica como ele deve ser processado. A Figura 12 demostra como o fluxo é processado:
Figura 12 – Fluxograma do fluxo de pacotes dentro de um switch OpenFlow
Fonte: OFN (2012a)
Desta forma é permitido, através de regras de classificação de dados baseados em diferentes atributos dos protocolos IP (Internet Protocol), bem como de camadas superiores como os protocolos TCP (Transmition Control Protocol) e UDP (User
Datagram Protocol) no controlador OpenFlow, selecionar o tipo de tráfego desejado
encaminhando-o para determinada interface de saída no switch. Seguindo o modelo usado na camada 2 (Link Layer) pelos switches, que selecionam o tráfego baseado em endereços MAC (Medium Access Control) de origem / destino, forma-se assim um fluxo. Este fluxo pode ser compartilhado com outro tráfego entrante no switch de rede que tenha como destino o mesmo caminho e switch de rede (MCKEOWN et al., 2011).
4.1.2 Canal de Comunicação
Segundo OFN (2012a), todas as comunicações entre o controlador e o switch devem ser realizadas através de um canal seguro sob conexão TCP (Transmission
Control Protocol) e usualmente encriptado através do TLS (Transport Layer Security).
Através deste canal, o controlador configura e gerencia o switch, recebe eventos do switch e envia pacotes para o switch.
4.1.3 O Protocolo
Conforme descrito em OFN (2012a), o protocolo OpenFlow suporta três tipos de mensagens com seus respectivos sub tipos, sendo:
Controller-to-switch: são mensagens iniciadas pelo controlador e podem ou não requerer uma resposta do switch.
o Sub tipos: Features, Configuration, Modify-State, Read-State,
Packet-Out e Barrier.
Asynchronous: são mensagens enviadas pelo switch ao controlador sem serem solicitadas. O switch envia mensagens Asynchronoµs para o controlador;
o Sub tipos: Packet In, Flow Removed, Port Statµs e Error.
Symmetric: são mensagens enviadas em qualquer direção sem requisição de um dos lados;
o Sub tipos: Hello, Echo e Experimenter
4.1.4 Controlador
O Controlador OpenFlow é responsável por programar as tabelas de fluxos nos
switches da rede através do canal seguro TCP/TLS, através do protocolo OpenFlow
(MCKEOWN, et al., 2011).
O controlador exerce a função de abstração da rede e atua como o Sistema Operacional (SO) da rede.
A parte principal da implementação do OpenFlow é sem dúvidas o controlador, elemento responsável por programar as decisões a serem tomadas na rede.
Conforme GUDLA (2010), desta forma, pesquisadores e/ou fabricantes podem criar/alterar protocolos e arquiteturas sem a necessidade de realizar alterações no plano de dados.
Um dos controladores utilizados é o controlador NOX e todas as aplicações funcionam sobre o Sistema Operacional, facilitando e permitindo novos desenvolvimentos sem alterações nas demais camadas, como o plano de dados.
O controlador realiza as funções da CPU (Central Processing Unit) de um switch convencional.
4.2 Funcionamento
Para MCKEOWN et al. (2008) quando um pacote chega em um elemento de rede com suporte ao OpenFlow, ou, OpenFlow Aware, os cabeçalhos dos pacotes são comparados com as tabelas de fluxos carregadas no elemento, os contadores são incrementados para manter o estado atualizado do número de fluxos que são recebidos em um determinado fluxo. Após isso as devidas ações são tomadas com os pacotes.
Caso não haja nenhuma tabela correspondente, o pacote é encaminhado por completo ao controlador OpenFlow. Como alternativa, apenas o cabeçalho pode ser enviado ao controlador, mantendo no elemento o restante do pacote em sua memória. Para OFN (2012a), em geral quando um pacote atinge o controlador, trata-se de um novo pacote, não possuindo nenhuma correspondência na tabela de fluxos. Ainda pode ser criada uma regra específica para que determinados tipos de pacotes sejam sempre enviados ao controlador.
Segundo MCKEOWN et al. (2008), o pacote pode sofrer determinadas ações previstas para seu processamento como:
Encaminhar o fluxo de pacotes para uma determinada porta (programável); Alterar informações dos campos do cabeçalho;
Encapsular e transmitir para o controlador; Descartar dados;
Encaminhar o pacote para a pilha de processamento convencional do equipamento (não OpenFlow).
Devido a tais características, é possível fazer com que o tráfego crítico em estudo nesta dissertação seja tratado de tal forma que não interfira nos demais tráfegos de rede, considerados tráfegos não críticos.
Na Tabela 1 é apresentada a forma como um switch OpenFlow trata os pacotes que chegam no equipamento:
Tabela 1 – Exemplo de tabela de fluxo de um switch OpenFlow
MAC src MAC dst IP src IP dst TCP dport ... Ação Contador
* 10:20:.. * * * * Porta 1 250 * * * 5.6.7.8 * * Porta 2 300 * * * * 25 * Descarte 892 * * * 192.* * * Local 120 * * * * * * Controlador 11 Fonte: OFN (2012b) 4.3 Versões
Atualmente, as versões mais utilizadas do OpenFlow são a 1.0 e 1.1, embora muitas implementação estejam sendo feitas na versão 1.3.
4.4 Aplicações
Devido a flexibilidade e a quebra de paradigmas do uso de redes de computadores e o potencial disruptivo do OpenFlow, diversas empresas de diferentes segmentos despertaram interesse em utilizá-lo.
Conforme relato de OFN (2011) as empresas Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo! formaram a organização sem fins lucrativos chamada de OFN (Open Networking Foundation) para disseminar sua implementação e adoção.
Dentre alguns segmentos de aplicações promissores pode-se citar:
Redes Corporativas: provê mecanismos de gerência e segurança integradas a rede sem fio e cabeada com suporte a diferentes tipos de tráfegos por VLAN, entre outros (CASADO et al., 2007);
Backbone: convergência de redes de circuitos e pacotes, alternativas de caminho,
roteamento, recuperação de falhas, balanceamento de tráfego WEB, entre outros; GUDLA (2010)
Redes Celulares: transporte para diversas redes de acesso como 3G, LTE, WiMAX possibilitando a separação de provedores de serviços (YAP et al., 2010); Data Centers: engenharia de tráfego, conservação de energia, roteamento e
suporte a virtualização (KOPONEN et al., 2010).
4.5 OpenFlow e os fabricantes de equipamentos
Devido à grande flexibilidade e escalabilidade que o OpenFlow estabelece para os equipamentos de comunicação de dados, grandes fabricantes de switches estão inovando seus equipamentos e os preparando para suporte ao OpenFlow.
Segundo OFN (2011) as empresas Broadcom e Marvell, Brocade, Ciena, Cisco, Citrix, Dell, Ericsson, Force10, HP, IBM, Juniper Networks, NEC, Netgear, NTT, Riverbed Technology e VMware assim como as empresas referenciadas em 4.4 Aplicações também integram a organização OFN.
4.6 Deficiências do OpenFlow
Como todo protocolo e arquitetura, o OpenFlow não é diferente e apresenta algumas limitações que serão abordadas abaixo.
Embora tenha iniciado em 2008, o OpenFlow é considerado ainda um padrão recente, que de acordo com OFN (2012a), em cada nova versão novos suportes e melhoria são realizadas.
Para CURTIS et al. (2010) o OpenFlow possui limitações de escalabilidade para tratar grandes quantidades de fluxos, limitação esta encontrada no controlador OpenFlow e na arquitetura de processamento interna utilizada para processar novos fluxos. CURTIS et al. (2010) cita que uma vez que o fluxo esteja instalado no plano de dados, esta limitação não é mais vista.
Embora o OpenFlow tenha sido desenvolvido inicialmente para aplicações acadêmicas, teve aderência de grandes provedores de serviços para aplicações em
Data Centers e backbones.
CURTIS et al. (2010) menciona que a comunicação com o plano de controle é maior que a comunicação com o plano de dados e portanto, gera-se muito overhead limitando a capacidade de processamento do controlador que está diretamente ligada com sua capacidade de memória e processamento.
A proposta de CURTIS et al. (2010) para o problema de overhead foi dividida em dois mecanismos sendo:
Rule cloning: dentro do padrão OpenFlow para critérios de entradas baseados em máscaras de subrede, todos os pacotes que combinam com uma determinada regra, são tradados como um fluxo. Segundo CURTIS et al. (2010), todos os fluxos baseados na mesma máscara de subrede serão tratados como um único fluxo, enviando-os pelo mesmo caminho.
Local actions: certas decisões de encaminhamento de fluxos requerem a ação do controlador, que muitas vezes está sobrecarregado e o plano de dados sem carga. Com isso, pode ocorrer o problema de um fluxo levar um determinado tempo para ser processado e instalado no plano de dados por conta da alta carga do controlador. Para CURTIS et al. (2010), transferir algumas funções de decisão de volta para o switch pode minimizar estes impactos. Isso seria feito para tráfegos com mesma máscara de subrede, como por exemplo, os múltiplos caminhos de saída também conhecido como ECMP (equal-cost multi-path), aplicando um
algoritmo de distribuição de probabilidade ou através de mecanismos de
Round-Robin.
Além da limitação descrita por CURTIS et al. (2010), ISHIMORI et al. (2012) cita em seu trabalhos mecanismos de contornar deficiências de QoS dentro de uma rede OpenFlow para gerenciamento de congestionamento.
Segundo OFN (2012a) mecanismos de QoS foram incorporados ao OpenFlow, porém apenas mecanismos básicos de reserva de banda feita pelo sistema operacional, e não mecanismos mais sofisticado de controle de congestionamento.
ISHIMORI et al. (2012) cita que os mecanismos de controle de QoS externos, não nativos do OpenFlow, dependem do Linux. Além disso, a largura de banda garantida e as filas por portas são configuradas estaticamente, não atendendo as necessidades de adaptabilidade características de implementações de QoS.
A proposta de ISHIMORI et al. (2012) é o desenvolvimento do QoSFlow, possibilitando o gerenciamento de QoS em domínios OpenFlow e permitindo inserir primitivas de QoS, como por exemplo, o gerenciamento de disciplinas de filas. Define-se as primitivas de QoS como um agregado de funções capazes de gerenciar recursos de QoS. Essas primitivas, quando invocadas por um controlador OpenFlow, realizam a programação dinâmica de aspectos de QoS nas portas dos dispositivos de rede habilitados com OpenFlow.
É proposta a seguinte arquitetura para o QoSFlow:
Gerente QoSFlow: possibilita a especificação, junto com o NOX, de aspectos de QoS a serem implantados em dispositivos da rede OpenFlow;
API Web do Gerente QoSFlow: permite que uma aplicação externa de gerenciamento possa invocar, junto ao controlador, funções de qualidade de serviço;
API do QoSFlow: Capacita o NOX a interagir com o plano de dados;
OpenFlow QoS: o subcomponente OpenFlow QoS é o plano de dados OpenFlow que implementa as primitivas de QoS.
Desta forma pretende-se controlar o plano de dados de forma dinâmica, quebrando a limitação de configuração estática de QoS.