Arquivo

Posts Tagged ‘bgp’

Objetos de Projeto Estendidos (OPE)

When knowledge is involved,
it is best to bring the Internet to the user,
instead of taking the user to Internet.

 

Uma dificuldade na Infraestrutura da Internet

 

Em tudo o que tem sido escrito sobre BGP neste blogue há sempre uma observação persistente: BGP é complexo. Na realidade, a complexidade do BGP está na sua abrangência e sua perspectiva de mudar constantemente. Mas, há outro componente importante quando se deseja implementar o BGP em roteadores de borda: a topologia.

Vamos a um exemplo. Recentemente, um Provedor consultou-me sobre uma topologia com três (3) trânsitos: dois com uma operadora A e um terceiro com a operadora B. A topologia parecia ser a mostrada na Figura 1, abaixo.

 

Figura 1. Três trânsitos sendo dois com a mesma operadora.

 

Este texto não propõe a implementação da topologia acima, com o BGP. Ele trata de outro assunto, correlato. Entretanto, vou dar algumas dicas sobre a implementação. Até aquele momento, nunca tinha passado por experiência semelhante. Ao entrar no roteador do Provedor foi curioso observar o fato de que a operadora A recomendou que se estabelecesse dois empareamentos com cada um de seus enlaces de trânsito: um com a tabela de roteamento completa e outro com tabela de roteamento parcial. Incluindo o empareamento da Operadora B haviam cinco sessões BGP ativas. O roteador estava em produção e alguns comportamentos ruins eram incompreensíveis. A primeira visão da implementação, sempre segue o instinto (da suposta experiência): (a) a Operadora A entende mais do que qualquer um e, (b) um ajuste nos filtros poderia resolver o comportamento ruim (abstraindo-se do fato do BGP ser complexo). Duas premissas completamente equivocadas. Revendo a presunção inicial, observou-se que, na realidade havia uma novidade na topologia: dois trânsitos com a mesma operadora. Google, eis a saída! Nesta hora é que você vê como o Google cansa!!! Depois de algum tempo, a luz no final do túnel veio com a RFC22701. Esta RFC, de 1998 é um pouco confusa, pois trata de topologias bem mais simples sem as variações possíveis do futuro atual. Por exemplo, a topologia poderia não ser a da Figura 1, exatamente. Em outras palavras, o trânsito poderia estar vindo através de um único roteador da Operadora A, ou chegando em uma única porta do roteador do Provedor. Ou ainda, alguma outra variação do tema. No Google, eficaz sintáticamente, infelizmente não consegue interpretar a semântica, ainda. Quem propõe a solução para implementar BGP em uma topologia destas é o primeiro autor da RFC2270, J. Stewart. No romance do BGP, escrito por ele2, Capítulo 3 há uma completa descrição de todos os comportamentos do BGP em casos como estes, incluindo balanceamento. Em particular, a Fig. 3.2, na página 78, Stewart explica em detalhes um multi-homed com uma mesma operadora, de forma didática!

Mas o erro mais grave da dúvida produzida pela topologia da Figura 1 é que, ao lidarmos com o BGP associado a uma topologia qualquer, não é por hábito fazer um projeto, minimamente cuidadoso, que permita o entendimento do comportamento esperado. Em outras palavras, não se pensa sobre o problema. Isto tem acontecido sistematicamente com os pequenos e médios provedores. Por outro lado, observa-se que a falta de pensar e/ou a falta de projeto são recorrentes, mesmo tendo do seu lado as grandes operadoras brasileiras. A Operadora A da Figura 1 é uma enorme de uma operadora. Por outro lado, o Google demorou demais em ajudar a encontrar uma saída.

 

Uma dificuldade em outras áreas de projetos

 

Há alguns meses atrás fiquei dependendo de uma informação relacionada com seguradoras que estariam dispostas a segurar riscos fortuitos. Suponha que você tenha um projeto cujo objetivo é a realização de um evento em uma determinada localidade. Um evento de grande porte, com um orçamento considerável. Imagine que na véspera do evento aconteça (digamos, uns 3 dias antes), uma tempestade de enormes proporções, que arrase a cidade e cause danos materiais irreversíveis (neste exemplo, não há perdas de vida, felizmente), causando uma perda total do evento. Qual seguradora seria capaz de segurar a perspectiva de uma perda destas? Procurei, procurei, googlei, telefonei, mandei e-mails e não consegui uma resposta. Finalmente entrei no Linkedin e coloquei uma pergunta relacionada, em um grupo de projetos. Houve um debate muito interessante, até que alguém passou o nome de uma seguradora que bancou um risco semelhante, na cidade de New Orleans e acabou pagando o prejuízo causado a um projeto semelhante que iria acontecer por lá. Desta forma, a dúvida e a ausência do seguro foram resolvidas.

Para uma equipe de projetos, a indisponibilidade de competências para descrever, detalhar ou desenvolver partes do projeto (ou mesmo o projeto completo) é a principal motivação para recorrer a opiniões especializadas.

 

Perdas de tempo em projetos

 

No primeiro exemplo, do BGP e topologias, o problema maior é a falta de pensar, com certa antecedência sobre a implementação de um trânsito com a Internet. Mas, esta questão, com a maturidade será resolvida e em breve teremos projetos sendo desenvolvidos para preparar devidamente os roteadores de borda ou até mesmo as redes internas que estão se tornando, também, complexas. Mesmo que sejam pequenos Sistemas Autônomos. Neste momento, o administrador (ou preposto) de um Sistema Autônomo passa a ser um gerente de projetos.

No segundo exemplo, a questão de segurar perdas fortuitas foi resolvida por um membro de um projeto completamente dissociado do meu projeto. Por acaso expor a dúvida em um grupo de alto nível do Linkedin foi um sucesso, embora a iniciativa tenha demorado um pouco para ser tomada.

Geralmente, dentro de uma mesma empresa, obter informações úteis ou fundamentais para projetos não levam muito tempo, porque há sempre disponível o chamado “golden book”, que vai acumulando informações úteis a cada término de um projeto. Entretanto, intergrupos desconexos de projetos, isto não acontece. Um provedor, dificilmente troca informações com outros Provedores. Não por considerarem as informações preciosas ou de valor competitivo, mas por falta de oportunidades ou de local adequado para fazê-los. Geralmente, as informações são trocadas quando alguém, em uma lista de e-mail ou fórum apropriados provoca a questão. Não é, portanto, usual alguém colocar em algum fórum ou lista, por livre e espontânea vontade: “o problema do multi-homed para um mesmo operador de trânsito resolve-se assim e assado…”. Da mesma forma, porque um membro ou gerente de projeto iria divulgar o nome de uma seguradora de riscos fortuitos, se não há um ambiente apropriado para fazê-lo?

 

Objetos de Projeto Estendidos

 

Se houvesse um ambiente apropriado, seguro, confiável e com um mecanismo de pesquisa mais “inteligente”, do que os disponíveis atualmente, a cooperação fluiria espontâneamente. Por várias razões, algumas relacionadas abaixo:

  • Pelo natural espírito de cooperação do ser humano, interessado e consciente.
  • Pela garantia de autoria da informação.
  • Pela perspectiva de auxiliar no crescimento de um repositório de sabedoria útil para projetos, em geral, do qual todos se beneficiarão.
  • Pela rapidez de acesso à informação.
  • Pela possibilidade de manter informações pessoais e privativas.
  • Pela garantia de intervir no ambiente garantindo a qualidade da informação.
  • Pela existência de mecanismos de pesquisa semântica, mais próximos do pensamento humano.

 

A disponibilidade de informações (textos, gráficos, imagens, videos, etc.), tratadas neste documento são armazenadas no que se convencionou chamar Objetos de Projeto Estendido (OPE). Existem dois tipos de OPEs: público e privado. Um OPE é público se ele pode ser compartilhado com terceiros. Um OPE é privado se ele não puder ser compartilhado com terceiros. Os OPEs são agrupados (ou armazenados) em um ambiente chamado de ROPE (Repositório de Objetos de Projeto Estendidos). Existem inúmeros ROPEs, cada um deles hospedados no computador do usuário interessado (o “dono” do ROPE). Um ROPE, possui uma interface humano-computador que, de forma independente classifica, pesquisa e visualiza os OPEs armazenados, além de permitir operações de criação/inclusão e demais atividades necessárias ao tratamento de um OPE isoladamente ou em conjunto. OPEs podem ser enviados ou recebidos de um Sistema de Gerenciamento de Projetos (SGP), através de uma interface apropriada que funcionaria da forma representada na Figura 2.

 

Figura 2. OPE e o Sistema de Gerenciamento de Projetos

 

Se o SGP possuir as facilidades adequadas, os recursos de WEB Semântica serão utilizados, mais apropriadamente, ontologias7 e as propostas da W3C relacionadas com a OWL (Web Ontologoy Language)6. Em futuro próximo, outro artigo abordará este tema, em detalhes, oportunidade em que será mostrado que ontologias podem ser transformadas em XML e vice-versa, aperfeiçoando a proposta da Figura 2. Uma ótima e rápida leitura pode ser encontrada no artigo da Scientific American8 e com maior profundidade, um texto clássico e completo em [9].

Cada OPE possui uma medida de aceitação, denominada assimetria e pode sofrer alterações por terceiros, no sentido de aprovar, reprovar ou identificar a relevância. Assimetria é uma medida de qualidade de um OPE. Por outro lado, o conteúdo de um OPE pode, também, sofrer alterações. Neste caso, o repositório manterá um histórico de tais alterações, desde o OPE original até o atual, incluindo cada uma das contribuições efetivamente aceitas, aprovadas ou reprovadas, e relacionadas com o OPE. A técnica usada para que este procedimento ocorra adequadamente é a procedência de dados, a qual garante que um OPE conterá a descrição de “como”, “quando”, “onde”, “porque” os dados foram obtidos e “quem” os obteve. Cada um dos componentes históricos de uma OPE, caracterizado pela procedência de dados, também tem o sua respectiva assimetria associada, que representa uma medida de aprovação/reprovação e relevância da nova alteração OPE. Por outro lado, a informação oferecida em um OPE pode ou não ter um valor financeiro para que ela se torne visível.

A contribuição da procedência de dados foi obtida da interessante experiência sobre imagens, proposta por Braga4. A noção de assimetria tem sido experimentada e abordada neste blogue em diversas oportunidades, como medida representativa de distorções sociais, de pessoas, entre outras.

 

Caracterizando o tratamento do ROPE

 

A Figura 3 é um esboço preliminar de um diagrama (que parece, mas não é uma diagrama de caso de uso!), caracterizando os pontos mais importantes. Na sequência uma abordagem, também preliminar, sobre o escopo do sistema. A formalização definitiva dependerá de alguns componentes ainda pendentes no âmbito acadêmico em que o autor está atualmente engajado.

 

Figura 3. Diagrama preliminar do sistema de tratamento do ROPE (Fonte: autor).

 

Os desafios de pesquisa avaliados a partir da abstração exposta na Figura 3, são:

  1. A medida de assimetria e as intervenções históricas (procedência) sobre um OPE exigem autenticação do usuário, a qual irá configurar sua validação. Também, a assimetria poderá indicar a permanência ou não de um OPE no repositório distribuído ou no repositório local, sem que haja intervenção humana direta, com base em critérios pré-definidos.
  2. O ROPE deverá estar disponível na Internet, da forma descrita em (c). A disponibilidade de um ROPE é ativa ou passiva. Uma disponibilidade é ativa, se o ROPE está hospedado em um IP público (IPv4 e/ou IPv6), e a disponibilidade é passiva se o IPv4 e/ou IPv6, no qual ele se hospeda é privado (não está visível na Internet). IPv6 é a alternativa preferencial.
  3. Não pode haver um sistema central, característica do paradigma cliente/servidor. Apesar de este paradigma criar uma imensa facilidade para o usuário, uma vez que o acesso poderia ser feito por qualquer navegador (cliente da WEB), ele traria um componente de custo que poderia inviabilizar sua implementação ou mesmo exigir um patrocínio, para garantir servidores e seus respectivos sistemas de segurança associados. Além do mais, tal alternativa afrontaria o princípio do domínio local.
  4. Os mecanismos de pesquisa e acesso ao ROPE que é, na verdade, uma base de conhecimento deve seguir as recomendações propostas nos padrões W3C e em técnicas derivadas.
  5. A quebra do paradigma cliente/servidor exige um mecanismo que permita que os ROPEs sejam distribuídos, isto é, sejam hospedados nas máquinas de cada usuário interessado. Tal predisposição leva às seguintes preocupações:
    1. Fácil implementação e uso de linguagem universal independente do sistema operacional utilizado pelo usuário. Preferencialmente em código objeto com versão bem definida onde, o sistema operacional é uma completa abstração.
    2. Cada ROPE deve ter uma identificação única sempre associada a seu usuário. Está identificação será um número de 32 bits permitindo até 4.294.967.296 repositórios diferentes. Tal identificação pode ser obtida através de qualquer repositório ativo (sempre o mais próximo do usuário, preferencialmente).
    3. Disponibilidade de mecanismo que permita atualização do(s) procedimento(s) associado(s) à operação local do ROPE. Por exemplo, o código objeto dito em (i).
    4. Atualização do repositório de OPE, em tempo real, que não poderá usar qualquer SGBD (Sistema de Gerenciamento de Base de Dados). O uso de um SGDB implicaria em complexidade adicional à implementação. Tal imposição leva à criação de representações de arquivos (incorporando XML, RDF, …) sob uma estrutura de diretórios locais, em texto ou outro formato, bem como qualquer outro tipo de informação (como por exemplo, aquelas necessárias ao mecanismo de autenticação).
    5. O projeto deve prever a ubiquidade, e usar recursos pervasivos.
    6. As propriedades ubíquas e pervasivas implicam na necessidade de mecanismo de cooperação entre os ROPEs disponíveis. A propriedade pervasiva somente poderá ocorrer em ROPEs ativos. Neste caso, o proprietário do ROPE pode autorizar ou não, terceiros usarem seu repositório para atender tal demanda.
    7. Por fim, um ROPE deve ser autônomo, com todas as facilidades e demandas disponíveis localmente.
  6. Mecanismos de criptografia adequados e transparentes aos usuários para garantir a segurança a todos os requisitos exigidos.
  7. O OPE deve ser caracterizado, também, pela sua aplicação às recomendações do PMBOK5, suas seções e capítulos. Consequentemente, deverá atualizar as características recomendadas pelas novas versões de padronizações propostas pelo PMI. Na hipótese de ocorrerem mudanças fundamentais na estrutura do PMBOK de referência, o OPE deverá manter histórico referencial.
  8. Os ROPEs devem ser identificados com garantia de autonomia. O mecanismo de cooperação (item d, subitem v), deve propagar tais informações para outros repositórios. A princípio, o mecanismo de propagação seguirá um esquema conhecido por empareamento (peering). Em outras palavras, um repositório OPE tem um ou mais empareados (peers).
  9. Cada empareado age ativamente (e de forma autônoma), no sentido de atualizar seus ROPEs, das seguintes maneiras:
    1. Cada ROPE está disposto a receber e enviar atualizações de um ou mais empareados, quando seu hospedeiro for ativo (item b);
    2. Um ROPE busca e envia atualizações em um ou mais empareados, previamente conhecidos, quando seu hospedeiro for passivo (item b).
  10. ROPEs empareados possuem um protocolo de relacionamento que permita a troca segura de informações. Tal protocolo é caracterizado por um autômato finito e seguirá os exemplos mais eficazes e simples, disponíveis na literatura.
  11. Um ROPE empareado que tenha sofrido uma alteração comunica-se com todos os seus empareados conhecidos com o objetivo de atualizá-los.
  12. Um OPE pode ter um custo associado à informação que ele está disponibilizando. Baseado na descrição objetiva do conteúdo do OPE pode-se decidir pelo pagamento com regras bem estabelecidas, inclusive uso de cartões de crédito. Neste caso, um mecanismo de pagamento deverá estar disponível para acesso imediato via o próprio OPE. A previsão de mecanismos de segurança descritas no item (e) torna factível esta proposição.

Vale lembrar, que o BGP é uma implementação que quebra o paradigma cliente/servidor (o que não é uma novidade), e usa a Internet para criar os ambientes de redes autônomas. Aliás, melhor seria afirmar que as implementações de BGP constroem a Internet.

Ademais, não é uma proposta de um sistema de relacionamento. Os ROPEs não possuem a identificação de seus proprietários, muito embora os OPEs e seus históricos, sim. Neste último caso, se o autor do OPE ou histórico, assim o desejar. Isto não configura o anonimato pois só se pode criar ou alterar um OPE se existir um proprietário de ROPE bem identificado.

Com referência à metodologia há fortes indícios que levam às recomendações propostas por Eeles e Crips3.

 

Observações finais

 

O trabalho deve ser desenvolvido em três etapas, a saber:

  1. Definição do problema: é a etapa em que o refinamento do texto acima irá acontecer, com a especificação do mecanismo de bases de dados distribuídas, as relações ubíqua e pervasiva. Formalização do esquema de mensagens e o autômato finito das conexões dos repositórios entre si. Adicionalmente, a especificação do modelo da base da dados do ROPE, através de uma metalinguagem.
  2. A descrição geral do sistema e suas relações com o PMBOK: etapa que irá descrever todo o sistema, com os detalhes das especificações e os componentes teóricos envolvidos. Os mecanismos de arbitragem das medidas de aceitação (assimetrias). Os tipos de OPEs possíveis e seus formatos relacionados com a estrutura do PMBOK. A proposta da linguagem de programação com base em comparações específicas.
  3. A evolução: propostas de estudos e pesquisas que possam viabilizar a implementação, testes de protótipos e fortalecimento de fragilidades a serem identificadas. Esta etapa está fora do escopo da proposta de trabalho inicial, que representam os itens (1) e (2), acima.

Referências

 

  1. RFC2270, Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart, T. Bates, R. Chandra, E. Chen [ January 1998 ] (TXT = 12063) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr)
  2. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
  3. Peter Eeles e Peter Cripps. (2012, Second Printing). The process of software architecting. Addison-Wesley.
  4. Juliana Cristina Braga. Procedência de Dados: Teoria e Aplicações ao Processamento de Imagens. 2004. 110 f. Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada. INPE, São José dos Campos, 2007.
  5. PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK), 4a. edição, 2008
  6. W3C. OWL Web Ontology Language Guide. W3C Recommendation 10 February 2004. Disponível em: http://www.w3.org/TR/owl-guide/. Acessado em 16/12/2012.
  7. NOY, N.; MCGUINNESS, D. Ontology development 101: A guide to creating your first ontology, 2001. Disponivel em: http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What is an ontology and why we need it.htm. Acessado em 20/12/2012.
  8. BERNERS-LEE, T. I. M.; HENDLER, J.; LASSILA, O. R. A. The Semantic Web will enable machines to. Scientific American, n. May, p. 1-4, 2001. Disponível em http://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20American_%20Feature%20Article_%20The%20Semantic%20Web_%20May%202001.pdf
  9. TRUSZKOWSKI, W.; BREITMANN, K. K.; CASANOVA, M. A. Semantic Web: Concepts, Technologies and Applications. [S.l.] Springer-Verlag, 2007.

 

Na sequência: Máquinas de estado finito: Parte Prática: MEF do BGP

Anúncios

Laboratório virtual de roteamento – LVR (I)

Atualizado em: 30/01/2011.

Introdução

Ultimamente tenho gasto meu tempo no aperfeiçoamento do meu conhecimento na RPSL (com foco no Abranet IRR, [1]) e na construção da infraestrutura de rede da minha empresa. São dois projetos muito interessantes, que exigem uma enorme dedicação.

O Abranet IRR já possui uma equipe muito boa e breve teremos novidades. Acho que esse projeto da Abranet, que não é exclusivamente o IRR trará muitos benefícios para os administradores de ASes brasileiros. É um projeto de médio/longo prazos, com uma característica de neutralidade que somente uma instituição como a Abranet poderia proporcionar.

Dos trabalhos relacionados com a demanda da empresa, onde um conceito renovado de Voz sobre IP está sendo implementado chegam os principais desafios. São vários e, principalmente na parte relacionada com BGP, PTTs, túneis MPLSs e infraestrutura da Internet reside o mais apaixonante interesse do autor, eterno aprendiz em roteamento. Provavelmente, todos nós somos.

Um dos maiores problemas que tenho encontrado está no exercício de uma determinada teoria em relação ao que se está planejando. Geralmente o exercício está ligado em como fazer ou, como aplicar nos equipamentos disponíveis. A falta de padrão e a tentativa de estabelecer como padrão, equipamentos da Cisco aumenta mais ainda a dificultade e esforço. Esse esforço é redobrado quando, uma vez entendido a teoria tenta-se ir à prática.

Com tais preocupações em mente ao estudar um excelente curso, em [2], imaginei a hipótese de construir um laboratório apropriado para testar e aprender o que se precisa. Essa hipótese já tinha sido pensada, logo após o treinamento de IPv6, no Nic.br, [3]. Quem teve essa oportunidade sabe muito bem o quão bem elaborado foi o esforço do Antônio Moreiras (responsável pelo treinamento IPv6, do Nic.br). O laboratório engendrado para o treinamento é algo muito interessante. Invejável e perfeito. Sei que houve uma equipe envolvida na construção desse laboratório de IPv6, na qual o Eduardo Ascenço teve participação significativa, entre muitos outros.

Resolvi então, montar um laboratório pessoal, que chamei de Laboratório Virtual de Roteamento (LVR). O modelo desse laboratório deveria ter as seguintes características:

  • Ser ilimitadamente escalável: tanto sob o ponto de vista do crescimento físico, como do crescimento lógico. Escalabilidade lógica implica na possibilidade de ampliar o exercício para a prática. Por exemplo, o laboratório poderia se conectar a um PTT. Nunca houve a pretensão de fazer algo como o projeto GENI, [4], mas o GENI sempre esteve no foco.
  • Flexível: permitir a inclusão de novos recursos e facilidades. Há aqui, no escritório, diversos roteadores que eventualmente pudesse ser interconectados ao projeto para permitir experiências práticas.
  • Mobilidade: o projeto deve permitir acesso remoto ou acompanhar as viagens pessoais.
  • Ser barato! Sem comentários.

Foi então, que ao terminar o treinamento [2], a base do LVR foi estabelecida. Nesse texto e nos outros que virão pretende-se contar as experiências.

O modelo do LVR

A idéia inicial foi feita sobre 7 (sete) servidores Mikrotiks (MKs), implementados em máquinas virtuais, em um notebook. Usando o esquema simples de roteamento estático, o que foi feito está na figura 1, abaixo. Na figura está um modelo de representar a Internet concebido em [5], onde os ASes estão representados em laranja e PTTs em verde. Vem a calhar, tal representação, para o que iremos falar no futuro.

Figura 1. Modelo original do LVR, baseado em rede local.

A implementação de rotas estáticas permitiu experimentar o resultado. Tendo sido positivo, a preocupação agora era criar uma topologia que permitisse transformações de forma, sem dificuldade. Então, abstraiu-se das rotas estáticas influenciadas pela rede onde o notebook estava. Em outras palavras, a conectividade foi estabelecida e a figura 2 mostra que a pretensão era uma abstração dessa conectividade para se pensar em outra.

Figura 2. Abstraindo-se das interconexões.

Cada Mikrotik do LVR está identificado como MKn, para n de 0 a 7. O MK0 não é virtual. É um gateway com acesso à Internet. A versalidade do Mikrotik é incrível! Por isso ele foi preferido, inicialmente. Mas, a possibilidade de uma máquina virtual, não limita nenhuma possibilidade, tais como Quagga, Bird [5] e outros. Um hospedeiro poderoso permite asas à imaginação.

Iniciou-se a implementação de VLANs, para ligar os MKn. Na medida quem que as VLANs foram criadas, pode-se, finalmente, abstrair-se das rotas estáticas originais. Só abstração. Elas não foram retiradas, com o objetivo de manter a conectividade. Mas, podem ser ignoradas, já que não participam como “gateway” em cada MKn. A figura 3 exibe a primeira VLAN.

Figura 3. Construindo as VLANs.

Em seguida, os outros MKs tiveram suas VLANs estabelecidas, conforme mostra as figuras que seguem. Note-se a numeração das VLANs. Por exemplo, a VLAN que conecta o MK0 ao MK1, tem o número 10. O mesmo acontece com os IPs definidos para as VLANs. Sempre são 10.1.n.0/30, onde n é o número da VLAN. Isso obrigou uma rota estática do 10.1.0.0/17 para os vizinhos. Tudo para facilitar a implementação.

Próximas atividades

Eis alguma das próximas atividades sobre o LVR:

  • IPv6: nesse caso pode-se até mesmo viabilizar os MK virtuais, quando da implementação do BGP.
  • Seguir a proposta do Greg: RIP, OSPF, eBGP e iBGP
  • Novas topologias para que se possa fazer experiências.
  • Manter as experiências descritas sumariamente aqui nesse blogue e em detalhes, na Base de Conhecimento da Abranet.
  • Estimular a criação de outros LVRs para troca de experiências e interconexões. O LVR acima tem a identificação LVR28182.
  • Em 7 de novembro de 2010 resolvi trocar o nome do LVR para, Fábrica Fictícia de Encaminhamento (FFE ou 1111 1111 1110).

E o notebook, com estas 7 máquinas virtuais? Nem piou!

Referências

[1]. Abranet IRR.
[2]. Greg Sowell, Routing. Vídeo disponível aqui. Acessado em 02/11/2010.
[3]. Curso IPv6 Básico (Presencial). Nic.br, CEPTRO.br, IPv6.br. Material disponível aqui. Acessado em 02/11/2010.
[4]. Projeto GENI. Acessado em 02/11/2010.
[5]. Julião Braga, Tráfego, trânsito, transporte e peering (uma proposta de definição). Março 9, 2010, Disponível aqui. Acessado em 02/11/2010.
[5]. BIRD. Acessado em 02/11/2010.

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: