Balanceamento de Chamadas VoIP H.323 para a Rede de Telefonia Pública

Tamanho: px
Começar a partir da página:

Download "Balanceamento de Chamadas VoIP H.323 para a Rede de Telefonia Pública"

Transcrição

1 Balanceamento de Chamadas VoIP H.323 para a Rede de Telefonia Pública Anderson A. Albuquerque, Paulo H. de A. Rodrigues Núcleo de Computação Eletrônica - Departamento de Ciência da Computação/IM Universidade Federal do Rio de Janeiro (NCE/UFRJ DCC/IM/UFRJ) * Caixa Postal Rio de Janeiro RJ Brasil Laboratório de Voz Sobre IP Núcleo de Computação Eletrônica. Abstract. A distributed call load balancing algorithm for routing H.323 VoIP calls to the PSTN within the scenario, where more than one institution can complete a call, is presented. The algorithm takes in consideration all operational limitations of RNP H.323 architecture and uses the fraction of externals calls to the number of gateway voice channels not occupied by internal calls as the optimizing metrics. Simulations with different scenarios show algorithm efficacy under varying internal VoIP traffic load. The algorithm adoption in the service is been evaluated. Resumo. Um algoritmo distribuído para balanceamento de chamadas H.323 destinadas à rede pública de telefonia dentro do cenário do serviço é apresentado. São respeitadas as limitações operacionais da arquitetura H.323 da RNP, onde várias instituições interconectadas a um POP completam chamadas para uma mesma cidade. É utilizada a métrica representada pela fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas para balanceamento. Simulações com diferentes cenários comprovam a eficácia do algoritmo frente a diferentes níveis de utilização interna de VoIP nas instituições. Seu uso no serviço está sendo avaliado. 1. Introdução A estrutura de rede da RNP (Rede Nacional de Ensino e Pesquisa) possui pontos de presença (POP-RNP) em algumas cidades brasileiras, como mostrado na Figura 1, onde se interligam instituições de ensino, pesquisa ou mesmo redes. * Suporte parcial do projeto VoIP4ALL da RNP. Paulo Rodrigues é analista do NCE e professor do DCC. Anderson Albuquerque é mestrando do Programa de Pós-Graduação em Informática do NCE/DCC.

2 A RNP oferece hoje para as instituições integrantes da sua rede o serviço que implementa a transmissão de voz sobre IP, sendo utilizada a sinalização H.323 [1] do ITU-T (International Telecommunication Union - Telecommunication) para encaminhamento de chamadas interinstitucionais. Dentro do padrão H.323 existem alguns elementos essenciais como o gatekeeper (GK), que recebe chamadas de terminais H.323, e o gateway de voz, que interfaceia o PBX (Private Branch exchange) com a rede. O GK é responsável pela autorização, controle de admissão e estado das chamadas, podendo atuar como proxy de mídia e sinalização. Os terminais H.323 podem ser telefones IP em hardware ou software, sendo que tanto os terminais H.323 como os gateways de voz têm que se registrar num gatekeeper. Estes elementos se comunicam com uso da arquitetura TCP/IP, podendo estar conectados em qualquer ponto de uma rede local ou backbone IP. Um exemplo de topologia é mostrado na Figura 1, onde as instituições conectadas ao POP-RNP1 e pertencentes ao serviço são capazes de encaminhar chamadas VoIP para a rede de telefonia fixa comutada (RTFC) da cidade, via PBX. Uma chamada originada em outra cidade e destinada ao código de área da cidade do POP-RNP1 é roteada até este POP e depois encaminhada a um dos gatekeepers existentes, o qual irá repassá-la ao gateway, e esse, por sua vez, ao PBX. Gateways com interface E1 ISDN (Integrated Services Digital Network) conectam a troncos digitais do PBX e são capazes de suportar 30 conexões de voz simultâneas, enquanto que a interface FXO (Foreign exchange Office), usada para conexão a um ramal analógico do PBX, possibilita o estabelecimento de apenas uma única chamada telefônica. Cidade atendida pelo POP-RNP 1 RTFC PBX PBX PBX 2xFXO Gateway VOIP/PBX E1 ISDN Gateway VOIP/PBX 4xFXO Gateway VOIP/PBX Gatekeeper H.323 Gatekeeper H.323 Gatekeeper H.323 Rede Instituição 1 Rede Instituição 2 Rede Instituição N POP-RNP 3 Roteador POP-RNP 1 Roteador Rede RNP POP-RNP 2 Roteador Figura 1. Interconexão de Instituições do serviço ao POP-RNP

3 Como a quantidade de canais disponíveis nos gateways de voz é limitada, o aumento do número de usuários com a expansão do serviço poderá gerar uma demanda de tráfego muito alta para ser atendida pelos gateways existentes. Quando vários GKs receberem, ao mesmo tempo, um pedido para estabelecimento de chamada com a RTFC, o GK que responder primeiro à solicitação será aquele que receberá a chamada. Esse procedimento simples da sinalização H.323 pode levar a um uso ineficiente dos gateways de voz, repassando as chamadas sempre para uma mesma instituição, provocando o congestionamento de seu gateway, e, como conseqüência, o não completamento da chamada, ainda que existam canais livres para comunicação em outras instituições da mesma cidade. Uma chamada encaminhada para um gateway VoIP/PBX que foi originada em outra instituição será denominada chamada externa; a chamada interna será aquela originada na rede da própria instituição. Caso um gateway esteja com todos os canais ocupados, naquele momento o seu PBX é inalcançável. É importante ressaltar que, quando todos os gateways de uma cidade estiverem saturados, sem canais livres, chamadas externas e internas para a cidade não serão completadas e serão descartadas. Além dessa, outras situações podem contribuir para que uma chamada não seja completada, como a ocorrência de falhas na rede local de pelo menos uma das instituições envolvidas na chamada, problemas com elementos VoIP do serviço ou das instituições envolvidas na chamada, dentre outras. A saturação numa instituição poderá ser contornada com o aumento do número de canais de voz com o PBX, assumindo que a instituição possa absorver o volume de tráfego VoIP pretendido. Todavia, o compartilhamento dos recursos das várias instituições de uma mesma cidade seria uma solução mais adequada. O balanceamento de chamadas tem por objetivo distribuir as chamadas entre os vários gateways, segundo alguma métrica. Com isso, uma diminuição na probabilidade de chamadas não completadas por saturação pode ser alcançada, além de haver a possibilidade de equilíbrio de custos telefônicos, relativos ao entre as instituições. Cabe aqui lembrar que chamadas do serviço são completadas para a rede pública de telefonia de forma opcional pelas instituições, não sendo um requisito mandatório. Pela especificação do serviço o GK deve funcionar tanto em modo proxy de mídia como em modo proxy de sinalização, o que obriga toda a sinalização e a mídia envolvida numa chamada a passar pelo GK, ou seja, clientes envolvidos em uma chamada não podem se comunicar diretamente. Essa configuração do GK atende a requisitos de segurança e implantação de QoS. Dessa forma, uma chamada VoIP entre instituições diferentes primeiro passa pelos seus gatekeepers antes de ir para o gateway. Quando uma instituição opera mais de um gateway com o PBX, o gatekeeper precisa controlar o encaminhamento das chamadas, evitando repassar chamadas para gateways sem canais livres. No serviço o gatekeeper utilizado é o GNU Gatekeeper (GnuGk) 1, e o balanceamento entre gateways pode ser realizado com a versão do Gatekeeper GnuGk, que possui recursos para isso. Mas, para balancear o encaminhamento de chamadas entre os gatekeepers não existe uma solução a priori, e tanto algoritmos centralizados como distribuídos podem ser utilizados. 1 Site oficial do Gatekeeper GnuGk, que foi consultado em dezembro de 2005.

4 No algoritmo centralizado, existe uma entidade central [3] que precisa receber atualizações das métricas a serem utilizadas pelo algoritmo de decisão [3], e ser consultada antes do encaminhamento de uma chamada, o que provoca um atraso adicional para completamento da chamada. As informações precisam ser sincronizadas com freqüência na entidade central [8], evitando erros na tomada de decisão do algoritmo. Com a escalabilidade do serviço VoIP é inevitável que as consultas tendam a crescer [8], provocando um aumento de tráfego na rede [8] em torno deste ponto de decisão e a necessidade de aumento do poder computacional desta entidade para realizar a tomada de decisão em tempo hábil. Nesse tipo de algoritmo, a entidade central é um ponto de falha [3], que pode ter problemas no seu funcionamento ou na comunicação com a rede. Além disso, o atraso para a tomada de decisão pode ser alto, o que é crítico para esta aplicação de tempo real. A complexidade de uma arquitetura centralizada [8] é também um ponto negativo. No algoritmo distribuído cada elemento gerencia os seus próprios recursos [4], baseando-se em informações locais. Quando são utilizadas informações de outros elementos para viabilizar o funcionamento do algoritmo, ele é classificado como global [3]. Neste tipo de algoritmo não existe um elemento central a ser consultado, e o ponto de falha local é eliminado. Um ponto que deve ser levado em consideração é a escalabilidade do algoritmo distribuído [3, 4], importante em serviços onde a sua utilização é crescente. Levando em consideração o que foi exposto, a implementação de um algoritmo distribuído, que considere as limitações e versatilidades dos elementos da arquitetura H.323 no serviço parece ser uma decisão conveniente. Neste artigo, uma proposta de algoritmo distribuído de balanceamento de chamadas para o cenário do serviço é apresentada. O algoritmo se aplica a qualquer situação onde a aceitação de chamadas depende do retorno de mensagens enviadas de um ponto central, como com DGK (Directory GK), em H.323. Situação semelhante também ocorre com a sinalização SIP (Session Initiation Protocol) [9], quando há múltiplos pedidos de estabelecimento de chamadas ( fork ) a partir de um servidor Proxy. Portanto, o algoritmo não fica restrito à topologia do serviço O artigo está divido em 5 seções. Na seção 2, são apresentados aspectos básicos sobre VoIP, necessários para o entendimento da proposta. Na seção 3, o algoritmo proposto neste artigo é explicado, e os resultados de simulação são mostrados na seção 4. Finalmente, são apresentadas as conclusões e trabalhos futuros na seção Aspectos básicos sobre VoIP Nesta seção são apresentados aspectos básicos sobre VoIP que são importantes para o entendimento do funcionamento do serviço e do algoritmo proposto. No ambiente H.323, o servidor gatekeeper realiza a tarefa de autenticação dos clientes H.323 utilizando um nome de usuário e uma senha. Um cliente registrado recebe um identificador numérico único num determinado código de área, que é chamado de número E.164. No serviço os quatro primeiros números identificam uma instituição e os quatro seguintes identificam um usuário. Um usuário pode ser alcançado discando 0 <código de área> <número E.164>.

5 Toda entidade H.323 registrada em um gatekeeper pertence a sua zona administrativa. Dessa forma, o gateway VoIP/PBX também precisa estar registrado para fazer parte da zona administrativa, e o gatekeeper permite que o gateway possa receber chamadas com destino ao PBX ou à RTFC, através dele. Quando um cliente H.323 deseja realizar uma chamada, ocorre uma sinalização entre ele e o seu gatekeeper, onde primeiro é enviada uma mensagem chamada ARQ (Admission Request), que solicita a admissão da chamada, informando o número E.164 de destino da chamada. O gatekeeper poderá retornar uma confirmação da chamada, através de um ACF (Admission Confirm), ou um ARJ (Admission Reject), rejeitando a chamada. Caso o número E.164 de destino não esteja registrado no GK, uma lista de vizinhos é consultada, permitindo o repasse do ARQ, e para isso é utilizada a primitiva de sinalização LRQ (Location Request). A sinalização envolvida no processo de consulta a GKs vizinhos, é exemplificada na Figura 2. Nessa figura, o Terminal A, chamador, é quem irá iniciar uma solicitação de chamada; o Terminal B, chamado, irá receber o pedido. Além disso, como é mostrado na Figura 2 os gatekeepers envolvidos estão em modo proxy de sinalização, pois os Terminais A e B não enviam sinalizações entre si diretamente. Na explicação que se segue, os números entre parênteses referem-se às mensagens de sinalização identificadas na Figura 2. Quando uma chamada é solicitada através da ARQ (1), o gatekeeper (GK Routed A) irá verificar se o usuário de destino está registrado nele, e, caso não esteja, consultará os seus vizinhos. No cenário na Figura 2 existe apenas um vizinho contatado, que é o DGK. Figura 2. Processo de localização utilizando o DGK A consulta de vizinhos no serviço é realizada enviando um pedido de localização LRQ (Location Request) (2) para o DGK da RNP. No pedido de localização o LRQ possui o número E.164 do terminal chamado e o endereço do gatekeeper que originou a solicitação da chamada. O DGK irá localizar o GK que atende o número E.164 de destino em sua configuração interna, e, nessa busca, são

6 utilizados o código de área e o prefixo E.164 do telefone IP. Caso o DGK não localize pelo menos um GK que atenda o prefixo E.164, será retornada uma mensagem de rejeição da chamada, LRJ (Location Reject) (3 ), para o GK que originou o pedido de localização enviado ao DGK. Uma vez que um ou mais GKs de destino tenham sido localizados, uma mensagem LRQ (3) será repassada para eles, e o próximo passo será cada servidor contatado pelo segundo LRQ (no exemplo, o GK Routed B) enviar um LCF (Location Confirm) (4), permitindo ao GK originador iniciar o estabelecimento da chamada através do envio de uma mensagem SETUP (6, 7 e 8). Quando um LRQ ao DGK não tem sucesso, a seqüência de mensagens na Figura 2 é ARQ (1), LRQ (2), LRJ (3 ) e ARJ (4 ). A seqüência ARQ (1), LRQ (2), LRQ (3) e LCF (4) representa um LRQ ao DGK com sucesso. O recebimento do SETUP (8) pelo terminal B provoca um pedido de admissão ARQ (9) ao GK de sua zona administrativa. Assim como a mensagem ACF (5) informa ao cliente chamador (Terminal A) que a chamada foi admitida, a mensagem ACF (10) confirma a admissão ao cliente Terminal B. Todos os GKs que respondem com LCF são denominados vizinhos daquele que fez a solicitação ao DGK. Na Figura 2, o GK Routed B é um dos vizinhos do GK Routed A. No serviço um gateway VoIP/PBX que pertencesse à zona administrativa B, Figura 2, estaria registrado no gatekeeper GK Routed B. Caso o gateway fosse o destino da chamada, ele se comportaria como o Terminal B, ou seja, a chamada seria encaminhada para o gateway através do gatekeeper GK Routed B. Se a instituição zona administrativa B tivesse mais de um gateway, o seu gatekeeper poderia fazer o balanceamento entre esses gateways, utilizando recursos disponíveis no gatekeeper GnuGK versão , que foi citado na seção 1. Assim, é possível sempre considerar uma zona administrativa (ou instituição) como tendo apenas um gateway VoIP/PBX, que possui a soma das capacidades de canais dos gateways dessa zona administrativa. Quando existem múltiplos GKs em uma região com capacidade de encaminhar chamadas a um mesmo prefixo E.164 da RTFC, o LCF que chegar primeiro ao GK chamador indicará para qual GK a chamada será encaminhada. Assim, esse GK intermediará a chamada que será encaminhada para o seu gateway VoIP/PBX, que a aceitará se possuir canais de voz disponíveis, caso contrário a chamada será perdida. Qualquer LCF que chegue ao iniciador da chamada após o primeiro não será considerado, ou seja, GKs que tiverem os seus LCFs desconsiderados não irão receber o SETUP (7), que é enviado apenas para o GK que enviou o primeiro LCF (4) recebido pelo GK chamador. O controle do atraso para envio do LCF poderá determinar quem terá maiores chances de receber a chamada. Assim, um gatekeeper pode provocar um atraso adicional no envio do LCF, quando for desejável que ele não receba a chamada. 3. O Algoritmo de Balanceamento Para evitar que o gatekeeper mais próximo (em termos de atraso) do POP sempre receba as chamadas destinadas à cidade, um algoritmo de balanceamento é necessário. Encaminhar as chamadas sempre para uma mesma instituição não é desejável, porque o seu gateway ficaria mais sobrecarregado, do ponto de vista de ocupação de canais, além de onerar o custo telefônico de chamadas locais da instituição. Um algoritmo de

7 balanceamento que nos traga alternativa de encaminhamento é fundamental. O da Figura 1 é aquele em que o algoritmo irá atuar. cenário O DGK, como mostrado na Figura 2, é utilizado para localizar os GKs de instituições que podem encaminhar chamadas com um determinado prefixo E.164 destino. No uma zona administrativa pode ter vários GKs para encaminhamento de chamadas à telefonia pública da cidade, e, nessa situação, cada GK será informado da tentativa de uma chamada pela primitiva LRQ, que possui informações como o número E.164 destino e o endereço do GK originador da chamada. Cada gatekeeper que receber este LRQ e que tiver gateways com canais disponíveis com PBX responderá com um LCF, que confirmará sua disponibilidade de receber a chamada. Todavia, a chamada será encaminhada para o GK do primeiro LCF que chegar. Os outros LCFs não serão considerados, e inclusive os seus gatekeepers não serão informados que a chamada foi enviada para outro. Mesmo que houvesse uma falha, que impedisse o início da chamada, um outro GK não seria contatado, e a tentativa de estabelecimento dessa chamada não ocorreria, sendo a chamada descartada. O gatekeeper que irá receber a chamada é determinado pelo atraso sofrido pelo LCF, e essa premissa será utilizada pelo algoritmo, a fim de influenciar qual gatekeeper irá receber a chamada destinada à RTFC. A idéia principal do algoritmo é trabalhar com atrasos no envio do LCF, de modo a permitir que ocorra uma distribuição balanceada das chamadas entre os gatekeepers que completam chamadas para uma mesma cidade. Na Figura 3 é mostrado um diagrama da sinalização envolvendo dois gatekeepers que podem encaminhar chamadas para a RTFC, porém relembrando que isso é realizado através dos seus gateways VoIP/PBX. A Figura 3 mostra qual percurso influenciaria no atraso dos LCFs. Entre o PBX chamador e o POP RNP 1, onde estão os gatekeepers que podem encaminhar a chamada, não existe diferença no percurso da sinalização, mas o tempo de ida e volta (RTT ou Round Trip Time) entre o POP-RNP e os GKs B e C são diferentes. Esta diferença de tempo é básica para o algoritmo, pois é determinante de quem terá sucesso em ter seu LCF chegando primeiro. Figura 3. Percursos envolvidos na localização dos gatekeepers Para balancear as chamadas bastará adicionar atrasos no envio do LCF. O atraso adicional deverá ser função de uma métrica que leve em conta a quantidade de canais de

8 voz livres e o número de chamadas externas já sendo atendidas pela instituição. Quando a quantidade de canais livres diminui, o GK deve atrasar um pouco mais o envio do LCF para diminuir sua probabilidade de ser escolhido para receber a chamada, evitando assim congestionar mais ainda o seu sistema. A ordem de grandeza desses atrasos não pode gerar um atraso para o recebimento do LCF no GK originador da ordem de minutos, pois isso causaria a desistência da chamada por timeout na sinalização H.323. Na Figura 3, caso o LCF do GK B receba um atraso adicional, e chegue no GK A após o LCF do GK C, o GK B não receberá a chamada, que será enviada para o GK C. No algoritmo, o atraso para envio do LCF por um GK i será dependente da utilização U(GK i ), dada por: U X i ( GKi ) = Ui = (1), Ci Yi Esta utilização é a fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas. Na fórmula (1), C i representa capacidade de encaminhar chamadas simultâneas, sendo a soma das capacidades dos gateways conectados ao GK i ; X i é o número de chamadas externas em andamento; e Y i é o número de chamadas internas em andamento. Além disso, o valor de i indica o GK para o qual a utilização está sendo calculada. Temos sempre X i C i Y i. Quando todos os canais de voz estiverem ocupados, C i = Y i + X i, e o gatekeeper não retornará LCF, pois não pode mais receber chamadas. No caso de C i = Y i e X i = 0, quando todas as chamadas em andamento são internas, a utilização ficará indeterminada e será assumido o valor 1. A equação (1) foi escolhida por representar simples e adequadamente o compromisso voluntário de cada instituição de completar chamadas externas, e caso a utilização fosse calculada segundo uma outra fórmula, isso não afetaria o algoritmo em si, mas apenas a prioridade ou ordem de recepção das chamadas num determinado contexto de chamadas internas e externas. Seja um POP com n instituições conectadas, onde GK 1 é o GK mais próximo, e GK n é o mais distante. O POP é o ponto comum de passagem das primitivas de sinalização com os GKs chamados, seja elas provenientes do DGK ou do GK chamador. Sejam: τ i, o atraso unidirecional entre o POP e o GK i ; τ ni = τ n τ i, a diferença de atraso ao POP entre GK n e GK i ; C, a capacidade máxima de canais de voz em um determinado GK; LCF i, o location confirm emitido pelo GK i ; D i (U i ), o atraso para envio do LCF i em função de U i. Quando GK i atinge uma determinada utilização U i = A < 1, o algoritmo forçará GK i a se alinhar com GK n, ou seja, LCF i será atrasado de um valor D i de modo a chegar simultaneamente com LCF n ao POP, iniciando o processo de balanceamento entre o GK i e GK n. Para isso, é preciso ter D i (A) = T i = 2 τ ni, função da topologia. D i (A) será designado por Ti, por simplicidade. O algoritmo calcula D i segundo a fórmula Ti. U i Di ( U i ) = (2), A

9 fazendo com que o atraso varie linearmente com a utilização. Esta dependência linear é suficiente e adequada, como será mostrado na seção 4. Quando a utilização for 1, o atraso sofrido será de T i /A, como indicado no gráfico da Figura 4, que representa a equação (2). Com U i < A, i, GK n certamente não recebe chamadas, pois elas são enviadas a algum GK mais próximo do POP. À medida que as utilizações chegam a A, os GKs se alinham com GK n, e as confirmações de chamadas são enviadas de forma mais demorada, inclusive pelo próprio GK n, que passa a usar também o atraso adicional. O valor de A será o mesmo para todos os GKs, a princípio. Todavia, caso uma instituição resolva utilizar um valor acima deste especificado, ela poderá fazê-lo, mostrando estar propensa a receber uma porcentagem maior de ligações externas. O valor de A não deve ser demasiadamente pequeno a ponto de provocar um valor exagerado de T i /A, que seria o atraso máximo adicional a ser impingido ao LCF. Todavia, como nos cenários reais do serviço a diferença de atraso entre GKs é da ordem de milissegundos, a escolha de A não deverá ser crítica. Empiricamente, espera-se que A seja escolhido entre 20% e 50%. Figura 4. Gráfico de Atraso D i x Utilização U i A Figura 5 apresenta três GK i s com atrasos bem variados ao POP, e ela será usada para explicar a operação do algoritmo. Os GK i s têm capacidade de 4 canais de voz, sendo inicialmente o número de chamadas externas e internas iguais a zero, sem atraso para envio dos LCFs. Neste exemplo, será assumido A = 50%. Figura 5. Topologia exemplo Quando se tentar estabelecer a primeira chamada, o DGK enviará um LRQ para cada um dos três GKs, sendo que o LRQ destinado ao GK 1 chegará primeiro, pois os outros GKs estão mais distantes. LCF 1 chegará primeiro ao GK chamador e, assim, a chamada será encaminhada para GK 1. Após esta primeira chamada, U 1 será de ¼ e o próximo LCF 1 será atrasado de 40 ms, como mostrado no gráfico da Figura 6a. Quando ocorrer uma segunda chamada externa, LCF 2 será enviado primeiro e chegará ao POP-RNP antes que os outros, fazendo com que a chamada seja encaminhada para GK 2 e não para GK 1, como ocorreria na ausência do algoritmo.

10 A utilização do GK 2 que era de zero passará a ser de ¼, e o próximo LCF 2 enviado por esse GK será atrasado de 35 ms. Isso é mostrado no gráfico da Figura 6b. O LRQ de uma terceira chamada externa chegará primeiro no GK 1, que atrasará o envio do LCF em 40 ms. O envio do LCF 2 sofrerá um atraso de 35 ms, que, somado aos 5 ms do seu percurso totalizará 40 ms. Isso fará com que o LCF 2 seja enviado ao mesmo tempo do LCF 1, porém, como GK 1 está mais próximo do POP, LCF 1 chegará 5 ms antes no GK chamador, fazendo com que o GK 1 receba sua segunda chamada. Com essa segunda chamada externa a utilização do GK 1 pela fórmula (1) será de ½, e assim o envio do próximo LCF 1 será atrasado de 80 ms, conforme mostrado na Figura 7a. Atraso Atraso Figura 6. Utilização após a primeira e segunda chamadas externas O LRQ de uma quarta chamada externa chegará antes no GK 1 e o envio do seu LCF será atrasado 80 ms. Quando o GK 2 receber o LRQ desta quarta chamada, 5 ms depois de GK 1, o envio do seu LCF será atrasado de apenas 35 ms e chegará ao GK originador com 35 ms de folga em relação aos LCFs de GK 1 e de GK 3. Apesar de LCF 3 ser enviado ao mesmo tempo que LCF 2, ele está 35 ms mais distante em relação a GK 2. Assim, esta quarta chamada será enviada para o GK 2, cuja utilização passará a ser de ½, com um atraso para envio do próximo LCF de 70 ms, como mostrado na Figura 7b. Atraso Atraso Figura 7. Utilização para as próximas chamadas externas Quando a quinta chamada chegar, o LCF do GK 1 será atrasado de 80 ms, o LCF do GK 2 será atrasado de 70 ms e o LCF de GK 3 será gerado de imediato. O LCF dos três GKs passarão pelo POP-RNP ao mesmo tempo e chegarão aproximadamente ao mesmo tempo no GK chamador. Um deles chegará primeiro. Se GK 1 receber a chamada, ele passa a ter uma utilização de ¾, e o atraso para envio do LCF será de 120 ms. No caso de GK 2 receber a chamada, o atraso será de 105 ms. Será arbitrado que o GK 1 receba essa chamada. Assim, quando um sexto LRQ for enviado, os GKs 2 e 3 enviarão os seus LCFs, que chegarão juntos no GK chamador,

11 com 40 ms de folga sobre o LCF do GK 1. Para esta sexta chamada é arbitrado, nesse exemplo, que o GK 2 receberá a chamada, e assim o seu atraso para envio do LCF será de 105 ms, como mostrado na Figura 7b. As chamadas seguintes serão encaminhadas para o GK 3, pois os GKs 1 e 2 terão os seus LCFs tão atrasados que eles chegarão depois no GK chamador. Como o GK 3 é o último, ele não tem uma reta de utilização, e, assim, as próximas chamadas externas não são balanceadas com os outros GKs, e seu gateway acabará saturado e as chamadas serão descartadas. Para evitar esta situação, foi concebido um GK virtual, mais distante do POP do que todos os outros, o que permite que o GK real mais distante tenha suas chamadas externas também balanceadas com os outros GKs. Resta obter a restrição no atraso ao POP para este GK virtual, para que o balanceamento ocorra adequadamente Posicionamento do GK Virtual Seja δ rede, a variação máxima de atraso na comunicação entre os GKs e o POP, devido a variações de carga na rede. Seja τ v, o atraso do POP ao GK virtual. Será preciso determinar a restrição no valor de τ v para garantir o balanceamento das chamadas. A situação mais crítica para o balanceamento ocorre quando todos os GKs operam numa certa utilização acima de A, exceto GK 1 e GK n, que estão com um número a menos de chamadas, e não existem chamadas internas estabelecidas, apenas externas. Nestas condições, supõe-se que a chamada mais recente tenha sido encaminhada a GK n. Para que a próxima chamada seja encaminhada para GK 1, é necessário que seja satisfeita a 2( τ v τ1) U1 2( τ v τ n ) U n desigualdade < 2( τ τ ) + (3). O lado esquerdo corresponde A n j A ao atraso para a geração de LCF 1 a partir da chegada do LRQ e o lado direito indica quando LCF n aconteceria na posição de GK 1. Se o LCF n acontece depois, então a chamada será encaminhada para GK 1, como desejado. Observando que U = n U1 + 1 / C, obtém-se, após simplificar, ( τ v τ n ) > C( U1 A) τ n1 (4). Fazendo U 1 A = 1, pode-se obter um limite inferior para τ v dado por τ v τ n + Cτ + δ (5). n1 rede Usando esta condição no posicionamento do GK virtual, o atraso máximo adicional que um LCF pode sofrer é dado por ( C + 1) τ n1 + δ rede Atraso adicional máximo = (6). A Para um exemplo numérico, usando C=30, A = 0,40, τ n1 = δ rede = 5ms, obtém-se um atraso adicional de 400 ms. Convém salientar que essa situação só irá ocorrer quando todos os GKs estiverem na saturação, o que não será freqüente numa rede com boa engenharia de tráfego Determinação dos Atrasos ao POP Inicialmente cada gatekeeper de uma região terá que conhecer o atraso do percurso de cada GK da sua região até o POP-RNP, e para a viabilização do algoritmo foram estudadas algumas possíveis alternativas. A primeira forma é utilizar um medidor no DGK, que realizaria as medidas de atraso aos GKs utilizando PING, e, num segundo passo, enviaria para os GKs as medidas obtidas em campos de extensão do usuário nas

12 mensagens de LRQ. A vantagem deste procedimento é que o DGK tem conhecimento completo dos IPs e prefixos de todos os GKs, além de processar as mensagens LRQ, tornando simples a implementação desta solução. A desvantagem é que o DGK pode estar muito distante do POP correspondente, e as medidas podem ter uma ordem de grandeza bem maior que a diferença entre os atrasos dos GKs, induzindo a erro, se a variância de atraso na rede for grande. A segunda forma é utilizar um medidor nos POPs, que poderia obter o endereço IP e prefixos dos gatekeepers de uma região no DGK, e realizar as medidas utilizando PING, e, num segundo passo, enviar para os GKs as medidas obtidas. A vantagem desta solução seria a maior precisão na medida do atraso do POP aos GKs. A desvantagem é que o repasse das informações teria que ser feito fora da sinalização H.323, possivelmente usando a porta de gerência do gatekeeper e/ou aplicação rodando no GK, o que tem implicações de segurança para acesso privilegiado. Uma terceira forma seria tentar realizar as medidas a partir de cada GK i. Inicialmente a relação dos GK i da região é obtida do DGK. A partir desse momento, cada GK i de uma região utilizaria o PING para medir o seu atraso até os outros GK i da sua região. Estas medidas deveriam ser obtidas nos vários GKs em um mesmo intervalo de tempo, para evitar erros grosseiros, o que é uma desvantagem e um complicador. A quarta forma envolve a própria sinalização LRQ entre o DGK e o gatekeeper que pretende iniciar uma chamada destinada à RTFC. Assim que um GK i enviar um pedido de localização para o DGK, uma mensagem chamada RIP (Request in Progress) seria enviada do DGK para o gatekeeper que enviou o LRQ. Dessa forma, esse GK i conhecerá o RTT entre ele e o DGK. Esse RTT será subtraído do tempo que o LCF de cada um dos outros GK i levar para chegar, obtendo assim o tempo de ida e volta de cada GK i até o POP. Esse procedimento seria falho se houver rotas fortemente assimétricas no backbone, mas isso não é o caso hoje em dia. 4. Cenários simulados Nesta seção, são apresentados os cenários utilizados nas simulações no MatLab e os gráficos dos resultados. Os gráficos apresentam a variação da métrica de utilização definida na equação (1) ao longo do tempo, para os vários GKs. O primeiro cenário simulado, mostrado na Figura 8, apresenta três GKs numa mesma cidade (prefixo=10), e igualmente distanciados do POP-RNP de 100 ms. Figura 8. Cenário da primeira simulação

13 Os gatekeepers GK 1 e GK 2 têm capacidade de 4 canais de voz, enquanto GK 3 tem capacidade de 8. Na simulação são disparadas 15 chamadas, com um tráfego de fundo de uma chamada interna nos gateways dos GKs 1 e 2, e não existirá chamadas internas no GK 3. Para esse cenário o valor estipulado de A, a taxa de utilização para alinhamento dos GKs será de 0,25. O objetivo é verificar o equilíbrio no encaminhamento de chamadas, quando os GKs têm a mesma capacidade, e estão igualmente distantes do POP. Na simulação do cenário da Figura 8, todos os canais de voz dos gateways foram ocupados com chamadas, e a situação de chamadas não completadas por saturação de um gateway é evitada. A Figura 9 mostra a evolução da métrica de utilização em cada GK após o estabelecimento das chamadas. Figura 9. Resultado da primeira simulação Na Figura 9, é mostrado que as métricas dos três GKs tendem a se aproximar e, na última chamada, as utilizações convergem para 1, como esperado. A atuação do algoritmo para forçar o equilíbrio pode ser observada através da oscilação dos valores de utilização, mas que tendem sempre a convergir em torno da diagonal do gráfico, mostrando assim o balanceamento. Figura 10. Cenário da segunda simulação

14 No segundo cenário, mostrado na Figura 10, GK 3 está afastado de 200 ms do POP, e os GKs 1 e 2 continuaram afastados do POP de 100 ms. Na simulação continuam a ser disparadas 15 chamadas, com um tráfego de fundo de uma chamada interna nos gateways dos GKs 1 e 2, e não existirão chamadas internas no GK 3, como no exemplo anterior. Além disso, o valor de A será mantido em 0,25. Nesse cenário, as utilizações dos canais de voz tendem a ficar iguais, ou seja, o mesmo comportamento do cenário anterior é observado. Porém, o GK 3 demora um pouco mais a se alinhar com os outros, pois ele possui mais canais de voz. Figura 11. Resultado da segunda simulação O próximo cenário é mostrado na Figura 12, e ele apresenta três GKs, agora com distâncias diferentes em relação ao POP-RNP. A capacidade de cada um é diferente, assim o resultado poderá mostrar o comportamento do algoritmo quando a capacidade e distâncias do POP são diferentes, o que seria uma realidade no serviço pois as instituições necessariamente não possuem uma disponibilidade de recursos homogênea. Para este cenário a taxa de utilização para alinhamento foi modificada para 0,20, forçando os GKs a atingirem o equilíbrio com uma quantidade menor de chamadas. O tráfego de fundo foi de uma chamada interna para o GK 1, duas chamadas internas para o GK 2 e três chamadas internas para o GK 3. Figura 12. Cenário da terceira simulação

15 A Figura 13 mostra o resultado da terceira simulação, onde foram disparadas 21 chamadas. Nota-se que para esse cenário ocorre o balanceamento das chamadas, assim como aconteceu nas simulações anteriores. Figura 13. Resultado da terceira simulação Como o GK 1 possui uma quantidade menor de canais de voz ele fica muito tempo sem receber chamadas, e isso é observado na Figura 14 porque a sua utilização se mantém constante durante várias chamadas. Para avaliar a situação em que chamadas são terminadas, assuma na Figura 13 que os GKs estão em equilíbrio, com 15 chamadas externas em andamento. No caso de várias chamadas serem repentinamente terminadas em um GK, a utilização desse GK diminuiria, e, pelo algoritmo implementado, o atraso para envio do LCF desse GK voltaria a um estado anterior, aumentando sua prioridade de receber chamadas. Esse GK, que teve as suas chamadas terminadas repentinamente, receberia as próximas chamadas, que voltariam a ser balanceadas quando a sua métrica alcançasse o equilíbrio com a de outro GK. Dessa forma, não é necessário acompanhar o término de chamadas e o algoritmo se mostra robusto para diferentes cenários. 5. Conclusão Um algoritmo distribuído para balanceamento de chamadas H.323 destinadas à rede pública de telefonia dentro do cenário do serviço onde várias instituições interconectadas a um POP completam chamadas para uma mesma cidade, foi apresentado. O algoritmo também se aplica a qualquer situação onde a aceitação de chamadas depende do retorno de mensagens enviadas de um ponto central, como com o uso de DGK, em H.323, e em SIP, quando se utiliza o encaminhamento múltiplo para estabelecimento de chamada por servidor proxy. Dessa forma, o algoritmo proposto pode ser aplicado a outras topologias diferentes daquela do serviço

16 A métrica representada pela fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas é utilizada para balanceamento. A partir de um determinado valor da métrica as confirmações de chamadas são atrasadas e o balanceamento é alcançado. O algoritmo usa o artifício de colocação de um GK virtual e a restrição ao posicionamento deste GK, que pode afetar o atraso na admissão das chamadas. Resultados de simulações demonstram a eficácia do algoritmo em diferentes cenários. Nota-se, através da simulação, que a velocidade de convergência dos valores de utilização dos canais de voz dos GKs é influenciada pela capacidade dos gateways VoIP/PBX e pela distância dos GKs até o POP. Todavia, o mecanismo é bastante robusto, pois opera adequadamente frente a localizações variadas dos GKs institucionais e diferentes demandas de tráfegos interno e externo. No momento, visando o uso em produção, procura-se aprimorar o algoritmo para incorporar procedimentos automáticos de reavaliação dos atrasos do POP aos GKs e incorporar otimizações para minorar o efeito do atraso adicional na aceitação das chamadas, principalmente após o alinhamento com o GK mais distante ter acontecido. 6. Bibliografia [1] ITU-T H.323 Telecomunication Standardization Sector of ITU (07/2003), series H: AudioVisual and Multimidia Systems. [2] Zhou, Q., Shirmohammadi, D. e Liu Edwin, W.-H., "Distribution Feeder Reconfiguration For Service Restoration And Load Balancing", IEEE Transactions on Power Systems, Vol. 12, No. 2, May [3] Ghanem, J., Implementation of Load Balancing Policies in Distributed Systems, The University of New Mexico, New Mexico, tese de mestrado. June, Site consultado em fevereiro de [4] Floyd, S. e Jacobson V., Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on networking. vol I. N O 1. August [5] Riedl, R. e Richter, L., Classification of Load Distribution Algorithms, Department of Computer Science University of Zurich, Zurich, Switzerland, 1996 IEEE. [6] Harchol-Balter, M. e Downey, A., Exploiting Process Lifetime Distributions for Dynamic Load Balancing, University of California, Berkeley, ACM Transactions on Computer Systems, August 1997, Pages [7] Zhang, L., "Scheduling Algorithm for Real-Time Application in Grid Environment", Departmenrt of Computer Science and Technology, Guangdong, Chine. IEEE SMC, [8] Rhee, W.-S., Lee, J.-H., Yu, J.-H. e Kim, S.-H., "Scalable Quasi-Dynamic-Provisioning-Based Admission Control Mechanism in Differentiated Service Networks", ETRI Journal, Volume 26, Number 1, February [9] IETF RFC 3261, SIP: Session Initiation Protocol, Junho 2002.

Serviço fone@rnp: descrição da arquitetura

Serviço fone@rnp: descrição da arquitetura Serviço fone@rnp: descrição da arquitetura Maio de 2005 Esse documento descreve a arquitetura do serviço fone@rnp. RNP/REF/0343a Versão Final Sumário 1. Arquitetura... 3 1.1. Plano de numeração... 5 1.1.1.

Leia mais

Serviço fone@rnp: descrição geral

Serviço fone@rnp: descrição geral Serviço fone@rnp: descrição geral Este documento descreve o serviço de Voz sobre IP da Rede Nacional de Ensino e Pesquisa. RNP/REF/0347 Versão Final Sumário 1. Apresentação... 3 2. Definições... 3 3. Benefícios

Leia mais

Transmissão de Voz em Redes de Dados (VoIP)

Transmissão de Voz em Redes de Dados (VoIP) Transmissão de Voz em Redes de Dados (VoIP) Telefonia Tradicional PBX Telefonia Pública PBX Rede telefônica tradicional usa canais TDM (Time Division Multiplexing) para transporte da voz Uma conexão de

Leia mais

H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed

H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed UNIVERSIDADE FEDERAL DO PARANÁ H.323: Visual telephone systems and equipment for local area networks which provide a nonguaranteed quality of service Resumo para a disciplina de Processamento Digital de

Leia mais

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H.

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H. Departamento de Engenharia de Telecomunicações - UFF Aplicações Multimídia Distribuídas Aplicações Multimídia Distribuídas Videoconferência Padrão H.323 - ITU Padrão - IETF Profa. Débora Christina Muchaluat

Leia mais

O protocolo H.323 UNIP. Renê Furtado Felix. rffelix70@yahoo.com.br

O protocolo H.323 UNIP. Renê Furtado Felix. rffelix70@yahoo.com.br UNIP rffelix70@yahoo.com.br Este protocolo foi projetado com o intuito de servir redes multimídia locais com suporte a voz, vídeo e dados em redes de comutação em pacotes sem garantias de Qualidade de

Leia mais

Protocolos Sinalização

Protocolos Sinalização Tecnologia em Redes de Computadores Fundamentos de VoIP Professor: André Sobral e-mail: alsobral@gmail.com São protocolos utilizados para estabelecer chamadas e conferências através de redes via IP; Os

Leia mais

WRNP 2009. Proxies e Gateways. Núcleo de Computação Eletrônica/UFRJ

WRNP 2009. Proxies e Gateways. Núcleo de Computação Eletrônica/UFRJ WRNP 2009 Proxies e Gateways Núcleo de Computação Eletrônica/UFRJ Tópicos Proxy Troca de tráfego com outras redes Princípios do Proxy do serviço fone@rnp Configuração para operação com o Proxy Conexões

Leia mais

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM Roteiro Introdução a Redes Convergentes. Camadas de uma rede convergente. Desafios na implementação de redes convergentes. Introdução a Redes Convergentes.

Leia mais

Protocolo OSPF. O p e n S h o r t e s t P at h F i r s t. E s pec i a li s ta

Protocolo OSPF. O p e n S h o r t e s t P at h F i r s t. E s pec i a li s ta Ebook Exclusivo Protocolo OSPF O p e n S h o r t e s t P at h F i r s t E s pec i a li s ta em S e rv i ços G e r e n c i a do s Segurança de de Perímetro Sumário Introdução P.3 Ententendendo o Protocolo

Leia mais

GT-VOIP Avançado. Paulo Aguiar Tel. (0xx21) 2598-3165 e-mail: aguiar@nce.ufrj.br Núcleo de Computação Eletrônica da UFRJ

GT-VOIP Avançado. Paulo Aguiar Tel. (0xx21) 2598-3165 e-mail: aguiar@nce.ufrj.br Núcleo de Computação Eletrônica da UFRJ GT-VOIP Avançado Paulo Aguiar Tel. (0xx21) 2598-3165 e-mail: aguiar@nce.ufrj.br Núcleo de Computação Eletrônica da UFRJ GT-VoIP (maio/02-maio/04) Capacitar instituições para disseminação de VoIP Implantar

Leia mais

Tecnologias Atuais de Redes

Tecnologias Atuais de Redes Tecnologias Atuais de Redes Aula 5 VoIP Tecnologias Atuais de Redes - VoIP 1 Conteúdo Conceitos e Terminologias Estrutura Softswitch Funcionamento Cenários Simplificados de Comunicação em VoIP Telefonia

Leia mais

Arquitetura de Monitoração de Chamadas Telefônicas IP

Arquitetura de Monitoração de Chamadas Telefônicas IP Arquitetura de Monitoração de Chamadas Telefônicas IP NCE - UFRJ Leandro C. G. Lustosa Paulo Henrique de A. Rodrigues Fabio David Douglas G. Quinellato Importância de Estatísticas de Qualidade Monitoramento

Leia mais

Guia Técnico Inatel Guia das Cidades Digitais

Guia Técnico Inatel Guia das Cidades Digitais Guia Técnico Inatel Guia das Cidades Digitais Módulo 3: VoIP INATEL Competence Center treinamento@inatel.br Tel: (35) 3471-9330 As telecomunicações vêm passando por uma grande revolução, resultante do

Leia mais

Implantação de QoS no fone@rnp

Implantação de QoS no fone@rnp III Workshop VoIP Marcel R. Faria & Fábio Okamura Maio 2008 Agenda Introdução Backbone RNP rede Ipê QoS na rede Ipê - Serviço Premium Aplicação no fone@rnp Introdução A fim de atender a crescente demanda

Leia mais

Roteamento e Comutação

Roteamento e Comutação Roteamento e Comutação Uma estação é considerada parte de uma LAN se pertencer fisicamente a ela. O critério de participação é geográfico. Quando precisamos de uma conexão virtual entre duas estações que

Leia mais

Ambiente Atual (GT-VoIP)

Ambiente Atual (GT-VoIP) Ambiente Atual (GT-VoIP) Operação baseada em H.323 Cada instituição possui um GK para implantação de plano de numeração local DGK centralizado armazena os prefixos E.164 de cada uma das instituições GT-VOIP

Leia mais

PNNI. Prof. José Marcos C. Brito

PNNI. Prof. José Marcos C. Brito PNNI Prof. José Marcos C. Brito 1 Introdução O PNNI compreende um protocolo de roteamento e um protocolo de sinalização. O PNNI se aplica na interface entre dois switches ou na interface entre duas redes.

Leia mais

H.323. Laboratório VoIP Núcleo de Computação Eletrônica/UFRJ

H.323. Laboratório VoIP Núcleo de Computação Eletrônica/UFRJ H.323 Laboratório VoIP Núcleo de Computação Eletrônica/UFRJ Histórico de H.323 Início: SG-16 do ITU-T (Maio 1995) H.323 v1, Jun 1996 H.323 v2, Fev 1998 H.323: Packet-based multimedia communication systems

Leia mais

Roteamento em Redes de Computadores

Roteamento em Redes de Computadores Roteamento em Redes de Computadores José Marcos Câmara Brito INATEL - Instituto Nacional de Telecomunicações INATEL - Instituto Nacional de Telecomunicações 01/08/00 1 Introdução Objetivo Tipos de rede

Leia mais

5.2 MAN s (Metropolitan Area Network) Redes Metropolitanas

5.2 MAN s (Metropolitan Area Network) Redes Metropolitanas MÓDULO 5 Tipos de Redes 5.1 LAN s (Local Area Network) Redes Locais As LAN s são pequenas redes, a maioria de uso privado, que interligam nós dentro de pequenas distâncias, variando entre 1 a 30 km. São

Leia mais

Roteamento e Comutação

Roteamento e Comutação Roteamento e Comutação Design de Rede Local Design Hierárquico Este design envolve a divisão da rede em camadas discretas. Cada camada fornece funções específicas que definem sua função dentro da rede

Leia mais

Diretoria de Operações RNP

Diretoria de Operações RNP Alexandre Grojsgold Diretoria de Operações RNP I Workshop POP-RS julho/2005 O que é VoIP? Conversas telefônicas feitas sobre a Internet, sem passar pela rede de telefonia convencional em oposição a...

Leia mais

Módulo 8. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados

Módulo 8. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados Módulo 8 Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados 1 Roteamento IP (Internet Protocol) 2 Roteamento IP 3 Roteamento IP Tarefa executada pelo protocolo

Leia mais

Redes de Computadores I Conceitos Básicos

Redes de Computadores I Conceitos Básicos Redes de Computadores I Conceitos Básicos (11 a. Semana de Aula) Prof. Luís Rodrigo lrodrigo@lncc.br http://lrodrigo.lncc.br 2011.02 v1 2011.11.03 (baseado no material de Jim Kurose e outros) Algoritmos

Leia mais

Serviços Prestados Infovia Brasília

Serviços Prestados Infovia Brasília Serviços Prestados Infovia Brasília Vanildo Pereira de Figueiredo Brasília, outubro de 2009 Agenda I. INFOVIA Serviços de Voz Softphone e Asterisk INFOVIA MINISTÉRIO DO PLANEJAMENTO INFOVIA MINISTÉRIO

Leia mais

Claudivan C. Lopes claudivan@ifpb.edu.br

Claudivan C. Lopes claudivan@ifpb.edu.br Claudivan C. Lopes claudivan@ifpb.edu.br Por que redes de computadores? Tipos de redes Componentes de uma rede IFPB/Patos - Prof. Claudivan 2 Quando o assunto é informática, é impossível não pensar em

Leia mais

Fernando Albuquerque - fernando@cic.unb.br REDES LAN - WAN. Fernando Albuquerque (061) 273-3589 fernando@cic.unb.br

Fernando Albuquerque - fernando@cic.unb.br REDES LAN - WAN. Fernando Albuquerque (061) 273-3589 fernando@cic.unb.br REDES LAN - WAN Fernando Albuquerque (061) 273-3589 fernando@cic.unb.br Tópicos Modelos Protocolos OSI e TCP/IP Tipos de redes Redes locais Redes grande abrangência Redes metropolitanas Componentes Repetidores

Leia mais

VoIP. Redes de Longa Distância Prof. Walter Cunha

VoIP. Redes de Longa Distância Prof. Walter Cunha Redes de Longa Distância Prof. Walter Cunha As principais tecnologias de Voz sobre Rede de dados: Voz sobre Frame Relay Voz sobre ATM Voz sobre IP VoIP sobre MPLS VoIP consiste no uso das redes de dados

Leia mais

Protocolos de roteamento RIP e OSPF

Protocolos de roteamento RIP e OSPF Roberto Néia Amaral et al. 75 Roberto Néia Amaral (Mestre) Curso de Ciência da Computação - Universidade Tuiuti do Paraná Ciro de Barros Barbosa (Doutor) Curso de Ciência da Computação - Universidade Tuiuti

Leia mais

GT-VOIP. Especificação de Compra de Gateways VoIP. Fevereiro de 2003

GT-VOIP. Especificação de Compra de Gateways VoIP. Fevereiro de 2003 GT-VOIP Especificação de Compra de Gateways VoIP Fevereiro de 2003 Este relatório apresenta a especificação de cenários e do hardware necessário para a implantação do piloto VOIP na Rede Nacional de Pesquisa.

Leia mais

Introdução ao protocolo SIP*

Introdução ao protocolo SIP* Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Pode se dizer que SIP trata se de um protocolo de controle referente à camada de aplicações do Modelo de Referência OSI (Open System Interconnection),

Leia mais

Telefonia IP na UFSC Experiências e Perspectivas

Telefonia IP na UFSC Experiências e Perspectivas Telefonia IP na UFSC Experiências e Perspectivas BoF VoIP Experiências de Perspectivas RNP, Rio de Janeiro, 22 Agosto 2011 Edison Melo SeTIC/UFSC PoP-SC/RNP edison.melo@ufsc.br 1 Histórico Serviço VoIP4All

Leia mais

Arquitetura do Protocolo da Internet. Aula 05 - Protocolos de Roteamento. Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu.

Arquitetura do Protocolo da Internet. Aula 05 - Protocolos de Roteamento. Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu. Arquitetura do Protocolo da Internet Aula 05 - Protocolos de Roteamento Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu.br Revisão Roteamento; Gateway; Tabelas de Roteamento; Slide 2 de 82 Rotas?!

Leia mais

Unidade 1. Conceitos Básicos

Unidade 1. Conceitos Básicos Unidade 1 Conceitos Básicos 11 U1 - Conceitos Básicos Comunicação Protocolo Definição de rede Rede Internet 12 Comunicação de dados Comunicação de dados comunicação de informação em estado binário entre

Leia mais

Redes de Computadores II

Redes de Computadores II Redes de Computadores II Prof. Celio Trois portal.redes.ufsm.br/~trois/redes2 Roteamento Dinâmico As principais vantagens do roteamento dinâmico são: Simplifica o gerenciamento da rede. Viável em grandes

Leia mais

ESTUDO DE VIABILIDADE, PROJETO E IMPLANTAÇÃO DE UMA REDE VPN (VIRTUAL PRIVATE NETWORK)

ESTUDO DE VIABILIDADE, PROJETO E IMPLANTAÇÃO DE UMA REDE VPN (VIRTUAL PRIVATE NETWORK) ESTUDO DE VIABILIDADE, PROJETO E IMPLANTAÇÃO DE UMA REDE VPN (VIRTUAL PRIVATE NETWORK) 1. VPN Segundo TANENBAUM (2003), VPNs (Virtual Private Networks) são redes sobrepostas às redes públicas, mas com

Leia mais

O que são DNS, SMTP e SNM

O que são DNS, SMTP e SNM O que são DNS, SMTP e SNM O DNS (Domain Name System) e um esquema de gerenciamento de nomes, hierárquico e distribuído. O DNS define a sintaxe dos nomes usados na Internet, regras para delegação de autoridade

Leia mais

6127. Redes comunicação de dados. RSProf@iol.pt. 2014/2015. Introdução.

6127. Redes comunicação de dados. RSProf@iol.pt. 2014/2015. Introdução. Sumário 6127. Redes comunicação de dados. 6127. Redes comunicação de dados A Internet: Permite a interação entre pessoas. 6127. Redes comunicação de dados A Internet: Ensino; Trabalho colaborativo; Manutenção

Leia mais

2 Controle de Congestionamento do TCP

2 Controle de Congestionamento do TCP 2 Controle de Congestionamento do TCP 17 2 Controle de Congestionamento do TCP A principal causa de descarte de pacotes na rede é o congestionamento. Um estudo detalhado dos mecanismos de controle de congestionamento

Leia mais

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos Videoconferência: H.323 versus SIP Este tutorial apresenta uma avaliação técnica e as tendências que envolvem os serviços providos pela pilha de protocolos do padrão H.323, especificados pelo ITU-T, e

Leia mais

VoIP Peering. Operação, Tecnologia e Modelos de Negócio

VoIP Peering. Operação, Tecnologia e Modelos de Negócio VoIP Peering Operação, Tecnologia e Modelos de Negócio Histórico 2005 2004 2004 2003 2002 2001 2000 1999 1998 1996 1995 1993 Plataformas de Suporte ao Cliente Final Suporte ao protocolo SIP POP em Miami

Leia mais

Arquitetura de Rede de Computadores

Arquitetura de Rede de Computadores TCP/IP Roteamento Arquitetura de Rede de Prof. Pedro Neto Aracaju Sergipe - 2011 Ementa da Disciplina 4. Roteamento i. Máscara de Rede ii. Sub-Redes iii. Números Binários e Máscara de Sub-Rede iv. O Roteador

Leia mais

Este tutorial apresenta conceitos e recomendações para o planejamento de uma rede multi-serviço.

Este tutorial apresenta conceitos e recomendações para o planejamento de uma rede multi-serviço. O que se deve considerar no planejamento de uma rede multi-serviço? Este tutorial apresenta conceitos e recomendações para o planejamento de uma rede multi-serviço. Jorge Moreira de Souza Doutor em Informática

Leia mais

Redes de Computadores

Redes de Computadores Departamento de Informática UFPE Redes de Computadores Nível de Redes - Exemplos jamel@cin.ufpe.br Nível de Rede na Internet - Datagramas IP Não orientado a conexão, roteamento melhor esforço Não confiável,

Leia mais

Universidade Federal do Acre. Centro de Ciências Exatas e Tecnológicas

Universidade Federal do Acre. Centro de Ciências Exatas e Tecnológicas Universidade Federal do Acre Centro de Ciências Exatas e Tecnológicas Universidade Federal do Acre Centro de Ciências Exatas e Tecnológicas Pós-graduação Lato Sensu em Desenvolvimento de Software e Infraestrutura

Leia mais

UniFOA - Curso Seqüencial de Redes de Computadores Disciplina: Sistemas de Telecomunicações 4º período Professor: Maurício AULA 02 Telefonia Fixa

UniFOA - Curso Seqüencial de Redes de Computadores Disciplina: Sistemas de Telecomunicações 4º período Professor: Maurício AULA 02 Telefonia Fixa Introdução UniFOA - Curso Seqüencial de Redes de Computadores Com o aparecimento dos sistemas de comunicação móvel como a telefonia celular, o termo telefonia fixa passou a ser utilizado para caracterizar

Leia mais

A Camada de Rede. A Camada de Rede

A Camada de Rede. A Camada de Rede Revisão Parte 5 2011 Modelo de Referência TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace de Dados Camada de Física Funções Principais 1. Prestar serviços à Camada de Transporte.

Leia mais

APOSTILA DE REDES DE COMPUTADORES PARTE - III

APOSTILA DE REDES DE COMPUTADORES PARTE - III APOSTILA DE REDES DE COMPUTADORES PARTE - III 1 REDE DE COMPUTADORES III 1. Introdução MODELO OSI ISO (International Organization for Standardization) foi uma das primeiras organizações a definir formalmente

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Roteamento www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Roteamento Roteamento é a técnica que define por meio de um conjunto de regras como os dados originados em

Leia mais

MPLS MultiProtocol Label Switching

MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching Cenário Atual As novas aplicações que necessitam de recurso da rede são cada vez mais comuns Transmissão de TV na Internet Videoconferências Jogos on-line A popularização

Leia mais

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Se você tem mais que um computador ou outros dispositivos de hardware, como impressoras, scanners ou câmeras, pode usar uma rede para compartilhar

Leia mais

ARP. Tabela ARP construída automaticamente. Contém endereço IP, endereço MAC e TTL

ARP. Tabela ARP construída automaticamente. Contém endereço IP, endereço MAC e TTL ARP Protocolo de resolução de endereços (Address Resolution Protocol) Descrito na RFC 826 Faz a tradução de endereços IP para endereços MAC da maioria das redes IEEE 802 Executado dentro da sub-rede Cada

Leia mais

3 Qualidade de serviço na Internet

3 Qualidade de serviço na Internet 3 Qualidade de serviço na Internet 25 3 Qualidade de serviço na Internet Além do aumento do tráfego gerado nos ambientes corporativos e na Internet, está havendo uma mudança nas características das aplicações

Leia mais

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP.

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP. Exercícios: Redes WAN Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é

Leia mais

24/03/2015. Prof. Marcel Santos Silva

24/03/2015. Prof. Marcel Santos Silva Prof. Marcel Santos Silva Embora os roteadores possam ser usados para segmentar os dispositivos de LAN, seu principal uso é como dispositivos de WAN. Os roteadores têm interfaces de LAN e WAN. As tecnologias

Leia mais

MODULO SERVIDOR DE GERENCIAMENTO DE CHAVES DE ENCRIPTAÇÃO AÉREA OTAR P25, FASE 2

MODULO SERVIDOR DE GERENCIAMENTO DE CHAVES DE ENCRIPTAÇÃO AÉREA OTAR P25, FASE 2 MODULO SERVIDOR DE GERENCIAMENTO DE CHAVES DE ENCRIPTAÇÃO AÉREA OTAR P25, FASE 2 Servidor de Gerenciamento de Chaves de Encriptação Aérea (Criptofonia) OTAR (Over The Air Rekeying), para emprego na rede

Leia mais

CONCEITOS BÁSICOS DE REDES 2 [COMUTAÇÕES / TAXONOMIA]

CONCEITOS BÁSICOS DE REDES 2 [COMUTAÇÕES / TAXONOMIA] CONCEITOS BÁSICOS DE REDES 2 [COMUTAÇÕES / TAXONOMIA] UC: Redes Docente: Prof. André Moraes Curso técnico em Informática Instituto Federal de Santa Catarina Créditos I Instituto Federal de Santa Catarina

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br CENTRO UNIVERSITÁRIO DE VOLTA REDONDA UniFOA Curso Tecnológico de Redes de Computadores Disciplina: Redes Convergentes II Professor: José Maurício S. Pinheiro

Leia mais

Fornecer serviços independentes da tecnologia da subrede; Esconder do nível de transporte o número, tipo e a topologia das subredes existentes;

Fornecer serviços independentes da tecnologia da subrede; Esconder do nível de transporte o número, tipo e a topologia das subredes existentes; 2.3 A CAMADA DE REDE! Fornece serviços para o nível de transporte, sendo, freqüentemente, a interface entre a rede do cliente e a empresa de transporte de dados (p.ex. Embratel).! Sua principal função

Leia mais

Pedido de Esclarecimento 01 PE 12/2011

Pedido de Esclarecimento 01 PE 12/2011 Pedido de Esclarecimento 01 PE 12/2011 Questionamento 1 : 20.1.1.2 - Sistema de telefonia IP ITEM 04 - Deve ser capaz de se integrar e gerenciar os gateways para localidade remota tipo 1, 2 e 3 e a central

Leia mais

Introdução à voz sobre IP e Asterisk

Introdução à voz sobre IP e Asterisk Introdução à voz sobre IP e Asterisk José Alexandre Ferreira jaf@saude.al.gov.br Coordenador Setorial de Gestão da Informática CSGI Secretaria do Estado da Saúde SES/AL (82) 3315.1101 / 1128 / 4122 Sumário

Leia mais

Rede de Computadores II

Rede de Computadores II Slide 1 Técnicas para se alcançar boa qualidade de serviço Reserva de recursos A capacidade de regular a forma do tráfego oferecido é um bom início para garantir a qualidade de serviço. Mas Dispersar os

Leia mais

INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO

INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO INSTITUTO SUPERIOR DE TEOLOGIA APLICADA CURSO DE PÓS-GRADUAÇÃO EM REDES E SEGURANÇA DE SISTEMAS TELEFONIA IP E VOIP RESUMO Artigo Científico Curso de Pós-Graduação em Redes e Segurança de Sistemas Instituto

Leia mais

Packet Tracer 4.0: Overview Session. Conceitos e práticas

Packet Tracer 4.0: Overview Session. Conceitos e práticas Packet Tracer 4.0: Overview Session Conceitos e práticas Processo de Flooding ou Inundação envia informações por todas as portas, exceto aquela em que as informações foram recebidas; Cada roteador link-state

Leia mais

unesp UNIVERSIDADE ESTADUAL PAULISTA

unesp UNIVERSIDADE ESTADUAL PAULISTA unesp UNIVERSIDADE ESTADUAL PAULISTA Administração de Redes TCP/IP Roteamento: Sistemas Autônomos e EGP Prof. Dr. Adriano Mauro Cansian adriano@ieee.org UNESP - IBILCE - São José do Rio Preto 2001 1. Introdução

Leia mais

Introdução. Disciplina: Suporte Remoto Prof. Etelvira Leite

Introdução. Disciplina: Suporte Remoto Prof. Etelvira Leite Introdução Disciplina: Suporte Remoto Prof. Etelvira Leite Os Benefícios do Trabalho Remoto O mundo assiste hoje à integração e à implementação de novos meios que permitem uma maior rapidez e eficácia

Leia mais

Aula 20. Roteamento em Redes de Dados. Eytan Modiano MIT

Aula 20. Roteamento em Redes de Dados. Eytan Modiano MIT Aula 20 Roteamento em Redes de Dados Eytan Modiano MIT 1 Roteamento Deve escolher rotas para vários pares origem, destino (pares O/D) ou para várias sessões. Roteamento datagrama: a rota é escolhida para

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes (Continuação) 2 Camada de Rede 3 NAT: Network Address Translation restante da Internet 138.76.29.7 10.0.0.4 rede local (ex.: rede doméstica) 10.0.0/24

Leia mais

:: Telefonia pela Internet

:: Telefonia pela Internet :: Telefonia pela Internet http://www.projetoderedes.com.br/artigos/artigo_telefonia_pela_internet.php José Mauricio Santos Pinheiro em 13/03/2005 O uso da internet para comunicações de voz vem crescendo

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Switch na Camada 2: Comutação www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução A conexão entre duas portas de entrada e saída, bem como a transferência de

Leia mais

Tabela de roteamento

Tabela de roteamento Existem duas atividades que são básicas a um roteador. São elas: A determinação das melhores rotas Determinar a melhor rota é definir por qual enlace uma determinada mensagem deve ser enviada para chegar

Leia mais

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.)

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Tópicos Gerencia de Rede Motivação da Gerência Desafios Principais Organismos Padronizadores Modelo Amplamente Adotado As Gerências

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Tanenbaum Redes de Computadores Cap. 1 e 2 5ª. Edição Pearson Padronização de sistemas abertos à comunicação Modelo de Referência para Interconexão de Sistemas Abertos RM OSI Uma

Leia mais

Servidor de Gerenciamento de Chaves de Encriptação Aérea OTAR

Servidor de Gerenciamento de Chaves de Encriptação Aérea OTAR Servidor de Gerenciamento de Chaves de Encriptação Aérea OTAR P25 Fase 1 Requisitos Gerais Servidor de Gerenciamento de Chaves de Encriptação (Criptofonia) OTAR (Over The Air Rekeying), para emprego na

Leia mais

Aplicações P2P. André Lucio e Gabriel Argolo

Aplicações P2P. André Lucio e Gabriel Argolo Aplicações P2P André Lucio e Gabriel Argolo Tópicos Internet Peer-to-Peer (Introdução) Modelos (Classificação) Napster Gnutella DHT KaZaA Razões para o Sucesso da Internet Capacidade de interligar várias

Leia mais

ANEXO 5 PLANEJAMENTO TÉCNICO INTEGRADO E PROVIMENTO DA INTERCONEXÃO

ANEXO 5 PLANEJAMENTO TÉCNICO INTEGRADO E PROVIMENTO DA INTERCONEXÃO ANEXO 5 PLANEJAMENTO TÉCNICO INTEGRADO E PROVIMENTO DA INTERCONEXÃO 1. OBJETIVO 1.1 As Interconexões previstas no presente Anexo 5 serão objeto de planejamento técnico contínuo e integrado entre as Partes,

Leia mais

Introdução à Computação Móvel IP Móvel. Movimentação de Host. Movimentação de Host. Francisco José da Silva e Silva

Introdução à Computação Móvel IP Móvel. Movimentação de Host. Movimentação de Host. Francisco José da Silva e Silva Introdução à Computação Móvel IP Móvel Francisco José da Silva e Silva Francisco Silva 1 Movimentação de Host Francisco Silva 2 Movimentação de Host Se um host não estiver no enlace identificado por seu

Leia mais

Abra o software de programação. Clique na opção VOIP, depois opção configuração conforme as imagens:

Abra o software de programação. Clique na opção VOIP, depois opção configuração conforme as imagens: Caro cliente, atendendo a sua solicitação de auxílio no processo de configuração da placa VoIP na central Impacta, segue um passo-a-passo para ajudar a visualização. Abra o software de programação. Clique

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Contribuição acadêmica

Contribuição acadêmica Contribuição acadêmica Origem deste trabalho em cadeiras do curso de mestrado na COPPE/UFRJ; Continuidade da contribuição acadêmica através do laboratório RAVEL: desenvolvimento de sw para apoio; intercâmbio

Leia mais

rr-09-r.01 Introdução UC: Redes de Computadores Docente: Prof. André Moraes

rr-09-r.01 Introdução UC: Redes de Computadores Docente: Prof. André Moraes Introdução UC: Redes de Computadores Docente: Prof. André Moraes Créditos I Créditos II Bibliografia Básica Título Autor Edição Local Editora Ano Redes de computadores TANENBAUM, Andrew S. Rio de Janeiro

Leia mais

ESCLARECIMENTO I EDITAL DE PREGÃO PRESENCIAL Nº. 157/2015

ESCLARECIMENTO I EDITAL DE PREGÃO PRESENCIAL Nº. 157/2015 ESCLARECIMENTO I EDITAL DE PREGÃO PRESENCIAL Nº. 157/2015 O SESI/SENAI-PR, através de sua Comissão de Licitação, torna público o ESCLARECIMENTO referente ao edital de licitação acima relacionado, conforme

Leia mais

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.)

Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Gerencia de Rede (Desempenho) Professor: Guerra (Aloivo B. Guerra Jr.) Unidade 3 3.1 Introdução 3.2. Definições 3.3. Motivações 3.4. Problemas 3.5. Desafios 3.6. Padronização e Arquitetura 3.7. Gerência

Leia mais

F n u d n a d ment n os o Vo V I o P Introdução

F n u d n a d ment n os o Vo V I o P Introdução Tecnologia em Redes de Computadores Fundamentos de VoIP Professor: André Sobral e-mail: alsobral@gmail.com Introdução VoIP (Voice over Internet Protocol) A tecnologia VoIP vem sendo largamente utilizada

Leia mais

Proposta de Numeração VoIP Nacional

Proposta de Numeração VoIP Nacional GT-VOIP Relatório I.5: Proposta de Numeração VoIP Nacional Janeiro de 2003 Este relatório apresenta o plano de numeração preliminar definido com base na experiência em montar e gerenciar o ambiente VOIP

Leia mais

Capítulo 3: Implementar a segurança por meio de VLANs

Capítulo 3: Implementar a segurança por meio de VLANs Unisul Sistemas de Informação Redes de Computadores Capítulo 3: Implementar a segurança por meio de VLANs Roteamento e Switching Academia Local Cisco UNISUL Instrutora Ana Lúcia Rodrigues Wiggers Presentation_ID

Leia mais

Equipamentos de Rede. Prof. Sérgio Furgeri 1

Equipamentos de Rede. Prof. Sérgio Furgeri 1 Equipamentos de Rede Repetidor (Regenerador do sinal transmitido)* Mais usados nas topologias estrela e barramento Permite aumentar a extensão do cabo Atua na camada física da rede (modelo OSI) Não desempenha

Leia mais

A Gerência em Redes de Computadores

A Gerência em Redes de Computadores A Gerência em Redes de Computadores Gerência de Redes Redes Ferramenta fundamental Tecnicamente: constante expansão, tanto fisicamente como em complexidade. O que o usuário espera da rede? Disponibilidade

Leia mais

Qualidade de serviço. Determina o grau de satisfação do usuário em relação a um serviço específico Capacidade da rede de atender a requisitos de

Qualidade de serviço. Determina o grau de satisfação do usuário em relação a um serviço específico Capacidade da rede de atender a requisitos de Qualidade de serviço Determina o grau de satisfação do usuário em relação a um serviço específico Capacidade da rede de atender a requisitos de Vazão Atraso Variação do atraso Erros Outros Qualidade de

Leia mais

Capítulo 6 - Protocolos e Roteamento

Capítulo 6 - Protocolos e Roteamento Capítulo 6 - Protocolos e Roteamento Prof. Othon Marcelo Nunes Batista Mestre em Informática 1 de 53 Roteiro (1 / 2) O Que São Protocolos? O TCP/IP Protocolos de Aplicação Protocolos de Transporte Protocolos

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

Um Pouco de História

Um Pouco de História Telefonia IP Um Pouco de História Uma Breve Introdução às Telecomunicações Telefonia Tradicional Conversão analógica-digital nas centrais (PCM G.711) Voz trafega em um circuito digital dedicado de 64 kbps

Leia mais

Estrutura da Internet

Estrutura da Internet Estrutura da Internet Redes de redes Estrutura da Internet: rede de redes Grosseiramente hierárquica No centro: s de zona-1 (ex.: UUNet, BBN/Genuity, Sprint, AT&T), cobertura nacional/internacional Os

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Entendendo como funciona o NAT

Entendendo como funciona o NAT Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços

Leia mais

Figura 1: Como um PABX IP se integra na Rede. PSTN, em português, é Rede de Telefonia Pública Comutada.

Figura 1: Como um PABX IP se integra na Rede. PSTN, em português, é Rede de Telefonia Pública Comutada. O Que é um PABX IP? Um PABX IP é um sistema completo de telefonia que fornece chamadas telefônicas em cima da redes de dados IP. Todas as conversações são enviadas como pacotes de dados sobre a rede. A

Leia mais

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF REDES ESAF 01 - (ESAF - Auditor-Fiscal da Previdência Social - AFPS - 2002) Um protocolo é um conjunto de regras e convenções precisamente definidas que possibilitam a comunicação através de uma rede.

Leia mais

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1 Visão geral técnica e dos recursos SWD-1031491-1025120324-012 Conteúdo 1 Visão geral... 3 2 Recursos... 4 Recursos para gerenciar contas de usuário

Leia mais