IPv6 e as redes de acesso HSPA/HSPA+

Eu sei que ainda estou devendo para vocês o exemplo prático do algoritmo de planejamento de capacidade, mas a notícia que eu vi hoje, falando da preparação da TIM para o uso do protocolo IPv6, me causou uma preocupação: até que ponto o pessoal de marketing está consciente do que está fazendo ao usar este tipo de migração da rede como argumento para fazer posicionamento?

Migrar o serviço de acesso à internet de uma operadora celular 3G para IPv6 tem uma série de aspectos peculiares, além daqueles que afetam a migração de qualquer ISP para o IPv6. Talvez o maior deles seja o problema dos PDP contexts.

Para entender este problema temos que entender antes como funciona o acesso de um dispositivo móvel à Internet através de uma rede celular 3G. A figura abaixo dá um sumário disso.

Uma conexão PSD (Packet-Switching Domain) ocorre entre o UE (user equipment) e o GGSN (Gateway GPRS Support Node - eu sei... embora estejamos falando de HSPA e HSPA+, o nome do gateway ainda refere-se ao velho GPRS). Fisicamente essa conexão é mediada pelo Node-b onde o UE estiver concectado e pela RNC (Radio Network Controller) onde o Node-b estiver registrado. Como o UE é móvel, tanto o Node-B quanto a RNC que atendem o UE podem mudar ao longo da duração da conexão. Faz parte do processo de handover manter a conexão física UE-GGSN estável durante as trocas de Node-b e/ou RNC.

Logicamente a conexão UE-GGSN é associada a uma entidade chamada PDP (Packet Data Protocol) context. Na prática o PDP context funciona como um túnel lógico, e se comporta como se fosse uma interface de nível 2 para cada um dos equipamentos nas extremidades.

E isto é um problema por quê? Porquê, até que se complete a transição de todos os sites, serviços e aplicações da Internet para IPv6, nós teremos que conviver com duas Internet separadas logicamente: A Internet "clássica" IPv4 e a nova Internet IPv6. O processo de transição vai passar por duas etapas distintas, e nós estamos começando a entrar na primeira delas. E não tem prazo definido para a duração de cada fase.

A única forma prática (e recomendada pela IETF - Internet Engineering Task Force) para conviver com este processo de migração é que todos os hosts conectados possuam as duas pilhas de protocolos, IPv4 e IPv6 funcionando simultaneamente. Esta estratégia é chamada de dual-stack, e funciona da seguinte forma (para entender a figura você tem que ter familiaridade com o modelo TCP/IP)..

Desta forma cada host pode ter acesso às duas "Internets" enquanto durar a transição. Mas continua a regra: uma aplicação v4 não consegue dialogar diretamente com uma aplicação v6, e vice-versa. Vejamos as consequências disso para o modelo operacional da nossa rede de acesso 3G HSPA ou HSPA+.

Cada PDP context só pode estar associado a um único protocolo de nível 3. Portanto se o UE e o GGSN tem que funcionar em modo dual-stack, cada conexão PSD vai precisar de dois PDP contexts: um para o IPv4 e outro para o IPv6. Isto vai ter consequências em termos de memória e capacidade de processamento da platafoma que suporta o GGSN, e vai resultar em mais sinalização entre UE / Node-b / RNC / GGSN, o que pode ser problemático na HMM de algumas células. Portanto o planejamento de capacidade da interface aérea e do backhaul dos cell-sites tem que considerar esta carga extra.

Outra coisa é que, em geral, os fornecedores de soluções de GGSN cobram da operadora por número máximo de PDP contexts abertos (ativos ou dormentes), então tem que haver uma briga comercial feia aqui, senão o preço do GGSN vai quase dobrar de uma hora para outra.

E, como dizem os anúncios das Organizações Tabajara (do Casseta e Planeta), não é só  somente isso: ainda é muito incipiente a disponibilidade de UEs (exceto notebooks e desktops) capazes de funcionar em modo dual-stack. Mesmo que a operadora tenha todo o seu lado preparado e testado, poucos UEs estão prontos para desfrutar disso.

Por último temos a questão de como será a conexão, física e lógica, do GGSN às duas Intenets, v4 e v6. A solução mais básica é: duas interfaces físicas separadas (ou, pelo menos, duas interfaces lógicas separadas sobre a mesma interface física), cada uma delas conectada a roteadores diferentes (ou portas físicas ou lógicas diferentes de um mesmo roteador), cada uma delas servindo como uplink para uma das Internets.

Mas, como os diagramas da transição mostram, cada etapa é formada por "ilhas" de uma das Internets conectadas via tunelamento através do "mar" da outra internet (neste momento o IPv4 é o mar, e o IPv6 as ilhas, depois os papéis se invertem). Então existe a questão de quem vai prover o tunelamento do tráfego IPv6  da operadora (na fase 1)?

A resposta mais simples é: o fornecedor do(s) uplinks cuida disso. Neste caso, a depender do grau de separação física e lógica entre as interfaces e uplinks de acesso às Internets, a operadora pode não ter que fazer nada ou pode ter que configurar seu(s) roteadores de borda com as Internets - ou o próprio GGSN, e isso vai ter que ser outro item de negociação com o fornecedor - para fazer o tunelamento do tráfego IPv6 sobre pacotes IPv4. O mecanismo de tunelamento recomendado no momento é o Teredo (RFC 4380, RFC 5991 e RFC 6081).

A figura abaixo mostra o caso onde o tuelamento Teredo é implementado no roteador de borda com a Internet v4.

Esta figura é apenas uma visão simplificada. Ainda teriam que ser acrescentados os inevitáveis Firewalls e servidores DPI (Deep Packet Inspection) e, caso a arquitetura de serviços da operadora os use, servidores CDN (Content Delivery Network).

vocês percebem que isto é apenas um arranhão no problema completo de projetar a migração do acesso aos serviços de acesso a Internet (e aos serviços internos da operadora) para IPv6. E este é o motivo pelo qual achei engraçado a TIM ficar tocando tambores em público. Será que ela já resolveu dodos estes aspectos? Se algum dos leitores tiver conhecimento sobre o assunto e quiser entrar em contato comigo para conversar sobre isso eu agradeço.