Descri¸ c˜ ao do problema

volvimento da solu¸c˜ao proposta neste cap´ıtulo, denominada DynTun (Dynamic Tunnels) [Duarte et al. 2008].

A t´ecnica DynTun ´e uma solu¸c˜ao eficiente para o problema demulti-homing em redes mesh que utilizam a t´ecnica NAT. Esta solu¸c˜ao ´e baseada em cria¸c˜ao dinˆamica de t´uneis, marca¸c˜ao l´ogica de pacotes e pol´ıticas de roteamento. Neste cap´ıtulo, ´e apresentada tamb´em uma implementa¸c˜ao concreta da proposta, que possibilitou a avalia¸c˜ao da solu¸c˜ao em duas redes reais. Os resultados dos testes de desempenho mostram que a solu¸c˜ao DynTun preserva a semˆantica das conex˜oes dos usu´arios e tem o potencial de aumentar o desempenho e a escalabilidade da rede, assim como comprovam que o acr´escimo de custo computacional no processamento dos pacotes ´e bastante baixo.

Apesar do DynTun ter sido desenvolvido para a rede Remesh, os crit´erios e me-canismos de implementa¸c˜ao selecionados s˜ao comuns a diversas outras redes de acesso.

Portanto, a solu¸c˜ao ´e potencialmente aplic´avel a outras redes, que enfrentam o conflito entre NAT emulti-homing

O texto deste cap´ıtulo ´e organizado da seguinte forma: na Se¸c˜ao 3.1 o problema de vi-ola¸c˜ao da semˆantica das conex˜oes dos usu´arios ´e detalhado. Na Se¸c˜ao 3.2 s˜ao apresentados alguns crit´erios utilizados para a defini¸c˜ao de uma solu¸c˜ao para suporte a multi-homing.

Na Se¸c˜ao 3.3 s˜ao analisadas algumas propostas existentes para este suporte. Na Se¸c˜ao 3.4 a solu¸c˜ao DynTun ´e apresentada em detalhes. Na Se¸c˜ao 3.5 s˜ao comentados aspectos de implementa¸c˜ao da solu¸c˜ao proposta. Finalmente, na Se¸c˜ao 3.6 s˜ao exibidos os resultados da avalia¸c˜ao realizada, seguidos pelas considera¸c˜oes finais sobre a escalabilidade de redes mesh na Se¸c˜ao 3.7.

3.1 Descri¸ c˜ ao do problema

Em uma rede mesh com mais de um ponto de conex˜ao a Internet, o problema que pode prejudicar os clientes ´e a quebra das conex˜oes de suas aplica¸c˜oes, que ocorre por causa da intera¸c˜ao entre a escolha dinˆamica de rotas e a utiliza¸c˜ao da t´ecnica de NAT. A Figura 3.1 mostra um exemplo do comportamento desej´avel de um protocolo de roteamento no caso de problemas em um enlace. Nela, a rota, utilizada pelo clientemhinicialmente, ´e a mais curta em n´umero de saltos (destacada em negrito) at´e alcan¸car o gateway. Em um dado instante de tempo, ocorre uma falha em um dos enlaces que comp˜oem a rota. Neste instante, o protocolo deve detectar esta falha e alterar o caminho escolhido para uma rota alternativa.

3.1 Descri¸c˜ao do problema 18

Figura 3.1: Exemplo de uma mudan¸ca de rota causada por problemas de conectividade.

Neste cen´ario, usualmente os efeitos sentidos pelo cliente s˜ao uma perda em rajada de alguns pacotes e um potencial breve aumento do atraso fim-a-fim. Isto se deve ao intervalo de tempo necess´ario para que o protocolo de roteamento perceba o problema e conclua a altera¸c˜ao de rota necess´aria. Pacotes enviados pelo cliente ap´os a falha do enlace, por´em antes do completo estabelecimento de uma rota alternativa, provavelmente ser˜ao perdidos. Dependendo do modo de opera¸c˜ao do protocolo utilizado e de seus parˆametros de configura¸c˜ao, este intervalo pode durar v´arios segundos [Engelstad et al. 2004].

A situa¸c˜ao ilustrada pela Figura 3.1, entretanto, ´e v´alida para uma rede com apenas um gateway. Por´em, ao analisarmos uma topologia semelhante, mas composta por dois gateways, ´e poss´ıvel entender o problema potencial. A Figura 3.2 ilustra um cen´ario muito parecido com o anterior. Agora, no entanto, o ponto B tamb´em trabalha como gateway para a Internet (e n˜ao apenas o ponto A).

Considerando novamente que uma falha ocorrer´a em um dos enlaces da rota preferen-cial (em negrito) nesta ´ultima topologia, ´e razo´avel supor que o protocolo de roteamento ir´a agir para contornar o problema, utilizando como nova rota o caminho que passa pelo gateway B. Desta forma quando os pacotes de dados chegarem a B eles ser˜ao encami-nhados para o servidor ch com o endere¸co de B, devido `a t´ecnica NAT, e n˜ao com o endere¸co de A como na antiga rota. Ao serem recebidos por ch, os pacotes poder˜ao n˜ao ser corretamente associados `a sua conex˜ao, causando a quebra da comunica¸c˜ao.

Esta quebra de conex˜ao se deve `a maneira pela qual o protocolo de transporte TCP (Transmission Control Protocol) identifica os fluxos no destino. Uma conex˜ao ´e identifi-cada pela tupla contendo o endere¸co de origem, porta de origem, endere¸co de destino e

3.1 Descri¸c˜ao do problema 19

Figura 3.2: Utiliza¸c˜ao de diversos gateways e a t´ecnica NAT em conjunto.

porta de destino. Desta forma, uma vez iniciada uma conex˜ao, o endere¸co de origem deve se manter fixo. Do contr´ario, o destino n˜ao conseguir´a identificar corretamente a conex˜ao, levando `a quebra da comunica¸c˜ao, conforme ilustrado na Figura 3.2.

Embora neste exemplo ´e utilizado o caso em que um enlace apresenta falhas, a troca degateways pelo protocolo de roteamento pode ocorrer pela pr´opria varia¸c˜ao da qualidade dos enlaces sem fio.

Isto ´e especialmente verdadeiro em redes que trabalham com protocolos que realizam medidas ativas na rede. Diversas m´etricas de roteamento para redesmesh sem fio se valem deste expediente, enviando periodicamente pacotes de controle para avaliar a qualidade dos enlaces. Esta qualidade pode ser mensurada pela taxa de perda de pacotes ou atraso nos enlaces [Couto et al. 2003, Koksal and Balakrishnan 2006]. Portanto, em redes pr´ o-ativas, os pacotes de controle do protocolo de roteamento competem com os pacotes de dados dos clientes. Como conseq¨uˆencia, enlaces possuem a sua avalia¸c˜ao decrescente quanto maior for o n´ıvel de utiliza¸c˜ao pelos clientes.

Pode-se argumentar que uma solu¸c˜ao trivial para o problema de conectividade ´e a n˜ao utiliza¸c˜ao do NAT. Entretanto, existem diversas vantagens t´ecnicas [Ramakrishna 2001]

no emprego do NAT, que s˜ao importantes diante os crit´erios descritos na Se¸c˜ao 3.2.

Desta forma, a busca ou elabora¸c˜ao de outras solu¸c˜oes, que tornem poss´ıvel utilizar NAT emulti-homing, se fazem necess´arias.