Transcrições

31/07/08
Sobre "planos_B" (1)- Mensagem de José Smolka

É imprescindivel uma forma alternativa de acesso aos consoles de roteadores em pontos remotos. Se admira uma Tele não ter circuitos SLDD especificos para esta função, se foi realmente este o caso de falha no acesso aos equipamentos.
Havia plano de contingência/plano de continuidade dos negócios?
No caso da Atento, só há comunicação via rede (em caso de catastrofe eles ficam no escuro)?

Então vamos falar um pouco sobre planejamento de contingência, ou, para usar um termo mais fashion: business continuity plan (BCP). No popular: o "plano B" para situações de emergência.

Primeiro uma analogia no plano pessoal. Alguém aí tem uma apólice de seguro de vida que cubra a hipótese de ser atingido pela queda de um meteoro? Não?? E alguém tem seguro contra tsunamis? Também não??? Mas seguro do automóvel contra furto e roubo eu aposto que vcs tem, não é? Porque será?

Simples. Quando decidimos gastar o nosso dinheirinho suado na prevenção de algum sinistro, nós avaliamos se o risco compensa a despesa com a prevenção. E quando uma empresa tem que decidir sobre o seu BCP não é diferente. Tudo resume-se a quantificar objetivamente (nos termos que a alta administração entende: $$$) o dano causado pela manifestação de um determinado risco e o custo da sua prevenção ou mitigação. Trazendo estes valores para o valor presente líquido (VPL), se o custo da ocorrência do dano for maior que o custo da prevenção/mitigação, então o investimento é justificado. Senão esqueça.

Alguém aí pode estar pensando: peraí... mas existem os danos intangíveis, como dano de imagem. Mesmo estes podem e devem ser quantificados. Você pode traduzir o dano de imagem, por exemplo, em perda estimada de receita pela fuga de clientes atuais ou pelo não cumprimento de metas de captação de novos clientes.

O segredo do negócio é organizar uma matriz de riscos x danos. Mas, o que é um risco? Em todo negócio existem vulnerabilidades. Equipamentos podem quebrar, fornecedores podem descumprir contratos, podem acontecer greves ou desastres naturais, sabotagem, espionagem, you name it. Analisando o elenco das vulnerabilidades do negócio, o responsável pela montagem do BCP tem que determinar qual é, dentro de um horizonte definido no tempo, a probabilidade destas vulnerabilidades serem atingidas por algum evento. Cada conjunto vulnerabilidade + probabilidade de ocorrência é um risco.

A matriz é montada posicionando cada vulnerabilidade como um ponto em um gráfico cartesiano onde o eixo x representa o tamanho do dano, e o eixo y representa a probabilidade de ocorrência. Divide-se então o plano em 16 áreas:, definidas por 4 faixas para o valor do dano e para a probabilidade de ocorrência (baixo, médio, grande e muito grande - cada empresa precisa definir o que estes termos significam no seu contexto específico). A depender das disponibilidades orçamentárias, ataca-se prioritariamente as faixas de dano muito grande e de probabilidade muito grande, e sucessivamente vão sendo elaborados planos de ação para cada ponto restante, sempre considerando a comparação do VPL com o custo da prevenção ou mitigação. Nos casos de riscos com baixa probabilidade e baixo dano, a decisão executiva pode ser de aceitar o risco e não fazer nada.

O caso é: eu não acredito que o pessoal que administra a rede MPLS da Telefónica (corpo técnico e gerencial) tenha descuidado disto. Pode até ser que eles não sejam brilhantes, mas malucos eles não são. Eles certamente fizeram o dever de casa para colocar na rede MPLS todas as salvaguardas necessárias para garantir a continuidade do serviço, mesmo que com alguma degradação temporária e/ou localizada, para todos os riscos com probabilidade razoável de ocorrência.

E o que de fato aconteceu, estava nesta classe? Acredito que não. Falhas de links e roteadores, até mesmo falhas duplas simultâneas, são eventos razoavelmente prováveis, e cobertos via redundância planejada dos elementos da rede. Uma falha geral do roteamento tem probabilidade semelhante de ocorrer? No way. Não se você seleciona cautelosamente os seus fornecedores e tem um bom conjunto de práticas administrativas para fazer o change management da rede. E eu acho que eles fazem tudo isto. Pode até não ser perfeito, mas fazem.

Apesar das explicações não parecerem completas, em um ponto eu não tenho dúvidas: foi algo inesperado, tão improvável que não haveria medida economicamente justificável para a sua prevenção. Por isso, quando aconteceu, foi um burn through total. Se fosse em uma usina nuclear teria sido a "síndrome da china".

E continuamos à espera dos detalhes do laudo do CPqD...

[ ]'s
J. R. Smolka_

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Sobre "planos_B" (1)- Mensagem de José Smolka

29/07/08
Como funciona a Internet (29) - Mapeando os "nossos" backbones (17) - Smolka responde à Luiz Sérgio

 ----- Original Message -----
From: José de Ribamar Smolka Ramos

--- Em Celld-group@yahoogrupos.com.br, "luiz sergio lindenberg nacinovic" <lsnvic@...> escreveu:

O problema é o de sempre. Muita frequência para um backbone congestionado.
A conexão tem dias que chega 11kbps, impossibilitando qualquer coisa. Uma bullshit.

Oi Luiz,

Além dos comentários que fiz no post de resposta à Jana (que podem valer para vc também), existem outras considerações adicionais para avaliar onde estão os reais "gargalos" de performance.

É notório que operadoras de telecom usam DPI para fazer bandwidth throttling de aplicações consideradas "indesejáveis", como P2P em geral (eMule, Gnutella, e mesmo VoIP com provedores que não estejam no "barco" da operadora).

Faça o seguinte: abra duas janelas distintas para cada aplicação (talvez duas "abas" diferentes do browser sejam suficientes) e observe se o desempenho de ambas é ruim, ou se uma é significativamente pior que a outra.

No primeiro caso o problema pode ser de congestionamento upstream (que pode ser no DSLAM, nos roteadores do backbone da operadora - que tem uma rede MPLS por baixo - ou nos links/roteadores de peering dela com outros AS da Internet).

No segundo caso possivelmente vc está sendo vítima das policies implementadas pela operadora no DPI. Digo possivelmente, porque ainda existem outros fatores que influenciam, como qual a rota seguida pelo seu tráfego na Internet até o destino final (podem haver congestionamentos fora do alcance administrativo da operadora), ou o "estado de saúde" da máquina com a qual vc está se conectando. Discos cheios, pouca memória, pouco processador, banda de acesso insuficiente para atender à demanda de conexões dos usuários, má configuração do SO ou do programa servidor, tudo isto pode fazer com que um site da Internet ofereça um serviço ruim, mesmo que a rede esteja boa.

[ ]'s
J. R. Smolka_

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (29) - Mapeando os "nossos" backbones (17) - Smolka responde à Luiz Sérgio

29/07/08
Como funciona a Internet (28) - Mapeando os "nossos" backbones (16) - Smolka responde à Jana de Paula

--- Em Celld-group@yahoogrupos.com.br, "Jana" <jana_depaula@...> escreveu Em AZUL

Estou com a impressão de que está se armando um apagão no Rio de Janeiro. Com as promoções de pacotes triple play, o barateamento do PC e tudo o mais deve ter aumentado muito o número de assinantes do velox (Oi), no Rio de janeiro.
Isto tem abalado a rede. A intermitência do serviço é de irritar monge tibetano (e olha que eles aturam há aaaaanos o domínio chinês...).

Oi Jana,
O problema que vc está levantando é sempre uma possibilidade em redes de acesso DSL, como é o caso dos serviços Velox (da Oi) e Speedy (da Telefónica).

Sempre quando a gente reclama, eles sempre partem do princípio que a falha é nossa, clientes. Mas, se fôsse, porque tem dias que ela fica uma uva e eu navego em céu de brigadeiro?

Sei que isto vai parecer antipático, mas vc já teve que trabalhar com atendimento a clientes? Eu já. E é complicado. Especialmente no caso de serviços de informática para o público em geral (mesmo que seja dentro de uma rede corporativa).  Porque, apesar de todos os esforços em tornar os computadores pessoais em coisas mais parecidas com eletrodomésticos convencionais, eles ainda são coisas complicadas demais para a compreensão do usuário médio (veja um post recente meu onde mencionei o blinking twelve problem).

Costuma-se dizer que é impossível criar um sistema à prova de idiotas (idiot-proof system), porque os idiotas são muito criativos. Uma piada clássica sobre isto é a seguinte (diálogo entre o atendente do suporte técnico e um usuário):

- Suporte técnico, bom dia. Em que posso ajudar?
- Quero que alguém conserte o porta-copos do meu computador. Ele estava funcionando normalmente, mas quebrou.
- Perdão senhor, mas... porta-copos? É alguma espécie de acessório opcional que foi entregue junto com o seu computador?
- Não. Todas as máquinas que eu vi na loja tinham porta-copos, e o meu agora está quebrado. Quero que consertem.
- Desculpe senhor, mas realmente não estou entendendo. O senhor pode descrever melhor este acessório?
- Posso sim. Eu ativo o porta-copos, que fica em um compartimento lacrado, apertando um botãozinho na frente dele. Então a bandeja do porta-copos se projeta para fora, e eu posso colocar meu copo em cima dela.
- Por favor, existe alguma coisa escrita na frente deste compartimento lacrado?
- Tem sim... Aqui diz "CD/DVD ROM"...

Então, embora seja irritante ser tratado como idiota, em princípio, pelos atendentes de suporte técnico a serviços como o Velox, entenda que uma proporção imensa dos chamados que eles recebem tem parentesco próximo com o diálogo acima. Eles estão tentando eliminar os casos mais óbvios de BIOS (burrice imensa do operador do sistema).

Hoje fiquei meio irritada e comecei a falar ao atendente todas as letrinhas da sopa que aprendi com o professor Smolka. MPLS, NGN, PQP... ui!
Daí que finalmente eles viram que de fato "o sinal estava fraco". O que significa isto eu não sei. Mas, cá com os meus botôes, acredito que tá se armando um ''pobrema" aqui no Rio.

Você fez a coisa certa nestes casos. Mostrar ao atendente da primeira linha que o seu caso está fora dos scripts padronizados dele. Isto força que ele escale o seu caso para alguém mais especializado. Quanto ao PQP... deixa pra lá

Agora quanto ao problema em si. Acessos DSL são especialmente sensíveis às condições elétricas do par de fios utilizado. Se vc está, eletricamente falando, muito longe da central (onde está instalado o DSLAM), e/ou se a fiação na rota que lhe atende (cabos tronco, armários, cabos de distribuição aérea, cabos de entrada no edifício, e também a fiação interna da sua casa/prédio) não estiver em boas condições de isolamento, é certo que vc terá problemas.

Claro que problemas de performance também podem acontecer upstream do DSLAM, mas, no seu caso, eu procuraria eliminar esta possibilidade primeiro.

Peço encarecidamente que caso haja pessoas ligadas à Oi neste grupo, chequem isto.
Conversei com vários moradores aqui da minha área (Piratininga-Niteroi) e eles estão com os mesmos problemas. Chiado da linha (isto é péssimo para transmissão de dados no cobre) e dificuldade para acessar a internet.

Se outros usuários na mesma região que vc experimentam problemas semelhantes, então existe uma grande chance de ser realmente algo com a fiação daquela área. Para eliminar outras possíveis causas tente o seguinte: combine com um(a) amigo(a) que utilize o mesmo serviço, com a mesma banda contratada mas em local distinto da cidade, para que vcs acessem simultaneamente os mesmos sites ou serviços na Internet. Falem por telefone enquanto navegam, e comparem os tempos de resposta. Se os tempso dele forem sistematicamente melhores que os seus, então a hipótese do problema de fiação é mais provável. Se ambos estiverem ruins, então provavelmente o problema é upstream (mas o problema de fiação ruim também pode existir em paralelo).

É o POVO falando.

É verdade, mas cuidado com esta argumentação. Aceitar proposições como verdadeiras porque "a voz do povo é a voz de Deus" é uma falácia conhecida como argumentum ad populum.

[ ]'s
J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (28) - Mapeando os "nossos" backbones (16) - Smolka responde à Jana de Paula

28/07/08
Como funciona a Internet (24) - Mapeando os "nossos" backbones (13) - Smolka comenta as explicações da Telefonica

----- Original Message -----
From: José de Ribamar Smolka Ramos
To: Celld-group@yahoogrupos.com.br
Sent: Monday, July 28, 2008 11:03 AM
Subject: [Celld-group] Re: Apagão - TEM QUE SER LIDO!

--- Em Celld-group@yahoogrupos.com.br, "luiz sergio lindenberg nacinovic" <lsnvic@...> escreveu ("em azul")

> Grande Mestre. É o Luixsergio! Lembra de mim?

Lembro sim...

> Aqui estou eu novamente te chateando com minhas perguntas mal formuladas.

Não se preocupe com isso. É melhor uma pergunta mal-formulada do que uma dúvida não esclarecida.

> 1)No seu entender, qual a hipótese mais provável a respeito do "caladão" da Telefónica?
> 2) Esses roteadores não são auto-reprogramáveis- a exemplo daqueles D-Links domésticos?
> 3) O sr. acredita em falha de software?

Vamos com calma... Segundo o noticiário, A Telefónica comunicou à Anatel o laudo do CPqD, e deverá ter uma reunião com o CGI.br sobre o assunto. Embora o laudo não tenha sido publicado, o que vazou na imprensa é que o problema originou-se em uma interface ótica no roteador de Sorocaba, que fazia o link dele com outro roteador em Campinas. Então, vamos tentar aplicar um pouco de raciocínio lógico nisto.

Primeiro, pouco importa o fato da interface ser ótica (porque eles insistem em escrever "óptica?), elétrica, ou mesmo através de sinais de fumaça ou pombos-correio. A alegação é que a interface sofreu um problema de hardware. Muito bem... Se a interface tivesse simplesmente saído do ar, então não haveria problema (pelo menos não deste tamanho). O roteador de Campinas perceberia a queda do link para Sorocaba, alteraria suas tabelas de rotas para o caminho alternativo (que certamente existe; esta história que a rede não possuía "plano B" é bullshit), e em alguns minutos, no máximo, tudo estaria funcionando normalmente. E só a região servida pelo roteador de Sorocaba sentiria o problema, enquanto o restante da rede seguiria em frente sem transtornos.

Então o que deve ter acontecido é que a interface de Sorocaba não caiu, mas ficou em um estado instável onde, do ponto de vista do roteador em Campinas, o link ficava flutuando aleatoriamente entre os estados up e down. Isto faria que o roteador de Campinas ficasse tentando, sucessivas vezes, estabelecer uma rota alternativa (quando ele visse o link down) e voltar para a rota primária (quando ele visse o link up novamente). O nome técnico desta situação é route flapping.

No caso, ocorreria um LSP (label switching path) flapping entre os roteadores de Sorocaba e Campinas. Se o roteador de Sorocaba for (como disseram) um roteador de borda MPLS (denominação técnica: um provider edge router - PE), então muito provavelmente (porque acredito que a rede tem um projeto decente) ele estaria conectado a outro roteador do core MPLS (denominação técnica: um provider router - P), além do roteador de Campinas (que deve ser P). Ainda assim, nas CNTP o problema ficaria localizado entre os roteadores P (em Campinas e em outro site) e o roteador PE (em Sorocaba).

O que não está bem explicado é porque um problema de LSP flapping que deveria ficar localizado tornou-se generalizado. Para entender isto é preciso conhecer uma série de detalhes da rede da Telefónica: topologia, fornecedores dos roteadores P e PE envolvidos na raiz do problema (e as versões de SO em cada um deles), forma de distribuição dos labels na rede (I-BGP, LDP ou ambos), qual o IGP utilizado (OSPF ou IS-IS), se os roteadores MPLS também fazem full routing com a Internet, und so weiter... Provavelmente tudo isto está no laudo do CPqD, que não foi publicado.

Em resumo (supondo que o que foi divulgado procede), uma falha de hardware evoluiu para um completo meltdown do software responsável pelo roteamento global na rede. E porque demorou tanto tempo para isolar a falha? Acho que é o seguinte: o gerenciamento de falhas na rede é feito remotamente, a partir dos NOCs (network operations centers) da Telefónica, usando SNMP. Se todo o roteamento falhou catastroficamente, então as aplicações de gerência SNMP não conseguiam estabelecer contato com os objetos gerenciados, nem dava para acessá-los remotamente via sessões telnet. A única alternativa era despachar gente para cada site para intervir localmente. Como (provavelmente) a maioria dos sites funciona em regime lights-out operation, e os técnicos responsáveis pelo atendimento remoto são terceirizados, isto demorou. Ainda assim, não deveria ter demorado dois dias. Seis a doze horas eu consigo entender. Dois dias não.

Para terminar, um pouco de bom humor. Nos lugares que funcionam em regime lights-out operation, costuma-se dizer que são necessárias duas coisas: um operador e um cachorro. O cachorro é para vigiar o site e não deixar o operador mexer em nada (porque tudo é automático). E o operador é para dar comida e água ao cachorro .

> Meu nome real é Luiz Sergio Nacinovic. Obrigado por ter me respondido daquela outra vez. Um abraço.

Pra vc também Luiz.

J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (24) - Mapeando os "nossos" backbones (13) - Smolka comenta as explicações da Telefonica

26/07/08
• Como funciona a Internet (22) - Mapeando os "nossos" backbones (11) -  Mensagem de José Smolka

----- Original Message -----
From: J.R.Smolka
To: Celld-group@yahoogrupos.com.br
Sent: Saturday, July 26, 2008 11:25 PM
Subject: Re: 

Obs: esta mensagem cita o texto publicado pelo Estadão em 12/07/08: O apagão da internet

Caro mct3 (na falta de uma identificação melhor vou tratá-lo pelo seu cyber-nickname, ok?),

Vou ignorar o tom socialóide e "ai que saudades do sistema Telebrás" que polui todo o texto, e vou me concentrar no seguinte: o conhecimento que o sr. Celso Ming, responsável pela coluna (disponível para consulta na versão on-line d'O Estado de São Paulo), possui sobre os aspectos técnicos do problema é parecido com o que eu tenho sobre neurocirurgia. E a fonte utilizada na reportagem aparentemente também padece do mesmo mal.

Parece inútil, mas vou dizer assim mesmo, e "gritando": NÃO ACONTECEU APAGÃO DA INTERNET! QUEM PAROU CATASTROFICAMENTE FOI A REDE MPLS DA TELEFÓNICA! Fui claro?

Acontece que rigorosamente tudo que seja tráfego IP que passe pela rede da Telefónica é transportado pela rede MPLS. Quando ela caiu (por motivos ainda não esclarecidos) tudo que dependia dela também parou: os usuários do serviço DSL da própria Telefónica (Speedy), a rede de serviços do governo estadual de SP (Intragov), conexões IP de redes corporativas, etc. etc.

Entre estes etc. muito provavelmente está a Atento, que presta serviços de call-center à Telefónica (e também é uma empresa do grupo Telefónica). Para atender aos clientes da Telefónica os funcionários da Atento precisam acessar os sistemas de TI da própria Telefónica, que ficam em servidores nos data centers da Telefónica, e este acesso depende, com altíssima probabilidade, de links IP entre os call-centers e a Telefónica que cursam através da rede MPLS. Portanto qual é a surpresa em saber que os call-centers não conseguiam dizer nada claro a respeito do incidente, se eles mesmos estavam entre os serviços afetados?

O que não quer dizer que eu acredite piamente no (muito pouco) que foi publicado a título de explicação do ocorrido. Continuo achando que uma "caca" deste tamanho dificilmente poderia ser causada apenas por um roteador de borda que "pirou" em Sorocaba. Ainda quero saber melhor do lado técnico desta questão, até porque eu também tenho uma rede MPLS para me preocupar, e se algo semelhante puder acontecer com a minha rede, quero saber como prevenir ou remediar com antecedência.

[ ]'s

J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (22) - Mapeando os "nossos" backbones (11) -  Mensagem de José Smolka

13/07/08
Como funciona a Internet (15) - Mapeando os "nossos" backbones (04) - Nova mensagem de José Smolka

Julião, !3runo (legalzinho esse negócio de leetspeak :-) ) e demais colegas,

Vou tentar me limitar às questões técnicas, e deixas ar discussões sobre política e legislação para a troca de posts com o Rogério :-) .

Primeiro a questão "quem veio primeiro o ovo ou a galinha?" do BGP-4 versus AS. Vou transcrever a introdução da RFC 1930 - Guidelines  for creation, selection and registration of an Autonomous System (AS) - que pode ser consultada em http://tools.ietf.org/html/rfc1930:

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such.  ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.

Nesta mesma RFC, na seção 3 (definitions), está escrito que:

The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it.

To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.

Routing policy here is defined as how routing decisions are made in the Internet today. It is the exchange of routing information between ASes that is subject to routing policies.

Portanto para mim é claro que:

a) O conceito de AS foi criado para definir unidades administrativas que controlam segmentos lógicos (isto é, uma parte do espaço de endereçamento IPv4 ou IPv6) da Internet e a forma de roteamento no seu interior. Sem isto seria impossível que a Internet atingisse a escala mundial que ela tem hoje;

b) Cada AS deve apresentar aos demais AS (isto é, para o restante da Internet) uma política de roteamento única e claramente definida (isto é, como o tráfego destinado a endereços IP no seu interior deve ser encaminhado até a sua "fronteira"). Já o roteamento dentro da "fronteira" de cada AS é de sua exclusiva opção e responsabilidade;

c) A forma como estas políticas de roteamento entre AS são comunicadas entre eles é através das mensagens de um protocolo de exterior routing, compartilhado em comum acordo por toda a comunidade dos AS. Este protocolo já foi o EGP (RFC 904), hoje é o BGP-4 (RFC 4271), e um dia (talvez, when the hell freezes over :-) ) venha a ser o IDRP (ISO/IEC 10747).

Mas as interconexões AS-AS mostram apenas a organização lógica da Internet. Por baixo disto (e muito mais obscura) está a estrutura física de encaminhamento do tráfego.
É um fato (e não só no Brasil) que a posse física dos meios de conexão interfere muito na maneira como as coisas ocorrem na prática.
Vamos ver, como exemplo, a RNP (ASN 1916).
 Ela é dona dos seus roteadores, mas os links que os conectam certamente não são de sua propriedade.
Então, no mapa que mostra a topologia da RNP (e também o seu "estado de saúde") em http://www.rnp.br/ceo/trafego/panorama.php, podemos ver que no nó principal de tráfego SP existem conexões para a Embratel (ASN 4230) e para a Global Crossing (ASN 3549).
Supondo que os roteadores destes dois AS também estejam localizados em SP, existe uma forte possibilidade que os dois links passem pela infra-estrutura da rede MPLS da Telefónica, e tenham caído juntos durante o meltdown.

O caminho alternativo de tráfego mais óbvio seria a conexão SP-RJ, mas se alguma parte física deste link também depender da rede MPLS da Telefónica, adiós.
Próxima alternativa seria rotear o tráfego via DF e MG (desde que o link SP-DF também não tenha caído junto com os outros), mas existe a possibilidade de congestionamento se a falha ocorrer em HMM.
Conclusão: se os administradores da RNP não planejarem com cuidado de quem eles contratam os seus links, a esperada resiliência do projeto lógico da rede vai pras cucuias.

Se este problema existe no nível urbano das maiores cidades do país, imagine o resto.
Quando se trata se provimento de enlaces interestaduais a quantidade de escolhas se reduz a meia dúzia de operadores, e nem todos os trechos que alguém gostaria de conectar possuem mais de um operador com caminhos físicos completamente distintos.
Saídas internacionais? Se vc precisa de banda de verdade (digamos, assim, algumas centenas de Mbps) a única alternativa prática são os cabos submarinos de fibras óticas.
No mapa disponível em http://www1.alcatel-lucent.com/submarine/refs/World_Map_2007_LR.pdf eu contei sete cabos de conexão internacional e um cabo de uso puramente doméstico.
A administração destes cabos geralmente é feita por consórcios, e aposto alguns destes consórcios operam mais de um cabo.

A conseqüência final é que os pontos de interconexão das redes tendem a ser colocados apenas nos locais onde o agregado de tráfego justifique o custo.
E é por isto que os grandes provedores de interconexão, que operam os AS de "passagem" para os pequenos provedores de interconexão (que fazem o varejo do negócio de acesso à Internet), cobram "pedágio".
Enquanto o tráfego da Internet for composto principalmente por aplicações best effort (ex.: http e smtp) estas "voltas do mar" que o tráfego tem de fazer para passar de um AS para outro não chegam a comprometer a performance (alguns milissegundos a mais ou a menos? No big deal).
Mas, quando houver um volume considerável de tráfego real-time, isto será um problema.
Será um problema grande o suficiente a ponto de forçar uma mudança neste estado de coisas? Depende de vários fatores, mas isto é assunto para outro post.

Ah! Só para terminar... Alguém aí sabe quais seriam os impedimentos técnicos de lançar um trecho de cabo submarino de Fortaleza a Belém, e um trecho "subfluvial" de Belém a Manaus? Isto daria um desafogo e tanto para a região norte, onde praticamente só se chega por satélite.

[ ]'s

J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (15) - Mapeando os "nossos" backbones (04) - Nova mensagem de José Smolka

11/07/08
Como funciona a Internet (11) - Mapeando os "nossos" backbones (01) - Mensagem de José Smolka

Oi Julião e demais colegas do grupo.

Vou usar a sua principal pergunta como "gancho" para este post.

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (11) - Mapeando os "nossos" backbones (01) - Mensagem de José Smolka

Nota: a mensagem abaixo do Smolka faz referência ao "post" Como funciona a Internet (6): Os "nossos" backbones + Teleco: Tutorial sobre MPLS  que continha estas perguntas:

----- Original Message -----
From: J.R.Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Thursday, July 10, 2008 2:35 AM
Subject: Re: [wireless.br] Como funciona a Internet (5): Os "nossos" backbones + Teleco: Tutorial sobre MPLS

Hélio,
Entendo a sua ansiedade :-)   
E, realmente, a estrutura lógica e física da Internet, mesmo que só no nosso "cantinho" nacional da rede, não é tão fácil de entender.

Mas talvez a situação não seja de desespero total, embora haja um bocado de trabalho braçal a fazer (taí uma boa empreitada para "almas dedicadas" :-) ).

Andei dando umas "fuçadas" e descobri o seguinte:
o site da IANA (http://www.iana.org/numbers/) remete para o registrar base da América Latina, o LACNIC (http://lacnic.net/pt/index.html).

Como eu já sabia que o bloco CIDR de endereços IPv4 200.223/16 pertence à Oi/Telemar, dei uma consultada neste bloco no whois do LACNIC (a opção está na margem direita da página).

Lá diz apenas que este bloco CIDR está "embutido" no bloco CIDR 200.128/9, que está alocado para o Comitê Gestor da Internet Brasil (id BR-CGIN-LACNIC).

Parece um beco sem saída, não?
Mas o CGI.br também tem o seu serviço whois (http://whois.registro.br).
Consultando lá o bloco CIDR 200.128/9 encontramos a Oi/Telemar (ou Tele Norte Leste Participações S/A), e o que é mais interessante, o AS number (ASN) que a identifica como um autonomous system da Internet: 7738.

Aqui cabe uma explicação.
Os AS são as unidades administrativas da Internet. Só que eles não se interligam de maneira hierárquica, e sim federativa, de acordo com suas próprias conveniências técnicas e comerciais.

A navegação que vou descrever a seguir mostra que mapear os relacionamentos de interconexão entre eles de forma manual é possível, mas enjoado.

Abra a página do CIDR Report (http://www.cidr-report.org) no seu browser.
No final da (longuíssima) página inicial, que é uma série de relatórios sobre o estado de advertisement dos diversos blocos CIDR na Internet, existe uma opção de selected AS report.
Informando lá o ASN 7738 e clicando no botão generate AS report vamos para uma página com os relatórios deste AS.
Não estranhe o fato do relatório indicar a Telecomunicações da Bahia S/A como owner deste ASN, muitas informações de detalhes não são sincronizadas entre os vários registrars (no caso, IANA, LACNIC e registro.br).
O que nos interessa é o AS adjacency report.
Lá vemos que a Oi/Telemar possui oito AS upstream, todos internacionais, e vários AS downstream, todos nacionais (embora alguns não tenham o nome declarado - mas, usando o whois do registro.br, dá para verificar que são no Brasil).
Primeira conclusão: o AS da Oi/Telemar é uma "borda nacional".

Os ASN no relatório são hyperlinks, então vamos clicar no primeiro ASN downstream: Belgo Mineira Sistemas (ASN 14723).
Lá só encontramos dois AS upstream, a própria Oi/Telemar e a Embratel (ASN 4230), e nenhum AS downstream.
Segunda conclusão: a Belgo Mineira Sistemas é um AS "fim de linha", e todo o seu tráfego de/para o restante da Internet é encaminhado através dos AS da Oi/Telemar e da Embratel (em que proporção, e sob que condições é um acerto entre eles).

Bom... Acho que já chega.
Resumindo o processo, dá para "mapear" a estrutura lógica de interconexão dos AS da Internet Brasil (a estrutura física é uma conversa totalmente diferente) percorrendo, a partir de cada AS de "borda nacional", a lista os AS downstream até encontrar todos os AS "fim de linha".

Só tem dois probleminhas com esta idéia...

Primeiro é a natureza braçal da tarefa, se tiver que ser feita do jeito que eu descrevi.
Pode ser que esta atividade não seja pior que ser atendente de call-center, mas chega perto... Nem estagiário merece ser tratado assim :-) .

Segundo é a natureza dinâmica dos relacionamento entre os AS.
Quando vc terminar o mapeamento existe uma grande probabilidade dele estar desatualizado.
É até possível que o dinamismo do uso e interligação dos AS no Brasil não seja tão grande como em outras partes do mundo, mas acho que este mapeamento teria que ser atualizado pelo menos em base mensal.

Mas não acho que seja uma tarefa muito difícil de automatizar.
Até mesmo se for o caso de criar um programa que leia as páginas do CIDR report e vá interpretando dinamicamente os conteúdos, não é uma tarefa de programação muito complexa.
E o desenvolvimento poderia ser patrocinado, por causa do interesse público no assunto, pelo próprio Comitê Gestor da Internet Brasil.

Alguém aí conhece o pessoal do CGI.br para ver se esta idéia tem futuro ou não?

[ ]´s
J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (9): Smolka dá uma pista para encontrar a estrutura da Internet no Brasil.

Anatel e as recentes "Consultas Públicas" (9) - Ainda as "13 Perguntas" - Smolka: STFC e NGN

O serviço de telecomunicações que, por meio da transmissão de voz e de outros sinais, destina-se à comunicação entre pontos fixos determinados, utilizando processos de telefonia.
[http://www.planalto.gov.br/ccivil_03/decreto/D2534.htm]

Como já disse em outra ocasião, esta definição me parece meio tautológica, mas é o que temos, então vamos em frente com ela meso. Nestes termos, os serviços oferecidos através de uma rede de telecomunicações não podem ser enquadrados dentro da definição do STFC se:

a) Não envolverem a transmissão de voz (só outros sinais não vale);

b) Os serviços forem prestados de forma móvel ou nômade (porque aí não seria comunicação entre pontos fixos determinados);

c) Não utilizarem processos de telefonia (achou isto obscuro? Eu também).

Pela definição de NGN vemos que transmissão de voz e outros sinais está dentro do contexto, então não dá para descaracterizar uma rede NGN como base de prestação do STFC pelo critério (a). Porém uma NGN completa deverá suportar generalized mobility, e isto a desqualifica para a prestação do STFC pelo critério (b). Mas não vamos ser xiitas. Supondo uma implementação mais restrita, sem incluir na rede o suporte à mobilidade e/ou nomadicidade dos usuários, então ela ainda não poderia ser descartada com base neste critério. O real ponto crítico é o critério (c). O que vem a ser estes tais processos de telefonia? Consigo imaginar duas interpretações para esta expressão.

A interpretação mais restrita é que processos de telefonia significa que a rede utiliza somente o conceito de circuit switching (inclusive no que diz respeito às mensagens de sinalização). Se adotarmos esta linha de raciocínio podemos parar por aqui, porque uma NGN, por definição, é inteiramente baseada em packet switching. Quem entender que esta é a forma correta de interpretar o que diz o PGO atual quer dizer com a expressão processos de telefonia poderia terminar a leitura neste ponto, porque o assunto estaria resolvido.

Mas é possível (e eu prefiro) uma interpretação mais flexível. A expressão processos de telefonia pode ser entendida como a capacidade da rede de:

a) Suportar conexões de assinantes que utilizem, no mínimo, terminais telefônicos convencionais (com ou sem o uso de ATAs);

b) Garantir que o nível mínimo de interoperabilidade (estabelecimento de sessões funcionais de uso do serviço) entre os terminais conectados à rede é a transmissão de voz, com características de qualidade equivalentes ao serviço telefônico convencional (o referencial de qualidade é o encoding PCM conforme a Recomendação ITU-T G.711).

Desta forma daria para acomodar uma rede NGN (ou híbrida, com partes NGN e partes convencionais) dentro da definição do STFC. Mas, considerando a "fúria tributária" do Governo, creio que preferirão criar todo um novo elenco de definições de serviço, cada um com suas respectivas exigências de permissão e/ou concessão - porque assim maximiza-se a receita com licitações, FISTEL, etc.

Então a resposta à nossa primeira pergunta é um sonoro depende!  Parece que a possibilidade de enquadrar uma NGN fixa dentro do STFC é inversamente proporcional ao quanto o intérprete entender que a tecnologia empregada tecnologia define o serviço. Mas, mesmo que se adote uma interpretação mais elástica, haverá um break point que forçará a redefinição do marco regulatório. Em minha opinião, o "ponto de não retorno" está diretamente ligado à proporção entre as quantidades de terminais convencionais (incluindo aí os que utilizem ATAs) e terminais de nova geração (que suportem múltiplos serviços, com sinalização SIP mediada por IMS). Se a "população" de terminais NG na planta exceder 20% do total, então não dá mais para fingir que nada mudou.

O que nos leva à segunda pergunta do dia. Será que as operadoras do STFC já estariam over the edge? A situação das redes fixas hoje é (em maior ou menor grau, dependendo da operadora):

a) A esmagadora maioria dos terminais ainda é convencional (pares metálicos ligados diretamente à central local, com sinalização DTMF). Mesmo nos casos onde o acesso é feito com modems DSL, tipicamente o tráfego de voz gerado por terminais convencionais convive em paralelo com o tráfego puramente digital de outros serviços (via FDM, com separação dos tráfegos no DSLAM: voz vai para a central telefônica e dados vão para o roteador IP);

b) As centrais convencionais vem sendo complementadas ou substituídas por softswitches, para obter ganho estatístico de capacidade nos enlaces de transmissão usando VoIP (bearer channels na forma de sessões RTP entre as MGW). Desta forma uma parcela crescente do tráfego de voz está sendo cursado na transmissão em modo packet switching;

c) O protocolo de sinalização entre os nós de comutação (centrais convencionais e os MGCs) ainda é o SS7, mas, em paralelo com a introdução das softswitches na rede, também está ocorrendo a adaptação do transporte das mensagens SS7 sobre IP, seja pelo uso de gateways ou de forma nativa (veja as RFCs produzidas pelo working group SIGTRAN da IETF em http://www.ietf.org/html.charters/sigtran-charter.html).

d) Os serviços de dados estão praticamente todos concentrados sobre uma rede de transporte IP/MPLS, que compartilha a banda dos enlaces de transmissão com o tráfego de voz circuit switching (declinante) e com o tráfego VoIP (crescente). Desta forma o tráfego total em modo packet switching está em vias de superar o tráfego circuit switching na transmissão, e a conseqüência disto é que enlaces PDH e SDH estão tornando-se progressivamente inadequados, e substiruídos por enlaces que operam nativamente em modo packet switching (ex.: Metro Ethernet), inclusive nos acessos corporativos e residenciais. Meu palpite é que em 2012 os enlaces PDH e SDH representarão não mais que 30% da capacidade total de transmissão, e que sejam completamente substituídos até 2016.

Então, considerando o critério de um threshold de 20% de terminais NG na planta como o "divisor de águas" entre o STFC e o serviço (ou serviços) que vier(em) a comportar o ambiente NGN, eu acho que as operadoras fixas ainda estão do lado de cá da cerca. Porém elas estão se aproximando rapidamente dela. Até o ano que vem nós vamos ver o início da oferta de acessos VDSL2 e xPON para empresas e nas áreas residenciais mais fashion. O lógico é que estes lançamentos sejam acompanhados pelo lançamento dos primeiros serviços mediados por IMS, e, daí para a frente, é tudo ladeira abaixo.

Novamente fazendo previsões, creio que o alea jacta est regulatório tem que ocorrer até 2010. Depois disto o risco de confusão é grande.

Tive a seguinte idéia, que talvez seja um bom exercício de discussão na ComUnidade: como vocês acham que poderia ser a regulamentação dos serviços baseados em NGN? Como definir as características destes serviços mantendo coerência com os princípios de separação entre serviço e transporte, agnosticismo tecnológico e convergência fixo-móvel embutidos na própria definição de uma NGN?

Sou todo ouvidos...
[ ]'s
J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Anatel e as recentes "Consultas Públicas" (9) - Ainda as "13 Perguntas" - Smolka: STFC e NGN

----- Original Message -----
From: J.R.Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Friday, July 04, 2008 10:37 AM
Subject: [wireless.br] Ainda sobre as 13 perguntas

Oi Rogério, Hélio e demais colegas,

Vou escrever no "pretinho básico" mesmo :-) , e me ater aos principais pontos da discussão (que estão espalhados em várias das 13 perguntas), porque eles acabam colocando todo o resto nos trilhos (ou fora deles, sei lá). Os leitores que estejam interessados em consultar o texto das diversas leis, decretos e quetais que são mencionados, podem encontrá-los a partir da página de legislação da Presidência da República em http://www.presidencia.gov.br/legislacao/.

Ao invocar o finado CBT (Lei 4.117 de 27/08/19620) vc fez uma eloqüente defesa do que era o serviço de troncos. Digo finado porque a LGT (Lei 9.472 de 16/07/1997) diz:

Art. 215. Ficam revogados:
I - a Lei n° 4.117, de 27 de agosto de 1962, salvo quanto a matéria penal não tratada nesta Lei e quanto aos preceitos relativos à radiodifusão;

E digo era porque, embora concorde com a definição dada no antigo CBT, a colocação do art. 207 da LGT em obrigar as operadoras que atuavam nos moldes do CBT - incluídas aí as operadoras do serviço de troncos (além da Embratel, quem mais?) - a renovarem suas concessões nos moldes da LGT, conjugada com a permissão explícita da operação dos troncos dada às operadoras do STFC, nas modalidades local, LDN e LDI, pelo art. 2° do PGO atual (Decreto 2.534 de 02/04/1998), deixa muito claro - pelo menos para mim - que a intenção explícita do legislador era "embutir" o extinto serviço de troncos dentro do STFC.

Mas vamos admitir, por hipótese, que este serviço viesse a ser destacado novamente, em separado do STFC. O que os usuários dos serviços de telecom ganhariam com isto? Em minha opinião: nicht, nothing, nada. Pelo contrário, a vida deles ficaria pior. Teríamos mais uma camada empresarial na cadeia cliente-fornecedor da prestação dos serviços, sem nenhuma mudança na maneira como os enlaces são efetivamente usados. E esta camada extra vai querer garantir a sua margem de lucro (ou vc entende que isto devia ser operado diretamente pela União?), portanto quem vai pagar o pato vai ser o usuário, na forma de contas mais altas devido ao repasse deste custo adicional.

Agora o caso da Embratel. Nos termos do CBT era muito claro que ela era operadora do serviço de troncos. Com o advento da LGT o que ela poderia ser? O que consigo entender, dada a definição do STFC feita no art. 1 do PGO atual (especialmente no parágrafo 2°), é que ela opera apenas as modalidades LDN e LDI do STFC, e este seria o novo enquadramento do seu contrato de concessão, exigido pelo art. 207 da LGT. Isto está de acordo com o art. 6°, e detalhado no item 35 do anexo III, do PGO atual. Além disto, ela não teria mais direito a exclusividade na exploração destes serviços, de acordo com o art. 5° do PGO atual. Não vejo paradoxo nenhum aqui, porque neste papel ela continuaria fazendo exatamente o que sempre fez: prover os enlaces (ou troncos, como queira) - e centrais telefônicas, não esqueçamos delas - para trânsito do tráfego inter-áreas de registro e internacionais.

Após a privatização a Oi (então Telemar) na região I, a BtT na região II e a Telefônica na região III (conforme definidas no anexo I do PGO atual) devem ter pleiteado e conseguido concessões para operar também as modalidades LDN e LDI do STFC. Além disto houve a outorga de mais uma concessão para operar LDN e LDI para a "espelho" da Embratel - a Intelig (cadê ela?). Ao assinante foi dada a opção de escolher qual das operadoras LDN ou LDI ele preferia utilizar (via inclusão do CSP no processo de "discagem" deste tipo de chamada telefônica).

A gente não deve esquecer que a LGT foi editada em um momento particular. Ao mesmo tempo que ela redesenha o cenário dos serviços de telecom (anteriormente definidos pelo CBT, que ela substitui e revoga explicitamente) ela tem que lidar com o cenário de transição do modo CBT de fazer as coisas para o novo modelo. O art. 207 e o anexo III tem de ser lidos e entendidos neste contexto: regular o que acontece entre a edição da LGT e a privatização do Sistema Telebrás. Se não fosse assim, o art. 207 não deveria estar nas disposições finais e transitórias, mas em algum outro livro, capítulo, whatever.

Este é meu ponto de vista sobre estes assunto. Não sinto a necessidade de criticar, conceitualmente, esta estrutura legal (já a sua execução pode ser outra conversa). Mas, também, nisto eu sou leigo. Como os advogados são especializados em "procurar pelo em ovo" neste tipo de situação, não vou tentar competir com eles :-) . Como engenheiro e analista de sistemas prefiro o no-nonsense, e esta análise me satisfaz.

Mas vamos em frente... Sobre a Anatel ter ou não poderes para celebrar os contratos de concessão. Assumindo que o que depois foi formalizado na Lei 9.649 de 27/05/1998 já constava na looonga cadeia de MPs que a precederam (creio que a lista completa conta no art. 64), então porque o Minicom não protestou, interveio, contestou, ou qualquer coisa do gênero, os contratos celebrados pela Anatel? Porque ele se conformou que a anatal atuasse como sua "procuradora" neste assunto e momento?

No entanto, admitindo que os contratos são ilegais por este motivo, e portanto nulos de pleno direito, só tem dois caminhos possíveis: anular tudo e começar de novo (inclusive com novas licitações); ou convalidar tudo com uma nova "penada" legal do Presidente da República - afinal, para que mais servem as MPs :-) ? Minha opinião é que, caso pressionado, o Governo vai pela segunda via. A primeira, por mais desejável que fosse para alguns, simplesmente ain´t gonna happen. Não com este Governo (Presidente e Ministros - especialmente o Sr. Hélio Costa) nem com este Congresso. Minha opinião pessoal é que, neste caso, não compensa o rebuliço, a insegurança regulatória e tudo o mais em nome do purismo ideológico ou do desejo de criar embaraços políticos ao atual Governo.

Finalmente temos o nosso grande ponto de discordância: a possibilidade (ou falta dela, no seu entender) da introdução de tecnologias não tradicionais - por comodidade, vamos agrupar todas elas debaixo do título NGN - para o transporte de voz e ainda assim chamar isto de STFC, dentro da lei. Para esclarecer direito meus pontos de vista neste assunto eu terei que ser mais que claro. Vou ser didático - embora isto pareça chato e pedante. Porém isto piora a minha já natural tendência à prolixidade :-) , então vamos fazer o seguinte: vou separar esta conversa em duas threads: a primeira diz respeito aos aspectos legais e regulatórios (que já falei), e a segunda sobre os aspectos técnicos do STFC em um ambiente de migração para NGN (que colocarei no meu próximo post), ok?

Sendo assim, até breve...

[ ]'sJ. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Anatel e as recentes "Consultas Públicas" (8) - Ainda as "13 Perguntas" - Smolka continua o debate

Rogério e demais colegas da ComUnidade,

Vou destacar em azul o texto das 13 perguntas que o Rogério colocou, e acrescento meus comentários após cada uma delas. Minha postura geral é a do "advogado do diabo", mas minha intenção é garantir a solidez da argumentação.

Pergunta 1: Por que a Embratel ainda não se tornou a concessionária do serviço de troncos, conforme determina expressamente o art. 207 da LGT?

Embora a leitura de textos legais não seja a minha ocupação predileta, resolvi dar uma boa olhada nos textos da LGT (Lei 9.472 de 16/07/1997 -  http://www.planalto.gov.br/ccivil_03/Leis/L9472.htm) e do PGO atual (Decreto 2.534 de 02/04/1998 - http://www.planalto.gov.br/ccivil_03/decreto/D2534.htm).

O art. 207 das disposições finais e transitórias da LGT trata da obrigação das operadoras do então Sistema Telebrás, em via de privatização, pleitearem a junto à Anatel a assinatura de novos contratos de concessão. O texto menciona o STFC e o "serviço de troncos e suas conexões internacionais", mas não os define (aliás, a LGT não define nenhum serviço de telecomunicações).

O único serviço definido no PGO é o STFC (no art. 1°), e o art. 2° especifica que são direitos das prestadoras do STFC (sem restrição se nas modalidades local, LDN ou LDI) a "implantação, expansão e operação dos troncos, redes e centrais de comutação necessárias à sua execução" (grifo meu).

Então, se a intenção do legislador ao editar a LGT era definir a existência de um serviço específico de operação de troncos de interconexão, porque ele não foi especificado no PGO, da mesma forma que o STFC? Será que havia mesmo esta intenção? Será que esta menção, de passagem, em um artigo das disposições finais e transitórias da LGT, é o suficiente para criar um casus belli?

Pergunta 2: Por que a Anatel outorgou uma concessão de STFC de longa distância para a Embratel, se a LGT não prevê a existência desse tipo de concessão?

A LGT não especifica nenhum tipo de serviço, mas o PGO atual, no art 1°, parágrafo 2°, incisos I, II e III definem as modalidades local, LDN e LDI da prestasção do STFC. Então qual é o problema da Anatel outorgar uma concessão deste tipo à Embratel se isto é exatamente o que ela sempre fez, desde os tempos do Sistema Telebrás?

Pergunta 3: Como poderia a Anatel ter celebrado os contratos de concessão com as antigas subsidiárias Telebrás no dia 02.06.98, se a Lei 9.649/98 atribui  expressamente ao Minicom as competências da outorga, regulamentação e fiscalização dos serviços de telecomunicações?

Aqui tem um perigo escondido, porque a redação destas obrigações foi alterada. A Lei 9.649 de 27/05/1998 (disponível em http://www.planalto.gov.br/ccivil_03/Leis/L9649cons.htm) define a macro estrutura do Poder Executivo Federal e as competências de cada órgão. No art. 14, inciuso III, alínea b, estas competências são, de fato, atribuídas ao Minicom. Mas esta redação foi dada pela MP 2.216-37 de 31/08/2001, portanto posterior à data de celebração dos contratos mencionados. Então cabe a pergunta: dada a legislação vigente em 1998, a Anatel realmente excedeu a sua competência?

Mais interessante ainda (supondo que a Casa Civil da Presidência mantenha o seu acervo de textos legais na Internet atualizados) é que os incisos V e VI do art. 19 da LGT não aparecem como revogados ou com redação alterada por algum ato posterior à edição da LGT, e eles atribuem exatamente as mesmas competências à Anatel. Então, qual das duas Leis prevalece?

Pergunta 4: Por que a minuta do novo PGO, a exemplo do atual, não faz nenhuma alusão à existência da concessionária do serviço de troncos?

Cabe a mesma observação anterior. Será que realmente houve, algum dia, a intenção de definir o tal "serviço de troncos"?

Pergunta 5: Por que as concessionárias do STFC estão explorando comercialmente serviços de âmbito nacional e internacional em redes STM-16 e STM-64 específicas da rede de troncos, se o status de concessionárias regionais de telefonia permite apenas que elas operem redes STM-1 e STM-4?

Porque, se a Anatel outorgou a elas as concessões de exploração do STFC nestas modalidades, nos termos do art. 2° do PGO atual, elas tem este direito.

Agora, se tivesse que haver uma definição para o "serviço de troncos", ele teria que ser feito em termos das condições onde o encaminhamento do tráfego teria que ser feito, obrigatoriamente, via a concessionária deste serviço, e não pela tecnologia ou banda das conexões utilizadas. A mim parece que a possibilidade de escolha do prestador do serviço LDN ou LDI pelo assinante (via inclusão do CSP no endereço de identificação do destinatário da chamada telefônica) preenche exatamente este papel.

Os vários STM (synchronous transport module) citados definem formatos e bandas de transmissão da tecnologia SDH (synchronous digital hierarchy). Mas porque algumas bandas seriam típicos do serviço de troncos e outras não? Creio que a interconexão de centrais dentro da área de registro 11 (São Paulo - Capital) estoura os 622,08 Mbps de um link SDH STM-4. E os troncos verdadeiramente pesados para LDN e LDI já estão migrados para transporte ótico WDM (wavelength division multiplexing). Sem falar do papel que tem as redes Metro Ethernet (hoje a 10 Gbps, e com 40 e 100 Gbps em discussão no IEEE), que não são esta aberração toda. Mas veremos isto depois.

Pergunta 6: Por que a Anatel permite que as concessionárias do STFCexplorem serviços públicos de comunicação de dados (ex. links IP,Velox, Speedy e BR-Turbo), se essa atividade é vedada à elas pelos arts. 69 e 86 da LGT?

Perdão, mas estes artigos não proíbem nada disto. O art. 69 diz que é competência da Anatel definir as diferentes modalidades dos serviços de telecomunicações, e o seu parágeafo é o mais longe que a LGT vai na definição de serviços, ao afirmar que telefonia e transmissão de dados, por exemplo, não são o mesmo serviço. Já o art. 86 diz que a outorga de concessão para exploração de serviços de telecomunicações só pode ser feita a empresas constituídas sob as leis brasileiras, com sede e administração no país, e específicas para a prestação do serviço objeto da concessão.

Então creio que a interpretação que vc fez destes dois artigos é: o serviço de comunicação de dados é distinto do STFC (art. 69, parágrafo único), portanto ele deveria ser objeto de concessão específica (que a Anatel nunca fez), mas, mewsmo que fosse explorado pelo mesmo grupo econômico, teriam de haver empresas separadas para cada concessão (art. 86).

Minha pergunta então é: vc acha que isto afeta apenas o roteamento IP e o entroncamento de tráfego entre os AS (autonomous system) da Internet, ou isto também afetaria os serviços de SLDD (serviço de linha dedicada de dados) e redes de pacotes X.25 e Frame-Relay? Acessos de banda larga empresarial para acesso à Internet (hoje a moda é ofertar acessos Ethernet a 10 ou 100 Mbps para isto)? E os serviços de VPN (virtual private networking) MPLS (multi-protocol label switching) que sucedem as redes de pacotes convencionais para que empresas possam montar redes IP privativas?

Pergunta 7: Por que a Anatel permite que os provedores de acesso sejam utilizados até hoje como fachada para ocultar a exploração ilegal de serviços públicos de comunicação de dados pelas concessionárias do STFC?

Como falei acima, quem disse que os serviços de comunicação de dados resumem-se ao acesso de banda larga residencial à Internet? Hoje isto é feito principalmente pelo reaproveitamento dos pares de cobre da rede de acesso com modems DSL (digital subscriber line), mas isto também está mudando. Fala-se abertamente em bandas residenciais da ordem de 30 Mbps, com redes PON (passive optical networking).

Pergunta 8: Por que, antes, as concessionárias do STFC precisavam da fachada dos provedores para explorarem serviços de rede IP em banda larga (aDSL) e agora não precisarão mais dela?

Em termos puramente técnicos da montagem da infra-estrutura de acesso à Internet, isto nunca foi necessário. A explicação, IMHO (in my humble opinion), é um cabo-de-guerra entre os lobbies dos provedores de acesso à Internet e das operadoras do STFC.

Quando o negócio de acesso à Internet estava na infância, haviam vários pequenos provedores de acesso dial-up fixo (tipicamente ex-provedores de serviços de BBS - bulletin board systems) que operavam bancos de 20 ou 30 modems e um número correspondente de linhas telefônicas. Se as operadoras do STFC "entrassem de sola" instalando seus próprios RAS (remote access servers), seria uma quebradeira geral dos pequenos provedores de acesso. Neste ponto o lobby dos provedores era mais forte, e entendia-se que as operadoras não podiam vender diretamente o acesso, apenas intermediá-lo.

Eventualmente o darwinismo empresarial concentrou o mercado de provedores de acesso em poucos players, que terceirizaram os RAS com as operadoras do STFC e passaram a conectar-se via links E1 ou E3 (hoje, provavelmente, Metro Ethernet ou SDH), e o risco de quebradeira generalizada passou. Neste meio tempo as operadoras STFC abandonaram de vez a ilusão do B-ISDN (broadband integrated services digital network) e mergulharam de cabeça na instalação de acessos DSL. Agora era o lobby das operadoras que ficava mais forte. Se não vai haver quebradeira, porque obrigar o assinante a fechar um contrato de acesso com um provedor de banda larga, cerca de 3 vezes mais caro que o contrato de acesso dial-up? Para mim, isto é questionável com base na Lei de Defesa do Consumidor, porque é venda casada.

Junte a isto, possivelmente, uma interpretação mais liberal do art. 154 da LGT et voilà, chegamos ao estado atual das coisas.

Pergunta 9: Por que a Anatel permitiu que a Telemar celebrasse um contrato de "turn key" com a Siemens em 2005 para cumprir obrigações de universalização de atendimento às comunidades com mais de 300 habitantes utilizando redes metro ethernet e telefonia IP, se o padrão IEEE 802.3, além de não fornecer suporte ao Sistema de Sinalização por Canal Comum (SSC-7) dos serviços públicos de telefonia fixa, também não atende aos requisitos de QoS do STFC?

Primeiro: porque é mais barato fazer assim do que usar os meios convencionais.

Segundo: o que caracteriza o STFC não é a tecnologia de transporte, mas a capacidade de interoperar livremente dentro do plano de numeração, nacional e internacional. Ou seja: se você é capaz de estabelecer uma conexão funcional entre dois terminais telefônicos (independente da tecnologia de construção de cada um deles) para a "transmissão de voz e outros sinais" você está dentro dos "processos de telefonia" previstos no art 1° do PGO atual (que, na minha opinião, é uma tautologia).

Terceiro: a questão da sinalização não é, de maneira nenhuma, impedimento para a interoperação de terminais, quer a originação-terminação da chamada telefônica seja IP-IP, IP-POTS (plain old telephony service) ou POTS-IP. O que acontece é que os terminais IP não usam sinalização DTMF (dual-tone multi-frequential) para o call-setup. Eles usam, muito provavelmente, SIP (session initiation protocol - IETF RFC 3261). O terminal IP é o SIP client, e o papel de SIP server pode ser feito por uma softswitch - que é uma "federação" entre uma MGC (media gateway controller) e um ou mais MG (media gateway). Quando o call-setup envolve terminais convencionais, a MGC usa SS7 para negociar o estabelecimento do circuito com as centrais convencionais. Já o bearer channel da conexão telefônica é uma sessão RTP (real-time transport protocol - IETF RFC 3550) entre os terminais IP (em uma chamada IP-IP) ou entre o terminal IP e o MG designado pela MGC para encaminhamento da conexão, com o encaminhamento do MG para as centrais convencionais usando os meios tradicionais (em uma chamada IP-POTS ou POTS-IP).

E, last but not least, quarto: quem disse que não dá para garantir QoS neste tipo de ambiente? É apenas uma questão de engenharia adequada. Eu mesmo já escrevi alguns artigos sobre isto (que estão postados em http://www.wirelessbrasil.org/jose_smolka/js01.html). E se ainda não lhe convenci, considere o seguinte: que eu saiba todas as empresas da lista Fortune 500 (e várias outras menos fashion, inclusive no Brasil) já migraram suas comunicações internas para VoIP, com transporte LAN (local area network) IEEE 802.3 e/ou WLAN (wireless LAN) IEEE 802.11, e cada uma delas é uma comunidade maior que 300 pessoas. E uma rede Metro Ethernet é, grosso modo, uma LAN com esteróides :-)

Pergunta 10: Por que a Anatel batizou as redes metro ethernet (NGNs) como "backhaul do STFC", se essas redes, destinadas única e exclusivamente à comunicação de dados, não têm nenhuma relação com as redes PDH e SDH do STFC?

Conforme a Recomendação ITU-T Y.2001 (General Overview of NGN),  uma NGN (next generation network) é uma rede de comutação de pacotes para a prestação de serviços de telecomunicação. Pelo andar da carruagem, a tecnologia melhor posicionada para satisfazer este papel é o IP. Mas uma rede de transporte Metro Ethernet (que transporta muito bem tráfego IP) não é necessariamente uma NGN, e pode, sim, com a engenharia adequada, ser usada como rede de suporte do STFC, conforme vimos na resposta anterior.

Provavelmente as tecnologias de transmissão PDH (plesiochronous digital hierarchy) e SDH sobreviverão ainda por algum tempo no contexto POTS, mas eu não compraria ações de empresas que dependem principalmente da venda deste tipo de equipamento para sobreviver.

Pergunta 11: Por que o decreto 6.424/2008 imputou metas de universalização de redes metro ethernet (travestidas de "backhaul do STFC") às concessionárias de telefonia fixa, se essas redes, inadequadas para o STFC, serão utilizadas pelas empresas exclusivamente para exploração de serviços de comunicação de dados em regime privado, violando os art. 69 e 86 da LGT?

Como já vimos antes, as redes Metro Ethernet podem sim, com a engenharia adequada, ser usadas como backhaul do STFC, tanto no legado POTS quanto nos segmentos pré-NGN da rede. Como não é a tecnologia, mas a função desempenhada que importa, então não vejo problema com esta definição.

Esta é uma opinião puramente técnica, e não implica em nenhum julgamento de valor sobre se esta é ou não uma meta válida para constar no novo PGMU.

Pergunta 12: Considerando que, nos termos dos arts. 2º, 84º, 87º e 175º da CF e da alínea "b" do inciso V do art. 14 da Lei 9.649/98, o Minicom representa o Poder Executivo na condição de Poder Concedente das Telecomunicações, por que a Anatel jamais propôs ao Poder Executivo que regulamentasse o Livro III da LGT e emitisse decretos instituindo o regulamento geral dos serviços de telecomunicações e o regulamento específico dos serviços públicos de comunicação de dados?

Taí... Esta sim, é uma boa pergunta para ser feita à Anatel. Ou até, se for o caso, convencer algum promotor do Ministério Público a mover ação civil ou penal pública com base nisso.

Pergunta 13: Em julho de 1998, quando arremataram em leilão o controle acionário das concessionárias regionais do STFC, a preços irrisórios e sem concorrência, os atuais controladores dessas empresas sabiam perfeitamente que, por força do art. 86 da LGT, elas deveriam explorar única e exclusivamente o STFC. O fato de a Anatel querer transformá-las em concessionárias multi-serviços, através de alterações ilegais na regulamentação, não poderia ser interpretado como uma manobra casuística para tentar "legitimar" todas as irregularidades que têm sido praticadas pelas empresas nos últimos anos com total anuência da agência e do Minicom?

Isto está mais no reino da política. E se eu for enveredar nesta seara provavelmente não consigo terminar este texto ainda neste mês :-)

Tereminando, enfim, creio que o único estribo sólido para montar neste "cavalo de batalha" é a questão das empresas separadas para exploração de cada concessão. O resto, bem, vc corre o risco de "pagar mico" nas audiências públicas.

[ ]'s

J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Anatel e as recentes "Consultas Públicas" (6) - José Smolka comenta as "13 Perguntas" de Rogério Gonçalves

BACKHAUL E PGMU (14) - Mais opiniões de José Smolka

BACKHAUL E PGMU (11) - Opiniões do nosso participante engenheiro José Smolka

----- Original Message -----
From: J. R. Smolka
To: WirelessBR
Sent: Tuesday, May 27, 2008 12:00 PM
Subject: [wireless.br] Sobre backhauls e etc.

Colegas da ComUnidade (ou seria ComDiversidade? :-) )

Tenho acompanhado as discussões sobre PGMU, PGO, back* (substitua o * pelo sufixo que quiser: haul, bone, plane, ...), fusão Oi/BRt, etc. etc., e algumas coisas me intrigam.

Em minha opinião, o marco regulatório atual é ruim, porque é fruto de uma visão ultrapassada: que a infra-estrutura e o serviço são coisas indissociáveis. Isto não se justifica mais, e persistir nisto só vai complicar a evolução. Portanto é necessário mexer, e muito, na LGT, no PGO, e todos os textos legais que definem o funcionamento do mercado de serviços de telecomunicações no Brasil, senão vamos ficar encalacrados. Os impasses que vivemos hoje são, IMHO, o reflexo desta dissociação entre modelo legal e realidade tecnológica/operacional/mercadológica.

Isto não quer dizer que eu seja partidário de rasgar a lei, e ir improvisando ao sabor das conveniências dos negócios. Enquanto a lei existe, é para ser cumprida, ponto! Esta é a essência do Estado de Direito, que é a base do Estado democrático. O que defendo, sim, é que esta lei é ruim, e não dá para remendar. É hora de passar o arado e começar de novo.

Para mim, um exemplo claro de como o estrito cumprimento da lei atual não resolve os problemas é a tese (tão cara ao Rogério Gonçalves) de que a investidura da Embratel (ou de qualquer outra empresa) como concessionária do serviço de troncos (RTT) resolva o impasse. Primeiro porque eu não consigo ver como a outorga do direito de transporte de média/longa distância a um único provedor vá melhorar a vida do cidadão. Pelo contrário, isto cria um monopólio, e nós já vimos este filme antes. E segundo, porque o real gargalo do problema não é o transporte de média/longa distância (que, aliás, a tecnologia já está tornando obsoleto como definição de "serviço"), mas a oferta de acesso em condição isonômica a todos os que queiram competir no mercado.

Para entender o que quero dizer com isso, precisamos olhar para trás e ver como eram construídas as redes de telefonia do século passado. Só existia um serviço: transporte de voz fim a fim entre dois assinantes, usando terminais especializados e dedicados unicamente a esta tarefa (a introdução dos modems para conexões dial-up é apenas um uso diferenciado deste mesmo serviço, não um serviço à parte). Para prestar este serviço as operadoras "lotearam" o mercado de acesso local e de interconexão de longa distância (intermunicipal/interestadual/internacional), tudo bem definido e padronizado pelas recomendações da ITU. O sistema Telebrás foi montado nestes princípios: as operadoras estaduais resolviam o acesso local e a interconexão intermunicipal, enquanto a interconexão interestadual e internacional era atribuição exclusiva da Embratel.

O acesso era feito pela instalação de uma malha de fios de cobre conectando as residências/empresas até a central telefônica mais próxima. Se ninguém lembra, os famigerados planos de expansão (que era a forma, naquela época, de alguém comprar um telefone novo) eram auto-financiamentos. O assinante pagava pelo investimento que a operadora faria para estender a malha de acesso até a sua casa e, se tudo corresse bem, em até dois anos você teria o seu telefone instalado. E sempre foi um "calo" a questão dos PEX vencidos: o assinante pagava por dois anos, mas o telefone não chegava...

A posse desta malha dá à operadora local um poder enorme sobre o usuário, porque ela (ainda) é o principal meio para que ele possa usufruir de qualquer serviço de telecomunicações. todo este modelo ia bem até meados da década de 80 do século passado. O plano, na época, era transformar a rede telefônica em uma rede multi-serviços no modelo B-ISDN definido pela ITU (as especificações do SDH e do ATM nasceram para suportar isto, lembram?). O que deu errado neste plano foi o boom da Internet comercial na década de 90. De lá para cá toda a idéia sobre convergência de serviços mudou para transporte IP, e os efeitos disto são uma das raízes desta dor de cabeça regulatória que vivemos. Nem as operadoras, nem os legisladores, nem o pessoal do Minicom e da Anatel sabem como definir direito como deve ser o marco regulatório neste cenário.

As famosas "21 perguntas" colocam uma data fatídica: 2025, quando expiram as atuais concessões do STFC. Alguém já parou para pensar como será a infra-estrutura de uma operadora de telecomunicações a esta altura? Não vou nem tão longe. Por volta de 2015 as redes de transporte (os backbones ou backhauls, como queiram) já deverão estar todos convertidos para um modelo tecnológico all-IP. Uma boa parte dos usuários (pelo menos nas partes mais fashion do mercado) acessarão os serviços a partir de terminais multi-serviços, e negociarão os termos de cada sessão usando sinalização SIP, mediados por IMS (se os wet dreams atuais das operadoras e fornecedores de equipamentos de realizarem, o que ainda está para ser provado). A interconexão destes terminais com o legacy de terminais convencionais ainda vai precisar de centrais telefônicas, mas elas já são, e serão cada vez mais, diferentes das centrais clássicas. Primeiro porque uma "central" será uma federação de media gateways (MG) distribuídas, controladas por um media gateway controller (MGC) centralizado. Entre os MGCs o estabelecimento de sessões até poderá (ainda) ser negociado usando os protocolos da família SS7 (embora existam alternativas, como o bearer-independent call-control - BICC), mas o transporte dos pacotes SS7 será feito sobre a rede IP via SIGTRAN, nativo nos MGCs ou, no máximo, intermediados por gateways SIGTRAN. As sessões de dados MG-MG, por serem IP, não necessitarão mais da hierarquia de centrais trânsito. o roteamento dos pacotes fim a fim fica por conta da rede IP subjacente, então não há mais razão para diferenciar o tráfego local do tráfego de longa distância. E, como a banda para a interconexão IP normalmente é negociada no atacado entre as operadoras, o natural é que o serviço que hoje chamamos de longa distância (LDN e LDI) perca totalmente o sentido, e voz seja oferecida em flat rate independente da distância.

A esta altura, não existirá mais a distinção entre o que é STFC e o que é comunicação de dados, porque tudo será comunicação de dados (na verdade esta distinção já é difícil hoje). A única pedra neste cenário é que, enquanto o acesso local estiver monopolizado, não haverá real competição e o benefício tarifário para os usuários será bem menor (se houver). Então, esqueçam o backhaul, porque o que interessa realmente, a curto/médio prazo (porque a longo prazo estaremos todos mortos :-) ), é o unbundling dos meios de acesso aos serviços.

Imaginem o seguinte: que seja possível definir regras claras para que uma operadora que queira "invadir a praia" possa alugar os meios de acesso da operadora já estabelecida localmente (algo no estilo dos contratos EILD usados na interconexão de redes). Ainda mais, que seja possível negociar o uso de redes de acesso diferenciadas da malha de cobre convencional (ex.: a rede de TV a cabo, os acessos wireless das operadoras celulares, as redes metropolitanas Wi-Fi e/ou WiMax, os provedores independentes de acesso existentes na região, etc.) para o provimento genérico de serviços de telecomunicação. Creio que, neste cenário, haverão operadoras que preferirão investir em possuir a infra-estrutura de acesso e transporte e também prover os serviços. E haverão aquelas que preferirão investir apenas no provimento do serviço, e alugar os meios de acesso/transporte de provedores especializados em infra-estrutura (algo meio com cara de MVNO, mas não necessariamente móvel).

Que tal isto como ponto de partida para discussão de um futuro marco regulatório?

[ ]'s
J,.R. Smolka

Ajuda sobre IMS (2) - IP Multimedia Subsystem - Mensagem de José Smolka

----- Original Message -----
From: J. R. Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Wednesday, May 07, 2008 11:33 AM
Subject: Re: [wireless.br] Fw: Ajuda sobre redes IMS...

Boa Noite! Sou aluno do curso de Ciência da Computação da Universidade do Triângulo (UNITRI), estou no último período do curso e o meu tema de monografia é sobre as redes IMS ( comparação do IMS em diferentes tecnologia de acesso: DLS, 3G/UMTS WIMAX)... Estou precsinado muito da sua ajuda para que posso concluir esse trabalho, com algumas informações, como: gráficos, como é o serviço, se vai contiunar por muito tempo, se tem alguma outra tecnologia para substituir, QoS, Segurança, quantidade de aplicativos, base instalada, tráfego, confiabilidade, custos,... Tudo sobre o ims em diferentes tecnologias.
Não estou achando nada, nenhum artigo quem contenha esses tipos de informação..
Peso humildemente a sua ajuda para que esse trabalho seja realizado.

Acho que todo mundo já notou que perguntas deste tipo atiçam a minha vontade de "dar pitacos" :-)

Primeiro: acho que o Adriano escolheu um bom tema para a sua monografia. O IMS (IP multimedia subsystem) é uma - entre tantas - das coisas mal compreendidas que surgem nas redes de telecomunicações no processo de conversão para um ambiente all-IP. Segundo: antes de entrar muito fundo no desenvolvimento do assunto da monografia, é bom compreender bem quais as motivações que levaram à existência de algo como o IMS.

Para entender bem meu weltanschauung a respeito deste assunto (não entendeu? Tente http://pt.wikipedia.org/wiki/Weltanschauung), convém dar uma olhada no primeiro artigo da série VoIP (http://www.wirelessbrasil.org/wirelessbr/colaboradores/jose_smolka/voip/serie_voip_01.html), que escrevi cerca de dois anos atrás, quando o Hélio lançou a campanha "maio sobre IP". Na verdade ele vem me cutucando para retomar o assunto. Confesso que estou tentado, mas não vou fazer promessas agora :-)

Mas, vamos ao assunto... O IMS tem alguns aspectos do seu funcionamento que tem a ver com o tipo (ou tipos) de rede de acesso que o usuário está usando (ou tem possibilidade de se conectar), mas este não é o motivo principal para a sua existência. Ele é, acima de tudo, a resposta técnica que o 3GPP (3rd Generation Partnership Project) encontrou para compatibilizar o modelo de negócios tradicional de telecom com a evolução das redes para um modelo tecnológico all-IP - que convencionou-se chamar de NGN (next-generation network). Este modelo, que fica completo no release 8 das especificações do 3GPP, é, em princípio, agnóstico para os vários tipos de rede de acesso utilizados (HSPA, LTE, WiMAX, xDSL, cable modem, etc.).

Porque isto foi necessário? Porque o modo como um usuário interage com a rede para ter acesso a um serviço (aplicação) é fundamentamente diferente nos casos telecom e Internet.

Em redes telecom, toda vez que um usuário solicita acesso a um serviço ele deve passar, primeiro, por um admission control. Em redes IP (estilo Internet), o estilo é baseado no end-to-end principle: o usuário negocia as condições de uso do serviço diretamente com o provedor (paradigma client-server).

Se as NGNs fossem arquitetadas em torno do end-to-end principle, as operadoras veriam toda sua infra-estrutura de rede (acesso, backhaul e backbone) reduzida ao papel de dumb pipes, ou - no máximo - idiot savant pipes (signigficado em http://wordnet.princeton.edu/perl/webwn?s=idiot%20savant). E todo o valor percebido pelo usuário estaria nas mãos da Google e assemelhados. Este cenário é o fim da picada para as operadoras de telecom.

Qual a alternativa, então? Criar um "ecossistema" que ofereça aos desenvolvedores a possibilidade de facilmente integrar suas aplicações para delivery através das redes de telecom, especialmente naqueles aspectos que são peculiares a elas (ex.: SMS). Neste modelo a operadora ainda oferece ao desenvolvedor o valor adicionado de desobrigá-lo de manter toda a estrutura de comercialização (especialmente o billing) da sua aplicação, porque a operadora faz isto em nome dele - por uma modesta quantia, claro :-)

Outro fator interessante em criar esta intermediação do acesso às aplicações é manter, nas mãos da operadora, as informações detalhadas sobre os hábitos de navegação dos usuários. Porque? Ora, o mercado de publicidade vai mudar muito no futuro próximo, e estes dados são críticos (e muito valiosos) para permitir a montagem de campanhas publicitárias mais focadas e personalizadas.

Só que a criação deste "ecossistema" tem de andar rápido, senão perde o bonde da história. E isto depende de uma outra criatura, ainda mais esotérica que o IMS, que atende pela sigla SDP (service delivery platform). Mas isto é assunto para outro post.

[ ]'s
J. R. Smolka

Serviços de telecomunicações x Infra-estrutura de redes de telecomunicações

----- Original Message -----
From: Rogerio Gonçalves
To: wirelessbr@yahoogrupos.com.br
Sent: Saturday, May 03, 2008 2:29 AM
Subject: [wireless.br] Re: Serviços de telecomunicações x Infra-estrutura de redes de telecomunicações
Oi Smolka,

Muito boas as suas observações, principalmente por servirem para aprofundar e enriquecer os nossos papos.

Você tem razão. O amigo aqui deu uma derrapada feia ao manter o pé no passado quando utilizou o termo "rede ATM" para referenciar os
circuitos que fazem a interligação entre as centrais telefônicas.

Pior, é que se o estudo tivesse utilizado como exemplo as redes SDH, de repente as coisas poderiam ficar mais claras pois, como a facilidade de extrair e inserir enlaces do SDH o tornou o padrão ideal para as redes de transporte integrado (RTT), bastaria demonstrar que, embora o tráfego IP possa circular junto com o tráfego do STFC nas redes SDH, isso não significa de forma alguma que as concessionárias de telefonia possam se tornar fornecedoras de outros enlaces senão aqueles destinados às comutações fim a fim do STFC (com as limitações da plataforma SSC-7) já que, por força dos arts. 85, 86 e 207 da LGT, o fornecimento de infra-estrutura, inerente
à exploração industrial do serviço de rede de transporte de telecomunicações (serviço de troncos), deve ser objeto de concessão específica.

Pena que a Flávia já mandou o estudo para a juíza. De qualquer forma, assim que for necessário, nós vamos utilizar essa tua dica.
Valeu mesmo o teu post.
Um abraço
Rogério

-------------------------

---- Original Message -----
From: J. R. Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Friday, May 02, 2008 4:30 PM
Subject: [wireless.br] Serviços de telecomunicações x Infra-estrutura de redes de telecomunicações
Caros colegas,

Não sei se mais ninguém reparou, mas a definição sobre a não-superposição da infra-estrutura de suporte aos serviços de telefonia fixa (STFC) e acesso de banda larga à Internet (na falta de uma sigla vou chamar de BIA - broadband Internet access), que o Rogério publicou em um post aqui na lista, não está totalmente correta.

No que diz respeito à rede de acesso xDSL está tudo bem. Os sinais do STFC e do BIA compartilham a last mile até o DSLAM, onde são separados. O sinal STFC é encaminhado para a central telefônica (que usa o protocolo SS7 para negociar com as outras centrais o estabelecimento do circuito telefônico fim a fim) e o sinal BIA é encaminhado a um roteador IP.

Mas, a partir daí, as coisas não são bem como ele disse. A interligação entre as centrais telefônicas (que o Rogério generalizou como "redes ATM" - embora o ATM seja apenas uma das formas de fazer isto) e os roteadores IP também usam meios compartilhados. Estes meios já foram enlaces PDH (os tradicionais canais E1 ou E3), hoje já foram praticamente todos migrados para MUXes SDH, e estão em processo de substituição (pelo menos no nível metropolitano) por enlaces "carrier-class" Ethernet.

A presença de switches ATM entre as centrais telefônicas é opcional. Até onde sei, as operadoras de telefonia fixa colocaram isto nas suas redes no tempo em que se achava que a NGN seria nos moldes B-ISDN. Mas, mesmo que as switches ATM existam, elas são interconectadas pela malha SDH. E elas podem, sim (embora eu não veja vantagem nisso), acomodar circuitos virtuais separados para a interconexão das centrais STFC e para a interconexão dos DSLAMs e roteadores IP do BIA.

Então, a verdadeira estrutura de backhaul (e também backbone) neste caso é a malha de transmissão SDH (ou o que venha a substituí-la), e ela é compartilhada pelo STFC, pelo BIA e por outros serviços (ex.: serviços de circuitos de dados ponto a ponto, redes públicas de pacotes - X.25 ou Frame-Relay, etc.).

[ ]'s
J. R. Smolka

Ajuda: RENPAC X.25

----- Original Message -----
From: J. R. Smolka
To: Celld-group@yahoogrupos.com.br
Sent: Monday, April 14, 2008 9:27 AM
Subject: RE: [Celld-group] Ajuda: RENPAC X.25

At 11:25 11/4/2008, you wrote:
Smolka,
Por favor me corrija se estiver errado, mas seja lá qual for a solução que seja adotada do lado da rede do Tadashi, terá que também ser adotada do lado do cliente dele, não é?
Por exemplo, se encapsulamos IP em X.25 de um lado, o outro lado terá desencapsular (e vice-versa).
Se no PVC de um lado colocamos um GW, do outro deve haver um GW similar para poder ler o payload do quadro X.25 e jogar para a LAN.
Portanto talvez a grande pergunta é: o que o cliente do Tadashi já tem/usa do lado de lá?
Pelo que ele diz o cliente dele opera já com X.25, portanto ele já tem um GW ou um Roteador...
Não seria o caso do Tadashi seguir a mesma solução que o cliente já usa?
O que vc acha?
Abs,
Rodrigo.

Rodrigo,
Em um ponto básico vc está certo: as duas partes tem que usar o mesmo modo de comunicação entre suas aplicações para que tudo funcione a contento. Só que vc parte da suposição que existe uma LAN e TCP/IP do outro lado. O que não parece ser o caso.

O problema do Tadashi, se é que entendi direito, é estabelecer comunicação entre uma aplicação dele e outra aplicação, que roda em uma máquina de uma instituição financeira (banco, cartão de crédito, seguradora, whatever...). Só que a tal IF - o que não é incomum - estruturou a aplicação dela em cima de X.25 nativo, com primitivas proprietárias no protocolo de camada 7 (aplicação), e diz a quam quiser comunicar-se com ela que existem dois jeitos de fazer isto: o jeito dela e o jeito errado. Tenho a forte suspeita que seja assim, porque já passei por problema parecido alguns anos atrás. Minha única surpresa, neste caso, é que nada tenha mudado de lá para cá.

Isto faz sentido hoje em dia? Acho que não. Conexões IP sobre frame-relay dão o mesmo efeito, são mais fáceis de programar - tanto para a IF quanto para seus parceiros, são tão seguras quanto o X.25, e são suportadas nos ambientes mainframe IBM que a maioria das IF ainda usa. Mas uma boa parte das IFs ainda age desta maneira. Sei lá... Talvez eles não tenham ainda dominado as APIs entre NCP, CICS, VTAM e TCP/IP no z/OS, ou quem sabia fazer isso já se aposentou e não treinaram mão-de-obra substituta. :-D Seja lá qual for o motivo, o problema existe de fato.

É por isso que eu disse no meu post sobre as duas formas de solução: programação nativa X.25 (horrível) ou colocar um gateway X.25/IP entre a aplicação do Tadashi e a aplicação da IF. Neste segundo caso, a aplicação dele precisa emular as primitivas do protocolo de aplicação da IF usando a API de sockets (piece of cake), e o gateway tem de ser programado para "trasladar" o payload dos pacotes TCP/IP ou UDP/IP vindos da aplicação dele para os pacotes X.25 (no formato esperado pela IF), e vice-versa.

[ ]'s
J. R. Smolka

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto: