Grupos de Trabalho - Documento GT-ER

Operação e Administração de PTTs no Brasil
Comitê Gestor da Internet no Brasil no Brasil
Grupo de Trabalho de Engenharia e Operação de Redes
Reinaldo Penno Filho

NortelNetworks
Universidade Federal do Rio de Janeiro
janeiro 2000

Objetivo deste Documento

Este documento é um informativo para a comunidade da Internet do Brasil. A distribuição deste documento é ilimitada.

Resumo

Este documento visa apresentar uma recomendação para a operação e administração de PTTs no Brasil. Ele foi feito baseado nas melhores políticas de administração e operação de PTTs ao redor do mundo. Nele são abordados e recomendados diversos temas como endereçamento, anúncio de rotas e segurança com a finalidade de assegurar um política técnica mínima de qualidade na operação e administração de PTTs no Brasil.

Sumário

1. Introdução
2. Conectividade

3. Troca de Tráfego:  acordos bilaterais e acordos múltiplos
4. Endereçamento
          4.1 IP

          4.2 VPI/VCI
5. Servidores de Roteamento
6. Anúncio de Rotas
          6.1 Recomendações de Eficiência
7. Práticas Gerais de Eficiência para Acordos de Tráfego Bilaterais
8. Velocidade de Acesso
9. Lista de Discussão
10. Registro de Domínio Reverso
11. Equipamento dos Participantes
12. Preço
13. Considerações Gerais
14. Considerações de Segurança
15. Referências


1. Introdução

Um PTT Internet é definido como uma rede ou comutador de alta velocidade a que um número de redes pode se conectar através de roteadores, com o propósito de trocar tráfego ou interoperar [NSF 93-52]. A operação e administração de um PTT é uma atividade que demanda muita organização e planejamento. Desde a primeira solicitação para instalação de PTTs nos EUA feita pela NSF (National Science Foundation) em 1993 [NSF 93-52], muitos erros e acertos foram cometidos na operação de PTTs ao longo do tempo. Este documento sintetiza as melhores políticas de administração e operação utilizadas por PTTs no EUA, Europa e Ásia de modo a minorar os problemas que podem acontecer e estabelecer uma recomendação mínima, que assegure uma boa performance técnica e segurança a todos os participantes de um PTT no Brasil.


2. Conectividade

Os candidatos ao PTT devem ter sua própria conexão permanente com a Intenet (Internacional ou através de um backbone). As insituições que desejarem se conectar ao PTT devem mostrar que possuem caminhos de um endereço IP dentro do Autonomous System (AS) que será apresentado para PTT, para 4 servidores de nomes raiz (hosts no domínio 'root-servers.net'). O prefixo de rota, incluindo este endereço, devem ser visíveis como originando deste AS em qualquer roteador Internet que contenha todo o conjunto de rotas globais.


3. Troca de Tráfego: acordos bilaterais e acordos múltiplos

Todos os participantes devem formar acordos bilaterais ou mútiplos com outras redes conectadas ao PTT. É altamente recomendado que o processo de estabelecimento de acordos de tráfego entre as redes seja começado antes da conexão física propriamente dita.

Muitos participantes do PTT fazem parte do acordo de tráfego múltiplo (ATM), que facilita a interconexão para a troca de tráfego. O ATM é um documento desenvolvido para facilitar a troca de tráfego entre as redes conectadas a um PTT. Quando um participante concorda com os termos do ATM, ele está concordando formar e suportar acordos de tráfego com todos os outros participantes do ATM no PTT. Sabendo que nem todos os participantes do PTT são membros do ATM, acordos bilateriais devem ser formados com estas redes. É exigido que para entrar e permancecer no PTT que o membro tenha pelo menos dois acordos de tráfego bilaterais ou faça parte do ATM.

Vale portanto ressaltar que uma instituição que participa do ATM não é obrigada a prover trânsito para outras insituições participantes do ATM como também a anunciar rotas obtidas através de seus acordos bilaterais para os participantes do ATM.

Os membros devem publicar o contato para o qual requisições de peering devem ser enviadas.

Os membros devem responder a uma requisição de peering de um membro novo potencial dentro de dois dias úteis a partir do dia da requisição.


4. Endereçamento

Não é recomendado que o PTT aloque endereços IP para os participantes. Os participantes devem conseguir endereços IP através de outros meios. Entretanto, caso escolha fazê-lo, o item 2.1 deve ser seguido.

4.1 IP

É recomendado que seja provisionado um formulário web para a requisição de endereços IP. Além disso, é também recomendado que a lista de endereços IP atualmente alocados e seus respectivos nomes de domínio estejam disponíveis através da web. Como o operador do PTT será responsável pela administração do DNS reverso, uma outra alternativa para conseguir a lista de endereços IP alocados é consultar o arquivo de zona IN-ADDR.ARPA do domínio utilizado para o PTT.

4.2 VPI/VCI

Participantes do PPT que usarem circuitos virtuais permanentes (PVCs) para trocar tráfego e fazem parte do ATM serão incluídos na malha que cobre todo o PTT (full mesh). O operador do PTT cria sempre uma malha total entre um novo participante e os outros membros existentes. Em qualquer momento um participante pode requisitar que qualquer de seus PVCs seja removido para proibir a troca de tráfego com determinado participante.

Cada ponto final do PVC tem um VPI/VCI único associado . Todos os participantes do PTT terão um VPI/VCI designado pelo operador do PTT. Quando um PVC interconectando dois participantes é estabelecido, o VPI/VCI utilizado em cada extremo está associado ao participante na outra ponta do PVC. O operador do PTT pode disconectar qualquer participante que estiver colocando em risco a operação confiável do PTT maliciosamente ou acidentalmente, e contactará em seguida as redes envolvidas.

5. Servidores de Roteamento

Os servidores de roteamento são computadores executando um software que realiza as funções de troca e processamento de rotas. Os servidores de roteamento (SR) facilitam a troca de rotas entre os participantes do PTT através da coleta de informações de roteamento, processamento dessa informação baseada na política de roteamento do participante e distribuição das rotas processadas para cada um dos roteadores. Os SR usam BGP-4 como o protocolo de roteamento inter-dominio para trocar informações de roteamento com os roteadores das redes conectadas ao PTT.

Os SR não roteiam pacotes entre as redes conectadas ao PTT. Ao invés disso, eles usam a capacidade que o protocolo BGP tem de distribuir rotas através de um roteador intermediário para passar informações de roteamento de uma rede para outra, com o próximo destino (next hop) apontando para o roteador que anunciou a rota para o SR. O tráfego é portanto trocado diretamente entre os roteadores das redes participantes, apesar do SR prover as informações de rotas. Um grande benefício do uso de SR é a redução do número de sessões BGP que os roteadores do NAP tem que manter. É recomendado que os PTTs tenham pelo menos um SR servindo os participantes conectados. Informações adicionais sobre o software usado pelos servidores de roteamento e o projeto Routing Arbiter podem ser obtidos em [Ra].

6. Anúncio de Rotas

Esse item e seu subitem só se aplicam àqueles participantes que fizerem parte do ATM.

É importante que os participantes anunciem somente prefixos de roteamento com um comprimento máximo de 24 bits. A troca de rotas deve ser feita utilizando o protocolo BGP4. A sintaxe da política de roteamento daqueles que fazem parte do ATM deve seguir a recomendação RIPE 181 [RIPE] e/ou futuras recomendações do IETF. Todos os participantes que fizerem parte do ATM devem utilizar o registro de roteamento provido pelo árbitro de roteamento (RA) através de seu banco de dados. Além disso, todos os participantes do ATM devem estabelecer uma sessão com o RS provido pelo RA.

6.1 Recomendações de Eficiência
  • Não é permitido injetar informação IGP nos anúncios BGP, ou seja, não é recomendado redistribuir OSPF, RIP, entre outros, nos anúncios BGP.
  • É recomendado usar Flap Dampening [RFC 2439] entre todos os participantes.
  • Todas as rotas que contenham endereços citados na RFC 1918 devem ser filtradas
  • Os membros devem, em todas as interfaces conectadas ao PTT, desabilitar: Proxy ARP, ICMP redirects, Directed broadcasts, IEEE802 Spanning Tree, Interior routing protocol broadcasts e todos os outros broadcasts da camada de acesso (MAC), com exceção de ARP.
7. Práticas Gerais de Eficiência para Acordos de Tráfegos Bilaterais

Caso um ISP1 estabeleça um acordo de tráfego bilateral (ATB) com o ISP2 e o ISP2 por sua vez
estabeleça um (ATB) com o ISP3 alguns cuidados devem ser tomados:
  • Se o ISP2 anunciar as rotas provenientes do ISP1 para o ISP3, o ISP3 pode reescrever o
    next-hop eBGP baseado no número dos ASs. Com isso o ISP1 precisará filtrar manualmente
    tráfego proveniente do AS pertencente ao ISP3. Caso contrário o ISP3 poderá injetar tráfego
    diretamente no ISP1.
  • Caso o ISP2 anunciar as rotas provenientes do ISP1 para o ISP3 e vice-versa sem alterar o
    next-hop para seu endereço, ISP1 e ISP3 trocarão tráfego diretamente. O ISP1 pode
    manualmente reescrever todos os next-hops para o endereço do ISP2, mas isso não é
    suficiente para que o ISP2 pare de anunciar o ISP1 como next-hop do ISP3. A ultima parte do problema só pode ser resolvida com a cooperação entre ISP1 e ISP2.
8. Velocidade de Acesso

É recomendado que seja fixada uma velocidade de acesso para os participantes do ATM. Além disso, se o PTT assim desejar, uma velocidade de acesso mínima para se conectar pode ser estipulada. A velocidade de acesso mínima utilizada pelo PTT em São Paulo é de 2Mbps.


9. Lista de Discussão

É recomendado que uma lista de discussão sediada no PTT seja criada e que todos os participantes sejam inscritos. Essa lista deve ser usada para comunicados e discussões entre os participantes do PTT.


10. Registro de Domínio Reverso

As instituições ligadas ao PTT devem cadastrar o DNS reverso dos dispositivos conectados.


11. Equipamento dos Participantes

Os participantes do PTT devem se preparar para instalar seu equipamento em um rack de 19". O equipamento padrão de conexão é limitado a um roteador e modems para no máximo duas conexões externas. Todo o equipamento deve caber em 4U de altura (17.73 cm). A instalação de qualquer equipamento adicional ou maior requer um acordo prévio com o PTT.

Qualquer equipamento e/ou cabeamento instalado por um participante deve ser claramente identificado como pertencendo a este participante.

Os membros não tocarão equipamentos e/ou cabos pertencentes a outro membro e instalados no PTT ou na sala onde o PTT é sediado sem a permissão explícita do membro que é dono dos equipamentos.


12. Preço

O PTT pode, se assim desejar, cobrar taxas de manutenção de seus membros.


13. Considerações Gerais

É importante ressaltar que o PTT não provê conexão para a Internet e não garante a presença de um determinado ISP ou conectividade ao mesmo que este esteja presente.

Além disso, com o objetivo de desenvolvimento da Internet no Brasil, é recomendada a existência de PTTs nas seguintes cidades: São Paulo, Rio de Janeiro, Brasília, Belo Horizonte e Porto Alegre. Cabe observar que outras cidades podem criar, a partir do interesse dos provedores nela localizados, PTTs que sirvam as necessidades desta cidade ou região. A lista anteriormente descrita é somente a lista de cidades que, do ponto de vista de tráfego Internet, devem ter os seus PTTs ativados o mais cedo possível.

14. Considerações de Segurança

Quando um participante faz parte do ATM ele deve implementar, no mínimo, as regras de segurança ali especificadas. Já nos acordos bilaterais os participantes estão livre para implementar qualquer política de segurança, contanto que não exija modificação ou interfira na operação no PTT.

Os membros não podem instalar analisadores de tráfego (sniffers) para monitorar tráfego passando pelo PTT.


15. Referências

[Ameritech] Ameritech, Chicago NAP Homepage, https://nap.aads.net/main.html

[Benn] Benn R.S., The Great Peering Debate, https://www.clark.net/pub/rbenn/debate.html

[ICS] ICS Network Systems, Big East Nap, https://www.bigeast.net/html/big_east.html

[Digital] Digital Internet Exchange, https://www.ix.digital.com/

[ESPANIX] Punto Neutro Español de Internet, https://www.espanix.net

[Louisville] Louisville-nap, Louisville-nap.net, https://www.louisville-nap.net/

[LIX] Luxembourg Internet eXchange, https://www.lix.lu/

[LINX] London Internet Exchange, https://www.linx.net

[Manning] Exchange Point Engineering, https://www.memra.com/bofnote1.html

[NorthWest] The NorthWest Internet Exchange, https://www.structured.net/nix/

[NSF 93-52] National Science Foundation,"NETWORK ACCESS POINT MANAGER, ROUTING ARBITER, REGIONAL NETWORK PROVIDERS, AND VERY HIGH SPEED BACKBONE NETWORK SERVICE PROVIDER FOR NSFNET AND THE NREN(SM) PROGRAM ", NSF 93-52, Type : Program Guideline, NSF Org: CISE / NCR, Date : May 6, 1993

[PacBell] Pacific Bell, Pacific Bell NAPs, https://www.pacbell.com/products/business/fastrak/networking/nap/index.html

[Ra] Routing Arbiter, Routing Arbiter Project, https://www.ra.net

[RFC 1918] Address Allocation for Private Internets. Y. Rekther, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996.

[RFC 2439] BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998.

[RIPE] IETF RFC 1786, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", march 1995

[Rtd] RTD Internet Connectivity, The Tucson NAP, https://www2.rtd.com/connectivity/nap/

[Shen] Naiming Shen, Interesting Activities at the Peering Points,
https://www.nanog.org/mtg-9811/shen.html (abstract),
https://www.nanog.org/mtg-9811/ppt/shen/index.htm (slides) Nanog 14, November 8-10,
Atlanta GA

[Sprint] Sprint, Sprint Internet Services, https://www.sprint.net/

[VIX] Vienna Internet eXchange, https://www.vix.at/

[WorldCom] WorldCom, WorldCom MAE Services, https://www.mfst.com/MAE/doc/maedesc/maedesc1.html