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.

Gabarito do teste de afinidade com programação Assembly

Rapaz! o post do teste de habilidade para programação Assembly me surpreendeu. Em apenas dois dias conseguiu chegar no 3º lugar geral de visualizações do blog, com 240 acessos até agora, sendo que o 1º colocado tem 381 visualizações. Impressionante.

De qualquer forma, aqui vai o gabarito dos problemas propostos, conforme prometido. Quem quiser discutir alguma das soluções apresentadas, ou quiser apresentar alguma outra solução, melhor ou alternativa (pense bem antes de fazer isso - em mais de 20 anos não apareceu nada melhor que isso), sinta-se à vontade em usar a área de comentários deste post, e eu digo o que acho da sua idéia, ok? Então vejamos:

Problema 1: AHAT12 ou AHT0A2 (duas soluções, com 6 instruções). Pontuação: 2 pontos para cada  solução válida que você tenha encontrado.

Problema 2: T5AT7H0H3 (9 instruções). Pontuação: 2 pontos para a solução correta.

Problema 3: T0T0T097HT8AT8AT8A7 (19 instruções). Pontuação: 2 pontos pela estrutura lógica geral do programa, e mais 2 pontos se você acertou a "pegadinha" de colocar o programa em loop para forçar a parada (no sentido do programa não fazer mais nada, não da máquina não executar nenhuma instrução).

Meu critério pessoal de avaliação dos candidatos que fazem este teste é que, para ter futuro nesta área, a nota mínima neste teste é 6. Se você conseguiu, parabéns! Você proavelmente não terá diificuldade em habituar-se com a programação Assembly em qualquer arquitetura de hardware.

Se não conseguiu, paciência. Sugiro que você tente outras linguagens de programação, que não Assembly.

Correlação estatística entre câncer e celulares!

Finalmente alguém teve uma idéia nova nesta área tão controversa.

Será que você leva jeito para programação Assembly?

Cerca de 25 anos atrás, em uma das minhas encarnações anteriores como systems programmer, meu gerente surgiu com um teste de aptidão para avaliar a competência dos candidatos ao cargo de programador na área de raciocínio lógico.

Depois eu passei a ver este teste como uma forma legal de avaliar se um determinado candidato tinha potencial pra trabalhar na área de systems programming, porque o teste tem muito a ver com programação Assembly: entender a arquitetura da máquina e saber usar as instruções de máquina.

Se você tiver curiosidade sobre sua possível habilidade para esta área da Informática, sugiro que tente fazer o teste abaixo. As regras são as seguintes:

1. Você tem, no máximo, uma hora para fazer o teste;
2. Todas as informações necessárias para responder às questões estão no texto;
3. A interpretação das questões faz parte do teste.

Se você não se der bem, não se desespere. Eu mesmo, quando fiz o teste, não consegui terminar corretamente a terceira questão. E até hoje eu só encontrei uma pessoa que "gabaritou" o teste, e ele fez isso com requintes de crueldade: as duas primeiras questões ele fez de cabeça, e a terceira só precisou de um pouco de rascunho. Demorou, no total, uns 10 minutos.

Enfim, vamos ao enunciado. Depois publico o gabarito. Quem tiver um pouco de familiaridade com a teoria da computação vai reconhecer que o que vamos usar no teste é uma máquina de Turing.

Um computador hipotético é composto por:

a) Unidade de fita magnética cujos cabeçotes de leitura e gravação possuem acionamento independente (ou seja: é possível estar lendo e gravando em posições físicas diferentes da mídia montada na unidade) e, quando acionados, sempre atuam na direção progressiva de leitura/gravação da mídia;

b) Memória de tamanho infinito, com cada posição de memória sendo capaz de armazenar uma única instrução de máquina, e endereçamento das posições de memória de forma sequencial, crescente, iniciando em 0 (zero), com todos os endereços expressos em decimal;


c) CPU que sempre inicia a execução dos programas a partir da posição de memória com endereço 0 (zero) e que, com exceção dos casos previstos no instruction set, executa as instruções de máquina de forma sequencial em ordem crescente dos endereços de memória;

d) Instruction set:
d.1) Instrução A - causa a gravação de um caracter * (asterisco) na mídia montada na unidade de fita magnética;
d.2) Instrução H - causa a gravação de um caracter - (hífen) na mídia montada na unidade de fita magética;
d.3) Instrução T - causa a leitura de um caracter na mídia montada na unidade de fita magnética e: se o caracter lido for - (hífen) executa a seguir a instrução no endereço de memória x + 1; se o caracter lido for * (asterisco) executa a seguir a instrução no endereço de memória x + 2; onde x é o endereço de memória onde reside a instrução T;
d.4) Instrução n (onde n = 0,1,2,3,4,5,6,7,8 ou 9) - causa desvio incondicional para a instrução de máquina no endereço de memória n.

Para cada um dos exemplos apresentados e problemas propostos supõe-se que:

1) Existe mídia montada na unidade de fita magnética, cujo conteúdo inicial é uma sequência aleatória dos caracteres * (asterisco) e - (hífen), e tanto o cabeçote de leitura quanto o cabeçote de gravação da uidade de fita magnética estão posicionados no início físico da mídia;


2) Todas as posições da memória estão preenchidas com uma sequência aleatória de instruções de máquina válidas;


3) Não é possível codificar instruções de máquina inválidas;


4) Todos os programas par asolução dos problemas iniciam-se na posição de memória de endereço 0 (zero).


EXEMPLO:


Trocar, na mídia de fita magnética, cada caracter * (asterisco) por - (hífen), e vice-versa.

Resposta: T4H0A0



Com estas informações, elabore programas com o menor número possível de instruções de máquina que solucionem os problemas propostos.


PROBLEMAS PROPOSTOS:


P.1) Gravar, na mídia de fita magnética, o padrão de caracteres: *-**-***- ... (um asterisco, um hifen, dois asteriscos, um hífen, três asteriscos, um hífen, ...).


P.2) Trocar, na mídia de fita magnética, cada segundo caracter * (asterisco) encontrado pelo caracter - (hífen).


P.3) Localizar, na mídia de fita magnética, a primeira ocorrência do string *** (três asteriscos consecutivos) copiar, a partir do início da mídia de fita magnética, todos os caracteres que se seguem ao string localizado até encontrar a próxima ocorrência do string *** (três asteriscos consecutivos), copiando-os, inclusive, e depois parar.

Boa sorte!

O que aprender com Marie Curie, Lise Meitner e Emmy Noether?

Redes de telecomunicação (11) - Going all-IP (parte 2)

Seguindo com o assunto da conversão das redes fixas e móveis convencionais em uma estrutura convergida e all-IP, comumente denominada Next Generation Network - NGN.

A arquitetura da NGN que vimos na parte anterior deste artigo não tinha a menor condição de acontecer sozinha, ou em separado da estrutura convencional dos serviços de voz por comutação de circuitos. Três problemas fundamentais precisavam ser solucionados para que a NGN pudesse surgir como uma evolução, e não como uma ruptura com a arquitetura das redes existentes:

1. Como garantir a interoperação entre usuários do serviço convencional de telefonia e usuários do serviço de voz na NGN, que utilizam Voice over Internet Protocol (VoIP)?
2.  Como substituir a transmissão convencional TDM (veja este artigo anterior) por uma rede TCP/IP?
3. Como controlar a utilização de serviços de voz, video e dados dos usuários NGN?

Nesta parte deste artigo vamos responder às primeiras duas questões. A resposta para a terceira questão fica para a próxima parte.

Na telefonia convencional (Plain Old Telephone Service - POTS) o estabelecimento dos circuitos para tráfego de voz é mediado pela troca de sinalização entre os elementos da rede. Esta sinalização normalmente é dual-tone multifrequency (DTMF) entre os aparelhos dos usuários e as suas respectivas centrais de comutação local, e Common Channel Signaling System #7 (CCSS7 ou SS7) entre centrais de comutação.

Tanto o canal para o tráfego de voz quanto os canais de interconexão entre os elementos de sinalização SS7 (essencialmente Service Switching Points - SSPs e  Signal Transfer Points - STPs) são mapeados sobre a rede de transmissão TDM, tanto na arquitetura PDH quanto na SDH/SONET (veja artigos anteriores aqui e aqui), como no modelo abaixo.

Quando as operadoras fixas começaram a suportar o tráfego da Internet isso foi feito simplesmente usando a rede de transmissão para mapear conexões virtuais, fim a fim, entre os roteadores. Com o tempo esta estrutura passou a ser suportada sobre uma outra rede de roteadores IP, configurados para formarem um serviço agnóstico de transporte no nível da camada 2 do modelo OSI, chamado Multi-Protocol Label Switching (MPLS), que efetivamnte substituiu os serviços de comunicação de dados baseados em X.25 e Frame-Relay (veja este artigo anterior). Sobre a rede de roteadores IP/MPLS mapeiam-se redes virtuais privativas (Virtual Private Networks - VPNs) que isolam logicamente o tráfego de cada grupo de usuários. Nosso modelo operacional, agora, adquiriu a seguinte aparência.

O próximo passo do caminho é a introdução de um novo tipo de central de comutação, conhecido como softswitch. Uma softswitch é composta por dois tipos de elementos: um Media Gateway Controller (MGC) que, como diz o nome, controla um conjunto (que pode ser geograficamente disperso) de Media Gateways (MGW), responsáveis pelo transcoding e pala conectividade VoIP do tráfego de voz.

Quanto à sinalização, o MGC incorpora:

•  Um elemento SSP da sinalização SS7, o que permite que a softswitch interopere com as centrais de comutação POTS tradicionais;
• Sinalização de controle dos seus MGWs subordinados, conforme a recomendação  ITU-T H.248.1 v3 

nota histórica: O protocolo H.248 foi desenvolvido conjuntamente pela ITU-T e pela IETF (MEGACO -  RFC 3015, e GCP - RFC 3525) mas, como explicado na RFC 5125, a ITU-T assumiu integralmente a tarefa de especificação deste protocolo.

O tráfego de sinalização SS7 convencional também pode ser adaptado para transporte sobre IP através de gateways SIGTRAN, que são vistos como SCPs pelos SSPs convencionais, e tunelam entre eles as mensagens SS7 sobre a rede de transporte IP/MPLS. Falando nisso, tipicamente criam-se duas novas VPNs (ou Virtual Routing and Forwarding - VRFs, no jargão MPLS) para o transporte individualizado do tráfego de voz e do tráfego de sinalização.

Finalizando o modelo temos o tráfego TDM legado que, por algum motivo, não possa ser acomodado através das softswitches. Para isso os roteadores IP/MPLS implementam emulação de circuitos TDM sobre o transporte IP, de acordo com os padrões desenvolvidos pelo grupo de trabalho Pseudo-Wire Emulation Edge to Edge (PWE3) da IETF.

E assim chegamos, finalmente, aos dias atuais. Pelo desenho acima já deu pra perceber que gradualmente o tráfego está sendo transportado nativamente sobre IP/MPLS, e que as hierarquias de transmissão TDM (PDH e SDH/SONET, que foram explicados antes neste artigo e neste artigo) vão sendo progressivamente relegadas ao papel de suporte ao tráfego de equipamentos ou serviços legados, para os quais não existe solução prática diretamente sobre a rede de transporte IP/MPLS.

Mesmo o papel de oferecer conectividade entre os roteadores IP/MPLS está gradualmente saindo da esfera dos multiplexadores SDH, com a gradual adoção de redes ópticas de grande capacidade, que fazem FDM (falamos disso neste artigo) sobre fibras ópticas. Mas, como sempre acontece, damos um novo nome a velhas coisas, e isto passa a ser conhecido como Wavelength Division Multiplexing (WDM). A depender da quantidade de comprimentos de onda (lambdas, para os íntimos) que podem ser multiplexados sobre uma fibra óptica, estes sistemas são chamados de Coarse WDM (CWDM) ou Dense WDM (DWDM).

Existe (mais uma!) "guerra religiosa" em andamento nesta área, a respeito de como organizar o plano de controle da rede de transporte integrada formada pelos roteadores IP/MPLS e pelos elementos da rede WDM. As hipóteses disputando a dominância de mercado são:

• Usar o plano de controle dos roteadores IP/MPLS, e manter a rede óptica subjacente apenas como canais de transporte independentes. Neste modo os roteadores IP/MPLS usam interfaces IP over DWDM (IPoDWDM) para interoperar ativamente com a rede óptica, de acordo com a recomendação G.709/Y.1331 da ITU-T;
• Usar o plano de controle da rede óptica configurada como uma OTN, e interligar os roteadores IP/MPLS de forma passiva, através de transponders;
• Integrar os planos de controle IP/MPLS e óptico. As propostas mais avançads neste sentido são o MPLS-TP e o GMPLS, ambos com muito trabalho a ser feito antes de poderem ser utilizados em larga escala.

Caramba, como isso tá ficando comprido! Vou parar por aqui e, na próxima (e, possivelmente, última) parte deste artigo vou falar da arquitetura geral para uma NGN fixa e móvel, e vamos falar do IMS, como um dos elementos chave desta arquitetura convergente.