Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Renato Brunoro Florentino
Uso do OpenFlow para troca de tráfego prioritário entre Sistemas
Autônomos na Internet
São Paulo
2013
Renato Brunoro Florentino
Uso do OpenFlow para troca de tráfego prioritário entre Sistemas Autônomos na Internet
Dissertação de Mestrado apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT, como parte dos requisitos para obtenção do título de Mestre em: Engenharia de Computação.
Data da aprovação ____/____/____
_______________________________________ Prof. Dr. Alexandre José Barbieri de Sousa (Orientador)
IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Membros da Banca Examinadora:
Prof. Dr. Alexandre José Barbieri de Sousa (Orientador)
IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo Prof. Dr. Mário Olimpio de Menezes (Membro)
IPEN – Instituto de Pesquisas Energéticas e Nucleares Prof. Dr. Volnys Borges Bernal (Membro)
Renato Brunoro Florentino
Uso do OpenFlow para troca de tráfego prioritário entre Sistemas
Autônomos na Internet
Dissertação de Mestrado apresentada ao Instituto de Pesquisas Tecnológicas do Estado de São Paulo – IPT, como parte dos requisitos para obtenção do título de Mestre em: Engenharia de Computação.
Área de concentração: Redes de Computadores
Orientador: Dr. Alexandre José Barbieri de Sousa
São Paulo Agosto/2013
Ficha Catalográfica
Elaborada pelo Departamento de Acervo e Informação Tecnológica – DAIT do Instituto de Pesquisas Tecnológicas do Estado de São Paulo - IPT
F633u Florentino, Renato Brunoro
Uso do OpenFlow para troca de tráfego prioritário entre Sistemas Autônomos na internet. / Renato Brunoro Florentino. São Paulo, 2013.
128p.
Dissertação (Mestrado em Engenharia de Computação) - Instituto de Pesquisas Tecnológicas do Estado de São Paulo. Área de concentração: Redes de Computadores
Orientador: Prof. Dr. Alexandre José Barbieri de Sousa
1. OpenFlow 2. Pontos de troca de tráfego 3. Sistema Autônomo 4. Internet (redes de computadores) 5. Tese I. Sousa, Alexandre José Barbieri de, orient. II. IPT. Coordenadoria de Ensino Tecnológico III. Título
DEDICATÓRIA
Este trabalho é dedicado à Marilande Brunoro, minha mãe, que sempre me incentivou à alcançar meus objetivos. Mãe amiga, que sempre apoiou nos momentos de dificuldade com suas palavras de perseverança. Mãe esta, que sempre fez da sua vida, a realização dos seus filhos.
AGRADECIMENTOS
Agradeço primeiramente à Deus, por me conceder a oportunidade de chegar até aqui e conquistar este objetivo.
Ao amigo Adilson Feliciano, por sempre me apoiar e lutar ao meu lado, aqui deixo meu especial agradecimento por todos os anos de dedicação.
Ao amigo orientador Dr. Alexandre Barbieri, por ter assumido a responsabilidade e ter me conduzido sabiamente até o final desse trabalho.
A minha esposa, pela compreensão nos momentos que me ausentei para desenvolver este trabalho.
Aos membros da banca Dr. Volnys e Dr. Mário, pelas valiosas contribuições permitindo o aprimoramento este trabalho.
A amiga Andréia Longuinho, pela apoio e ajuda.
Aos demais amigos que participaram e contribuíram para que este sonho se tornasse realidade.
RESUMO
Aplicações sensíveis a atraso e à perda de pacotes estão cada vez mais sendo trafegadas pela Internet, sejam aplicações de voz, vídeo, conferência ou jogos. Para tais aplicações, requisitos de qualidade de serviço como garantia de entrega, perda de pacotes e latência são importantes para o bom funcionamento.
Alternativas como o uso de redes de diferentes tecnologias como MPLS e redes com engenharia de tráfego muitas vezes são adotadas para otimizar a transmissão de dados entre Sistemas Autônomos na Internet. A falta de padronização devido a dificuldades de manter um padrão de qualidade de serviço fim a fim na Internet faz com que os dados sejam transmitidos sem tais requisitos.
Como alternativa, está sendo proposto neste trabalho, a criação de uma rede especializada com o OpenFlow que priorizará o tráfego sensível a atraso, diminuindo o número de saltos entre o Sistema Autônomo origem e destino utilizando a estrutura atual dos PTT’s.
Através de experimentos simulando o ambiente similar a Internet com PTT, e o OpenFlow, foi possível comparar os resultados e avaliar a funcionalidade do OpenFlow para esta finalidade de aplicação e gerenciamento de tráfego.
Com o uso do OpenFlow, foi possível enviar tráfego entre distintos Sistemas Autônomos atingindo os objetivos de latência, perda de pacotes e variação da latência.
ABSTRACT
Using OpenFlow to exchange priority data between Autonomous Systems in the Internet
Applications sensitive to delay and packet loss are increasingly being seen in the Internet, such as voice, video, conferencing and games. For such applications, requisites of quality of service to guarantee delivery, packet loss and latency are important to work properly.
Alternatives such as the use of networks of different technologies such as MPLS networks and traffic engineering are often adopted to optimize the transmission of data between Autonomous systems in the Internet. The lack of standardization due to difficulties in maintaining an end-to-end standard of quality of service in the Internet, makes data be transmitted without such requirements.
Alternatively, in this work is being proposed the adoption of a specialized network with OpenFlow that will address the delay-sensitive traffic, decreasing the number of hops between the source and destination Autonomous system.
Through experiments simulating the current similar environment of the Internet, and the OpenFlow, it was possible to compare the results and evaluate the functionality of OpenFlow for this purpose as well as the application traffic management.
It was observed that with the use of OpenFlow, it was possible to send traffic between different Autonomous Systems reaching the goals of latency, packet loss and jitter.
Lista de Ilustrações
Figura 1 – Método de trabalho 17
Figura 2 – Pontos de Presença dos PTT’s brasileiros 33 Figura 3 – Tráfego agregado dos PTT’s brasileiros – PTTMetro 34 Figura 4 – Histórico de tráfego mensal (gráfico anual) – PTTMetro São Paulo 35 Figura 5 – Histórico de tráfego anual (gráfico decenal) – PTTMetro São Paulo 35 Figura 6 – PTT – Modelo Switch Único – Matrix de Comutação 37 Figura 7 – PTT – Modelo Rede Metro Ethernet – Matrix de Comutação 38 Figura 8 – PTT Regional – Comunicação entre AS’s sem PTT 39 Figura 9 – PTT Regional – Comunicação entre AS’s com PTT 40
Figura 10 – Arquitetura do OpenFlow 41
Figura 11 – Switch OpenFlow 43
Figura 12 – Fluxograma do fluxo de pacotes dentro de um switch OpenFlow 44
Figura 13 – Modelos de Transmissão 52
Figura 14 – Tráfego enviado por encaminhamento tradicional IP / BGP 60 Figura 15 – Tráfego enviado por encaminhamento especializado OpenFlow 61
Figura 16 – Etapas das simulações 70
Figura 17 – Modelo de implementação do controlador OpenFlow 73 Figura 18 – Encaminhamento Tradicional/OpenFlow – 25% / 64 bytes 78 Figura 19 – Encaminhamento Tradicional/OpenFlow – 25% / 512 bytes 79 Figura 20 – Encaminhamento Tradicional/OpenFlow – 25% / 1518 bytes 80 Figura 21 – Comparação da variação da latência – 25% 81 Figura 22 – Encaminhamento Tradicional/OpenFlow – 50% / 64 bytes 83 Figura 23 – Encaminhamento Tradicional/OpenFlow – 50% / 512 bytes 84
Figura 24 – Encaminhamento Tradicional/OpenFlow – 50% / 1518 bytes 85 Figura 25 – Comparação da variação da latência – 50% 86 Figura 26 – Encaminhamento Tradicional/OpenFlow – 75% / 64 bytes 88 Figura 27 – Encaminhamento Tradicional/OpenFlow – 75% / 512 bytes 89 Figura 28 – Encaminhamento Tradicional/OpenFlow – 75% / 1518 bytes 90 Figura 29 – Comparação da variação da latência – 75% 91 Figura 30 – Encaminhamento Tradicional/OpenFlow – 100% / 64 bytes 93 Figura 31 – Encaminhamento Tradicional/OpenFlow – 100% / 512 bytes 94 Figura 32 – Encaminhamento Tradicional/OpenFlow – 100% / 1518 bytes 95 Figura 33 – Comparação da variação da latência – 100% 96
Quadro 1 – Lista de Serviços 64
Quadro 2 – Métricas do sistema 66
Quadro 3 – Especificação do laboratório 69
Quadro 4 – Modelo de coleta de dados 74
Quadro 5 – Resultado das medições da Amostra Referencial 75 Quadro 6 – Coleta de amostras de dados – Encaminhamento Tradicional: 25% 81 Quadro 7 – Coleta de amostras de dados – Encaminhamento OpenFlow: 25% 82 Quadro 8 – Coleta de amostras de dados – Encaminhamento Tradicional: 50% 87 Quadro 9 – Coleta de amostras de dados – Encaminhamento OpenFlow: 50% 87 Quadro 10 – Coleta de amostras de dados – Encaminhamento Tradicional: 75% 92 Quadro 11 – Coleta de amostras de dados – Encaminhamento OpenFlow: 75% 92 Quadro 12 – Coleta de amostras de dados – Encaminhamento Tradicional: 100% 97 Quadro 13 – Coleta de amostras de dados – Encaminhamento OpenFlow: 100% 97
Lista de Tabelas
Tabela 1 – Exemplo de tabela de fluxo de um switch OpenFlow 47 Tabela 2 – Tabela n tuple de seleção de tráfego 72
Lista de Abreviaturas e Siglas
3G Third Generation AS Autonomous System
BGP4 Border Gateway Protocol version 4 CGI Comitê Gestor de Internet
CIX Commercial Internet Exchange CPU Central Processing Unit
DSCP Differentiated Services Code Point ECMP Equal-cost multi-path
ESNet Energy Science Network EXP Experimental Bit
FIX-E Federal Internet Exchange East
FIX-W Federal Internet Exchange West
ForCES Forwarding and Control Element Separation IP Internet Protocol
IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6
ISO International Organization for Standardization ISP Internet Service Provider
IXP Internet Exchange Point
L3 Layer 3
LTE Long Term Evolution
MPLS Multiprotocol Label Switching
MPLS-TE Multiprotocol Label Switching – Traffic Engineering MAC Medium Access Control
MILNET Data Defense Network
NSF National Science Foundation NOX OpenFlow Controller C++ based NSI Nasa Science Internet
OSI Open Systems Interconnection OSPF Open Shortest Path First PC Personal Computer PCC Path Computation Client PCE Path Computation Element PHB Per Hop Behavior
PTT Ponto de Troca de Tráfego QoS Quality of Service
RA Roteador de Acesso RI Roteador de Interconexão RNP Rede Nacional de Pesquisas RSVP Resource Reservation Protocol SDN Software Defined Network SLA Service Level Agreement SO Sistema Operacional STP Spanning Tree Protocol TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol TLS Transport Layer Security
ToS Type of Service
UDP User Datagram Protocol VLAN Virtual Local Area Network VPN Virtual Private Network XML eXtensible Markup Language
Sumário 1 INTRODUÇÃO 13 1.1 Motivação 15 1.2 Objetivo 16 1.3 Método de trabalho 17 1.4 Organização do trabalho 21
2 PRIORIZAÇÃO DE TRÁFEGO ENTRE SISTEMAS AUTÔNOMOS 23
2.1 Redes MPLS com Engenharia de Tráfego 24
2.2 Redes Baseadas em Elementos de Computação de Caminhos 25 2.3 Redes com Qualidade de Serviços com uso de Serviços Integrados 27 2.4 Redes com Qualidade de Serviços com uso de Serviços Diferenciados 28
2.5 Redes Virtuais Embarcadas 30
3 PONTO DE TROCA DE TRÁFEGO 32
4 OPENFLOW 41
4.1 Componentes do Switch OpenFlow 42
4.1.1 Tabela de fluxos 43 4.1.2 Canal de Comunicação 45 4.1.3 O Protocolo 45 4.1.4 Controlador 45 4.2 Funcionamento 46 4.3 Versões 47 4.4 Aplicações 47
4.5 OpenFlow e os fabricantes de equipamentos 48
4.6 Deficiências do OpenFlow 48
5 PROPOSTA DE TRABALHO 52
5.1 Gerenciamento de tráfego 52
5.1.1 Tráfego prioritário 53
5.2 Fluxo de dados na camada de interconexão 54
6 AMBIENTE DE SIMULAÇÃO 57
6.1 Componentes da Simulação 57
6.2 Especificação dos Equipamentos de Teste 58
6.3 Topologias de Simulação 59
6.4 Delimitação de escopo 61
6.5 Metodologia 62
6.5.1 Determinar os objetivos do trabalho e definir o sistema 62 6.5.2 Listar os serviços do sistema e possíveis resultados 63
6.5.3 Selecionar as métricas 64
6.5.4 Listar os parâmetros do sistema e de carga 66
6.5.5 Selecionar fatores e seus valores 66
6.5.6 Selecionar as técnicas de avaliação 68
6.5.7 Selecionar a carga de trabalho 69
6.5.8.1 Encaminhamento Tradicional 70
6.5.8.2 Encaminhamento Especializado OpenFlow 71
6.5.9 Analisar e interpretar os resultados 73
7 ANÁLISE DOS DADOS 76
7.1 Cenário 1 – Análise com taxa de ocupação do canal de 25% 77 7.2 Cenário 2 – Análise com taxa de ocupação do canal de 50% 82 7.3 Cenário 3 – Análise com taxa de ocupação do canal de 75% 87 7.4 Cenário 4 – Análise com taxa de ocupação do canal de 100% 92
8 CONSIDERAÇÕES FINAIS 98 8.1 Conclusão 99 8.2 Contribuições 99 8.3 Pontos de atenção 100 8.4 Trabalhos futuros 100 REFERÊNCIAS 102
APÊNDICE A – VERSÕES DO OPENFLOW 109
APÊNDICE B – CONFIGURAÇÃO DO ROTEADOR RA1 111
APÊNDICE C – CONFIGURAÇÃO DO ROTEADOR RI1 116
APÊNDICE D – CONFIGURAÇÃO DO ROTEADOR RI2 120
APÊNDICE E – CONFIGURAÇÃO DO ROTEADOR RA2 124
1 INTRODUÇÃO
Inicialmente, as redes de dados e a Internet foram concebidas para a troca de dados sem priorização de tráfego.
Com o crescente uso das redes de dados e da Internet, diferentes tipos de tráfegos, como e-mails, voz, vídeo e aplicações multimídia fazem uso do mesmo canal de comunicação.
Embora na Internet não haja garantia de banda, entrega de pacotes e latência garantida, aplicações sensíveis requerem tais requisitos para seu correto funcionamento.
A Internet é formada por um conjunto de Sistemas Autônomos que, interligados entre si, constituem a rede global e são divididos em camadas, também conhecidos como “tiers”, que possuem 3 níveis: tier 1, tier 2 e tier 3.
Cada Sistema Autônomo tem suas próprias características de administração, autonomia e blocos de endereçamento IP (Internet Protocol), sendo eles IPv4 (Internet
Protocol version 4) e/ou IPv6 (Internet Protocol version 6).
A troca de tráfego entre os Sistemas Autônomos é feita através do anúncio dos blocos de endereços IP, dos quais cada Sistema Autônomo detém direitos administrativos. Este anúncio é feito através do protocolo de roteamento denominado BGP4 (Border Gateway Protocol version 4), que através de sessões TCP/IP (Transmission Control Protocol/Internet Protocol) que são estabelecidas com outros Sistemas Autônomos adjacentes, trocam os prefixos pertencentes a cada um, conhecendo assim todos os prefixos de todos os demais Sistemas Autônomos que compõem a internet, também denominado de full-routing.
A troca de tráfego na Internet é conhecida também como troca de tráfego de melhor esforço, ou best-effort, não havendo compromisso para a garantia dos requisitos de qualidade de serviço acima citados.
Aplicações sensíveis a atraso como conferências, chamadas de voz, vídeo e jogos concorrem com aplicações não sensíveis, tais como o acesso a páginas WEB, troca de arquivos, correios eletrônicos, entre outras aplicações e serviços.
Entende-se como tráfego prioritário qualquer tipo de tráfego diferenciado, que demande garantia de atraso, latência e variação da latência, além de outros tráfegos que não sejam caracterizados como tráfego de melhor esforço.
Mecanismos de qualidade de serviço, ou QoS (Quality of Service) não são aplicados na Internet fim a fim, prejudicando o tráfego de aplicações sensíveis a latência, perda de pacotes, banda e variação da latência.
O fato do tráfego não ser priorizado na Internet, se dá devido à diferentes arquiteturas, tipos e velocidades de enlaces de dados e a distintas políticas locais de QoS.
Esta tarefa não é difícil de se realizar quando é considerado o gerenciamento de tráfego dentro de um domínio de QoS, pertencente a um determinado Sistema Autônomo. Neste domínio de QoS, é possível criar uma política de QoS personalizada para as demandas de determinado perfil de tráfego.
Alternativas de se realizar QoS na Internet para determinadas aplicações podem ser encontradas através do uso do protocolo MLPS com engenharia de tráfego. Porém, seu uso é restrito devido a dificuldades de implementação, uma vez que não apenas o Sistema Autônomo origem e destino devem ter tais funcionalidades habilitadas, mas todos os Sistemas Autônomos intermediários, também conhecidos como Sistemas Autônomos de trânsito. Os Sistemas Autônomos tem como prática, desconsiderar as marcações dos pacotes recebidos quando estes adentram em sua rede.
Com o uso do OpenFlow, diferentes Sistemas Autônomos podem enviar seus tráfegos prioritários sem obedecer a um padrão de marcação de priorização, acordo ou políticas que definem o tráfego prioritário ou até o roteador convencional, bastando apenas realizar a classificação do tráfego de acordo com o critério desejado na borda de troca de tráfego entre os Sistemas Autônomos e enviar através da rede OpenFlow. O padrão OpenFlow, desenvolvido pela Universidade de Stanford, consiste na separação do plano de controle e do plano de dados. Esta separação permite utilizar a rede existente em produção como laboratório para novos protocolos ou teste de novas tecnologias, sem interferir nos dados que estão sendo trafegados na rede.
Com o OpenFlow, surgiu um novo conceito de funcionamento das redes de computadores, transformando até então robustos roteadores e switches em simples
interfaces de entrada e saída de dados, passando o controle para elementos externos e remotos, como o caso dos controladores OpenFlow (GUDLA, 2010).
Este trabalho explorou o uso do OpenFlow como meio de troca de tráfego prioritário entre Sistemas Autônomos. Atualmente, trocas de tráfego baseados em QoS não foram padronizadas devido a dificuldades de homogeneização de políticas de QoS (Quality of Service) entre diferentes domínios de QoS, existindo apenas guias de referências ou melhores práticas com sugestões de implementação.
Devido aos PTT’s (Pontos de Troca de Tráfego) existentes na Internet possuírem estruturas dedicadas de alta capacidade e com gerenciamento centralizado, este trabalho avaliou a viabilidade do uso do OpenFlow para priorizar o tráfego prioritário em um PTT.
1.1 Motivação
A dificuldade de se propor padrões de qualidade de serviço entre Sistemas Autônomos, também conhecido como QoS AS (Quality of Service
Inter-Autonomous Systems), contribui para que não haja troca de tráfego especializada
para aplicações sensíveis a atraso e a perda de pacotes, sendo a troca de tráfego na Internet realizada sem priorização de tráfego.
A demanda por aplicações prioritárias como voz, sinalização de voz, vídeo e jogos usando a Internet como meio de transmissão tem contribuído com o crescimento e desenvolvimento tecnológico, porém, devido a limitações de qualidade, tais serviços ainda apresentam seu crescimento limitado (GUDLA, 2010).
Diante da dificuldade de garantia de parâmetros de qualidade como latência, variação da latência, perda de pacotes e sequencialização dos pacotes, provedores de serviços têm adotado alternativas, como redes MPLS e engenharia de tráfego para enviar pacotes de aplicações prioritárias de seu Sistema Autônomo para outros Sistemas Autônomos ondereside a fonte ou destino da informação, processo custoso devido a dificuldades de parâmetros qualitativos de interconexão das redes como mesma política de QoS e sistemas de enfileiramento de dados (MEYER, 2010).
Para MEYER (2010) e BHANIRAMKA (2010) a solução apontada para a resolução dos problemas relativos à qualidade de serviço na Internet é o uso de
técnicas de engenharia de tráfego. Já para BIANCO et al. (2010), embora o OpenFlow não ofereça mecanismos de controle de congestionamento, são oferecidos mecanismos de garantia de banda, que combinados com uma política de transmissão de dados em uma rede especializada confere uma proposta de implementação e gerenciamento mais simples, de forma que independente dos parâmetros de qualidade de serviço gravados no cabeçalho IP, o OpenFlow realiza a seleção dos fluxos de dados programados pelo provedor de serviços e as envia ao destino (próximo Sistema Autônomo).
Atualmente, as técnicas de qualidade de serviço são feitas usando o campo DSCP (Differentiated Services Code Point) do pacote IP ou o campo EXP (Experimental bit) do pacote MPLS. Para KAPPLER (2012) e LI et al. (2012), são campos lidos na entrada de uma rede para determinar qual tratativa de QoS será aplicada a determinado tráfego, porém, isso funciona de forma adequada quando os fluxos são trocados dentro do mesmo Sistema Autônomo, pertencente ao mesmo domínio de QoS. Mas isso não é verdade quando há troca entre Sistemas Autônomos. O pacote, ao entrar na fronteira de um outro Sistema Autônomo, tem todas as marcações de DSCP e EXP sobrescritas para o padrão utilizado no dado Sistema Autônomo, descaracterizando o fluxo recebido em relação aos parâmetros de qualidade de serviço.
1.2 Objetivo
Este trabalho teve como objetivo avaliar o uso do OpenFlow para troca de tráfego prioritário em uma estrutura física de pontos de troca de tráfego existente na Internet. Primeiramente foi validada a funcionalidade do OpenFlow. Posteriormente comparou a estrutura similar a Internet com o modelo proposto neste trabalho, utilizando o OpenFlow.
Como objetivo específico, foram estudados e realizados experimentos e simulações com o OpenFlow para se caracterizar as diretrizes para uso do OpenFlow em um PTT.
1.3 Método de trabalho
O método de trabalho foi dividido em três etapas e é mostrado através do diagrama na Figura 1. O detalhamento de cada etapa será feito na sequência.
Figura 1 – Método de trabalho
Fonte: Elaborado pelo Autor
Etapa 1 – Análise Bibliográfica
A) Análise dos trabalhos relacionados a qualidade de serviço na Internet: Análise de trabalhos que referenciam o uso de qualidade de serviço para a troca de dados prioritários na comunicação entre Sistemas Autônomos, visando explorar os parâmetros de qualidade utilizados e medidos, bem como as dificuldades e benefícios em sua utilização e suas aplicações.
B) Análise dos trabalhos relacionados com transmissão de dados entre provedores de serviço na Internet:
Avaliar a característica de troca de tráfego entre Sistemas Autônomos, bem como trabalhos relacionados a análise de desempenho e aplicações, com foco nas métricas de medição de desempenho: latência, variação da latência, tempo de propagação, topologias e ambientes de testes.
C) Avaliar as características de tráfego do PTT:
Pesquisar a volumetria de tráfego dos PTT’s, bem como entender como o tráfego é encaminhando dentro de sua estrutura. Conhecer a topologia e forma de comunicação entre os Sistemas Autônomos que se comunicam entre si.
D) Avaliar a utilização do PTT entre os Sistemas Autônomos na Internet: Analisar o tipo e interesse de tráfego entre os Sistemas Autônomos que usam o PTT como meio de troca de tráfego, observando o tipo de protocolo IP, TCP ou UDP, o tamanho de pacotes e analisar a marcação de qualidade de serviço destes pacotes, como o DSCP e o ToS.
E) Avaliar as características do OpenFlow:
Fazer um estudo detalhado de como é o protocolo OpenFlow e seus elementos como tabela de fluxos, controlador canal de comunicação e hardware, entender como é o fluxo de mensagens, tratamento do pacote ao chegar no elemento de rede com OpenFlow habilitado, envio e tratamento pelo controlador.
F) Estudar o uso do OpenFlow:
Avaliar trabalhos e experimentos que utilizam o OpenFlow para entender suas limitações, funcionalidades de implementação, restrições,
recomendações de utilização e características específicas de funcionamento.
Etapa 2 – Metodologia
A) Planejamento dos testes:
Elaboração da planilha de testes com os elementos a serem medidos em cada experimento, contendo as variáveis a serem definidas na ETAPA 3.
B) Metodologia da análise dos testes:
Definição da metodologia a ser utilizada nos experimentos, tais como vazão de dados, latência, variação da latência, e perda de pacotes:
Transmissão Tradicional o Vazão de dados;
o Latência fim a fim em sentido único; o Variação da latência;
o Perda de pacotes;
o Marcação DSCP do pacote; o Taxa de ocupação do canal.
Transmissão Especializada OpenFlow (todos os fluxos): o Vazão de dados;
o Latência fim a fim em sentido único; o Variação da latência;
o Perda de pacotes;
o Marcação DSCP do pacote;
o Variação da latência entre o dispositivo OpenFlow e o controlador;
Será elaborada uma tabela com os parâmetros acima e ao final dos testes será feita a comparação entre as variáveis para a análise de desempenho do OpenFlow, comparado às redes tradicionais IP.
C) Especificações dos testes:
Especificar os testes de transmissão de dados entre Sistemas Autônomos a serem realizados em todos os experimentos.
D) Especificação do ambiente de testes:
Especificação dos ambientes de testes dos experimentos descrevendo os equipamentos e interconexões necessárias para realizar as provas, disponíveis no capítulo 6.1 Componentes da Simulação.
Etapa 3 – Simulações e Análise dos Resultados A) Montagem dos ambientes de testes:
Realizar a montagem dos ambientes de testes mencionados na ETAPA 2.
B) Execução dos testes:
Para a execução dos testes, foram preparados dois experimentos para a avaliar a transmissão nos seguintes ambientes:
Encaminhamento Tradicional:
Encaminhamento Especializado OpenFlow:
C) Análise dos resultados:
Como parâmetro de base de teste, serão utilizadas as medições e resultados observados no experimento “Encaminhamento Tradicional”, pois este modelo apresenta o fluxo de transmissões realizadas na Internet atualmente, de acordo com os requisitos descritos na ETAPA 3 item C.
A análise dos resultados será realizada observando cada grupo de resultado descrito na ETAPA 3 item C em forma de tabela comparando-os entre si para analisar o desempenho do OpenFlow em relação ao modelo atual da Internet.
D) Conclusão:
Apresentar a conclusão dos testes, analisando se os parâmetros de desempenho do OpenFlow são satisfatórios em relação ao tipo de transmissão atual. Caracterizar as diretrizes para o uso do OpenFlow em um PTT.
1.4 Organização do trabalho
Para atender aos objetivos da pesquisa, o trabalho está estruturado em oito capítulos; além desta introdução:
O capítulo 2 apresenta os trabalhos pesquisados relacionados a desempenho de transmissão de dados e qualidade de serviço entre Sistemas Autônomos.
O capítulo 3, Ponto de Troca de Tráfego, refere-se ao estudo feito sobre as características e uso dos pontos de troca de tráfego com respeito ao volume de dados e topologia de interconexão.
O capítulo 4, OpenFlow, descreve a arquitetura e funcionamento do OpenFlow incluindo aplicações, benefícios, limitações e uso acadêmico e comercial.
O capítulo 5 apresenta a proposta de trabalho dessa dissertação, descrevendo o que foi avaliado. Foi identificado e detalhado cada elemento usado e o fluxo de dados entre a origem até o destino.
No capítulo 6 são apresentadas topologias de testes, metodologia e os procedimentos de teste para cada um dos dois experimentos realizados, para a análise de transmissão de dados prioritários na rede de dados, utilizando o modelo de transmissão similar à Internet e a rede OpenFlow.
O capítulo 7 apresenta a análise dos resultados coletados nos experimentos da rede Internet com PTT e OpenFlow, no que tange a transmissão de dados e os parâmetros de qualidade de serviço analisados.
O capítulo 8 contém as considerações finais e as conclusões do trabalho, bem como as limitações, observações e temas futuros correlacionados a serem explorados em outras dissertações.
2 PRIORIZAÇÃO DE TRÁFEGO ENTRE SISTEMAS AUTÔNOMOS
Na fase de análise dos trabalhos relacionados, observou-se que a maioria dos modelos utilizados são baseados na coexistência do tráfego prioritário com os demais tipos de tráfegos em uma rede.
Desta forma, todos os recursos são compartilhados e a distinção de serviços é feita através de políticas de QoS (Quality of Service) para cada serviço.
Sendo assim, o tráfego prioritário é processado pelos mesmos equipamentos e recursos internos de memória, CPU (Central Processing Unit) e planos de controle e encaminhamento que o tráfego não crítico.
Através de técnicas de QoS, os elementos de rede priorizam determinado tráfego com base na marcação, seja ela, DSCP, ToS (Type of Service), IP (Internet Protocol)
Precedence ou ainda pelo campo EXP (Experimental bit) em caso de redes MPLS
(Multiprotocol Label Switching).
Em situações de alto tráfego, tal sobrecarga da rede pode gerar latência no processamento das informações e tomadas de decisão na classificação dos pacotes prioritários, acarretando em eventuais descartes.
Com o padrão OpenFlow, todo o processamento é feito de forma descentralizada no controlador, elemento o qual atua como a CPU dos roteadores e switches, e permite que interfaces específicas dos elementos de rede sejam utilizadas para o encaminhamento do tráfego classificado, como por exemplo os tráfegos prioritários (COUTO, 2010).
O OpenFlow é baseado em fluxos de dados. O controlador (plano de controle), programa nos elementos de rede (plano de encaminhamento) as entradas que caracterizam um determinado fluxo, alocando interfaces específicas para tais dados. Estas interfaces são usadas para encaminhar o tráfego que atende a determinada descrição de fluxo, exigindo menos processamento local, uma vez que o processamento é realizado no controlador OpenFlow (GUDLA, 2010).
2.1 Redes MPLS com Engenharia de Tráfego
Um modelo de rede que provê recursos de garantia de serviços, largura de banda, controle fim a fim para aplicações sejam elas críticas ou não, é o MPLS-TE (Multiprotocol Label Switching-Traffic Engineering).
O MPLS-TE é uma evolução das redes MPLS, que originalmente apenas forneciam melhor desempenho do que as redes IP nativas devido ao processamento dos cabeçalhos em camada inferior, na conhecida camada 2,5 ao invés da camada 3, que usa o conceito de encaminhar sempre que possível e rotear sempre que necessário. As redes MPLS estão presentes em quase 90% das redes das operadoras de serviços atualmente (MEYER, 2010).
Com o MPLS-TE, são construídos túneis entre origem e destino dos dados, selecionando os elementos de redes intermediários nos quais os fluxos de dados irão transitar. Na construção destes túneis lógicos, são configuradas suas propriedades, como banda desejada, roteadores intermediários entre origem e destino e ainda ações de descarte de pacotes, caso seja necessário priorizar em relação a outros túneis que transitam pelo mesmo caminho (BHANIRAMKA, 2010).
O MPLS-TE depende do hardware do dispositivo de rede que os túneis atravessam, sendo assim necessárias inteligências no plano de controle e plano de dados para criar, estabelecer e permitir a passagem de dados.
Sendo assim, sua configuração é complexa e exige que todos os dispositivos de rede ao longo do caminho possuam recursos para as exigências de determinado(s) túnel(is).
Uma vantagem de utilizar esta técnica é que ela permite a classificação do tráfego baseada em diferentes atributos, tanto do protocolo IP quanto do MPLS, tornando flexível sua implementação (BHANIRAMKA, 2010).
Porém, uma dificuldade e muitas vezes uma limitação do uso do MPLS-TE, é a necessidade de possuir este recurso habilitado na rede de todos os provedores de serviço entre a origem e destino dos dados. Para a configuração de MPLS-TE, são necessários requisitos que muitas vezes se tornam inviáveis, ou são necessários estudos, provas de conceitos e alteração na arquitetura atual da rede (MEYER, 2010).
Mesmo que o protocolo MPLS esteja habilitado na rede, isto não significa que o MPLS-TE possa ser habilitado de forma simples. O recurso de engenharia de tráfego é uma configuração adicional ao protocolo MPLS já habilitado.
Segundo SHIMONISHI (2010) o uso de OpenFlow em uma rede não altera suas características, permitindo ainda que a rede MPLS / IP atualmente em uso seja preservada, permitindo que o tráfego baseado em OpenFlow seja redirecionado para outras interfaces dos elemento de rede de forma transparente.
Como o OpenFlow opera em camada 2, não altera as características das camadas superiores, embora em seu mecanismo de classificação de dados possa selecionar determinados pacotes, baseados em informações de camadas 3 e 4 (MCKEOWN et al., 2008).
Para determinadas aplicações como VPN MPLS, esta implementação ainda se torna razoável por sua natureza, embora extensões de VPN MPLS estejam sendo desenvolvidas para uso no OpenFlow, conforme proposta de SHARAFAT et al. (2011). Independentemente de aplicações de MPLS VPN ou a transmissão de qualquer pacote que seja prioritário, é necessário enviar tais dados usando o protocolo MPLS. Este trabalho aborda a transmissão de dados regulares IP prioritários sendo transmitidos em uma rede OpenFlow, não requerendo que nenhuma política de acordo ou compatibilização de classes de serviços seja realizada, como é feito nas redes MPLS-TE. Sendo assim, pode-se citar várias vantagens, como manter a arquitetura das redes dos provedores de serviços, manter os protocolos e padrões adotados individualmente em cada uma delas, menos complexidade da rede e para o desempenho. Tudo será avaliado após a simulação nos experimentos a serem realizados.
2.2 Redes Baseadas em Elementos de Computação de Caminhos
O PCE (Path Computation Element) pode calcular caminhos mais sofisticados através da rede por ter acesso a dados adicionais não visíveis a um único elemento de rede.
Essencialmente, o PCE da arquitetura do plano de controle tradicional é migrada para uma função centralizada na rede, mantendo os demais componentes de
descoberta, compartilhamento de topologia e sinalização intactos. O PCE pode ser um roteador, um servidor ou uma entidade virtual em execução em uma nuvem.
A centralização do PCE permite aos operadores personalizar, controlar e atualizar as políticas de um único local. Esta arquitetura permite:
Roteamento inter-domínio; Flexibilidade;
Operação simplificada.
O roteamento na Internet não leva em consideração mecanismos de qualidade de serviços (BERTRAND et al., 2008).
O uso de recursos que se baseiam na separação do plano de controle com o plano de dados também é abordado por (MCKEOWN et al., 2008) e (BERTRAND et al., 2008).
Como premissa, o PCE usa a rede MPLS para encaminhar os pacotes até a rede destino.
Segundo GELEJI (2010) um PCE único não pode controlar caminhos multi-domínios, sendo necessários outros PCE’s de outros domínios. Desta forma, os PCE’s devem se comunicar entre si para trocarem os estados de cada domínio a fim de que o PCE possa computar o melhor caminho para determinado destino.
Semelhante ao controlador do OpenFlow, redes PCE possuem um elemento que também atua no plano de controle.
Cada PCC (Path Computation Client) precisa se comunicar com um ou mais PCE para receber a tabela de estado das redes, as quais possuam interesse de troca de tráfego GELEJI (2010).
Para BERTRAND et al. (2008) e GELEJI (2010), a proposta de novos algoritmos descritos em seus trabalhos, visa melhorar o desempenho em cenários multi-domínios como uma alternativa para o PCE que nativamente possui restrições de funcionamento neste ambiente.
Todas as implementações dependem de acordo de políticas de reserva de recursos de rede em todos os domínios que o tráfego cruzar, sendo esta a dificuldade atual.
Outros parâmetros de estudos definidos em BERTRAND et al. (2008) e GELEJI (2010) não foram analisados devido à necessidade de padronização de configuração em todos os domínios, sendo a proposta desta dissertação a definição de um modelo de troca de tráfego sem a necessidade de compatibilização de configurações entre os Sistemas Autônomos pertencentes ao fluxo de troca de dados.
A proposta de GELEJI (2010) trata uma implementação de QoS fim a fim entre diferentes Sistemas Autônomos, o que no ponto de vista técnico é uma das melhores formas de se realizar. Se compararmos com a proposta desta dissertação, como em cada domínio de QoS o provedor de serviço pode caracterizar o tráfego da forma que melhor convier, e como o interesse é de definir um tráfego prioritário, ambos os provedores de serviços com interesse de tráfego podem classificar os fluxos de dados oriundos do OpenFlow como tráfego prioritário dentro do seu Sistema Autônomo.
Sendo assim, tal tráfego será tratado com métricas de QoS que atendam a baixa latência e variação da latência e perda de pacotes nula.
2.3 Redes com Qualidade de Serviços com uso de Serviços Integrados
Como uma proposta de qualidade de serviços, os serviços integrados não são muito utilizados atualmente devido à sua complexidade de implementação e manutenção.
Os serviços integrados são uma alternativa para o uso de recursos em uma rede que exija requisitos mínimos de reservas de recursos como garantia de banda e atraso (AAMIR et al., 2012).
Geralmente são controlados por uma aplicação que demanda quais recursos serão necessários para a reserva nos dispositivos de rede ao longo do caminho.
Pelo fato de utilizar o protocolo de reserva de recursos, o RSVP (Resource
Reservation Protocol), semelhante ao protocolo utilizado no modelo descrito acima
requisitos de reserva, bem como confirmar salto a salto se todos os elementos de rede possuem tais recursos disponíveis (AAMIR et al., 2012).
O protocolo RSVP pode ser usado em redes IPv4 nativas ao invés de ser utilizado com o protocolo MPLS, garantindo compatibilidade com provedores de serviços que não possuem MPLS habilitados em suas redes, porém que demandem recursos de qualidade de serviços (SAMAK, 2011).
Desta forma, ao receber um pacote de dados prioritário, que deve ser notificado pela aplicação, o elemento de rede inicia o processo de reserva de recursos de nó em nó até o último elemento de rede que o tráfego passará. Caso a reserva seja feita com sucesso, o tráfego de dados então é iniciado (SAMAK, 2011).
Para este processo, todo e qualquer tipo de tráfego compartilha os mesmos elementos de rede, interfaces, serviços, planos de dados e encaminhamentos, não havendo distinção entre os fluxos de dados.
Como o protocolo RSVP está disponível apenas em elementos de rede de grande porte, sua adoção é restrita e confinada nos elementos de núcleo da rede.
Conforme NAOµS et al. (2008) o OpenFlow permite criar caminhos distintos e não depende da aplicação para programar o que será necessário reservar ao longo da rede. Esta é uma tarefa do próprio controlador e extensível a todos os elementos de rede que tenham OpenFlow habilitado.
Pelo fato de usar caminhos distintos, o OpenFlow independe dos protocolos de roteamento para rotear o tráfego entre origem e saída, sendo o controlador responsável por programar os fluxos de acordo com requerido pelo usuário e os instalar nos planos de encaminhamento dos dispositivos (KOBAYASHI, 2011).
Não é necessário manter grandes tabelas de roteamento no planos de controle, utilizando recursos de memória e CPU para criar uma decisão de encaminhamento.
2.4 Redes com Qualidade de Serviços com uso de Serviços Diferenciados
A utilização de serviços diferenciados para tratamento de qualidade de serviços em uma rede, possui maior abrangência do que os serviços integrados.
Os serviços diferenciados estão descritos em JACOBSON (1999) e (HEINANEN et al., 1999).
Com os serviços diferenciados, intitulados como PHB (Per Hop Behavior), os dados são processados salto a salto por todos os elementos entre a origem e o destino.
Segundo KAPPLER (2012), não se trata de reserva de recursos dinâmicos, mas de como os recursos são tratados e priorizados em caso de congestionamento, fazendo com que o elemento de rede, de acordo com os recursos configurados, reserve determinada parte da banda disponível para os fluxos que estão passando por ele.
Conforme LI et al. (2012), ao adentrar ao elemento de rede, é lido o valor do DSCP contido no pacote IP e com base na classificação local, o pacote recebe determinado tratamento.
Atualmente, este tipo de serviço é largamente utilizado nas redes de dados, sendo esta proposta para o controle de qualidade para redes convergentes.
De acordo com a marcação do pacote, o elemento de rede o classifica e encaminha a determinada fila interna para tratamento. Diversos tipos de filas e tratamentos podem ser dados ao pacote com base em sua criticidade (KAPPLER, 2012).
Dessa forma, é necessário configurar todos os elementos de rede ao longo do caminho que o pacote irá trafegar, pois como visto, seu comportamento é por salto (PHB). Caso um destes elementos esteja com a configuração indevida, o pacote poderá ser tratado erroneamente, acarretando na má classificação e incorreta manipulação do pacote localmente e pelos elementos de redes subsequentes (LI et al., 2012).
Com este tipo de implementação, dados prioritários são processados com outros dados prioritários, podendo haver descarte indevido, caso este ocorra.
O que este modelo não contempla, assim como nos demais citados, é a isolação do tráfego, o qual trafega com todos os demais dados não prioritários, sendo eles de dados não prioritários como Internet e outros serviços de clientes no mesmo canal de comunicação (LI et al., 2012).
Embora a proposta deste trabalho seja o uso do campo DSCP assim como neste modelo, o campo DSCP será utilizado como base de classificação do pacote, que será programado no controlador OpenFlow para analisar determinado valor de DSCP e encaminhar o fluxo para outro caminho desejado, também programado no controlador OpenFlow.
Assim, o tráfego é separado e encaminhado de acordo com sua criticidade e necessidade, isolando-o do resto da rede.
Semelhante a este processo, são as chamadas L3 MPLS VPN (Layer 3 MPLS
Virtual Private Networks), que não serão tratadas neste trabalho devido ao escopo
delimitado.
2.5 Redes Virtuais Embarcadas
Este modelo visa a implementação de uma rede virtualizada sugerindo a separação do plano de controle do plano de dados. É um modelo de rede com plano de controle descentralizado, permitindo a operadoras de serviços terem melhor SLA (Service Level Agreement) e controle dos processos dentro de uma rede de computadores. (KELLER et al., 2009)
Para KELLER et al. (2009) a proposta é de implementar roteadores emulados em servidores, usando-os em forma de máquinas virtuais. Cada máquina virtual emularia um determinado provedor de serviço. As interfaces de rede seriam utilizadas como interfaces de entrada e saída dos roteadores.
O emulador de roteadores virtuais proposto em KELLER et al. (2009), pelo fato de ser implementado através de interfaces de comunicação de dados de uso em PC (Personal Computer), insere limitações no processamento de pacotes como determinados protocolos de roteamento, protocolos de contenção de loops como o STP (Spanning Tree Protocol), redes MPLS, entre outras limitações que não são observadas no OpenFlow.
Este modelo de virtualização de elementos de rede mostra-se limitado para finalidades acadêmicas e de uso profissional controlado, uma vez que não é compatível com os elementos de rede existentes em uso.
Conforme BIANCO et al. (2010), com o OpenFlow é possível utilizar os mesmos equipamentos de rede existentes, desde que seu software de controle possua suporte para o padrão OpenFlow, podendo usar os mesmos elementos para redes OpenFlow e para redes legadas, permitindo assim determinado equipamento funcionar em ambos tipos de redes.
Da mesma forma descentralizada, o OpenFlow permite operações de larga escala e processamento (criação / alteração / exclusão) de fluxos simultaneamente. Por se basear em padrão aberto e ser instalado em sistemas operacionais livres como Debian, Ubuntu, entre outros, permite seu uso tanto acadêmico como profissional (SALVADORI et al., 2011).
Pelo fato do OpenFlow ser um protocolo extensível, permite que sejam inseridos novos padrões de análise / classificação de dados, permitindo também sua adaptabilidade a novos protocolos e arquiteturas que podem ser concebidas futuramente (MCKEOWN et al., 2008).
Embora a proposta de KELLER et al. (2009) possa ser considerada para aplicações restritas, o OpenFlow se caracteriza por ser mais extensível, adaptável e escalável, permitindo seu uso em redes tanto acadêmicas quanto em redes de produção de provedores de serviços e data centers.
Devido a necessidade de escalabilidade das redes e a busca por custos cada vez menores, a separação do plano de dados com o plano de controle está cada vez maior, vemos isso com o OpenFlow, com a proposta de KELLER et al. (2009) e DORIA et al. (2010). Dentre outras pesquisas realizadas, a separação dos planos está se consolidando e se tornando uma tendência nas redes de computadores.
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.
