Date: Aug 11 2000 08:12:40 EDT
From: "Alexandre Otto Durr" <[EMAIL PROTECTED]>
Subject: Re: [redewan] Velocidade FR x HDLC

Mas espera a�,
que eu saiba o ATM surgiu junto c/ a tecnologia B-ISDN no final dos anos 80.
Ele j� tem "canais virtuais"p/ voz , v�deo e dados. Ou seja, ele j� foi proposto p/ se usar VOZ.
Outra coisa, o ATM � da camada 2 (enlace ou datalink) ou seja, se sua rede for ATM end to end vc n�o precisa nem do protocolo IP.
Corrijam-me se estiver enganado...
[]
Otto
-----Original Message-----
From: Kevison Dennys Carrilho Bentes [mailto:[EMAIL PROTECTED]]
Sent: quarta-feira, 9 de agosto de 2000 19:23
To: Lista de Discuss�o Rede Wan
Subject: Re: [redewan] Velocidade FR x HDLC

Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br

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.
Kevison Dennys Carrilho Bentes
Engenheiro de Rede
Air System Network
Bras�lia - DF Brasil
Fone: 55 61 313-8002
Fax: 55 61 313-8008
[EMAIL PROTECTED]
----- Original Message -----
Sent: Tuesday, August 08, 2000 9:17 PM
Subject: Re: [redewan] Velocidade FR x HDLC

Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br

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
----- Original Message -----
Sent: Monday, August 07, 2000 1:37 PM
Subject: RE: [redewan] Velocidade FR x HDLC

Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br

-----Original Message-----
From: Gustavo S. Gaidzinski [mailto:[EMAIL PROTECTED]]
Sent: sexta-feira, 4 de agosto de 2000 06:33
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



Responder a