GT-ATER: Aceleração do Transporte de Dados com o
Emprego de Redes de Circuitos Dinâmicos
RT1 - Termo de referência e estado da arte
Sand Luz Corrêa
Kleber Vieira Cardoso
05/02/2013
1. Introdução
Em NRENs (National Research and Education Networks) como APAN, Internet2, ESnet,
GÉANT, CLARA e RNP, a necessidade de transportar de maneira confiável e eficiente grandes
volumes de dados é sempre crescente. Grande parte dessa necessidade é justificada pela
existência de equipamentos e aplicações em áreas como Física, Meteorologia, Medicina e
Computação que, ao evoluírem, demandam maior capacidade de transmissão de dados.
Portanto, há uma demanda crescente por largura de banda e uso efetivo dessa capacidade.
Por outro lado, é bastante conhecida a dificuldade do TCP de acompanhar a ampliação da
capacidade da rede, sobretudo devido aos altos valores do produto largura de bandaatraso[1,2]. Atualmente, há várias abordagens para melhorar o desempenho do TCP em redes
de alta capacidade como, por exemplo, conexões TCP em paralelo [3,4], UDT [5], logística em
rede [6] e mecanismos de controle de congestionamento especializados [7,8,9,10]. Quando
uma rede de backbone suporta a criação de circuitos dinâmicos, uma nova abordagem passa a
estar disponível. Os circuitos dinâmicos podem ser usados como atalhos dentro da rede, onde
o produto largura de banda-atraso é reduzido pela remoção de parte dos atrasos de
enfileiramento.
Atualmente, a RNP oferece, através do Serviço Experimental CIPÓ (SE-CIPÓ) [11], uma
maneira dos usuários solicitarem a criação de circuitos sob demanda. O intuito do GT-ATER é
desenvolver um serviço para transporte de grandes volumes de dados através de circuitos
dinâmicos criados automaticamente a partir de regras de encaminhamento. Este serviço foi
denominado de ATER (Aceleração do Transporte de Dados com o Emprego de Redes de
Circuitos Dinâmicos). O serviço ATER fará uso do SE-CIPÓ para o aprovisionamento de
circuitos fim-a-fim para o tráfego selecionado.
Este relatório apresenta o resultado de um trabalho de levantamento do estado da arte em
áreas importantes para o desenvolvimento do serviço ATER. Em especial, o levantamento se
concentra no estudo de soluções eficientes para o encaminhamento e filtragem de pacotes,
soluções para o controle de regras de encaminhamento e um estudo sobre as tecnologias
usadas no SE-CIPÓ.
Este documento está organizado da seguinte forma. A Seção 2 apresenta os objetivos
deste projeto e descreve uma arquitetura de alto nível definida para a implementação do
serviço ATER. A Seção 3 discute soluções para a implementação dos componentes da
arquitetura definida na Seção 2. A Seção 4 finaliza este relatório apresentando trabalhos
similares ao proposto pelo serviço ATER.
2. Descrição do projeto
2.1
Objetivos
Atualmente, os usuários da RNP podem solicitar o estabelecimento de circuitos virtuais
dinâmicos através do SE-CIPÓ. Acessando uma interface Web, o usuário indica as
extremidades de origem e de destino do circuito, assim como os horários em que deseja o
estabelecimento desse circuito. Em geral, essas extremidades são definidas através da
indicação do equipamento (normalmente um switch), porta do equipamento e, geralmente,
2
identificador de VLAN. Apesar do SE-CIPÓ atender uma ampla gama de necessidades,
algumas demandas importantes ainda não são contempladas, por exemplo:
•
Não é possível ativar circuitos automaticamente a partir do perfil de tráfego. Esse tipo
de demanda é importante em cenários em que o usuário não é capaz de determinar
quando uma transmissão de dados deve ter início. Por exemplo, o mecanismo de
sincronização de grandes storages pode ser ativado de maneira não determinística.
•
Não é possível filtrar os dados que serão transmitidos pelo circuito. O SE-CIPÓ
estabelece um circuito entre duas redes, ficando a cargo do usuário definir o que deve
fluir através do circuito dinâmico. Ou seja, caso o usuário tenha interesse em
encaminhar apenas fluxos específicos, ele deverá implementar essa filtragem.
O objetivo desse projeto é oferecer um serviço que permita aos usuários da RNP
solicitarem circuitos dinâmicos de maneira automatizada através da definição de regras para
identificação do perfil do tráfego. Apenas o tráfego que combinar com as regras definidas deve
ser enviado através de circuito dinâmico criado sob demanda, enquanto o restante é enviado
pela rede IP convencional. Inicialmente, o objetivo é atender usuários que tenham necessidade
de realizar transporte confiável de grande volume de dados. A seguir, descrevemos alguns
requisitos a serem satisfeitos pelo serviço ATER.
•
O usuário acessará uma interface Web na qual informará o perfil do tráfego que deseja
enviar por um circuito dinâmico. Caso queira, o usuário poderá indicar o destino do
circuito, mas essa informação é opcional, uma vez ela que poderá ser extraída dos
próprios pacotes. O perfil do tráfego será descrito através da escolha de regras de
filtragem, ou seja, o usuário escolhe um protocolo (ex.: TCP) e indica as eventuais
informações extras (ex.: porta). Não é necessário indicar quando o circuito deve ser
ativado, pois a ativação ocorrerá sob demanda, quando o tráfego começar a fluir.
•
A duração de um circuito será em fatias (slots) fixas de tempo, cujo tamanho poderá
ser indicado pelo usuário ou definido pelo administrador. Quando uma fatia de tempo
for encerrada e ainda existir tráfego a ser enviado, o serviço poderá solicitar um novo
circuito por mais uma fatia de tempo.
•
O serviço ATER será capaz de encaminhar o tráfego pela rede convencional sempre
que não conseguir reservar um novo circuito, de maneira transparente e sem perda de
dados.
•
Quando o usuário não desejar mais utilizar uma regra, pode simplesmente removê-la.
A regra garante que apenas o perfil do tráfego definido será transportado através do
circuito. Como o esquema de regras é flexível, o usuário pode escolher enviar desde
todo o tráfego entre duas redes até um fluxo bastante específico.
•
A autorização para que uma regra seja efetivamente ativada deverá ser fornecida pela
equipe de operação da RNP, semelhante ao que é realizado no SE-CIPÓ. Assim, um
administrador acessará a interface Web oferecida pelo serviço ATER, porém com
privilégios especiais. A interface oferecida ao administrador o permitirá autorizar regras
solicitadas e também criar regras. A criação de regras pelo administrador permite que o
serviço seja mais transparente para o usuário final, pois seu tráfego pode ser
transportado por um circuito dinâmico sem que ele tome conhecimento.
3
•
O administrador poderá ativar uma regra ou apenas solicitar seu monitoramento. No
modo de monitoramento, a regra não pode dar origem a um circuito dinâmico, mas
todo tráfego que casar com a regra será contabilizado. Assim, após um tempo
determinado pelo administrador, ele poderá verificar a quantidade de fluxos, número de
pacotes por fluxo e número de pacotes totais, duração de cada fluxo e duração média,
vazão por fluxo e vazão média. Essas informações podem ser usadas para subsidiar a
decisão de ativar ou não a regra solicitada. Essas informações também estarão
disponíveis quando a regra for ativada, podendo ser utilizadas para decidir pela
continuidade ou remoção da regra. Além disso, caso observe algum indício de tráfego
que envolva grande volume de dados, o administrador pode criar regras de
monitoramento e usar as informações para antecipar a demanda dos usuários.
•
Por fim, o administrador pode também mudar o nível de um usuário para gerente local,
permitindo que suas regras sejam ativadas sem a necessidade de intervenção do
administrador.
2.2
Solução Proposta
A Figura 1 ilustra os dois tipos de equipamentos que o serviço ATER fará uso: um servidor e
um intermediário. No servidor, doravante chamado de CORE (Circuit Operation and Rule
Establishment), será hospedado o núcleo do serviço, ou seja: o controle de acesso dos
usuários e dos administradores, a solicitação para criação de circuitos dinâmicos, o
armazenamento do resumo das estatísticas de tráfego, a comunicação com o serviço de
circuitos dinâmicos da RNP e o controle remoto dos equipamentos intermediários. Nos
equipamentos intermediários, denominados RACEs (Rule Applier and Circuit Endpoint),
estarão as regras e a configuração para estabelecer a conectividade entre as extremidades dos
circuitos dinâmicos.
Figura 1: Arquitetura do Serviço ATER
Um RACE pode ser implementado em um computador convencional com algumas
interfaces de rede. Inicialmente, duas interfaces do equipamento são colocadas em modo
ponte (bridge), fazendo com que o encaminhamento seja realizado na camada de enlace. Essa
abordagem ajuda a tornar um RACE transparente aos demais equipamentos no mesmo
4
segmento de rede. Normalmente, os RACEs trabalharão aos pares, sendo coordenados pelo
CORE para formar as extremidades dos circuitos dinâmicos. Quando um circuito dinâmico se
torna disponível, o RACE de origem inicia o processo de reencaminhamento do tráfego de
acordo com a regra que recebeu do CORE. O reencaminhamento pode ser realizado
logicamente, acrescentando a etiqueta (tag) de VLAN que identifica o circuito, ou fisicamente,
através de envio por outra interface de rede, conforme ilustrado na Figura 1. Em ambas as
soluções, o endereço MAC dos pacotes também será alterado para refletir o RACE que está na
outra extremidade do circuito. O RACE de destino realiza a tarefa complementar de remover a
etiqueta de VLAN adicionada pelo serviço ou simplesmente encaminhar o pacote para o
destino final. Novamente, é necessário substituir o endereço MAC para o valor adequado.
Assim, os RACEs funcionam como comutadores de nível 2 (switches) que escondem os
circuitos dinâmicos das redes que estão nas bordas.
Cada RACE mantém uma conexão segura com o CORE a partir da qual recebe toda a
configuração necessária e pela qual informa sobre o tráfego que casa com alguma regra, envia estatísticas de uso e relatórios de operação. O canal seguro também é usado para
monitorar a disponibilidade de todos os componentes do serviço. Caso algum RACE não
consiga estabelecer a comunicação segura com o servidor após algum tempo, todas as regras
são desativadas e o equipamento passa a funcionar como um comutador (switch) simples,
reencaminhando de maneira convencional todos os pacotes. Do lado do CORE, a ausência de
algum RACE significa que novos circuitos não podem ser iniciados ou terminados naquela
localidade.
Após a aprovação de uma regra, é tarefa do CORE estabelecer um circuito dinâmico assim
que é informado sobre o surgimento de tráfego que atenda à referida regra. Para isso, o CORE
entra em contato com o SE-CIPÓ e solicita a criação do circuito.
3. Tecnologias Envolvidas
Com base na solução descrita na seção anterior, os componentes de software que irão compor
o serviço ATER são apresentados na Figura 2. Os principais componentes são descritos a
seguir.
1. Módulo Web: sistema instanciado no CORE que permite a criação e gerência de regras
de forma simples e amigável.
2. Módulo de Criação de Circuitos: componente instanciado no CORE, responsável pela
comunicação com o SE-CIPÓ para a criação de circuitos dinâmicos.
3. Módulo de Encaminhamento e Filtragem: componente instanciado no RACE,
responsável pela aplicação das regras e tratamento do tráfego nas extremidades de
um circuito virtual.
4. Coleta de Estatística: componente instanciado no CORE e no RACE que permite a
coleta de estatísticas do serviço para auxiliar o administrador em tomadas de decisão
envolvendo a criação e manutenção de regras.
5. Canal Seguro: camada de software que permite a comunicação segura entre CORE e
RACE e vice-versa.
5
Figura 2: Componentes de Software do Serviço ATER
A seguir, são discutidas as principais tecnologias que serão empregadas no
desenvolvimento de cada componente de software listados na Figura 2, bem como a forma de
comunicação entre esses componentes. Também serão discutidas algumas tecnologias
utilizadas pelo SE-CIPÓ, que é contatado pelo Módulo de Criação de Circuitos do serviço
ATER.
3.1
SE-CIPÓ
A RNP oferece a possibilidade do uso de circuitos dinâmicos em seu backbone através do SECIPÓ. Como mostrado na Figura 3, atualmente, esse serviço é composto por três ferramentas
principais: DRAGON (Dynamic Resource Allocation via GMPLS Optical Networks)[12],
OSCARS (On-demand Secure Circuits and Advance Reservation System) [13] e MEICAN
(Management Environment of Inter-domain Circuits for Advanced Networks) [14].
O nível mais baixo da arquitetura do serviço é composto pelo DRAGON. Essa
ferramenta é responsável pelo estabelecimento do circuito e aprovisionamento dos recursos de
rede através de tecnologias heterogêneas. O DRAGON utiliza GMPLS (Generalized
Multiprotocol Label Switching) em sua arquitetura e seu plano de controle é composto por dois
elementos principais: NARB (Network Aware Resource Broker) e VLSR (Virtual Label Switch
Router). O primeiro elemento usa OSPF (Open Shortest Path First-Traffic Engineering) para
criar uma visão abstrata da topologia intra-domínio, enquanto o segundo elemento traduz
6
comandos GMPLS para protocolos específicos de dispositivos que não têm suporte nativo a
esse protocolo.
No nível intermediário da arquitetura do serviço está o OSCARS, uma ferramenta
desenvolvida pela ESnet com o objetivo de oferecer um serviço seguro de reserva e
estabelecimento de circuitos inter-domínio. A comunicação inter-domínio é possível pela
implementação do protocolo IDCP (Inter Domain Controller Protocol).
Ao contrário do
DRAGON, o OSCARS provê suporte à criação e políticas de usuário, bem como ao
agendamento de reservas de circuito a serem estabelecidos em um determinado período. As
reservas podem ser solicitadas através de uma interface Web ou através de chamadas a Web
Services. Em ambos os casos, a solicitação é verificada por um serviço de autenticação.
O nível mais alto da arquitetura do SE-CIPÓ é composto pelo MEICAN. Este é um
sistema Web desenvolvido pelo Grupo de Redes de Computadores do Instituto de Informática
da Universidade Federal do Rio Grande do Sul (UFRGS), para atuar como uma solução de
front-end no gerenciamento de reservas de circuitos dinâmicos. O MEICAN se comunica com o
OSCARS, através de sua API Web Services, para realizar operações sobre reservas de
circuitos (criação, consulta, remoção) e consultas a topologias de domínios. Outra
funcionalidade importante do MEICAN é o suporte à criação de políticas de autorização
baseadas em workflow. Esse tipo de suporte facilita a definição de políticas de autorização
específicas de cada domínio.
Figura 3: Principais Ferramentas do SE-CIPÓ
3.2
Módulo Web
O objetivo do módulo Web no ATER é oferecer aos usuários e administradores do serviço um
front-end simples e amigável para criar, manter e gerenciar regras para criação e
estabelecimento de circuitos. Os principais módulos desse sistemas são: gerência de usuários,
gerência de regras, gerência de RACEs e configuração do serviço. Este sistema será
implementado usando CakePHP [15], um arcabouço de código aberto que permite o
desenvolvimento rápido de aplicações Web usando a linguagem de programação PHP. O
CakePHP possui uma série de recursos para o desenvolvimento de aplicações Web:
7
•
adota o padrão MVC (Model - View - Controller);
•
suporta de forma transparente vários sistemas de banco de dados;
•
possui funções para validar entrada de dados em formulários;
•
realiza sanitização de dados para evitar os ataques mais comuns a aplicações Web
(CSRF, XSS, SQL injection);
•
permite geração automatizada e semi-automatizada de código;
•
possui nativamente recursos de internacionalização, autenticação/autorização, ACL;
•
é extensível através de plugins personalizados ou bibliotecas de terceiros.
O módulo Web a ser desenvolvido seguirá o padrão MVC. Esta arquitetura divide uma
aplicação em três camadas principais. A primeira camada, denominada model, representa os
dados e as regras de negócio da aplicação; a segunda camada, denominada view, é
responsável pela apresentação dos dados, enquanto que a terceira camada, denominada
controller, faz a mediação de entradas em comandos para as duas camadas anteriores. A
adoção do padrão MVC neste projeto é justificada pelo fato dessa arquitetura ser uma das mais
bem sucedidas no desenvolvimento de aplicações Web, sendo também a arquitetura mais
utilizada nos arcabouços de desenvolvimento disponíveis para esse tipo de aplicação. Além
disso, a arquitetura MVC provê benefícios como:
•
separação de interesse;
•
modularidade;
•
prototipação rápida;
•
facilidade de manutenção.
Todas os dados gerados ou mantidos pelo módulo Web serão persistidos em um banco de
dados relacional. O gerenciador de banco de dados escolhido foi o PostgreSQL [16], por se
tratar de um software de código aberto maduro e robusto, possuindo também uma comunidade
de desenvolvedores consolidada. O PostgreSQL possui vários recursos que atendem as
necessidades desse componente do serviço ATER, entre eles:
•
possui suporte a chave primária e estrangeira, joins, views, triggers e procedimentos
armazenados;
•
suporta conjunto de caracteres internacionais, com codificação de caracteres multibyte
(Unicode);
•
implementação de SQL compatível com o padrão ANSI-SQL:2008;
•
possui uma linguagem procedural própria para procedimentos armazenados (PLpgSQL);
8
•
possui recursos de nível corporativo, como: recuperação Point-in-Time, utilização de
tablespaces, replicação assíncrona, backup
online e registro de transações
sequenciais;
Outra vantagem do PostgreSQL é o fato da linguagem de programação PHP suportar
nativamente esse gerenciador de banco de dados, facilitando a integração entre o CakePHP e
o banco de dados onde as informações ficarão armazenadas.
3.3
Módulo de Criação de Circuitos
O serviço ATER é capaz de estabelecer circuitos virtuais através de chamadas ao SE-CIPÓ.
No ATER, o componente responsável pela interação com o SE-CIPÓ é o módulo de criação de
circuitos. Como no MEICAN, o módulo de criação de circuitos irá interagir diretamente com o
OSCAR para realizar operações como criar, consultar ou cancelar reservas de circuitos. Todas
essas operações serão invocadas diretamente da API Web Services provida pelo OSCARS.
Essa API é baseada em SOAP [17] com suporte a segurança WS-SECURITY [18]. A
tecnologia utilizada para implementação de SOAP é Apache Axis2/Java[19], enquanto que A
tecnologia utilizada para implementação de WS-SECURITY é Rampart, um módulo do Axis2
que suporta HTTP sobre SSL (HTTPS).
É importante notar que outra alternativa de comunicação com o SE-CIPÓ seria através
do próprio MEICAN. Ou seja, o serviço ATER executaria sobre o MEICAN, como um usuário
desse serviço. Essa solução, no entanto, foi descartada pois o acesso direto ao OSCARS
permite maior flexibilidade. Além disso, o uso de um software intermediário adicional
aumentaria a complexidade da solução.
3.4
Módulo de encaminhamento transparente e comunicação através de circuitos
dinâmicos
Para realizar o encaminhamento transparente, o projeto do software do RACE tem que atender
duas restrições fundamentais: desempenho e confiabilidade. Uma vez que o sistema
operacional Linux é a plataforma de desenvolvimento, o uso de Linux bridge [24] se apresenta
como a solução mais promissora. Linux bridge é um software que foi inicialmente
implementado há mais de 10 anos e vem sendo utilizado, mantido e atualizado desde então e,
portanto, foi considerado suficientemente confiável para adoção. Além disso, Linux bridge é
implementada em modo núcleo e distribuído em conjunto com o núcleo do sistema operacional
Linux. Esse fato reforça a confiabilidade do software e adiciona o fator desempenho a suas
características. A seguir, Linux bridge é descrita e seu uso dentro do contexto do software
RACE é comentado.
Uma Linux bridge pode ser interpretada como um contêiner para interfaces que
participam de uma ponte (bridge). Cada instância da ponte é representada por uma nova
interface de rede. Todos os dispositivos contidos em uma ponte atuam como interfaces de um
mesmo equipamento, por exemplo, um switch.
Uma ponte retransmite, de forma transparente, o tráfego entre múltiplas interfaces de
9
rede. Ou seja, uma ponte conecta duas ou mais interfaces físicas do tipo Ethernet ou
equivalente (por exemplo, 802.11) para que essas interfaces formem uma única rede Ethernet
lógica. Novamente, o funcionamento é similar a de um switch convencional.
Semelhante a um switch, a Linux bridge pode utilizar o STP (Spanning Tree Protocol)
que, além de prover tolerância a falhas, habilita múltiplas pontes a trabalharem juntas. As
pontes comunicam entre si para descobrir como elas estão interconectadas. Essa informação
poderá ser utilizada para eliminar ciclos e otimizar o encaminhamento de pacotes. Cada ponte
possui uma prioridade e um custo relativos. Cada interface pertencente a uma ponte é
associada com uma porta (número) no STP. Prioridade e custo são utilizados para decidir qual
caminho um pacote deve ser enviado. No serviço ATER, esse recurso não será necessário.
Cada ponte possui os seguintes atributos:
•
tempo de duração (ageing time) - tempo em que os endereços MAC de uma ponte
podem permanecer armazenados sem precisarem ser renovados;
•
tempo de anúncio (hello time) - sempre que esse tempo expira, a ponte envia um
pacote de anúncio (hello packet) para a vizinhança com o intuito de informar que está
ativa;
•
idade máxima (max age) - caso uma ponte não envie um pacote de anúncio dentro do
tempo estipulado nesse atributo, essa passa a ser considerada inativa.
A parte inicial da comunicação através de circuitos dinâmicos consiste em interceptar o
tráfego que não deve seguir através da rede de pacotes convencional. Para implementar essa
funcionalidade novamente a escolha foi uma solução nativa do núcleo do sistema operacional
Linux, conhecida como netfilter. O software netfilter consiste em um arcabouço para filtragem
de pacotes também utilizado, mantido e atualizado há mais de 10 anos. A configuração de
regras do netfilter é frequentemente realizada através de uma ferramenta chamada iptables. No
entanto, como utilizaremos netfilter em conjunto com Linux bridge, faremos uso de outra
ferramenta mais adequada para esse contexto, chamada ebtables [25]. A seguir são
apresentadas mais informações sobre essa ferramenta.
O ebtables atua na camada de enlace, permitindo configurar e manter as tabelas de regras
que inspecionam os quadros Ethernet. As regras instaladas pela ebtables permitem a filtragem
transparente do tráfego de rede enviado através da Linux bridge. Seguem exemplos de
algumas das funções que essa ferramenta oferece:
•
Filtragem Ethernet;
•
MAC NAT - possibilidade de alterar endereços MAC de origem e destino;
•
Brouting - combinar funções de ponte e roteamento em um mesmo conjunto de
interfaces de rede;
•
Envio de pacotes para programas no espaço do usuário, usando socket netlink.
A capacidade de enviar pacotes para programas no espaço do usuário é de especial
interesse no software do RACE. Para acelerar o processo de prototipação e facilitar a
10
realização de testes, depuração e modificação do software do RACE, foi escolhida a API de
raw sockets, em linguagem C, para a implementação da injeção dos pacotes dentro de um
circuito dinâmico e sua correspondente remoção na outra extremidade do circuito. Através do
socket netlink, o código do RACE tem acesso aos pacotes que combinarem com as regras
estabelecidas, podendo modificá-los e reinjetá-los adequadamente. No entanto, os pacotes que
não combinam com as regras são tratados apenas em modo núcleo pelo código da Linux
bridge e do arcabouço netfilter, o qual é devidamente configurado pela ebtables. A Figura 4
ilustra como essas ferramentas serão utilizadas dentro do software do RACE.
Figura 4: Combinação de Linux bridge com netfilter/ebtables a ser utilizada no RACE
3.5
Módulo de coleta de estatísticas
O serviço ATER está sendo desenvolvido para encaminhar fluxos de pacotes através de
circuitos dinâmicos e, portanto, oferece a oportunidade de coletar informações a respeito do
tráfego encaminhado. De fato, o serviço ATER será capaz de coletar informações sobre o
tráfego que potencialmente poderia ser encaminhado mesmo quando os pacotes não são
enviados através de circuitos dinâmicos. Essa funcionalidade estará disponível através de
regras de monitoramento, as quais poderão auxiliar administradores do serviço na decisão de
criar ou autorizar regras efetivas de encaminhamento do tráfego.
No serviço ATER, o intuito é permitir a coleta de estatísticas referentes a pacotes
encaminhados efetivamente e também dos que potencialmente poderiam ter sido enviado
através de circuitos dinâmicos. Ou seja, o serviço ATER armazenará informações sobre o
número de pacotes potencial e efetivamente transmitidos em cada circuito, a vazão média de
cada circuito dinâmico e a vazão média agregada. Futuramente, o serviço ATER poderá
oferecer outras estatísticas como número de fluxos encaminhados e vazão por fluxo, porém a
coleta dessas informações exige processamento adicional e exige otimizações para impedir
que o desempenho do serviço seja comprometido.
Uma vez que o serviço ATER é composto de duas partes principais, CORE e RACEs, é
necessária uma solução para coletar de maneira distribuída as estatísticas e, posteriormente,
agrupá-las de maneira centralizada. A coleta das estatísticas deve ser realizada onde o tráfego
flui, ou seja, nos RACEs e então encaminhada para o ponto central de operação do serviço, ou
seja, para o CORE. A partir do CORE, as estatísticas poderão então ser consultadas e
analisadas. Para implementar a coleta distribuída e a persistência centralizada das estatísticas,
11
foi escolhida a ferramenta OML [26] que é descrita a seguir.
A OML (OMF Measurement Library) permite definir pontos de medição (MP - Measurement
Points) dentro de aplicações novas ou que já existem. Os dados gerados pelas aplicações a
partir dos MPs são chamados de fluxos de medição (MS - Measurement Streams) e podem ser
enviados para pontos de coleta remotos para armazenamento em base de dados. A OML é
composta por potencialmente 3 componentes: cliente, servidor e proxy, sendo esse último
opcional. A Figura 5 ilustra esses 3 componentes no contexto do serviço ATER, os quais são
comentados a seguir.
Figura 5: Uso do OML no serviço ATER
O cliente OML é uma biblioteca implementada originalmente em linguagem C e,
atualmente, com implementações nativas em Python e Ruby. A biblioteca oferece uma API
para a coleta de medições e um mecanismo de filtragem configurável dinamicamente que
permite realizar algum processamento em cada MS antes de enviá-lo para o servidor OML.
O servidor OML é responsável por receber as coletas enviadas pelos clientes OML e
armazená-las em uma base de dados. Atualmente, o servidor OML suporta os sistemas
SQLite3 e PostgreSQL.
Em alguns cenários, um cliente OML pode não ter acesso ao servidor OML durante um
período de tempo, ainda que informações estejam sendo coletadas. A ausência temporária de
conectividade entre cliente e servidor OML pode surgir de questões como problemas na
infraestrutura de comunicação, intermitência do canal de comunicação ou necessidade de adiar
a transferência das coletas para evitar concorrência com transmissões mais críticas ou
simplesmente para melhorar a eficiência através do envio de maior volume de dados. Para
tratar esse tipo de cenário, é possível utilizar o proxy OML que funciona como um
armazenamento temporário e limitado de medidas. No serviço ATER, o proxy OML pode ser
útil para garantir o armazenamento de informações mesmo que ocorra problemas de
conectividade entre RACEs e CORE, e também permite uso mais eficiente do canal de
comunicação permitindo que as estatísticas sejam enviadas apenas quando uma quantidade
relevante seja coletada.
Por fim, é interessante destacar que a OML é flexível e permite que novas estatísticas e
12
MPs sejam incluídos nos RACEs. Assim, é possível modificar ou ampliar o conjunto de
estatísticas que serão coletadas pelo serviço ATER.
3.6
Canal Seguro
Um elemento fundamental na arquitetura do serviço ATER é a existência de um canal seguro
através do qual CORE e RACEs podem se comunicar. No ATER, os RACEs se comunicam
com o CORE para notificar a existência de tráfego que casa com uma regra instalada e para
enviar estatísticas do serviço para o CORE. De maneira análoga, o CORE também se
comunica com os RACEs para instalar regras nesse equipamentos e notifica-los sobre o
estabelecimento de circuitos. Um exemplo de sequência de chamadas entre CORE e RACE é
mostrada na Figura 6.
Figura 6: Sequência de mensagens entre CORE e RACE
No ATER, o canal seguro será implementado usando o paradigma de execução
remota. Esse paradigma foi adotado por ser uma abordagem simples que permite prototipação
rápida, ao mesmo tempo que facilita uma evolução para modelos de comunicação mais
sofisticados, como Web Services e MOM (Message Oriented Middleware).
Para implementar o canal seguro entre RACEs e CORE será usada a biblioteca
libssh2[20]. Esta é uma biblioteca que implementa o protocolo SSH2 para clientes escritos na
linguagem C. Adicionalmente, existe também um wrapper dessa biblioteca para clientes PHP, o
qual será usado para implementar a comunicação entre CORE e RACEs.
13
A seguir, são apresentadas algumas iniciativas mundiais similares ao serviço ATER, ou
seja, que tentam aproximar o usuário de aplicações científicas de sistemas de provisionamento
de banda, sob demanda, que operam no núcleo da rede.
4. Trabalhos Relacionados
4.1
Lambda Station
Uma das primeiras iniciativas para conectar usuários finais de aplicações científicas a redes de
provisionamento dinâmico de banda foi o projeto Lambda Station [21], idealizado pelo Fermi
Lab (Fermi National Accelerator Laboratory) e o Instituto de Tecnologia da Califórnia. Este
projeto consistia no desenvolvimento de um conjunto de serviços de rede para selecionar,
admitir e encaminhar tráfego entre clusters de computadores através de redes de longa
distância.
Ao receber requisições de aplicações locais que demandam caminhos de rede com
grande largura de banda, o Lambda Station negocia tais caminhos com um sistema de
provisionamento da WAN, a qual pode ser tanto um canal SONET (Synchronous Optical
Networking), quanto uma rede de circuitos dinâmicos. Havendo caminho disponível, o Lambda
Station se coordena com um serviço par no destino e reconfigura dinamicamente a
infraestrutura da rede local para encaminhar o tráfego da aplicação por esse caminho. O
tráfego pode ser encaminhado seletivamente, sendo a identificação do fluxo feita através de
DSCP (Differentiated Services Code Point).
4.2
TeraPaths
TeraPaths [22] é um projeto financiado pelo Departamento de Energia dos Estados Unidos. O
projeto foi concebido para tratar aplicações da área de física nuclear e altas energias que
necessitam transferir grandes quantidades de dados experimentais através de redes de alta
velocidade espalhadas pelo mundo.
Para diferenciar o tráfego de aplicações científicas e priorizar o seu encaminhamento, o
projeto TeraPaths propõe a criação de caminhos virtuais fim-a-fim que possam dar garantias de
qualidade de serviço (banda) para as aplicações. Para atingir esse objetivo, o TeraPaths
combina o uso de redes locais baseadas em DiffServ e redes de longa distância baseadas em
túneis MPLS. As redes locais de cada extremidade da comunicação são controladas por um
módulo denominado Controlador de Domínio, enquanto que os dispositivos dessas redes estão
sob controle de um ou mais Controlador de Dispositivo. A coordenação de todos os domínios
de rede envolvidos em uma rota é feita por um módulo de Serviço Distribuído. Este módulo
inicia seu serviço interagindo com os Controladores de Domínio para configurar o caminho,
prosseguindo para a interação com cada controlador de domínio das WANs envolvidas. Essa
interação entre o módulo de Serviço Distribuído e o controlador de domínio da WAN é feita
através de um proxy que exporta uma interface padrão para o TeraPaths, abstraindo a
interface de comunicação do controlador da WAN.
14
4.3
Science DMZ
Uma das iniciativas mais recentes relacionadas à otimização de transferência de dados
científicos é o Science DMZ [23]. Desenvolvido pela ESnet, este é um modelo de projeto de
rede para instituições de pesquisa que precisam de um ambiente customizado para aplicações
científicas que demandam alto desempenho computacional. Esse modelo é fundamentado em
quatro conceitos principais:
•
uma arquitetura de rede explicitamente projetada para aplicações de alto desempenho,
onde a rede para aplicações científicas é diferente das redes de propósito geral;
•
o uso de sistemas dedicado para transferência de dados;
•
o uso de métricas de desempenho para caracterizar a rede e diagnosticar problemas;
•
o uso de políticas de segurança customizadas para o ambiente em questão.
Para atingir seu objetivo, o modelo Science DMZ é composto por vários componentes,
incluindo acesso dedicado a redes de longa distância e de alto desempenho (geralmente
controladas pelo OSCARS), equipamentos com grande espaço em buffers, e nós dedicados à
transferência de dados. Esses nós são conectados diretamente a um switch Science DMZ, o
qual é conectado diretamente ao roteador de borda. A conexão direta do switch Science DMZ
ao roteador de borda é feita com o intuito de minimizar o número de componentes que devem
ser configurados para suportar transferências de alto desempenho. Adicionalmente, o controle
de acesso aos nós de transferências é feito pelo próprio switch Science DMZ e não por um
firewall separado.
4.4
Logística em Redes
O conceito de logística em redes consiste em alocar dinamicamente armazenamentos
temporários na rede como uma forma de provisionamento do meio de comunicação [27].
Quando aplicado ao protocolo TCP, esse conceito pode apresentar ganhos de desempenho
porque o RTT (Round-Trip Time) entre os equipamentos intermediários é menor que o RTT
fim-a-fim. Assim, o mecanismo de controle de congestionamento de cada conexão TCP age de
forma mais eficiente. Dessa forma, cada conexão TCP consegue aumentar sua vazão mais
rapidamente, aproveitando de maneira mais eficiente a capacidade disponível. Além disso, a
retransmissão de um pacote perdido é feita a partir da extremidade mais próxima, a qual está
sempre menos distante que as extremidades fim-a-fim.
O protótipo de um serviço de logística em redes já foi implementado na RNP pelo GTTravel [28]. A utilização do serviço proposto se baseava na disponibilização de arquivos em
servidores Web e na transferência desses arquivos por clientes convencionais, como
navegadores. Pelo menos umas das extremidades precisava ser configurada para utilizar o
serviço, servidor ou cliente. Para uma maior transparência na utilização do serviço, foi
desenvolvida uma extensão para os navegadores Web Firefox que minimizava a necessidade
de configuração por parte dos usuários, tornando-os não conscientes do uso do serviço.
15
A implementação do serviço consistiu na instalação de uma rede sobreposta à rede da RNP
que tinha como função segmentar conexões TCP entre servidores e clientes de forma a
aumentar o desempenho na transferência de dados. Para o encadeamento de conexões entre
equipamentos escolhidos pela rede sobreposta, foi definido um procedimento de sinalização
HTTP entre os clientes, os servidores e os nós da rede. Essa sinalização utilizava o
redirecionamento de URLs do protocolo HTTP, normalmente implementado na maior parte dos
clientes, para o estabelecimento das conexões TCP entre os equipamentos envolvidos.
No fim de 2009, o serviço desenvolvido pelo GT-Travel chegou a transportar mais de
1TB de um servidor-espelho de uma distribuição Linux [29]. Apesar do grande potencial, a
logística em rede possui algumas desvantagens que precisam ser levadas em conta.
Inicialmente, o problema com altos RTTs permanece, o efeito do problema é tratado, mas não
sua causa. A implementação de logística em rede envolve incluir equipamentos no núcleo da
rede que são capazes de processar, no mínimo, até a camada de transporte. Há uma
dificuldade em manter e operar esse tipo de equipamento, sobretudo em grande quantidade,
por exemplo, um por PoP. Além disso, no núcleo da rede, atualmente já há enlaces de 10Gbps
na RNP, exigindo equipamentos mais sofisticados que os computadores tradicionais usados
para enlaces de 1Gbps.
O serviço proposto pelo GT-ATER, conforme descrito previamente, aborda, pelo menos
em parte, a causa do problema de desempenho do TCP, ou seja, o alto BDP. Através dos
atalhos criados pelo serviço, o RTT é reduzido. Além disso, o tráfego pode ser isolado,
reduzindo também as perdas que também afetam o desempenho. Embora não seja explorado
nessa versão inicial do serviço ATER, há a possibilidade de beneficiar outros protocolos de
transporte através do serviço, como UDP, DCCP e SCTP.
4.5
Redes Definidas por Software – OpenFlow
O OpenFlow [30] é considerado a primeira implementação bem sucedida do conceito de redes
definidas por software. O padrão surgiu na Universidade de Stanford como proposta de um
grupo de pesquisadores que buscavam uma forma de testar inovações em protocolos de rede
em uma escala mais realista, e não apenas em pequenos ambientes de laboratório. Os
pesquisadores de Stanford perceberam que uma forma de aumentar a adoção, por parte da
indústria, das novas ideias que nasciam na academia, era realizar testes com esses protocolos
em cenários mais reais. Assim, o protocolo OpenFlow surgiu como uma forma de se realizar
experimentos acadêmicos, validando seu funcionamento e eficiência, utilizando a mesma
infraestrutura que a rede de produção.
O protocolo OpenFlow realiza a manipulação de tabelas de fluxo em computadores
(switches) de nível dois. Para isso a camada de operação e gerência do equipamento (control
plane) é modificada para incluir suporte ao protocolo. A manipulação das tabelas de fluxo é
feita com a ajuda de um elemento externo chamado de controlador, que realiza a instalação de
regras de encaminhamento de fluxos na camada de comutação de pacotes do switch (data
plane). A Figura 7 ilustra a comunicação entre o switch e o controlador.
16
Figura 7: Comunicação entre switch OpenFlow e controlador
A comunicação entre o switch e o controlador ocorre por meio de mensagens definidas
na especificação do protocolo OpenFlow, usando um canal seguro. As regras de fluxo
instaladas pelo controlador controlam a forma como o switch encaminha os pacotes. Essas
regras são compostas por três partes: 1) tupla contento campos do cabeçalho do pacote; 2)
ação que o switch deve realizar com esse fluxo; e 3) contadores de pacotes e bytes. A Figura 8
apresenta os campos do cabeçalho definidos na versão 1.0 do protocolo OpenFlow [31].
Ingress Ether Ether Ether VLAN VLAN
Port
src
dst
Type
id
prio
IP
IP
IP
src
dst
proto
IP ToS TCP/UDP
bits
TCP/UDP
src port
dst port
Figura 8: Campos do cabeçalho definidos no OpenFlow 1.0
Há uma semelhança significativa entre a base da proposta do GT-ATER e a tecnologia
OpenFlow. De fato, a coordenação do GT acredita que é OpenFlow é a evolução mais provável
do serviço ATER. Atualmente, a equipe tem algumas ressalvas devido a sua experiência com a
tecnologia OpenFlow, conforme descrito a seguir.
Os coordenadores do GT-ATER também participam do projeto FIBRE, no qual lidam
com a tecnologia OpenFlow desde o início de 2012. A experiência com OpenFlow no projeto
FIBRE mostrou que o padrão e as implementações ainda apresentam diferenças importantes.
Enquanto o padrão atual do OpenFlow está razoavelmente maduro em sua versão 1.3, a maior
parte dos fabricantes oferecem apenas versões incompletas do OpenFlow 1.0. As deficiências
nos equipamentos avaliados vão desde pequena quantidade de TCAM,
limitando
excessivamente o número de regras, até ausência de suporte à camada de rede, impedindo
um uso efetivo da tecnologia. Adicionalmente, a aquisição de equipamentos OpenFlow no
Brasil ainda apresenta dificuldades significativas, pois poucos fabricantes oferecem
equipamentos com essa tecnologia, as equipes técnicas e de venda não estão treinadas e o
custo é muito elevado. A solução é a importação que tradicionalmente consome um longo
tempo.
Com a adoção crescente da tecnologia OpenFlow, a equipe do GT-ATER acredita que
nos próximos anos os problemas apresentados serão amenizados e o uso efetivo de
equipamentos OpenFlow se tornará viável. As ações realizadas por grandes fabricantes de
hardware sinalizam nessa direção, com a previsão de novos produtos ou novas versões de
firmware agendadas ao longo de 2013 e 2014.
17
Referências
[1] V. R. B. Jacobson. “RFC 1072 – TCP extensions for long-delay paths,” IETF Request for
Comments. 1988.
[2] T. V. Lakshman and U. Madnow. “The performance of TCP/IP for networks with high
bandwith-delay product and random loss,” IEEE/ACM Transactions on Networking. 1997.
[3] H. Sivakumar, S. Bailey, and R. L. Grossman, “PSockets: The Case for Application-level
Network Striping for Data Intensive Applications using High Speed Wide Area Networks,” in
ACM/IEEE Conference Supercomputing, p. 38, nov. 2000.
[4] T. Hacker, B. Athey, and B. Noble, “The end-to-end performance effects of parallel TCP
sockets on a lossy wide-area network,” in International Parallel and Distributed Processing
Symposium, pp. 434–443, 2002.
[5] Y. Gu and R. L. Grossman, “UDT: UDP-based data transfer for high-speed wide area
networks,” Computer Networks, vol. 51, pp. 1777–1799, may 2007.
[6] D. M. Swany and R. Wolski, “Data Logistics in Network Computing: The Logistical Session
Layer,” in IEEE International Symposium on Network Computing and Applications, vol. 2, pp.
174–185, oct 2001.
[7] D. Katabi, M. Handley, and C. Rohrs, “Congestion control for high bandwidth-delay product
networks,” ACM SIGCOMM Computer Communication Review, vol. 32, no. 4, pp. 89–102,
2002.
[8] L. Xu, K. Harfoush, and I. Rhee, “Binary increase congestion control (BIC) for fast longdistance networks,” in INFOCOM 2004. Twenty-third Annual Joint Conference of the IEEE
Computer and Communications Societies, vol. 4, pp. 2514–2524, mar 2004.
[9] C. Jin, D. Wei, and S. Low, “FAST TCP: motivation, architecture, algorithms, performance,”
in INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and
Communica- tions Societies, vol. 4, pp. 2490–2501, mar 2004.
[10] S. Ha, I. Rhee, and L. Xu, “CUBIC: a new TCP-friendly high-speed TCP variant,” ACM
SIGOPS Operating System Review, vol. 42, pp. 64–74, jul 2008.
[11] RNP, “SE-CIPÓ.”
http://wiki.rnp.br/display/secipo/Home [Último acesso: 05-Fevereiro-
2013].
[12] Xi Yang, C. Tracy, J. Sobieski, T. Lehman, "GMPLS-Based Dynamic Provisioning and
Traffic Engineering of High-Capacity Ethernet Circuits in Hybrid Optical/Packet Networks," in
INFOCOM 2006. 25th IEEE International Conference on Computer Communications.
Proceedings , vol., no., pp.1-5, 23-29 April 2006.
[13] C. P. Guok, D. W. Robertson, E. Chaniotakis, M. R. Thompson, W. Johnston, B. Tierney,
"A User Driven Dynamic Circuit Network Implementation," GLOBECOM Workshops, 2008 IEEE,
vol., no., pp.1-5, Nov. 30 2008-Dec. 4 2008.
[14] J. J. C. de Santanna, J. A. Wickboldt, L. Z. Granville, L.Z, "A BPM-based solution for interdomain circuit management," Network Operations and Management Symposium (NOMS), 2012
IEEE , vol., no., pp.385-392, 16-20 April 2012.
[15] “CakePHP.” http://cakephp.org [Último acesso: 05-Fevereiro-2013].
18
[16] “PostgreSQL.” http://www.postgresql.org [Último acesso: 05-Fevereiro-2013].
[17] “SOAP Specification.” http://www.w3.org/TR/soap/ [Último acesso: 05-Fevereiro-2013].
[18]
“WS-Security.”
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
[Último acesso: 05-Fevereiro-2013].
[19] “Axis2.” http://axis.apache.org/axis2/java/core/ [Último acesso: 05-Fevereiro-2013].
[20] “libssh2.” http://www.libssh2.org/ [Último acesso: 05-Fevereiro-2013].
[21] ”Lambda Station Project.” http://www.lambdastation.org
[Último acesso: 05-Fevereiro-
2013].
[22] “TeraPaths Project”. https://www.racf.bnl.gov/terapaths/
[Último acesso: 05-Fevereiro-
2013].
[23] ESnet, “Science DMZ – A Scalable Network Design Model for Optimizing Science Data
Transfers.” http://fasterdata.es.net/science-dmz/, 2009. [Último acesso: 05-Fevereiro-2013].
[24]
The
Linux
Foundation,
“Linux
Bridge.”
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge [Último acesso: 05Fevereiro-2013].
[25] “Ebtables”, http://ebtables.sourceforge.net/ [Último acesso: 05-Fevereiro-2013].
[26] “OML-Measurement Library.” http://oml.mytestbed.net/projects/oml/wiki [Último acesso: 05Fevereiro-2013].
[27] Augusto, C. H. P., Silva, M. W. R., Cardoso, K. V., Mendes, A. C., Guedes, R. M., and de
Rezende, J. F. - "Implementação e Avaliação de Encadeamento de Conexões TCP em Redes
de Grande Memória e Altas Perdas", in XXVII Simpósio Brasileiro de Redes de Computadores SBRC´2009, pp. 89-102, Recife, PE, Brazil, May 2009.
[28] “Grupo de Trabalho sobre Transporte de Alta Velocidade”, http://www.rnp.br/pd/gts20072008/gt_travel.html [Último acesso: 13-Março-2013].
[29] “GT-Travel”, http://www.gta.ufrj.br/gt-travel/doku.php [Último acesso: 13-Março-2013].
[30] “OpenFlow”, http://www.openflow.org [Último acesso: 15-Março-2013].
[31] “Especificação 1.0 do Protocolo OpenFlow”, http://www.openflow.org/documents/openflowspec-v1.0.0.pdf [Último acesso: 15-Março-2013].
19