Arquivo

Posts Tagged ‘as’

Soluções simples para melhorar a Internet

Algumas coisas básicas, me incomodam como administrador de sistemas associados à Internet. E nada posso fazer, pois depende de atitudes de terceiros. A maior parte delas, depende dos RIRs ou do nosso NIR. Abaixo, algumas sugestões que, na medida do possível e por sugestões de colaboradores, serão incrementadas. Nenhuma delas agride o espírito da Internet.

  1. O reverso deve ser obrigatório. Quem não tiver o reverso deve ser punido.
  2. O Registro.br deve permitir a renúncia de blocos IPs, pelos ID Técnicos. Essa facilidade é pré-requisito para a proposta do item anterior. Atualmente, os responsáveis técnicos por blocos de IPs de terceiros, não conseguem se livrar deles, a partir do momento que não são mais responsáveis.
  3. O DNSSEC deve ser obrigatório para todos as DPNs. Quem não fizer isso, deverá ser punido. Quem não atualizar as chaves na época do vencimento, também será punido. O Registro.br deveria indicar nos avisos em que houver quebra de respostas no DNSSEC, QUAIS os servidores de DNS envolvidos, assim como ele fazia quando não havia respostas de servidores de DNS. Esse problema não é grave para quem possui, somente dois servidores de DNS, mas é complicado para quem possui o máximo permitido (5). Se a identificação do servidor específico de DNS não for possível, por alguma razão, então que informe aos administradores que eles devem cuidar dessa questão, monitorando cada um deles. O estado do domínio com DNSSEC implementado, também poderia aparecer por lá, o que nos ajudaria bastante.
  4. ASN deve ser liberado, livremente. Para quem provar que tem uma rede. As restrições somente para a liberação de blocos IPv4. Blocos IPv6 deveriam ser liberados para os ASs, mesmo sem IPv4. Isso anteciparia as implementações de IPv6. Muitos ASs com IPv6 estimulariam os fornecedores a implementar tal funcionalidade, já que o mercado estaria disponível. Por outro lado, o LACNIC deveria rever os preços relativos ao IPv6, que pretende cobrar no futuro.
  5. Instalação de uma base do IRR espelhada na RADB. De graça e com suporte a IPv6! E o Nic.br (ou LACNIC) pode criar, à semelhança do RIPE NCC, orientações de uso, inclusive das ferramentas disponíveis (IRRTools, p. ex.).
  6. Propostas para o tratamento das punições. Sempre haverá avisos, antecedendo a punição. As punições, após os avisos, não devem ser brandas. Os critérios de punição deveriam considerar a reincidência. Quem possui um ID Técnico, pressupõe-se que seja um administrador, conhecedor dos fundamentos da Internet. Os avisos e punições, podem se estender aos outros IDs.
Anúncios

Internet Routing Register (IRR)

Introdução

Alguns de meus amigos que trabalham com infraestrutura da Internet e administradores de redes, em particular, usam com uma certa frequência, o CIDR-Report. Pessoalmente, mantenho-o, permanentemente, no meu desktop. O CIDR-Report gerou um equívoco para estes amigos e para mim, também. O problema é que quando se pesquisava o CIDR-Report para qualquer ASN que tenha sido destinado pelo Nic.br (após a transferência das funções pelo LACNIC), aparecia a mensagem no cabeçalho “–No AS Description–“. Todos diziam que faltava o registro do AS no RADB, a principal base de dados do Internet Routing Register (IRR). E eu, repetia isso para outros. Então, passei a procurar uma maneira de registrar os ASs que administro no RADB. O primeiro impasse, nesta tentativa, foi o fato do registro no RADB custar US$495.00/ano. Uma pergunta do !3runo, na GTER, sobre o ALTDB, deu a pista para o registro do AS no RADB, em bases que eram espelhadas. Minhas tentativas de registro no ALTDB foram de pura frustação. Mas, mesmo percebendo que muitos já tinham registrado no ALTDB acabei usando os serviços do pessoal da Infraestrutura.IP. Em menos de um dia, os ASs estavam na RADB. Sem a anualidade! Recentemente (agosto/2009) a Pegasus implementou a primeira base de dados IRR no Brasil: http://irr.redepegasus.net.br.

Logo fui no CIDR-Report e percebi que, o No AS description, continuava lá. Esperei alguns dias e nada. Logo percebi que não era a inexistência no RADB que gerava a mensagem. Então fiz o que deveria ter feito desde o início: entender o IRR. A conclusão foi de que é uma peça muito importante para a consistência de rotas publicadas pelos ASs, em particular, para detetar o MOAS (acrônimo de Multiple Origin Autonomous Systems), automaticamente. Os conflitos de MOAS acontecem pelo simples problema de que um AS pode “injetar” qualquer prefixo, por configuração correta, incorreta ou maliciosamente*. A história do No AS description deixarei para o final.

O que é o IRR e para que serve?

Existem inúmeras definições na literatura que pesquisei. Uma delas diz que IRR é um conjunto de bases de dados que permitem ao BGP, documentar suas rotas e políticas de roteamento, com o objetivo de dar consistência às configurações de um roteador. Dizia ainda que o BGP fazia isto “conversando” em uma linguagem chamada RPSL. É a linguagem comum dos whois, jwhois, etc. E a mesma que motivou a construção de uma autômata de pilha em artigo que pode ser visto aqui.

Nada de errado com a definição acima. Mas não era muito precisa. Cheguei então, à página oficial do IRR, em [5]. Há várias informações importantes, incluindo as bases de dados ligadas ao RADB. A relação das bases de dados é quase uma piada, mostrando que alguma coisa não estava sendo levada a sério. A última vez que estive por lá foi no mes de março/2009.

Mais á frente, percebi que muitos RIRs possuem ofertas de bases de IRR, espelhadas no RADB, para os usuários de sua região, mas não vi nada em relação ao LACNIC, exceto propostas, inclusive do Nic.br. Aqui, uma notícia do LACNIC a respeito. O APINIC [6] tem o APIRR e é capitaneado pelo Japão, também com um serviço IRR para seus usuários, como pode ser visto em [3].

Europa (RIPE) e Japão (membro do RIPE), levaram a sério o IRR. E, principalmente no Japão, estão os trabalhos mais consistentes sobre IRR. Em um dos trabalhos que li, [7], uma definição completa sobre o que é, e para que serve o IRR reproduzo, no original: “The Internet Routing Registry (IRR) … is a large distributed repository of information, containing the routing policies of many of the networks that compose the Internet. The IRR was born about ten years ago with the main purpose to promote stability, consistency, and security of the global Internet routing. It consists of several registries that are maintained on a voluntary basis. The routing policies are expressed in the Routing Policy Specification Language (RPSL) … The IRR can be used by operators to look up peering agreements, to study optimal policies, and to (possibly automatically) configure routers.”

Logo a seguir, o trabalho ressalta: “There is a wide discussion about the current role of the IRR … Some people consider it outdated and almost useless. Others have put in evidence its importance to understand the Internet routing and that it contains unique and significant information. Anyway, it is undeniable that the IRR keeps on being fed by many operators, that useful tools have been developed to deal with the IRR (see, e.g., IRRToolSet [3]), …”.

Queria chegar, na citação acima, no IRRToolSet. Acabei implementando a IRRToolSet em FreeBSD e tem realmente algumas ferramentas interessantes. Por exemplo a peval, com a qual descobri que um punhado de gente boa publica blocos /24. Aos montões! Outra que seria interessante, é a prtraceroute, que inclui o ASN e a política de roteamento, em cada etapa do traceroute. Sobre a instalação do IRRToolSet, veja aqui. Há uma lista pouco movimentada, mas interessante, que pode ser assinada aqui.

A história do –No AS Description–, no CIDR-Report

Eu não percebi, de imediato, que a mensagem, tecnicamente incômoda, do CIDR-Report somente ocorria para os ASs distribuídos pelo Nic.br, a partir da mudança do LACNIC, em meados de 2007. Escrevi ao LACNIC a respeito do problema e a resposta que obtive não foi muito clara e resolvi escrever para o Geoff Huston, responsável pelo CIDR-Report. Ele me respondeu de pronto, dizendo que o problema estava relacionado com o jwhois, que o LACNIC não estava autorizando a consulta em suas bases de whois. Três ou quatro mensagens se seguiram para o LACNIC, sendo que na penúltima, finalmente, percebi que o problema eram somente os atuais ASs liberados pelo Nic.br. Por fim, o LACNIC em uma das respostas informou que o problema do proxy seria resolvido nos primeiros 4 meses de 2010, já que o CIDR-Report não era tão importante assim, para os administradores de sistemas.

Mais recentemente, ando desconfiado que outros além do CIDR-Report estão com o mesmo problema. Por exemplo, o Google Analytics. A grande maioria dos acessos de rede (93%), são registrados como comite gestor da internet no brasil.

Últimas notícias sobre IRRToolSet

Há cerca de dois ou três dias atrás (a partir de hoje, 15/05/2009) tem havido um debate interessante sobre as ferramentas do IRRToolSet. Em particular, val a pena ver aqui, a descrição que Nick Hilliard, faz sobre cada uma delas. Para frente e para trás, na sequência dessa mensagem o debate é interessante.

* Usar a base do IRR para detetar conflitos de MOAS, não é a única técnica disponível. Há uma corrente recomendando o bgp.in.addr.arpa.. Esse grupo, provavelmente está preocupado com a falta de confiabilidade das informações armazenadas na RADB. Como elas são atualizadas pelos próprios responsáveis pelos ASs, observa-se um certo descuido. Entretanto, nota-se que o pessoal que faz peering ou pretende fazer, está cuidando de forma correta das suas informações lá armazenadas.

Referências


[1] Siganos G., Faloutsos, M., Analazing BGP policies: methodology and tool, INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, Vol. 3 (2004), pp. 1640-1651 vol.3.
[2] Alaettinoglu C. et alii, Routing Policy Specification Language (RPSL), The Internet Society, RFC2622, 1999.
[3] JPNIC IRR (JPIRR) Operation Policies and User Guideline, Japan Network Information Center, IRR-Planning Team, July 2003.
[4] Nagahashi, K., Esaki, H. & Murai, J., An integrity check for the conflit Origin AS Prefixes in the inter-domain routing, IEICE Trans. Commun., Vol. E86-B, no. 2, February 2003.
[5] Internet Routing Register
[6] APIRR resource guide
[7] Battista, G. di, Refice, T., Rimondini, M., How to Extract BGP Peering Information from the Internet Routing Registry

Últimas atualizações:
29/04/2009 09:00

Sistemas Autônomos, Empresas Autônomas

Últimas atualizações:
22/04/2009 – 08:17
14/12/2008 – 08:17
10/12/2008 – 16:39
26/03/2006 – 11:20
18/03/2006 – 19:15
16/03/2006 – 07:30
  1. Introdução

    O micro, pequeno e médio provedor brasileiro de serviços agregados da Internet, seja ele licenciado do SCM ou não, está sendo afetado duramente pela idiossincrasia do modelo brasileiro de telecomunicações. Sem representatividade, o provedor brasileiro fica à mercê das regras impostas pelas concessionárias do serviço público e, quase inerte na sua preocupação de sobrevivência, deixa de lado questões importantes que tornam difusas as fronteiras entre as velhas e as novas tecnologias.

    À distância e, curiosamente, pouco lembrado pelos provedores está o Comitê Gestor da Internet brasileira (CGI). A permanente presença das instituições de ensino e pesquisa brasileiras no CGI alentam nossas preocupações com o futuro em relação à governança da Internet Brasileira.

    As principais razões do alento e motivações do presente trabalho são:

    1. Atuação do Comitê Gestor. Disponibilizando o PTTMetro9 que, em linhas gerais, propõe aumento da confiabilidade e disponibilidade da Internet, diminui os custos de interconexão e, mais importante, diminui o poder das grandes concessionárias.
    2. Ausência de conhecimento técnico em relação às facilidades e recursos disponíveis.
    3. Disponibilidade de números IP´s, tanto IPv4 como IPv6.
    4. Perspectiva de mudança de paradigma tecnológico (IPv4 -> IPv6).
    5. Política: há um profundo desconhecimento das instituições sobre o que os provedores fazem neste país, sob o ponto de vista social. E, consequentemente, a aparente ausência de lideres e instituições com ampla e consistente visão de nossos problemas.
    6. Meios alternativos de transmissão e transporte de dados, gerando capilaridade em grande parte do território brasileiro.
    7. Necessidade de nivelar e ampliar o debate em torno de alternativas de negócios para os provedores de pequeno e médio porte.

    Talvez em (g) resida a principal motivação desse artigo. Não somente a legislação é confusa mas, insaciavelmente relegada ao cenário da impunidade. A falta de equilíbrio e precisão nos debates não nos está permitindo levar ao conhecimento de instituições como a Anatel, o fato de que os tempos mudaram. Somente para citar um exemplo, mas extremamente agressivo para os pequenos e médios provedores, está a questão da fixação de preços das telecomunicações através do que se denomina “degraus tarifários”. Esse critério é demasiadamente antigo e não reflete a realidade. Os recursos de interconexões se transformaram com as novas técnicas e tecnologias, as facilidades para se atingir as localidades estão alterados e, portanto, devem ser revistos. Ideias brilhantes e representativas dos interesses do país, como da Aneel, que estabeleceu a livre negociação no mercado de energia elétrica poderiam ser transpostos para a área de telecomunicações.

  2. Fundamentos históricos e definições

    Há certas dificuldades para introduzir o conceito da Internet atual. A procura pela descentralização da oferta de acesso à Internet gerou inúmeras alternativas, uma imensidão de técnicas e, consequentemente, uma variedade incomum de termos para classificar tais técnicas e, particularmente, para identificar os participantes que habitam o cenário da Internet global. Fica um pouco mais complicado quando se expõe o mosaico mundial, onde cada país adota caracterizações próprias.

    O regionalismo é um aspecto interessante. Aqui no Brasil, o modelo escolhido (1995), que deu origem à privatização (1996) foi distorcido ao longo do tempo. Em particular, na concepção da privatização, uma vez que, efetivamente, houve concessão. E, associada às distorções, uma série de leis, decretos, portarias e outros insumos burocráticos deturparam os princípios fundamentais estabelecidos na Lei Geral das Comunicações e legislação acessória6.

    Mas distorções e interesses financeiros envolvidos no cenário das telecomunicações de um país parecem estar proliferados em diversas regiões do mundo. Na Austrália, por exemplo, o chamado Grupo dos Quatro, recebe um nome pejorativo de Gang of Four (GOF), para designar os acordos entre a Telstra, Optus, AAPT e MCI. Apesar de três competidores da Gangue das Quatro (Comindico, Agile Communications e Primus Telecom) terem mais tráfego e rede maior do que duas das quatro (AAPT e MCI), não conseguiam acordos com as Quatro. A evidente demonstração de tentativa, de formação de cartel fez com que a Australian Competition and Consumer Commission (ACCC), criada em 1995, já em 1998, exigisse uma mudança nos acordos de “peering” feitos pela Gangue das Quatro. Detalhes dessa história, podem ser encontrados em 13

  3. Tráfego, “peering”, trânsito e transporte

    Há uma certa confusão na definição dos termos acima. Sabemos que a Internet (ao contrário de internet, como identifica a mídia) é uma rede de redes de computadores, usando o protocolo TCP/IP. A figura abaixo, mostra a Internet, somente com três redes, para simplificarmos as definições:

    tresredes1

    Figura 1. Peering: acordos bilaterais

    A figura acima mosta interconexões entre as redes A e B, e entre as redes B e C. Estamos supondo que tais redes (A, B e C), pertencem à Internet e, também, nos abstraindo do tamanho de cada uma. Podem possuir um tamanho continental ou ser redes de um só computador, por exemplo. Tudo o que passa entre uma rede e outra, através da interconexão ou interconexões, é tráfego (ou seja, tráfego de pacotes TCP/IP). Se as redes A e B possuem interesses mútuos de que seus clientes troquem tráfego entre si, geralmente elas fazem um acordo sem que haja troca financeira. Isso é o que se chama de peering. O mesmo acontece entre as redes B e C, onde interesses mútuos podem criar um peering, entre elas. Mas clientes da rede A, estão impedidos de trocar tráfego com clientes da rede C, pois não há uma interconexão diretra entre elas ou, em outras palavras, não é possível um acordo ou arranjo de peering entre as redes A e C. Para que a troca de tráfego entre A e C possa ocorrer, existem duas maneiras: (a) A rede A faz um acordo de trânsito que permitirá o tráfego passar pela rede B e atingir a rede C ou, (b) as redes A e C estabelecem uma conexão física e fazem um acordo de peering. O tráfego, de A, que passa por B, para atingir C, geralmente é pago, pois está usando recursos físicos de B.

    Imaginando que as três redes da figura acima fossem os únicos membros da Internet, provavelmente, cada “dono” de uma das redes, seria um Provedor de Serviços de Internet (PSI). Seus clientes ou usuários estariam comprando trânsito, para trafegarem na Internet.

    Há algumas ideias que tornam o problema das interconexões entre redes um pouco mais complexos. Vamos supor, que a Rede A seja a CTBC, que a Rede B seja a Telefônica. Imaginemos que a CTBC tenha interesse de fazer uma conexão com a Telefônica e, vice-versa. Em outras palavras, desejam estabelecer um peering para agregar valor às suas ofertas de acesso à Internet, aos seus clientes (ou usuários). A questão que aparece é: de que maneira será feita a interconexão entre elas, para estabelecer o peering? Existem inúmeras alternativas, que devem ser passadas pelo crivo do menor custo. Vamos imaginar, ainda, que depois de uma análise adequada, elas cheguem à conclusão de que a melhor alternativa é usar a rede da Eletronet, digamos, de Uberlândia até São Paulo. Se isso acontece, então as duas (CTBC e Telefônica), ou uma delas, contrata tráfego da Eletronet, para fazer o ponto-a-ponto. Este tráfego é denominado transporte. Em outras palavras, a Eletronet foi contratada para transportar os pacotes TCP/IP entre Uberlândia e São Paulo e, vice-versa, para que o peering entre a CTBC e a Telefônica seja estabelecido, portanto.

    Nesse cenário, das três redes podemos imaginar que a Rede C, está em uma posição desconfortável em relação ao peering com a Rede A (e o inverso, também!).

    No contexto do que foi dito acima, vale lembrar que a Eletronet é um Provedor de Serviço de Backbone (PSB).

  4. PSI e PTTs

    Vale lembrar que PSI (ou, ISP, do inglês) possui o significado comum expresso na literatura em geral, sem as limitações da concepção brasileira. PSI é uma empresa ou organização que oferece acesso à Internet e disponibiliza, também, valores agregados a esse acesso. Muitos PSIs, em qualquer parte do mundo são as concessionárias ou empresas de telefonia (ou licenciadas do STFC, no Brasil). Mas, muitos outros PSIs são, unicamente, provedores de acesso à Internet e de seus valores agregados. Os serviços prestados pelos PSIs incluem, além da Internet, registro de nomes (agora no Brasil, em expansão), hospedagem de servidores, acesso discado, colocação, redes sem fio e muitos outros. Os provedores brasileiros, espalhados por todo o canto de nosso país, são PSIs. Alguns PSIs, tem se aventurados a fornecer serviços de backbone, relativamente restritos. Outros, contratando grandes servidores de backbone (como a Eletronet, por exemplo), com sucesso atendem a transporte de longa distância e, também, trânsito.

    No Brasil há um comportamento diferenciado da grande maioria dos provedores que não são concessionários de telefonia pública e que não se encaixam na categoria de fornecedores de “backbone”, hospedagem e co-locação, em relação aos provedores do resto do mundo. Eles são sensivelmente dependentes das concessionárias do STFC. Provavelmente, por razões de natureza técnica e, em alguns casos, por puro desconhecimento dos recursos e técnicas disponíveis.

    Vamos retornar à figura das três redes e lembrar das dificuldades para o estabelecimento do peering. Em particular, se pensarmos na Rede C e os interesses mútuos com a Rede A. Um dos recursos disponíveis para resolver problemas dessa natureza, é o chamado Ponto de Troca de Tráfego (PTT), que poderia ser ilustrado na figura abaixo:

    tresredesptt

    Figura 2. PTT: acordos multilaterais

    No Brasil, o NIC.br entre suas atividades está “a promoção da infra-estrutura para a interconexão direta entre as redes que compõem a Internet Brasileira, através do PTT.br”. Quando um PTT é estabelecido em uma região metropolitana, ele recebe o nome de PTTMetro. A descrição técnica8 do PTTMetro9 explica as regras propostas e no vasto material do PTT-MG7 podemos acompanhar o nascimento de um PTT sob a coordenação do NIC.br, através de suas atas. Nelas é possível ver os atuais interessados em participar. Chama atenção a presença de algumas concessionárias, sobre cuja participação falaremos já. Há uma dificuldade, entretanto o fato de que os PTT’s brasileiros estarem projetados somente para as principais capitais. Portanto, o desafio, ao se desejar estabelecer no ambiente de um PTT é chegar até lá. No exemplo de Minas Gerais (em Belo Horizonte), o PTT-MG não é somente um local físico. Ele é projetado para disponibilizar vários locais físicos, cada um podendo ser um PTT, interconectados via uma rede de fibra ótica de alta capacidade e, pelo que indica, usando Ethernet. No documento técnico do MGIX (PTT-MG) é claro o fato de qualquer empresa poder se estabelecer como PTT. O uso do protocolo Ethernet torna mais barato a troca de tráfego, inclusive trânsito.

    Umas das principais perguntas que surge é: qual a rzazão pela qual o NIC.br está provocando a criação dos PTTMetro em todas as regiões metropolitanas brasileiras? Uma resposta imediata é o fato econômico envolvido, que é possível concluir das descrições acima. Uma outra é observando a presença das concessionárias do STFC no MGIX e perguntando como poderia ser o relacionamento com tais membros que pertencem a um grupo de PSIs diferenciados. Elas pertencem ao grupo de PSIs que possuem um grande volume de tráfego e são quase provedores de backbone. Estes PSIs trocam tráfegos entre si, geralmente, em acordos de peering, sem transação financeira. Mas tarifam a troca de tráfego entre os pequenos ISP’s (aqueles com pequeno volume de tráfego). Nos EEUU, os ISP´s classificados como Tier 1 são conhecidos, informalmente, como membros do clube SFI, acrônimo de “Settlement-Free Interconnection”. Até 2005, faziam parte deste seleto clube: Qwest, MCI, Sprint Nextel Corporation, AOL, Verio/NTT, Level 3, Global Crossing, Savvis e AT&T. As concessionárias brasileiras, devem merecer um estudo, em separado, sobre onde elas se encaixam nesse contexto. Mas algumas destas gigantes americanas possuem seus próprios PTTs (inclusive no Brasil, curiosamente articulado ou facilitado, por uma instituição de fomente brasileira – como é o caso do NAP, em Barueri) e, provavelmente, grandes empresas brasileiras (por exemplo, as empresas estaduais de processamento de dados, grandes provedores, grandes empresas de co-locação e hospedagem, ISP’s virtuais), não conseguem troca de tráfego com estes PTTs, enquanto que, provavelmente, as concessionárias brasileiras do STFC conseguem.

    Das observações acima é possível imaginar que o NIC.br está liderando a construção dos PTTMetros preocupado em permitir o acesso de interessados, com pequeno volume de tráfego, favorecendo condições econômicas de “peering” e de trânsito, estimulando o desenvolvimento seguro e eficaz da Internet brasileira. Além de tentar neutralizar ou diminuir as tendências de formação de monopólios e cartéis no cenário brasileiro. Felizmente, a partir do final de 2008 e início de 2009, uma frente de apoio da comunidade está levando à criação dos chamados PTTs Regionais (PTT-R). Não é possível deixar de lembrar um dos mais ativos atores, nesse movimento: a ANID.

    Um dos prérequisitos para se ligar a um PTT é ser um Sistema Autônomo ou participar de um grupo de possua um Sistema Autônomo “compartilhado”.

  5. Sistemas autônomos e o BGP-4

    Um AS é um grupo redes TCP/IP conectadas, sob o controle de um ou mais operadores ou entidades. Vejam a figura abaixo. Ela mostra dois grupos de redes TCP/IP conectadas. Cada uma pertence à respectiva entidade. Entidade A e Entidade B.

    São dois grupos de redes independentes. Para que os dois grupos de redes possam se integrar é necessário que a Entidade A e a Entidade B façam um acordo de “peering”. Fazendo o acordo de “peering”, então a conexão entre os dois grupos de redes TCP/IP (ou entidades) é estabelecida. Como a figura abaixo:

    Se o acordo de “peering” entre as A e B tem como objetivo a visibilidade dos equipamentos de cada uma (por exemplo, um navegador em uma máquina de A poder acessar um servidor de Web de B), então elas precisam estabelecer uma política de roteamento comum. Então, cada uma das entidades, separadamente, passam a ser um Sistema Autônomo ou AS. Se imaginarmos milhares de entidades interconectadas, a melhor definição para AS é a dada por20: um AS é uma porção lógica de uma grande rede IP.

    Portanto, podemos esquecer a identificação “entidade” e passar a chamá-las de AS A e AS B. Na realidade, na Internet, cada AS é identificado por um número único, chamado de “Autonomous System Number“, ou ASN. Embora não esteja representada, ainda, o trânsito de Internet nas figuras acima, o ASN, por ter a característica de ser único, é obtido através de uma instituição controladora. Aqui no Brasil o ASN é obtido via o NIC.br em acordo com o LACNIC14.

    Os preços para aquisição de um ASN, blocos de IPv4 e IPv6 podem ser vistos em [25].O ASN é um número de 16 bits (já com um projeto para 32 bits). O 0-(zero) e o 65535 são reservados. De 1 a 64511 são ASN’s públicos, fornecido pelo NIC.br. Os ASN’s de 64512 a 65534 são considerados privativos e usados para o estabelecimento de AS particulares. Supondo que A e B possuem políticas de roteamento compatíveis com a Internet, então podemos recompor a figura usando a referência do ASN de cada uma delas. Suponhamos que A tenha o ASN=i e B tenha o ASN=j, onde 0 < i != j < 64512. Então, a figura agora fica mais clara:

    Então, recapitulando, AS constrói o cenário da Internet. Com sua nova definição, o cenário da nova Internet, em franca expansão! AS´s se entendem através de uma política de roteamento comum. No Brasil, existem atualmente (março/2006) cerca de 200 AS’s. O NIC.br, por ocasião da Telexpo 2006, considera esse número muito baixo e a expectativa é de que ele dobre em um ano. Em se tratando da Internet, a política de roteamento é estabelecida através do uso do protocolo BGP-411. O BGP é um protocolo antigo, mas a versão 4 passa a suportar o conceito de agregação de rotas e o CIDR 23. Tais recursos permitem a publicação de rotas de maneira simples, transformando complexidades em facilidades na interconexão de redes em ambiente de grande porte. O BGP-4 aumentou, consideravelmente, a escalabilidade do BGP!

    Escapa do escopo desse trabalho, detalhes técnicos sobre o BGP-4. Na área restrita, estaremos fazendo abordagens mais adequadas e profundas sobre AS e, naturalmente, dos poderes do BGP-4 integrando e facilitanto o projeto. Um bom tutorial sobre BGP-4, oferecido no 17° GTER está em 24.

  6. Mais sobre “peering”, trânsito e algumas considerações econômicas

    O entendimento do conceito exato de “peering” e trânsito não é muito fácil. Alguns profissionais experientes consideram uma questão obscura e complexa. Basicamente, duas razões levam ao pensamento de dificuldade de compreensão: o oligopólio das grandes concessionárias (monopólio regional, no Brasil – o que piora o cenário) e os custos envolvidos.

    Vamos recompor nossa definição de “peering” para estimular o entendimento: “peering” é uma relação entre ISP’s ou entre outras redes que agregam Internet, na qual eles trocam o tráfego de seus clientes, entre si, geralmente sem envolvimento de dinheiro. A idéia por trás dos PTT’s é proporcionar facilidades para “peering” entre seus participantes. Mas, no Brasil, os PTT’s estão nas regiões metropolitanas e, portanto alijam do processo, os pequenos provedores do interior. Por outro lado, “peering” é, também feito entre ISP’s sem passagem por um PTT. É o que acontece entre as concessionárias de telecomunicações no Brasil. Mas não acontecem entre provedores, principalmente de pequeno porte. E há muitos equívocos por trás da ausência de “peering” entre os provedores brasileiros. Primeiro porque não há, absolutamente, interesse das concessionárias, de que os ISP’ saibam desse recurso. Segundo por um desconhecimento profundo dos ISP’s sobre o que pode ser feito e, curiosamente, das próprias concessionárias em face de seu modelo de negócios. Por exemplo, quando um ISP possui dois enlaces para a Internet (isto é, trânsito) ele imagina que esta alternativa é factível somente para evitar perdas de conexões para seus usuários. E nem pensam que a melhor forma de garantir isso é obtendo um ASN e, consequentemente, implementando BGP-4 poderiam, além de adequar de forma correta o balanceamento de tráfego, se tornar independente em relação à publicação de seus IPs (IPv4 e IPv6 – esse, em uso crescente). Com o ASN, o provedor está fazendo “peering” sob trânsito nas duas concessionárias, numa solução barata, provavelmente usando recursos que já possui. E, não se pode esquecer o fato de que as concessionárias fazem “peering” entre si, sabe-se lá como.

    A próxima questão importante a ser debatida é: porque fazer “peering”? Há três razões imediatas: (i) é barato, (ii) irá melhorar a eficiência da conexão sob o ponto de vista de eliminar terceiros no relacionamento entre grupos de PSIs com interesses na troca de tráfego (VoIP, por exemplo) e, (iii) ganha-se maior controle sobre as rotas. Cada uma destas razões merecem comentários e novos debates, que serão feitos em outra oportunidade.

    E, existem motivações para não se fazer “peering”?. Sim, muitas! A primeira razão é curiosa e associada a uma pergunta óbvia, praticamente recursiva, de “o que é “peering?”. Quando se compra trânsito, um conjunto de facilidades estão embutidas, simplificando o trabalho e tornando os administradores de redes despreocupados com o significado de “peering”, se existe “peering” e como se faz “peering”! Uma segunda razão, para não fazer “peering” é o fato de, curiosamente, ele ser caro sob o ponto de vista dos investimentos, dependendo do cenário ou localização do interessado. Embora o “peering”, em si, seja livre de custos, há custos associados à física para chegar ao PTT. Há o espaço para hospedar servidores, switchs e/ou roteadores, nas proximidades do PTT. Além de investimentos em equipamentos necessários ao “peering”. Em resumo, o trânsito acaba sendo mais barato se abandonamos a idéia do “peering”. A terceira razão é de que “peering” pode dar trabalho e exigir conhecimento, excedendo á competência dos administradores de redes. Tudo isso com que os custos fiquem elevados com contratação de terceiros, por exemplo. Como quarta motivação sobressai a questão da eficiência, cujo ganho irá depender das condições em que o trânsito é estabelecido. Mesmo essa questão pode nos enganar facilmente. Os oligopólios fazem “peering” entre si, como falamos. E, repetindo, sabe-se lá como! O “sabe-se lá como” é a parte preocupante da questão que pode negar a vantagem de não se fazer “peering” devido ao quarto propósito acima. A governança da Internet brasileira (leia-se, Comitê Gestor), está preocupada com essa questão, tanto que já comunicou às grandes operadoras que irá monitorar os “peering” por elas estabelecidos. A eficiência pode estar sendo comprometida e, em face da complexidade, os provedores e/ou empresas usuárias nem percebem isto ou não podem resolver e nem discutir as demonstrações de ineficiência do trânsito contratado.

    Estas questões são abordadas com muita propriedade em [21] incluindo um interessante cálculo de custos envolvidos no “peering”. Muitos outras informações podem ser encontradas no sítio da Packet Clearing House (PCH)22.

  7. Conclusões e considerações finais

    As técnicas envolvendo Sistemas Autônomos e os protocolos que circundam o BGP-4, por sí só, garantem a viabilidade do segundo projeto (a principal expectativa). Mas, o componente financeiro, em particular, os custos de projeto e aqueles necessários à manutenção do ambiente central de oferta de recursos e facilidades, indicam que não se pode viabilizar um projeto como esse sem a participação (ou união), de uma considerável parcela dos provedores brasileiros.

    É praticamente impossível abordar um projeto como esse, que exige razoáveis investimentos, no esquema tradicional de divisão de cotas, onde cada provedor participa com um valor préviamente estabelecido, por duas razões. A primeira, pela dificuldade em estabelecer o valor da quota (ou, o número de participantes). A segunda, porque os provedores brasileiros já estão cansados de investir em perspectiva, sem que ela se apresente, efetivamente. Sendo assim, os modelos até hoje procurados, Associações, Cooperativas etc., tendem a não oferecer resultados e, infelizmente, não viabilizariam a saida do papel de um projeto como esse. Vale dizer, que outras formas de agrupamento dos ISP´s são válidas e devem continuar sendo mantidas ou criadas.

  8. Agradecimentos

    Inúmeras pessoas contribuiram para este trabalho e de várias maneiras. Gostaríamos de expressar o agradecimento a todos e alguns, em particular. Ao Eugênio Fonte Boa13, que revisou o texto inúmeras vezes. Ao Bruno Cabral1, da Openline que leu o texto várias vezes, contribuindo com diversas observações. Ao Rubens Kuhl Jr. que, em diversas conversas e e-mail, contribuiu para o entendimento de questões técnicas e concepção das ideias, as quais são mais fortes na área restrita. Finalmente, ao Nicolau Meisel que recompôs todo o conjunto recomendando ajustes fundamentais, como sempre o fez e de maneira original.

  9. Epílogo

    Esse artigo foi escrito no início de 2006. Na época, o principal objetivo era estabelecer um equilíbrio no pensamento dos provedores, em relação aos conceitos e termos envolvendo PTTs. Havia, também, a preocupação de nos aproximar na defesa da criação dos PTT regionais (PTT-R). Na medida do possível, iremos atualizando e simplificanto o texto, além de ajustá-lo aos movimentos que estão tornando a Internet brasileira, mais preparada para reagir aos interesses de grupos poderosos e desinteressados em levá-la a toda a sociedade brasileira, em benefício do resultado financeiro. Finalmente, observa-se uma diferença significativa, na visão positiva dos PSIs em relação aos PTTs, desde o ano de 2006 até agora, 2009.

  10. Referências
    1. Bruno L. F. Cabral, E-mails, etc.
    2. Comitê Gestor Internet/Brasil, GT-ER, Proposta para a Recomendação de PTTs
    3. Eugênio Fonte Boa, E-mails, reuniões, etc.
    4. Freesoft
    5. Hawkinson, J. e Bates, T., Guidelines for creation, selection, and registration of an Autonomous System (AS), RFC1930, 1996.
    6. Legislação brasileira de Telecomunicações
    7. MGIX
    8. N. Silva e outros, Metropolitan Internet eXchange – MIX (em português PTTMetro)
    9. PTTMetro
    10. Rede Eletronet (mapa)
    11. Rekhter, y. e Li, T., A Border Gateway Protocol 4 (BGP-4), RFC1771, 1995
    12. Rubens Kuhl Jr., E-mails, reuniões, etc.
    13. Wikipedia
    14. Lacnic – Solicitando ASN
    15. IANA, Autonomous System Numbers
    16. BGP
    17. Redes da Infovias
    18. REMAV – Redes Metropolitanas de Alta Velocidade
    19. RedeRio de Computadores (FAPERJ)
    20. Adolfo Rodriguez, John Gatrell, John Karas, Roland Peschke, TCP/IP Tutorial and Technical Overview
    21. Steve Gibbard, Economics of Peering
    22. Packet Clearing House
    23. Introdução a CIDR (Classless Inter-Domain Routing)
    24. Caio Klein, BGP v4 – Tutorial
    25. LACNIC – Tabela de preços

    * Alguns chamam de última milha. Ambos os termos não possuem definição bem clara. Preferimos identificar como primeira milha, já que é onde começa a demanda para o acesso à Internet e é, também, um ponto bem definido.

Categorias:PTT, TCP/IP Tags:, , , , ,
%d blogueiros gostam disto: