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.