Proliferação de padrões concorrentes

Network capacity planning - exemplo de uso do algoritmo (parte 1)

Conforme prometido, vou mostrar um exemplo de aplicação do algoritmo de planejamento de capacidade mostrado no artigo anterior sobre a seguinte rede hipotética:

Adicionalmente vou mostrar uma implementação do algoritmo na linguagem C. O vetor de nós de comutação tem a seguinte estrutura lógica:

Que tem a seguinte implementação (sintaxe C):

Para entrada de dados no vetor de nós de comutação vamos usar no exemplo um arquivo CSV, onde cada registro representa um elemento do vetor:

A matriz de topologia tem a seguinte estrutura lógica:

Com a seguinte descrição da estrutura de dados em C:

De forma análoga ao que fizemos para o vetor de nós de comutação, os dados de entrada para a matriz de topologia são dados no seguinte arquivo CSV (que percorre a matriz linha a linha):

A matriz de rotas tem a seguinte estrutura lógica::

E o código C para a sua estrutura de dados é:

No arquivo CSV para carga inicial percorremos os valores nesta matriz linha a linha. Observe que o valor armazenado nos elementos da matriz não é o valor de índice do vetor de nós de comutação, mas o valor numérico inteiro do Id do nó de comutação. Assim, um valor zero nesta matriz indica a inexistência de rota entre o par de nós considerado.

Na próxima parte deste artigo vamos ver a estrutura lógica, o código C e os arquivos CSV usados para definir a matriz de interesse de tráfego, e estaremos em condição de definir a implementação C do algoritmo e ver os resultados da sua execução sobre os dados de entrada que fornecemos.

Os indicadores de performance de rede no SGQ-SCM e SGQ-SMP (1)

Li e reli os dois novos regulamentos sobre indicadores da qualidade do SCM e do SMP, e, sinceramente, achei a redação confusa e, às vezes, contraditória. Então decidi publicar alguns posts dedicados a tentar fazer uma apresentação inteligível dos indicadores de qualidade da rede do SCM e dos indicadores de conexões de dados do SMP (não vou tratar dos indicadores de reação do usuário - SCM e SMP, nem dos indicadores de atendimento - SCM e SMP, nem dos indicadores das conexões de voz - só SMP, e nem dos indicadores de pesquisa - SCM e SMP).

Sempre que possível vou emparelhar os indicadores que medem coisas semelhantes para o SCM e para o SMP. E vale observar logo: estes regulamentos só afetam operadores SCM ou SMP com mais de 50K assinantes (ou acessos em serviço, na terminologia dos regulamentos). Ou seja: praticamente só as operadoras de telefonia fixa e móvel entram neste critério. Os pequenos e médios operadores SCM (creio que esta categoria não exista no SMP) não são afetados por estes regulamentos.

Qualquer problema de análise de performance começa pela definição do 5W1H:

• WHAT: o que vai ser medido?
• WHY: porque vamos medir isso?
• WHO: quem fará a medição?
• WHERE: onde será feita a medição?
• WHEN: quando será feita a medição?
• HOW: como faremos esta medição? 

Então vamos tentar organizar os indicadores de qualidade da rede para dar a melhor resposta possível a estas perguntas, com base no que está escrito nos regulamentos e com um pouco de bom senso.

Os dois regulamentos (art. 10 para o SCM e art. 24 para o SMP) prevêem que as operadoras tem que disponibilizar (para a Anatel e para os assinantes, no caso do SMP, e só para os assinantes no caso do SCM) software de medição do desempenho da rede, que deverá poder ser baixado por cada usuário interessado, e que deve ser capaz de medir os seguintes indicadores (e registrar - onde? - data/hora e local dos resultados obtidos, para possibilitar a formação de série histórica):

• Taxa de transferência instantânea - indicadores SCM4 e SMP10. A taxa instantânea deve ser medida tanto no canal de download quanto no canal de upload;
  
• Latência bidirecional (aquilo que comumente chamamos de round-trip time, medido com o programa ping) - indicador SCM6, mas sem indicador correspondente no SMP (aliás, não tem nem mesmo definição para o round-trip time no RGQ-SMP). O que levanta uma questão interessante: o software vai medir isso, mas a operadora não tem nenhuma meta estabelecida para este item de desempenho. Vai dar confusão.
  
• Variação de latência (jitter) - indicador SCM7, e também sem indicador correspondente para o SMP. Valem as mesmas observações do caso da latência bidirecional.
  
• Taxa de perda de pacotes (packet loss) - indicador SCM8, e também sem correspondente no SMP. Aqui temos os inconvenientes dos dois itens anteriores e mais um adicional: não é dada nenhuma definição, nem mesmo no regulamento do SCM, para este item o como calcular está completamente em aberto.

Outro fator de confusão ligado a este software de medição é que enquanto o regulamento do SCM especifica (no inciso I do art. 15) que a medição dos dados para o cálculo oficial dos indicadores deve ser feito com equipamento dedicado, na casa do assinante (na verdade de uma amostra estatisticamente significativa do conjunto dos assinantes - inciso II do art. 15 - com intervalo de confiança mínimo de 95% - por analogia com o item 4.3 do anexo III do regulamento do SCM). Já o SMP não fala nada sobre como fazer a medição, e ainda deixa aberta a possibilidade de ser usado o mesmo software que será disponibilizado para os assinantes. Muito mal definido.

Existe mais um indicador comum aos dois regulamentos: taxa de transferência média (SCM5 e SMP11). Novamente os regulamentos definem que as medidas devem ser feitas tanto no canal de download quanto no canal de upload.

E existem indicadores que são específicos para o SMP, e não tem correspondente no SCM. Talvez seja apenas a vontade de manter paralelismo com os indicadores do serviço de voz do SMP:

• Taxa de completamento de conexões de dados (SMP8);
  
• Taxa de queda das conexões de dados (SMP9);

Então podemos fazer uma tabela resumo sobre o que (what) temos que medir:

Vamos assumir que o porquê medir (why) seja auto-explicativo. E sabemos quem (who) vai medir. Será a tal da Entidade Aferidora da Qualidade, que é descrita nos artigos 33 a 37 do RGQ-SCM e nos artigos 26 a 30 do RGQ-SMP, mas com uma diferença: no SCM a Entidasde Aferidora é responsável pela coleta de dados e cálculo de todos os indicadores de rede (SCM4, SCM5, SCM6, SCM7 e SCM8), mas no SMP ela é responsável apenas pela coleta de dados e cálculo dos indicadores SMP10 e SMP11. Subentende-se, então, que a responsabilidade pela coleta de dados e cálculo dos indicadores SMP8 e SMP9 cabe às operadoras.

As questões de onde (where) e quando (when) medir também dão o que falar: tanto o SCM quanto o SMP pedem que os cálculos dos indicadores ocorra no PMT (período de maior tráfego - que é definido de forma invariável como sendo das 10:00 às 22:00 horas - o que, por si só, é uma incongruência estatística). Mas, enquanto no RGQ-SCM o art. 15 define que a medição deve ocorrer na casa dos usuários, com uma dispersão da amostrage tal que permita a representação estatisticamente significativa da diversidade do público usuário do serviço, no RGQ-SMP apenas é dito que o mesmo software que for disponibilizado para que os usuários façam suas próprias mediçoes também poderá ser usado para efetuar as medições para cálculo oficial dos indicadores. E não diz nada sobre como escolher uma amostra estatisticamente significativa dos usuários, que, no caso do SMP, tem uma dimensão a mais em relação ao SCM: a maior diversidade de equipamentos de acesso (smartphones e tablets, além dos desktops e notebooks típicos do SCM).

Para terminar esta etapa da análise, vou apenas sumarizar as metas a atingir em cada indicador, para os dois serviços (SCM e SMP).

(*) Tanto o indicador SCM6 (diretamente, pelo inciso III do art. 15 do RGQ-SCM) quanto o indicador SMP10 (indiretamente, por analogia ao que é dito sobre o software de medição a ser disponibilizado aos usuários no § 8º do art. 24 do RGQ-SMP) dizem que a medição deve ser efetuada entre o equipamento do usuário e o PTT. Só não especifica o critério para definir qual PTT usar nas medições, porque existem vários, públicos e privados.

Na próxima parte vou analisar com calma a questão do como (how) medir. Do svidanʹya tovarishchi.

To NAT or not to NAT? That's the question for HSPA/HSPA+

No artigo anterior eu defendi a tese que a opção menos ruim (porque boa, boa mesmo, de verdade, não tem) para a migração do serviço de acesso móvel à Internet através das redes de acesso celulares 3G (HSPA e HSPA+) era a abordagem dual-stack (ver RFC 4213).

Nos comentários daquele artigo o Rubens Kuhl e o Juliano defenderam que a melhor opção é o uso do NAT64. Certamente que eu acho possível usar o NAT64 neste contexto, mas tenho dúvidas se ele vai funcionar tão bem.

Antes de começar a discutir prós e contras relativos de cada abordagem, pelo bem daqueles leitores que não tenham familiaridade com o assunto (afinal este blog tem uma finalidade basicamente instrutiva), vou fazer uma breve apresentação do que se trata o NAT64.

NAT significa Network Address Translation. Na Internet v4 o uso extensivo de NAT (ver RFC 2663) e dos blocos de endereçamento privado definidos na RFC 1918 permitiram um considerável aumento da sobrevida do espaço de endereçamento do IPv4, mas também criaram uma sensação de falsa segurança, e muito pouca coisa concreta foi feita para que a transição IPv4-IPv6 ocorresse de fato. Resultado: muito tempo perdido, e agora vamos ter que fazer correndo o que podia ter sido feito com calma.

Na Internet v6 não existe motivo para o uso de NAT, como é destacado na RFC 4864. Já a questão de como um host v6 pode estabelecer conexão com um host v4, e vice-versa, só pode ocorrer mediante alguma forma de NAT para fazer a "ponte" entre as duas Internets (v4 e v6).

O NAT64 permite que aplicações em um host que seja single-stack IPv6 consigam acessar aplicações que residem em hosts também single-stack, porém IPv4. Os recursos necessários para usar o NAT64 são:

• Um Well-Known Prefix (WNP) IPv6. Conforme a seção 2.1 da RFC 6052, o WNP para o NAT64 é 64:ff9b::/96 (se você já penou pra entender a notação dotted decimal dos endereços IPv4, então prepare-se, porque a notação dos entereços IPv6 é bem mais críptica. Sugiro dar uma olhada aqui).
  
• Servidor DNS que suporte as extensões DNS64 (RFC 6052 e RFC 6146)

A figura abaixo mostra o esquema geral de funcionamento do NAT64.

O fluxo de mensagens mostrado é para quando o host de destino só possui conectividade IPv4 (o que fica evidente pela resposta de erro do servidor DNS para o servidor DNS64 quando ele pede o registro AAAA do host de destino). Se o host de destino possuísse conectividade IPv6 haveria uma resposta válida para a query pelo registro AAAA no servidor DNS, e (mesmo que o host de destino fosse dual-stack e também houvesse uma resposta com o registro A associado) a conectividade IPv6 seria possível - logo o gateway NAT64 não seria usado.

Bonito, porém vejo um problema sério nesta abordagem. Ele é muito bom quando os UEs estão querendo acessar servidores IPv4 no regime client-server habitual (ex.: web surfing e verificação da caixa postal de e-mails). Mas a situação muda quando a direção do início da sessão é invertida (da Internet v4 para dentro da "ilha" IPv6 que é a rede interna da operadora). E, no quadro de funcionamento peer-to-peer típico das aplicações de telefonia  (tanto na conexão bearer quanto na conexão de sinalização SIP) isto vai ocorrer a toda hora - Exemplo: o IMS de uma operadora, ainda usando IPv4, tentando negociar o estabelecimento de uma sessão com o IMS de outra operadora, que já migrou a plataforma para IPv6.

Aí a solução será o que? Incorporar suporte a NAT64 stateless, mais algum mecanismo de NAT traversal, tipo STUN ou TURN? Vai ficar complicado. E talvez não escale bem.

No geral ainda simpatizo mais com a solução puramente  dual-stack apresentada no post anterior. É certo que também é necessário o suporte do DNS64, mas fica muito mais simples para as aplicações decidirem como estabelecer conexão. Se ela recebe um registro AAAA, então a conectividade é estabelecida pelo socket v6, e se recebe apenas um registro A, ela usa o socket v4. E não há obrigatoriedade que o servidor DNS64 tenha conectividade IPv6, como é o caso na solução NAT64.

Outro problema óbvio para a solução dual-stack no ambiente das redes de acesso HSPA/HSPA+ é que cada UE precisa receber endereçamento IPv4 e IPv6, só que nenhuma operadora tem (nem vai ter) pool de endereços IPv4 públicos suficientes para atender à demanda de todos os clientes conectados. Neste caso creio que a saída menos ruim (porque também tem problemas de escalabilidade) é a proposta Dual-Stack Lite (DS-Lite, RFC 6333). Veja a figura abaixo.

Na proposta DS-Lite o endereçamento IPv4 dos UEs (que são dual-stack) é feito com endereços de alguma das faixas privadas definidas na RFC 1918 (ex.: 10.0.0.0/8). O tráfego IPv4 é destinado para a Internet v4 através de um Carrier-Grade NAT (CGN) gateway de forma muito parecida com o que já é feito hoje. E o tráfego IPv6 é encaminhado diretamente à Internet v6. Possivelmente a "ilha" IPv6 da operadora estará conectada às demais "ilhas" IPv6 por mecanismos de tunelamento sobre a Internet v4. Destes todos, o que me parece mais utilizado no momento é, como já disse no post anterior, o Teredo (RFC 4380), mas também existem outras opções, como, por exemplo, o 6rd (RFC 5569 e RFC 5969).

E, para não alongar muito, se for o caso deixo para mais tarde a análise do SIIT (Stateless IP/ICMP Translation - RFC 6052, RFC 6144 e RFC 6145) no contexto das redes de acesso HSPA/HSPA+.

Para fechar, então. um resumão do problema, conforme a minha opinião (o 3GPP e os fornecedores podem divergir - só que a operadora deve ter suas próprias idéias, não andar a reboque do que dizem os fornecedores), e é o que eu recomendaria às operadoras:

• O grande fator decisivo da estratégia é o roadmap de disponibilidade do IPv6 pelos fornecedores dos UEs. Computadores convencionais não são problema, porque todos os sistemas operacionais relevantes (MS-Windows, Apple MacOS, Linux em vários "sabores", Solaris, HP-UX, AIX, zOS, etc.) já oferecem suporte ao dual-stack. O problema são os smartphones e os tablets. Todo o resto, para mim, é legacy.
  
• Se a questão da duplicidade dos PDP contexts não for um problema, minha sugestão é: vá para uma solução dual-stack. Se o pool de endereços IPv4 apertar, cá para DS-Lite.
  
• Se UEs dual-stack forem escassos, ou a duplicidade dos PDP contexts for um problema, vá para o NAT64. Separe os UEs legacy para usarem apenas PDP contexts IPv4, e, para todos que suportarem, use apenas PDP contexts IPv6.

Por ora é isso. Mas este é o tipo do assunto que ainda pode render mais posts, então até a qualquer momento, em edição extraordinária.

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.

História de terror para jovens administradores de rede

Network capacity planning - um algoritmo

Vamos primeiro definir: o que é fazer planejamento de capacidade? É garantir que os recursos da sua rede (enlaces de comunicação e nós de comutação de pacotes) sejam capazes de cursar o tráfego previsto sem entrar em congestionamento.

Neste artigo vou apresentar um algoritmo simples para, conhecido o interesse de tráfego (em K/M/Gbps e K/M/Gpps) bidirecional entre todos os pontos de ingresso e egresso de tráfego na rede, calcular o volume de tráfego na HMM (Hora de Maior Movimento) em cada enlace e em cada nó da rede.

Vetor dos nós de comutação:

Os nós de comutação de pacotes da rede (roteadores e switches) são descritos como um vetor (array unidimensional) de estruturas de dados. Cada estrutura S(i) contém um acumulador do volume de tráfego cursado em K/M/Gbps (bits/s) e um acumulador do volume de tráfego cursado em K/M/Gpps (packets/s), para cada hora do dia, conforme o modelo abaixo.

Como regra geral vou usar sempre a seguinte convenção para os itens de hora: cada rótulo hh:00 acumula o tráfego desde a hora hh:00:00 até a hora hh:59:59. Exemplo: o rótulo 13:00 representa os valores desde 13:00:00 até 13:59:59.

Outra dúvida comum é: porque os volumes de tráfego em K/M/Gbps e em K/M/Gpps? Aplicações diferentes geram tamanhos médios de pacote diferentes. Aplicações tipo VoIP geram um K/M/Gpps alto, porém com um K/M/Gbps modesto. O contrário acontece com aplicações como, por exemplo, transferência de arquivos. Como a capacidade dos elementos de comutação não depende somente dos K/M/Gbps trafegados, mas tem um limite muito mais sensível para o K/M/Gpps máximo, ambos os números são importantes.

Matriz de topologia da rede:

Para representar a topologia da rede vamos usar uma matriz (array bidimensional) de estruturas de dados. A numeração dos elementos nas dimensões i e j da matriz de topologia replicam a numeração da dimensão i do vetor de nós de comutação. Desta forma cada estrutura T(i,j) representa a existência (ou não) de um enlace de comunicação entre os elementos i e j do vetor de nós de comutação e o volume de tráfego esperado, em K/M/Gbps e K/M/Gpps, a cada hora, na direção de i para j. Obviamente, se existe o enlace T(i,j) então também tem que existir o enlace T(j,i), que representa o tráfego na direção reversa (de j para i) do enlace.

Abaixo temos um modelo para o elemento T(i,j)

Matriz de interesse de tráfego:

Cada estrutura I(i,j) desta matriz (array bidimensional) indica o particionamento do tráfego, em K/M/Gbps e K/M/Gpps, por hora do dia, originado no nó de comutação i e direcionado ao nó de comutação j, conforme o modelo abaixo.

Uma situação comum é a existência concomitante do tráfego dos serviços A, B, C, ... cursando pela rede. Neste caso é necessário montar uma matriz de interesse de tráfego para cada serviço individual, e depois executar o algoritmo com a matriz de interesse de tráfego total, ou seja, se IA(i,j), IB(i,j), IC(i,j), ... são as matrizes de interesse de tráfego, respectivamente, para os serviços A, B, C, ..., então o algoritmo deve ser executado sobre a matriz de interesse de tráfego obtida pela operação

Matriz de rotas:

A matriz de rotas é um array tridimensional que descreve a sequência dos nós de comutação que deve ser percorrida pelo tráfego. Visualmente podemos imaginar esta matriz como um cubo.

As dimensões i e j definem, respectivamente, os nós de comutação de início e fim da rota. cada instância da dimensão k declara a identificação (numérica, correspondente à numeração dos nós de comutação) de um dos nós de comutação na rota que vai do nó de comutação i até o nó de comutação j. Consequentemente o primeiro nó de comutação em cada rota é dado, implicitamente, pelo valor da dimensão i. E  rota encerra´se quando localizamos um elemento na dimensão k cujo valor seja igual a j.

Condições normais de tráfego x condições de contingência:

A forma mais simples de executar este algoritmo é considerar o conteúdo das estruturas de dados que representem a situação normal de operação. Caso queira-se analisar também o comportamento da rede em situações de contingência é necessário criar novas versões das estruturas de dados, uma para cada situação de contingência que se deseje testar.

Neste caso os valores de tráfego em HMM em cada enlace e em cada nó de comutação será o pior caso obtido em cada ponto da rede, considerados todos os cenários testados.

Como definir o conteúdo da matriz de rotas?

Esta é, talvez, a parte mais complexa da utilização prática deste algoritmo, porque exige o conhecimento prévio da estrtura de rotas negociada entre os nós de comutação, geralmente pelo uso de algum protocolo de roteamento dinâmico (OSPF, IS-IS, etc.). Mesmo nos casos onde seja usada alguma forma de "circuitização de pacotes" (ex.: MPLS-TE) nem sempre é fácil saber com antecedência as rotas correspondentes ao cenário considerado (normal ou contingência).

Em termos práticos é necessário observar o comportamento real da rede em cada situação desejada, ou simular o comportamento dos algoritmos de roteamento dinâmico para definir quais rotas devem ser inseridas na matriz.

Que valores usar na(s) matriz(es) de interesse de tráfego?

Uma vez que buscamos o dimensionamento dos elementos da rede de tal forma que, mesmo em HMM, eles não apresentem congestionamento (e, talvez, para que não entrem em congestionamento mesmo em certas situações de contingência), temos que pensar um pouco sobre que valores de tráfego devemos considerar para cada hora do dia (por serviço, se for o caso).

O comportamento do tráfego medido em uma determinada hora não é constante. Existem diferenças, para a mesma hora, entre os diferentes dias da semana, feriados, etc. Quando tabhulamos estas variações obtemos (muito provavelmente) uma distribuição de frequência normal, para a qual calculamos o valor médio e o desvio padrão.

Minha sugestão, já que estamos projetando para o pico de tráfego em HMM, em cada hora considere como valor do tráfego (em bps e pps) o valor médio mais quatro desvios-padrão. Desta forma a probabilidade que qualquer tráfego observado seja menor ou igual a este valor é de, aproximadamente 99,69%

O algoritmo:

Pois bem... agora podemos iniciar o processamento dos dados.

Tudo começa pelo percurso sistematicamente da matriz de interesse de tráfego e, para cada par (i,j) de origem e destino de tráfego, Acumular (para todas as horas do dia) o tráfego nos nóe e links ao longo da rota que une o nó de comutação i ao nó de comutação j.

Vou representar os trechos do algoritmo usando a linguagem REXX. A sintaxe é muito simples e intuitiva. Não creio que isso venha a dificultar a compreensão pelos interessados. Não está mostrada a parte inicial de leitura dos dados nas respectivas estruturas.

Um detalhe da implementação mostrada: a linguagem REXX permite que o contexto das variáveis de um procedimento seja ou não visível para os procedimentos que ele invoca. A forma sintática que estou apresentando expõe todo o espaço de variáveis do procedimento invocador para os procedimentos invocados.

Como o primeiro nó de comutação na rota de i para j é o próprio nó i, a primeira coisa a fazer é acumular o tráfego (de todas as horas) no nó de comutação i. A seguir fazemos o percurso da rota até encontrar o elemento que contém o valor j, que marca o final da rota. Para cada elemento ao longo da rota (nós de comutação e enlaces) acumulamos o tráfego de i para j indicado na matriz de interesse de tráfego.


Uma observação sintática: a construção "DO WHILE" na linguagem REXX executa o teste da condição  de controle no final do loop, o que resulta em pelo menos uma execução das instruções contidas no loop. O loop será executado enquanto o resultado da condição de controle for o valor lógico "VERDADEIRO"

Resta agora detalhar cada um do procedientos de acumulação do tráfego. Vejamos primeiro a acumulação por nó.

O nó alvo da acumulação é passado para o procedimento como um parâmetro, que é recuperado pela instrução "PARSE ARG". A variável índice da variação das horas começa do valor 1 (indicando o período das 00:00:00 às 00:59:59), somente porque a linguagem REXX não aceita valores de índice iguais a zero.


Aliás, o uso da hora como índice transforma, na prática, o vetor de nós de comutação em um array bidimensional, e a matriz de interesse de tráfego em um array tridimensional.

O procedimento de acumulação por enlace é logicamente semelhante ao procedimento de acumulação de tráfego por no, com a diferença que os parâmetros de entrada são dois: ponta A e ponta B do enlace. Da mesma forma que no procedimento anterior, a matriz de topologia transforma-se, na prática, em um array tridimensional, com o acréscimo do indice de hora.

Não estão mostrados os procedimentos para exibição/impressão dos resultados.

Como avaliar os resultados?

Após a execução do algoritmo o vetor dos nós de comutação e a matriz de topologia contém o tráfego acumulado sobre cada elemento, conforme indicado pela matriz de interesse de tráfego.

Para cada elemento representado nestas estruturaas de dados a sequência temporal dos valores indicará qual hora representa a HMM daquele elemento (que não é, necessariamente, a mesma sobre toda a rede).


O valor a ser considerado para dimensionamento dos nós de comutação é o valor de K/M/Gbps e K/M/Gpps na HMM daquele elemento. A especificação do roteador ou switch para este ponto da rede deve atender, no mínimo, a esta demanda de tráfego.


Para o dimensionamento dos enlaces é necessário comparar os valores de K/M/Gbps em HMM de cada enlace nas duas direções (porque o volume de tráfego sobre o enlace pode ser assimétrico). O valor para dimensionamento do enlace (i,j) deve ser o maior valor de HMM entre esta direção e a direção reversa (j,i).


No próximo artigo vou apresentar um caso-exemplo de utilização deste algoritmo. Inté...

Para engenheiros eletricistas

Redes de telecomunicação (13) - Going all-IP (parte 3)

Estive pensando sobre os assuntos que prometi, no final da parte anterior deste artigo, abordar aqui. Cheguei à concusão que preciso, antes, contextualizar melhor as mudanças de paradigma (ô terminologia batida, sô) envolvidas na prestação de serviços de nova geração. Sem isso não dá para arquitetar uma repartição racional de responsabilidades entre os três grupos atuantes no ecossistema NGN:

• Operadoras de telecom e seus fornecedores de equipamentos e serviços carrier-class tradicionais;
• Provedores de serviço na Internet (Internet Service Providers - ISPs) e seus fornecedores de equipamentos e serviços Internet-class (que podem ou não ser, também, participantes do grupo anterior de fornecedores);
• Os usuários dos serviços prestados pelos outros grupos.

Coloquei os fornecedores (vendors) junto com as operadoras de telecom e com os ISPs porque, até certo ponto, eles possuem um "carma compartilhado", no sentido que o fracasso do modelo de negócio (e, consequentemente, do próprio negócio) das operadoras ou ISPs leverá também ao fracasso os fornecedores que deles dependam.

E isto é uma das principais dificuldades para analisar com isenção o cenário de evolução das redes de telecom em direção à NGN. É difícil separar o que é uma genuína inovação técnica, ou uma verdadeira tendência, do "ruído de fundo" criado pelo intenso bombardeio de propaganda dos fornecedores de equipamentos e serviços. Principalmente aqueles que tem seu próprio destino umbilicalmente ligado ao destino das próprias operadoras (como, por exemplo, os fornecedores de equipamentos SDH e DWDM).

Se a migração das redes para o modelo NGN ocorrer muito rápido eles ficarão "na chuva". Basicamente eles ouvirão dos seus atuais clientes algo parecido com: "segura aí no pincel, que eu tô levando a escada embora". E a consciência disso (por parte deles) aliada a uma postura leniente (em minha opinião) das operadoras de telecom, que, em vez de traçarem seus próprios roadmaps de evolução tecnológica e de serviços (e, depois disso, selecionarem os vendors capazes de satisfazer suas necessidades), meio que "terceirizam" isso para seus fornecedores. Na maioria dos casos o planejamento das operadoras depende demais daquilo que os fornecedores dizem que dá pra fazer, ou não, e quando. No meu conceito, isso é um caso do rabo abanando o cachorro.

Enfim... isso justifica o ambiente de FUD (fear, uncertainty and disinformation) com relação a redes e serviços all-IP que vemos na maioria das operadoras de telecom. Em grande parte ele é criado e disseminado pelos fornecedores, que tem muito a perder. Mas vou tentar não me deixar levar por isso na minha argumentação.

O ponto principal que temos que reconhecer é que, mais do que uma mudança na filosofia e tecnologia de transporte dos dados (e tudo é dados, inclusive a voz), o que caracteriza uma NGN é a capacidade de prover serviços realmente inovadores aos seus usuários. O que vai caracterizar quais modelos de negócio serão vencedores, ou não, neste contexto será sua real capacidade em suportar estes novos tipos de interação dos usuários.

Falamos muito de novos serviços, de serviços avançados, mas quase ninguém entende direito o que isto significa. Vou tentar dar dois exemplos:

• Você está no seu escritório usando um equipamento desktop, em videoconferência com alguns colegas, e a reunião se alonga a ponto de você correr o risco de perder o vôo marcado para o fim da tarde. Então você transfere a sessão de videoconferência do seu desktop (que está usando a rede LAN e o acesso Internet compartilhado do escritório) para o seu laptop/tablet usando acesso wireless 3G/4G e segue para o aeroporto mantendo a videoconferência ativa. Ao chegar no aeroporto você continua com a sessão de videoconferência ativa, porém utilizando a cobertura WiFi do aeroporto como meio de acesso.
• Você usa uma aplicação (no desktop, laptop, tablet ou smartphone - normalmente teremos versões das aplicações adequadas a todos os tipos de plataforma) para programar a sua smart house - ligar o ar condicionado, ativar o microondas onde você deixou o jantar congelado, ligar o aquecedor de água, fechar as cortinas, etc. Mas, em vez de usar um horário específico para cada evento você especifica que todos eles devem ser iniciados após intervalos determinados, contados a partir do recebimento de um sinal disparador. E programa o sistema multimídia do seu carro (que também está conectado) a controlar seu posicionamento em relação à sua casa, e disparar o sinal de acionamento se o tempo estimado de chegada (considerando a rota adotada e as informações de tráfego recebidas) for menor ou igual a, por exemplo, meia hora.

Este tipo de cenário exige três coisas principais: a integração funcional de vários tipos de redes de acesso, backhaul e core de forma transparente para o usuário; a capacidade de construir redes e serviços ditos carrier class (como isso tem sido usado pelos fornecedores tradicionais para criar barreiras de entrada neste mercado!) usando componentes COTS (Commercial, Off-The-Shelf); e a capacidade de um mesmo tipo de aplicação ser executado a partir de vários tipos de dispositivo, com as características da sessão podendo ser ajustadas on the fly;

As diversas tecnologias de rede que devem ser integradas e harmonizadas para este cenário estão resumidas no diagrama abaixo (retirado da Recomendação ITU-T Y-110):

O desenho é meio velho (1998), daí ainda mencionar N-ISDN e B-ISDN (respectivamente Narrowband e Broadband Integrated Services Digital Network) como alternativas para o segmento core da NGN. Isto, como vimos em artigo anterior, já foi superado. Mas a ideia geral da variedade de redes de acesso a convergir sobre um core NGN comum (agora all-IP) ainda é válida.

Para o problema de construção de plataformas de redes e serviços de telecom usando componentes COTS a ITU-T produziu um framework chamado CGOE (Carrier-Grade Open Environment), descrito na Recomendação ITU-T Y-2901. O diagrama abaixo (retirado da Recomendação Y-2901) mostra os elementos gerais deste framework.

Arquiteturalmente as NGNs devem separar claramente o estrato de serviço (service stratum) e o estrato da rede de transporte (transport stratum), sendo que cada estrato possui um user plane (onde trafegam os dados de aplicação), um control plane (onde trafegam os dados de sinalização) e um management plane (onde trafegam os dados das aplicações de gerência). Este é o NGN BRM (Basic Reference Model), descrito na Recomendação ITU-T Y.2011, de onde foi retirada a figura abaixo:

Observem que a divisão entre os planos de usuário, controle e gerenciamento dentro de cada estrato é puramente lógica, servindo mais para propósitos administrativos (ex.: determinação dos critérios de QoS aplicáveis a cada caso) do que indicando segregação rígida dos diversos tipos de tráfego dentro de cada estrato.

E assim chegamos, finalmente, no ponto principal para o sucesso da idéia das NGNs: conseguir criar um ecossistema de aplicações que reconheçam um mesmo padrão para a troca de sinalização de controle entre elas. O 3GPP (3rd Generation Partnership Program) fez a primeira proposta abrangente para suportar um ecossistema de aplicações IP que utilizam o protocolo de sinalização SIP (Session Initiation Protocol - veja RFC 3261): o IMS (IP Multimedia Subsystem).

Embora o IMS tenha surgido no contexto das redes móveis, ele mostrou-se bastante adequado para o cenário convergente da NGN, então a ITU-T, na Recomendação Y.2021, adotou o IMS como solução padrão de sinalização SIP para serviços convergentes e all-IP para NGNs.

Vou apresentar a seguir o modelo de referência básico para o IMS, tal como aparece na Recomendação Y.2012, mas aviso logo: tanto a recomendação ITU quanto as especificações do 3GPP que se referm ao IMS causam em mim a impressão que elas foram escritas por computadores, com a intenção de que fossem lidas por máquinas de calcular. Vou (na medida do possível) tentar abrandar isso.

Muito bem... Sem pânico. O primeiro elemento importante a observar é aquela caixinha despretensiosa na parte inferior esquerda do diagrama, marcada UE (User Equipment). Ela representa qualquer tipo de dispositivo que o usuário possa estar utilizando para concetar-se à NGN. A linha do UE para a direita apenas indica que ele tem conectividade IP à NGN, através do estrato de transporte (que, claro, incorpora os segmentos de acesso, backhaul e core).

Os outros relacionamentos importantes do UE são com o AS-FE (Application Server Functional Entity), que é o elemento de tratamento de sinalização no servidor de aplicação que o usuário está tentando acessar (esta comunicação é regida conforme o protocolo de interface Ut - não vou nem tentar detalhar estes protocolos de interface); e com o elemento principal da estrutura do IMS, o CSCF (Call Session Control Function).

O CSCF executa todas as funções que, tradicionalmente, são chamadas de call control: o estabelecimento da sessão (call initiation), os eventos durante a sessão - inclusive aqueles ligados a tarifação (o call control propriamente dito), e o término da sessão (call termination).

O UE entra em contato, usando o protocolo de interface Gm, com o proxy CSCF (P-CSCF). Este elemento pode ser um dos CSCFs nativos da NGN de registro do usuário (nada impede que o CSCF seja implementado de forma distribuída), ou um dos CSCFs da NGN visitada pelo usuário (se ele estiver em roaming em outra NGN). O P-CSCF vai selecionar um serving CSCF (S-CSCF) para executar de fato as funções de call-control. Não vi nenhuma restrição (e acho lógico) que, no caso de um UE dentro da sua própria NGN de registro, as funções de P-CSCF e S-CSCF não possam ser acumuladas por uma única instância do CSCF.

Se a sessão de serviço demandada pelo UE implique em troca de sinalização com servidores que utilizem perfis de sinalização SIP diferentes do IMS, ou outros protocolos de sinalização utilizados em ambiente IP (ex.: H.323), o P-CSCF e o S-CSCF utilizam o serviço de intermediação de um IBC-FE (Interconnection Border gateway Controller Functional Entity), usando o protocolo de interface Mx.

Para os casos de UEs em roaming, ou de tráfego de sinalização que esteja apenas em trânsito através de uma NGN, aparece uma nova variedade de para o CSCF: o interrogating CSCF (I-CSCF), que faz o meio de campo da comunicação entre o P-CSCF e o S-CSCF. A comunicação entre todas estas variantes funcionais do CSCF são regidas pelo protocolo de interface Mw.

O S-CSCF interage com o AS-FE no servidor de aplicação demandado pelo UE através do protocolo ISC (IMS Service Control) e pelo protocolo de interface Ma. Para a correta designação e acesso do S-CSCF ao AS-FE existe a intermediação de elementos de localização (SL-FE - Subscription Locator Functional Entity) e autorização/autenticação (SAA-FE - Service Authentication and Authorization Functional Entity; e SUP-FE - Service User Profile Functional Entity).

Se a sessão de serviço demandada pelo usuário necessita utilizar recursos específicos do estrato de transporte da NGN (ex.: classe de QoS, registro/retirada em grupos de multicast, etc.) o CSCF usa um outro elemento do IMS, o MRFC (Multimedia Resources Control Function), que aciona o elemento MRP-FE (Multimedia Resources Processor Functional Entity) para a implementação das ações específicas de suporte à sessão do serviço no estrato de transporte da NGN.

Para a interoperação de serviços NGN com redes de telecomunicação legadas (PSTN/ISDN) o S-CSCF interage com o MGCF (Media Gateway Control Function). No caso de haver necessidade de trânsito do tráfego entre a NGN e a PSTN/ISDN o S-CSCF utiliza o BGCF (Breakout Gateway Control Function) para determinar qual TMG-FE (Trunking Media Gateway Functional Entity) no estrato de transporte deve ser usado para efetuar o "salto" do tráfego entre as redes. A troca de sinalização fim a fim (SIP/SS7) é mediada por um SG-FE (Signalling Gateway Functional Entity).

Só para terminar, caso vocês ainda não tenham percebido, elementos responsáveis pelo processo de sinalização IMS são chamados Control Functions. Elementos que interagem com o IMS para determinar como executar suas funções corretamente são chamados Functional Entities.

E chega! Acho até que, para um texto introdutório, fui até complexo demais. Isto encerra a série de artigos sobre a evolução das redes (e serviços) de telecom. Espero que tenham gostado da viagem, e até breve.

Auf wiedersehen...

Teste de afinidade com programação Assembly - entendendo o exemplo

Se você estiver na lamentável situação de nem sequer iniciar o teste porque não conseguiu entender o funcionamento do programa apresentado no exemplo, e porque ele é uma solução válida para o problema, não desespere.

Sua situação, na verdade, corresponde à maioria das pessoas que fazem o teste sem nenhum conhecimento prévio de linguagens de programação de baixo nível e/ou toria da computação e/ou arquitetura de computadores.

Para facilitar a sua vida vou fazer algo bem fora de moda hoje em dia: um teste de mesa. Vamos simular (por escrito) a execução passo a passo do programa e verificar se o efeito produzido corresponde ao que se pede.

Cada passo do programa será representado da seginte forma:

Vamos começar. Esta é a situação inicial (válida para todos os casos): cabeçotes de leitura e gravação posicionados no início da mídia e primeira instrução a executar no endereço de memória 0.

Após a execução da instrução T, como o caracter lido na mídia foi um *, a próxima instução a executar estará no endereço de memória 0 + 2 = 2. Observe a nova posição do cabeçote de leitura.

Agora a instrução executada é H, que grava um - na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço de memória 3.

Desvio incondicional para a instrução no endereço de memória 0.

Voltamos à instrução T. Após execução o cabeçote de leitura é reposicionado e, como o caraccter lido foi um -, a próxima instrução a executar está no endereço de memória 0 + 1 = 1.

Desvio incondicional para a instução no endereço de memória 4.

Executa a instrução A, que grava um * na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço 5.

O desvio para a instrução na posição de memória 0 voltará a executar a instrução T. A esta altura já dá para perceber toda a mecânica de execução do programa, que vai percorrer toda a mídia (supostamente de comprimento infinito) substituindo os caracteres * por -, e vice versa, como pedido.

Se ainda assim você não consegue entender como escrever os programas para solucionar os problemas propostos, então realmente é melhor você se dedicar a linguagens com sintaxe mais abstrata.