Oi Lilian,
Voce tem raz�o.
O que quis dizer � que eu possor listar mais de 50 protocolos
que podem ser encapsulados pelo frame-relay ou pelo ATM.
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 -----
From: "Lilian Campos Soares" <[EMAIL PROTECTED]>
To: "Lista de Discuss�o Rede Wan" <[EMAIL PROTECTED]>
Sent: Thursday, August 10, 2000 6:13 PM
Subject: ENC: [redewan] Velocidade FR x HDLC
> 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,
>
> Lilian Campos Soares
> Coordena��o Geral de Inform�tica
> INCRA
> Tel.: 61.411-7747 Fax: 61.326-6578
>
>
> ----- Mensagem original -----
> De: Kevison Dennys Carrilho Bentes [SMTP:[EMAIL PROTECTED]]
> <mailto:[SMTP:[EMAIL PROTECTED]]>
> Enviada em: quarta-feira, 9 de agosto de 2000 19:23
> Para: Lista de Discussco Rede Wan
> Assunto: Re: [redewan] Velocidade FR x HDLC
>
> Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br
> <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] <mailto:[EMAIL PROTECTED]>
>
> ----- Original Message -----
> From: Luiz Fernando T. Campos <mailto:[EMAIL PROTECTED]>
> To: Lista de Discuss�o Rede Wan <mailto:[EMAIL PROTECTED]>
> 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
> <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
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
>
> ----- Original Message -----
> From: Edgar Shine <mailto:[EMAIL PROTECTED]>
> To: Lista de Discuss�o Rede Wan <mailto:[EMAIL PROTECTED]>
>
> 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 <http://www.networkdesigners.com.br>
>
>
>
> -----Original Message-----
> From: Gustavo S. Gaidzinski
> [mailto:[EMAIL PROTECTED]] <mailto:[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
>
> _____
>
>
>
> _____
>
>
>
> ______________________________________________________________________
>
|
