Sie sind auf Seite 1von 118

PONTIFCIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL

FACULDADE DE ENGENHARIA
CURSO DE ENGENHARIA ELTRICA
DISCIPLINA DE TRABALHO DE INTEGRAO

SOLUES DE SERVIOS ESPECIALIZADOS DE
TELECOMUNICAES COM A UTILIZAO DE
UMA REDE MULTISERVIOS
ALUNO: FLVIO LUIS WISNEVSKI

ORIENTADOR: EDGAR BORTOLINI

Porto Alegre, Julho de 2003.

2
Dedicatria

Este trabalho dedicado a todos aqueles que acreditam que possvel mudarmos os
paradigmas. O aperfeioamento acadmico se completa com um aprendizado constante, atravs
do desempenho para atingir um objetivo, acreditem vocs tambm podem. Uma dedicatria em
especial, ao Prof. Joo Ernandes Silveira Vieira, que incondicionalmente tem me orientado na
vida profissional e pessoal:

Um professor afeta a eternidade; ele nunca sabe onde sua influncia termina. Henry Adans


3
Agradecimentos
Muito obrigado a todos que de alguma forma cooperaram para a realizao deste
trabalho, em especial minha amada Lisiane Nunes pela sua compreenso e seu auxlio.
Dedico este trabalho minha a minha av, Sra. Jenny Ilka Clauhs que tanto esperou esta
realizao.
Um agradecimento minha me, Sra Alzira Berenice Wisnevski que sempre valorizou a
minha educao.
Muito obrigado ao Prof. Edgar Bortolini, um mestre dedicado, que sabe como poucos
exigir qualidade e ensinar sobre o mercado profissional, agradeo-o pelo imenso aprendizado
durante suas aulas extras.
Agradeo a Deus por todas as realizaes e oportunidades que estou tendo na vida,
felicidades a todos!


4
Resumo
Atualmente as mudanas que ocorrem na tecnologia so rpidas e competitivas. Existe
um nmero cada vez maior de opes e facilidades em servios de telecomunicaes. Este
trabalho descreve a experincia de utilizao de uma rede multiservios para o fornecimento do
vdeo, voz e dados: a to chamada convergncia tecnolgica. Baseia-se em conhecimentos
tcnicos adquiridos e experincias fundamentadas na implementao prtica em solues de
redes coorporativas ao longo de trs anos de minha atuao profissional na rea de redes.
O trabalho descreve inicialmente o processo de evoluo da internet, o qual possibilita
chegar s facilidades que se tem nos dias de hoje. Em seguida foram destacadas as grandes redes
que trabalham com as mais diversas tecnologias, entre elas o MPLS (Multi Protocol Label
Switch) , um protocolo capaz de suportar a gama de servios que existem atualmente com uma
melhor performance de rede. Para a implementao de tais tecnologias, foi relatada a facilidade
das redes wireless, que esto sendo muito utilizadas nas empresas de telecomunicaes, bem
como os servios prestados para absorver a rpida demanda do mercado e a fidelidade do
cliente. No que se trata de fidelidade do cliente, o trabalho mostra a abordagem de cases, entre
eles o que foi implementado na Pontifcia Universidade Catlica do Rio Grande do Sul
(PUCRS).
A finalidade deste projeto constatar as mudanas que esto ocorrendo com relao aos
servios prestados em telecomunicaes, demonstrando que cada vez mais exigido pelo cliente
uma otimizao dos recursos financeiros com uma maximizao dos recursos tecnolgicos
existentes. O que coloca o engenheiro numa posio de agregar solues.



5
Abstract
Nowadays, the changes that happen in the technology are fast and competitive. There is
a such larger number of options and means in services of telecommunications. This work
describes the experience of use a multiservices net for the supply of video, voice and data: that is
called technological convergence. It bases on technical knowledge acquired and experiences in
solutions of coorporatives nets along three years of my professional performance in this area.
Initially, the work describes the process evolution of internet, which allows us to get the
facilities that we have with this tecnology. Afterwards we highlight the biggest nets that work
with the most several technologies, among them MPLS (Multi Protocol Label Switch), a protocol
able to support the scale of services that exists, with a better net performance. For the
implementation of such technologies, it was given an account of the facilities of the nets wireless,
that are being used in the telecommunications companies, as well as the services done to absorb
the fast demand of the market and the customer's fidelity. In this topic, we have the approach of
some cases, among the one that was implemented at Pontifcia Universidade Catlica do Rio
Grande do Sul (PUCRS).
The purpose of this project is to verify the changes that are happening in the services
given to telecommunications, is to demonstrate that the customer demands more and more an
optimization of the financial resources with a maximization of the existent technological
resources. That what puts the engineer in a position of joining solutions.





6
Sumrio
1. Introduo.............................................................................................................................. 12
2. A evoluo da Internet .......................................................................................................... 14
2.1. A origem da Internet ..................................................................................................... 14
2.2. Os conceitos iniciais da Internet.................................................................................... 17
2.3. O teste das idias ........................................................................................................... 21
2.4. A transio para a infra-estrutura aberta ....................................................................... 24
2.5. O papel da documentao ............................................................................................. 27
2.6. A formao da comunidade........................................................................................... 29
2.7. A comercializao da tecnologia................................................................................... 32
3. MPLS .................................................................................................................................... 35
3.1. Introduo...................................................................................................................... 35
3.1.1. O que MPLS? ..................................................................................................... 36
3.2. Conceitos Bsicos ......................................................................................................... 38
3.2.1. Rtulo.................................................................................................................... 38
3.2.2. Pilha de Rtulos .................................................................................................... 38
3.2.3. Pacote Rotulado..................................................................................................... 39
3.2.4. FEC (Forward Equivalence Class)........................................................................ 39
3.2.5. NHLFE (Next Hop Label Forwarding Entry) ....................................................... 40
3.2.6. ILM (Incoming Label Mapping) ........................................................................... 41
3.2.7. FTN (FEC-to-NHLFE).......................................................................................... 41
3.2.8. LER (Label Edge Router) ..................................................................................... 42
3.2.9. LSR (Label Switching Router).............................................................................. 42
3.2.10. Label Merging....................................................................................................... 42
3.2.11. LSP (Label Switched Path) ................................................................................... 43
3.2.12. LDP (Label Distribution Protocol)........................................................................ 43
3.2.13. CR-LDP (Constraint-Based Routed LDP) ............................................................ 44
3.2.14. Vizinhos (Next-hops)............................................................................................. 45
3.2.15. Colegas (Peers) ..................................................................................................... 45
3.2.16. LSRs Upstream e Downstream............................................................................. 46
3.3. Distribuio de Rtulos................................................................................................. 47
3.3.1. Mtodos de Distribuio de Rtulos ..................................................................... 47
3.3.2. Downstream No-Solicitado ................................................................................. 47
3.3.3. Downstream Sob Demanda................................................................................... 48
3.3.4. Controles de Distribuio de Rtulos.................................................................... 48
3.3.5. Independente ......................................................................................................... 49
3.3.6. Ordenado ............................................................................................................... 50
3.3.7. Modo de Reteno de Rtulos .............................................................................. 50
3.3.8. Conservativo.......................................................................................................... 51
3.3.9. Liberal ................................................................................................................... 52
3.3.10. Exemplo de utilizao das formas de distribuio de rtulos ............................... 52

7
3.4. Roteamento.................................................................................................................... 54
3.4.1. Roteamento N a N (Hop by Hop)...................................................................... 54
3.4.2. Roteamento Explcito............................................................................................ 55
3.4.3. Tunneling .............................................................................................................. 56
3.5. Encapsulamento do Rtulo............................................................................................ 58
3.5.1. Ethernet ................................................................................................................. 58
3.5.2. ATM...................................................................................................................... 59
3.5.3. SVC Encoding....................................................................................................... 59
3.5.4. SVP Encoding ....................................................................................................... 60
3.5.5. SVP Multipoint Encoding..................................................................................... 60
3.5.6. Frame Relay .......................................................................................................... 61
4. Experincia Pratica................................................................................................................ 62
4.1. Empresa Diveo do Brasil............................................................................................... 62
5. Concepo de Rede ............................................................................................................... 64
5.1. Rede atual (Descrio dos Elementos).......................................................................... 64
5.1.1. Backbone ATM Multiservio Dveo:.................................................................... 65
5.1.2. Equipamento de enlace de microondas: SDH....................................................... 65
5.1.3. Switch ATM.......................................................................................................... 66
5.1.4. Sincronizao de rede............................................................................................ 66
5.1.5. Equipamento de enlace de microondas (PDH): .................................................... 67
5.1.6. Unidade de Interface de Dados UID: ................................................................. 79
5.1.7. Descrio da Topologia......................................................................................... 79
5.1.8. Terminologia utilizada nesta rede ......................................................................... 80
5.2. Servios disponveis ( formas de acesso)...................................................................... 85
5.2.1. Servio Digital Business Access (Dveo DBA) .................................................... 85
5.2.2. Ponto a ponto:........................................................................................................ 86
5.2.3. Ponto-Multiponto: ................................................................................................. 86
5.2.4. Rede privativa virtual (VPN): ............................................................................... 87
5.2.5. Gateway:................................................................................................................ 87
5.2.6. Solues Especiais: ............................................................................................... 88
5.2.7. Caractersticas tcnicas ......................................................................................... 89
6. Cases de Solues Tecnolgicas ........................................................................................... 90
6.1. Perfil de Clientes ........................................................................................................... 90
6.2. Cases de Clientes........................................................................................................... 96
6.2.1. Cliente: Sonae ....................................................................................................... 97
6.2.2. Cliente: PUCRS................................................................................................... 104
7. O mercado atual e as necessidades...................................................................................... 113
8. Mudanas da Rede ............................................................................................................. 116
9. Concluses .......................................................................................................................... 117
10. Referncias Bibliogrficas .............................................................................................. 118






8


Lista de Tabelas
Tabela 3-1 Simbolos dos elementos das figuras sobre MPLS ...................................................... 37
Tabela 5-1 Distncia do Radio Enlace x Freqncia .................................................................... 71
Tabela 6-1 Reportagem: Migrao das redes VPN/IP para MPLS............................................... 92
Tabela 6-2 Reportagem: Utilizao do MPLS para prover servios qualificados de redes. ......... 93
Tabela 6-3 Reportagem: Uma das primeiras Redes MPLS , SPB ................................................ 94
Tabela 6-4 Repotagem: Rede SONAE e a soluo de conectividade de Voz............................. 103

9
Lista de Figuras
Figura 3-1 - Envio de dois pacotes em um domnio de roteamento IP. ........................................ 36
Figura 3-2 - Envio de dois pacotes em um domnio de roteamento MPLS. ................................. 37
Figura 3-3 Codificao da unidade funcional do MPLS............................................................... 38
Figura 3-4 Pilha de rtulos no MPLS........................................................................................... 39
Figura 3-5 FECs em uma rede IP comum..................................................................................... 40
Figura 3-6 Descrio das entradas NHLFE................................................................................... 41
Figura 3-7 Exemplo deILM........................................................................................................... 41
Figura 3-8 Exemplo de FTN......................................................................................................... 42
Figura 3-9 Label Merging ............................................................................................................. 43
Figura 3-10 Constraint Based Routing.......................................................................................... 45
Figura 3-11 Ilustrando alguns dos principais conceitos do MPLS................................................ 46
Figura 3-12 Downstream no-solicitado...................................................................................... 47
Figura 3-13 Downstream sob demanda......................................................................................... 48
Figura 3-14 Controle independente com downstream no-solicitado.......................................... 49
Figura 3-15 Controle independente com downstream sob demanda. ........................................... 49
Figura 3-16 Controle ordenado com downstream sob demanda................................................... 50
Figura 3-17 Modo conservativo com controle independente e downstream no solicitado. ........ 51
Figura 3-18 Modo liberal com controle independente e downstream no-solicitado. .................. 52
Figura 3-19 Distribuio de rtulos .............................................................................................. 53
Figura 3-20 Roteamento n a n em MPLS.................................................................................. 55
Figura 3-21 Roteamento explcito................................................................................................. 56
Figura 3-22 Tunneling em redes MPLS. ....................................................................................... 57
Figura 3-23 Encapsulamento do rtulo em um pacote de uma rede Ethernet. ............................. 58
Figura 3-24 Encapsulamento do rtulo em uma clula ATM no SVC......................................... 59
Figura 3-25 Ilustrao do encapsulamento do rtulo em uma clula ATM no SVP ................... 60
Figura 3-26 Encapsulamento do rtulo em uma clula ATM no SVP multipoint Encoding........ 61
Figura 3-27 Encapsulamento da pilha de rtulos na clula Frame Relay. .................................... 61
Figura 4-1 HUB Site da Diveo...................................................................................................... 63

10
Figura 4-2 NOC ( Network Operation Center) ............................................................................. 63
Figura 5-1 Topologia de um site para formao de um Backbone ATM. .................................... 64
Figura 5-2 Antena de 0,6 m de dimetro montada com a RAU (Radio Unit) acoplada ............... 67
Figura 5-3 Rau com kit de montagem separada da antena(enlace 1+0)........................................ 68
Figura 5-4 RAU com Power Splitter(enlace 1+1)......................................................................... 68
Figura 5-5 Topologia utilizada para diversidade de espao.......................................................... 69
Figura 5-6 Kit Montagem separada............................................................................................... 69
Figura 5-7Ligao entre ODU e a IDU......................................................................................... 70
Figura 5-8 Modelos de Magazine (usados no padro para Rack 19 polegadas ) .......................... 72
Figura 5-9 Mdulo de rdio indoor para enlaces(1+0) de 4 ou 8E1s .......................................... 72
Figura 5-10 Mdulo de radio indoor para enlaces(1+1) de 2, 4, 8, 16 E1s. ................................ 72
Figura 5-11 Utilizao de modulo de rdio indoor em hub site para conexo de clientes............ 73
Figura 5-12 Ocupao de uma AMM-4U as placas que podem ser utilizadas ............................. 73
Figura 5-13 Exemplo de conexo dos equipamentos de transmisso em um cliente ................... 78
Figura 5-14 Topologia para acesso do cliente............................................................................... 84
Figura 5-15 Composio do Servio Dveo DBA......................................................................... 85
Figura 5-16 Configurao Ponto a Ponto...................................................................................... 86
Figura 5-17 Configurao Ponto Multiponto................................................................................ 87
Figura 5-18 Configurao VPN.................................................................................................... 87
Figura 5-19 Conexo de Gateway................................................................................................ 87
Figura 5-20 Conexo Off Net com gernciamento ....................................................................... 88
Figura 5-21 Configurao Off Net sem gerenciamento................................................................ 88
Figura 6-1 Grfico de utilizao de banda .................................................................................... 91
Figura 6-2 Conexo lgica de uma rede MPLS com topologia full mesh. ................................... 95
Figura 6-3 Rede SONAE - Diagrama de aplicao....................................................................... 98
Figura 6-4 Conexo Sonae diretamente no Backbone MPLS..................................................... 100
Figura 6-5 Conexo Sonae via Internet com IPSec..................................................................... 101
Figura 6-6 Conexo Sonae via meio fsico de terceiros com MPLS .......................................... 101
Figura 6-7 PUCS- Conexo RNP: Acesso anterior via dois links E1s.................................... 106
Figura 6-8 PUCRS- Conexo RNP: Soluo LAN-to-LAN E3 Clear Channel......................... 107
Figura 6-9 PUCRS- Conexo Internet: Topologia DBI 3E1 Clear Channel Router com load balancing........................... 108
Figura 6-10 PUCRS- Conexo Internet: Topologia DBI 5E1 Clear Channel Router com BGP4.................................. 108

11
Figura 6-11 PUCRS- Interconexo dos campus: Topologia DBAs E1 Clear Channel - Voz ........................ 110
Figura 6-12 PUCRS- Interconexo dos campus: Topologia DBAs E1 Clear Channel Voz & Dados............ 111
Figura 7-1 Grandes nichos de mercado e suas aplicaes .......................................................... 114


12
1. Introduo
O avano da tecnologia digital impressionante. A to chamada convergncia depara-se
com o IP(Internet Protocol), basicamente quase toda tecnologia utilizada em redes acaba de uma
forma ou outra utilizando IP. A internet est presente em todos os segmentos, a cada instante em
nossas vidas, deixou de ser um paradigma, tornando-se uma realidade cada vez mais necessria.
O mundo est passando por uma grande transformao, nunca fomos to longe e to precisos
com a informao, podemos visualizar dados antes nunca mostrados, como a guerra em Bagd,
um exemplo da tecnologia de ponta inserida no nosso cotidiano, mas isso no para por aqui.
Temos pela frente, olimpadas, copa do mundo e outros grandes eventos que so to necessrios
a divulgao quanto os documentrios realizados sobre a guerra. Estes fatos sempre foram
abordados pela mdia, e hoje estamos num desenvolvimento muito rpidos das tecnologias
digitais, pois a demanda crescente. Fazendo esta anlise, observamos outra reas que esto
crescendo em termos de avanos tecnolgicos: as empresas exploram as facilidades de VoIP(voz
sobre IP), e-bussiness, e-comerce, videoconferncia ; os hospitais utilizam a rede para tele
medicina, diagnsticos mdicos on-line; as universidades, pioneiras do desenvolvimento, criam
suas Gigaredes, realizam EAD(ensino distncia); alunos que buscam um maior
conhecimento,tornando-se consumidores e profissionais mais exigentes, este o ciclo que faz
com que a tecnologia digital avance cada vez mais.
Este trabalho baseia-se na fomentao desta necessidade emergente, os servios de
telecomunicaes que nunca foram to explorados, a Internet realmente se consolidou como a
rede de conhecimento. A internet e o avano da tecnologia digital tornaram-se o centro das
atenes das empresas de telecomunicaes, onde os servios esto focados em novas
tecnologias capazes de fornecer vdeo voz e dados. As idias explanadas aqui so para mostrar
as solues de servios especializados, constatando papel do engenheiro como um agregador de
solues. Este papel tem sido muito requisitado em empresas de grande porte e um nicho de
mercado extremamente carente, pois poucos tem a viso e a capacidade de agregar solues

13
nesta rea de telecomunicaes, at mesmo pela gama de hardwares e softwares que aparecem
com todo este avano da tecnologia digital.

14
2. A evoluo da Internet
2.1. A origem da Internet

Os primeiros registros de interaes sociais que poderiam ser realizadas atravs de redes
foi uma srie de memorandos escritos por J.C.R. Licklider, do MIT - Massachussets Institute of
Technology, em agosto de 1962, discutindo o conceito da "Rede Galxica". Ele previa vrios
computadores interconectados globalmente, pelo meio dos quais todos poderiam acessar dados e
programas de qualquer local rapidamente. Em essncia, o conceito foi muito parecido com a
Internet de hoje. Licklider foi o primeiro gerente do programa de pesquisa de computador do
DARPA(Defense Advanced Research Projects Agency)comeando em outubro de 1962.
Enquanto trabalhando neste projeto, ele convenceu seus sucessores Ivan Sutherland, Bob Taylor
e Lawrence G. Roberts da importncia do conceito de redes computadorizadas.
Leonard Kleinrock, do MIT, publicou o primeiro trabalho sobre a teoria de trocas de
pacotes em julho de 1961 e o primeiro livro sobre o assunto em 1964. Kleinrock convenceu
Roberts da possibilidade terica das comunicaes usando pacotes ao invs de circuitos, o que
representou um grande passo para tornar possveis as redes de computadores. O outro grande
passo foi fazer os computadores se conversarem. Em 1965, Roberts e Thomas Merrill
conectaram um computador TX-2 em Massachussets com um Q-32 na Califrnia com uma linha
discada de baixa velocidade, criando assim o primeiro computador de rede do mundo. O
resultado deste experimento foi a comprovao de que computadores poderiam trabalhar bem
juntos, rodando programas e recuperando dados quando necessrio em mquinas remotas, mas
que o circuito do sistema telefnico era totalmente inadequado para o intento. Foi confirmada
assim a convico de Kleinrock sobre a necessidade de trocas de pacotes.
No final de 1966, Roberts comeou a trabalhar no DARPA para desenvolver o conceito
das redes computadorizadas e elaborou o seu plano para a ARPANET(Advanced Research

15
Projetcs Agency Network) , publicado em 1967. Na conferncia onde ele apresentou este
trabalho, houve tambm uma apresentao sobre o conceito de redes de pacotes desenvolvida
pelos ingleses Donald Davies e Roger Scantlebury, da NPL-Nuclear Physics Laboratory.
Scantlebury conversou com Roberts sobre o trabalho da NPL e do trabalho de Paul Baran e
outros em RAND. O grupo do projeto RAND tinha escrito um trabalho sobre o papel das redes
de trocas de pacotes para voz segura quando serviam militarmente em 1964. O que se percebeu
ento que os trabalhos desenvolvidos no MIT (1961-67), RAND (1962-65) e NPL (1964-67)
estavam se desenrolando em paralelo sem que nenhum dos pesquisadores soubesse dos outros
trabalhos. A palavra "pacote" foi adotada do trabalho desenvolvido no NPL e a velocidade de
linha proposta para ser usada no projeto da ARPANET foi upgraded de 2,4 Kb para 50 Kb.
Em agosto de 1968, depois de Roberts e o grupo do DARPA terem refinado a estrutura e
especificaes para a ARPANET, uma seleo foi feita para o desenvolvimento de um dos
componentes-chave do projeto: o processador de interface das mensagens (IMP). Um grupo
dirigido por Frank Heart (Bolt Beranek) e Newman (BBN) foi selecionado. Paralelamente ao
trabalho do grupo da BBN nos IMPs com Bob Kahn assumindo um papel vital do desenho
arquitetnico da ARPANET, a topologia e economia da rede foi desenvolvida e otimizada por
Roberts em conjunto com Howard Frank e seu grupo da Network Analysis Corporation, e
sistema de mensurao da rede foi preparado pelo pessoal de Kleinrock na UCLA -University of
California at Los Angeles.
Devido teoria de trocas de pacotes de Kleinrock e seu foco em anlise, desenho e
mensurao, seu Centro de Mensurao de Rede da UCLA foi escolhido para ser o primeiro n
(ponta) da ARPANET. Isso aconteceu em setembro de 1969, quando BBN instalou o primeiro
IMP na UCLA e o primeiro servidor de computador foi conectado. O projeto chamado Aumento
do Intelecto Humano, de Doug Engelbart, que inclua NLS (um precursor dos sistemas de
hipertexto), no SRI-Stanford Research Institute, foi o segundo n ou ponta. SRI passou a manter
as tabelas de "Host Name" para o mapeamento dos endereos e diretrio do RFC. Um ms
depois, quando SRI foi conectado ARPANET, a primeira mensagem entre servidores foi
enviada do laboratrio de Kleinrock para o SRI. Dois outros "nodes" foram acrescentados ento:
a UC Santa Barbara e a Universidade de Utah. Este dois ns incorporavam projetos de
aplicaes visuais, com Glen Culler e Burton Fried na UCSB investigando mtodos de uso de
funes matemticas para restaurar visualizaes na rede e Robert Taylor e Ivan Sutherland em
Utah investigando mtodos de representao em terceira dimenso na rede. Assim, no final de

16
1969, quatro servidores estavam conectados na ARPANET e, mesmo naquela poca, os
trabalhos se concentravam tanto na rede em si como no estudo das possveis aplicaes da rede.
Esta tradio continua at hoje.
Computadores foram rapidamente adicionados ARPANET nos anos seguintes e os
grupos de trabalho desenvolveram um protocolo servidor a servidor funcionalmente completo e
outros softwares de rede. Em dezembro de 1971, o Network Working Group (NWG) gerenciado
por S. Crocker, concluiu o primeiro protocolo servidor a servidor da ARPANET, chamado
Network Control Protocol (NCP). De 1971 a 1972, os usurios da rede finalmente puderam
comear a desenvolver as suas aplicaes. Em outubro de 1972, Kahn organizou uma grande e
bem sucedida demonstrao sobre a ARPANET na Conferncia Internacional de Comunicao
entre Computadores (ICCC). Esta foi a primeira demonstrao pblica da nova tecnologia de
rede para o pblico. Foi tambm em 1972 que o correio eletrnico, considerado a primeira
aplicao "hot", foi introduzido. Em maro de 1972, Ray Tomlinson, da BBN, escreveu o
software bsico de e-mail com as funes de "send/enviar" e "read/ler", motivado pela
necessidade dos desenvolvedores da ARPANET de ter um fcil mecanismo de coordenao. Em
julho, Roberts expandiu a utilidade do e-mail escrevendo o primeiro programa utilitrio de e-
mail para listar, ler seletivamente, arquivar, encaminhar e responder a mensagens. Dali, o correio
eletrnico se tornou a maior aplicao de rede por mais de uma dcada. Este foi o prenncio do
tipo de atividade que vemos hoje na WWW , ou seja, o enorme crescimento de todos os tipos de
aplicaes e utilitrios agregados pessoa-a-pessoa.













17

2.2. Os conceitos iniciais da Internet
A ARPANET original cresceu e se tornou a Internet. A Internet foi baseada na idia de
que haveria mltiplas redes independentes de desenho arbitrrio, comeando com a ARPANET
como rede pioneira de trocas de pacotes, mas, logo incluindo redes de satlites, de rdio, etc. A
Internet como conhecemos hoje incorpora uma idia-chave: rede de arquitetura aberta. Nesta
abordagem, a opo pela tecnologia de qualquer rede individual no ditada por nenhuma
arquitetura de rede particular e sim escolhida livremente pelo provedor, que a torna capaz de
entrar em rede com outras redes pela "Arquitetura de Internetworking". At aquele perodo,
havia apenas um mtodo para agregar redes: a tradicional troca de circuitos onde redes se
interconectavam no nvel do circuito, passando bits individuais em base sncrona por um circuito
ponta a ponta entre duas localidades. Lembre que Kleinrock tinha mostrado em 1961 que troca
de pacotes era um mtodo mais eficiente. Condies especficas de interconexo entre redes era
outra possibilidade. Enquanto havia outras formas limitadas de interconectar redes, todas
requeriam que uma fosse componente da outra, ao invs de agirem como companheiras no
oferecimento do servio ponta a ponta. Numa rede de arquitetura aberta, as redes individuais
podem ser separadamente desenhadas e desenvolvidas e cada uma pode ter sua interface prpria
que pode ser oferecida a usurios e outros provedores. Cada rede pode ser desenhada de acordo
com o ambiente e os requerimentos dos seus usurios. No h restries em relao aos tipos de
redes que podem ser includas numa rea geogrfica, apesar de algumas consideraes
pragmticas ditarem o que razovel oferecer.
A idia de redes de arquitetura aberta foi introduzida primeiramente por Kahn em 1972.
Este trabalho foi parte de um programa de pacotes de rdio, mas depois se tornou um programa
em separado. Naquele tempo, o programa foi chamado "Internetting". O NCP no tinha a
habilidade de enderear redes e mquinas alm da destinao IMP da ARPANET e, portanto,
deveria ser mudado. O NCP se amparava na ARPANET para prover confiabilidade de ponta a
ponta. Se qualquer pacote fosse perdido, o protocolo e qualquer aplicao que ele suportasse iria
simplesmente parar a transferncia de dados. Nesse modelo, o NCP no tinha controle de erro
ponta a ponta, uma vez que se pensava que a ARPANET seria a nica rede em existncia e ela
seria to confivel que nenhum controle de erro seria necessrio por parte dos servidores. Ento

18
Kahn decidiu desenvolver uma nova verso do protocolo que iria satisfazer as necessidades de
um ambiente de redes de arquitetura aberta. Este protocolo iria eventualmente ser chamado
Transmission Control Protocol/Internet Protocol (TCP/IP). Enquanto o NCP agia como um
driver de equipamento, o novo protocolo seria mais um protocolo de comunicaes.
Quatro regras foram crticas para a idia de Kahn: cada rede distinta deveria ser
independente e mudanas internas no deveriam ser requisitadas para conect-las Internet;
comunicaes seriam na base do melhor esforo. Se um pacote no chegasse sua destinao
final, ele seria retransmitido da fonte; caixas pretas seriam usadas para conectar as redes. Mais
tarde elas seriam chamadas gateways e roteadores. Os gateways no reteriam informaes sobre
os fluxos de pacotes passantes. Isso assegurou que eles se mantivessem simples, evitando
adaptaes complicadas e recuperaes de erros; no haveria controle global no nvel
operacional.
Outros itens avaliados foram os seguintes: algoritmos para prevenir perda de pacote de
comunicaes desabilitadas, capacitando-os a serem retransmitidos da fonte; provimento de
"pipelining" de servidor a servidor, de forma que mltiplos pacotes poderiam ser roteados da
fonte ao destino vontade dos servidores participantes, se redes intermedirias o permitissem;
funes de gateway (porta de entrada) para encaminhar os pacotes apropriadamente. Isso
incluiria cabealhos de IP para roteamento, interfaces dirigidas, quebra de pacotes em pedaos
menores (caso necessrio), etc; a necessidade de checagens ponta a ponta, recuperao dos
pacotes de fragmentos e deteco de duplicatas; a necessidade do endereamento global; tcnicas
de controle de fluxo servidor a servidor; interfaces com vrios sistemas operacionais; eficincia
da implementao, performance entre as redes, etc.
Kahn comeou a trabalhar na srie orientada s comunicaes dos princpios do sistema
operacional enquanto na BBN, e documentou alguns dos seus pensamentos num memorando
interno chamado "Princpios de Comunicaes para Sistemas Operacionais". Neste ponto, ele
percebeu que seria necessrio aprender os detalhes de implementao de cada sistema
operacional para ter a chance de embutir neles novos protocolos de uma forma eficiente. Assim,
na primavera de 1973, depois de comear o projeto "Internetting", Kahn chamou Vint Cerf
(ento trabalhando em Stanford) para trabalhar com ele no desenho detalhado do protocolo. Cerf
tinha se envolvido intimamente com o desenho e desenvolvimento do NCP original e j tinha o
conhecimento em interfacing com os sistemas operacionais existentes. A abordagem

19
arquitetnica para a comunicao de Kahn e a experincia em NCP de Cerf possibilitou a
construo do que se tornou TCP/IP.
O trabalho de Kahn e Cerf foi altamente produtivo e a primeira verso escrita da teoria
resultante foi distribuda numa reunio especial do International Network Working Group
(INWG), que tinha sido definido numa conferncia da Sussex University em setembro de 1973.
Cerf tinha sido convidado para dirigir este grupo e usou a ocasio para realizar o encontro do
INWG. Algumas teses bsicas surgiram da colaborao entre Kahn e Cerf: comunicao entre
dois processos deveria consistir logicamente de uma longa corrente de bytes (que eles chamaram
de octets). A posio de qualquer octet na corrente seria usada para identific-lo; o controle do
fluxo seria feito usando janelas e corredias e acks. O destino poderia selecionar quando seria
efetuado o reconhecimento e cada ack retornado seria cumulativo para todos os pacotes
recebidos; foi deixado em aberto como a fonte e o destino iriam concordar nos parmetros das
janelas a serem usadas. Padres foram usados inicialmente; apesar de a Ethernet (sistema de
redes que transporta sinais (bits) para todos os microcomputadores em rede) estar em
desenvolvimento em Xerox PARC naquele tempo, a proliferao de LANs (redes locais) no era
prevista, muito menos a proliferao de PCs (computadores pessoais) e estaes de trabalho. O
modelo original de redes nacionais como a ARPANET, que se pensava, no iriam existir muitas
como ela. Ento um IP de 32 bits foi usado, dos quais os primeiros 8 bits indicavam a rede e os
restantes 24 bits designavam o servidor na rede. Esta hiptese de que 256 redes seriam
suficientes para o futuro prximo passou necessariamente a ser reconsiderada quando LANs
comearam a aparecer no final da dcada de 1970.
O trabalho original de Cerf e Kahn sobre a Internet descreveu um protocolo chamado
TCP, que provia todo o transporte e servios de encaminhamento na Internet. Kahn queria que o
protocolo suportasse uma srie de servios de transporte, desde a entrega seqenciada de dados
totalmente confivel (modelo de circuito virtual) at o servio de datagram, onde a aplicao
fazia uso direto do servio bsico de rede, o que poderia implicar em pacotes ocasionalmente
perdidos, corrompidos ou reordenados. Entretanto, o esforo inicial para implementar TCP
resultou numa verso que somente permitiu circuitos virtuais. O modelo funcionou bem para
transferncia de arquivos e aplicaes de logins remotos, mas alguns dos trabalhos em aplicaes
avanadas como pacotes de voz mostraram que, em alguns casos, a perda de pacotes deveria ser
corrigida pela aplicao e no pelo protocolo TCP. Isso levou a uma reorganizao do TCP
original em dois protocolos: o simples IP que provia apenas o endereamento e o roteamento dos

20
pacotes individuais e o TCP em separado, que se preocupava com o controle do fluxo e a
recuperao de pacotes perdidos. Para as aplicaes que no queriam os servios de TCP, uma
alternativa chamada User Datagram Protocol (UDP) foi adicionada para prover acesso direto ao
servio bsico de IP.
Uma grande motivao inicial para a ARPANET e para a Internet foi o
compartilhamento de recursos. A conexo das duas redes foi muito mais econmica do que a
duplicao de caros computadores. Entretanto, enquanto a transferncia de arquivos e o login
remoto (Telnet) foram aplicaes muito importantes, o correio eletrnico teve o impacto mais
significativo das inovaes daquela poca. O correio eletrnico ou e-mail criou um novo modelo
no qual as pessoas poderiam se comunicar e mudou a natureza da colaborao, primeiro na
construo da prpria Internet e mais tarde na sua utilizao por grande parte da sociedade.
Outras aplicaes foram propostas nos dias iniciais da Internet, incluindo comunicao
de voz (precursora da telefonia via Internet), vrios modelos de compartilhamento de arquivos e
discos, e os primeiros programas que mostraram o conceito de agentes (e vrus..). Um conceito-
chave da Internet que ela no desenhada para apenas uma aplicao, mas uma infra-
estrutura genrica na qual novas aplicaes podem ser concebidas, como aconteceu com a World
Wide Web. Foi e a natureza do servio provido pelos protocolos TCP e IP que tornam isso
possvel.















21

2.3. O teste das idias
DARPA fez trs contratos para Stanford (Cerf), BBN (Ray Tomlinson) e UCL (Peter
Kirstein) implementarem TCP/IP (que foi simplesmente chamado TCP no trabalho de
Cerf/Kahn, mas que continha ambos os componentes). A equipe de Stanford, liderada por Cerf,
produziu uma detalhada especificao e, em um ano, havia trs implementaes independentes
de TCP que poderiam operar em conjunto. Este foi o comeo de longa experimentao e
desenvolvimento a fim de evoluir e amadurecer os conceitos e a tecnologia da Internet.
Comeando com as trs primeiras redes (ARPANET, Packet Radio e Packet Satellite) e suas
comunidades iniciais de pesquisa, o ambiente experimental cresceu para incorporar
essencialmente qualquer forma de rede e grande comunidade de pesquisa e desenvolvimento. E,
com cada expanso, novos desafios surgiram.
As primeiras implementaes de TCP foram feitas por sistemas como Tenex e TOPS 20.
Quando os microcomputadores apareceram, alguns acharam que TCP foi grande e complexo
demais para rodar neles. David Clark e seu grupo de pesquisa no MIT trabalharam para mostrar
que poderia haver uma simples e compacta implementao de TCP. Eles produziram esta
implementao, primeiro para o Xerox Alto (a primeira estao de trabalho pessoal desenvolvida
em Xerox PARC) e depois para o IBM PC. Esta implementao foi completamente interopervel
com outros TCPs, mas foi feita sob medida para microcomputadores, e mostrou que estaes de
trabalho, tanto quanto sistemas de grande porte, poderiam tornar-se parte da Internet. Em 1976,
Kleinrck publicou o primeiro livro sobre ARPANET, com nfase na complexidade dos
protocolos e nas dificuldades que eles introduzem. Este livro foi importante na divulgao da
crena nas redes com trocas de pacotes para uma grande comunidade.
O desenvolvimento generalizado de LANs, PCs e estaes de trabalho na dcada de 80
permitiram a prosperidade da Internet que nascia. A tecnologia Ethernet, desenvolvida por Bob
Metcalfe em 1973 na Xerox PARC agora provavelmente a tecnologia de rede dominante na
Internet e os PCs e estaes de trabalho so os computadores dominantes. A mudana entre
poucas redes com pequeno nmero de servidores (o modelo original ARPANET) e muitas redes
resultou num nmero de novos conceitos e mudanas na tecnologia bsica. Primeiro, isso
resultou na definio de trs classes de rede (A, B e C) para acomodar o alcance das redes. A

22
classe A passou a representar redes de grande escala nacional (pequeno nmero de redes com
grande nmero de servidores). A classe B passou a representar redes de escala regional. E a
classe C passou a representar redes locais (grande nmero de redes com relativamente poucos
servidores).
Uma grande mudana ocorreu como resultado do aumento da escala da Internet e os
assuntos gerenciais associados. Para facilitar o uso da rede, nomes foram atribudos a servidores
para que no fosse necessrio lembrar endereos numricos. Originalmente, o nmero de
servidores foi limitado e, portanto, foi possvel manter uma tabela nica de todos os servidores e
seus nomes e endereos. A mudana para o grande nmero de redes independentemente
gerenciadas (por exemplo, LANs) significou o fim da tabela nica de servidores, e o Domain
Name System (DNS) foi inventado por Paul Mockapetris, da USC/ISI. O DNS permitiu um
mecanismo escalarmente distribudo para resolver nomes de servidores hierrquicos (por
exemplo, www.acm.org) num endereo Internet.
O crescimento da Internet tambm desafiou a capacidade dos roteamentos.
Originalmente existiu um nico algoritmo distribudo para roteamento que foi implementado
uniformemente por todos os roteadores na Internet. Quando explodiu o nmero de redes na
Internet e o desenho inicial de roteamento no expandiu o suficiente, este foi substitudo por um
modelo hierrquico de roteamento com um Interior Gateway Protocol (IGP) usado dentro de
cada regio da Internet e um Exterior Gateway Protocol (EGP) usado para ligar as regies. Este
desenho permitiu que diferentes regies usassem diferentes IGPs, de forma que diferentes
requerimentos de custo, rpida configurao, robustez e escala pudessem ser acomodados. No
apenas o algoritmo de roteamento, mas tambm o tamanho das tabelas de endereamento,
acentuaram a capacidade dos roteamentos. Novas abordagens para agregao de endereo, em
particular roteamento entre domnios sem classe (CIDR) foram introduzidas para controlar o
tamanho das tabelas de roteamento. Um dos maiores desafios foi como propagar as mudanas
para o software, particularmente o software do servidor. DARPA dava suporte UC Berkeley
para investigar modificaes para o sistema operacional Unix, inclusive incorporando o TCP/IP
desenvolvido em BBN. Apesar de Berkeley ter mais tarde reescrito o cdigo para torn-lo mais
adequado ao sistema Unix, a incorporao do TCP/IP no Unix BSD foi crtica para a disperso
dos protocolos na comunidade de pesquisa. Muitos da comunidade de pesquisa da cincia da
computao j haviam comeado a usar Unix BSD no seu dia-a-dia e a estratgia de incorporar

23
protocolos Internet no sistema operacional da comunidade de pesquisa foi um dos elementos-
chave das larga e bem-sucedida adoo da Internet.
Um dos mais interessantes desafios foi a transio do protocolo de servidor da
ARPANET de NCP para TCP/IP em 01/01/1983. Foi uma transio imediata, requisitando todos
os servidores em converso simultnea (ou ento passariam a se comunicar via mecanismos
especficos). A transio foi cuidadosamente planejada pela comunidade por anos antes e foi
muito fcil no dia em que realmente aconteceu (mas teve como conseqncia a distribuio de
"buttons" dizendo "Eu sobrevivi transio para o TCP/IP").
O protocolo TCP/IP tinha sido adotado como padro de defesa trs anos antes, em 1980.
Tal fato levou diretamente eventual diviso entre comunidades militar e no militar. Em 1983,
ARPANET estava sendo usada por um nmero significante de organizaes de pesquisa e
desenvolvimento e de operaes da defesa. A transio da ARPANET do protocolo NCP para o
protocolo TCP/IP permitiu a diviso entre a MILNET, que passou a suportar os requisitos
operacionais, e a ARPANET, que passou a suportar as necessidades de pesquisa.
Portanto, em 1985, a Internet j estava bem estabelecida como uma larga comunidade de
suporte de pesquisadores e desenvolvedores e comeava a ser usada por outras comunidades para
comunicaes dirias pelo computador. O correio eletrnico j estava sendo usado por muitas
comunidades, freqentemente com sistemas diferentes, mas a interconexo entre os diferentes
sistemas de correio foi demonstrando a utilidade de comunicao eletrnica entre as pessoas.













24

2.4. A transio para a infra-estrutura aberta
Ao mesmo tempo em que a tecnologia de Internet estava sendo experimentalmente
validada e largamente utilizada por um conjunto de pesquisadores da cincia da computao,
outras redes e tecnologias estavam sendo criadas. A utilidade das redes computadorizadas -
especialmente o correio eletrnico - demonstrada por DARPA e pelo Departamento de Defesa
dos Estados Unidos no foi perdida em outras comunidades e disciplinas, e, ainda na dcada de
1970, redes comearam a aparecer em qualquer lugar que dispusesse de fundos e recursos para
isso. O Departamento de Energia dos Estados Unidos estabeleceu a MFENet para seus
pesquisadores em energia de fuso magntica e a HEPNet para o grupo de fsica de alta energia.
Os fsicos espaciais da NASA seguiram com a SPAN, e Rick Adrion, David Farber, and Larry
Landweber estabeleceram a CSNET para a comunidade acadmica e industrial da Cincia da
Computao com um subsdio inicial da NSF-National Science Foundation. A livre
disseminao do sistema operacional Unix na AT&T resultou na USENET, baseada no protocolo
de comunicao UUCP includo no Unix, e, em 1981, Ira Fuchs e Greydon Freeman projetaram
a BITNET, que ligou os computadores acadmicos num paradigma do tipo "correio eletrnico
como imagens de carto".
Com a exceo da BITNET e da USENET, estas primeiras redes (incluindo ARPANET)
tinham sido construdas para um objetivo especfico, isto , elas foram criadas para, e largamente
restritas a, comunidades fechadas de acadmicos. Havia pouca presso para que as redes
individuais fossem compatveis e, na verdade, elas no eram. Mais ainda, tecnologias
alternativas estavam sendo procuradas pelo segmento comercial, incluindo XNS da Xerox,
DECNet e SNA da IBM. Restou inglesa JANET (1984) e U.S. NSFNET (1985) programas
para explicitamente anunciar seus intentos de servirem comunidade educacional, no
importando a disciplina. Mais, a condio para universidades americanas receberem fundos do
NSF era que "a conexo deveria estar disponvel para todos os usurios qualificados no campus".
Em 1985, Dennis Jennings, da Irlanda, passou um ano na NSF liderando o programa da
NSFNET. Ele trabalhou com a comunidade para ajudar a NSF a tomar uma deciso crtica: que
TCP/IP iria ser mandatrio para o programa da NSFNET. Quando Steve Wolff chegou
NSFNET em 1986, ele reconheceu a necessidade por uma infra-estrutura de rede maior para

25
suportar as comunidades acadmicas e de pesquisa, alm da necessidade de desenvolver uma
estratgia para estabelecer esta infra-estrutura independentemente dos recursos federais. Polticas
e estratgias foram adotadas para atingir este fim.
NSF tambm decidiu suportar a infra-estrutura organizacional da Internet da DARPA j
existente, hierarquicamente arranjada pelo ento Internet Activities Board (IAB). A declarao
pblica desta opo foi a autoria conjunta pelo grupo de Engenharia e Arquitetura da Internet da
IAB e pelo grupo de Assessoria Tcnica de Rede da NSF do RFC 985 - Requirements for
Internet Gateways, que formalmente assegurou a interoperabilidade entre DARPA e NSF.
Em adio seleo do TCP/IP para o NSFNET, agncias federais norte-americanas
fizeram e implementaram vrias outras decises polticas que definiram a Internet de hoje, como
segue:
Agncias federais norte-americanas dividiram o custo da infra-estrutura, como os
circuitos transocenicos. Elas tambm apoiaram os pontos de interconexo para o trfego entre
agncias. Federal Internet Exchanges (FIX-E e FIX-W) construdas com este objetivo serviram
como modelos para os pontos de acesso da rede e facilidades "*IX" que so caractersticas
proeminentes da arquitetura Internet de hoje;
Para coordenar esta participao, foi formado o Federal Networking Council (Conselho
Federal de Redes). The FNC cooperou com organizaes internacionais como o RARE na
Europa, atravs do Comit de Pesquisa Intercontinental, para coordenar o apoio da comunidade
mundial de pesquisa Internet;
Esta participao e cooperao entre agncias em assuntos relacionados Internet tm
uma longa histria. Um acordo sem precedentes realizado em 1981 entre Farber, representando a
CSNET e a NSF, e Kahn, representando a DARPA, permitiu CSNET compartilhar a infra-
estrutura da ARPANET numa base estatstica;
Similarmente, a NSF encorajou redes regionais (inicialmente acadmicas) da NSFNET a
buscar clientes comerciais, expandir seus estabelecimentos para servi-los e explorar as
resultantes economias de escala para baixar os custos de subscrio para todos;
No backbone da NSFNET, o segmento de escala nacional da NSFNET, NSF fez cumprir
uma poltica (Acceptable Use Policy - AUP) que proibiu o uso do backbone para objetivos que
no fossem de suporte Pesquisa e Educao. O resultado previsvel e desejado do
encorajamento de trfego comercial nos nveis local e regional, enquanto proibindo seu acesso
ao backbone nacional, foi estimular a emergncia e o crescimento de redes privadas e

26
competitivas (como PSI, UUNET, ANS CORE e outras mais tarde). Este processo de aumento de
redes privadas e auto-financiadas para usos comerciais foi iniciado em 1988 numa srie de
conferncias promovidas pela NSF em Harvard's Kennedy School of Government sob o ttulo "A
Comercializao e Privatizao da Internet" e na lista "com-priv" da rede;
Em 1988, o comit do Conselho Nacional de Pesquisa norte-americano, dirigido por
Kleinrock e com Kahn e Clark como membros, produziu um relatrio autorizado pela NSF
intitulado "Em Direo a uma Rede Nacional de Pesquisa". Este relatrio influenciou o ento
Senador Al Gore e anunciou as redes de alta velocidade que se tornariam a fundao para a
superhighway da informao do futuro;
Em 1994, o comit do Conselho Nacional de Pesquisa norte-americano, novamente
dirigido por Kleinrock e novamente com Kahn e Clark como membros, produziu um novo
relatrio autorizado pela NSF entitulado "Fazendo Idia do Futuro da Informao: a Internet e
Alm". Neste documento, a superhighway da informao foi articulada e tpicos crticos como
direitos da propriedade intelectual, tica, preos, educao, arquitetura, e regulamentao da
Internet foram discutidos;
A poltica de privatizao da NSF culminou em abril de 1995, com o fim do subsdio ao
backbone da NSFNET. Os fundos recuperados foram competitivamente redistribudos para redes
regionais para compra de conectividade nacional das agora numerosas redes privadas.
O backbone fez a transio entre a rede construda de roteadores da comunidade de
pesquisa para equipamentos comerciais. Em seus oito anos e meio, o backbone cresceu de seis
nodes com links de 56 Kb para 21 nodes com mltiplos links de 45 Mb. A Internet cresceu para
mais de 50 mil redes em todos os sete continentes, com aproximadamente 29 mil redes apenas
nos Estados Unidos.
Tal foi o peso do ecumenismo e dos recursos da NSFNET (US$ 200 milhes entre 1986
e 1995) e a qualidade dos protocolos, que em 1990, quando a ARPANET foi desautorizada,
TCP/IP tinha suplantado e marginalizado os demais protocolos de rede, e IP estava tambm se
tornando o servio de sustentao da infra-estrutura da informao global.






27
2.5. O papel da documentao
A chave para o rpido crescimento da Internet tem sido o livre e aberto acesso aos
documentos bsicos, especialmente as especificaes dos protocolos.
O incio da ARPANET e da Internet na comunidade acadmico de pesquisa promoveu a
tradio de publicao de idias e resultados. Entretanto, o ciclo normal da publicao acadmica
tradicional era formal e devagar demais para a dinmica troca de idias na criao das redes. Em
1969, um passo importante foi tomado por S. Crocker, ento na UCLA, estabelecendo srie de
notas relativas a "Request for Comments" (RFC, ou, traduzindo, Solicitao de Comentrios).
Estas notas ou memorandos seriam uma forma rpida de distribuio de observaes no
compartilhamento de idias com outros pesquisadores. A princpio, os RFCs eram impressos e
distribudos pelo correio tradicional. Quando o File Transfer Protocol (FTP, significando
protocolo de transferncia de arquivos) comeou a ser usado, os RFCs se tornaram arquivos on-
line acessados via FTP. Agora, claro, os RFCs so facilmente acessados via web em dezenas de
sites no mundo. O SRI-Stanford Research Institute, no papel de Centro de Informao de Redes,
manteve os diretrios on-line. Jon Postel atua at hoje como editor dos RFCs, bem como gerente
da administrao centralizada de nmero de protocolo.
O efeito dos RFCs foi criar um crculo positivo de retornos, com idias e propostas
apresentadas em um RFC gerando outro RFC com mais idias, e da por diante. Quando algum
consenso (ou pelo menos uma srie consistente de idias) era atingido, um documento com as
especificaes era ento preparado. Estas especificaes seriam ento usadas como base para
implementaes pelas vrias equipes de pesquisa.
Com o tempo, os RFCs se tornaram mais focados nos padres de protocolo (as
especificaes oficiais), apesar de ainda existir RFCs informativos que descrevem abordagens
alternativas ou provem informaes antecedentes sobre protocolos e engenharia. Os RFCs so
agora vistos como documentos de registro nas comunidades de engenharia e padres da Internet.
O acesso aberto aos RFCs (grtis, se voc tem qualquer tipo de conexo com a Internet) promove
o crescimento da Internet porque permite que especificaes reais sejam usadas como exemplos
em classes universitrias e por empreendedores desenvolvendo novos sistemas.
O correio eletrnico tem sido essencial em todas as reas da Internet, e especialmente no
desenvolvimento das especificaes dos protocolos, padres tcnicos e engenharia da Internet.
OS RFCs mais antigos apresentaram um conjunto de idias desenvolvidas por pesquisadores de

28
um determinado lugar para o resto da comunidade. Depois que o e-mail ou correio eletrnico
comeou a ser utilizado, o padro de autoria mudou - os RFCs eram apresentados por co-autores
com uma viso comum, independentemente de suas localizaes.
O uso de listas de discusso especializadas tem por muito tempo sido usado no
desenvolvimento das especificaes de protocolo e continua a ser uma ferramenta importante. O
IETF tem agora mais de 75 grupos de trabalho, cada um trabalhando num aspecto diferente da
engenharia da Internet. Cada um desses grupos tem uma lista de discusso para trocar idias
sobre documentos em desenvolvimento. Quando o consenso atingido num rascunho, o
documento ento distribudo como um RFC.
Como o rpido crescimento da Internet acelerado pelo entendimento da sua capacidade
de promover o compartilhamento de informaes, ns deveramos entender que o primeiro papel
da rede foi permitir o compartilhamento da informao sobre seu prprio desenho e operao
atravs dos RFC. Este mtodo nico para a evoluo de novas capacidades da rede continuar a
ser crtico na evoluo futura da Internet.



















29

2.6. A formao da comunidade
A Internet representa tanto uma coleo de comunidades como uma coleo de
tecnologias, e seu sucesso largamente atribudo satisfao das necessidades bsicas da
comunidade e utilizao efetiva da comunidade na expanso da sua infra-estrutura. O esprito
da comunidade tem uma longa histria, comeando com a ARPANET. Os pesquisadores da
antiga ARPANET trabalharam numa comunidade fechada para conseguirem fazer as
demonstraes iniciais da tecnologia de transferncia de pacotes descrita anteriormente. Da
mesma forma, vrios outros programas de pesquisa da cincia da computao promovidos pela
DARPA (Packet Satellite, Packet Radio e outros) foram fruto de atividades cooperadas que
usavam pesadamente qualquer mecanismo disponvel para coordenar seus esforos, comeando
com o correio eletrnico e acrescentando compartilhamento de arquivos, acesso remoto e
WWW. Cada um dos programas formou um grupo de trabalho, comeando com o Grupo de
Trabalho de Rede da ARPANET. Por conta do papel da ARPANET na infra-estrutura de suporte
a vrios programas de pesquisa, e com a evoluo da Internet, o Grupo de Trabalho de Rede se
tornou o Grupo de Trabalho da Internet.
No final da dcada de 70, reconhecendo que o crescimento da Internet foi acompanhado
pelo crescimento em tamanho da comunidade de pesquisa interessada na Internet e que, portanto,
havia uma necessidade maior de mecanismos de coordenao, Vint Cerf, ento gerente do
Programa Internet da DARPA, formou vrios grupos de coordenao: um Conselho de
Cooperao Internacional (ICB-Internet Cooperation Board), presidido por Peter Kirstein da
UCL, para coordenar as atividades com alguns pases europeus envolvidos no programa Packet
Satellite; um Grupo de Pesquisa Internet (Internet Research Group), para prover um ambiente
para a troca geral de informaes sobre a Internet; e um Conselho de Controle de Configurao
da Internet (ICCB-Internet Configuration Control Board), presidido por Clark. O ICCB iria
assessorar Cerf na gerncia da florescente Internet.
Em 1983, quando Barry Leiner passou a gerenciar o programa de pesquisa da Internet na
DARPA, ele e Clark reconheceram que o crescimento contnuo da comunidade Internet
demandava uma reestruturao dos mecanismos de coordenao. O ICCB foi ento substitudo
por foras-tarefa, cada uma focalizando uma rea particular da tecnologia (roteamentos,

30
protocolos ponta-a-ponta, etc.). O IAB, ento chamado Internet Activities Board ou Conselho de
Atividades Internet, foi ento formado com os presidentes das foras-tarefa. Foi uma
coincidncia que esses presidentes fossem os mesmos do antigo ICCB e Dave Clark continuou a
presidi-lo. Depois de algumas mudanas no IAB, Phill Gross se tornou o presidente da
revitalizada IETF-The Internet Engineering Task Force (Fora-Tarefa da Engenharia da
Internet), naquele tempo apenas uma das foras-tarefa do IAB. Em 1985 ento, houve um
tremendo crescimento no lado prtico/da engenharia da Internet. Este crescimento resultou na
exploso dos comparecimentos nas reunies do IETF, e Gross teve que criar uma sub-estrutura
do IETF na forma de grupos de trabalho.
Este crescimento foi complementado por uma grande expanso da comunidade. DARPA
ento tinha deixado de ser o maior financiador da Internet. Alm da NSFNet e de vrias
atividades financiadas pelos governos americano e internacionais, o segmento comercial
comeou a se interessar pela Internet. Tambm em 1985 Kahn e Leiner deixaram a DARPA que
no vinha conseguindo manter seu ritmo de atividades Internet. Como resultado, o IAB perdeu
seu patrocinador e progressivamente assumiu o papel de lder na Internet.
O crescimento da Internet continuou, resultando em nova sub-estruturao do IAB e do
IETF. O IETF combinou Grupos de Trabalho em reas, e designou Diretores de reas. Um
Grupo Diretivo de Engenharia da Internet ou a IRTF- Internet Research Task Force, presidida
por Postel, com as outras foras-tarefa renomeadas como Grupos de Pesquisa.
O crescimento do setor comercial trouxe uma crescente preocupao em relao ao
prprio processo de standards Internet. A Internet tinha crescido muito alm de suas razes
primrias de pesquisa, passando a incluir uma grande comunidade de usurios e atividades
comerciais cada vez maiores. O processo deveria ser aberto e justo. Esta preocupao,
acompanhada da necessidade reconhecida de suporte da comunidade da Internet, eventualmente
levou formao da Internet Society em 1991, com o patrocnio da CNRI-Corporation for
National Research Initiatives de Kahn e a liderana de Cerf, ento com a CNRI.
Em 1992, outra reorganizao foi feita de forma a reorganizar o IAB e renome-lo
Internet Architecture Board (ou Conselho de Arquitetura da Internet) e a coloc-lo sob o
comando da Internet Society. Uma relao de mesmo nvel foi definida entre o novo IAB e i
IESG, com o IETF e o IESG tendo uma maior responsabilidade na aprovao dos standards.
Principalmente, uma relao cooperativa e mutuamente apoiadora foi formada entre o IAB, o

31
IETF e a Internet Society, com a Internet Society tomando como objetivo a proviso do servio e
outras medidas que iriam facilitar o trabalho do IETF.
O recente desenvolvimento e uso da World Wide Web (WWW) formou uma nova
comunidade, j que muitos dos que trabalham com a WWW no so pesquisadores ou
desenvolvedores. Uma nova organizao coordenadora foi formada ento: o W3C-World Wide
Web Consortium. Inicialmente liderado pelo laboratrio para a Cincia da Computao do MIT,
por Tim Berners-Lee (o inventor do WWW) e Al Vezza, W3C tomou a responsabilidade de
evoluir com vrios protocolos e padres associados com a Web.
Assim, atravs das duas dcadas da Internet, ns temos visto uma estvel evoluo das
estruturas organizacionais desenhadas para suportar e facilitar uma sempre crescente
comunidade trabalhando colaborativamente em assuntos ligados Internet. Uma base deste
trabalho a evoluo desde 1957 at os dias de hoje 2003, o nmero de hosts aumentaram de 4
para mais de 180.000.000 de hosts, este dado e outros podem ser verificados na pesquisa de
nome The Internet Timeline onde mostra uma linha de tempo com os eventos mais
significativos na histria da internet, complementando o que foi relatado.


















32

2.7. A comercializao da tecnologia
A comercializao da Internet envolveu no somente o desenvolvimento de servios
privados e competitivos, mas tambm produtos comerciais implementando a tecnologia Internet.
Nos anos 80, dezenas de vendedores incorporaram TCP/IP em seus produtos porque viram
compradores para aquele modelo de rede. Infelizmente, eles no tiveram informao sobre como
a tecnologia trabalhava e como os clientes planejavam us-la. Muitos a viram como um add-on
que deveria ser adicionado s suas solues proprietrias de redes: SNA, DECNet, Netware,
NetBios. O Departamento de Defesa americano tinha autorizado o uso de TCP/IP em muitas de
suas compras, mas tinha dado pouca orientao aos seus vendedores em relao a como construir
produtos TCP/IP de utilidade.
Em 1985, devido falta de informao e falta de apropriado treinamento, Dan Lynch e
o IAB realizaram um workshop para "todos" os vendedores para que eles pudessem aprender
como TCP/IP funcionava e que problemas ainda tinha. Os palestrantes vieram em sua maioria da
comunidade de pesquisa da DARPA, que tinha desenvolvido os protocolos e os usavam
diariamente. Cerca de 250 representantes de vendedores ouviram 50 inventores e
experimentadores. Os resultados foram surpresas em ambos os lados: os vendedores ficaram
impressionados em como os inventores eram to abertos sobre como as coisas funcionavam (ou
no) e os inventores ficaram felizes em ouvir sobre novos problemas que eles no tinham
considerado, mas que estavam sendo descobertos pelos vendedores. Desta forma, uma saudvel
discusso em mo-dupla foi formada, discusso esta que tem durado por mais de uma dcada.
Depois de dois anos de conferncias, tutoriais, encontros e workshops, um evento
especial foi organizado e para o qual foram convidados os fabricantes de produtos que rodavam
TCP/IP bem o suficiente para se reunirem por 3 dias e mostrar o quanto eles trabalhavam bem
juntos - e tambm para examinarem a Internet. Em setembro de 1988, o primeiro Interop trade
show foi realizado, 50 empresas expuseram e 5.000 engenheiros de corporaes consideradas
clientes potenciais vieram ao trade show para ver se tudo funcionava como prometido. E
funcionou! Por que? Porque os fabricantes trabalharam duro para assegurar que os produtos de
todos operariam com todos os outros produtos, mesmo aqueles dos seus competidores. O Interop
trade show tem crescido imensamente desde ento e hoje realizado anualmente em sete locais

33
no mundo, com uma audincia de quase 250 mil pessoas que querem aprender sobre os ltimos
produtos lanados e discutir a mais recente tecnologia da interoperabilidade.
Paralelamente aos esforos de comercializao que foram salientados, os fornecedores
comearam a participar dos encontros do IETF, realizados 3 ou 4 vezes ao ano para discutir
novas idias para extenses do TCP/IP protocol suite. De poucas centenas de acadmicos
presentes e pagos pelo governo, os encontros do IETF agora renem milhares de representantes
de fornecedores e so pagos pelos prprios participantes. O grupo auto-selecionado desenvolve o
TCP/IP numa cooperativa mutua. Isto muito til, j que o grupo bem diversificado,
envolvendo pesquisadores, usurios finais e fabricantes.
A gerncia da rede um exemplo da interao entre a comunidade de pesquisa e a
comunidade comercial. No comeo da Internet, a nfase era definir e implementar protocolos
que atingiam a interoperabilidade. Quando a rede cresceu, ficou claro que procedimentos
especficos usados para gerenciar a rede no mais serviriam. A configurao manual de tabelas
foi substituda pela distribuio de algoritmos automatizados e ferramentas melhores foram
criadas para isolar falhas. Em 1987, ficou tambm claro que seria necessrio um protocolo que
permitisse que os elementos da rede, como roteadores, fossem remotamente gerenciados,
uniformemente. Vrios protocolos foram ento propostos, incluindo o SNMP - Simple Network
Management Protocol (Protocolo de Gerncia de Rede Simples, desenhado para a simplicidade e
derivado de uma proposta anterior chamada SGMP), o HEMS (um design mais complexo da
comunidade de pesquisa) e o CMIP (da comunidade OSI). Uma srie de encontros levou
deciso de que o HEMS seria desconsiderado como candidato para resolver a disputa, mas que o
trabalho em ambos o SNMP e o CMIP prosseguiria, com a idia de que o SNMP poderia ser uma
soluo de curto prazo e o CMIP uma soluo de mais longo prazo. O mercado iria escolher o
que achasse mais adequado. O SNMP agora usado quase universalmente como gerncia de
rede.
Nos ltimos anos, temos visto uma nova fase da comercializao. Originalmente,
esforos comerciais eram dirigidos aos vendedores que proviam os produtos bsicos da rede e
aos provedores que ofereciam conectividade e servios bsicos da Internet. A Internet agora se
tornou quase uma "commodity" e muita ateno tem sido dada recentemente ao uso de sua
estrutura global de informao para suportar outros servios comerciais. Isto tem sido
tremendamente acelerado pela rpida adoo dos browsers e da tecnologia Web, permitindo aos
usurios acessar a informao linkada em qualquer lugar do globo. Produtos esto disponveis

34
para facilitar a proviso desta informao e muito dos ltimos desenvolvimentos em tecnologia
tem sido no sentido de permitir cada vez mais sofisticados servios de informao no topo da
base das comunicaes de dados da Internet.

35
3. MPLS

3.1. Introduo
A Internet foi projetada para troca de informaes apenas via transmisso de texto ou de
arquivos. No era necessria uma alta velocidade de transmisso para suportar esse tipo de
comunicao. Com o crescimento da Internet, em termos geogrficos e, logicamente, de nmero
de pessoas, ela passou tambm a ser vista como um novo e emergente mercado de propores
mundiais. Assim, novas aplicaes (principalmente do tipo multimdia) foram sendo
desenvolvidas para executar sobre a Internet. Exemplos desse tipo de aplicao so aplicaes
interativas que utilizam vdeo, como filmes ou mesmo traillers de filmes; udio, como
transmisso de rdio FM, etc. Outras aplicaes em tempo real, como jogos, tambm esto sendo
executados atravs da rede. No roteamento tradicional em redes IP, que a maioria dos backbones
Internet utiliza como protocolo de comunicao, os pacotes seguem o menor caminho at o
destino, como mostra a figura 3.1. Alguns roteadores podem ento ficar sobrecarregados
enquanto outros so sub-utilizados. Outro problema que as buscas nas tabelas de rotas so
demoradas pois as entradas no tm tamanho fixo: procura-se o maior prefixo de endereo que
coincide com o endereo de destino do pacote (este mtodo conhecido como Longest Match).
Alm disso, o processo de roteamento, incluindo as buscas nas tabelas de rotas, realizado em
cada roteador para cada pacote que chega. A simples aquisio de hardware de roteamento mais
poderoso no corrige esses problemas. Novas tecnologias, como ATM, surgiram para contornar
esses obstculos e suportar as novas aplicaes, provendo servios com diferentes requisitos de
qualidade. Uma delas, o MPLS, alm de oferecer uma soluo elegante no sentido de
simplicidade e eficincia, pode reutilizar o hardware existente, j que ele integrvel com muitas
outras tecnologias. Outros exemplos de vantagens do MPLS so, quando se utiliza esta
tecnologia sobre ATM, a eliminao do problema conhecido como problema N2 que surgiu com

36
IP sobre ATM, em que so necessrias N2 conexes VCs para cada N switches ATM, quando se
utiliza MPLS nas redes IP convencionais, h uma drstica reduo do tempo de busca nas tabelas
de rtulos em comparao com as de roteamento.

F|gura 3-1 - Erv|o de do|s pacoles er ur dorir|o de rolearerlo lP.
Esta pesquisa tcnica sobre MPLS(Multi Protocol Label Switching) uma anlise
interessante, devido a este protocolo estar sendo implementado no Brasil entre 2002 e 2003 para
cormercializao, consolidando muitas das redes atuais para prover servios agregados.
3.1.1. O que MPLS?
Multi Protocol Label Switching um protocolo de comutao de rtulos que trabalha no
nvel de rede. um modelo proposto pelo IETF, projetado somente para rodar nos roteadores
(formando uma sub-rede transparente para o resto da rede). Sua proposta melhorar o trfego
nas redes, principalmente na Internet, utilizando uma soluo elegante, relativamente simples e
que possa tambm aproveitar e integrar-se com tecnologias j existentes como por exemplo
ATM, Frame Relay, Ethernet, OSPF, BGP ou RSVP, aproveitando as melhores caractersticas de
cada uma delas. O MPLS prov meios para separar o roteamento da transmisso dos dados em
redes IP. Os roteadores que ficam na borda (Label Edge Routers LER) da sub-rede MPLS,
recebem os pacotes vindos de redes convencionais e adicionam-lhes rtulos (ou ento retiram, se
os pacotes estiverem saindo do domnio MPLS). Os rtulos indicaro o caminho a ser seguido,
dispensando o roteamento para cada pacote nos roteadores internos rede (Label Switching
Routers LSR), pois este caminho pr-estabelecido. Estes roteadores internos realizam a troca
de rtulos (Label Switching), ou seja, verificam o rtulo do pacote no momento da chegada e o

37
substituem por outro, encaminhando-o para seu destino. Essa substituio realizada pela busca
exata em uma tabela de rtulos, que so pequenos e de tamanho fixo. Os caminhos (Label
Switched Paths LSPs) so estabelecidos apenas uma vez, a no ser que ocorram imprevistos ou
por alguma necessidade do prprio protocolo de distribuio de rtulos (Label Distribution
Protocol - LDP). O estabelecimento se d pela troca de informaes entre os LSRs e LERs e so
realizados antes do incio do trfego de pacotes. Esses pacotes, ainda, so agrupados em classes
de encaminhamento equivalentes (Forwarding Equivalence Classes FECs), que devem receber
o mesmo tratamento. A figura 3.2 ilustra um domnio MPLS.

F|gura 3-2 - Erv|o de do|s pacoles er ur dorir|o de rolearerlo VPL3.

Taoe|a 3-1 3|roo|os dos e|ererlos das l|guras soore VPL3


38

3.2. Conceitos Bsicos
Neste captulo sero apresentados os principais conceitos do MPLS.
3.2.1. Rtulo
um identificador de 20 bits (fixo) que pode ser inserido no pacote entre os cabealhos
dos nveis 2 e 3 ou pode ser encapsulado no nvel 2 como nos campos VPI e/ou VCI nas redes
ATM, ou no campo DLCI das redes Frame Relay . A figura 3.3 ilustra um rtulo.


Rtulo: Contedo do rtulo
Exp: Experimental
S : Controle de pilha
TTL: Tempo de vida
F|gura 3-3 Cod|l|caao da ur|dade lurc|ora| do VPL3


3.2.2. Pilha de Rtulos
O que codificado no pacote, na realidade, uma pilha de rtulos (de unidades de
rtulos), na qual o ltimo rtulo tem o valor 1 no campo S. Mas, para fins de encaminhamento,
somente analisado o rtulo do topo da pilha, ou seja, como se existisse apenas um rtulo. Os
LSRs podem, baseando-se nesta anlise do topo, realizar vrias operaes sobre a pilha. A figura
3.4 ilustra uma pilha de rtulos.

39

F|gura 3-1 P||ra de rlu|os ro VPL3
3.2.3. Pacote Rotulado
um pacote que contm uma pilha de rtulos codificada. Um pacote com uma pilha de
rtulos que contm apenas rtulos nulos , ainda, um pacote rotulado. A pilha com um rtulo
nulo pode ser usada, por exemplo, quando se quer diferenciar uma clula ATM rotulada de uma
no-rotulada .

3.2.4. FEC (Forward Equivalence Class)
um grupo de pacotes que encaminhado seguindo um mesmo critrio. A colocao de
um rtulo em um pacote significa atribuir este pacote a uma determinada FEC. Cada FEC
especificada como um ou mais elementos de FEC . H atualmente dois tipos de elementos de
FEC definidos para o MPLS: prefixos de endereos e endereos completos (prefixos podem ser
tambm completos e havero casos em que tero significado diferente de endereos completos).
Este conceito importante pois, como as FECs agrupam pacotes que se adequam a determinado
critrio, possvel criar FECs para satisfazer requisitos de QoS ou de Engenharia de Trfego. No
MPLS, as FECs no sero mapeadas diretamente com as interfaces de sada do roteador mas sim
com as NHLFEs . A figura 3.5 mostra exemplos de FECs em uma tabela de roteamento comum.

40

F|gura 3-5 FECs er ura rede lP corur

A figura acima mostra a tabela de roteamento do roteador B. As FECs so grupos de
pacotes que recebem o mesmo tratamento. Os pacotes que pertencerem FEC 64.11, por
exemplo, seguiro todos pela interface 2, em direo a D.

3.2.5. NHLFE (Next Hop Label Forwarding Entry)
Esta entrada, ilustrada na figura 3.6, contm todas as informaes que devem ser
aplicadas pilha de rtulos de um pacote. Alm do endereo do prximo vizinho a quem deve
ser encaminhado o pacote, ela contm tambm as seguintes operaes:
trocar o rtulo do topo da pilha por outro novo;
trocar o rtulo do topo da pilha por outro novo e colocar outros
rtulos na pilha;
remover a pilha de rtulos;
como codificar a pilha de rtulos;
qualquer informao que sirva para encaminhar corretamente o
pacote.

41

F|gura 3- 0escr|ao das erlradas NlLFE

3.2.6. ILM (Incoming Label Mapping)
Implementado somente nos roteadores do ncleo, ou seja, utilizado somente para os
pacotes j rotulados. Faz o mapeamento de cada rtulo que entra no domnio em um conjunto de
NHLFEs (geralmente apenas uma NHLFE). No caso de duas ou mais NHLFEs estarem
mapeadas, apenas uma deve ser escolhida. A figura 3.7 ilustra um exemplo de ILM.

F|gura 3-Z Exerp|o delLV
3.2.7. FTN (FEC-to-NHLFE)
Implementado somente nos roteadores da borda , ou seja, utilizado apenas para pacotes
no-rotulados. Faz o mapeamento de cada FEC em um conjunto de NHLFEs. No caso de duas
ou mais NHLFEs serem mapeadas, apenas uma deve ser escolhida. interessante notar que, se o
mtodo Longest Match (ver introduo) for utilizado, ainda haver overhead na busca da FEC
nesta tabela mas, este overhead, existir apenas nos roteadores da borda. A figura 3.8 ilustra um
exemplo de FTN.

42

F|gura 3-8 Exerp|o de FTN
3.2.8. LER (Label Edge Router)
Roteador que fica na borda da rede. Ele responsvel por inserir ou remover pilhas
inteiras de rtulos dos pacotes, dependendo se estes esto entrando ou saindo da rede,
respectivamente. LERs realizam o FTN (no momento da chegada de um pacote ao domnio
MPLS). Tambm devem poder se conectar com redes de diferentes tipos, j que fazem a
fronteira entre o domnio MPLS e as demais. LER uma definio parte do padro MPLS,
criado para facilitar a viso do domnio. Eles so, na verdade, LSRs que tem a capacidade de
fazer fronteira com outras redes.
3.2.9. LSR (Label Switching Router)
Roteador que fica no ncleo da rede. responsvel por fazer a troca, retirada ou insero
de rtulos na pilha mediante o mapeamento (ILM), na NHLFE, do rtulo do topo da pilha. Atua,
junto aos LERs, na troca de mensagens para requisio ou envio de rtulos para manuteno de
LSPs.
3.2.10. Label Merging
Ocorre quando um LSR atribuiu vrios rtulos de entrada para uma determinada FEC e
tem a capacidade para atribuir apenas um rtulo de sada para esta FEC . Pela a utilizao de
bem menos rtulos, o label merging possibilita a utilizao de menos buffers nos LSRs e evita a
manuteno de muitos VCs nos LSRs ATM que trabalham com VC-Merge , o que elimina o
problema N2, citado na introduo.

43

F|gura 3-9 Laoe| Verg|rg
Na figura 3.9 acima o LSR1 tem capacidade de atribuir apenas um rtulo de sada aos
pacotes para mais de um rtulo de entrada da mesma FEC. RX so os rtulos e N2 e N3 so os
cabealhos dos seus respectivos nveis de protolocos.

3.2.11. LSP (Label Switched Path)
Caminho (unidirecional), estabelecido antes do envio de pacotes, ao longo dos
roteadores, que ser seguido por um pacote segundo a anlise do rtulo do topo da pilha. Para
percorrer o sentido inverso necessrio um novo LSP. A prpria estrutura de pilha dos rtulos
permite que se tenha vrios nveis de LSPs na rede, que so chamados de tneis. Para cada LSP
existe um roteador de incio e de fim, geralmente LERs mas LSRs tambm podem ser usados,
inclusive para o estabelecimento de tneis.
3.2.12. LDP (Label Distribution Protocol)
Protocolo que garantir, por meio de trocas de mensagens entre os roteadores (usando
TCP e UDP), que todas as suas tabelas estaro atualizadas e sem conflitos, a fim de manter
corretamente os LSPs. o LDP quem cuidar das requisies e atribuies de rtulos entre os
roteadores . O MPLS no utiliza somente um nico protocolo de distribuio de rtulos. De fato,
vrios protocolos de distribuio de rtulos diferentes esto sendo padronizados. Protocolos
existentes foram estendidos para que a distribuio de rtulos possa ser adicionada, enquanto
novos protocolos foram definidos apenas para o propsito de distribuio de rtulos.

44
3.2.13. CR-LDP (Constraint-Based Routed LDP)
um protocolo de distribuio de rtulos que adiciona caractersticas (restries,
mensagens de erro, ... ) ao LDP, a fim de se implementar Engenharia de Trfego. Engenharia de
Trfego preocupa-se com a otimizao da performance nas redes operacionais. Em geral, une a
tecnologia com princpios cientficos para medir, modelar, caracterizar e controlar o trfego, e a
aplicao de tais conhecimentos e tcnicas para alcanar objetivos especficos de performance .
Ela um processo que melhora a utilizao da rede pela tentativa de criar uma distribuio
uniforme e diferenciada do trfego atravs da rede. Um importante resultado deste processo a
eliminao do congestionamento em qualquer caminho.
importante notar, ainda, que a engenharia de trfego nem sempre escolhe o menor
caminho entre dois dispositivos. possvel que, para dois fluxos de pacotes de dados, os pacotes
percorram caminhos completamente diferentes mesmo se os hosts de sada e chegada forem os
mesmos para ambos os fluxos. A Engenharia de Trfego ento utilizada para se conseguir os
requisitos de qualidade de servio (QoS, Quality of Service), cujos exemplos (udio, vdeo, etc.)
foram citados no incio do captulo . As restries do CR-LDP (exemplificadas na figura 3.10)
so parmetros que so passados para os downstreams nas requisies de atribuio de rtulos a
fim de determinar se eles podem fornecer a qualidade de trfego desejada. Esses parmetros so:
1) ER (Explicit Route), onde pode-se indicar um conjunto de ns a serem seguidos ou
um CR-LSP j existente;
2) Trfego (Traffic Parameters);
3) Preempo (Preemption);
4) LSP-ID;
5) Classes (ou cores) de recursos (Resource Class);
6) Route Pinning. O CR-LDP funciona apenas no modo downstream sob demanda.









45


F|gura 3-10 Corslra|rl 8ased Roul|rg.
Os enlaces que satisfizerem os parmetros, sero utilizados. Alguns parmetros podem
ser negociados, como os de Trfego.

3.2.14. Vizinhos (Next-hops)
Dentro de algum protocolo ou algoritmo de roteamento, vizinhos so dois roteadores
"consecutivos", ou seja, um o prximo n do outro no caminho a ser seguido por um pacote.
Existem tambm as denominaes de vizinho "vlido" e "no vlido" no MPLS. LSR2 ser um
vizinho vlido de LSR1 se LSR2 puder ser o prximo roteador no caminho de um LSP que passa
por LSR1, independentemente do fato do LSP comear antes de LSR1 ou comear nele e
terminar ou continuar aps LSR2.
3.2.15. Colegas (Peers)
So roteadores que trocam informaes de rtulos via LDP. Se forem vizinhos, sero
denominados "colegas locais de distribuio de rtulos". Se no, sero "colegas remotos de
distribuio de rtulos".

46
3.2.16. LSRs Upstream e Downstream
So roteadores que concordaram em atribuir determinado rtulo a uma determinada FEC.
Isso significa dizer que um conjunto de pacotes fluir diretamente do upstream para downstream
mediante colocao (push, pelo upstream), do rtulo na pilha implementada no pacote (rtulo
este que foi escolhido pelo downstream. Mas no implica que esses pacotes no passaro por
outros LSRs. Os dados sempre fluiro do upstream para o downstream, enquanto as atribuies
de rtulos fluiro sempre em sentido contrrio . De uma forma simples, "upstream" e
"downstream" so denominaes que indicam o sentido do fluxo dos dados, das atribuies e das
solicitaes de rtulos entre dois colegas.

F|gura 3-11 l|uslrardo a|gurs dos pr|rc|pa|s corce|los do VPL3.
A tabela da figura 3.11 mostra, para cada roteador MPLS, os seus respectivos vizinhos,
colegas, upstreams e downstreams.

47
3.3. Distribuio de Rtulos
No LDP, foram definidas aes a serem tomadas no momento da distribuio de rtulos.
Um LSR pode requisitar explicitamente uma atribuio de rtulo ou receber uma sem requisitar .
Pode tambm esperar por uma atribuio do seu downstream antes de responder a uma
requisio do seu upstream ou ento responder imediatamente a este mesmo sem ter uma
atribuio do downstream .
3.3.1. Mtodos de Distribuio de Rtulos
A arquitetura MPLS permite a um LSR requisitar explicitamente ao seu vizinho, para
uma FEC particular, uma atribuio de rtulo para esta FEC. Este mtodo conhecido como
downstream sob demanda. A arquitetura MPLS permite tambm que um LSR distribua
atribuies de rtulos para LSRs que no as tenham requisitado explicitamente, mtodo este
conhecido como downstream no-solicitado.
3.3.2. Downstream No-Solicitado
Neste mtodo, um LSRX envia para LSRY uma atribuio de rtulo para uma FEC sem
que LSRY solicite explicitamente. LSRX o faz, por exemplo, quando recebe uma ou mais
atribuies de um novo vizinho vlido para uma determinada FEC e quer distribuir as atribuies
imediatamente para seus colegas upstreams. A figura 3.12 ilustra um exemplo.

F|gura 3-12 0ounsrream rao-so||c|lado
Na figura acima o LSR3 detecta uma nova FEC (prefixo 64.12); LSR3 envia para LSR2
a atribuio de rtulo para a FEC; LSR2 aceita (modo liberal) e ento repete o procedimento
para LSR1.

48

3.3.3. Downstream Sob Demanda
Um LSRX envia para LSRY uma solicitao de atribuio de rtulo para uma FEC, aps
detectar este ltimo como vizinho vlido para esta FEC. Esta deteco pode ser realizada se
LSRY enviar, via OSPF por exemplo, um prefixo para LSRX, tornando-se, ento, um vizinho
vlido para este roteador. Neste caso, o requisitante pode ser um LER de entrada ou ento est
enviando esta requisio como resultado de uma outra requisio que chegou a ele. A figura 3.13
ilustra um exemplo.


F|gura 3-13 0ounsrream soo derarda
Na figura acima o LSR1 requisita ao LSR2 uma atribuio de rtulo para a FEC 64.12;
LSR2 repete o procedimento para LSR3; LSR3 tem um mapeamento e envia para LSR2; LSR2
agora tem um mapeamento e envia para LSR1.

3.3.4. Controles de Distribuio de Rtulos
O comportamento do estabelecimento inicial dos LSPs ser determinado pelo tipo de
operao com a qual os LSRs trabalham: independente ou ordenado .


49
3.3.5. Independente
No controle independente, se estiver sendo utilizado o mtodo downstream no
solicitado, o LSR downstream decide distribuir os rtulos para seus colegas logo que detecta um
novo vizinho vlido (que ser o downstream desse) para uma FEC. No mtodo sob demanda, o
LSR pode responder atribuies de rtulos para seus colegas (upstreams) logo que receba
solicitaes destes, mesmo que no tenha recebido ainda uma atribuio do seu downstream . As
figuras 3.14 e 3.15 ilustram exemplos de controle de distribuio independente com downstream
no-solicitado e downstream sob demanda, respectivamente.

F|gura 3-11 Corlro|e |rdeperderle cor oounsrream rao-so||c|lado
Os nmeros indicam a ordem temporal em que a atribuio foi enviada.

F|gura 3-15 Corlro|e |rdeperderle cor oounsrream soo derarda.
Os nmeros indicam a ordem temporal em que a atribuio foi enviada. Nota-se aqui que
no necessrio que o roteador tenha um rtulo para a determinada FEC para enviar a
atribuio solicitada.

50
3.3.6. Ordenado
Se um LSR no for o roteador de sada para um LSP ou no tiver um mapeamento para
uma determinada FEC, ele deve esperar, antes de enviar qualquer atribuio para seu(s)
upstreams, at que um downstream seu envie uma atribuio de rtulo para aquela FEC. O LSP
ento formado de maneira ordenada primeiro pelo caminho de solicitao, do LSR solicitante
para o LSR de sada, e depois voltando pelo sentido inverso. A figura 3.16 ilustra um exemplo de
controle ordenado de distribuio com downstream sob demanda.

F|gura 3-1 Corlro|e orderado cor oounsrream soo derarda.
Os nmeros indicam a ordem temporal em que a atribuio foi enviada. Nota-se aqui que
necessrio que o roteador tenha um rtulo para a determinada FEC para enviar a atribuio
solicitada. Para que isso ocorra ele tem que requisitar tambm uma atribuio ao seu
downstream. Se nenhum LSR tiver, o LER de sada ir gerar uma atribuio e envi-la ao seu
upstream.

3.3.7. Modo de Reteno de Rtulos
Um LSR1 pode receber (ou ter recebido) uma atribuio de rtulo para uma FEC de um
LSR2, mesmo que LRS2 no seja o vizinho de LSR1 (ou no mais) para aquela FEC. LSR1
tem a escolha de manter tais atribuies (modo liberal) ou descart-las (modo conservativo). Se
LSR1 as mantiver, ele pode imediatamente reutiliz-las se LSR2 eventualmente vier a ser o
vizinho para a FEC em questo. Se LSR1 descart-las, ento neste caso, as atribuies devem ser
readquiridas .

51
3.3.8. Conservativo
Neste modo de reteno, as atribuies de rtulos, recebidas de vrios vizinhos, so
descartadas logo que o LSR percebe que elas no servem para repassar pacotes vindos dos LSPs
(dos seus upstreams) que esto nele mapeados. Ou seja, vem de vizinhos no vlidos. Isso se o
LSR estiver operando em downstream no-solicitado, que recebe atribuies de rtulos de todos
os colegas. Se estiver operando em downstream sob demanda, as solicitaes de atribuies de
rtulos so enviadas no todos os seus colegas, mas apenas aos colegas locais de distribuio
de rtulos . A vantagem do modo conservativo que o roteador no necessitar de grandes
buffers mas, por outro lado, caso ocorram mudanas ou falhas, ser necessrio requisitar
novamente as atribuies dispensadas, o que causar envio de mais mensagens de controle. A
figura 3.17 ilustra um exemplo de modo conservativo com controle independente e downstream
no-solicitado.

F|gura 3-1Z Vodo corserval|vo cor corlro|e |rdeperderle e oounsrream rao so||c|lado.
Os LSRs 1 e 4 descartam as atribuies recebidas dos LSRs 3 e 2 respectivamente.










52

3.3.9. Liberal
No modo liberal, as atribuies de rtulos recebidas pelo LSR que no servirem para
repassar pacotes vindos dos LSPs (dos seus upstreams) que esto nele mapeados, sero mantidas
para utilizao futura. Esse modo tem a desvantagem de consumir mais buffers dos LSRs. A
vantagem que se houver alguma mudana no roteamento, no ser necessrio, para o LSR que
manteve as atribuies, solicitar ou esperar pelas atribuies, tendo um ganho de tempo e
liberao de banda da rede. A figura 3.18 ilustra um exemplo de modo liberal com controle
independente e downstream no-solicitado.

F|gura 3-18 Vodo ||oera| cor corlro|e |rdeperderle e doWrslrear rao-so||c|lado.
Os LSRs 1 e 4 mantm as atribuies recebidas dos LSRs 3 e 2 respectivamente.
3.3.10. Exemplo de utilizao das formas de distribuio de rtulos
As formas de distribuio de rtulos citadas neste captulo podem ser implementadas
dentro do mesmo domnio MPLS, contanto que cada roteador tenha conhecimento do tipo de
distribuio que o seu colega est usando. A figura 3.19 ilustra um exemplo.


53

F|gura 3-19 0|slr|ou|ao de rlu|os
Neste exemplo, os LSRs 1, 2 e 3 operam em downstream sob demanda enquanto os
LSRs 4 e 5 operam em downstream no-solicitado. Primeiramente, LSR5 detecta uma nova FEC
(prefixo 64.12) e, como funciona com controle independente, envia para LSR4 a atribuio de
rtulo para esta FEC. LSR4, que funciona no modo liberal com controle independente, retm a
atribuio e envia imediatamente uma atribuio para LSR3. LSR3 funciona no modo liberal
mas com controle ordenado. Ento ele retm a atribuio mas no envia outra imediatamente
para LSR2. LSR1 requisita ao LSR2 uma atribuio de rtulo para a FEC 64.12. LSR2 repete o
procedimento para LSR3 que tem um mapeamento e envia para LSR2 (nota-se que se LSR3
funcionasse em modo conservativo teria que requisitar ou esperar que LSR4 enviasse novamente
a mesma atribuio. LSR2 agora tem um mapeamento e envia para LSR1, completando o LSP.








54

3.4. Roteamento
No MPLS existem duas formas de roteamento: N a N e Explcito. Roteamento aqui
quer dizer o modo como os LSPs sero criados. O fato dos LSPs serem caminhos pr-
estabelecidos, ou seja, um LER, ao receber um pacote, escolher um LSP j criado, no quer
dizer que sempre sero criados explicitamente e nem que so caminhos explcitos.
3.4.1. Roteamento N a N (Hop by Hop)
Nas redes IP, em geral, os pacotes seguem o menor caminho entre a fonte e o destino.
Esse caminho vai sendo percorrido atravs de cada roteador pela escolha da entrada da tabela de
roteamento cujo prefixo de endereo o maior que se encaixa no endereo de destino do pacote
(Longest Match). O roteamento n a n no MPLS, via LDP, utiliza as mesmas entradas das
tabelas de rotas, aps estas serem criadas por um determinado protocolo de roteamento que pode
ser OSPF, BGP, RIP ou outros. A partir da, so atribudos um ou mais rtulos de entrada e sada
para cada prefixo de endereo da tabela de roteamento existente. Em seguida, esses rtulos sero
distribudos para todos os seus vizinhos. Como essa distribuio realizada mediante LDP, nem
todas as requisies ou envio de atribuies sero obrigatoriamente aceitos. Tambm possvel
que o MPLS utilize as prprias mensagens destes protocolos para enviar as suas, a figura 3.20
ilustra um exemplo. Uma das vantagens de se usar o MPLS sobre o roteamento n a n
tradicional que s existir roteamento de pacotes de dados na borda do domnio, pois aps o
estabelecimento dos LSPs, o encaminhamento de pacotes ser realizado apenas pela troca de
rtulos.



55

F|gura 3-20 Rolearerlo r a r er VPL3.
A tabela acima em cor cinza representa parte das tabelas de roteamento que esto
em cada roteador. As tabelas restantes so a representao das tabelas MPLS que foram
geradas pelo LDP, mediante atribuio de um rtulo de entrada e um de sada para cada
prefixo de endereo da tabela de roteamento.


3.4.2. Roteamento Explcito
Existem casos onde opta-se pela escolha de um caminho diferente do que foi estabelecido
pelo roteamento utilizado. Esse caminho chamado de Explicit-Routed LSP (ERLSP). O ER-
LSP uma das funcionalidades (restries) do CR-LDP . Esse caminho formado pelo envio de
uma requisio de atribuio contendo todos os ns que devem formar o LSP (figura 21) ou
ento pode simplesmente indicar um LSP j estabelecido. possvel utilizar tambm o RSVP
para realizar o roteamento explcito (CR-LPD e RSVP esto na definio padro MPLS para
roteamento explcito). A diferena ser apenas que as requisies de atribuio de rtulos sero
encaminhadas em mensagens Path State e as atribuies em mensagens Resv.

56

F|gura 3-21 Rolearerlo exp|ic|lo.
O roteamento explicito formado pela restrio de ns, com CR-LDP. O LSR1envia
uma requisio de atribuio contendo o caminho explcito. As mensagem ento percorre o
caminho desejado at o fim (LSR5) e depois so retornadas as atribuies. Note que o
funcionamento do protocolo de distribuio do tipo downstream sob demanda . Se for
utilizado o RSVP para o roteamento explcito, a diferena ser apenas que as requisies de
atribuio de rtulos sero encaminhadas em mensagens Path State e as atribuies em
mensagens Resv.


3.4.3. Tunneling
Em ambos os tipos de roteamento possvel a implementao de tneis. Tneis so
caminhos ocultos formados entre dois roteadores que sero os pontos de sada e de chegada.
Nenhum roteador no caminho do tnel conseguir enxergar os dados enviados por ele. Uma
das maneiras de se conseguir o tunneling, nas redes IP usuais, com a utilizao de IP sobre IP,
no qual o roteador de sada encapsula o pacote IP em outro cabealho IP. O pacote encapsulado
ser processado apenas pelo roteador de chegada. Isto til, por exemplo, para criar redes
virtuais privadas (VPNs). No MPLS, o tunneling realizado utilizando-se da estrutura de pilha
em que so codificados os rtulos. No padro MPLS, no necessrio que o LSR de chegada
saiba distinguir se o pacote recebido veio do tnel ou no. A figura 3.22 ilustra um exemplo.

57

F|gura 3-22 Tunne||ng er redes VPL3.
Nesta rede MPLS existem dois LSPs: LSP, passando por LER1, LSR 2 e LER 3 e o
LSP, passando pelos LSRs A, B e C (que formam o tnel, interligando LSR 2 e LER 3). LER1
recebe um pacote, detecta que ele ir pertencer uma determinada FEC (LSP), insere na pilha
o rtulo R1 correspondente e encaminha para LSR2, que recebe o pacote, troca o rtulo R1 por
R2, adiciona o rtulo Ra na pilha, referente ao LSP, e envia para LSRA. LSRA ir trocar o
rtulo do topo, no caso, Ra, por Rb e repassar para LSRB, que ir trocar o rtulo do topo, no
caso, Rb, por Rc e repassar para LSRC. LSRC ir retirar o rtulo do topo da pilha e repassar para
o LER3. Neste caso, LSRC ir retirar o rtulo Rc, sobrando apenas o rtulo R2. LER3 ir ento
analisar o rtulo que est no topo (R2, intacto) e realizar as operaes necessrias. Nota-se que
LER 1 e LSR 2 so colegas locais de distribuio de rtulos, assim como os LSRs A, B e C. J
LSR 2 e LER 3 so colegas remotos de distribuio de rtulos,







58
3.5. Encapsulamento do Rtulo
Em estabelecido um padro para a codificao da pilha de rtulos nos pacotes. A pilha
codificada seguindo este padro, deu-se o nome de shim label, pois no ocupa espao no
cabealho, mas adicionada ao pacote. Este padro ser seguido, independentemente da
tecnologia de nvel 2 empregada, mas podem haver diferenas na codificao do topo da pilha,
que no necessariamente deve estar no shim label. Neste captulo, sero mostradas trs
tecnologias (Ethernet, ATM e Frame Relay) que podem ser utilizadas para essa codificao.
3.5.1. Ethernet
Cada pacote de uma rede Ethernet tem um endereo de fonte e destino, ambos
identificados no cabealho. Um pacote enviado por esta rede chegar a todas as estaes, que
podem copiar este pacote em suas memrias locais, mas, normalmente, somente a estao cujo
endereo coincide com o endereo de destino do pacote ir process-lo . O shim label, inclusive
com o topo da pilha, inserido entre o cabealho de nvel 2 e o de nvel 3, este geralmente do
protocolo IP. Os roteadores devem ento ser capazes de identificar um pacote rotulado e realizar
as operaes necessrias sobre ele. Como a Ethernet funciona com envio de pacotes para todas
as estaes, necessrio que o LSR saiba identificar tambm se o pacote rotulado foi enviado
realmente para ele. A colocao de uma pilha com mais de um rtulo pode causar estouro do
MTU (Maximum Transfer Unit) do nvel 2, o que exige que o roteador suporte o parmetro
Maximum Initially Labeled IP Datagram Size e qualquer pacote no rotulado que tenha
tamanho maior que esse parmetro deve ser fragmentado. O campo TTL do rtulo deve receber
o mesmo valor do TTL do IP, no momento da entrada do pacote no domnio MPLS e no
momento da sada, o valor do TTL do IP deve receber o valor do TTL do rtulo. A figura 3.23
ilustra um pacote Ethernet rotulado.


F|gura 3-23 Ercapsu|arerlo do rlu|o er ur pacole de ura rede Ernerner.


59

3.5.2. ATM
Na tecnologia ATM, cada clula de envio de dados possui, em seu cabealho, dois
campos chamados VPI e VCI, que funcionam como rtulos no nvel da camada ATM. Estes
rtulos so utilizados para identificar uma conexo com canal virtual (Virtual Channel
Connection VCC) atravs de uma ou mais conexes de caminho virtual (Virtual Path
Connection VPC) entre dois switches ATM. Tem-se ento duas hierarquias de multiplexao
(um VPC contm vrios VCCs). Existem dois modos de estabelecimento dos canais e caminhos:
permanente, com PVC (Permanent Virtual Connection) e PVP (Permanent Virtual Path) ou
temporrio com SVC (Switched Virtual Connection) e SVP (Switched Virtual Path).
Independentemente do tipo de conexo (VCC ou VPC), o rtulo do topo ser codificado nos
campos VPI e/ou VCI. O restante da pilha dever ser codificado utilizando-se o shim label, na
rea de dados. As formas de encapsulamento so 3: SVC Encoding, SVP Encoding e SVP
Multipoint Encoding .
3.5.3. SVC Encoding
Usa os campos VPI/VCI para codificar o rtulo que est no topo da pilha. Esta tcnica
pode ser usada em qualquer rede ATM. Com esta codificao, cada LSP funciona como um
SVC, e o protocolo de distribuio de rtulos funciona como o protocolo de sinalizao ATM .

F|gura 3-21 Ercapsu|arerlo do rlu|o er ura c|u|a ATV ro 3vC
Nota-se que o rtulo colocado est topo da pilha nos campos VPI e VCI de um cabealho
de clula ATM, no SVC Encoding.



60
3.5.4. SVP Encoding
Neste encapsulamento, ilustrado na figura 73, o campo VPI usado para codificar o
rtulo do topo da pilha, e o campo VCI para codificar o segundo rtulo da pilha, se este estiver
presente. Esta tcnica oferece vantagens sobre a anterior, uma vez que permite o uso do
Vpswitching do ATM. Os LSPs funcionam como SVPs, e o protocolo de distribuio de rtulos
funciona como o protocolo de sinalizao ATM. No entanto, esta tcnica no pode sempre ser
usada . Se existir nesta rede um virtual path atravs de uma rede ATM no-MPLS, ento o
campo VPI no necessariamente estar disponvel para uso do MPLS. Quando esta tcnica
usada, o ATM-LSR de sada faz uma operao de pop na pilha .


F|gura 3-25 l|uslraao do ercapsu|arerlo do rlu|o er ura c|u|a ATV ro 3vP


3.5.5. SVP Multipoint Encoding
Usa o campo VPI para codificar o primeiro rtulo do topo da pilha, parte do VCI para o
segundo rtulo, se este existir, e o resto do VCI para identificar a entrada do LSP. Com esta
tcnica, as capacidades convencionais de VP-switching do ATM podem ser usadas para prover
conexes VPs multiponto a ponto. Clulas de diferentes pacotes carregaro, ento, diferentes
valores de VCI. Isto habilita o label merging , sem encontrar com problemas de intercalao de
clulas, em switches ATM que podem prover VPs multiponto a ponto mas no tem capacidade
de VC-merge . A figura 3.26 ilustra o encapsulamento.


61

F|gura 3-2 Ercapsu|arerlo do rlu|o er ura c|u|a ATV ro 3vP ru|l|po|rl Ercod|rg
Ilustrao do encapsulamento dos rtulos do topo da pilha nos campos VPI e parte do
VCI em um cabealho de clula ATM, no SVP Multipoint Encoding.


3.5.6. Frame Relay
O rtulo do topo carregado no campo DLCI do cabealho. Podem ser usados tanto 2
como 4 octetos do endereo Q.922 (10, 17, 23 bytes). Assim como no ATM, o rtulo do topo
codificado no campo DLCI enquanto o topo do shim label dever conter o valor explicit null .
A figura 3.27 ilustra o encapsulamento.


F|gura 3-2Z Ercapsu|arerlo da p||ra de rlu|os ra c|u|a Frame Re|a,.




62
4. Experincia Pratica


A descrio destas experincias prticas tem como objetivo nos auxiliar a demonstrar o
rumo que os servios de telecomunicaes esto tomando com base em levantamentos realizados
nos clientes, os quais indicam a necessidade de mudana de tecnologia e de mudana de
relacionamento entre empresa e cliente.

4.1. Empresa Diveo do Brasil

A Diveo Broadband Networks, Inc. uma empresa de infra-estrutura de Internet e
provedora de comunicaes. Oferece servios atravs de uma rede de banda larga fixa sem fio e
de fibra, disponibilizando sua conectividade de "primeira milha" para prover servios de Internet,
dados, voz e vdeo. a nica empresa da Amrica Latina a oferecer uma rede pan-regional de
Internet Data Centers de ltima gerao e padro mundial, abrangendo mais de 37.500m de
Web Hosting e espao para Colocation. Alm dos servios de Data Centers (hosting dedicado,
colocation, largura de banda, servios de entrega de contedo e servios gerenciados), a Diveo
disponibiliza tambm Links Dedicados, que incluem linha privada, acesso dedicado a Internet,
frame relay e ATM. A Diveo foi fundada em 1996, visando suprir uma nova demanda por
servios de banda larga e de Internet de alta qualidade na Amrica Latina. Desde ento, vem
atuando com sucesso nos maiores mercados, oferecendo o que h de melhor em infra-estrutura
Internet. Levantou US$ 1 bilho em fundos, incluindo US$ 400 milhes em investimentos

63
privado, atravs de alguns dos maiores fundos de investidores em empresas de telecomunicaes
e tecnologia, como GS Capital Partners III, Texas Pacific Group/Newbridge Latin America, Alta
Communications, Booth American, Columbia Management, Meritage Private Equity Fund L.P.,
Norwest Venture Partners, One Liberty Ventures, e um fundo de capital privado da Rothschild
Family. Investimentos slidos marcam toda a trajetria da Diveo: dois dos melhores
fornecedores de equipamentos do setor, a Ericsson e Lucent Technologies, investiram US$ 600
milhes em fundos, permitindo que a Diveo expandisse seus negcios e construsse redes de
banda larga de acesso local e Internet Data Centers em toda a Amrica Latina. No ano passado a
Ericsson incorporou a Diveo, tornando-se um de seus acionistas marjoritrios. Em Porto Alegre a
Diveo iniciou suas operaes em 1999.

A foto ao lado mostra a principal
Infra-estrutura necessria para
prover acesso de ultima milha aos
cliente.





F|gura 1-1 lu8 3|le da 0|veo

A foto ao lado do centro de
Operaes da Diveo onde se
monitoram todos os cliente para se fazer
a recuperao ou criao dos circuitos.




F|gura 1-2 N0C ( heruork Dperar|on 0enrer)


64
5. Concepo de Rede
As redes utilizadas nas principais empresas de telecomunicaes, possuem muitos pontos
em comum, com isso, de uma certa forma, podemos utilizar o exemplo (Diveo) para explicar a
topologia que se faz necessria para fornecimento dos principais servios em telecomunicaes.
5.1. Rede atual (Descrio dos Elementos)
A rede atual da Diveo do Brasil de baseia em tecnologia ATM sobre SDH. Nesta figura
segue uma topologia utilizada em um site da Diveo em Porto Alegre.


F|gura 5-1 Topo|og|a de ur s|le para lorraao de ur 8ac|oore ATV.
Elementos necessrios para insero de clientes em um Backbone e um modelo de
gerncia dos mesmos, atravs de endereamentos IPs.


65
5.1.1. Backbone ATM Multiservio Dveo:
Toda a infra-estrutura utilizada no Backbone ATM Multiservio Dveo se caracteriza
por:
Interfaces disponveis: UNI e PNNI;
Tratamento de rotas: BGP4 ( servios IP);
Velocidades disponveis para acesso cliente: Mltiplos de E1, E3, e STM1

5.1.2. Equipamento de enlace de microondas: SDH

Os enlaces em SDH so responsveis pelo trfego de alta capacidade da rede de
transmisso. Seu trfego constitudo basicamente dos dados provenientes dos rdios PDH
(explicados adiante). A configurao topolgica da rede SDH feita de tal maneira a permitir
uma proteo no s do enlace propriamente dito, mas tambm da rede como um todo. Tal
topologia chamada de SDH ring, e a proteo em si chamada de self-heeling, isto , os dados
podem trafegar tanto no sentido horrio quanto no anti-horrio.
Os rdios SDH tm como caractersticas principais:
Freqncia de operao na faixa de 7,15,18 GHz;
Capacidade de transmisso STM-1 (aproximadamente 155 Mbps);
Modulao tipo 128TCM;
Sistema de superviso remoto;
Unidade de alarme (entrada e sada de alarmes);
Canal de servio (dados e voz);
Unidade de sincronizao usado para sincronizar o trfego a um clock externo;
Possibilidade de adaptao para diversidade de espao e diversidade de
freqncia;










66

5.1.3. Switch ATM
O Switch ATM utilizado no core do Backbone ATM Multiservio Dveo , o CBX500
da Lucent. Este switch tem como principais caracteristicas:
Backplane de 5Gbps, redundante;
Interfaces ATM: STM-4c/OC-12c, STM-1/OC-3 (tica e eltrica), E3;
Classes de servio: CBR, rt-VBR, nrt-VBR, UBR, ABR;
Redundncia: Switch Fabric, Control Processor e Interfaces, todos em hot stand by;
Emulao de Circuitos (Clear Channel) em velocidades de 2048 Kbps
ATM/FRAME RELAY: UNI,TM 4.0,IFSP,PNNI,FRF5,FRF8
IP/MPLS:BGP4,OSPF,RIP,MOSPF
Ethernet: 10/100 Mps

Este equipamento responsvel pelo chaveamento dos STM1 entre as HUBs.

5.1.4. Sincronizao de rede.

O Backbone ATM Multiservio Diveo tem fonte de clock originria a partir de um
relgio com classificao Stratum 1, operando em modo redundante por duas fontes de clock.
Isto garante que o Backbone possa gerar toda a sinalizao de clock necessria sua operao,
garantindo uma alta qualidade de servio. Atualmente existe um GPS da Acterna(Time Source
3100), este equipamento funciona com a sinalizao de 3 12 satlites, em caso de falha pode-
se: utilizar uma porta spam a qual pode utilizar um E1 externo para trazer o sincronismo para a
rede; e em ltimo caso utiliza o oscilador interno do equipamento.







67
5.1.5. Equipamento de enlace de microondas (PDH):
Este item est um pouco mais detalhado, pois trata-se do acesso ltima milha(last mile),
onde cada cliente um caso. Portanto segue abaixo um levantamento realizado sobre rdios e
equipamentos que so necessrios para prover este acesso de conexo do cliente ao Backbone.
Geralmente so rdio para conexo do site do Cliente at o Backbone Diveo para trfego
de 2x2Mbps at 17x2Mbps , com estrutura instalada composta por rdio 15, 18, 23 ou 38GHz
freqncia relacionada distncia do Pop a HUB mais prxima .
Estes rdios so formados por unidade externa de RF(ODU) acoplada a antena de 30 ou
60 cm e interligada atravs de cabo coaxial LMR-300 ,400 ou 600 (definio do cabo
relacionada a distncia entre IDU e ODU) a unidade interna IDU que fornece interligao rede.
O rdio opera com tenso DC de -48 V fornecida por retificador alimentado com 220 ou 110 V
AC , o sistema possui autonomia de 4 horas de bateria.
A ODU e a antena suportada por mastro fixado em torre , parapeito ou laje e a IDU
instalada em bastidor 19`` ou gabinete externo ambos com retificador -48V e banco de baterias
para 4 horas.
Os equipamentos de microondas PDH so descritos da seguinte forma:

ODU - Composta de Antenas, RAU, Cabos de FI, Power Splitter e acessrios.

O RAU ( Radio Unit) , junto com a antena, a parte externa do MINI-LINK E Terminal. O RAU
totalmente independente da capacidade de trfego e disponvel para diferentes canais de
freqncia de acordo com as recomendaes do ITU-R e CEPT.
A parte outdoor possui as antenas nas seguintes freqncias:7, 15, 18, 23 e 38 Ghz..

RAU + Antena
F|gura 5-2 Arlera de 0, r de d|relro rorlada cor a RAu (Rad|o ur|l) acop|ada



68
Existem situaes em que a RAU pode ser instalada separada da Antena. Isso acontece
quando a antena maior que 0,6 m (exemplo 1,2m) ou quando o enlace protegido (redundante
ou 1+1). Veja figuras abaixo:

Kit Montagem Separada. Liga RAU Antena

RAU
F|gura 5-3 Rau cor ||l de rorlager separada da arlera(er|ace 10)
Exemplo de enlace 1+1 (redundante). Usamos para proteger o enlace, quando se trata de
alta capacidade transmisso de dados. Ao existir qualquer problema na RAU 1 por exemplo, a
RAU 2 assume o funcionamento automaticamente.
Mais adiante veremos que a parte da IDU precisa ter tambm sua redundncia nesses casos.




RAU 1 RAU 2 Power Splitter (compartilha a antena com as 2 RAUs)

F|gura 5-1 RAu cor PoWer 3p||ller(er|ace 11)


69
Exemplo de diversidade de espao. usado quando necessitamos de um enlace
redundante, mas usamos 2 antenas. Isso ocorre quando existe um evento intermitente, por
exemplo : uma mquina que passa periodicamente em frente a uma antena, atrapalhando o sinal
do Rdio, ora o conjunto RAU1 + Antena1 est em funcionamento, ora a RAU2 + Antena2.
muito raro usar este tipo de enlace em circuitos disponibilizados cliente, pois o custo
muito elevado, esta configurao utiliza-se em gateways.



F|gura 5-5 Topo|og|a ul|||zada para d|vers|dade de espao


F|gura 5- K|l Vorlager separada
Explodido (composto de guia de onda, barra de fixao e acessrios).


70

MODELOS de RAU utilizados (freqncia / sub-banda):

Os modelos descritos abaixo, so os utilizados pela Diveo, pois a Ericsson possui outros
modelos. Esta descrio para mostrar os equipamentos que foram aplicados no projeto dos
cases que sero apresentados:
- 15 Ghz
15/24 (TX baixa), faz par com 15/28 (TX alta) - usadas para at 8E1.
-18 Ghz
18/23 (TX baixa), faz par com 18/27 (TX alta) usadas para at 4E1.
18/32 (TX baixa), faz par com 18/36 (TX alta) usadas de 8E1 a 16E1.
18/31 (TX baixa), faz par com 18/35 (TX alta) usadas de 8E1 a 16E1.
-23 Ghz
23/22 (TX baixa), faz par com 23/24 (TX alta) usadas de 2E1 a 16E1.
-38 Ghz
38/13 (TX baixa), faz par com 38/17 (TX alta) usadas para 4E1.
38/12 (TX baixa), faz par com 38/16 (TX alta) usadas para 2E1, 8E1 e 16E1.

F|gura 5-ZL|gaao erlre 00u e a l0u


RAU
Magazine c/
MMU (IDU)
Cabo FI,
liga RAU
MMU

71
Taoe|a 5-1 0|slrc|a do Rad|o Er|ace x Frequrc|a


TABELA DISTNCIA x TIPO DE EQUIPAMENTO
Polarizao Vertical
ERICSSON
Tipo de Equipamento Configurao Capacidade Dimetro de 0,3m Dimetro de 0,6m
Mini-Link 38GHz (1+0) 2xE1 0,05 km ~ 1,29 km 0,70 km ~ 1,50 km
Mini-Link 38GHz (1+1) 2xE1 0,05 km ~ 1,10 km 0,70 km ~ 1,36 km
Mini-Link 38GHz (1+0) 4xE1 0,05 km ~ 1,21 km 0,70 km ~ 1,42 km
Mini-Link 38GHz (1+1) 4xE1 0,05 km ~ 1,03 km 0,70 km ~ 1,28 km
Mini-Link 38GHz (1+0) 8xE1 0,05 km ~ 1,14 km 0,70 km ~ 1,31 km
Mini-Link 38GHz (1+1) 8xE1 0,05 km ~ 0,96 km 0,70 km ~ 1,21 km
Mini-Link 38GHz (1+0) 16xE1 0,05 km ~ 1,07 km 0,70 km ~ 1,24 km
Mini-Link 38GHz (1+1) 16xE1 0,05 km ~ 0,89 km 0,70 km ~ 1,14 km
ERICSSON
Tipo de Equipamento Configurao Capacidade Dimetro de 0,6m Dimetro de 1,2m
Mini-Link 23GHz (1+0) 2xE1 1,00 km ~ 3,25 km 1,80 km ~ 3,75 km
Mini-Link 23GHz (1+1) 2xE1 1,00 km ~ 2,91 km 1,80 km ~ 3,73 km
Mini-Link 23GHz (1+0) 4xE1 1,00 km ~ 3,05 km 1,80 km ~ 3,53 km
Mini-Link 23GHz (1+1) 4xE1 1,00 km ~ 2,72 km 1,80 km ~ 3,52 km
Mini-Link 23GHz (1+0) 8xE1 1,00 km ~ 2,86 km 1,80 km ~ 3,25 km
Mini-Link 23GHz (1+1) 8xE1 1,00 km ~ 2,55 km 1,80 km ~ 3,52 km
Mini-Link 23GHz (1+0) 16xE1 1,00 km ~ 2,68 km 1,80 km ~ 3,00 km
Mini-Link 23GHz (1+1) 16xE1 1,00 km ~ 2,38 km 1,80 km ~ 2,98 km
ERICSSON
Tipo de Equipamento Configurao Capacidade Dimetro de 0,6m Dimetro de 1,2m
Mini-Link 18GHz (1+0) 2xE1 3,00 km ~ 5,26 km 3,00 km ~ 6,78 km
Mini-Link 18GHz (1+1) 2xE1 3,00 km ~ 4,73 km 3,00 km ~ 6,60 km
Mini-Link 18GHz (1+0) 4xE1 3,00 km ~ 4,89 km 3,00 km ~ 6,18 km
Mini-Link 18GHz (1+1) 4xE1 3,00 km ~ 4,38 km 3,00 km ~ 6,15 km
Mini-Link 18GHz (1+0) 8xE1 3,00 km ~ 4,65 km 3,00 km ~ 5,75 km
Mini-Link 18GHz (1+1) 8xE1 3,00 km ~ 4,17 km 3,00 km ~ 5,72 km
Mini-Link 18GHz (1+0) 16xE1 3,00 km ~ 4,32 km 3,00 km ~ 5,22 km
Mini-Link 18GHz (1+1) 16xE1 3,00 km ~ 3,85 km 3,00 km ~ 5,19 km
ERICSSON
Tipo de Equipamento Configurao Capacidade Dimetro de 0,6m Dimetro de 1,2m
Mini-Link 15GHz (1+0) 2xE1 5,00 km ~ 7,70 km 5,00 km ~ 11,10 km
Mini-Link 15GHz (1+1) 2xE1 5,00 km ~ 6,82 km 5,00 km ~ 10,12 km
Mini-Link 15GHz (1+0) 4xE1 5,00 km ~ 7,07 km 5,00 km ~ 10,16 km
Mini-Link 15GHz (1+1) 4xE1 5,00 km ~ 6,25 km 5,00 km ~ 9,26 km
Mini-Link 15GHz (1+0) 8xE1 5,00 km ~ 6,48 km 5,00 km ~ 9,34 km
Mini-Link 15GHz (1+1) 8xE1 5,00 km ~ 5,71 km 5,00 km ~ 8,50 km
Antenas
Antenas
Antenas
Antenas

72
IDU Composta de Magazine, MMU, SMU, SAU, Painel de Tributrios, Conversor,
Retificador de Tenso.

F|gura 5-8 Vode|os de Vagaz|re (usados ro padrao para Rac| 19 po|egadas )
Magazine AMM-2U:
- Ocupa 2 unidades de Rack 19
- Normalmente usada no cliente, pois comporta um nmero menor de Rdios.
- Comporta at 2 enlaces 1+0 at 4E1, ou 1 enlace 1+1 at 4E1, ou 1 enlace de 8E1 at 16E1
quer seja 1+0 ou 1+1.
Magazine AMM-4U:
- Ocupa 4 unidades de Rack 19
- Normalmente usada no HUB, pois comporta um nmero maior de Rdios.
- Comporta at 4 enlaces 1+0 at 4E1, ou 2 enlaces at 16E1 1+1.
Veja as figuras a seguir:

Ligados pelo Cabo de FI
F|gura 5-9 Vdu|o de rd|o |rdoor para er|aces(10) de 1 ou 8E1's

F|gura 5-10 Vdu|o de rad|o |rdoor para er|aces(11) de 2, 1, 8, 1 E1's.


73



F|gura 5-11 ul|||zaao de rodu|o de rd|o |rdoor er ruo s|le para corexao de c||erles


F|gura 5-12 0cupaao de ura AVV-1u as p|acas que poder ser ul|||zadas






AMM-4U

74
Placas dentro do magazine(AMM):

SAU Service Access Unit
Unidade utilizada para gernciamento do rdio enlace e para conexo de cascateamento
de gerncia.

MMU - Modem Multiplex Unit
A MMU (Modem Unit) a unidade interna totalmente independente da banda de freqncia.
Junto com o rdio e a antena, ela quem contm todas as funes necessrias para
funcionamento do terminal rdio, com suas capacidades descritas abaixo.
A MMU-LINKE o programa abrange um conjunto de verses de MMU provenientes das
seguintes capacidades de trfego:

MMU 2X2 para 2X2 Mbps
MMU 4X2/8 para 4X2 Mbps ou 8 Mbps
MMU 2X8 para 2X8 Mbps
MMU 34+2 para 34+2 Mbps

As unidades de modem possuem capacidades variadas, e cada E1 pode ser fracionado em
velocidades mltiplas de 64Kbps at 2048 Kbps, para isso usado um fracionador (Conversor
V35).

- SMU Switch and Multplex Unit:
A SMU (Switch Multiplexer Unit) uma unidade interna usada para fornecer switching com
proteo 1+1 e/ou multiplexing / demultiplexing para os canais de 2 Mbps.

SMU 8X2 para 8X2 Mbps
SMU 16X2 para 16X2 Mbps
SMU Sw somente para switching

Usada mais com as MMUs de 8E1 e 16E1, esta unidade(SMU) utilizada em enlaces
1+1, onde necessita-se da mulplexao dos feixes E1s ou quando utilizada como um circuitos
E3, faz a multiplexao dos 34Mbps.






75
- Painel de Tributrio:
Usado no Rack 19.
Montado com os acessrios (conectores e Kit 8 Cabos ) , faz a conexo entre a MMU e o
equipamentos do cliente.
Tem capacidade para at 16 E1.
Usa-se um kit de 8 cabos montado e conectado na MMU.


ACESSRIOS (outros equipamentos)

- Conversor/Fracionador V35:
Usado para fracionar os E1 e para converter a Interface do Rdio, que G703 (120 Ohm
unbalanced ou 75 Ohm balanced) para a Interface dos equipamentos usados nos cliente que
V35.
Usado somente no cliente, pois o HUB trabalha em G703 (120 Ohm), onde o switch gera
clock e realiza o fracionamento em time slots de acordo com a configurao aplicada no
conversor/fracionador de interface utilizado no cliente.

- Retificador 48V / 5 A:
Usado para retificar a corrente alternada da rede eltrica (110/220V) para corrente
contnua dos equipamentos do cliente ( - 48 V ).
Especificado para atender um consumo de energia de uma determinada quantidade de
Rdios.
Possui banco de baterias de 12 AH (Ampere x hora) que suporta at 4 horas sem energia
eltrica, tempo este suficiente para atendimento, quando houver algum problema de energia,
queda de disjuntores etc.
Tambm usado somente no cliente, pois o HUB tem outro tipo de retificao, de maior
capacidade.





76
- Roteador
Modelos usados : CISCO 1721 & 2501 (c/ 2 portas serial) e CISCO 1601 (c/ 1 porta
serial)
Usado em clientes que desejam acesso IP.
Serve para conexo da rede local com o mundo externo (Internet) do cliente.

- Rack 19
Usado para comportar a unidade interna ( IDU ), ou seja, Magazine, MMU, painel de
tributrio, Conversor, Retificador etc.
O tamanho varia de acordo com a necessidade do cliente ou espao disponvel no Site.

- RACK DKL
um Rack 19 fechado para uso externo, suportando chuva e calor, sem perder o
desempenho do Rdio.
J vem equipado com fonte ( retificador ) , banco de baterias, painel de tributrios e
pedestal.
A IDU instalada dentro dele, o qual tem a ligao com a RAU.
Funciona como um mini HUB.
Usado em POP (Multiple Tenant), onde pode ser ligado mais de um enlace no mesmo
prdio ainda que no seja um HUB.

- CABOS
Cabo de FI 50 Ohms para ligar a RAU MMU.
Existem bitolas de diferentes medidas (10 mm ou 3/8, 16 mm ou 1/2) de acordo com
as metragens utilizadas, onde h necessidade de ser maior quando h atenuao (perda) do sinal.
Modelos utilizados pela Diveo:
LMR-400; LMR-600; RGC-213; 3/8; ou .

Cabo de RF 75 Ohm ou cabo de Tributrios para ligar o Conversor ao painel de
Tributrios.
Tambm existem bitolas de diferentes medidas (0,4/2,5mm; 0,6/3,7mm) usadas quando
h atenuao, em funo de metragens maiores.

77
Modelos utilizados pela Diveo:
RF75 0,4 / 2,5; RGC-59

Cabo UTP cabo de rede usado para roteador.

Cabos de Energia e aterramento - Todas as RAUs e Magazines so aterradas para evitar
queima de equipamentos, utilizado o cabo de 16mm.


Segue descrito na figura abaixo um diagrama com os elementos de acesso no site do
cliente, deste as placas IDU do rdio PDH at os equipamentos e acessrios para conexo e
provisionamento do circuito.





















78
RESUMO (esquema)

F|gura 5-13 Exerp|o de corexao dos equ|parerlos de lrarsr|ssao er ur c||erle






79
5.1.6. Unidade de Interface de Dados UID:

Conversor G.703/G.704 para V.35. Este conversor tem a finalidade de adequar a
velocidade de transmisso do enlace velocidade desejada pelo cliente, sem comprometer a
confiabilidade e a disponibilidade do servio. Suas caractersticas:
Velocidades selecionveis em mltiplos de 64Kbps (N x 64Kbps), at 1984 Kbps;
Interfaces V.35, V.11, G.703/G.704;
Com ou sem CRC-4;
Cascatevel.



5.1.7. Descrio da Topologia
A rede Diveo, de uma certa forma, segue uma topologia comum em relao s outras
redes ( Embratel, Intelig, AT&T, Impsat e outros), porem se caracteriza por ser uma rede
metropolitana especializada no fornecimento de acesso de ultima milha, ou seja, alem de possuir
Backbone prprio, ela faz infra-estrutura necessria para conexo dos clientes at o mesmo.













80
5.1.8. Terminologia utilizada nesta rede

AMM (Access Module Magazine) o local onde so armazenadas as placas MMU, SAL e
SMU.

BER (Bit Error Rate) Relao entre a quantidade de erros recebidos e a quantidade total de
bits taxa de recebimento de bits que so relativas aos erros.

HCC (Hop Communications Channel)

MMU (Modem Unit) A placa MMU o modem que faz o enlace com a outra ponta (Hub ou
PoP (repeater)).

NCC (Node Communications Channel)

Netman Programa de gerenciamento dos mini-links.

Switch - um comutador de circuito.

RAU (Rdio Unit) a unidade externa do rdio.

SAU (Service Access Unit) A placa SAU usada para o gerenciamento do enlace.

SMU (Switch Multiplexador Unit) A placa SMU sera usada somente quando a MMU for 8xE1
ou 16xE1.

ANATEL (Agncia Nacional de Telecomunicaes) o rgo regulamentador de servios de
telecomunicao no territrio brasileiro. Oferece servios que permitem sociedade participar
diretamente da regulamentao do setor, acompanhar processos, esclarecer dvidas sobre
servios de telecomunicaes e sobre diretos e obrigaes dos usurios e prestadores de servios.

OSI (Open System Interconection) Interconexo de sistemas abertos. um modelo para
interconexo em comunicao de dados que distribuda em funes em sete camadas:
1) Fsica (Responsvel pela interface eltrica e mecnica para a transmisso de bits sobre
um canal de comunicao).
2) Enlace ( responsvel pelas transmisses de bits isentas de erros em uma interface
fsica. Tambm conhecida como a Camada de Enlace. A Camada de Enlace combina os bits de
dados dentro de uma unidade chamada quadro e adiciona a este um checksum a fim de permitir
a deteco de erros de bits ao seu destino).
3) Rede ( responsvel pelo roteamento ponta a ponta das unidades de dados chamadas
pacotes. Cada pacote transmitido para o prximo n em uma rede dentro de um quadro da

81
camada de enlace de dados. Alguns tipos de redes OSI (por exemplo: X.25) proporcionam um
processamento extensivo para garantir um servio de rede dirigida para conexes confiveis.
Outros tipos de redes (por exemplo: o IP) proporcionam um processamento mnimo e deixa a
verificao de erros para a camada superior (transporte)).
4) Transporte ( responsvel pela confiabilidade ponta a ponta. As unidades de dados do
protocolo a partir da camada de sesso so passadas para a camada de rede. O destino dos
pacotes da camada de redes so novamente combinados e sofrem a verificao quanto a erros.
Os dados recebidos so passados para a camada de sesso. As classes diferentes de servio de
transporte so definidas dependendo das capacidades da camada de rede subjacente).
5) Sesso ( responsvel pelo estabelecimento no controle de dilogos entre os usurios
de mquinas diferentes sincronizao para a transferncia confivel de dados e gerenciamento de
fichas para controlar a utilizao da conexo so os servios proporcionados pela camada de
sesso).
6) Apresentao ( responsvel pela identificao da sintaxe dos dados que esto sendo
transmitidos).
7) Aplicao ( o software do host responsvel por rodas todas as informaes contidas
no protocolo)


Frame Relay uma interface de comutao desenvolvida, que opera no modo pacote (quadros
com endereamentos individuais multiplexados estatisticamente em uma porta ou tronco).
Utiliza o protocolo LAPD com menos processamento do que a comutao por pacote X.25. O
frame relay definido pelas normas ANSI CCITT e possui caractersticas que o fazem casar com
perfeio a interligao em redes de velocidade elevada de dados por rajadas (LANs).

ATM (Asynchrnous Trensfer Mode) Modo de transferncia assncrona. Tcnica de comutao
por pacotes que utiliza pacotes de comprimento fixo (53 bytes), resultando em pouco
processamento e velocidade mais elevadas. Tambm conhecido como B-ISDN e cell relay.

B-ISDN (Broadband Integrated Services Digital Network) Rede Digital de servios integrados
de banda larga. Tcnica de comutao por pacotes que utiliza pacotes de comprimento fixo,
resultando em pouco processamento e velocidades mais elevadas. Tambm conhecida como Cell
Relay e ATM.

Backbone Facilidade ou conjunto de facilidades de transmisso de alta velocidade, desenhada
para interconectar canais distribudos de baixa velocidade.

Circuit Emulation (CE) uma emulao de um circuito de velocidade E1 que se utiliza a
alocao de canais dedicados providos por servios de mais alta velocidade. No caso da rede
ATM multiservios Diveo, o ATM faz este papel de prover este recurso para a emulao deste
circuito.

Circuit Switching (Comutao por circuitos) um mtodo onde um caminho dedicado
estabelecido entre o transmissor e o receptor. A conexo transparente o que significa que os
comutadores no tentam interpretar os dados.

Packet Switching (Comutao por pacotes) um mtodo de comutao em comunicao de
dados que divide os dados em unidades individuais chamadas de pacotes. Os pacotes contm os

82
dados do usurio mais informaes tais como endereamento sequenciamento e controle de
fluxo.

Frame (Quadro) grupo de bits de dados em um formato especfico com indicadores nas
pontas para indicar o incio e o trmino do quadro. O formato normatizado habilita o
equipamento da rede a reconhecer o significado e a finalidade dos bits especficos.

Decibis (db) uma unidade de medida logartmica comparativa que mede a potncia do sinal.

E1 (European) Circuito digital de dados de velocidades de 2.048 Mbps.

Gateway um tipo de conexo especial, em altssima velocidade, definida para efetuar a
comunicao entre dois ou mais backbones.

HUB Elemento componente do Backbone ATM multiservios Diveo. o local onde esto
instalados os equipamentos SDH e ATM. ainda o local onde se interligam os POPs.

PDH (Plesiochronous Digital Hierarchy) Arquitetura de multiplexao e de transmisso de
sinais digitais entre elementos de cujos sinais de relgio de amostragem no so exatamente
sincronizadas (clock). As velocidades de transmisso vo de 64 Kbps e chegam a 140 Mbps.

SDH (Sinchronous Digital Hierarchy) Arquitetura de multiplexao e de transmisso de sinais
digitais entre elementos de rede, cujos sinais de relgio de amostragem so perfeitamente
sincronizadas. A velocidade de transmisso de 155 Mbps.

POP (Point Of Presence) Conjunto de equipamentos e de facilidades Diveo instalados no
cliente.

Shaft um canal ou duto fsico para toda a instalao de cabeamento necessrio que um
prdio necessita.

Site Survey um servio necessrio obteno de informaes para a instalao de um ponto
de conexo final (POP) ou de um Hub.

STM-1 uma interface fsica que prov o suporte a para qualquer aplicao que requeira
interface ATM. A velocidade especificada de 155 Mbps.

Bridge (Ponte) um dispositivo de interconexo para LAN que filtra e passa os dados entre
duas LANs com base nas informaes da Camada 2 (Camada do MAC endereo fsico da
mquina do host).

Router um dispositivo que interconecta LANs e que pode rotear dinamicamente os dados.

V.35 Interface para conexo de equipamentos com velocidades variveis de 64 Kbps 2Mbps.

G.703 e G.704 Interface para conexo de equipamentos de 2Mbps. A padronizao G704
define esta mesma velocidade de conexo, mas internamente a esta velocidade, existem

83
divises que podem ser usadas separadamente ou no, dependendo da velocidade necessria.
Esta padronizao permite a utilizao de velocidades inferiores a 2Mbps.

Canal no estruturado um feixe de 2Mbps (Un-framed)

Canal estruturado Canal de 2Mbps dividido em 32 time-slots. Sendo que o 0 (zero) e 16
(dezesseis) so usados para sincronizao resultando em 30 time-slots disponveis para uso.
(framed).

Cross Conection (Conexo virtual) Para se efetuar uma conexo entre um hub e outro feita
uma cross-conection, onde cada VPI (Virtual Path Identifier) e VCI (Virtual Channel Identifier)
de um canal em um Hub ligado do outro canal do outro Hub. Dentro de um VPI h vrios VCIs

PVC (Permanent Virtual Conection) Conexes permanentes, s seguir o caminho j
previamente definido da origem ao destino. O PVC um circuito virtual que estabelecido de
forma administrativa pelo operador da rede para uma conexo ponto-a-ponto dedicada.

SPVC (Swiich Permanent Virtual Conection) Conexes no permanentes, pois os caminhos so
indefinidos Sabe-se que a origem e quem o destino mas no se especifica o caminho

Slot e Port Definem o canal/circuito que est sendo utilizado, sendo que escolhido pelo
operador, so dispostos conforme placas alocadas no hardware do equipamento.
Slot vo de 1 ao 9, no switch demonstrado nesta topologia pode-se alocar at 9 placas
Port vo de 1 ao 21, cada placa possui 21 portas E1

Time-slot Cada timeslot corresponde 64 Kbps no canal, sendo que cada port (igual E1)
possui 31 timeslots, estes representam um total de 1984Kbps, que podem ser divididos para mais
de um cliente.






84
CBX 500 Multiservice
WAN Switch
PSAX1250
Hub Diveo
Ethernet
Server / Proxy Server
DKL Shelter
1
5

t
o

3
8

G
H
z
Mini-Link
Ericsson
STM1 ATM
G.703 E1
Cisco 2501 Router
V.35
G.703

Backbone ATM
STM1 ATM
Cliente
Switch de Acesso
Multiplas portas E1s


F|gura 5-11 Topo|og|a para acesso do c||erle
A figura 5.14 mostra a conexo do equipamentos que falamos anteriormente.





85

5.2. Servios disponveis ( formas de acesso)

5.2.1. Servio Digital Business Access (Dveo DBA)

O Servio Diveo DBA um servio de telecomunicao digital fim-a-fim em modo
transparente (Clear Channel) que interliga duas localidades dentro da rea de cobertura da Diveo
do Brasil Telecomunicaes, em velocidades de transmisso de 64 Kbps e seus mltiplos at
1984 Kbps (E1 canalizado), 2 Mbps (E1 no canalizado), alm de 2 x E1 (4 Mbps), 4 x E1 (8
Mbps), 8 x E1 (16 Mbps) e 16 x E1 (32 Mbps).
As opes disponveis para o Servio Diveo DBA dependem da aplicao final do
Cliente. Caso a aplicao final seja para utilizao de Voz, o servio deve ser Canalizado
(G.704). Para as demais aplicaes, pode-se utilizar a opo Canalizado, ou No-Canalizado.
Este servio pode ser composto de forma a interconectar dois ou mais pontos de um
cliente atravs do Backbone ATM Multiservios Dveo. Para conectar servios e redes de dados,
de voz ou de vdeo.

Backbone
ATM Diveo
Acesso
PDH
Cliente Cliente
UID UID
Interface Interface
Equipamento
doCliente
Equipamento
doCliente
Acesso
PDH

F|gura 5-15 Corpos|ao do 3erv|o 0iveo 08A
O Servio Diveo DBA se compe de uma parcela do Backbone ATM Multiservios
Diveo reservada para uso exclusivo e dedicado ao Cliente (tecnologia de alocao de canais
dedicados) e dos acessos a este Backbone. Os equipamentos que implementam este acesso so
chamados de equipamentos de terminao. O conjunto destes equipamentos instalados no
Cliente definem o Ponto de Presena Dveo (PoP Dveo).

86
O PoP Diveo inclui o equipamento de enlace de microondas (tecnologia PDH) e da
Unidade de Interface de Dados (UID).
O enlace de microondas entre o PoP Diveo e o Backbobe ATM Multiservios Diveo
dimensionado de forma a garantir as condies de confiabilidade e de disponibilidade
caractersticas do servio, mesmo nas condies mais adversas de chuva. Para tanto, alguns do
parmetros do enlace so fundamentais: potncia de transmisso, ganho de antenas, distncia
entre as localidades e condies de visada.
Todas as freqncias utilizadas nos enlaces PDH e SDH so homologadas junto a
ANATEL.

5.2.2. Ponto a ponto:
O Servio Diveo DBA na configurao Ponto a Ponto pode ser configurado de forma a
interligar somente duas localidades do cliente entre si.
As duas localidades (PoP Diveo) se interligam ao Backbone ATM Multiservios Diveo
atravs de enlaces de microondas em PDH.
PDH
PDH

Link SDH
Backbone ATM Multiservio Diveo

Pop Diveo Pop Diveo

F|gura 5-1 Corl|guraao Porlo a Porlo

5.2.3. Ponto-Multiponto:
O Servio Diveo DBA na configurao Ponto-Multiponto pode ser configurado de forma
a interligar vrias localidades do cliente a uma localidade central.
Todas as localidades (PoPs Diveo) se interligam ao Backbone ATM Multiservios
Diveo atravs de enlaces de microondas em PDH. O enlace localidade central deve ser
dimensionado de forma a permitir todas as interconexes simultneas.

87

PoP Diveo
Backbone ATM
Multiservio Diveo
PoP Diveo

F|gura 5-1Z Corl|guraao Porlo Vu|l|porlo
5.2.4. Rede privativa virtual (VPN):

Neste tipo de conexo, todos os locais tem a capacidade de se intercomunicar,
independente da localizao dos mesmos, garantindo assim total conectividade de acordo com as
necessidades do Cliente.

Backbone ATM
Multiservio Diveo
PoP Dveo
PoP Dveo

F|gura 5-18 Corl|guraao vPN
5.2.5. Gateway:
O Gateway a interconexo entre o Backbone ATM Multiservios Diveo e o Backbone
de uma outra empresa de telecomunicaes, sejam elas pblicas ou privadas.
Este tipo de conexo se baseia no servio Diveo DBA de alta capacidade de transmisso.
E permite a implementao de servios conjuntos (prestados por ambas as empresas em parceria)
de velocidades menores.
Backbone ATM
Multiservio Diveo
Backbone
Cliente ou Parceiro
PoP Diveo

F|gura 5-19 Corexao de 0aleWay


88
5.2.6. Solues Especiais:
Alm das configuraes acima, algumas configuraes especiais podem ser
desenvolvidas com o Servio Diveo DBA. Estas configuraes especiais esto sujeitas a
avaliao e a aprovao caso a caso.Um dos casos especiais o Servio Diveo DBA na
modalidade Off-net, como se descreve a seguir.
Off Net com gerenciamento:
O Servio Diveo DBA na modalidade Off-Net, pode ser utilizado quando uma ou mais
localidades que devem ser interligadas esto fora da rea de cobertura do Backbone ATM
Multiservios Diveo.
Neste caso, pelo menos uma das localidades deve estar dentro da rea de cobertura do
Backbone, a fim de garantir o gerenciamento do servio.

Backbone ATM
Multiservio Diveo
Pop Diveo

F|gura 5-20 Corexao 0ll Nel cor gerrc|arerlo


As velocidades disponveis para este tipo de conexo podem ser: 2Mb/s, 4Mb/s; 8Mb/s;
34Mb/s (E3) ou 155Mb/s (STM-1). Um exemplo a conexo da PUCRS com a RNP-RS.
Off Net sem gerenciamento:
O Servio Diveo DBA na modalidade Off-Net sem gerenciamento pode ser utilizado,
quando todas as localidades esto fora da rea de cobertura do Backbone ATM Multiservios
Diveo.
Backbone ATM
Multiservio Diveo


F|gura 5-21 Corl|guraao 0ll Nel ser gererc|arerlo


89
5.2.7. Caractersticas tcnicas
A seguir, tem-se as caractersticas tcnicas do servio Diveo DBA.
Confiabilidade: Taxa de erro de bit (BER) menor que 10
-8;

Velocidade de Transmisso: 64Kbps a 2 Mbps, em mltiplos de 64Kbps;
Padro G.704 em E1 (2 Mbps);
STM-1 com 63 E1s sem canalizao;
Interfaces: V.35, G.703;
Modalidade de Redundncia:
Em PoP: Rdios PDH 1 + 0;
Em Gateway: Rdios SDH ou PDH 1 + 1;
Codificao de Linha (no caso de Voz): HDB-3 ou AMI;
Clock da Rede: O equipamento do cliente regenera o sinal e clock, sempre fornecido
pelo Backbone;
Tipo de canalizao:
- No-Canalizado (UnFramed): A opo Unframed entrega a velocidade total de 2048
kbps, sem as separaes internas para subvelocidades. Muito comum para utilizao em
aplicaes de Dados, quando o Cliente necessita de um E1 cheio;
- Canalizado (Framed): A opo UnFramed entrega a velocidade total de 1984 kbps,
equivalente a 31 timeslots, que tem a velocidade de 64 kbps. Nesta opo, alguns itens
devem ser observados:
- Timeslot 16 transporta os dados transparentemente, ou seja, no importa
se o que est sendo transportado alguma informao de sinalizao de controle,
ou dados puros.
- Algoritmo de correo de erros o CRC-4. Pode-se tambm fornecer a
opo Framed sem este algoritmo, mas o servio no estar habilitado a corrigir
os erros nesta camada de transporte.
- Timeslot 0 (zero) no mapeado.
- Basicamente utilizado para aplicaes de Voz, e Dados em velocidades
entre 64 Kbps e 1984 Kbps

90
6. Cases de Solues Tecnolgicas
6.1. Perfil de Clientes
Os clientes das empresas prestadoras de acessos, inicialmente eram somente as
operadoras como Embratel, GVT e Intelig, onde eram fornecidas as mesmas o servio de DBA
para conexo de ltima milha. Nestes circuitos de ultima milha as operadoras colocavam
servios de voz e dados. Com a evoluo dos processos de engenharia e o tipo de venda
comercial, a Diveo comeou a fornecer acesso Internet diretamente aos clientes corporativos,
vindo assim a se tornar mais uma opo para as empresas que necessitavam deste tipo de servio
especializado. Este produto veio a se chamar de DBI ( Digital Business Internet), uma evoluo
de certa forma, do DBA, onde o mesmo s necessita uma alterao nas configuraes das
interfaces ATM e a colocao de um roteador no cliente, neste ano a partir de abril de 2003,
devido a necessidade do mercado e tambm pela atual a topologia da rede da Diveo, foi
implementado sobre o Backbone os switches com MPLS, os quais nos possibilitou a realizar
VPN sobre MPLS um novo servio.
Com aparecimento de mais opes de acesso Internet, e principalmente da crescente
quantidade de servios sobre a mesma, os pequenos clientes corporativos evoluram para grandes
universidades, empresas com grandes redes que possuem filiais em outros estados, provedores de
internet at as operadoras de telefonia mvel, devido a necessidade de melhorias na planta
instalada para prover os novos servios(dados com mobilidade). O cliente se tornou mais tcnico
no que diz respeito as suas necessidades, pois os mesmos tinham que responder aos anseios de
seus prprios clientes; queriam mais banda de acesso e contedo para acesso. Assim se tem um
novo perfil de cliente sendo este chegando ao mais alto ponto que de se tornar um AS (Sistema
Autnomo).

91
Segue abaixo um grfico utilizado para estudo para levantamento de necessidade de
banda, mostrando o grau de relacionamento em que o cliente necessita entre o seu fornecedor de
acesso, pois o mesmo utiliza destas ferramentas para apurar sua qualidade de servio.


F|gura -1 0rl|co de ul|||zaao de oarda
A figura acima demonstra uma das ferramentas que os clientes esto utilizando
para gerenciamento de trfego(In= download, Out=Upload), alm desta, existem medidas por
ping, para verificar a latncia da rede de acesso e do caminho a ser percorrido pelos pacotes.
Portanto nota-se que o cliente necessita de um servio cada vez mais especializado.
Observa-se uma tendncia utilizao do protocolo MPLS em redes multiservios,
abaixo algumas matrias sobre a utilizao desta nova tecnologia para provisionamento de
servios, demonstrando a realidade do mercado.
Com novas funcionalidades, a famlia de VPNs (Virtual Private Networks) tambm
apresenta alto potencial de venda, principalmente junto s grandes corporaes. A nova
concepo de rede corporativa compartilhada e virtual incorpora a funcionalidade de QoS
(qualidade de servio), podendo oferecer voz, imagens e dados por meio de um nico link, com
segurana e qualidade.
Atualmente, as velhas linhas dedicadas ou servios de comutao de circuitos
representam entre 60% e 80% da receita de dados das operadoras, que concentram mais de 80%
dos negcios na rea de voz. O objetivo que esta equao se torne mais equilibrada com a
chegada da convergncia dos servios para redes multiservios. Para tanto observa-se as matrias
abaixo.



92
TELECOM So Paulo, 23 de Maio de 2003


Telcos apostam na migrao da VPN/IP para MPLS

Ceila Santos, do World Telecom

Telemar e Embratel deixaram claro, nesta quarta-feira, 22, durante seminrio "Aplicaes Corporativas em
VPN IP, promovido pela IDG Computerworld, a aposta no potencial de vendas do servio VPN IP com MPLS (
Multiprotocl Label Switching) e QoS (qualidade de servio).
Considerada uma evoluo da tradicional rede virtual corporativa, a VPN IP com MPLS e QoS permite
simplicidade na configurao de redes multipontos, prioriza o trfego conforme a demanda da corporao e
exige roteadores de ponta menos robustos - o que reduz o custo das corporaes. A caracterstica de QoS
traz tambm a possibilidade de trafegar voz e vdeo na rede de dados.
Por outro lado, o MPLS no garante a mesma segurana que as VPNs tradicionais, as quais utilizam o
protocolo de segurana IPSec, nem a flexibilidade de escolha da provedora de acesso.
Andr Pires, gerente de produto IP VPN da Embratel, explica que enquanto a VPN tradicional exige o IPSec,
que criptografa e encapsula os pacotes de dados barrando qualquer tipo de ataque online, o protocolo MPLS
no tem criptografia nem encapsulamento, o que aumenta a disponibilidade do link de dados. "Isto no
significa que o MPLS no garante segurana, mas no to rgida como a do IPSec, que demanda mais
banda na capacidade de transmisso. A segurana do MPLS equivalente segurana existente nos links
frame relay. Tanto que o SPB (Sistema do pagamento Brasileiro) utiliza a VPN com MPLS, compara Pires.
Apesar da escabilidade e qualidade de servio permitida na VPN IP com MPLS e QoS, a nova soluo amarra
a corporao uma nica operadora. Isto porque a VPN com MPLS migra toda a configurao e
gerenciamento existente na ponta do cliente para o backbone da operadora.
Pires explica que a maioria das VPNs implementadas foi configurada pela prpria corporao, que contrata os
links de dados de diversas operadoras para acessar os tneis formatados entre os equipamentos adquiridos
de fornecedores. A Embratel revela que j h 300 clientes usurios da VPN com MPLS e cerca de 25 com
QoS.
Thiago Cruz Silveira, gerente de desenvolvimento de servios VPN da Telemar, detalha como feita a
priorizao da qualidade de servio na oferta da operadora. So cinco classes de servios, sendo trs
referentes aos dados e os demais divididos em voz e vdeo. A subdiviso dos links de dados referem-se ao
trfego considerado crtico, prioritrio e convencional.
Silveira acrescenta tambm que o QoS permite o gerenciamento da rede, que reflete em relatrios
discriminados e controlados periodicamente encaminhados ao cliente corporativo pela operadora. Ele
tambm diz que o perfil de clientes implica empresas que tm disperso geogrfica ou grande nmero de
sites e utilizam aplicaes crticas.
http://computerworld.terra.com.br/AdPortalV3/adCmsDocumentoShow.aspx?Documento=24914

Taoe|a -1 Reporlager: V|graao das redes vPN/lP para VPL3

A tabela acima demonstra a tendncia da migrao dos servios para uma rede
multiservios, quando nos referimos a multiservios, estamos falando de voz, vdeo e dados.






93

TELEXPO 2003 So Paulo, 23 de Maio de 2003


BrT quer 400 mil usurios de banda larga



Ceila Santos, do World Telecom

Empenhada em dobrar a base de usurios de alta velocidade, a operadora Brasil Telecom anuncia, nesta
tera-feira, 25/03, uma parceria com a Vsper para a oferta conjunta do acesso de banda larga com a
tecnologia CDMA 2000 1xEV-DO, que permite transmisso de dados em at 2,4 Mbps.

A perspectiva de crescer 100% na oferta de banda larga est baseada tambm na comercializao das
tecnologias ADSL, IP e Wi-Fi no padro 802.11.

Yon Moreira Jnior, diretor de negcios corporativos da Brasil Telecom, explica que na parceria com a Vsper
os clientes sero contabilizados separadamente, mas a oferta e a cobertura do servio sero compartilhadas.

Por enquanto, a Vsper ser responsvel pela oferta em So Paulo e a Brasil Telecom cobre o distrito federal
(Braslia). A previso lanar o servio nos prximos 90 dias com capacidade para suportar 4 mil usurios
at o final deste semestre e 18 mil usurios no segundo perodo do ano.

A parceria estender para outras localidades, sendo que a Vsper ser responsvel pela cobertura do Rio de
Janeiro e BrT pretende expandir para Curitiba, Florianpolis, Goinia e Campo Grande.

O fabricante da soluo a Lucent. Porm, o acordo entre as empresas no foi selado comercialmente. "Por
enquanto, no pagamos nada para a Lucent porque estamos em teste. A idia fechar contrato aps
adquirirmos 4 mil clientes, conta Moreira.

E acrescenta: "Nossa inteno que entre 10% a 15% da base total de usurios de banda larga, que hoje
soma 200 mil usurios, utilize o EV-DO at o final de 2003, planeja Moreira.

J a Vsper almeja angariar cerca de 30 mil usurios, que somados aos planos da BrT, totaliza 50 mil
clientes at o final de 2003.

A rede IP com MPLS (multiprotocol label switching) suportar a demanda de banda larga das grandes
empresas. A tecnologia ainda est em projeto piloto com duas corporaes, sendo uma financeira. O
lanamento comercial est previsto para maio e a soluo foi batizada de Vetor.

J o padro 802.11, conhecido como Wi-Fi, que permite o acesso internet em alta velocidade sem fio, ser
oferecido tanto ao mercado residencial como de pequenas empresas. Para a oferta desta tecnologia, a
operadora selou acordo com o fabricante de modems U.S. Robotics.

"Estima-se que o Wi-Fi seja responsvel por cerca de 6 mil usurios at o final do ano , diz.

http://computerworld.terra.com.br/AdPortalV3/adCmsDocumentoShow.aspx?Documento=24289

Taoe|a -2 Reporlager: ul|||zaao do VPL3 para prover serv|os qua||l|cados de redes.
Na tabela acima, pode-se perceber que as carriers esto apostando na tecnologia MPLS
no somente para acessos de clientes(usurios finais), mas tambm para prover outros servios,
como exemplifica o provisionamento de servios como CDMA 2000 1xEV-DO e Wi-Fi no
padro 802.11.


94
NEGCIOS So Paulo, 23 de Maio de 2003


Novos servios para incrementar trfego na rede do SPB

Ana Paula Lobo

Primeira infra-estrutura IP/MPLS( (Multiprotocol Label Switching) do Pas, a rede de telecomunicaes do
Sistema de Pagamentos Brasileiro mantm uma taxa aproximada de 30% da sua capacidade ocupada.

A expectativa que novos servios, entre eles, a liquidao financeira de todos os boletos de cobrana e dos
documentos de ordem de crdito (DOCs) - sejam incorporados ao modelo bancrio do SPB no segundo
semestre deste ano. Atualmente, essas atividades so realizadas pela Cmara de Compensao do Banco do
Brasil (Compe).

"A maior parte dos links vendidos pelo consrcio RTM/Embratel ainda de 64Kbps. Os grandes bancos
consomem mais banda, mas temos a certeza que to logo novos servios sejam incorporados ao SPB, esse
trfego ser ampliado", destaca Carlos Roberto Soares Teixeira, diretor de telecomunicaes do consrcio
RTM/Embratel.

A infra-estrutura de telecom do SPB - alm da inovao do uso do IP/MPLS - tambm foi uma das primeiras
a compartilhar responsabilidades dentro de um contrato governamental. Isso porque houve a escolha de
dois provedores nacionais: AT&T e RTM/Embratel. As empresas so responsveis por todo o atendimento ao
sistema financeiro.

"Nosso relacionamento com a AT&T timo. Estamos sempre nos falando para que no haja qualquer
problema operacional. Acredito que esse modelo de co-responsabilidade sagrou-se positivo. Em um ano, no
foi registrado nenhum problema significativo na rede ", observa Soares Teixeira.

Em entrevista ao COMPUTERWORLD, o chefe do departamento de TI do Banco Central, Fernando Abreu,
mostrou-se tranquilo com relao aos problemas financeiros da AT&T Latin America - a concordata ainda
no havia sido pedida oficialmente pela provedora, o que aconteceu no dia 15 de abril. Segundo ele, h
regras especficas no contrato de SLA(Service Level Agreement), alm de ter o suporte do RTM/Embratel.

De acordo com dados divulgados pela Febraban, em maro deste ano, a mdia diria de TEDs (Transferncia
Eletrnica de Documentos) - que mantm-se em R$ 5.000 pelo SPB - ficou em 48 mil/transaes.

Em um ano de funcionamento, o SPB cumpriu boa parte dos seus objetivos. O principal deles, de acordo
ainda com a Febraban, foi o de permitir reduzir metade, o volume de cheques emitidos. Os valores caram
de R$ 15,8 bilhes para R$ 9 bilhes.
http://computerworld.terra.com.br/AdPortalV3/adCmsDocumentoShow.aspx?Documento=24588


Taoe|a -3 Reporlager: ura das pr|re|ras Redes VPL3 , 3P8
Para finalizar a contestao da utilizao das Redes MPLS, nada mais prtico do que a
implementao desta tecnologia na Rede do Sistema de Pagamentos Brasileiros,o que comprova
o paradigma da utilizao MPLS em redes multiservios.




95
Com o intuito de comentar a pratica que tive sobre uma rede MPLS, demonstrei abaixo
um exemplo de VPN MPLS, esta topologia foi realizado em laboratrio da Diveo, na realidade
foram configurados 04 escritrios(POA, BHE, RJO e SPO), nos quais pude fazer testes de
implementao desta tecnologia:
Office BHE
Router-
SPO2
Router-
SPO1
Core-1
Router
SPO-3
Core-2
Router-BSA Router-CAS
Router-POA
Router CTA
Router-RJO
Router-BHE
Office POA
Office RJO
WAN : 200.198.104.40/30
CIDR : 200.198.104.56/29
Ethernet : 200.198.104.57/29
Workstation : 200.198.104.58/29
ip vrf 5521008999-01
description RJO Office
rd 15180:12199901
route-target export 15180:11100002
route-target import 15180:11100001
route-target export 15180:12199901
route-target import 15180:13199901
route-target import 15180:15199901
ip vrf 5531008999-01
description BHE Office
rd 15180:13199901
route-target export 15180:11100002
route-target import 15180:11100001
route-target export 15180:13199901
route-target import 15180:12199901
route-target import 15180:15199901
ip vrf 5551008999-01
description POA Office
rd 15180:15199901
route-target export 15180:11100002
route-target import 15180:11100001
route-target export 15180:15199901
route-target import 15180:12199901
route-target import 15180:13199901
Office SPO
WAN : 200.197.104.40/30
CIDR : 200.197.104.56/29
Ethernet : 200.197.104.57/29
Workstation : 200.197.104.58/29
ip vrf 5531008999-01
description BHE Office
rd 15180:13199901
route-target export 15180:11100002
route-target import 15180:11100001
route-target export 15180:13199901
route-target import 15180:12199901
route-target import 15180:15199901
ip vrf 5551008999-01
description POA Office
rd 15180:15199901
route-target export 15180:11100002
route-target import 15180:11100001
route-target export 15180:15199901
route-target import 15180:12199901
route-target import 15180:13199901
ip vrf 5511008999-05
description SPO Office - Full Mesh
rd 15180:11199905
WAN : 200.197.88.112/30
CIDR : 200.197.90.24/29
Ethernet : 200.197.90.25/29
Workstation : 200.197.90.26/29
WAN : 200.202.114.160/30
CIDR : 200.202.114.184/29
Ethernet : 200.202.114.185/29
Workstation : 200.202.114.186/29
ip vrf 5511008001-01
description Management Net
rd 15180:11100001
route-target export 15180:11100001
route-target import 15180:11100002
WAN : 200.197.112.52/30
CIDR : 200.197.82.240/29
Ethernet : 200.197.82.241/29
Workstation : 200.197.82.242/29

F|gura -2 Corexao |g|ca de ura rede VPL3 cor lopo|og|a lu|| resr.

Uma breve explicao desta topologia seria a especificao de uma rede full mesh com
gerenciamento concentrado em SPO. Esta a tpica aplicao que est sendo utilizada em
empresas com mltiplos pontos. A nica diferena que colocado o acesso site exclusivo, ou
seja, todo mundo conversa com todo mundo atravs de um site nico onde se centraliza a sada
para internet. Desta forma tem-se a gerncia e o controle do que est trafegando na rede.
O protocolo MPLS est sendo utilizado pelas operadoras como uma sada para otimizar a
planta instalada e agregar servios aos clientes, pois existe a possibilidade de priorizar trfego e
gerar circuitos virtuais(VPNs), alm de otimizar os recursos existentes(processamento dos
switches, e trfegos na rede).


96

6.2. Cases de Clientes
O cliente agora necessita de solues de integrao. Esta integrao se faz necessria
pois a sua estrutura de rede est descentralizada em campus ou filiais. Estes precisam estar
conectados entre si trocando em um nico link, dados e voz otimizando os seus recursos. Sendo
assim podemos verificar as topologias aplicadas em dois grandes e diferentes segmentos de
mercado(PUCRS e Sonae)
























97
6.2.1. Cliente: Sonae

Sobre o cliente:
A SONAE Distribuio Brasil S.A., ocupa hoje a terceira posio no ranking das
Empresas de Distribuio de Alimentos no Brasil. No final da dcada de 80, a SONAE, o maior
grupo no financeiro de Portugal e um dos maiores do segmento de distribuio de alimentos na
Europa, chegou ao Brasil atravs de uma joint-venture com a empresa Josapar (Grupo Joaquim
Oliveira). Em 1998, associou-se empresa Cndia Mercantil Norte Sul, em So Paulo, num
acordo que deu origem a uma nova sociedade, que foi denominada, SONAE DISTRIBUIO
BRASIL S.A. Em uma operao no final da dcada de 90, assumiu o controle da rede
Paranaense Mercadorama, primeira no ranking nesta praa. Tambm neste mesmo ano assumiu o
controle da rede Gacha Extra Econmica, no Rio Grande do Sul, e posteriores aquisies das
Redes Nacional, no RS, e Coleto e Muffato, no PR. O grupo controla hoje no pas, 160 lojas
entre Hipermercado, Supermercado e Atacado. O seu faturamento em 2001 foi da ordem de 3,4
bilhes de reais.

Necessidade:
Devido ao tamanho da rede do Sonae, o cliente estava insatisfeito o custo de telefonia,
necessitando de um projeto para Interconexo para trfego de voz.

Abordagem:
A abordagem a uma rede como SONAE foi sem dvida diferenciada, principalmente
pelas implicaes de logstica, bem como a crescente expanso do segmento alimentcio, visto
que os centros de distribuio esto situados, via de regra, j nas proximidades de rodovias para
facilitar a sada e entrada de mercadorias para o suprimento das lojas. Geralmente nas
proximidades dessas rodovias as operadoras no disponibilizam facilidades de acessos para
informao Digital para propiciar a interligao da rede, apesar dos acessos pticos de Long
Distance passarem por estas rodovias. Por estas razes que a realizei na DIVEO uma parceira
com a empresa PHASECOM abordou o cliente em questo, apresentando-lhes as solues
interconexo da rede de mercados para trfego de voz.


98
Resoluo do Problema(Case em si) Primeiro Projeto:
Tudo comeou para objetivar de forma adequada e com qualidade o atendimento das
necessidades de comunicao de voz para interligao dos POPs, Porto Alegre (Matriz), So
Paulo(Centro de Distribuio So Bernardo do Campo) e Curitiba(Centro de Distribuio So
Jos dos Pinhais). Para tal, foi projetado uma rede conforme o diagrama de aplicao abaixo.
Este projeto permitiu a integrao de switches em um ambiente nico, que alm da
disponibilidade e qualidade, proporcionou uma reduo significativa nos custos de comunicao
interurbana de voz para o cliente, cerca de 25%. Evidenciou-se assim, um excelente negcio para
o SONAE em termos de reduo de custos em telecomunicaes.
P
A
B
x
P
A
B
x
P
A
B
x
P
A
B
x
P
A
B
x
PHILIPS
IS 3000
PHILIPS
IS 3000
PHILIPS
IS 3000
PHILIPS
IS 3000
SIEMENS
*FUTURA
PHILIS 3000
PORTO ALEGRE
CURITIBA SO PAULO
E1 DBA
E1 DBA
E
1

















D
B
A
E
1

















D
B
A
SWITCH
SONAE
SWITCH
SONAE
SWITCH
CD SONAE
SWITCH
CD SONAE
SWITCH
SONAE
SO BERNARDO
DO CAMPO
SO JOS DOS
PINHAIS
G703
G703
G703
G703
G703
DIAGRAMA DE APLICAO - REDE DE VOZ PARA A SONAE
S
R
P
S
A
X
R
P
D
H
S
D
H
R
P
D
H
S
D
H
R
P
D
H
S
D
H
R
P
D
H
S
D
H
R
P
D
H
S
D
H
S
R
P
S
A
X
S
R
P
S
A
X
S
R
A
X
D
S
R
A
X
D
ATM
ATM
ATM
ATM
ATM

F|gura -3 Rede 30NAE - 0|agrara de ap||caao





99
Renovao da Rede Sonae Segundo Projeto:
Aps a implementao de uma rede de voz entre os centros de Distribuio do SONAE,
foram avaliados pelo cliente, questes relativas custo, qualidade, disponibilidade, atendimento
e outros, estes fatos fizeram com que o cliente tomasse a deciso de renovar sua rede de dados,
hoje existente, onde maior parte doa acessos realizados por circuitos Frame-Relay via
Telefnica, utilizando links de outras operadoras tambm.
Nota-se neste contexto, que existe uma necessidade do cliente em ter uma maior
confiabilidade e domnio e interoperabilidade entre os sites de sua rede, pois o SONAE expandiu
de tal forma que sua planta est estruturada sobre vrias tecnologias desde LPs at circuitos
dedicados de alta velocidade, utilizando uma grande quantidade de acessos FR da Telefnica,
por este motivo, foi exposto ao cliente uma proposta com a seguinte descrio:
Fase 1:
- Interligao de 13 localidades na grande So Paulo, Campinas, Curitiba e Porto Alegre
atravs de VPN IP MPLS, pois so pontos que esto dentro da rede Diveo.
- Fornecimento dos CPEs envolvidos na soluo, para padronizar as aplicaes.
- Gerenciamento de todos os equipamentos envolvidos no projeto.
- Garantias de suporte e manuteno, bem como detalhamento das especificaes de
atendimento proposto.
Fase 2:
- Interligao de mais 10 pontos atravs de circuitos de terceiros em configurao a ser
definida entre VPN IPSec ou Rede WAN Clear Channel, caso seja possvel prospectar os
sites pela Diveo(instalar um rdio enlace com conexo no Backbone ATM).

Aps a abordagem da idia ao cliente, foi analisada de uma forma mais tcnica para que
atendesse a necessidade de centralizar as informaes atravs de uma rede WAN localizada no
Tucuruvi em So Paulo. Para tal sugerimos soluo atravs de rede VPN IP MPLS inicialmente
interconectando 13 pontos na grande So Paulo, Campinas, Curitiba e Porto Alegre atendidos
diretamente pela Diveo atravs de enlaces de rdios PDH. A configurao sugerida na VPN IP
MPLS Site Central Exclusivo ou seja, todos os pontos tero somente acesso ao site central
localizado no Tucuruvi em So Paulo. Esta definio uma caracterstica para atender uma das
principais exigncias que tenho observado na maioria dos clientes, controle sobre os processos
que ocorrem na sua rede.

100
Na segunda fase comentada anteriormente, tem-se a anlise da forma de interconexo dos
10 pontos no atendidos diretamente pela Diveo, que so atravs de duas possibilidades:
- A primeira via VPN IPSec, ficando sob responsabilidade do cliente a contratao de um
circuito dedicado Internet em cada um dos 10 pontos para a implementao da VPN.
- A segunda via rede WAN montada sobre circuitos clear channels a serem contratados
com terceiros, parceiros da Diveo.
A diferena tcnica entre as solues que, na primeira via VPN IPSec, a Internet ser
utilizada como backbone WAN para a interligao dos pontos, porm a segurana na
comunicao garantida atravs de criptografia inserida na VPN, enquanto na segunda, a rede
dedicada ao cliente, no possuindo compartilhamento de estrutura. Comercialmente, a segunda
soluo bem mais cara que a primeira devido contratao de vrios circuitos Long Distance
para a interconexo dos pontos fora de SP.

Sendo assim temos as seguintes topologias:
Primeira Fase do Projeto de conexo de dados, interligao de 13 pontos existentes na
rede Diveo, utilizando um servio que est sendo muito requisitado hoje(rede MPLS).
PROJETO SONAE - REDE DIVEO - FASE 1 Backbone IP/MPLS
Diveo
Backbone IP/MPLS Diveo
Hub
Hub Hub
Hub
512 Kbps
BIG SPO - Tucuruvi
012 - Candia SP
Freguesia do
072 - BIG SP
Pirituba
077 - BIG SP
Santo Amaro
Hub
089 - BIG CPS
Campinas Out Let
088 - BIG SP
Santo Andr
087 - BIG CPS
Campinas Shopping
084 - BIG SP
Casa Verde
Hub
Hub
Hub
Hub
423 - CD SP
So Bernardo do Campo
009 - BIG SP
Ipiranga
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
Hub
Hub
Hub
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
2 Mbps
Hub
512 Kbps
SONAE POA
Sede Adm.
SONAE CWB
Esc. Regional
SONAE CWB
CD Pinhais

F|gura -1 Corexao 3orae d|relarerle ro 8ac|oore VPL3


101
Para a segunda fase deste projeto, exposta as duas possibilidades:
-Uma conexo entre ao sites que no esto na rede Diveo pode ser realizada via Internet.
Rede Internet
IPSEC
PROJETO SONAE - REDE DIVEO + IPSEC - FASE 2 Backbone IP/MPLS
Diveo
Backbone IP/MPLS Diveo
Hub
Hub
Hub
Hub
512 Kbps
011 - BIG SP
Tucuruvi
012 - Candia SP
Freguesia do
072 - BIG SP
Pirituba
077 - BIG SP
Santo Amaro
Hub
089 - BIG CPS
Campinas Out Let
088 - BIG SP
Santo Andr
087 - BIG CPS
Campinas Shopping
084 - BIG SP
Casa Verde
Hub
Hub
Hub
Hub
423 - CD SP
So Bernardo do
Campo
009 - BIG SP
Ipiranga
512 Kbps 512 Kbps
512 Kbps
512 Kbps
512 Kbps
Hub
Hub
Hub
512 Kbps
512 Kbps
512 Kbps
512 Kbps 512 Kbps
2 Mbps
Hub
512 Kbps
Dat a Ge nera l
Ponto Concentrador
IP SEC
016 - BIG SP
Morumbi 030 - BIG SP
Tatuap
031 - BIG Santos
Aparecida
069 - BIG Garulhos
Bom Jesus
086 - BIG SP
So Miguel
099 - BIG SP
Limeira
113 - BIG SP
Mogi Guau
151 - BIG SP
Araras
166 - BIG SP
Piracicaba
199 - BIG SP
Americana
SONAE CWB
CD Pinhais
SONAE CWB
Esc. Regional
SONAE POA
Sede Adm.

F|gura -5 Corexao 3orae v|a lrlerrel cor lP3ec
Outra alternativa a utilizao de circuitos dedicados atravs de meios de terceiros para
conectar ao sites que no esto na rede Diveo.
PROJETO SONAE - REDE DIVEO + 3Os. - FASE 2
Backbone IP/MPLS
Diveo
Backbone IP/MPLS Diveo
Hub
Hub
Hub
Hub
512 Kbps
011 - BIG SP
Tucuruvi
012 - Candia SP
Freguesia do
072 - BIG SP
Pirituba
077 - BIG SP
Santo Amaro
Hub
089 - BIG CPS
Campinas Out Let
088 - BIG SP
Santo Andr
087 - BIG CPS
Campinas Shopping
084 - BIG SP
Casa Verde
Hub
Hub
Hub
Hub
423 - CD SP
So Bernardo do
Campo
SONAE POA
Sede Adm.
SONAE CWB
Esc. Regional
SONAE CWB
CD Pinhais
009 - BIG SP
Ipiranga
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
Hub
Hub
Hub
512 Kbps 512 Kbps
512 Kbps
512 Kbps 512 Kbps
2 Mbps
Hub
512 Kbps
016 - BIG SP
Morumbi
030 - BIG SP
Tatuap
031 - BIG Santos
Aparecida
069 - BIG Garulhos
Bom Jesus
086 - BIG SP
So Miguel
099 - BIG SP
Limeira
113 - BIG SP
Mogi Guau
151 - BIG SP
Araras
166 - BIG SP
Piracicaba
199 - BIG SP
Americana
Dat a Ge ne ra l
Ponto Concentrador
3os.
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps
512 Kbps

F|gura - Corexao 3orae v|a re|o lis|co de lerce|ros cor VPL3


102
Concluso do Projeto realizado:
A principal lio no case ora abordado est evidenciado no sucesso da parceria com
empresas afins, neste caso a PHASECOM, que alm de ser representante da Philips,
responsvel pela operao e manuteno dos equipamentos de telecomunicaes com tecnologia
Philips, aplicado na rede SONAE. Esta parceria possibilitou prospectar necessidades e apresentar
solues ao cliente.
Outra tambm importante lio, que uma rede com as caractersticas da rede DIVEO,
suporta adequadamente aplicao de voz com tima qualidade, desempenho e fcil configurao
dentro do seu backbone ATM.
Podemos concluir que esses clientes alm de necessitarem tratamento diferenciado, ou
seja, da aproximao das equipes tcnicas de ambos os lados, as mesmas necessitam cada vez
mais de profissionais capazes de agregar solues atravs de parcerias, como a que pude realizar
entre a DIVEO e a empresa PHASECOM, no sentido de resolverem os problemas, tais como:

Integrao em um ambiente nico de telefonia;
Contingncia de meios (rede pblica ou integrada);
Contingncia para back-up de armazenamento de dados (Data Center);
Evoluo para topologias com hierarquia digital avanada (imagem, VoIP, tele-
conferncia, VPN suportados IP-MPLS).

No que diz respeito ao ltimo item, evoluo da topologia, ainda est sendo negociada
a implementao deste segundo projeto, portanto no existem dados, quanto reduo de
custos, pois o diferencial citado pelo cliente foi que as redes j estavam tendo a necessidade de
mudar, evoluir, pois era uma necessidade a melhoria de qualidade, confiabilidade,
disponibilidade e gerenciamento dos processos que o SONAE necessita, neste caso aplica-se o
conceito comentado anteriormente de site central. Essa topologia abranger a necessidade do
cliente em aumentar sua produtividade com a interligao dos pontos existentes, trazendo uma
maior dinmica aos processos. O que se prev com esta implementao que a Rede MPLS
100% gerencivel, trazendo uma maior confiabilidade do sistema atual(diminuio de problemas
com perda de pacotes e com interrupo de ligaes entre sites).



103
Projeto reduz em cerca de 25% custos de telefonia da rede
Sonae
-- 05/05/2003 --
Projeto teve incio com a criao de uma rede ATM de 2MB para integrar no ambiente IP a
comunicao entre dois escritrios e trs centros de distribuio
Thais Aline Cerioni
"Quando traamos os planos para 2003, foi determinada uma reduo dos custos de comunicaes, que
estavam muito altos", relembra Oggo Machado, gerente de produo do Sonae Distribuio Brasil. Com o
desafio nas mos, a empresa do setor de supermercados - cuja rede inclui os varejistas Big Hipermercados,
Nacional Supermercados, Cndia e Mercadorama e os atacadistas Max e SDB - decidiu implementar uma rede
para transportar o trfego de voz entre os escritrios e centros de distribuio da companhia, localizado nos
estados da regio Sul e em So Paulo.
O projeto teve incio em dezembro do ano passado e j gerou uma economia entre 20% e 25% com custos de
telefonia para o grupo. O primeiro passo, conta Machado foi contratar links ATM de 2MB, da Diveo, para
interligar os escritrios de So Paulo e Curitiba, alm dos centros de distribuio de So Bernardo do Campo
(SP), So Jos dos Pinhais (PR) e Porto Alegre (RS). Transportando assim a comunicao da empresa para o
ambiente de voz sobre IP. "No entanto, a Diveo forneceu apenas o meio fsico, necessitvamos ainda de um
software que fizesse a integrao entre as centrais telefnicas de cada local", conta o executivo.
Ento, a SDB procurou a Philips, fornecedora das centrais telefnicas, a qual ofereceu um softwrae para
criao de uma VPN. "Assim, como se todos os telefones das cinco unidades estivessem em uma mesma
central", garante. O gerenciamento da infra-estrutura foi terceirizado pela SDB, sendo responsabilidade da
Servicom. "Nosso negcio no telefonia, vender arroz e feijo", brinca Machado, explicando, que alm do
maior foco nos negcios de core, a terceirizao promove reduo de custos.
Iniciado em dezembro do ano passado, o projeto integrou quatro das cinco unidades at a metade de fevereiro.
"Estamos agora finalizando a integrao da ltima unidade", revela o executivo. Machado no quis revelar o
investimento feito no projeto, mas acredita que o retorno dever ocorrer em cerca de dois meses. "Agora,
estamos fazendo o levantamento das ligaes intra-rede para verificar o volume de chamadas realizados entre
as demais unidades (lojas), trabalho que deve ser finalizado entre maio e junho", conta Machado, e explica:
"Se a economia compensar o investimento, iremos levar a rede s lojas tambm."
http://www.telecomweb.com.br/noticias/artigo.asp?id=37517

Taoe|a -1 Repolager: Rede 30NAE e a so|uao de corecl|v|dade de voz.









104
6.2.2. Cliente: PUCRS
Sobre o cliente:
A Pontifcia Universidade Catlica do Rio Grande do Sul (PUCRS), reconhecida como
uma das maiores universidades particulares do pais, visto que atualmente conta com
aproximadamente 29.000 alunos, 2.000 professores e 1.200 funcionrios. A universidade oferece
44 cursos de graduao, 47 cursos de especializao, 23 mestrados e 13 doutorados. Hoje a
PUCRS possui quatro Campus avanados, primeiramente o Campus Ipiranga na cidade de Porto
Alegre, sendo este o Campus principal; o Campus Zona Norte, tambm em Porto Alegre; o
Campus Viamo, localizado no municpio de Viamo 30 Km da capital e o Campus de
Uruguaiana, localizado 780 Km da capital gacha. Esta universidade conta com uma infra-
estrutura para atendimento de EAD (Educao Distncia). Podemos destacar o curso de
Engenharia Qumica, que atende a demanda de treinamento aos Plos Petroqumicos Nacionais.

Necessidade:
A PUCRS estava reestruturando os servios interconexo de redes de acesso para trfego
de Voz(Via Embratel) este foi o incio das negociaes com a Universidade para iniciarmos os
projetos que sero descritos.

Abordagem:
A abordagem a uma Instituio de Ensino, forte como a PUCRS, sem dvida
diferenciada, principalmente pelas implicaes comportamentais, quer pelo conhecimento
intrnseco da utilizao de meios (multimdias), bem como o aspecto de estar na vanguarda.
Atualmente as Universidades concorrem entre si, e sem dvidas, meios eletrnicos de acesso
para alunos, quer para pesquisa atravs da RNP (Rede Nacional de Pesquisa) como para a
Internet, fazem a diferena. Outro ponto de destaque entre as Universidades que a mesma seja
um AS (Sistema Autonomo).
Atravs desses cenrios, empresas do porte da Diveo por si s, se insere neste contexto,
visto as Universidades serem um mercado cada vez mais promissor. Neste Case irei abordar as
lies que aprendemos bem como apresentar as solues oferecidas que evidenciaram o sucesso
com esse importante cliente.


105
Resoluo do Problema(case em si):
Tudo comeou quando a Embratel nos solicitou (Diveo) a instalao de um circuito DBA
para atendimento da PUCRS (Campus Ipiranga) para o servio de VIP Phone da Embratel(uma
espcie de Sempre 21 empresarial, onde todas as ligaes para outros DDDs so realizadas
pelo Embratel), pois a Diveo possui uma parceria nvel nacional com a Embratel para
atendimento last mile. Como a instalao do circuito foi bem executada e acompanhada com
toda a preocupao necessria, chamou a ateno do pessoal da rea de Comunicaes da
Universidade. Um fato, que certamente tambm chamou a ateno foi desde o incio das obras a
presena e o acompanhamento dos servios executados, onde possibilitou-me dar toda
assistncia, at mesmo pelo conhecimento da estrutura da PUCRS, fazendo que a Diveo
conseguisse a confiana PUCRS para iniciarmos uma parceria de melhoramentos na estrutura
desta Universidade, at mesmo pelo fato de estar realizando algo para a Universidade PUCRS,
no visando somente o lado comercial e sim levando em considerao o fato de poder trazer
melhorias a esta instituio.
Partindo do princpio que a PUCRS est em crescimento e que certamente ir expandir
sua rede a outros Campus, fizemos uma visita tcnica ao pessoal tcnico do CPD da
Universidade. Desde ento comeou uma troca de informaes e a partir da iniciamos o
atendimento direto PUC para questes de acessos (DBA e DBI).
O primeiro atendimento foi a interconexo do Campus da PUCRS UFRGS aonde a
porta de com a RNP(Rede Nacional de Pesquisa). A PUCRS j possua um acesso de
conectividade com a RNP, mas devido ao nmero de falhas e pelo fato do rdio ethernet
existente apresentar problemas constantes, esse fato gerou um descontentamento por parte da
PUCRS com o servio que estava sendo prestado, alm disso a PUCRS estava conectada via
2E1s(4Mb) balanceados em um roteador Cisco 2501, e o acesso estava praticamente no limite
mximo de utilizao, onde gerava-se uma demanda reprimida de internet por no haver um link
mais rpido com a RNP. Baseado na atual situao do acesso RNP, foi realizado um projeto
para atender esta necessidade mantendo a qualidade dos servios que dependiam deste acesso,
onde a PUCRS realizou uma anlise em diversos aspectos sobre as empresas que poderiam
atender esta demanda. Uma vez que a Diveo j havia atendido a PUCRS em diversas
oportunidades(suporte ao acesso Embratel, testes com o Terra e ligaes de enlaces provisrios
para Feira), onde todos estes servios apresentaram capacidade de superviso e monitoramento
on-line, a soluo Diveo foi caracterizada como a melhor em questes tcnicas. Os

106
equipamentos providos possuem alta performance de processamento e memria, com interface
de conexo escalonvel at 34MB, sendo que a configurao apresentada conecta a PUCRS
diretamente no POP-RS sem haver a necessidade de saltos por hops. Instalamos um enlace de
rdio entre prdio 41(CPD PUCRS)e o prdio da Odontologia da UFRGS com capacidade de
34 Mbps. Porm tanto o POP-RS como a PUCRS possuem uma estrutura de rede que roda em
cima de interfaces Fastethernet 10/100Mps, com isso foi necessrio a colocao de um Switch
com interfaces G.703 E3 para Fastethernet. Esta configurao faz um tunelamento em ATM
ponto-a-ponto, onde os equipamentos ligados nas Fastethernet se comportam com se estivessem
cascateados ou ligados diretamente um no outro.

F|gura -Z PuC3- Corexao RNP: Acesso arler|or v|a do|s ||r|'s E1's


107

F|gura -8 PuCR3- Corexao RNP: 3o|uao LAN-lo-LAN E3 0|ear 0nanne|

A figura acima descreve o acesso realizado para o fornecimento de um link E3 em ATM,
foram utilizados switches ATM Lucent(PSAX100), na UFRGS o enlace de rdio foi instalado
em outro prdio longe do CPD(devido a dificuldade de visada entre o prdio do CPD UFRGS e o
CPD PUCRS), para tal situao foi necessrio implementar dois conversores E3 eletro-
ptico(conexo do swict PSAX100 Lucent com o Rdio E3).
Algumas consideraes tcnicas que foram levantadas para considerara a
dimenso(velocidade de link) e a tecnologia utilizada para conexo com a RNP(E3 ATM):
- Os usurios da Biblioteca relatavam constantemente problemas com a velocidade do acesso
dos servios ON-LINE mantidos pela Unidade.
- Questionava-se a existncia de uma demanda reprimida de utilizao da internet, onde
pesquisadores e alunos poderiam estar deixando de utilizar o acesso, dando a impresso de
que o link de acesso(2E1s) em funcionamento era suficiente. Isto pode-se verificar aps a
implementao da soluo E3 ATM, onde o acesso normalmente tem utilizado um a banda
superior 4Mbps.



108
O segundo atendimento, foi de acesso Internet, baseado que a PUC necessita tornar-
se um AS, e para tal contratou da Diveo inicialmente 3 acessos de 2Mbps IP, que at o final
deste ano, com a implantao do Autnomo System na Universidade, se tem a previso de
expandir a rede para 10 Mbps IP, esta definio para evitar a dependncia do acesso da RNP, a
soluo estudada pela PUCRS foi avaliada levando em considerao os custos, a no
dependncia da RNP, as alternativas de acessos(nacionais e internacionais) contemplando um
nmero de hops aceitveis e a capacidade de expanso imediata do link com um tempo reduzido
de instalao.
Abaixo um diagrama de conexo que mostra o acesso atual da rede IP. Este link est
sendo utilizado atualmente para acesso interno da PUCRS e para testes juntamente com o EAD.

RDIO 16E1
Existente
BACKBONE
ATM
CISCO 7500
SWITCH PSAX 1250
SITE: HUB CENTRO
PUC RS
FastEth
2 Porta Fastethernet
3 Portas G.703 E1
Rede Diveo POA
FastEth
conexo
CPD
CONEXO ATUAL CIRCUITOS IP - PUCRS 3xE1
01 roteador com 2048Kb/s e outro roteador com 4096Kb/s com load balancing nas interfaces seriais

F|gura -9 PuCR3- Corexao lrlerrel: Topo|og|a 08l 3E1 0|ear 0nanne| - Rourer com |oao oa|anc|ng

RDIO 8E1
Existente
BACKBONE
ATM
CISCO 7500
SWITCH PSAX 1250
SITE: HUB CENTRO
PUC RS
FastEth
Foundry NetIron
Router a ser
adquirido
1 Porta Fastethernet
5 Portas G.703 E1
BGP4
Rede Diveo POA
TOPOLOGIA SUGERIDA PARA IMPLEMENTAO DO
AS(Autonomo Systens) DA PUCRS

F|gura -10 PuCR3- Corexao lrlerrel: Topo|og|a 08l 5E1 0|ear 0nanne| - Rourer com 3SP4


109

Aps a implementao do AS, a PUCRS poder prover de uma nica sada para toda
universidade, tendo duas rotas externas configuradas via o protocolo BGP4(Border Gateway
Protocol), onde tanto a topologia acima exemplificada, quanto a soluo para acesso RNP vista
anteriormente, podero ser conectadas em uma nica sada. Para isso existe a necessidade de
balancear o trfego, ou seja a sada via RNP e a sada via Diveo(ou outra operadora) dever ter a
mesma carga nas interfaces, pois pela ltima atualizao de IOS dos roteadores
Cisco(Fevereiro/2003), possvel conectar at oito interfaces em um nico roteador utilizando o
BGP4.
O terceiro atendimento foi um projeto realizado para interconectar os campus(Ipiranga,
Viamo e Zona Norte), pois a PUCRS mantinha um circuito de 512Kbps entre o campus Zona
Norte e o campus Ipiranga e o campus de Viamo estava sem conexo. Esta interligao entre os
campus para que a PUCRS pudesse realizar o fornecimento de voz inicialmente e
posteriormente implementar neste mesmo acesso dados, onde ao campus Zona Norte e Viamo
pudessem acessar via um site central no campus Ipiranga, para isso e servio de voz ser sobre
IP. Em termos de tecnologia, h um abismo entre as opes tradicionais e as solues IP, o
conceito de telefonia IP est de acordo com as tendncias de todo um mercado mundial, onde
operadoras de telecomunicaes j esto trabalhando nesta realidade, alm de ser passvel de
implementao no s para atender a necessidade do Campus Viamo, como tambm para os
demais Campus, inclusive o Central.
A questo custo-benefcio no deve ser avaliada comparando-se simplesmente o valor de
um aparelho ip com um aparelho analgico, e sim quais os valores agregados, quais os custos
para instalao e administrao de infra-estruturas duplicadas e a proteo do investimento em
relao a tecnologia adquirida.
Para qualquer soluo IP deve-se atentar para o clculo que feito para uma ligao IP
chegar at a central telefnica tradicional, que relaciona o nmero de chamadas simultneas de
um lado para o outro, nas configuraes propostas este nmero varia de 5 a 8 ligaes
simultneas, sendo que para o aumento deste nmero um mdulo ou licena de software deve ser
adquirido.
Para que a PUCRS pudesse implementar sua soluo de voz sobre IP, necessitava-se de
um acesso confivel, desta forma foi realizada a interconexo dos Campus Ipiranga x Viamo,
aonde disponibilizamos 2x2Mbps DBA, concomitante sugerimos fazermos a interconexo do
outro Campus da Zona Norte(que estava sendo acessado via GVT), com isso foi otimizada

110
utilizao dos rdios e disponibilizado mais 2x2Mbps DBA (Ipiranga x Zona Norte), totalizando
assim 4E1s DBA .
Neste atendimento evidenciamos algumas solues para interconexo dos campus:
- A topologia em anel entre os campos Ipiranga, Zona Norte e Viamo;
- A multiplexao para possibilitar voz, dados e vdeo, atravs de um nico circuito,
otimzando o fsico(esta implementao de multiplexao foi realizada somente no circuito
entre o campus Ipiranga e o campus Uruguaiana, ser vista no prximo atendimento).

1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
Radio Campus ZN
Radio Campus Ipiranga
Public switch Public switch
PBX
PBX
Frame Relay
Ponto a Ponto
Soluo PUCRS
REDE ATM
DBA
DBA
Ipiranga
Zona Norte
Radio Campus Viamo
Public switch
PBX
1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
Viamo DBA

F|gura -11 PuCR3- lrlercorexao dos carpus: Topo|og|a 08A's E1 0|ear 0nanne| - voz

O quarto atendimento diz respeito interconexo do Campus Uruguaiana, a PUCRS
estava conectada via um Link dedicado da EMBRATEL de 256 kb, utilizando roteadores cisco
srie 2500 nas extremidades dos acessos e uma MUX para disponibilizar um feixe de128Kbps
para voz e 128Kbps para dados e ainda havia um acesso de internet local em Uruguaiana de
128Kbps.

111
Com este cenrios a PUCRS necessitava otimizar os recursos com uma soluo mais
robusta, foi proposto utilizar um nico acesso para interconectar as centrais telefnicas
existentes(entre Porto Alegre e Uruguaiana) multiplexando em um nico circuito E1, voz e
dados. Visto que em Uruguaiana o acesso s redes de dados so instveis e a Universidade
utilizava um acesso via Embratel de baixa kilobitagem. Aps a implementao da soluo,
circuito E1 entre Porto Alegre e Uruguaiana, sendo 256Kbps utilizados para voz e o restante da
banda utilizado para dados, multiplexados . Uruguaiana passou a utilizar 4 canais de voz, e uma
banda de 1728Kbps para acesso aos sistemas coporativos(banco de dados) que esto todos em
Porto Alegre e para o acesso Internet. A PUCRS centralizou o acesso internet em Porto
Alegre, ao mesmo tempo reduziu o custo retirando o link de 256(voz & dados) que era mais caro
do que a soluo adotada, e ainda economizou com a retirada do outro de link de 128 para acesso
Internet que estava ligado em Uruguaiana, pois no havia mais necessidade.
1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
Radio Campus Uruguaiana
Public switch
Public switch
PBX
PBX
REDE ATM
E1
Ipiranga
1 2 3
4 5 6
7 8 9
* 8 #
1 2 3
4 5 6
7 8 9
* 8 #
Radio Campus Ipiranga
E1
256Kbps
1728Kbps
256Kbps
1728Kbps
Emulao de circuitos sobre ATM

F|gura -12 PuCR3- lrlercorexao dos carpus: Topo|og|a 08A's E1 0|ear 0nanne| -voz & 0aoos

Verificando-se a topologia das duas ltimas figuras acima, podemos verificar que a
PUCRS est convergindo o acesso IP destes Campus, evidenciando assim o aumento da banda
IP disponibilizada no Campus Ipiranga, prevendo-se que a Universidade poder aumentar(up-
grade) a sua banda de acesso a Internet pelo backbone de operadoras(Diveo, EBT, Intelig..), uma
vez que a atual RNP possui um backbone de transporte instvel, alm da dependncia de meios
de terceiros e a falta de um gerenciamento pr-ativo sobre a rede. Visando a homologao do AS

112
Para que se possa concentrar todos os acessos num nico switch dever haver balanceamento de
cargas, mais um motivo para aumentar a banda IP por outras operadoras e no pela RNP.

Concluso do Projeto realizado:
A principal lio, que as Universidades esto caracterizadas como clientes
extremamente importantes e que esto cada vez mais interessados em acessos (DBA, DBI) .
Podemos concluir que esses clientes alm de terem tratamento diferenciado, ou seja,
aproximao das equipes tcnicas , eles necessitam cada vez mais de profissionais com o senso
de resolver os seus principais problemas como um todo, e no isoladamente, tais como os citados
neste case:

- Acesso a RNP, rea de pesquisa (DBA);
- Obteno de AS (Internet DBI);
- Solues de interconexo de Campus (DBA);
- Possveis solues para o Acesso a EAD (utilizao de redes ATM com MPLS);
- Contingncia de meios (DBA e roteamento sobre MPLS);

Em uma anlise juntamente com o cliente, aps a implementao de todos estes servios
podemos constatar que:
- Em termos percentuais, a PUCRS estima retornar seu investimento em uma ano, sendo
uma economia de mais de 70% no total das operaes, pois com a utilizao de links robustos
no h necessidade de ter sistemas de telefonia, armazenamento e processamento de dados
distribudos por todas as localidades onde ela est instalada, tornando o custo de propriedade
extremamente baixo ou inexistente.
- De acordo com o planejamento estratgico da Universidade, em todo mundo , a internet
j atinge 80 milhes de lares e seu potencial para o ensino est apenas comeando a ser
explorado. Com a implantao da Internet2, uma srie e barreiras tecnolgicas esto sendo
superadas(ex: velocidade dos acessos), favorecendo ainda mais o desenvolvimento de
programas de ensino distncia e a comunicao entre a universidade e a comunidade
acadmica e social da qual faz parte.

113
7. O mercado atual e as necessidades

Atualmente o mercado est carente no que se refere a solues completas. O cliente
possui uma determinada necessidade, exemplo acesso a Internet e quando o mesmo sai procura
de provedores de acesso, ele os acha porem a sua necessidade que era apenas uma se torna
varias. O cliente ter que comprar um router, um firewall e muitas outras coisas para realmente
poder ter acesso a Internet, isto se deve principalmente porque a Internet se tornou um meio onde
os servios agregados, ou seja, e-mail, proxy, servios de segurana, voz, etc so bem lucrativos.
Estes servios cada vez mais complexos tem sido a grande mudana que as
telecomunicaes tem sofrido. Muitos deles que eram at ento fornecidos separados e por meios
distintos, agora rodam sobre uma nica plataforma, o TCP/IP; e nisso que se faz um diferencial
na questo de rede e principalmente na questo de se manter o cliente e prospectar novos
clientes. Uma soluo completa onde o cliente necessita em primeiro lugar de banda larga pois o
contedo pesado em decorrncia dos mltiplos servios. Estes servios so desde um simples
e-mail at uma tele-medicina, videoconferncia, treinamento distncia ou um grande provedor
de contedo.








114


F|gura Z-1 0rardes r|cros de rercado e suas ap||caoes

Os servios de telecomunicaes, tornam-se a cada dia mais especializados, pois
necessitam de uma dedicao quase que exclusiva por parte do engenheiro, para analisar cada
caso.
A figura acima tem o intuito de colocar alguns exemplos de necessidade como:
- Ensino a distancia(ex: PUCRS), a educao distncia (EAD), teleconferncia,
consulta a bibliotecas (base de dados pesadas), Internet, circuitos dedicados e outros
representam uma verdadeira revoluo para a educao neste milnio. As instituies
educacionais e profissionais precisam se preparar urgentemente para enfrentar e
aproveitar eficientemente as novas topologias de rede. Sabemos que no fronte mais
avanado, veremos aplicaes sofisticadas como a tele-presena (exemplo: exames
vdeo-endoscpicos interativos remotos), realidade virtual (navegao remota em
ambientes tridimensionais) tele-cirurgia e robtica (manipulao cirrgica distncia
com viso 3D), etc.

115

- Rede integrada de servios(ex: Sonae), atualmente existe uma mudana no perfil do
consumidor, onde todos os servios(alimentao, vesturio, eletro-eletrnicos e
outros...) foram centralizados no mesmo local, gerando assim grandes shopping
centers e num nvel mais acessvel populao, as grandes redes de mercados, onde
existe a necessidade de infra-estrutura para suportar a rede(telefonia, site backup,
solues de hospedagem e outros).
- Provedores de servios, este o nicho que necessita de um atendimento mais
qualificado, pois so os meios onde se podem gerar grandes empreitadas, a entra o
papel do engenheiro como agregador de solues. Os provedores de servios,
entenda-se Provedores de Internet e as Operadoras de Telefonia Mvel
Celular(fornecimento de dados com mobilidade) so grandes provedores de servios
que necessitam ter uma rede muito bem estruturada para o fornecimento de circuitos
de dados. Atualmente a tecnologia de acesso para redes de celular j algo que est
aperfeioado, entretanto o core da rede e os elementos internos so muitas vezes
equipamentos de outras empresas(existe uma terceirizao da rede de transporte, ou
seja, utilizao de backbone de terceiros) o que faz com que o servio fornecimento
de dados no sejam totalmente confivel, uma vez que a rede de transporte no cem
por cento gerencivel.

Com essa realidade o que ouso em apresentar uma proposta de servios que est apta
para atender essas demandas.






116
8. Mudanas da Rede
A Internet mudou as relaes de negcios nas empresas de telecomunicaes. Os
servios que antes rodavam em separado, agora necessitam estar reunidos rodando sobre o
protocolo TCP/IP.
As redes de certa forma esto prontas para suportar o protocolo, porm, fazer com que os
servios rodem sobre o mesmo um problema. Podemos ter QoS nos servios atuais rodando
sobre plataformas ATM. Como alternativa o MPLS vem a complementar ou solucionar em parte
o problema. O MPLS pode garantir QoS sobre uma rede IP porm inicialmente encarece a
estrutura para a empresa fornecedora. A soluo para tal problema manter a rede ATM para
interconexo de backbone e utilizar o MPLS no ponto em que o cliente est conectado at a sada
para internet, ou seja, somente dentro do backbone da operadora.
Desta forma, tem-se uma otimizao do trnsito de pacotes dentro da rede, liberao de
processamento dos switches, uma vez que os mesmos tero caminhos pr-estabelecidos pelos
rtulos do MPLS. Tambm possibilita a facilidade de conexes simultneas entre sites, que um
caso para solucionar as grandes redes que desejam estar interconectadas e com integrao entre
as redes das filiais com a matriz.









117
9. Concluses

Para que o profissional possa manter-se no mercado necessrio fornecer solues
completas. Estas solues sero frutos de relaes conjuntas de diferentes empresas.
A tecnologia MPLS deve ser utilizada como complemento nas solues existentes. Toda
soluo deve visar tirar o cliente da rea de conforto, provocando-o a procurar novos servios.
A competio entre empresas de Telecomunicaes tem causado a queda nos preos dos
servios, porem manter a qualidade do servio primordial para garantir a fidelidade.
Se a qualidade no pode ser mantida com baixo custo prefervel ter qualidade de
clientes.
A resistncia dos clientes no que se refere aceitao de novos servios o reflexo de
mercado que ainda no est totalmente livre da mentalidade conservadora do antigo monoplio.
A diversificao de fornecedores e produtos tem por vezes causando danos na confiabilidade,
pois houve o surgimento de vrias empresas e servios que no cumpriam com as expectativas e
qualidade esperados de um servio de telecomunicao, reforando assim o antigo nome do
monoplio.
Uma das principais preocupaes das grandes empresas que fornecedoras de servios(
provedores de internet provedores de telefonia mvel) a garantia de servio, pois atualmente a
tecnologia de acesso est muito bem dimensionada e evolui de forma exponencial, o grande
problema destes fornecedores que muitos utilizam servios de interconexes de terceiros, no
tendo gerenciamento ao que poderamos chamar de backbone terceirizado da sua rede, pois eles
utilizam um backbone de terceiros do qual no possuem nenhum controle. Portanto o engenheiro
capaz de agregar solues com confiabilidade e qualidade para estes grandes projetos um
profissional com viso de engenharia, o que podemos dizerengenheirar, ter uma viso do
problema como um todo. O mercado atualmente est carente de solues para resoluo de
grandes redes.


118
10. Referncias Bibliogrficas
A Brief History of the Internet foi escrita por Barry M. Leiner, Vinton G.
Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch,
Jon Postel, Larry G. Roberts e Stephen Wolff.
SOARES, LEMOS,COLCHER. Redes de Computadores.Segunda
Edio.Editora Campus, 1995
DOWNES, FORD, LEW, SPANIER E STEVENSON. InternetWorking
Manual de Tecnologia.Segunda Edio. Editora Campus, 2001
MATTEHNW, Naugle. Guia ilustrado do TCP/IP.Primeira Edio.Editora
Berkeley,2002.
www.cisco.com
www.diveo.com.br
www.atmforum.com
AWDUCHE, D., et al, RFC 2702 - Requirements for Traffic Engineering
Over MPLS, 1999;
Estudo de Anlise: RFC2547 BGP/MPLS VPN
Estudo de Anlise: RFC2702 Requirements for Traffic Engineering Over
MPLS
ASHWOOD-SMITH, P. & JAMOUSSI, B., MPLS Tutorial, Nortel
Networks, 1999, http://www.nanog.org/mtg-9905/ppt/mpls/index.htm
ANDERSSON, L., et al., RFC 3036 - LDP Specification, 2001; The
International Engineering Consortium, Multi Protocol Label Switching,
http://www.iec.org/online/tutorials/mpls/
ITU-T Recommendation I.361, "B-ISDN ATM Layer Specification",
Helsinki, 1993
ERICSSON Microwave Systems AB Microwave Solutions
Mini-Link E Instalation Manual

Das könnte Ihnen auch gefallen