Mobilidade sobre IPv6
Escrito por Dairton Luiz Bassi Filho
Mecanismo de handoff no cliente
Apesar do IPv6 fornecer suporte à mobilidade ainda há pontos que podem ser refinados para tornar a comunicação wireless tão sólida e transparente quanto uma rede fixa. Esta seção explora mecanismos que provêem a transição entre redes de forma menos traumática à unidade móvel.
A navegação através de redes estrangeiras não é totalmente transparente, muitas interrupções ocorrem durante a passagem de uma rede para outra. Muitas vezes a unidade móvel perde contato com a rede por onde está e para continuar é preciso conectar-se a outra rede. O objetivo é evitar, ou minimizar, a “quebra” na comunicação permitindo que o host móvel decida quando trocar seu ponto de conexão.
Uma das características previstas no FMIPv6 (Fast Mobile Internet Protocol versão 6) proposto pela IETF é a detecção de movimentos e a minimização da latência no handoff.
Quando o handoff é eminente a unidade móvel continua o trafego pela conexão e inicia o processo de registro em outro roteador. Entretanto, um ponto em aberto neste mecanismo é identificar quando iniciar o processo de handoff.
Uma possível abordagem para disparar um processo de handoff é adicionando algoritmos a entidades da rede, como roteadores e agentes, de forma que percebam o status das unidades móveis enviando avisos para a troca de rede. Esta técnica possui alta complexidade pois requer mudança em componentes da rede.
Uma segunda maneira de tratar este problema é adicionando inteligência no lado do cliente. Assim cada unidade móvel pode decidir quando o handoff é apropriado. Nesta abordagem é criado um Módulo de Handoff (MoH) que gerencia as trocas de rede.
Para identificar os roteadores e realizar o handoff com eficácia o MoH interage com três camadas da rede. A camada de enlace, consultando o status do link. A camada do IPv6 obtendo as informações sobre os Router Advertisements (RA) através do Neighbor Discovery. E com a camada de TCP por onde o status da conexão é acompanhado.
Posição do Módulo de Handoff em relação às camadas de rede
A unidade móvel inicia o processo de handoff sempre que recebe um RA, para evitar handoffs indesejados o MoH filtra os anúncios dos roteadores para evitar conexões com sinal mais fraco e força o handoff sempre que necessário.
Para determinar qual o melhor ponto de conexão é adicionado à unidade móvel um RA cache, que possibilitará estabelecer prioridades para escolher o melhor roteador. Os critérios de seleção de RA são divididos em dois grupos conforme sua importância, os de maior importância são:
- a qualidade do sinal
- o tempo desde a última atualização no RA cachê
Os critérios de menor importância são:
- o número de hops até o roteador
- se o roteador é ou não acessível no link local.
O MoH usa o status da camada de enlace para monitorar a conectividade do link. Isso ajuda a aumentar a velocidade da detecção da desconexão de um link.
Para iniciar um handoff existem dois cenários onde seguramente este processo faz sentido.
Quando o atual ponto de conexão apresenta algum erro ou torna-se inacessível. Neste caso para evitar a perda de muitos dados transmitidos ou que deveriam ser recebidos a unidade móvel deve fazer um Hard Handoff. O handoff é iniciado pelo handler do MoH que monitora o status do link assim que a desconexão é detectada usando a próxima entrada da RA cache.
O segundo caso ocorre quando o handler da camada de enlace detecta problemas com o link, nesta situação um Soft Handoff é iniciado, caso o MoH verifica o status da conexão TCP, se não existir uma conexão TCP o handoff é automaticamente iniciado, se existir alguma conexão, ela pode ser preservada, diminuindo o valor limite de qualidade de sinal. Se a qualidade do sinal continuar a cair e atingir o novo limite o processo de handoff é iniciado, conforme os critérios de prioridade.
O hard handoff oferece um risco potencial de perda de alguns pacotes enquanto o soft handoff, teoricamente, não perde nenhum pacote.
Se em qualquer dos cenários não houver nenhum RA na RA cache, o IPv6 Neighbor Unreachability Detection é invocado para encontrar um novo ponto e conexão.
Handoff rápido para aplicações multimídia e de tempo real
A especificação do IPv6 dá suporte a aplicações multimídia e de tempo real através dos campos
flow e
classe de tráfego do cabeçalho IP. Esta adaptação estimula ainda mais o crescimento deste tipo de aplicação. Na internet os dados dessas aplicações requerem um tratamento adequado para preservar a qualidade do serviço este tratamento é oferecido tratando os dados como um fluxo.
Para atender as requisições de qualidade de serviço alguns protocolos foram desenvolvidos, mas em geral são adequados para redes fixas e nunca tem o mesmo desempenho com dispositivos móveis.
O RSVP (Resurce reSerVation Protocol) é usado em aplicações de tempo real reservando recursos no caminho entre um host e outro. Quando um dos hosts é móvel e muda seu ponto de conexão, o caminho deve ser re-configurado. A unidade móvel só pode fazer isso depois de determinar seu novo care-of address e enviar um binding update ao host comunicante. O tempo gasto com o processo de handoff somado ao estabelecimento de uma nova seção do RSVP é considerável e prejudica a qualidade do serviço.
Para otimizar o processo de handoff o RSVP precisa ser adaptado para tornar possível que uma nova seção RSVP seja criada antes de encerrar a atual. Isto requer estabelecer um túnel entre o roteador antigo (RA), que a unidade móvel está, e o novo roteador (NR), para onde ela irá. Através deste túnel pacotes poderão ser recebidos e envidados pela unidade móvel até que ela finalmente estabeleça e mude seu ponto de conexão para receber diretamente os pacotes. A principal vantagem desta abordagem é que a comunicação continua enquanto a unidade móvel configura seu novo care-of address.
Esta técnica tornasse viável com IPv6 devido à capacidade da unidade móvel manter um endereço fixo, o home address, e adquirir outros care-of addresses simultaneamente, assim, a unidade móvel pode receber dados por uma interface enquanto configura outra.
Neste protocolo, para realizar um handoff de forma suave a unidade móvel notifica o RA com o endereço IP de NR. O RA estabelece com NR um túnel IP bidirecional por onde podem ser encaminhados pacotes para a unidade móvel. Porém este túnel não serve para a recepção dos dados pelo RSVP porque a nova seção RSVP ainda não possui um estado configurado.
Quando a unidade móvel adquire seu novo care-of address ela envia um binding update para o host correspondente sem deixar de usar o caminho antigo passará a enviar mensagens RSVP para o NR configurando o estado da seção RSVP e estabelecendo os termos da qualidade de serviço no caminho até NR.
Quando as mensagens percorrem o caminho até NR, passam por roteadores que ainda não acordaram com as requisições de qualidade de serviço, até que estes se acomodem às necessidades do serviço um tempo é perdido que prejudica e torna esta comunicação inaceitável. A solução é criar um segundo túnel, do RA para a unidade móvel, este é um túnel RSVP que garante a qualidade de serviço de um ponto ao outro. Assim, os dados são enviados passando pelo caminho antigo e pelo RA antes de chegarem na unidade móvel. Quando a nova rota fica pronta a unidade móvel envia um binding update definitivo para o host comunicante informando que a comunicação RSVP pode ser feita pelo novo caminho.
Última atualização 28/08/2008 14h09
Este sítio web funciona com IPv6. Se o globo estiver girando, você também já usa IPv6!
Licença:
Creative Commons Atribuição 2.5 Brasil (salvo seja especificada outra)
Válido:
XHTML 1.0 -
CSS 3
