Arquivo

Archive for março \22\-03:00 2010

Curso IRR – Parte III: Inserindo dados na base IRR

A base do IRR é formada de objetos. Cada objeto tem uma função bem definida e é formado por atributos. É obrigatório que existam dois objetos antes que se possa criar, alterar ou excluir outros objetos: o mntner e o person. O objeto mntner é aquele que contem as informações (através de seus respectivos atributos), que qualificam e autenticam um AS. O objeto person serve para qualificar o administrador ou administradores do objeto mntner. Pode haver mais de um objeto person para um mesmo mntner e vários objetos mntner podem possuir um mesmo objeto person.

Cada objeto é bem definido através de seus atributos que são apresentados um “template” ou padrão. Eis os padrões para os objetos mntner e person e, seus atributos:

mntner:         [obrigatório]  [único]      [chave primária e de pesquisa]
descr:          [obrigatório]  [múltiplo]   [ ]
admin-c:        [obrigatório]  [múltiplo]   [chave inversa]
tech-c:         [optional]     [múltiplo]   [chave inversa]
upd-to:         [obrigatório]  [múltiplo]   [chave inversa]
mnt-nfy:        [optional]     [múltiplo]   [chave inversa]
auth:           [obrigatório]  [múltiplo]   [ ]
remarks:        [optional]     [múltiplo]   [ ]
notify:         [optional]     [múltiplo]   [chave inversa]
mnt-by:         [obrigatório]  [múltiplo]   [chave inversa]
auth-override:  [optional]     [único]      [ ]
referral-by:    [optional]     [único]      [chave inversa]
changed:        [obrigatório]  [múltiplo]   [ ]
source:         [obrigatório]  [único]      [ ]

person:        	[obrigatório]  [único]      [chave de pesquisa]
address:       	[obrigatório]  [múltiplo]   [ ]
phone:         	[obrigatório]  [múltiplo]   [ ]
fax-no:        	[opcional]     [múltiplo]   [ ]
e-mail:        	[opcional]     [múltiplo]   [chave de pesquisa]
nic-hdl:       	[obrigatório]  [único]      [chave primária e de pesquisa]
remarks:       	[opcional]     [múltiplo]   [ ]
notify:        	[opcional]     [múltiplo]   [chave inversa]
mnt-by:        	[opcional]     [múltiplo]   [chave inversa]
changed:       	[obrigatório]  [múltiplo]   [ ]
source:        	[obrigatório]  [único]      [ ]

Na realidade, o IRR usa objetos no formato especificado pela Routing Policy Specification Language (RPSL), definida pela RFC2622, na qual vale a pena dar uma lida, tamanha sua importância.

Vejamos o objeto *mntner* para o AS28182 (whois -h irr.redepegasus.net.br MAINT-AS28182):

mntner:     MAINT-AS28182
descr:      TeleSA
admin-c:    Juliao Braga
tech-c:     Juliao Braga
upd-to:     jb@telesa.net.br
mnt-nfy:    jb@telesa.net.br
auth:       CRYPT-PW ZocCkOH/zCkQw
mnt-by:     MAINT-AS28182
changed:    jb@telesa.net.br 20090302
source:     PEGASUS

Um objeto possui os atributos definidos pelo seu “template” (ou padrão). Atributo com o mesmo nome do objeto é quem qualifica o objeto. No exemplo acima:

mntner:     MAINT-AS28182

O objeto mntner sempre deve ser inserido primeiro. Justamente por causa do atributo auth. Existem diversos tipos de autenticações: via PGP, via senha criptografada, via e-mail e sem autenticação. Eis algumas representações:

auth: PGPKEY-2CD5CE3
auth: CRYPT-PW lz1A7/JnfkTI
auth: MAIL-FROM jb@telesa.net.br
auth: MAIL-FROM .*@telesa.net.br
auth: NONE

O Pegasus IRR aceita todos eles. O mais prático é o por senha criptografada:

auth: CRYPT-PW lz1A7/JnfkTI


É a nossa alternativa recomendada. Então, será necessário criptografar uma senha. Suponha que escolhemos a senha 1##23CP20C. Usamos a facilidade que pode ser encontrada em https://www.radb.net/radb/crypt_calculator.html. O resultado da senha criptografada é: g0hSOSrs03VXo.

Assim, o objeto mntner para o primeiro objeto e, obrigatório, a ser inserido, deveria estar assim:

mntner:     MAINT-AS28182
descr:      TeleSA
admin-c:    Juliao Braga
tech-c:     Juliao Braga
upd-to:     jb@telesa.net.br
mnt-nfy:    jb@telesa.net.br
*auth:       CRYPT-PW g0hSOSrs03VXo   #Senha criptografada*
mnt-by:     MAINT-AS28182
changed:    jb@telesa.net.br 20090302
source:     PEGASUS

Enviamos então, um e-mail em formato texto para db-admin at redepegasus dot net dot br. Logo após o recebimento da informação de inclusão no Pegasus IRR, pode-se enviar outros objetos. E o primeiro deve ser o person, como abaixo:

person:     Juliao Braga
address:    Pegasus Telecom
address:    Brazil
phone:      +55 12 3027 7105
e-mail:     jb@pegasus.com.br
nic-hdl:    LJF32-NICBR
notify:     jb@pegasus.com.br
mnt-by:     MAINT-AS18782
mnt-by:     MAINT-AS28182
mnt-by:     MAINT-AS53073
changed:    jb@telesa.net.br 20090903
changed:    jb@telesa.net.br 20090926
remarks:    Thu Nov 26 07:30:01 BRST 2009
source:     PEGASUS
password:   1##23CP20C

O atributo password, acima é o componente fundamental para que haja sucesso na inclusão do objeto person. É importante lembrar que esse atributo deve ser o último e não pode haver linhas em branco separando atributos. Esse objeto deve ser enviado para auto-dbm at redepegasus dot net dot br. Todo o procedimento de agora em diante passa a ser automático através desse e-mail (em formato texto …). Vale lembrar que os dois objetos podem ser enviados de uma só vez no primeiro e-mail, alternativamente. Nesse caso com o atributo password no final de cada objeto e, uma linha em branco separando cada objeto.

A figura abaixo exibe a participação do auto-dbm e respectivas ações:

Onde e como o auto-dbm atua

Onde e como o auto-dbm atua.

Exercícios:

  • Incluir os objetos mntner e person em um só e-mail.

  • Descreva o significado de [chave primária e de pesquisa], [chave primária] e [chave inversa] que aparecem na representação dos padrões de objetos.

 

Itens relacionados:

 

Categorias:IRR

Curso IRR – Parte II: O que é o IRR

Introdução

 

O IRR (Internet Routing Registry) é um repositório de políticas de roteamento. Os dados do IRR podem ser usados por qualquer pessoa com o objetivo de obter informações para depurar, configurar e planejar endereçamento e política de roteamento. Resumidamente, o IRR e ferramentas associadas:

  • facilitam a validação do conteúdo de mensagens dos anúncios BGP
  • permitem mapear um ASN em suas respectivas redes
  • permitem a definição de políticas de roteamento bem mais amplas do que através de filtros, nos roteadores
  • gera configurações para roteadores

O IRR foi criado em 1995 na época em que os provedores de acesso à Internet do mundo estavam se preparando para o final da atividade do backbone da NSFNET e, comemorando o primeiro aniversário da Internet comercial. Por volta de 1999, haviam os seguintes repositórios: CA*Net, no Canadá, o ANS, CW e RADB nos EEUU e o RIPE na Europa. Os três primeiros eram privativos e os dois últimos, públicos. Atualmente, os repositórios cresceream e uma lista das bases de dados IRR pode ser vista, preferencialmente, na página do sítio oficial do IRR reproduzidas abaixo.

  • ALTDB
  • AOLTW
  • APNIC
  • ARIN
  • BCNET
  • BELL
  • DERU
  • DIGITALREALM
  • EASYNET
  • EBIT
  • EPOCH
  • GT
  • GW
  • HOST
  • JPIRR
  • LEVEL3
  • REACH
  • RETINA
  • RGNET
  • RIPE
  • RISQ
  • ROGERS
  • SAVVIS
  • WVFIBER

A principal base é o RADB. As outras bases são periféricas e usam o RADB de duas possíveis maneiras:

  1. Espelhamento bi-direcional.
  2. Espelhando o RADB e outras bases (espelhamento unidirecional).

Em ambos os casos, usa-se o servidor IRRd. O espelhamento unidirecional nem sempre é somente com o RADB para o IRRd e é muito usado por grandes concessionárias para manter os servidores, disponíveis mais próximos de seus clientes.

Algumas bases são de uso gratuito, como a ALTDB e são bidirecionais. Não mais do que 10 minutos são necessários para que o RADB atualize uma inclusão ou alteração sobre seus servidores homologados, como o caso do Pegasus IRR.

Os dados do IRR podem ser obtidos, também, via whois, como já vimos. Os recursos para obter informação do IRR via o whois são enormes e ao longo do treinamento estudaremos os diversos formatos.

É possível obter os dados atualizados das bases que são espelhadas e da própria base do RADB, [1] e, usar diversas ferramentas disponíveis gratuitamente, na Internet para pesquisá-las.

Em [2] é possível pesquisar todos os objetos disponíveis nas bases IRR, para um mesmo mantenedor. Testem, por exemplo, com MAINT-AS28182. MAINT-ASn é o formato preferido (e recomendado) para o nome de um mantenedor, embora não seja um formato obrigatório. Sendo o formato preferido, todo mundo usa. Vamos usá-lo, portanto apesar de não ser a sugestão do artigo “Some practical advice on using the IRR”, do Merit. Alternativamente, em [3] , ainda em desenvolvimento pode-se pesquisar de maneira simples.

Recomendamos a leitura da apresentação “APNIC Internet Routing Registry”. Na sequência vale a pena ler uma interessante avaliação em “A Survey On Utilization of IRR’s Route Objects”. Ambos na BC.

Eis algumas ferramentas para usar/pesquisar uma base IRR, de forma inegrada:

  • IRRToolSet: ferramenta para análise de políticas de roteamento e geração de configurações para roteadores a partir das informações contidas no IRR. A versão, 4.8.6, pode ser obtida aqui e, em [4], muitas informações adicionais e o candidato à versão 5.0.
  • IRR Power Tools: é uma coleção de utilitários que permite facilmente pesquisar, gerenciar e utilizar as informações de roteamento contida no IRR (http://sourceforge.net/projects/irrpt/)
  • ASLookup: é uma ferramenta para pesquisar a sequência de um ASN que esteja registrado no IRR e o retorno da primeira linha de descrição de um objeto AS. Através do ASLookup podemos pesquisar diversos números de AS, usar o resultado do “show ip bgp” e, descobrir um AS a partir de um endereço IP. Obtenham em http://aslookup.bgpview.org/index-e.html.

Conhecer as ferramentas disponíveis será importante para que possamos definir de forma correta as configurações dos objetos que deveremos incluir na base IRR. Nas próximas aulas iremos começar a atividade prática. As recomendações de leitura não precisam ser consultadas, sob o ponto de vista prático, É recomendação adicional para os que fazem do BGP uma ferramenta de trabalho. Nesse caso seria bom enfrentar o curso do RIPE, “Routing Register Training Course”. Recomenda-se o uso do PEGASUS IRR. É a melhor maneira de compreender as entre-linhas das aulas, nesse treinamento. Não se deve preocupar em errar, eventualmente. Em computação, o erro, contribui para a aprendizagem (a não ser que tenha sorte, [5]). Finalmente, uma geral sobre o sítio Overview of the IRR é o exercício desse segmento.

 

Itens relacionados:

 

 

Referências

 

[1] Bases de dados do IRR, associadas ao RADB.
[2] Whois do RADB.
[3] Whois do Pegasus IRR.
[4] Wiki do IRRToolSet
[5] Erl, T., SOA Princípios de design de serviços, Pearson Prentice Hall, São Paulo, 2009.

Categorias:IRR, Sem categoria

Curso IRR – Parte I: Introdução

Vou reproduzir o treinamento virtual que dei recentemente para cerca de 46 inscritos. Um pouco mais aperfeiçoado. Haverá no mínimo uma postagem por semana.

Os tópicos a serem abordados serão:

  • As bases de dados.
  • Pesquisas às bases com o objetivo de avaliar as tabelas de rotas e eventuais consistências das tabelas.
  • A utilização da base para ajustar de forma adequada os filtros dos roteadores.
  • Ferramentas de apoio.

Cada postagem, com o título começando por “Curso IRR”, refere-se a uma mensagem do treinamento virtual. São poucas mensagens, complementadas pela documentação, disponível e/ou a ser inserida na Base de Conhecimento da Pegasus, em .

Muito importante serão os exercícios. Para isso, o PEGASUS IRR estará disponível para os interessados, por um período de 30 dias, sem ônus. Se alguém estiver em alguma base que não a do PEGASUS IRR pode, assim mesmo usar nosso registro e, portanto, executar os exercícios. Estar registrado em mais de uma base IRR, não é recomendável mas, não há problemas que isso aconteça por pouco tempo. Os interessados podem solicitar o uso temporário a j at braga dot net dot br, indicando o ASN.

Sintam-se à vontade para, através dos comentários participar de cada segmento. Assim, todos se beneficiarão. Nenhuma dúvida deve ser evitada e é menor ou maior do que a outra. Portanto, não se acanhem, por favor.

O whois será a nossa principal ferramenta de pesquisas. Os hosts podem ser tanto o irr.redepegasus.net.br como outro qualquer (p. ex.: whois.radb.net). Eis alguns exemplos de pesquisas:

. whois -h irr.redepegasus.com.br juliao
. whois -h irr.redepegasus.com.br fltr-unallocated
. whois -h irr.redepegasus.com.br AS28182
. whois -h irr.redepegasus.com.br fltr-bogons
. whois -h irr.redepegasus.com.br MAINT-BOGON-FILTERS
. whois -h irr.redepegasus.com.br MAINT-AS28182
. whois -h whois.radb.net MAINT-AS28182

Exercícios para esse segmento

Podem enviar os exercícios para j at braga dot net dot br que serão avaliados em Comentários de cada segmento. Daremos uma declaração de participação no treinamento com base nos exercícios resolvidos, nos enviado.

  1. Quais os hosts possíveis de serem pesquisados via whois e estejam espelhadas pela base do RADB?
  2. Executar as pesquisas acima e pensar sobre os resultados. Fazer as pesquisas em mais de um host.
  3. Dê uma demorada olhada no sítio do RADB.

 

Textos relacionados:

 

Categorias:IRR, Sem categoria Tags:,

Reflexões brasileiras: Plano Nacional de Banda Larga

Introdução

O debate sobre o Plano Nacional de Banda Larga extrapolou o foco inicial, EMHO. Inicialmente, o objetivo para a implementação do PNBL era prover a primeira milha (outros chamam de última milha – diferença já abordada nesse blog), com banda suficiente para o uso da Internet sem restrições e, como mais importante objetivo, estender as facilidades da Internet a todo o território nacional, caracterizando a inclusão da população brasileira. O principal objetivo (o segundo acima) se sobrepõe a qualquer eventual restrição. Nesse aspecto o governo brasileiro está corretíssimo. Nada demonstra ao contrário. É uma decisão política que reflete no futuro, com imensa grandiosidade.

A preocupação da presente reflexão é lembrar àqueles que estão desenhando o projeto da PNBL de alguns aspectos esquecidos e, curiosamente, representam a força de sua viabilidade, na amplitude proclamada. Além de simplificar o debate e estimula o caminho da complexidade com entendimento intuitivo e completo.

Pressupostos

O primeiro componente da reflexão são os PTTs* e o trabalho que vem fazendo o Nic.br, nessa direção. Acertou o Nic.br. Eis o mapa dos PTTs atuais, na Figura 1, abaixo.

Figura 1. PTTs já em funcionamento (bolas azuis) (Ref:Mapa do Brasil retirado de uma página do BNDES).

Outros estados brasileiros e respectivas cidades importantes, já estão com seus PTTs em andamento. Um estímulo financeiro, sem que haja significativo excesso nos recursos já alocados pelo Nic.br pode, rapidamente, crescer a presença dos PTTs. Com os PTTs, ocorrerão duas coisas importantes: rápido acesso à Internet em locais onde a dificuldade é maior e baixo custo para esse acesso.

Pressupostos no entorno dos PTTs

A iniciativa privada (concessionárias com mente avançada e, principalmente os pequenos provedores) irá se aproveitar da disponibilidade dos PTTs. A competição, sob uma demanda de mercado imensa cuidará dos preços acessíveis. Sempre haverá condições para competir. As empresas de Serviço de Valor Agregado – SVA (VoIP, gerenciamento remotos, datacenters, etc.) e de serviços de infraestrutura (física e lógica) sofrerão um impacto positivo, principalmente, aquelas com conhecimento e características de inovação, que estejam preparadas para o que virá junto com o PNBL. Não se deve mexer ou criar empecilhos para livre iniciativa. Exceto o uso dos recursos periféricos de interesse público. Coisa que a Anatel pode cuidar desde que ela seja uma agência reguladora independente, isto é, no sentido lato, uma agência reguladora PRECISA ser independente.

PTT está ótimo sob a coordenação do Nic.br, muito bem preparado para isso. Deixemos com ele. Mas, surge uma questão importante com os PTTs. Eles devem se interconectar. A interconexão entre PTTs tem sido feita pela iniciativa privada e, com muita frequência tem ocorrido a “tercerização” do transporte nessas interconexões. O resultado é o preço aviltado em não menos do que 40%, com uma natural variação muito grande. Chamo isso de “terceirização oportunista”. Se continuar dessa forma, teremos instabilidade nas interconexões (e, nos preços), entre os PTTs. A proposta é que, à luz dos objetivos fundamentais do PNBL, cuide o governo das interconexões. Mas, colocar isso nas mãos de uma empresa nova, sem experiência ou quadros preparados é um tiro no pé. Portanto, a sugestão do modelo exposto nesse texto é deixar por conta de quem entende muito e com bastante experiência de interconectar todo o Brasil: Rede Nacional de Pacotes (RNP). A RNP é imbatível na habilidade em lidar com redes de longa distância, complexas e funcionais e, com facilidade contorna as limitações físicas.

À iniciativa privada, deve restar o mais importante gerador de negócios do PNBL: o trânsito e o transporte. A primeira milha, com as facilidades dos PTTs e suas interconexões cuidará para que os patamares dos preços de trânsito e transporte estejam nos limites adequados.

As interconexões entre os PTTs

As interconexões entre os PTTs exigem facilidades físicas. Vejam o privilégio do Brasil: Eletronet e congêneres! Ai entra o governo com o fôlego atual, com ênfase na recriação da Telebrás. A Telebrás parece ser mais apropriada para absorver a rede da Eletronet, nas condições em que se encontra. Uma restrição interessante à Telebrás é a de que ela seja um Tier 1**, no Brasil. A restrição é de que ela nunca compre trânsito, em particular, trânsito internacional, já que ela É o trânsito nacional. Colocando a RNP e Nic.br no circuito fundamental do PNBL, a Telebrás será uma empresa enxuta e orientada a perpetuar o PNBL na medida da necessidade do povo brasileiro e na dinâmica inerente à inovação tecnológica (tipo, “o futuro é agora”). Ela será, também, uma empresa de fomento e pouco interesse haverá para investidores. O governo não precisa de investidor para a Telebrás. Que se use o FUST pois, estará muito bem empregado. Não se pode esquecer que à Telebrás exercerá um papel importante na formação dos preços da primeira milha (ela é um Tier 1, grande – ou, maior – vendedora de trânsito no Brasil!). Não estou entrando no mérito ou justificativas jurídicas que envolvem a Eletronet. Nem conheço bem essa questão. Mas com ou sem a Eletronet, o modelo faz sentido. Por exemplo, a RNP tem um backbone que transcende ao da Eletronet (independente se próprio ou contratado).

Conclusões

O modelo da reflexão é curto e grosso. Mas mostra um outro caminho para o debate. Sobretudo, retira das bordas o excesso, sob a luz dos interesses de grupos e avança na direção de um debate mais participativo.

A proposta é simples, como disse. Há algumas respostas a perguntas que poderiam aparecer. E, ansiedade por contribuições. Na sequência, pode-se aprofundar no modelo da reflexão. Não se pode deixar de criar o debate objetivo que traga benefícios para o país. Faz parte de nosso princípio profissional evitar que a indefinição direcione a um cenário em que a competição efetiva seja posta de lado. Competição irá absorver a expectativa de todos os brasileiros, em particular, as nossas, empresas e técnicos. Talvez, a palavra chave. Indefinição e despreparo técnico para sustentar o cenário complexo o transformará em caos, numa extensão jamais vista. Mas, um PNBL consistente e visível, certamente será exemplar ao povo brasileiro.

* PTT, ou mais precisamente, PTTMetro é o nome dado ao projeto do Comitê Gestor da Internet no Brasil (CGIbr) que promove e cria a infra-estrutura necessária (Ponto de Troca de Tráfego – PTT) para a interconexão direta entre as redes (“Autonomous Systems” – ASs) que compõem a Internet Brasileira. A atuação do PTTMetro volta-se às regiões metropolitanas no País que apresentam grande interesse de troca de tráfego Internet. (http://sp.ptt.br/intro.html)

** Tier-1 é a referência a um provedor de acesso à Internet que tem acesso à tabela de roteamento global sem comprar trânsito de ninguém. A tabela de roteamento é estabelecida ou atualizada, através de relações de “peering”. Nesse texto, está sendo usado no contexto do território brasileiro, somente e, não entra no mérito (abstração ditática) à tabela de roteamento.

Categorias:PNBL

Tráfego, trânsito, transporte e peering (uma proposta de definição)

Introdução

Sistematicamente, há sempre alguém pedindo para identificar a diferença entre tráfego, trânsito e transporte. Tem sido tão frequente, que resolvi mais uma vez dar uma explicação definitiva aqui no Infraestrutura da Internet. Naturalmente, sob o meu ponto de vista pessoal, que difere um pouco do senso comum.

O senso comum, parece estar pouco interessado em uma explicação suficientemente clara. Imagino, que seja porque a noção de tráfego, não é intuitiva em relação à acepção da palavra. Isso ficou mais evidente quando apareceram os PTTs. Para o senso comum, tráfego é o fluxo de dados que acontece entre os pares que fazem acordos dentro de um PTT. Esse texto propõe mudar o significado de tráfego.

Intuitivamente, a noção que temos de tráfego é tudo aquilo que trafega em rodovias ou, nas ruas e avenidas de uma cidade. Inclui motos, caminhões, triciclos, automóveis seja lá de que marca ou modelo forem. Essa é a noção que estamos procurando, quando o contexto é a Internet. Nesse contexto, portanto, definimos tráfego como: tudo o que se movimenta nos meios físicos de transmissão de dados, através de representações reconhecidas por protocolos bem definidos. Tudo! Tráfego é bit! Seja lá o que os bits representem.

Internet, trânsito e tráfego

Vamos relembrar de alguns conceitos primitivos sobre a Internet, a partir da figura abaixo:

Figura 1. A Internet

A figura acima não é uma forma tradicional de representar a Internet (usualmente, em uma única nuvem) e, nem é original exceto pelo fato de incluir, além do aglomerado de sistemas autônomous (ASes), em laranja, os pontos de troca de tráfego (PTTs), em verde e, em azul, os sistemas não autônomos (NASes). Nossa definição intuitiva, não fica prejudicada pela palavra tráfego, no PTT. Pelo contrário, melhora nossa posição em relação ao senso comum, como veremos mais adiante! Incomum é a representação do que chamamos sistemas não autônomos (NASes). Sistemas não autônomos são redes que, apesar de serem administrativamente independentes usam recursos e acessam a Internet através de um ou mais ASes. Por exemplo, um provedor de acesso à Internet que não seja dono de seus próprios IPs é uma rede não autônoma. Os IPs são fornecidos por algum sistema autônomo (AS) ao qual está conectado, geralmente, através de protocolos que não seja o BGP. Vale lembrar, apesar de não nos interessar nesse artigo, que mesmo um NAS pode se comportar como um AS e, portanto, implementar BGP (dai a razão da palavra “geralmente”).

Uma questão que nos vem à mente quando exibimos a Internet como um aglomerado de ASes e PTTs é: qual o tamanho da Internet? Abstraindo-nos dos usuários e dos NASes, podemos enxergar o tamanho da Internet pelo número de ASes e de PTTs. Em [1] há uma referência a 359 PTTs, 86 nos EEUU e 19 no Brasil (segundo lugar em números de PTTs em 26/06/2012, incrementado pelas expectativas de [4]. Ótimo trabalho do Nic.br). Já em [2], uma estatística, do dia 11/03/2011, o IANA alocou aos RIRs, 61.438 números de sistemas autônomos (ASN) – cada AS tem um ASN univocamente associado. Mas, um AS alocado não significa atividade imediata. Aos interessados, vale uma incursão nas referências [1] e [2].

A visão da relação econômica entre ASes e seus NASes é, também, importante, como motivação para entendermos a noção de tráfego. Um NAS, quando se interconecta a um AS estabelece uma relação econômica com puro interesse de acesso à Internet, isto é, com o objetivo de permitir aos usuários de sua rede (do NAS), acessar a Internet! No nome dado ao acesso à Internet é trânsito. Nesse sentido, tráfego se confunde com trânsito. Ou, em uma relação aritmética: tráfego = trânsito. Se representarmos tráfego pela letra T (maiúscula) e trânsito por \textbf{t} _ \textbf{n}, a relação aritmética fica mais próxima do formalismo usual: \textbf{T = t} _ \textbf{n}.

Caminho do tráfego

Vamos estabelecer um outro cenário, capturando da Figura 1, somente dois ASes (ASi e ASj) e seus respectivos NASes. Teremos, então, a Figura 2, abaixo:

Figura 2. Cenário simplificado.

Suponha que os NAS1, NAS2 e NAS3 possuam servidores de mensagens. Uma mensagem com origem em NAS1 e destino em NAS2, segue o caminho definido pela seta azul. É um caminho que faz jús ao trânsito contratado. Suponha agora, que a origem da mensagem seja NAS1 e o destino seja NAS2. Ora, ambos pertencem ao mesmo domínio administrativo: ASi. Então, o tráfego não irá atravessar o Resto da Internet. Veja a ilustração na Figura 3, abaixo.

Figura 3. Trânsito menor do que o contratado.

No exemplo acima, não está ocorrendo trânsito entre NAS1 e NAS2, pois a Internet está fora do circuito, uma vez que ambos estão na rede de AS1. Somente ocorre transporte de dados (nesse caso, os bits que representam a mensagem) entre NAS1 e NAS2. Nesse exemplo, o agente do transporte é ASi. Portanto, a nossa definição de transporte é bem simples: transporte é o tráfego onde não ocorre acesso à Internet. Nesse ponto e, sob a ótica do NAS1 e seu fornecedor de trânsito, podemos concluir que tráfego não é somente igual a trânsito, como indicava nossa primeira equação (\textbf{T = t} _ \textbf{n}). Tráfego é a soma do trânsito e do transporte. Geralmente, o transporte entre os NASes, é feito sem conhecimento das partes envolvidas e, sim por pura iniciativa do AS que fornece o trânsito para as partes envolvidas. O interesse, claro é reduzir o custo de tráfego de trânsito. Denotaremos tráfego de transporte, quando conhecido pela parte interessada, por \textbf{t} _ \textbf{r} e o tráfego de transporte não conhecido por todas as partes por \textbf{t} _ \textbf{i} (indicando tráfego interno). Assim, a equação de tráfego, nesse ponto será:

\textbf{T } = \textbf{ t} _ \textbf{n } + \textbf{ t} _ \textbf{i } + \textbf{ t} _ \textbf{r}

Se \textbf{t} _ \textbf{i} não é conhecido, por alguma das partes, então \textbf{t} _ \textbf{i } = \textbf{ 0} e, o seu valor real estará adicionado a \textbf{t} _ \textbf{r}. O AS que fornece trânsito quer maximizar!

Alterando o caminho do tráfego

Se somente uma mensagem for levada em conta, o valor do transporte \textbf{t} _ \textbf{r} (medido em bps – capacidade do enlace ou velocidade do enlace) é irrelevante (sob o ponto de vista de ASi, pelo menos). De qualquer forma, \textbf{t} _ \textbf{n } > \textbf{ t} _ \textbf{r}. Mas suponha que ASi tenha uma razoável quantidade de NASes em sua rede, geograficamente próximos, por exemplo, em uma mesma cidade ou município. Nesse município, existem alguns hospedeiros de dados ou de servidores. A demanda de \textbf{t} _ \textbf{r}, digamos passou a ser significativamente representativa, por exemplo, 30% do trânsito contratado por AS1, que como empresa de negócios, reduziu sua demanda com os fornecedores de enlaces para a Internet (outros ASes). É a escolha certa e AS1 tem todas as facilidades para fazer as contas. Mas os NASes, também podem chegar a tais conclusões avaliando questões semelhantes. . E, provavelmente começam a levar a sério as indicações de que interconexões locais podem trazer uma economia no trânsito. Das diversas alternativas disponíveis duas são levadas em consideração: (a) interconexões diretas e (b) o estabelecimento de um PTT.

Das duas alternativas acima, o PTT é a melhor escolha. A criação do PTT implica em uma cooperação direta entre os interessados produzindo tráfego sem custo, pois todas as partes estão interessadas. Tais acordos de tráfego sem custo, se fazem de forma bilateral (quando dois NASes estão particularmente interessados) ou multilateralmente (quando mais de dois NASes são partes interessadas). É nesse momento que NASes se transformam em ASes, pois a topologia de um PTT exige que seus membros sejam sistemas autônomos. O PTT trás uma outra vantagem que são as adesões de outros ASes que também irão participar do tráfego sem custo. Esse tráfego sem custo é o que chamaremos de tráfego de peering. Apesar de tradicionalmente o tráfego de peering existir, em sua maioria nos PTTs, é possível fazer tráfego de peering fora dos PTTs tanto bilateralmente como multilateralmente.

Equação final do tráfego

Se denotarmos o tráfego de peering por t_p a equação final que define o tráfego ficará da seguinte forma, medida em bps:

T = t_n + t_i + t_r + t_p \text{, para } t_n \geq 0\text{, } t_r \geq 0\text{, } t_i \geq 0\text{, e } t_p \geq 0

Uma mudança na unidade de medida, de bps para moeda (p. ex.: R$), a seguinte equação, representa o custo do tráfego digamos, por Mbps:

C_T = C_{tn} + C_{tr} + C_{ti} + C_{tp} \text{, para } \forall C_{tn}\text{, } \forall C_{tr}\text{, } \forall C_{ti}\text{, } \forall C_{tp} \in \mathbf{R}

O significado das representações na fórmula acima, fica como exercício. Veja mais sobre a economia em PTTs na referência [3], onde há uma interessante analogia com bananas.

Referências

[1] Packet Clearing House Report on
Internet Exchange Point Locations.

[2] The 32-bit AS Number Report.
[3] Bill Woodcock, The Economic Significance of
Internet Exchange Points.
, July 2007.
[4] Nic.br, Novas localidades para PTTMetro. Acessado em 28/10/2010.

%d blogueiros gostam disto: