Visão Geral

O ATER foi concebido para realizar a comutação de tráfego entre rede de produção (baseada no modelo melhor esforço) e rede de circuitos dinâmicos (baseada em modelos que oferecem qualidade de serviço). Com o ATER, o usuário continuará utilizando a rede de produção normalmente, porém terá a opção de enviar fluxos de aplicações via rede de circuitos dinâmicos. Para tal, o usuário identificará, através de regras de filtragens, os fluxos que deseja enviar via rede de circuitos dinâmicos. O ATER utiliza regras de filtragem para detectar o tráfego do usuário e realizar a injeção desse tráfego na rede de circuitos dinâmicos.

A Figura 1 apresenta a integração entre o ATER e a rede híbrida da RNP, onde estão disponíveis a rede de produção (rede IPÊ) e a rede de circuito dinâmicos (rede CIPÓ). O ATER possuí dois componentes principais, CORE e RACE. O RACE é composto por um comutador de pacotes baseado em tecnologia OpenFlow, o qual está conectado às três redes: rede do Cliente, rede IPÊ e rede CIPÓ. Cada RACE possuí um controlador dedicado. O CORE é o núcleo de inteligência do serviço e coordena os RACEs aos pares para garantir a comutação dos fluxos de aplicações do usuário.

O usuário insere regras de filtragem através da interface WEB do CORE. O CORE identifica os RACEs que fazem parte da regra de filtragem e os informa que novas regras de filtragem devem ser aplicadas. Os RACEs aplicam as regras de filtragem e passam a identificar o tráfego do usuário. Ao identificar o tráfego do usuário os RACEs informam ao CORE que houve casamento de regra com tráfego e o CORE requisita a criação de um circuito ao OSCARS (componente disponível na rede CIPÓ). Após a criação do circuito com sucesso o CORE informa regras de encaminhamento aos RACEs. Após os RACEs aplicarem as regras de encaminhamento eles estarão aptos a injetar o tráfego do usuário na rede CIPÓ.

Figura 1: Integração entre ATER e rede híbrida da RNP

Arquitetura

A Figura 2 apresenta os módulos de software dos componentes do ATER. Segue abaixo um resumo de cada módulo:

CORE Web: aplicação Web através da qual o usuário pode criar suas regras de acordo com o perfil de seu tráfego, visualizar suas regras criadas e consultar estatísticas sobre suas regras. Os administradores do ATER também utilizam essa aplicação para gerenciar usuários e regras, monitorar estatísticas de tráfego, verificar o estado dos RACEs e configurar o sistema.

CORE Main: é o núcleo do sistema de gerenciamento de regras e circuitos, o qual é composto por dois principais componentes: o Circuit Manager, que é o responsável por coordenar os RACEs no estabelecimento da conectividade entre as extremidades do circuito; e o RACE Checker que implementa no lado do CORE, um protocolo do tipo heartbeat com os RACEs.

CORE OSCARS Driver (COD): módulo de software responsável pela integração com o OSCARS. O COD funciona como um driver para o OSCARS, criando uma abstração mais simples para o restante do sistema e oferecendo um ponto único de acesso à Rede CIPÓ.

CORE Comm: módulo de software instanciado no CORE para implementar um canal seguro, baseado na libssh2, para receber requisições dos RACEs.

RACE Comm: módulo de software instanciado no RACE, para implementar um canal seguro, baseado na libssh2, para receber requisições do CORE.

RACE Daemon: módulo de software responsável pela lógica de filtragem e encaminhamento transparente dos fluxos do usuário. O RACE_Daemon é o controlador OpenFlow e foi criado como uma extensão acoplada ao POX.

Figura 2: Arquitetura de software

Perfis de Usuário

Os usuários do ATER podem ser classificados em três tipos: cliente, gerente local e administradorA seguir são descritas as atividades que podem ser realizadas por cada usuário.

As regras para identificação do perfil de tráfego podem ser definidas pelos clientes, inicialmente usuários de instituições que tenham necessidade de realizar transporte confiável de grandes fluxos de dados, como também por administradores pertencentes à equipe de operação da RNP. A Figura 3 descreve as principais atividades dos usuários com perfil cliente e gerente local.

Figura 3: Principais atividades do cliente e gerente local


Tipos de Regra

No ATER, existem dois tipos de regras:

Independente do tipo da regra, todo o tráfego que casa com ela é contabilizado.

 Além de criar e remover uma regra, ainda é possível modificá-la. Entretanto, atualmente o serviço só permite a modificação do tipo da regra, de monitoramento para efetiva.

 Durante seu ciclo de vida, uma regra pode passar por diferentes estados, dependendo do seu tipo e do componente onde a regra está instanciada. Os componentes que trabalham com as regras atualmente são o CORE e o RACE.

Estado da regra no CORE

A Figura 4 apresenta a máquina de estado da regra mantida internamente no CORE.

Figura 4: Máquina de estado de regra no CORE

 

Pode-se dividir as transições da regra no CORE entre os processos de criação, aplicação e remoção da regra.
O processo de criação da regra contém alguns detalhes que dependem do tipo da regra e do usuário que está criando a regra.

Quando uma regra é considerada aprovada, imediatamente ela assume o estado "processando" (PROCESSING) e o processo para aplicá-la nos RACEs é iniciado. O processo de aplicação tem dois resultados possíveis:

Uma regra pode ser removida quando ela está em qualquer estado, exceto "processando". Nesse processo, algumas verificações acontecem sobre a regra para determinar qual o procedimento correto para sua exclusão.

Quando o usuário solicita a modificação uma regra, a regra assume o estado "processando" e então a modificação é enviada para os RACEs. Caso essa modificação aconteça com sucesso nos RACEs, a regra assume o estado "aplicada" e ação "NEW". Caso contrário, a regra assume o estado "não-aplicada". Entretanto, uma regra só pode ser modificada se ela já tiver sido aplicada, ou seja, quando ela está no estado "aplicada".

 Periodicamente, um componente do serviço tenta reaplicar regras cujas aplicações anteriores foram mal sucedidas. As tentativas são repetidas até que a regra seja aplicada com sucesso. Essa reaplicação acontece com base na ação que foi mal sucedida para a regra, ou seja, a reaplicação pode acontecer para uma regra não aplicada, não modificada ou não removida nos RACEs.

Estado da regra nos RACEs

A Figura 5 apresenta a máquina de estado da regra mantida internamente nos RACEs.

Figura 5: Máquina de estado de regra no CORE

 

No RACE as transições de estado da regra estão condicionadas ao tipo dela.

Independentemente do estado que uma regra se encontra, caso o RACE receba uma solicitação de exclusão da regra, a regra é removida do RACE e o ciclo de vida dela termina.

Conexão de Experimentação

A Figura 6 apresenta o modelo de conexão que é utilizado na fase experimental pelo ATER nos PoPs.

A infraestrutura do ATER nessas localidades é composta de um Switch OpenFlow Datacom DM 4001, de uma VM para o Controlador OpenFlow e de uma VM cliente de testes. O RACE será executado na VM Controlador OpenFlow que possui dois IPs: um IP público para acesso remoto (gerência) e um IP privado para envio de comandos ao Switch OpenFlow. A VM cliente de testes possui dois IPs: um IP público para acesso remoto (gerência) e um IP público para testes isolados.

Uma conexão nível 2 é realizada utilizando a VLAN Cliente_ATER desde o equipamento de testes da instituição do usuário até o Switch OpenFlow. Quando o tráfego do usuário chega no Switch OpenFlow a classificação do tráfego é realizada. Se houver regra de encaminhamento o tráfego do usuário será direcionado para a rede CIPÓ, caso contrário o tráfego será direcionado para a rede IPÉ.

Figura 6: Modelo para implantação dos RACEs nos PoPs da RNP