_____________________________________________________________________________ _/_/_/_/ _/ _/ _/_/_/_/ _/ _/ _/_/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ N E W S G E N E R A T I O N ___________________________________________________________________________ 30 de junho de 1997 | Volume 1, Numero 2 ___________________________________________________________________________ --------- Editorial ------------------------------ Ari Frazao Jr. Prezados Leitores Gostariamos de iniciar este editorial falando do sucesso que foi o primeiro numero do nosso boletim, como sempre os editores fazem no segundo numero de uma publicacao lancada no mercado. Mas, nao temos como faze-lo, uma vez que, no nosso caso, nao ha' como medir o nosso desempenho em termos da tiragem obtida. No entanto, continuamos acreditando que esta e' uma iniciativa que traz consigo um grande potencial, nao so' em termos de integracao de pesso- al, mas como um veiculo de disseminacao de informacoes que sao de interesse direto a voces que sao profissionais de redes. Saibam, portanto, que a nos- sa intencao esta' muito alem do que apenas aumentar sua crise consciencia em relacao a quantidade de material que voce tem para ler. O nosso intuito e' selecionar temas e produzir artigos que digam respeito a assuntos do seu cotidiano, ou que farao parte deste num futuro proximo. Desta forma, damos continuidade a nossa publicacao com tres temas muito interessantes: IPv6, ATM e Cache de Web. O primeiro artigo traz uma discussao bem atual a cerca do novo metodo de enderecamento IP a ser im- plantado na Internet nos proximos anos. O artigo sobre a tecnologia ATM trata de responder a uma pergunta basica sobre o tema: ainda vale a pena eu investir meu tempo estudando esta tecnologia? Por fim, temos o artigo sobre Cache de Web, escrito por tecnicos do PoP-MG. Este artigo apresenta uma estrategia de distribuicao de servidores de cache pelos PoPs da RNP que promete muita economia de banda passante no nosso "backbone" e vem inaugurar o que pretendemos tornar uma constante neste boletim: a participacao ativa dos PoPs na sua confeccao. Tanto que, para tal, estamos criando um endereco para receber dos nossos leitores cri- ticas e sugestoes de temas que poderao vir a ser tratados no nosso boletim. O endereco e': editor@rnp.br. Aguardaremos sua mensagem. Uma boa noticia que gostariamos de partilhar com todos e, princi- palmente com aqueles que participaram diretamente do projeto, foi a aceita- cao do artigo "Election Project Experience" na WebNet World Conference (www.AACE.org/conf/webnet). O mesmo trata da divulgacao, via Internet, do resultado das eleicoes para prefeito e vereador das cidades com votacao eletronica. Um resumo do artigo pode ser visto em www.na-rc.rnp.br/~teresa/ elections-project.html. -------------------------- O que Vai Mudar na Sua Vida com o IPv6 -------------------------------------------------------------- Adailton J. S. Silva adailton@na-cp.rnp.br Muitas discussoes, algumas mudancas, novas caracte- risticas, novas funcionalidades, algumas controver- sias mas um alto indice de unanimidade, e pronto. Es- tava pronta a tao esperada nova versao do IP, o IP Next Generation (IPng), ou, oficialmente, o IPv6, que surgiu como uma nova tecnologia para acabar com a possivel escassez de enderecos da atual versao em uso (IPv4), para freiar o crescimento vertiginoso das ta- belas de rotas e, principalmente, para causar uma grande revolucao na Internet. Saiba por que, lendo este artigo. Introducao Com a explosao da Internet e com o surgimento constante de mais e mais servicos e aplicacoes, os atuais enderecos IP (IPv4) estao se tornando um recurso escasso. Estima-se que, em aproximadamente dois anos, eles esta- rao esgotados. Para solucionar este problema, o IPNGWG (IP Next Generation Working Group) da IETF (Internet Engineering Task Force), publicou uma se- rie de RFCs descrevendo o protocolo IPv6. As principais sao a [RFC1883] e a [RFC1884]. Historico Em Junho de 1992, acontecia um dos encontros do IAB (Internet Activities Board) em paralelo ao congresso da Internet Society. Ja' era evidente a necessidade de uma nova versao para o endereco IP. Durante o en- contro propuseram, tentaram e conseguiram convencer o IAB da adocao do CLNP (Connection-Less Network Protocol) da ISO, como sucessor do IPv4. Com um "draft" discutido e revisado, o IAB estava pronto para convencer a comuni- dade Internet, quando um precipitado anuncio em jornal causou o maior rebu- lico, e com isso os membros da comunidade se sentiram traidos. Achava-se, entao, que estavam "vendendo" a Internet para a ISO, uma "inimiga" contra a qual se tinha lutado por varios anos e que ja' estava vencida, e que o IAB nao tinha o direito de tomar essa decisao sozinho. No mesmo encontro, surgiram tres propostas. A do CLNP, que foi cha- mada de TUBA (TCP and UDP over Bigger Address). Uma denominada IP versao 7, de Robert Ullman que, em 1993, propos outra versao chamada TP/IX, refletin- do mudancas no TCP e no IP ao mesmo tempo; e, em 1994, propos uma nova ver- sao chamada CATNIP, como ensaio para compatibilidade entre enderecos IP, CLNP e IPX. A ultima proposta foi chamada de "IP in IP". Em 1993, esta proposta foi modificada e passou a se chamar IPAE (IP Address Encapsulation). O IPAE foi adotado como estrategia de transicao para o SIP (Simple IP), proposto por Steve Deering em Novembro de 1992. O SIP aumentava o endereco IP para 64 bits, tornava a fragmentacao de pacotes opcional e eliminava varios aspectos obsoletos do IP. Rapidamen- te, ganhou a adesao de varios fabricantes e cientistas. Em setembro de 1993, Paul Francis propos uma nova especificacao, o Pip (Paul's internet protocol). Fundamentado no Pip, Francis propos uma no- va estrategia de roteamento baseada em listas diretivas. Isso permitiria uma implementacao eficiente de politicas de roteamento, facilitando, inclu- sive, a implementacao de mobilidade. A uniao do SIP com o Pip foi chamada de SIPP (Simple IP Plus). Em junho de 1994, a comissao do IPng revisou todas as propostas e publicou sua recomendacao em julho de 94, sugerindo o SIPP como a base para o novo protocolo IP, mas com mudancas em algumas caracteristicas chaves da especificacao original. Particularmente, o novo protocolo teria 128 bits e se chamaria IPv6. O numero 5 havia sido alocado ao protocolo ST (stream), um protocolo experimental para suportar servicos em tempo real em paralelo com o IP. Novo Formato Uma das mais importantes caracteristicas e' o novo formato de ende- reco. O IPv6 amplia o atual endereco de 32 para 128 bits, acaba definitiva- mente com as classes de enderecos e possibilita um metodo mais simples de auto-configuracao. Ha' tres formas de representacao do endereco IPv6. A notacao mais usual e' x:x:x:x:x:x:x:x, onde os "x" sao numeros hexadecimais, ou seja, o endereco e' dividido em oito partes de 16 bits, como no seguinte exemplo: 1080:0:0:0:8:800:200C:417A Apenas 15% de todo espaco de enderecamento IPv6 esta' previamente alocado, ficando os 85% restantes para uso futuro. Devido a essa pre-aloca- cao, sera' comum enderecos com longas sequencias de bits zero. Estas se- quencias de zeros podem ser substituidas pela string "::". No entanto, esta substituicao so' pode ser feita uma unica vez em cada endereco. A tabela abaixo mostra alguns exemplos na forma completa e na forma abreviada, como apresentado em [RFC1884]. Endereco Forma Completa Forma Abreviada Unicast 1080:0:0:0:8:800:200C:417A 1080::8:800:200C:417A Multicast FF01:0:0:0:0:0:0:43 FF01::43 Loopback 0:0:0:0:0:0:0:1 ::1 Unspecified 0:0:0:0:0:0:0:0 :: A terceira opcao de representacao, mais conveniente quando em ambi- entes mistos com nodes IPv4 e IPv6, e' da forma x:x:x:x:x:x:d:d:d:d, onde os "x" sao numeros hexadecimais (16 bits) e os "d" sao valores decimais de 8 bits referentes `a representacao padrao ja' bem conhecida do IPv4. Por e- xemplo: 0:0:0:0:0:0:192.168.20.30 ou, na forma abreviada: ::192.168.20.30 Esta forma de notacao sera' bastante util durante a migracao do IPv4 para o IPv6 e na coexistencia entre ambos. Novo Cabecalho Outra caracteristica importante do IPv6 e' o seu novo e simplifica- do formato de cabecalho. O cabecalho IPv6 e' constituido por um cabecalho inicial de 64 bits, seguido dos enderecos de origem e destino de 128 bits, totalizando 40 bytes. Enquanto o cabecalho do IPv4 possui 10 campos de cabecalho, dois enderecos de 32 bits cada, e algumas opcoes, o cabecalho IPv6 compoe-se a- penas de 6 campos de cabecalho e dois enderecos 128 bits cada. Os seis cam- pos de cabecalho sao: version (4 bits), priority (4 bits), flow label (28 bits) e length of the payload (16 bits). Ainda comparando-se o formato do IPv6 com o do IPv4, os mecanismos de opcoes foram completamente revisados, seis campos foram suprimidos (header length, type of service, identification, flags, fragment offset e header checksum), tres foram renomeados e, em alguns casos, ligeiramente modificados (length, protocol type e time to leave), e dois foram criados (priority e flow label). As simplificacoes mais consideraveis do IPv6 foram a alocacao de um formato fixo para todos os cabecalhos, a remocao do checksum de cabecalho e remocao dos procedimentos de segmentacao "hup-by-hop". A remocao de todos os elementos opcionais nao significa que nao se possa configurar servicos especiais. Estes poderao ser obtidos atraves de cabecalhos denominados "extension headers", que sao anexados ao cabecalho principal. A remocao do checksum de cabecalho poderia gerar problemas no rote- amento dos pacotes, mas o IPv6 pressupoe que as camadas inferiores sao con- fiaveis, com seus respectivos controles de erros como, por exemplo, o 802.2 LLC (Logical Link Control) para redes locais, o controle das camadas de a- daptacao dos circuitos ATM e o controle do PPP para links seriais. A cada salto de um pacote IPv6, os roteadores nao precisarao se preocupar com o calculo do tamanho do cabecalho, que e' fixo, com o calculo do checksum do cabecalho, e nem com as tarefas de fragmentacao, que serao realizadas pelos hosts. Todas estas modificacoes aumentarao substancialmen- te o desempenho dos roteadores. Tipos de Enderecos No IPv6, foram especificados apenas tres tipos de enderecos: Uni- cast, Anycast e Multicast. Sendo assim, diferente do IPv4, nao mais existem enderecos Broadcast. Esta funcao passa a ser provida pelo endereco Multi- cast. Endereco Unicast Identifica apenas uma interface. Um pacote destinado a um endereco unicast e' enviado diretamente para a interface associada ao endereco. Fo- ram definidos varios tipos de enderecos unicast, que sao: * Global Provider-based, ou baseado no Provedor: e' o endereco uni- cast que sera' globalmente utilizado. Seu plano inicial de aloca- cao baseia-se no mesmo esquema utilizado no CIDR (Classless InterDomain Routing, [RFC1519]) definido em [RFC1887]. Seu forma- to possui um prefixo de 3 bits (010) e cinco campos: registry ID, para registro da parte alocada ao provedor; provider ID, que i- dentifica um provedor especifico; subscriber ID, que identifica os assinantes conectados a um provedor; e infra-subscriber, parte utilizada por cada assinante. * Unspecified: definido como 0:0:0:0:0:0:0:0 ou "::", indica a au- sencia de um endereco e nunca devera' ser utilizado em nenhum node. Este endereco so' podera' ser utililado como endereco de o- rigem (source address) de estacoes ainda nao inicializadas, ou seja, que ainda nao tenham aprendido seus proprios enderecos. * Loopback: representado por 0:0:0:0:0:0:0:1 ou "::1". Pode ser u- tilizado apenas quando um node envia um datagrama para si mesmo. Nao pode ser associado a nenhuma interface. * IPv4-based, ou basedo em IPv4: um endereco IPv6 com um endereco IPv4 embutido. Formado anexando-se um prefixo nulo (96 bits ze- ros) a um endereco IPv4 como, por exemplo, ::172.16.25.32. Este tipo de endereco foi incluido como mecanismo de transicao para hosts e roteadores tunelarem pacotes IPv6 sobre roteamento IPv4. Para hosts sem suporte a IPv6, foi definido um outro tipo de en- dereco (IPv4-mapped IPv6) da seguinte forma: ::FFFF:172.16.25.32. * NSAP: endereco de 121 bits a ser definido, identificado pelo pre- fixo 0000001. Enderecos NSAP (Network Service Access Point) sao utilizados em sistemas OSI. * IPX: endereco de 121 bits a ser definido, identificado pelo pre- fixo 0000010. Enderecos IPX (Internal Packet eXchange) sao utili- zados em redes Netware/Novell. * Link-Local: endereco identificado pelo prefixo de 10 bits (1111111010), definido para uso interno num unico link. Estacoes ainda nao configuradas, ou com um endereco provider-based ou com um site-local, poderao utilizar um endereco link-local. * Site-Local: endereco identificado pelo prefixo de 10 bits (1111111011), definido para uso interno numa organizacao que nao se conectara' `a Internet. Os roteadores nao devem repassar paco- tes cujos enderecos origem sejam enderecos site-local. Tambem esta' reservado 12,5% de todo espaco de enderecamento IPv6 para enderecos a serem distribuidos geograficamente (geographic-based). Endereco Anycast Identifica um grupo de interfaces de nodes diferentes. Um pacote destinado a um endereco anycast e' enviado para uma das interfaces identi- ficadas pelo endereco. Especificamente, o pacote e' enviado para a interfa- ce mais proxima de acordo com a medida de distancia do protocolo de rotea- mento. Devido `a pouca experiencia na Internet com esse tipo de endereco, inicialmente seu uso sera' limitado: * Um endereco anycast nao pode ser utilizado como endereco de ori- gem (source address) de um pacote IPv6; * Um endere^Ço anycast nao pode ser configurado num host IPv6, ou seja, ele devera' ser associado a roteadores apenas. Este tipo de enderecamento sera' util na busca mais rapida de um determinado servidor ou servico. Por exemplo, pode-se definir um grupo de servidores de nomes configurados com um endereco anycast; o host acessara' o servidor de nomes mais proximo utilizando este endereco. Endereco Multicast Igualmente ao endereco anycast, este endereco identifica um grupo de interfaces, mas um pacote destinado a um endereco multicast e' enviado para todas as interfaces do grupo. As funcionalidades de multicasting foram formalmente incorporadas ao IPv4 em 1988, com a definicao dos enderecos classe D e do IGMP (Internet Group Management Protocol), e ganhou forca com o advento do MBONE (Multi- casting Backbone) mas seu uso ainda nao e' universal. Desta vez, estas fun- cionalidades foram automaticamente incorporadas ao IPv6. Isto significa que nao mais sera' necessario implementar tuneis MBONE, pois todos os hosts e roteadores IPv6 deverao suportar multicasting. Novas Funcionalidades Alem de um maior espaco de enderecos e das modificacoes apresenta- das anteriormente, o IPv6 possui varias outras caracteristicas interessan- tes como: Autoconfiguracao Quando se instala uma estacao cliente numa rede Netware, automati- camente, e' assinalado um endereco IPX para este cliente. Esta caracteris- tica de autoconfiguracao, denominada "stateless autoconfiguration", estara' presente no IPv6. Isso eliminara' a necessidade de se configurar manualmen- te as estacoes da rede. Para um maior controle de redes muito grande, os administradores poderao optar por uma outra forma de autoconfiguracao, conhecida como "stateful autoconfiguration". Esta opcao sera' disponibilizada por uma nova versao do DHCP (DHCPv6). Seguranca As especificacoes do IPv6 definiram dois mecanismos de seguranca: a autenticacao de cabecalho (authentication header, [RFC1826]) ou autentica- cao IP, e a seguranca do encapsulamento IP (encrypted security payload, [RFC1827]). A autenticacao de cabecalho assegura ao destinatario que os dados IP sao realmente do remetente indicado no endereco de origem, e que o con- teudo foi entregue sem modificacoes. A autenticacao utiliza um algoritmo chamado MD5 (Message Digest 5), especificado em [RFC1828]. A seguranca do encapsulamento IP permite a autenticacao dos dados encapsulados no pacote IP, atraves do algoritmo de criptografia DES (Data Encryption Standard) com chaves de 56 bits, definida em [RFC1829]. Os algoritmos de autenticacao e criptografia citados acima utilizam o conceito de associacao de seguranca entre o transmissor e o receptor. As- sim, o transmissor e o receptor devem concordar com uma chave secreta e com outros parametros relacionados `a seguranca, conhecidos apenas pelos mem- bros da associacao. Para gerenciar as chaves provavelmente sera' utilizado o IKMP (Internet Key Management Protocol), desenvolvido pelo grupo de tra- balho em Seguranca IP. Suporte a Servicos em Tempo Real Na especificacao do IPv6, o termo "flow" ou fluxo pode ser definido como uma sequencia de pacotes de uma determinada origem para um determinado destino (unicast ou multicast), na qual a origem requer um tratamento espe- cial pelos roteadores. Os campos "priority" e "flow label" foram criados especialmente pa- ra facilitar o desenvolvimento de protocolos para controle de trafego em tempo real, como o RSVP (Resource Reservation Protocol), de forma a permi- tir a implementacao de uma Internet com aplicacoes multimidia e com a inte- gracao de servicos de dados, voz e video em tempo real. Suporte a Multiprotocolos e Mobilidade Observa-se, dos tipos de enderecos unicast citados anteriormente, que foi reservada parte do espaco de enderecamento para enderecos NSAP e IPX. Assim, o IPv6 suportara' automaticamente trafego de redes OSI (ende- recos NSAP) e de rede Netware/Novell (endere cos IPX). Uma grande porcao do espaco de enderecamento IPv6 foi reservada para uso futuro. Essa porcao tambem podera' ser alocada para outros protocolos que se tornarem padroes de fato. O suporte a comunicacoes moveis tambem esta' presente no IPv6. En- contra-se em estudo um metodo para que, no estabelecimento inicial de uma sessao, um host IPv6 descubra dinamicamente atraves de um agente central, a localizacao de uma estacao movel. Consideracoes para Migracao Ha' pouco mais de um ano, a complementacao das especificacoes IPv6 foi estimada em 70% e que ja', no inicio de 97, os fabricantes de software comecariam a desenvolver seus sistemas incluindo o novo protocolo. Estima-se tambem que, a partir do inicio de 1998, comecara' o pro- cesso de migracao do IPv4 para o IPv6, colocando-se em pratica as estrate- gias de transicao. Tecnicamente, foram definidas varias delas: * Inicialmente, todos os servidores de nomes deverao ser migrados para suportar a nova representacao IP e todas as modificoes ine- rentes ao novo protocolo. Por exemplo, o registro DNS "A" do IPv4 passara' a ser "AAAA" no IPv6; * A estrategia principal exigida pelo grupo de trabalho IPv6 e' a implementacao do TCP/IP com pilha dupla (IPv6 e IPv4) nos hosts e roteadores da rede; * O IPv6 ja' possui representacao de endereco prevendo sua utiliza- cao como mecanismo de transicao; * Foi incluido um recurso para que pacotes IPv6 trafeguem em redes IPv4. Isso permite que dois hosts IPv6 se comuniquem atraves da infra-estrutura existente de roteadores (IPv4); * Tambem foi incluido mecanismo para que pacotes IPv4 trafegem em redes puramente IPv6. Isso permitira' `as organizacoes que nao queiram fazer a transicao, deixar suas redes IPv4 intactas, sem perder a conectividade com a Internet. Ha' varias outras questoes e observacoes sobre o processo de tran- sicao que devem ser consideradas como: planejamento de alocacao de endere- cos, requisitos de software (sistemas operacionais e aplicativos), requitos de hardware (memoria e CPU), velocidade dos links, recursos financeiros, etc. Todos estes fatores serao imprecindiveis para o exito de um plano de transicao. Conclusao E agora? Voce ja' sabe o que vai mudar em sua vida com a chegada do IPv6? Percebe-se claramente que muita coisa ira' mudar: nova terminologia, novas e interesssantes caracteristicas, novo processo de roteamento com o IDRP (Inter-Domain Routing Protocol), etc. Para os que trabalham diretamente no projeto e implementacao de re- des de computadores TCP/IP, a adaptacao a esta nova tecnologia sera' inevi- tavel. E, para nao ter que pegar o "bonde" andando, a preparacao para essa revolucao deve ser iniciada desde ja', tendo-se em vista um planejamento criterioso de acoes para o processo de transicao e implementacao do 6-BONE. Referencias [RFC1933] Gilligan, R. e Nordmark, E. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, Sun Microsystems, Inc., Abril/1994. [RFC1924] Elz, R. "A Compact Representation of IPv6 Addresses", RFC 1924, University of Melbourne, Abril/1996. [RFC1897] Hinden R. e Postel J. "IPv6 Testing Address Allocation", RFC 1897, Ipsilon Networks e ISI, Janeiro/1996. [RFC1887] Rekhter, Y. e Li, T. "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, Cisco Systems, Dezembro/1995 [RFC1886] Thomson S., e Huitema, C. "DNS Extensions to support IP version 6", RFC 1886, Bellcore e INRIA, Dezembro/1995. [RFC1885] A. Conta, A., e Deering S. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment e Xerox PARC, Dezembro/1995. [RFC1829] Karn, P., Metzger, P. e Simpsom, W. "The ESP DES-CBC Transform", RFC 1829, Qualcomm, Piermont e Daydreamer, Agosto/1995. [RFC1828] Metzger, P. e Simpsom, W. "IP Authentication using Keyed MD5", RFC 1828, Piermont e Daydreamer, Agosto/1995. [RFC1827] Atkinson, R. "IP Encapsulating Security Payload (ESP)", RFC 1827, Naval Research Laboratory, Agosto/1995. [RFC1826] Atkinson, R. "IP Authentication Header", RFC 1826, Naval Research Laboratory, Agosto/1995. [RFC1825] Atkinson, R. "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, Agosto/1995. [RFC1519] Fuller, V., Li, T., Yu, J. e Varadahan, K. "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, Cisco, MERIT e OARnet, Setembro/1993. [RFC1883] Deering, S. e Hiden, R. "Internet Protocol, Verion 6 (IPv6) Specification", RFC 1883, Xerox PARC e Ipsilon Networks, Dezembro/1995. [RFC1884] Hiden, R. e Deering, S. "IP Verion 6 Addressing Architecture", RFC 1884, Ipsilon Networks e Xerox PARC, Dezembro/1995. [HUITEMA] Huitema, Christian "IPv6 - The New INTERNET PROTOCOL", Prentice Hall Inc., New Jersey, 1996. [MENDES] Mendes, Gerald H. "A Nova Geracao de IP Toma Forma", Business Communications Review Brasil, No. 2, Maio/1996. ------------------------------------ Tecnologia ATM: Eu Vou Ter que Usar? ------------------------------------------------------------- Ari Frazao Jr. ari@na-rc.rnp.br Diferente da maioria dos artigos publicados neste bo- letim ate' agora, onde ha' a preocupacao em apresen- tar os conceitos basicos associados a uma tecnologia de forma a dar embasamento a futuras discussoes sobre a mesma, este artigo preocupa-se mais em responder a uma duvida que pode muito bem ter passado pela cabeca de voces: "Se poderemos fazer uso de tecnologias como a Gigabit Ethernet, por que me preocupar com ATM?". A resposta e' que, face `as necessidades que se apre- sentarao para as novas aplicacoes de rede, com a en- trada em cena cada vez maior dos servicos ditos mul- timidia, dentre todas as tecnologias de rede usadas atualmente, apenas a ATM e' capaz de garantir um ni- vel de qualidade adequado a cada diferente tipo de servico que deve ser suportado por tais redes. Introducao Uma rede multiservico e' aquela que possui uma infra-estrutura ca- paz de lidar com uma faixa de servicos, cada um com exigencias peculiares em termos de trafego, garantido a qualidade de servico pretendida por ca- da um deles. Atualmente, a maioria dos computadores de uma instituicao possui dois tipos de conectores de comunicacao: o da rede local e o de comunicacao de dados (modem conectado `a rede de telefonia). Eles sao suportados por duas redes dedicadas onde, em geral, apenas os meios de comunicacao de lon- ga distancia sao compartilhados. As tecnologias por tras destas redes dife- rem bastante: a rede telefonica utiliza uma tecnica conhecida como comuta- cao de circuitos que transfere um fluxo bidirecional de dados a uma veloci- dade tipica de 64 Kbps, enquanto que a rede de comunicacao de dados faz uso de uma tecnica de comutacao de pacotes onde nao se dedicam canais fisicos a conexoes fim-a-fim. No entanto, o avanco dos servicos ditos multimidia passou a exigir de forma latente o uso de uma rede com as caracteristicas daquela que fala- mos acima: uma rede de servicos integrados. Redes Integradas Usando ATM A tecnologia ATM (do ingles, Assynchronous Transfer Mode) transpor- ta dados, voz e video na forma de celulas de tamanho fixo (53 bytes) atra- ves de uma rede formada por comutadores (switches) conectados via enlaces de diferentes velocidades. Esta rede e' suportada e controlada por meio de protocolos de sinalizacao que permitem ao equipamento final requerer uma conexao com as caracteristicas mais adequadas ao tipo de servico que se quer fazer uso. Desde a sua concepcao, o ATM foi projetado para integrar voz, video e comunicacao de dados atraves de uma rede unica. Embora tenha sido pensado como uma tecnica de multiplexacao e comutacao de alta velocidade em redes publicas, nos ultimos anos, ele tambem comecou a ser utilizado como uma tecnologia para redes locais e/ou corporativas de velocidade elevada. Enquanto parece claro que o ATM e' a melhor solucao para a integra- cao de servicos multimidia, nao se pode desconsiderar o fato de que a gran- de maioria das redes existentes sao baseadas em tecnologias mais antigas (Ethernet, Token Ring, etc.) e se interconectam atraves de roteadores que rodam protocolos como o IP. Para estes, as maiores duvidas residem na parte tecnica. Como ga- rantir a interoperabilidade e a compatibilidade desta rede com o ATM? Nes- te caso, parece ser mais sensato apostar em tecnologias alternativas como o Gigabit Ethernet ou o IP Switching, que incrementam a banda passante, mantendo a "filosofia" do que esta' funcionando. Por Que ATM? O pensamento acima apresenta bastante coerencia se a instituicao apenas deseja resolver problemas de congestionamento em relacao as suas aplicacoes atuais. Se, ao inves disso, ela pretende incrementar os seus servicos, com a adicao de aplicacoes multimidia, como a videoconferencia, entao ela nao ha' como fugir do ATM. A razao para esta afirmacao pode ser vista quando sao analisadas as caracteristicas do trafego originado pelos diferentes servicos que devem ser suportados por uma rede multimidia. Sao exemplos destes: videotelefo- nia, videoconferencia, transferencia de dados a alta velocidade, video sob- demanda, etc. Cada um destes servicos pode ser caracterizado por diversos parame- tros, tais como: taxa de chamadas, taxas media e maxima de transmissao, grau de explosividade ("burstiness"), duracao da chamada e sensibilidade a atraso e/ou perda de dados. Tendo em vista o numero de aplicacoes ja' mencionadas, pode-se ima- ginar o quanto elas diferem entre si segundo os parametros acima. Comparan- do o trafego de aplicacoes unicamente de voz com o originado pela transfe- rencia de dados, tem-se que, enquanto o primeiro pode tolerar um certo grau de degradacao (perda de dados), mas e' muito sensivel a atrasos; o segundo pode tolerar atrasos, mas nao perda de informacao. Para exemplificar as exigencias em termos de atraso na rede, tome- se como base a implementacao de aplicacoes de video. A transmissao de ima- gens coloridas (video) em tempo real, tela cheia, codificado em MPEG2, de- pendendo do nivel de qualidade exigido, requer de 4 a 60 Mbps. Um dos fa- tores mais importantes para a manutencao da qualidade da imagem neste tipo de aplicacao (transmissao de video em tempo real) e' o atraso absoluto fim-a-fim. Enquanto atrasos de 200 ms chateiam, aqueles superiores a 400 ms tornam-se insuportaveis. Alem do atraso absoluto, a variacao do atraso ("jitter") tambem e' um parametro importante. Este ultimo nao so' interfere na qualidade visual, mas tambem contribui para a irritante falta de sincro- nizacao entre o video e o audio. Atualmente, apenas a tecnologia ATM garante a banda passante, bem como a qualidade de servico (QoS) requerida por aplicacoes de video em tem- po real. Alem disso, com ela, e' possivel fazer a multiplexacao estatistica de muitos trafegos de video numa so' linha. O Que Fazer com o Meu Investimento? Conforme ja' foi dito anteriormente, a realidade da maioria das instituicoes e' possuir redes baseadas em tecnologia mais antiga e interco- nectadas via roteadores que rodam IP. O protocolo IP foi projetado, pura e simplesmente, para o transpor- te eficiente de dados, nao sendo adequado para tratar de trafego de voz ou de video. Atualizar equipamentos como roteadores para que estes passem a lidar com esses tipos de trafego requer um grande dispendio para se obter um desempenho ainda questionavel. Embora exista toda uma facilidade natural do ATM em lidar com apli- cacoes multimidia, isto nao significa que ele deva substituir o IP. Aplica- coes baseadas neste protocolo continuam a usa-lo, rodando sobre ATM. Junta- mente com essas aplicacoes, o ATM suporta tambem aquelas de video e audio em tempo real atraves de sua propria pilha de protocolos. Roteadores ainda sao necessarios para suportar o trafego IP, mas as aplicacoes multimidia irao desconsidera-los, evitando a necessidade de sua atualizacao para dar suporte a trafego em tempo real. O cenario que temos hoje e' uma adaptacao em massa das redes locais para fazer uso concentradores inteligentes (hubs). Dessa forma, a migracao para um ambiente ATM encontra-se bastante facilitada. Um hub ATM pode ser utilizado para conectar redes heterogeneas atraves desta tecnologia. Deste modo, a conexao e' feita a alta velocidade. Este mesmo hub ATM pode ser utilizado para a interconexao de equi- pamentos a baixo custo. Assim, por exemplo, um micro ou uma estacao de tra- balho poderia fazer o seu acesso `a rede ATM atraves de sua interface Ethernet, trabalhando a uma velocidade de 10 Mbps nao de modo compartilha- do, mas dedicado entre o mesmo e o hub. E, finalmente, para a interconexao de servidores, a conexao seria efetuada utilizando-se o proprio ATM atraves de uma interface dedicada. A adocao de tal esquema tem sido facilitada ainda por dois fatores: o barateamento dos equipamentos e a atuacao do "ATM Forum", que tem incen- tivado a definicao de padroes ATM com bastante sucesso. Ha', contudo, outras consideracoes que ainda devem ser levadas em conta. Embora tenha havido uma grande reducao dos precos de equipamentos ATM, estes ainda tem precos elevados, o que torna uma mudanca, principal- mente se tiver que feita em larga escala, proibitiva. Ainda ha' a dificul- dade associada a configuracao e manutencao destes equipamentos, o que e' a- gravado pela pouca mao-de-obra qualificada em lidar com os mesmos. Conclusoes O ATM e' a unica tecnologia realmente capaz de lidar com todas as exigencias impostas pelo trafego de dados, video e audio numa rede de ser- vicos integrados. A integracao do ATM com as demais tecnologias de rede e' possivel e tem se mostrado bastante eficaz. Num proximo artigo, serao discutidos aspectos mais tecnicos acerca desta tecnologia. ----------------------------------------------------- Cache: Melhor Aproveitamento dos Recursos na Internet --------------------------------------------------------------------------- Laszlo Pinto laszlo@dcc.ufmg.br Marcio Cesario magc@dcc.ufmg.br Murilo Monteiro murilo@dcc.ufmg.br Com o crescimento da utilizacao da Internet e o sur- gimento de novas aplicacoes, cresce a cada dia a quantidade de dados a ser transmitida, tornando os meios de comunicacao disponiveis cada vez mais satu- rados. E, grande parte desse trafego e', muitas ve- zes, formado pela passagem de diversas copias da mesma informacao. Neste ponto, entra o cache, cuja finalidade e' exata- mente amenizar esse problema, fazendo uso de dados previamente consultados em vez de busca-los na origem sempre que requisitados. Como Funciona Servidores proxy sao instalados e as consultas, que antes eram fei- tas diretamente para os servidores de origem, passam a ser direcionadas a estes novos servidores. Assim, a primeira vez que uma pagina Web e' consul- tada, a requisicao e' encaminhada ao servidor proxy que a busca na origem, armazena-a localmente e a repassa ao cliente que fez o pedido. Para todas as outras consultas a essa mesma pagina, sera' apenas repassada a copia an- teriormente gravada. E' um cache compartilhado por diversos usuarios. Uma pagina Web e' formada por varios objetos, tais como textos, imagens e sons. O tempo em que um objeto sera' mantido em disco, depende de varios fatores: a frequencia dos acessos a essa pagina, o espaco dispo- nivel em disco, a existencia de cabecalhos HTTP que definem datas de expi- racao e de renovacao, entre outros. Quanto menos espaco tiver disponivel em disco, menor sera' o tempo de vida de cada pagina. Atualmente, existem programas que fazem cache de dados de diversas aplicacoes, como por exemplo HTTP, FTP e GOPHER. Como a primeira e', sem duvida, a mais utilizada, as informacoes citadas daqui pra frente se refe- rirao a ela. A porcentagem das requisicoes que conseguem ser resolvidas pelo servidor cache apenas com os dados armazenados localmente (taxa de acerto, ou "hit ratio") varia de acordo com varios fatores, tais como: a capacidade de armazenamento de objetos, o ambiente e grupo de trabalho onde estamos. Por exemplo, e' provavel que, num determinado laboratorio, as pessoas pro- curem sempre pelos mesmos documentos, ao contrario do que pode acontecer numa grande universidade. Na pratica, pode-se conseguir taxas de acerto en- tre 30% e 60%. Para se ter uma ideia de como isso pode economizar recursos da In- ternet, uma amostragem feita pelo "National Laboratory for Applied Network Research (NLANR)" num tronco OC-3 de um backbone dos Estados Unidos mostra que mais de 60% dos bytes em transito sao respostas de requisicoes HTTP. Se considerarmos que podemos ter em cache 60% das paginas Web, poderemos ter o equivalente a 3 Mbps de trafego com uma linha de 2 Mbps. Isto porque, se- gundo a amostragem feita, 60% destes 3 Mbps se referem a trafego HTTP, e um servidor de cache com tal taxa de acerto economizaria 1,08 Mbps (1,8 x 0,6) deste canal de 3 Mbps. Alem disso, o uso do cache traz algumas outras vantagens. Uma delas e' o fato de o servidor cache ficar "mais proximo" da maquina que faz a re- quisicao. Isto pode trazer um ganho consideravel de desempenho para o usua- rio, mesmo em caso de linhas pouco congestionadas. Outra vantagem e' quando um site, por algum motivo, fica inacessivel. Usuarios que utilizam um ser- vidor de cache continuarao podendo navegar e mesmo fazer FTP para este site, uma vez que os objetos tenham sido previamente armazenados no cache. Isto pode ser de grande utilidade no caso de quedas de linhas de dados, por exemplo. O Que E' Necessario Para se instalar um servidor de cache e' necessario que se tenha, no minimo, uma maquina e um bom software de cache. De preferencia, esta ma- quina deve ficar dedicada a essa atividade. Existem, atualmente, diversos programas para essa finalidade, entre eles o Squid, o NetApp, Apache, e muitos outros. Direcionaremos nossa a- tencao principalmente para o Squid, por ser o mais usado em todo o mundo, por ser freeware, por estar em constante atualizacao e por ter uma boa do- cumentacao. O Squid esta' na versao 1.1.11 e funciona com HTTP, FTP, WAIS e GOPHER. O programa fonte do Squid, que ja' foi testado em praticamente to- das as variacoes de UNIX, pode ser encontrado em [1]. O hardware necessario depende da utilizacao e da taxa de acerto de- sejadas. Com um Pentium 166 MHz, rodando FreeBSD ou Linux, 128 MB de RAM e 8 GB de disco SCSI, e' possivel atender a, no minimo, 55.000 conexoes por hora. A taxa de acerto e a quantidade de memoria necessaria sao proporcio- nais `a quantidade de espaco em disco disponivel para armazenar os objetos. Na pratica, boas configuracoes em termos de memoria e capacidade de disco seriam 64MB/2GB, 64MB/4GB e 128Mb/8Gb. Isso porque o Squid mantem um indice de todos os objetos que se encontram armazenados em disco. Para cada requisicao feita ao servidor, ele faz uma pesquisa neste indice para saber se os objetos procurados estao no cache. Este indice cresce na mesma pro- porcao da quantidade de objetos armazenados e deve ficar, preferencialmen- te, todo em memoria principal. Alem disso, ter memoria disponivel para de- dicar a objetos "em transito" e aos mais requisitados aumenta consideravel- mente o desempenho. Dificuldades Uma das maiores dificuldades de se ter sucesso na implantacao de servidores de cache e', talvez, conscientizar o usuario da importancia do seu uso. Isto porque e' necessario que cada um configure o seu "browser" para que as consultas feitas por eles a sites diversos sejam redirecionadas a um determinado servidor de cache. Esta conscientizacao vem sendo feita atraves de campanhas e divulgacoes. Uma destas campanhas e' a "Cache Now!", que pode ser vista em [2]. Outra dificuldade e' manter o servidor funcionando 24 horas por dia, 7 dias por semana, e com niveis satisfatorios de desempenho. Note que o "browser" de um usuario, uma vez configurado para fazer uso do servidor de cache, nao conseguira' acessar nenhum site caso o servidor de cache pare de funcionar. Para tentar atender a estes requisitos, utilizam-se varios servidores interligados em rede local e configura-se o DNS de tal modo que ao se consultar o endereco IP do servidor de cache obtenha-se mais de um numero IP. Repare que isto ameniza o problema, mas nao resolve. Se um dos servidores de cache cair, o DNS vai continuar respondendo o nome da maquina na qual ele esta' rodando e o usuario vai continuar fora do ar. Na verdade, ter mais de um pai garante tolerancia a falhas pois, se um deles cair, o filho faz a requisicao a um dos outros pais (ou de um de seus irmaos). Mas, no caso do browser fazendo requisicoes ao proxy, nao tem como garantir fun- cionalidade o tempo todo. Se uma maquina cair o que pode ser feito e' alte- rar o DNS, manualmente, retirando da lista de proxys o nome desta maquina. O Uso de Hierarquia Para se ter um aproveitamento ainda maior dos recursos de maquinas que rodam servidores de cache, e' possivel que elas estejam conectadas em uma hierarquia. Os servidores se comunicam de modo que haja um "comparti- lhamento" dos objetos armazenados. A comunicacao entre esses servidores pode se dar de duas formas: a- traves de um protocolo proprio, o ICP (Internet Cache Protocol)[3], ou por multicast. O ICP e' baseado em UDP, e seu objetivo principal e' verificar se um outro servidor de cache possui uma determinada pagina. No caso do Squid, para se utilizar o ICP e' necessario configurar alguns servidores vizinhos. Assim, o servidor ao receber uma requisicao de uma determinada pagina envia pacotes ICP para seus vizinhos para saber se eles tem esta pa- gina armazenada em seu disco local. Se algum deles responder que a possui, o servidor a requisita deste, em vez de recuperar a pagina original, econo- mizando um acesso mais demorado. Para evitar que vizinhos com problemas a- trasem o processo, existe um "timed-out" (2s, em media) em que o servidor espera resposta dos vizinhos antes de recuperar a pagina direto na fonte. Para flexibilizar mais essa hierarquia, existe uma maneira de con- figurar o que o servidor deve fazer se um vizinho requisitar uma pagina que ele nao possui. Se ele for configurado para apenas responder negativamente caso nao a possua, diz-se que ele e' irmao do outro servidor. Se, ao inves disso, ele tiver que recuperar a pagina da fonte original, e depois a re- passar ao servidor que pediu, diz-se que ele e' pai desse servidor. Nesse caso a pagina estara' no banco de dados tanto do servidor a quem foi requi- sitado inicialmente, quanto no de seu pai. E' possivel tambem configurar diversos irmaos e pais para um servidor. Nesse caso, ele faz o pedido a to- dos eles, e pega a pagina daquele cuja resposta chegar primeiro. A utilizacao de hierarquias aumenta muito o "hit ratio" combinado de diversos servidores. Se tres maquinas forem configuradas apenas para responder requisicoes de usuarios finais, sem comunicacao entre si, havera' uma grande probabilidade de uma delas estar buscado um objeto diretamente da origem que outro servidor acabou de buscar, e que poderia simplesmente ser repassada de um para outro servidor. Se um dos tres for colocado como pai dos outros dois, o pai, com o passar do tempo, tera' em seu banco de dados um grande numero de paginas que serao aproveitadas pelos dois filhos. Se, alem disso, o pai for irmao de outros servidores cache, em outros pon- tos da rede, esses servidores poderao trocar informacoes entre si, sem ter que recorrer aos sites originais das paginas. No caso da RNP, a situacao ideal e' que cada provedor de acesso ou instituicao ligada a um POP tenha o seu servidor de cache para atender seus usuarios. O POP, por sua vez, mantem um ou mais servidores que funcionarao como pais dos servidores dos provedores. Para uma reducao ainda maior no trafego internacional, os servidores cache dos POPs deverao se interligar como irmaos. Nesse caso, se o usuario requisitar uma pagina ao servidor cache de seu provedor, existe uma chance bem grande dessa pagina estar em algum servidor dentro do Brasil. Isso, alem de poupar as linhas internacio- nais, ajuda a balancear o trafego no backbone, uma vez que um servidor sem- pre baixara' a pagina daquele que o respondeu mais rapido, ou seja, o tempo de resposta sera' influenciado nao so' pelo estado atual de carga do servi- dor, mas tambem pelo tempo gasto para trafegar pelas linhas do backbone. Referencias [1] http://squid.nlanr.net [2] http://www.pop-mg.rnp.br/portugues/servicos/cache/CacheNow [3] http://www.nlanr.net/Cache/ICP/ICP-id.txt -------------------------------------------------------------------------- Envie criticas e sugestoes de temas para editor@rnp.br. Teremos prazer em conversar com voce. --------------------------------------------------------------------------- Este boletim contem 100% de eletrons reciclaveis