Oi Lilian,
O problema do ATM � o custo.
� muito caro ter ATM, ele s� se justifica comercialmente quando
voce necessita disponibilizar grandes larguras de banda.
Enviei para lista, tres p�ginas que mostram como os fabricantes
est�o usando ATM nos switches.
O Frame-relay na teoria usa a faixa de 64 kbps at� 45 Mbps.
Comercialmente, a Cisco tem interface frame-relay a 4 Mbps.
Nos switches que conhe�o, a maior velocidade � de 2 Mbps.
O ATM na teoria n�o tem limite, mas, o custo-benef�cio em
velocidades menores que o T1 � alto.
Comercialmente, para ATM a faixa �:
Lan ATM: 25 Mpbs a 155 Mbps.
Wan ATM: 1,5 Mbps (T1) - 2 Mbps (E1) a 622 Mbps
Grato.
> Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br
>
> Kevison,
>
> N�o entendi a quest�o do ATM. Na documenta��o que pesquisei, o ATM foi
> projetado para convergir as diferentes m�dias (voz, v�deo e dados).
>
> Por que somente em links maiores do que 2Mbps?
>
> Voc� teria material sobre isto?
>
> Grata,
>
>
>
> Oi Luiz,
>
> O frame-relay n�o foi feito especificamente para trafegar o sinal de voz.
> Muito menos o ATM ou o IP.
>
> H� tres t�cnicas no momento para trafegar o sinal de voz via rede:
> Voz sobre IP - VoIP.
> Voz sobre Frame-relay - VoFR.
> Voz sobre ATM - VoATM.
>
> Enviei uma p�gina que tece considera��es sobre as tres
> tecnologias.
>
> Tecnicamente, o sinal de voz sofre uma degrada��o maior com VoIP.
>
> O tr�fego de voz em VoIP consome 50% de tr�fego a mais do que
> VoFR.
>
> Voce consegue usar um canal de voz com VoFR consumindo apenas
> 8,2 kbps em um link de 64 kbps.
>
> Voce s� vai conseguir usar ATM em links maiores que 2 Mbps.
>
> O sinal de voz trafega muito bem com frame-relay.
>
> � �bvio a melhor rela��o custo/benef�cio do Frame-relay.
>
> Grato.
>
>
>
>
>
> S� uma observa��o, o tipo de encapsulamento do Frame Relay
> n�o � muito indicado para aplica��es como a transmiss�o de Voz.
> pois nao mantem um tempo de resposta "real time".
> o Frame Relay a grosso modo trabalha ao contr�rio do sistema ATM,
> ele fecha os dados em um pacote maior e envia, o problema � que se
> houver
> um erro nesta transmissao, o pacote grande inteiro ter� de ser
> retransmitido.
> j� o ATM divide os pacotes em pacotes encapsulados ainda menores,
> diminuindo
> assim o tempo de retransmissao em caso de erro, melhorando o tempo
> de resposta.
> Numa transmissao de voz, diz-se que eh real-time pois voce nao
> conseguiria
> entender uma voz que se cortasse ao longo da transmissao, na verdade
> se trabalha
> com um tempo de resposta dentro de 200ms, fato que numa transmissao
> de dados
> pura e simples nunca se notaria a diferenca pratica.
> S� mais uma coisa, a velocidade de transmissao � a mesma, nao
> interessa o encapsulamento,
> a �nica coisa que muda � a banda, maior ou menor o tamanho da
> palavra de bits por segundo,
> � um v�cio que pegamos de dizer que um link de 2Mbit eh mais lento
> que um de 45Mbit,
> na verdade a banda de um eh menor que outro.
> vou dar uma estudada no HDLC para poder falar dele, mas me parece
> que ele mantem um bit de controle que o Frame Relay e o ppp nao tem
> e quando chegam ao maximo da banda eles nao sao gerenciados tao
> eficientemente
> como o HDLC.
> Posso estar falando besteira, mas acho que eh por ai, vou dar uma
> olhada no material
> aqui e te falar exatamente porque o HDLC eh melhor.
>
> ate mais
>
> Luiz Fernando Campos
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
>
> Gostaria de saber se alguem teve a experiencia de
> comparar linhas usando HDLC e FR , com mesma velocidade . Pois pelos os
meus
> primeiros testes , o FR tem se mostrado um pouco mais �lento� que a HDLC .
> [Shine, Edgar] "mesma velocidade" quer dizer mesma
> velocidade fisica.
> Veja, existem alguns exemplos a serem considerados:
> - Tamanho de header: o HDLC tem um header menor que
> o FR, portanto para cada pacote que tivesse o mesmo tamanho, um pacote com
> FR teria que mandar "mais bytes" por frame.
> - Configuracao em "nuvem": como HDLC nao eh um
> protocolo de nivel 3 ele nao tem essa capacidade, eh soh pto-a-pto. FR tem
> algumas funcionalidades em N3 que permitem isso.
> - Recuperacao de erros: tanto FR como HDLC deixam
> isso como responsabilidade da aplicacao...
>
> O que eu quero dizer com as afirmacoes acima eh que comparar
> tecnologias distintas de comunicacao de dados com conceitos "eh mais
rapido"
> ou "eh mais lento" nao faz muito sentido. O que para mim faz sentido eh
> colocar a tecnologia mais adequada em cada caso (nao somente vendo a sua
> viabilidade tecnica, como vendo custos, planejamento de expansoes
> futuras...).
> Se vc pensar em transmissao pura e simplesmente e tiver uma
> linha de dados privada com alto grau de confiabilidade, melhor mandar os
> dados puros, sem formatacao e fazer comparacao direto na aplicacao, assim
> fica mais rapido do que ter protocolo.
>
> []s
> Edgar Hideyuki Shine
> Nortel Networks
>
|
