UMA PROPOSTA PARA GESTÃO DE QOS AUTÔNOMO DE TRÁFEGO VOIP EM REDES OPENFLOW

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

Download "UMA PROPOSTA PARA GESTÃO DE QOS AUTÔNOMO DE TRÁFEGO VOIP EM REDES OPENFLOW"

Transcrição

1 UMA PROPOSTA PARA GESTÃO DE QOS AUTÔNOMO DE TRÁFEGO VOIP EM REDES OPENFLOW Günter Fischborn 1 Rafael Bohrer Ávila 2 Resumo: A adoção de protocolos VoIP (Voice over Internet Protocol) em ambientes corporativos necessita de diversos controles para sua plena operação, entre os quais regras de QoS (Quality of Service), prioridade no encaminhamento de pacotes de mídia, monitoramento contínuo dos recursos de rede e correta configuração dos sistemas clientes. O SIP (Session Initiation Protocol), por oferecer uma estrutura de comunicação descentralizada e, por depender de outros protocolos como RTP (Real-time Transport Protocol) e SDP (Session Description Protocol) para o seu funcionamento, apresenta características que dificultam a implementação destes controles, por exemplo, identificação das portas de transporte em que será estabelecida a comunicação multimídia ou excesso de tráfego em filas de QoS mal dimensionadas. Em estruturas que utilizam o framework de redes programáveis OpenFlow, a dificuldade de implementação destes controles pode ser reduzida através de aplicações específicas desenvolvidas para possibilitar a automação de regras de QoS, introduzindo características na rede, de forma que esta se adapte conforme a necessidade deste tráfego. Este trabalho explora os recursos do OpenFlow para automatizar a gestão de regras de QoS e garantir que todo tráfego VoIP receba o tratamento adequado, sem que haja a necessidade de configuração de parâmetros específicos nos clientes SIP, em conjunto com o monitoramento dos recursos utilizados pelo tráfego de voz e gestão do mesmo. Estes objetivos são alcançados através da captura e análise de pacotes SIP trafegados nos comutadores e ações tomadas de acordo com os parâmetros adotados para cada sessão. Palavras-chave: OpenFlow. POX. QoS. Redes Definidas por Software (RDS). SIP. VoIP. 1 INTRODUÇÃO A utilização do VoIP (Voice over Internet Protocol) para comunicação em ambientes corporativos se tornou uma tendência a partir do desenvolvimento e popularização do protocolo SIP (Session Initiation Protocol ROSENBERG et al., 2002) desenvolvido pela IETF (Internet Engineering Task Force), tornando-se o protocolo mais utilizado para iniciar, controlar e encerrar sessões multimídia (SIÉCOLA; KON, 2011). Empresas de diferentes portes têm investido na utilização desta tecnologia por diversos fatores, entre os quais a mobilidade e a redução de custos, uma vez que soluções abertas podem ser utilizadas para a implementação de infraestruturas SIP. Apesar de o SIP ser um protocolo aberto e amplamente difundido, administradores de rede ainda sofrem para construir uma estrutura com qualidade de serviço confiável. Para garantir os recursos necessários para o tráfego VoIP em momentos de alto consumo da rede, cotas e pri- 1 Aluno do curso de Segurança da Informação. 2 Orientador, professor da Unisinos, doutor em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (2005), Mestre em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (1999).

2 2 oridades são estabelecidas de acordo com os endereços de rede ou portas TCP/IP (KIM et al., 2010). Porém, pelo fato de o SIP apresentar a característica de possuir uma estrutura descentralizada, sendo que diversos parâmetros das sessões de mídia são configurados nos próprios clientes SIP, a correta configuração destes parâmetros pode ser um trabalho oneroso. O problema refere-se justamente na identificação do tráfego VoIP para aplicação das regras de QoS (Quality of Service), uma vez que não há definição de uma porta padrão para a comunicação do tráfego de voz, podendo estas variar, dependendo da solução, modelo e fabricante de clientes SIP. O fator mobilidade também dificulta na aplicação de regras por endereços de rede, uma vez que usuários podem utilizar softphones instalados em seus notebooks ou smartphones para se locomover entre diferentes redes e utilizar um mesmo endereço IP (Internet Protocol) para diferentes fluxos de dados. O OpenFlow (MCKEOWN et al., 2008) é um modelo de redes programáveis por software desenvolvido inicialmente para possibilitar a utilização da estrutura e recursos de uma rede de produção para realização de experimentos de novos protocolos de rede e roteamento, possibilitando que os tráfegos de teste e produção, em uma mesma infraestrutura, estejam totalmente isolados. O OpenFlow explora recursos em comum da tabela de fluxos de diferentes equipamentos de rede, como switches, roteadores e access points, para implementação de regras de análise de dados e encaminhamento de pacotes. Levando em consideração os problemas apresentados anteriormente, este trabalho tem por finalidade apresentar um sistema de gestão autônoma para o tráfego VoIP, com o objetivo de monitorar, capturar os pacotes SIP trafegados nos computadores OpenFlow e, através da análise destes pacotes, identificar os recursos necessários para o pleno funcionamento do tráfego de voz, adequando as regras de qualidade de serviço individualmente para cada sessão SIP estabelecida. O protocolo SIP foi projetado para atender demandas de aplicações que necessitem de estabelecimento de sessões, por exemplo, comunicações por voz, vídeo e mensagens de texto. Entretanto, o escopo deste trabalho será limitado somente aos recursos de voz em redes locais OpenFlow através da utilização do SIP em conjunto com os protocolos SDP (Session Description Protocol) e RTP, também desenvolvidos pela IETF. Este trabalho também não contempla sessões SIP que utilizam o protocolo TLS (Transport Layer Security) para o estabelecimento de sessões, uma vez que os dados destes pacotes são criptografados, impossibilitando a análise dos mesmos. Este artigo está organizado da seguinte forma: no capítulo 2, são detalhados os protocolos e ferramentas essenciais para o desenvolvimento do sistema proposto, abordando o funcionamento e recursos do protocolo SIP, características do protocolo de troca e controle de mídia RTP, o protocolo de descrição de sessão SDP e o framework de redes programáveis OpenFlow. No capítulo 3, são apresentados os trabalhos relacionados ao controle de QoS e gestão de redes OpenFlow, o capítulo 4 detalha o sistema de gestão de QoS proposto, o capítulo 5 expõe os testes realizados para validação dos resultados dos objetivos propostos e, o capítulo 6, apresenta a conclusão e propostas de trabalhos futuros.

3 3 2 REFERENCIAL TEÓRICO Esta seção possui como objetivo apresentar brevemente os protocolos e ferrramentas essenciais para o desenvolvimento deste artigo. 2.1 SIP Session Initiation Protocol Rosenberg et al. (2002) definem o SIP como um protocolo de controle da camada de aplicação responsável por estabelecer, modificar e encerrar sessões multimídia, tais como chamadas telefônicas através da Internet. O SIP foi desenvolvido para ser capaz de criar e gerenciar sessões de troca de dados entre os participantes em uma rede IP, possibilitando estabelecer comunicações através de diferentes tipos de mídias. Como a função do SIP está relacionada com a gerência de sessões, para a construção de uma arquitetura multimídia completa o SIP pode ser usado simultaneamente com outros protocolos. Estes incluem o Real-time Transport Protocol - RTP (SCHULZRINNE et al., 2003), que possui a função de transporte de dados em tempo real e fornecimento de feedback referente à qualidade do serviço, e o Session Description Protocol - SDP (HANDLEY; JACOBSON; PERKINS, 2006), responsável por descrever e negociar parâmetros de sessões multimídia. O funcionamento do SIP, porém, não depende de qualquer um destes protocolos, mas permite que os participantes da sessão se descubram e possam chegar a um acordo referente às características da sessão que irão iniciar (ROSENBERG et al., 2002). A estrutura do SIP é dividida em clientes, proxy e registradores. Clientes são definidos por qualquer elemento de rede capaz de enviar, receber e responder requisições SIP, como aparelhos telefônicos ou softphones. Os servidores proxy são responsáveis por autenticar e autorizar serviços e recursos para clientes, além de rotear requisições entre usuários, independente das suas localizações em uma rede local ou na Internet, garantindo assim a mobilidade oferecida pelo protocolo SIP. Registradores são servidores responsáveis pelo recebimento de solicitações de registro de clientes e possuem também a função de gerenciar a localização destes em um domínio SIP. O protocolo SIP é baseado em um modelo transacional de mensagens, constituida por requisições e respostas. Cada transação consiste em uma requisição que invoca um determinado método ou função particular no servidor e, pelo menos, uma resposta (ROSENBERG et al., 2002). O SIP define seis tipos de requisições, utilizados para registrar, estabelecer, encerrar sessões e consultar servidores sobre as suas capacidades de serviços: REGISTER: Método utilizado para criar um vínculo entre o cliente e o serviço de localização de um domínio. Este vínculo é utilizado pelo proxy SIP para identificar o(s) endereço(s) do cliente para encaminhamento de requisições; INVITE: Método utilizado para iniciar ou modificar uma sessão SIP;

4 4 ACK: Mensagem encaminhada pelo cliente para confirmar qualquer resposta final recebida, com a finalidade de gerar confiabilidade nas transações SIP; CANCEL: Utilizado para cancelar uma requisição INVITE ainda não respondida. Ao encaminhar uma mensagem com este método, o cliente solicita ao destinatário que encerre o processamento da requisição e gere uma resposta de erro para a mesma, geralmente utilizando a mensagem 487 request terminated ; BYE: Método que encerra uma sessão em andamento ou uma sessão ainda em construção. Um cliente, ao receber o método BYE em um diálogo, deve encerrar qualquer sessão associada a este; OPTIONS: Este método permite que um cliente consulte as capacidades de outro cliente ou de um servidor proxy. A utilização deste método evita o encaminhamento de uma requisição não suportada pelo destinatário. As respostas SIP são divididas por classes definidas pelo primeiro dígito do código de estado, sendo os demais dois dígitos utilizados para a identificação das respostas. Estas classes estão divididas conforme a seguir: 1XX - Provisória: Possui a função de informar ao requisitante que a mensagem foi recebida e está sendo processada, porém ainda não possui uma resposta definitiva; 2XX - Sucesso: Esta mensagem indica que a solicitação foi recebida com sucesso, atendida e aceita; 3XX - Redirecionamento: Indica que outras ações precisam ser tomadas para que a requisição possa ser completada. Esta resposta fornece informações sobre a nova localização de um usuário ou referente a serviços alternativos que podem satisfazer a chamada; 4XX - Erro de Cliente: Indica erro de sintaxe ou impossibilidade do servidor de compreender a mensagem. Ao receber esta resposta, o cliente não deve reencaminhar a requisição ao mesmo servidor sem nenhuma alteração; 5XX - Erro de Servidor: Indica falha no servidor ao tentar processar uma mensagem aparentemente válida; 6XX - Falha Global: Indica que a requisição encaminhada não pode ser compreendida em nenhum servidor. 2.2 RTP Real Time Protocol O RTP é um protocolo de transporte que possui como principal característica o fornecimento de serviços de entrega de dados em tempo real, utilizado amplamente para transporte de áudio e vídeo em redes de computadores (SCHULZRINNE et al., 2003).

5 5 O RTP é geralmente transportado através do protocolo UDP (User Datagram Protocol), pelo fato de não ser orientado à conexão e ser mais leve que o protocolo TCP (Transmission Control Protocol). O UDP possui a característica de não fornecer garantias de que os pacotes serão entregues ao seu destino, mesmo assim, nenhum mecanismo complementar é utilizado pelo RTP para controle e garantia de entrega de pacotes. O RTP também não possui nenhum recurso para garantir a entrega de pacotes em ordem, entretanto, números de sequência são implementados para permitir a correta reconstrução desta sequência no remetente. O RTP utiliza também o protocolo RTCP (Real-time Control Protocol) para permitir o monitoramento da qualidade do serviço da transmissão e implementar controles estatísticos e informações sobre os participantes de uma sessão em curso. Em casos de conferência de áudio e vídeo simultâneas, os pacotes de mídia destes tráfegos são transmitidos separadamente, a fim de que participantes possam optar por receber pacotes somente de um dos tipos de mídia. 2.3 RTCP Real-time Control Protocol O protocolo RTCP é utilizado para implementar o controle de uma sessão RTP. A principal função do RTCP é fornecer o feedback referente à qualidade do serviço de transmissão de dados, a fim de que seja possível diagnosticar falhas neste processo. O RTCP é utilizado também para identificar participantes e sincronizar diferentes fluxos de dados de uma mesma sessão, como áudio e vídeo (SCHULZRINNE et al., 2003). Outra função do RTCP é controlar a taxa de pacotes encaminhada para cada participante de uma sessão. Esta taxa é calculada a partir de informações dos próprios pacotes de controle recebidos dos demais participantes. O RTCP pode ser utilizado ainda, opcionalmente, para controlar uma sessão multimídia com funções reduzidas, permitindo a entrada e saída de participantes. É aconselhável, porém, que protocolos específicos de controle de sessão, como o SIP, sejam utilizados para esta demanda, de modo que recursos e requisitos adicionais possam ser atendidos e implementados (SCHULZRINNE et al., 2003). 2.4 SDP Session Description Protocol O SDP (Session Description Protocol), segundo Handley, Jacobson e Perkins (2006), é um protocolo que possui a incumbência de fornecer informações referentes aos fluxos de mídia de sessões multimídias. Esta descrição contém informações essenciais para o início de transmissões de mídias, como detalhes que se referem à própria mídia e endereços de transporte (HANDLEY; JACOBSON; PERKINS, 2006). Em uma comunicação SIP, é de responsabilidade do SDP transmitir, entre as partes envolvidas, informações referente a codecs de mídia, endereços IP e portas de transporte que serão utilizadas para a transmissão dos pacotes RTP e RTCP. Para o transporte dos pacotes RTP, são

6 6 definidas sempre portas pares, sendo que o RTCP utiliza a porta ímpar imediatamente superior. O SDP, no entanto, não agrega na sua solução um protocolo de transporte, dependendo de outros protocolos, como o SIP, para exercer esta função (HANDLEY; JACOBSON; PERKINS, 2006). 2.5 OpenFlow As redes de computadores se tornaram comuns e fundamentais em empresas de qualquer segmento de negócio, entidades de ensino e até mesmo em residências. Contudo, um dos grandes desafios que pesquisadores encontram é a relutância em poder realizar experimentos de novos protocolos de rede e roteamento em ambientes de produção, a fim de ter resultados convincentes em estruturas suficientemente realistas para implantação destes de forma generalizada. Fato este que acaba engessando o processo de criação de novos protocolos ou até mesmo provocando a sua implementação ainda que não maduros o suficiente (MCKEOWN et al., 2008). OpenFlow foi proposto com o intuito de tornar possível a execução de protocolos experimentais em uma rede de produção, sem impactar no funcionamento e desempenho desta (MC- KEOWN et al., 2008). O OpenFlow foi desenvolvido inicialmente para ser utilizado em redes de universidades para realização de experimentos em uma estrutura de rede de produção, entretanto, diversos projetos propõem a sua utilização para gerenciar e monitorar redes de produção. O OpenFlow visa atender a quatro requisitos que são atualmente os maiores empecilhos para as redes de pesquisa (MCKEOWN et al., 2008): Ser uma implementação de alto desempenho e de baixo custo; Ser capaz de suportar uma ampla gama de pesquisas; Suportar o isolamento completo da rede de produção da rede de pesquisa; Atender às necessidades dos fabricantes de equipamentos de rede de plataformas fechadas, não necessitando da abertura dos seus códigos Componentes e Funcionamento Para possibilitar a compatibilidade do OpenFlow com equipamentos de diversos fornecedores, foi explorado o fato de que a maioria dos comutadores de rede (switches, roteadores e access points) possui tabelas de fluxos em sua estrutura, utilizadas para implementação de funcionalidades como NAT (Network Address Translation), QoS, firewall e também para coleta de estatísticas (MCKEOWN et al., 2008). Um conjunto comum de funções entre fabricantes e modelos de equipamentos foram constatados, funções estas que são exploradas pelo OpenFlow. Um comutador OpenFlow possui pelo menos três partes distintas: uma tabela de fluxo, um canal seguro e o protocolo OpenFlow (MCKEOWN et al., 2008). A tabela de fluxo é uma

7 7 Figura 1 Topologia OpenFlow Fonte: Adaptada de McKeown et al. (2008) associação da ação a ser tomada para cada entrada de fluxo no comutador. O canal seguro é responsável pela transmissão de dados entre os comutadores e o controlador OpenFlow, de modo que qualquer comunicação entre estes componentes possa ser criptografada através do protocolo TLS (Transport Layer Security) (PFAFF et al., 2011). Este canal é utilizado pelo controlador para configurar, gerenciar, receber eventos e encaminhar pacotes de saída (packetout) para portas específicas nos comutadores. Já o protocolo OpenFlow é a linguagem padrão que possibilita a comunicação entre o controlador e os comutadores (MCKEOWN et al., 2008), possibilitando ao controlador adicionar, alterar e excluir entradas de fluxo (PFAFF et al., 2011). Para o pleno funcionamento de uma rede OpenFlow, além dos comutadores possuírem a função de encaminhamento e descarte de pacotes, há a necessidade de uma entidade responsável pela gerência dos fluxos de dados, denominado controlador. O controlador é responsável por adicionar e remover entradas nas tabelas de fluxos dos comutadores, bem como receber pacotes através do canal seguro, a fim de tomar determinadas decisões não capazes pelo comutador. O POX (MCCAULEY, 2013) é um exemplo de controlador OpenFlow baseado na linguagem de programação Python 3, elaborado para proporcionar o rápido desenvolvimento e prototipagem de sistemas para controle de rede (MCCAULEY, 2013). A Figura 1 exemplifica uma topologia básica de uma rede OpenFlow, onde são representados os seus componentes. As tomadas de decisões em controladores e comutadores OpenFlow são baseadas nos campos de camadas 2, 3 e 4 do modelo OSI (Open Systems Interconnection) recebidos nos pacotes em cada comutador. Através dos valores destes campos, detalhados na Tabela 1, ações de direcionamento ou de descarte de pacotes serão executadas de acordo com as regras estipuladas pelo controlador. 3

8 8 Tabela 1 Campos de pacotes utilizados pelo OpenFlow Campo Descrição Ingress port Porta de ingresso do pacote Metadata Metadados Ether src Endereço de origem ethernet Ether dst Endereço de destino ethernet Ether type Tipo ethernet VLAN id Identificador de VLAN VLAN priority Prioridade de VLAN MPLS label Rótulo MPLS MPLS traffic class Classe de tráfego MPLS IPv4 src Endereço de origem IPv4 IPv4 dst Endereço de destino IPv4 IPv4 proto / ARP opcode Protocolo IPv4 / Código ARP IPv4 ToS bits Bits de tipo de serviço IPv4 TCP / UDP / SCTP src port / ICMP Type Portas de origem de transporte / tipo de ICMP TCP / UDP / SCTP dst port / ICMP Code Portas de destino de transporte / código ICMP Fonte: Adaptada de Pfaff et al. (2011) 3 TRABALHOS RELACIONADOS Diversos trabalhos foram desenvolvidos com a finalidade de prover qualidade de serviço em redes OpenFlow, sendo poucos destinados especificamente a comunicações que utilizam o protocolo SIP. Nesta seção, são apresentados os projetos encontrados que mais se aproximam dos objetivos deste trabalho. Mattos e Duarte (2012) apresentam o sistema QFlow, desenvolvido para gerar garantia de isolamento de recursos e implementação de QoS para redes virtuais. O objetivo do QFlow é alterar o atual modelo de negócio de provedores de serviço de Internet (Internet Service Provider ISP), separarando as funções de fornecer e manter os equipamentos físicos de rede, das funções de prover conectividade fim-a-fim e serviços de Internet. Com esta finalidade, uma nova entidade denominada Provedor de Infraestrutura Física (Physical Infraestructure Provider PIP) seria criada. A proposta do QFlow é prover um sistema de controle de qualidade de serviço e de isolamento de recursos em redes virtuais, baseado na plataforma de virtualização de computadores Xen e no OpenFlow. Para garantir esta qualidade, o QFlow propõe monitorar e controlar o uso de recursos por rede virtual, como controle de banda, limite estático de processamento e memória do roteador, além de realizar a redistribuição de recursos ociosos na infraestrutura física, através de prioridades calculadas para cada rede virtual. Esta redistribuição é destinada somente aos recursos de rede, sendo realizada em dois níveis, ocorrendo o primeiro quando a capacidade total do enlace é maior do que o somatório de todos os limites mínimos das filas associadas ao enlace e, o segundo, quando o uso total do enlace é menor do que o somatório dos limites mínimos reservados para as filas.

9 9 Para combater o problema de pouca exploração do serviço de QoS em redes OpenFlow, Ishimori et al. (2012) apresentam o QoSFlow, um arcabouço de software que visa possibilitar o gerenciamento de QoS em domínios OpenFlow, permitindo, através de primitivas de qualidade de serviço, o gerenciamento de disciplinas de filas. A proposta do QoSFlow é eliminar a tarefa de configuração manual e individual de políticas de QoS em comutadores e entre domínios OpenFlow, automatizando o processo de gerenciamento de QoS através da investigação dos fluxos na rede e comparação com regras armazenadas em repositórios de políticas. Com isso, o sistema oferece condições de definição em alto nível destas políticas através das ações de marcações TOS/DSCP, limitação ou provisionamento de banda e descarte ou priorização de pacotes. O QoSFlow implementa também um módulo de monitoramento de filtros de pacotes, classes e disciplinas de filas. Para chegar a este resultado, novas mensagens de controle foram adicionadas no protocolo OpenFlow e no controlador NOX, para que seja possível a configuração de classes de fluxos e filtros de pacotes no kernel do Linux dos comutadores. OpenQoS é proposto por Egilmez et al. (2012) como um sistema para controle de tráfego na Internet, com suporte à entrega de recursos multimídia com qualidade de serviço fim-a-fim. O OpenQoS parte da premissa de que o tráfego na Internet possui a característica de adotar tradicionalmente rotas com caminhos mais curtos, o que nem sempre favorece o tráfego multimídia devido à falta de recursos para o transporte deste com a qualidade necessária, principalmente em razão do consumo de links. Através desta premissa, o OpenQoS propõe roteamento dinâmico para o tráfego multimídia através de rotas que apresentam maior qualidade com relação à largura de banda, perda de pacotes e atraso, enquanto os demais fluxos permanecem sendo encaminhados pelo caminho mais curto. Os autores ressaltam que a principal diferença do OpenQoS, em comparação aos métodos tradicionais de QoS, é a não utilização de reservas de recursos ou filas de prioridades, sendo esta característica uma vantagem, pois diminui a perda de pacotes e latência nos demais tráfegos não priorizados. Mattos et al. (2011) apresentam a ferramenta OMNI (OpenFlow MaNagement Infrastructure), que possui a função de auxiliar o administrador no controle e gerência de redes Open- Flow, além de possibilitar o desenvolvimento de aplicações autônomas para complementar esta gerência. Estas funções são desempenhadas por aplicações que executam sobre o controlador OpenFlow, agindo este como uma interface entre as aplicações de controle e a rede. O OMNI disponibiliza um conjunto de ferramentas de controle e gerenciamento, divididas em ferramentas ativas e passivas, uma interface web para gerência destas ferramentas e um sistema multiagente para controlar autonomamente a rede OpenFlow. Entre as ferramentas passivas, destacam-se a Stats, que é responsável pela coleta de estatísticas dos comutadores OpenFlow e a ferramenta Discovery, responsável pela descoberta da topologia da rede. As coletas de dados são realizadas através de pedidos encaminhados pela aplicação para os comutadores OpenFlow, que respondem com os dados solicitados. Entre as

10 10 ferramentas ativas, estão a Flow Manager, responsável pela criação e remoção dos fluxos de dados nos comutadores da rede, e a Flow Migration, responsável pela migração destes fluxos entre os comutadores. O OMNI disponibiliza também um sistema multiagente que se destaca por oferecer a característica de gerenciamento autônomo da rede através de agentes específicos, sendo estes capazes de monitorar e detectar falhas de encaminhamento nos comutadores OpenFlow e gerenciar a migração dos fluxos de enlaces com alto índice de perda de pacotes, para outro com maior capacidade e que não apresenta tal falha. 3.1 Análise dos Trabalhos Relacionados Os trabalhos referenciados neste capítulo apresentam recursos voltados à gestão e qualidade de serviço em redes OpenFlow. Nesta seção, os trabalhos são comentados e relacionadas às funcionalidades que ajudaram na elaboração deste artigo. Para o provisionamento de qualidade de serviço em redes OpenFlow, o QFlow implementa a garantia de recursos por rede virtual, além da redistribuição de recursos ociosos entre as redes, de acordo com prioridades estipuladas para cada cliente. Já o sistema OMNI implementa funcionalidades de QoS migrando todos os fluxos de dados de um enlace que apresenta perda de pacotes para outro com maior qualidade. Estas propostas não tratam fluxos específicos de uma rede para provisionamento de QoS, possuindo a característica de garantir recursos por rede virtual ou enlace. O sistema QoSFlow, por sua vez, é capaz de gerenciar regras de QoS através de informações obtidas nos fluxos de dados, tais como endereço IP, portas de transporte, marcações TOS/DSCP, identificador de VLAN, entre outras. Com isso, regras mais específicas podem ser configuradas para priorização e enfileiramento de fluxos de dados distintos. O sistema OpenQoS implementa qualidade de serviço destinada ao tráfego multimídia na Internet, através do monitoramento de enlaces para estipular rotas com maior qualidade, enquanto os demais fluxos seguem em rotas de caminho mais curto. Apesar do QoSFlow ser capaz de aplicar regras para diferentes tipos de fluxos, e o OpenQoS tratar especificamente de tráfego multimídia, estes sistemas necessitam que parâmetros específicos, como porta de tranporte ou marcações TOS/DSCP, sejam atendidos para que haja a identificação e o correto tratamento destes fluxos. A principal inovação deste trabalho com relação a estas propostas é a capacidade de identificar, em cada sessão SIP, os parâmetros utilizados para o estabalecimento da comunicação de voz e, com isso, efetuar a configuração das regras de QoS individualmente para cada sessão estabelecida. A partir disso, pode ser evitada a necessidade da configuação de parâmetros, como portas de transporte e classes de serviços padronizados, na central telefônica e clientes SIP, além de garantir que todo tráfego VoIP receba o tratamento adequado, mesmo em situações em que os clientes não estejam corretamente configurados.

11 11 Os sistemas analisados implementam a funcionalidade de monitoramento dos recursos de rede para realocação de tráfegos entre redes virtuais, filas ou enlaces, de acordo com a ocupação ou qualidade do recurso monitorado. O sistema proposto também implementa o monitoramento da ocupação das filas de QoS dos comutadores OpenFlow, com a finalidade de restringir novas chamadas em situações em que não há disponibilidade para alocação desta. Para isso, análises são realizadas de acordo com parâmetros de cada sessão, para evitar que chamadas em andamento sejam prejudicadas por esta funcionalidade. 4 SISTEMA DE GESTÃO DE QOS PROPOSTO O aproveitamento da infraestrutura de redes existentes em organizações para a implementação de serviços de comunicação, necessita de requisitos para garantir que os demais tráfegos da rede não produzam impactos na transmissão dos pacotes de voz. O tráfego VoIP é extremamente sensível a qualquer evento que ocasione atraso, jitter elevado ou perda de pacotes, eventos estes que impactam diretamente na qualidade do serviço de voz. Para minimizar estes fatores, regras de QoS precisam ser implementadas na infraestrutura de rede, com a finalidade de priorizar o processamento destes pacotes nos comutadores, havendo ainda a possibilidade de reserva de uma parcela da banda do enlace para este tráfego. Usualmente estas regras são definidas levando-se em consideração os endereços IPs de origem e/ou destino dos pacotes, as portas de transporte utilizadas para a comunicação, ou ainda marcações de classe de serviço (DiffServ), de acordo com a necessidade e prioridade de cada tráfego. A configuração destes parâmetros de QoS geralmente não é uma tarefa fácil, principalmente em redes grandes e complexas, em razão da quantidade de sub-redes, roteadores, clientes SIP e demais equipamentos necessários para o pleno funcionamento de uma estrutura de VoIP completa. Uma característica do SIP é proporcionar sessões VoIP descentralizadas, ou seja, a comunicação multimídia ocorre diretamente entre os clientes. Em consequência disso, a configuração das portas para este tráfego é realizada em cada equipamento ou sistema final, muitas vezes manualmente, quando um parâmetro errado pode resultar no tratamento inadequado de chamadas e, consequentemente, na degradação da qualidade do serviço. Outro fator que pode impactar diretamente na qualidade do serviço de voz é o excesso de tráfego submetido à fila destinada ao VoIP, em situações onde o limite configurado é excedido por uma quantidade de chamadas maior do que o suportado pela estrutura. Este processo pode ocasionar o atraso no encaminhamento dos pacotes de voz ou até mesmo o seu descarte, gerando perda de qualidade em todas as chamadas trafegadas neste enlace. Este trabalho tem como objetivo solucionar os problemas descritos, através da monitoração e análise dos pacotes SIP trafegados pelos comutadores OpenFlow. Esta análise visa identificar informações essenciais como endereços IP, portas de transporte e demais informações utilizadas pelo protocolo SIP, para adequar o tráfego VoIP de acordo com a estrutura de QoS configurada

12 12 Figura 2 Topologia Aplicação OpenFlow Fonte: Elaborada pelo autor nos comutadores, além de monitorar o consumo deste tráfego e aplicar controles para a gestão de novas chamadas. Para gerenciar os processos de qualidade de serviço e monitoramento das filas, foi desenvolvida uma aplicação que atua em conjunto com o controlador POX. Esta aplicação é responsável por implementar regras de direcionamento de fluxos de dados nos comutadores OpenFlow, pela análise dos pacotes encaminhados por estes, pelo monitoramento das filas de QoS, pela gerência e automação do tráfego VoIP e aplicação das regras de qualidade de serviço destinados a este tráfego. A topologia da estrutura da aplicação está exemplificada através da Figura Estrutura da Aplicação Uma das principais dificuldades para a configuração de regras de QoS para tráfego VoIP é a identificação das características de rede utilizada por este serviço, uma vez que não há definição de portas padronizadas para o transporte de pacotes RTP, podendo estas serem geradas de forma aleatória. Para solucionar este problema em redes OpenFlow, a aplicação foi desenvolvida para configurar um fluxo nos comutadores, exigindo que todo pacote trafegado na porta 5060, TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), seja direcionado para o controlador. A partir do recebimento dos pacotes pela aplicação, todos são identificados por tipo de mensagem SIP e coletadas informações necessárias para a configuração das regras de QoS. Os dados coletados pela aplicação encontram-se detalhados na Tabela 2. O OpenFlow possui a característica de possibilitar que mais de uma aplicação seja executada simultaneamente em um mesmo controlador. Por este motivo, a aplicação identifica as mensagens SIP entre os pacotes encaminhados para o controlador, desconsiderando os demais, pelo fato de poderem pertencer a outra aplicação. Durante a coleta dos dados necessários para a configruação das regras de QoS, somente as mensagens INVITE e 200 OK são analisadas, pois são elas as responsáveis pelas funções de requisição e resposta de chamadas no SIP e por transportarem o payload do protocolo SDP com as informações relativas ao tráfego de mídia do protocolo RTP. Todas as mensagens SIP, ao serem identificadas, são prontamente devolvidas

13 13 Tabela 2 Campos Coletados em Pacotes SIP Campo Protocolo Descrição From SIP Identificação do originador da requisição To SIP Identificação do destinatário da requisição Call-ID SIP Código identificador da sessão SIP CSeq SIP Identificação do método originador da resposta Connection Address SDP IP em que originador espera receber os pacotes RTP Media Port SDP Porta em que originador espera receber os pacotes RTP Fonte: Elaborada pelo autor ao comutador para encaminhamento ao destino, com exceção do INVITE que, primeiramente, passa por uma análise para garantir que existem recursos disponíveis para o tráfego de uma nova chamada. A partir da coleta e análise das informações dos protocolos SIP e SDP informados na Tabela 2, regras de enfileiramento são aplicadas nos comutadores, levando em consideração os endereços IP e portas de transporte envolvidos na sessão RTP. Estas regras são aplicadas a todo tráfego que possua como destino o IP do cliente SIP e a respectiva porta utilizada pelo RTP, com isso encaminhando os pacotes para a fila destinada ao tráfego VoIP. Além disso, os pacotes SIP e RTCP são enviados para uma fila específica, destinada ao tráfego de sinalização e controle de sessão. As regras de fluxos de QoS configuradas são aplicadas antes do início do tráfego de voz e possuem a característica de expirar automaticamente após um período sem que haja tráfego no comutador que pertença a esta regra. Este período foi configurado em 30 segundos, tanto para pacotes RTP quanto RTCP, tempo este suficiente para identificar que a sessão SIP foi finalizada, podendo, no entanto, ser alterado de acordo com a necessidade do ambiente. O processo de configuração de regras de QoS pela aplicação é realizado através do cadastro de fluxos de enfileiramento dos pacotes SIP, RTP e RTCP nos comutadores OpenFlow. A configuração das filas e disciplinas de QoS deve ser aplicada diretamente nos comutadores, uma vez que o OpenFlow não possui suporte ao gerenciamento de filas em sua versão 1.1 (PFAFF et al., 2011), versão esta suportada pelo controlador POX e utilizada para o desenvolvimento deste trabalho. A utilização de apenas recursos de enfileiramento do OpenFlow, para gerenciamento das regras de QoS, visa tornar a aplicação compatível com qualquer comutador com suporte ao OpenFlow, uma vez que recursos externos poderiam ser utilizados para garantir a gerência completa das filas e disciplinas de QoS. Aplicações e configurações distintas, entretanto, precisariam ser utilizadas para cada modelo de comutador. A Figura 3 apresenta o fluxograma da aplicação de gestão de QoS desenvolvida. Antes que sejam aplicadas as regras de QoS, para cada pacote INVITE recebido pelo controlador, é verificada a existência de recursos de rede disponíveis para alocar uma nova sessão RTP na fila destinada ao tráfego VoIP. Esta verificação é realizada através da comparação do limite estipulado na aplicação para o tráfego de voz com o consumo atual da fila no comutador OpenFlow. Caso haja recursos para alocação de uma nova sessão, o pacote SIP é devidamente

14 14 Figura 3 Fluxograma Aplicação Fonte: Elaborada pelo autor analisado e as regras de QoS aplicadas no comutador. Não havendo banda disponível, o pacote é descartado e a comunicação não será estabelecida. No entanto, mesmo após o estabelecimento de uma sessão SIP, pacotes com o método INVITE podem ser enviados pelas partes envolvidas na comunicação, com a intenção de modificar a sessão em andamento. Por este motivo, a análise de disponibilidade de recursos na fila de VoIP verifica se o INVITE refere-se a uma sessão já estabelecida ou a uma nova sessão. Sendo uma sessão já existente, a solicitação é processada normalmente. Esta verificação é realizada através da comparação do Call ID da nova chamada com um dicionário contendo as demais chamadas em andamento e destina-se a evitar que ligações sejam iniciadas, não havendo mais disponibilidade de recursos na fila destinada ao VoIP, podendo ocasionar a degradação da qualidade de todas as demais chamadas. O registro de uma nova chamada é realizado sempre que uma mensagem 200 OK é recebida e identificada através do campo Cseq que corresponde a uma resposta de uma requisição INVITE. A exclusão deste registro é realizada também através de mensagens 200 OK, porém o Cseq sinalizando o retorno

15 15 Tabela 3 Dados armazenados no log de filas Campo Descrição Data e Horário Data e horário em que a aplicação recebeu as informações do comutador ID Comutador Identificação do comutador utilizada pelo OpenFlow MAC Address MAC Address do Comutador Kbps Taxa de transferência atual da fila em Kbps Bytes trafegados Total de bytes trafegados em cada fila Erros Atual Taxa de erros atual da fila Erros Total Taxa de erros total ocorrido na fila Fonte: Elaborada pelo autor de uma requisição BYE. Para a verificação e cálculo dos recursos utilizados em cada fila configurada nos comutadores OpenFlow, um processo de solicitação do status destas filas foi configurado para ser executado em intervalos de um segundo. Este intervalo visa estabelecer uma alta confiabilidade no processo de validação do consumo da fila de VoIP para alocação de novas chamadas, além de garantir agilidade neste processo, uma vez que a aplicação possui o status de utilização das filas praticamente em tempo real. Estas informações coletadas, além de serem utilizadas pela aplicação para análise do atual consumo de recursos nos comutadores, é também registrada em arquivos e logs, o que permite uma análise futura deste consumo. Neste log são armazenados os dados detalhados na Tabela 3, pertencentes a cada fila cadastrada no comutador. A aplicação possui também a capacidade de realizar tratamentos diferenciados para determinados ramais. Havendo a necessidade de garantia de recursos para ramais considerados críticos, a aplicação permite a realização de chamadas para ou a partir destes, mesmo que o limite estipulado para a fila VoIP esteja esgotado. Entretanto, para que não haja perda de qualidade no serviço de voz em situações de extrema utilização da fila VoIP, recursos adicionais devem ser reservados nesta fila para o pleno atendimento desta demanda extra. Através desta funcionalidade, pode-se, por exemplo, garantir recursos privados para que todas as chamadas realizadas ou recebidas por usuários considerados críticos, sejam estabelecidas. 5 VALIDAÇÃO DA PROPOSTA Testes foram realizados com a finalidade de validar o funcionamento e recursos do sistema de gestão de QoS desenvolvido. As seções, a seguir, apresentam o ambiente montado para realização destes testes, suas características e os resultados obtidos.

16 Ambiente de Testes Para a validação da proposta do sistema de gestão de QoS, um ambiente de testes foi montado utilizando a plataforma de switch virtual Open vswitch em conjunto com a ferramenta de virtualização VirtualBox Três notebooks compõem a estrutura utilizada para testes, sendo um MacBook com processador Core 2 Duo 2.4 GHz, 3 GB de memória e duas interfaces de rede, executando o sistema operacional Ubuntu em versão Desktop, Open vswitch, Virtual Box, uma máquina virtual com o sistema operacional Windows XP e o sistema cliente SIP X-Lite 7. No Open vswitch, foi configurado um switch virtual em uma das interfaces de rede, com o OpenFlow habilitado, possuindo esse uma porta virtual em modo bridge para ser utilizada pela máquina com Windows XP. A segunda interface de rede foi utilizada para gerência do Open vswitch e comunicação com o controlador POX. A utilização de uma interface exclusiva para gerência foi adotada para que o tráfego de rede não interfira na comunicação do controlador com o comutador. O segundo notebook utilizado é um Dell Latitude E5420 com processador Core i5 2.3 GHz, 4 GB de memória, executando o sistema operacional Ubuntu 12.4, Virtual Box e duas máquinas virtuais com o sistema operacional Windows XP. Em cada máquina virtual também foram configurados clientes SIP X-Lite, responsáveis pelos testes de chamadas de VoIP. Um terceiro notebook, um MacBook Pro com processador Core i5 2.5 GHz e 8 GB de memória, foi utilizado para complementar a estrutura de testes. Neste equipamento foi configurado o controlador POX no sistema operacional nativo OS X Mavericks, e uma máquina virtual com sistema operacional Ubuntu Server com o sistema de PABX IP Asterisk Faz parte da estrutura também um switch 3Com 4200, responsável pela interligação física dos notebooks. A Figura 4 demonstra a estrutura lógica detalhada acima e utilizada para todos os testes deste trabalho. Para os testes executados, a rede externa, representada pelo ambiente suportado pelo switch 3Com 4200, foi configurada de modo a não impor qualquer limite ao tráfego gerado, sendo o controle aplicado somente ao comutador OpenFlow, representado pelo Open vswitch. Para a realização dos testes de validação, foram configuradas, no switch virtual do Open vswitch, 3 filas de QoS com a disciplina HTB (Hierarchical Token Bucket). O HTB é um sistema de disciplina de filas de QoS que possibilita a implementação de compartilhamento hierárquico de recursos entre as suas interclasses, através da especificação de reservas garantidas e limites superiores de utilização de recursos, permitindo priorizar por interclasse o encaminhamento de pacotes nos recursos compartilhados entre as filas (BALAN; POTORAC, 2009). A primeira fila configurada destina-se ao tráfego normal da rede, possuindo esta uma pri https://www.virtualbox.org

17 17 Figura 4 Topologia de Testes Fonte: Elaborada pelo autor Tabela 4 Configuração das filas HTB Descrição ID Mínimo Grantido Máximo Permitido Prioridade Tráfego Normal 0 90 Kbps 250 Kbps 100 Tráfego VoIP 1 80 Kbps 240 Kbps 0 Tráfego Sinalização 2 30 Kbps 40 Kbps 50 Fonte: Elaborada pelo autor oridade baixa de encaminhamento com relação às demais. A segunda fila é designada exclusivamente ao tráfego VoIP e possui uma alta prioridade no encaminhamento. A última fila é reservada ao tráfego de sinalização SIP e pacotes RTCP, com prioridade média de encaminhamento. O tráfego total permitido para a interface de saída do switch virtual foi limitado em 360 Kbps. Este limite foi definido com o intuito de facilitar a visualização dos resultados graficamente, uma vez que o tráfego máximo de VoIP gerado será de duas ligações simultâneas, totalizando um consumo em torno de 160 Kbps. As configurações individuais de cada fila aplicadas no switch, incluindo detalhes referentes ao limite de tráfego mínimo garantido, máximo permitido e prioridades são detalhadas na Tabela 4. O HTB considera que valores menores de prioridade possuem maior preferência no encaminhamento. 5.2 Validação do Ambiente Para validar a estrutura de rede proposta, testes de tráfego foram realizados através da utilização de aplicativos Iperf 9 entre as máquinas representadas pelos ramais 1000 e 2000 na Figura 4, sem qualquer controle de QoS ou disciplinas de priorização de pacote aplicados, estando o consumo limitado ao máximo de 250 Kbps pela fila destinada ao tráfego normal. Em um primeiro teste, pacotes UDP foram trafegados entre duas máquinas em um período de 120 segundos, com taxa de transferência configurada para os mesmos 250 Kbps permitidos para este 9

18 18 Tabela 5 Perda de pacotes em testes sem QoS Número do Teste Tráfego Gerado Perda de Pacotes Iperf Perda de Pacotes RTP Kbps 0% 0% Kbps 13% 8% Kbps 40% 15% Fonte: Elaborada pelo autor tráfego. Neste teste, um total de 2552 pacotes foram gerados, não havendo registro de perdas e provocando uma taxa de transferência média de 247 Kbps. Em um segundo teste, o tráfego originado pelo Iperf foi ampliado para 375 Kbps, sendo mantido o limite da fila e a duração do teste. Neste, um total de 3828 pacotes foram gerados, porém, somente 3469 recebidos no destino, havendo a perda de 9% dos pacotes, com taxa de transfência média de 247 Kbps. No terceiro teste, o tráfego originado foi de 500 Kbps, quando 5104 pacotes foram encaminhados e 3569 recebidos no destino, havendo assim a perda de 30% dos pacotes, ficando a taxa de transferência média em 248 Kbps. Estes testes foram realizados para que haja a validação das regras de filas e a limitação do tráfego de acordo com as mesmas. A partir desta validação, os mesmos testes foram repetidos, no entanto, com a característica de ser adicionada uma chamada SIP, com duração de 60 segundos, entre os ramais 1000 e Para estas e demais ligações realizadas, foi utilizado o codec G.711 alaw, responsável pelo consumo de 80 Kbps em uma chamada de voz (ITU-T, 2008). Nestes novos testes, pôde-se perceber o aumento na perda de pacotes no que se refere ao tráfego UDP gerado pelo Iperf em comparação aos realizados anteriormente, sem as chamadas de VoIP, uma vez que houve acréscimo de 80 Kbps relativo ao tráfego de voz. Durante a realização destes testes, foram capturados, através do sniffer de rede Wireshark 10, os pacotes RTCP para verificar também a perda relativa ao tráfego VoIP, estando os resultados detalhados na Tabela 5. A partir destes resultados, é possível verificar que, com o aumento do tráfego gerado pelo Iperf, há um acréscimo na perda de pacotes RTP, uma vez que nenhum tratamento diferenciado está sendo realizado para estes pacotes. 5.3 Validação do Sistema de Gestão de QoS A partir dos resultados obtidos nos testes anteriores, novas chamadas foram realizadas, agora com a utilização do sistema de gestão de QoS desenvolvido. Para estes testes também foram gerados, através do sistema Iperf, tráfego UDP de 120 segundos. Como o sistema de gestão de QoS controla o direcionamento do tráfego para as filas adequadas, duas chamadas simultâneas foram realizadas. A primeira, para que haja a ocupação dos 80 Kbps garantidos pela reserva da fila destinada ao VoIP e, a partir da segunda, a utilização da banda compartilhada entre as filas. A primeira chamada teve a duração de 90 segundos e foi realizada entre os ramais 10

19 19 Tabela 6 Perda de pacotes em testes com a aplicação de gestão de QoS Número do Teste Tráfego Gerado Perda de Pacotes Iperf Perda de Pacotes RTP Kbps 0% 0% Kbps 18% 0% Kbps 45% 0% Fonte: Elaborada pelo autor Figura 5 Tráfego Empilhado das Filas de QoS Fonte: Elaborada pelo autor 1000 e 2000 e, a segunda, de 60 segundos, sendo estabelecida uma conferência adicionando o ramal 3000 à chamada anterior. A Tabela 6 representa o percentual da perda de pacotes de cada tráfego nestes últimos testes. Para propiciar a melhor visualização do correto direcionamento dos tráfegos entre as filas de QoS, a Figura 5 representa a ocupação destas durante a realização do teste de número 8. Através deste gráfico, é possível comprovar o correto enfileiramento dos tráfegos de voz e dos pacotes de sinalização, sem que haja uma pré-configuração de porta de transporte a ser utilizada pelo protocolo RTP ou marcação do tipo de serviço nos pacotes. Durante os testes número 7, 8 e 9, as portas de transporte utilizadas para o tráfego RTP foram determinadas de forma aleatória pelas aplicações clientes, sendo estas portas de número 52400, 15572, 50350, 58920, 51058, 60674, 56712, 60800, 63608, 56938, 56656, O gráfico representado na Figura 5 foi gerado com os dados de consumo empilhado das filas de QoS, utilizando como referência os logs fornecidos pela aplicação com o status de cada fila do comutador. É possível perceber que, à medida em que o tráfego gerado pelo Iperf é aumentado, a perda de pacotes também sofre acréscimo, no entanto, não proporcional ao aumento do tráfego. Esta diferença ocorre devido ao fato de que o comutador inicia o processo de descarte de pacotes por sobrecarga somente após o preenchimento total do seu buffer de memória, o que provoca atraso no encaminhamento do tráfego da fila Normal, mas proporciona que uma maior parcela de pa-

20 20 Figura 6 Perda de Pacotes nos Testes Realizados Fonte: Elaborada pelo autor cotes seja recebida no destino. Este atraso pode provocar impactos pequenos em aplicações que necessitam de confiabilidade no recebimento de dados, entretanto, é extremamente prejudicial para tráfegos que necessitam de baixo tempo de resposta, como comunicações multimídia. Por este motivo, a fila VoIP necessita de alta prioridade no encaminhamento de pacotes, evitando que este serviço seja prejudicado pelos demais tráfegos da rede. Nos primeiros testes realizados, quando a aplicação de gestão de QoS não estava gerenciando o direcionamento do tráfego VoIP, foi possível identificar também que a perda de pacotes VoIP aumentou à medida em que o tráfego gerado pelo Iperf era ampliado. Fato este que não ocorreu nos testes número 7, 8 e 9, uma vez que o tráfego de voz foi corretamente enfileirado e priorizado o encaminhamento deste pela disciplina de filas HTB. A Figura 6 apresenta o gráfico com a relação de perda de pacotes nos fluxos gerados pelo Iperf e tráfego RTP durante os testes 4, 5, 6, 7, 8 e 9. A partir dos resultados obtidos, foi possível comprovar que a aplicação desenvolvida é capaz de realizar, através da captura e análise dos pacotes SIP, o correto tratamento de chamadas VoIP em uma rede local OpenFlow, independente da porta de transporte utilizada para tráfego de voz ou de marcação de classe de serviço nos pacotes trafegados. Deste modo, proporciona que os pacotes de sinalização, controle de qualidade de serviço e os destinados ao transporte de mídia sejam encaminhados autonomamente para as respectivas filas de QoS nos comutadores, sem que haja a necessidade de qualquer configuração manual nos clientes SIP. Com isso, é possível garantir que toda comunicação VoIP receba o tratamento adequado. Testes foram realizados também com a finalidade de validar a funcionalidade de bloqueio de chamadas após o alcance do consumo da fila VoIP ao limite configurado. Para isso foi estabelecido o limite de verificação desta fila para 70 Kbps e, sendo o consumo maior que este valor, a aplicação descarta o pacote com o método SIP INVITE de chamadas que não estejam em andamento. Para validar esta funcionalidade, duas chamadas foram realizadas, sendo a primeira completada com sucesso e, a segunda, descartada devido ao fato de o consumo da fila

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

Walter Cunha Tecnologia da Informação Redes WAN

Walter Cunha Tecnologia da Informação Redes WAN Walter Cunha Tecnologia da Informação Redes WAN Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é uma tecnologia de transmissão de dados que (A) opera no nível 3 do modelo OSI. (B) tem velocidade

Leia mais

Protocolo de Sinalização SIP

Protocolo de Sinalização SIP Protocolos de Sinalização Protocolos com processamento distribuído e clientes/terminais inteligentes SIP - Session Initiation Protocol, desenvolvido pelo IETF para comunicação multimídia pela Internet

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

SIP Session Initiation Protocol

SIP Session Initiation Protocol SIP Session Initiation Protocol Pedro Silveira Pisa Redes de Computadores II 2008.2 Professores: Luís Henrique Maciel Kosmalski Costa Otto Carlos Muniz Bandeira Duarte Outubro de 2008 Índice Introdução

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

Camadas de Transporte, Sessão & Apresentação. Função. Camadas REDES x TRANSPORTE. Redes de Computadores Prof. Leandro C. Pykosz

Camadas de Transporte, Sessão & Apresentação. Função. Camadas REDES x TRANSPORTE. Redes de Computadores Prof. Leandro C. Pykosz Camadas de Transporte, Sessão & Apresentação Redes de Computadores Prof. Leandro C. Pykosz Função A camada de Transporte fica entre as camadas de nível de aplicação (camadas 5 a 7) e as de nível físico

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

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 915 VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP Paulo C. Siécola 1, Fabio Kon 1 1 Departamento

Leia mais

3 Gerenciamento de Mobilidade

3 Gerenciamento de Mobilidade Gerenciamento de Mobilidade 38 3 Gerenciamento de Mobilidade A Internet não foi originalmente projetada para suportar a mobilidade de dispositivos. A infra-estrutura existente e o conjunto dos principais

Leia mais

Estado de Santa Catarina Prefeitura de São Cristóvão do Sul

Estado de Santa Catarina Prefeitura de São Cristóvão do Sul 1 ANEXO VII QUADRO DE QUANTITATIVOS E ESPECIFICAÇÕES DOS ITENS Item Produto Quantidade 1 Aparelhos IP, com 2 canais Sip, visor e teclas avançadas, 2 70 portas LAN 10/100 2 Servidor com HD 500G 4 GB memória

Leia mais

CAMADA DE REDE. UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN

CAMADA DE REDE. UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN CAMADA DE REDE UD 2 Aula 3 Professor João Carneiro Arquitetura de Redes 1º e 2º Semestres UNIPLAN Modelo de Referência Híbrido Adoção didática de um modelo de referência híbrido Modelo OSI modificado Protocolos

Leia mais

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR Instituto Superior Técnico Projecto VoIP Sistema IVVR 68239 Rui Barradas 68477 Helton Miranda 68626 Ludijor Barros 72487 Bruna Gondin Introdução O objectivo deste projecto é desenvolver um sistema de Interactive

Leia mais

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO GÜNTER FISCHBORN IMPLEMENTAÇÃO DE QOS E MONITORAMENTO DE TRÁFEGO

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

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento IP 1 História e Futuro do TCP/IP O modelo de referência TCP/IP foi desenvolvido pelo Departamento de Defesa dos Estados Unidos (DoD). O DoD exigia

Leia mais

AGENTE PROFISSIONAL - ANALISTA DE REDES

AGENTE PROFISSIONAL - ANALISTA DE REDES Página 1 CONHECIMENTO ESPECÍFICO 01. Suponha um usuário acessando a Internet por meio de um enlace de 256K bps. O tempo mínimo necessário para transferir um arquivo de 1M byte é da ordem de A) 4 segundos.

Leia mais

Aula 03 Regras de Segmentação e Switches

Aula 03 Regras de Segmentação e Switches Disciplina: Dispositivos de Rede II Professor: Jéferson Mendonça de Limas 4º Semestre Aula 03 Regras de Segmentação e Switches 2014/1 19/08/14 1 2de 38 Domínio de Colisão Os domínios de colisão são os

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - QoS e Engenharia de Tráfego www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução Em oposição ao paradigma best-effort (melhor esforço) da Internet, está crescendo

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

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

Arquiteturas de Rede. Prof. Leonardo Barreto Campos

Arquiteturas de Rede. Prof. Leonardo Barreto Campos Arquiteturas de Rede 1 Sumário Introdução; Modelo de Referência OSI; Modelo de Referência TCP/IP; Bibliografia. 2/30 Introdução Já percebemos que as Redes de Computadores são bastante complexas. Elas possuem

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

Modelo de Camadas OSI

Modelo de Camadas OSI Modelo de Camadas OSI 1 Histórico Antes da década de 80 -> Surgimento das primeiras rede de dados e problemas de incompatibilidade de comunicação. Década de 80, ISO, juntamente com representantes de diversos

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

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

Curso Firewall. Sobre o Curso de Firewall. Conteúdo do Curso

Curso Firewall. Sobre o Curso de Firewall. Conteúdo do Curso Curso Firewall Sobre o Curso de Firewall Este treinamento visa prover conhecimento sobre a ferramenta de Firewall nativa em qualquer distribuição Linux, o "iptables", através de filtros de pacotes. Este

Leia mais

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Marcos R. Dillenburg Gerente de P&D da Novus Produtos Eletrônicos Ltda. (dillen@novus.com.br) As aplicações de

Leia mais

Modelo de referência OSI. Modelo TCP/IP e Internet de cinco camadas

Modelo de referência OSI. Modelo TCP/IP e Internet de cinco camadas Modelo de referência OSI. Modelo TCP/IP e Internet de cinco camadas Conhecer os modelo OSI, e TCP/IP de cinco camadas. É importante ter um padrão para a interoperabilidade entre os sistemas para não ficarmos

Leia mais

Redes de Computadores e Teleinformática. Zacariotto 4-1

Redes de Computadores e Teleinformática. Zacariotto 4-1 Redes de Computadores e Teleinformática Zacariotto 4-1 Agenda da aula Introdução Redes de computadores Redes locais de computadores Redes de alto desempenho Redes públicas de comunicação de dados Computação

Leia mais

MÓDULO 8 Modelo de Referência TCP/IP

MÓDULO 8 Modelo de Referência TCP/IP MÓDULO 8 Modelo de Referência TCP/IP A internet é conhecida como uma rede pública de comunicação de dados com o controle totalmente descentralizado, utiliza para isso um conjunto de protocolos TCP e IP,

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: Gládston Duarte

Professor: Gládston Duarte Professor: Gládston Duarte INFRAESTRUTURA FÍSICA DE REDES DE COMPUTADORES Computador Instalação e configuração de Sistemas Operacionais Windows e Linux Arquiteturas físicas e lógicas de redes de computadores

Leia mais

Protocolos Multimídia. Alunos: Roberto Schemid Rafael Mansano

Protocolos Multimídia. Alunos: Roberto Schemid Rafael Mansano Alunos: Roberto Schemid Rafael Mansano Exemplos de Aplicações Multimídia Mídia Armazenada: conteúdo gravado e armazenado play/pause/rewind/forward Streaming : vê o conteúdo enquanto baixa o arquivo evita

Leia mais

QoS em roteadores Cisco

QoS em roteadores Cisco QoS em roteadores Cisco Alberto S. Matties 1, André Moraes 2 1 Curso Superior de Tecnologia em Redes de Computadores Rua Gonçalves Chaves 602 96.015-000 Pelotas RS Brasil 2 FACULDADE DE TECNOLOGIA SENAC

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

VOIP: Um Estudo de Caso Utilizando o Servidor Stun

VOIP: Um Estudo de Caso Utilizando o Servidor Stun VOIP: Um Estudo de Caso Utilizando o Servidor Stun Fabrício José Rodrigues Costa 1, Luis Augusto Mattos Mendes 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

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

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

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Prof. Luís Rodolfo Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Redes de computadores e telecomunicação Objetivos da Unidade III Apresentar as camadas de Transporte (Nível 4) e Rede (Nível 3) do

Leia mais

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro)

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro) 1 HTVix HA 211 1. Interfaces Entrada de alimentação 12VDC / 500mA (Positivo no centro) Conector RJ11 para conexão de aparelho telefônico analógico ou o adaptador para telefone e rede de telefonia convencional

Leia mais

Capítulo 7 CAMADA DE TRANSPORTE

Capítulo 7 CAMADA DE TRANSPORTE Capítulo 7 CAMADA DE TRANSPORTE SERVIÇO SEM CONEXÃO E SERVIÇO ORIENTADO À CONEXÃO Serviço sem conexão Os pacotes são enviados de uma parte para outra sem necessidade de estabelecimento de conexão Os pacotes

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Ementa Introdução a Redes de

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

Comunicação interligando vidas

Comunicação interligando vidas Comunicação interligando vidas APRESENTAÇÃO E PROPOSTA COMERCIAL 1. INTRODUÇÃO O presente documento contém o projeto técnico comercial para prestação dos serviços de locação, suporte, consultorias da área

Leia mais

ALGUNS CONCEITOS. Rede de Computadores

ALGUNS CONCEITOS. Rede de Computadores ALGUNS CONCEITOS Rede de Computadores Prof. Airton Ribeiro de Sousa E-mail: airton.ribeiros@gmail.com 1 OBJETIVO 1. Compartilhar recursos computacionais disponíveis sem considerar a localização física

Leia mais

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet:

Há dois tipos de configurações bidirecionais usados na comunicação em uma rede Ethernet: Comunicação em uma rede Ethernet A comunicação em uma rede local comutada ocorre de três formas: unicast, broadcast e multicast: -Unicast: Comunicação na qual um quadro é enviado de um host e endereçado

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

SIP Session Initiation Protocol

SIP Session Initiation Protocol Session Initiation Protocol Carlos Gustavo A. da Rocha Session Initiation Protocol Desenvolvido pelo IETF RFC 2543 (Fev 1999) RFC 3261 (Jun 2002) É um protocolo de sinalização para sessões multimídia Negociação;

Leia mais

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br

FACULDADE PITÁGORAS. Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br FACULDADE PITÁGORAS DISCIPLINA FUNDAMENTOS DE REDES REDES DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br Material elaborado com base nas apresentações

Leia mais

Unidade 2.1 Modelos de Referência. Bibliografia da disciplina. Modelo OSI. Modelo OSI. Padrões 18/10/2009

Unidade 2.1 Modelos de Referência. Bibliografia da disciplina. Modelo OSI. Modelo OSI. Padrões 18/10/2009 Faculdade INED Unidade 2.1 Modelos de Referência Curso Superior de Tecnologia: Redes de Computadores Disciplina: Fundamentos de Redes Prof.: Fernando Hadad Zaidan 1 2 Bibliografia da disciplina Bibliografia

Leia mais

Por Érica Barcelos Fevereiro, 2012

Por Érica Barcelos Fevereiro, 2012 Por Érica Barcelos Fevereiro, 2012 2 INTRODUÇÃO Com a informatização dos sistemas nas empresas veio também o aumento da competitividade e isso fez com que a qualidade dos serviços fosse questionada. O

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

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

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 2 - MODELO DE REFERÊNCIA TCP (RM TCP) 1. INTRODUÇÃO O modelo de referência TCP, foi muito usado pela rede ARPANET, e atualmente usado pela sua sucessora, a Internet Mundial. A ARPANET é de grande

Leia mais

MODELOS DE QUALIDADE DE SERVIÇO - APLICAÇÕES EM IP

MODELOS DE QUALIDADE DE SERVIÇO - APLICAÇÕES EM IP MODELOS DE QUALIDADE DE SERVIÇO - APLICAÇÕES EM IP Nilton Alves Júnior naj@cbpf.br Kelly Soyan Pires Dominguez kelly@cbpf.br Resumo Este trabalho tem como função explicitar o conceito de Qualidade de Serviço

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES Conteúdo 1 Topologia de Redes 5 Escalas 5 Topologia em LAN s e MAN s 6 Topologia em WAN s 6 2 Meio Físico 7 Cabo Coaxial 7 Par Trançado 7 Fibra Óptica 7 Conectores 8 Conector RJ45 ( Par trançado ) 9 Conectores

Leia mais

APLICABILIDADE DE QoS NOS RECURSOS DE TELECOMUNICAÇÕES EM AMBIENTES CORPORATIVOS

APLICABILIDADE DE QoS NOS RECURSOS DE TELECOMUNICAÇÕES EM AMBIENTES CORPORATIVOS Encontro de Ensino, Pesquisa e Extensão, Presidente Prudente, 22 a 25 de outubro, 2012 81 APLICABILIDADE DE QoS NOS RECURSOS DE TELECOMUNICAÇÕES EM AMBIENTES CORPORATIVOS Luiz Eduardo de Castilho Junior,

Leia mais

OpenFlow: abrindo portas para inovações nas redes de nossos campi

OpenFlow: abrindo portas para inovações nas redes de nossos campi 1 OpenFlow: abrindo portas para inovações nas redes de nossos campi Leandro Haruo Aoyagi Universidade Federal de São Carlos, Campus Sorocaba Sorocaba, São Paulo Email: aoyagi.haruo@gmail.com Resumo A comunidade

Leia mais

2 Fundamentação Conceitual

2 Fundamentação Conceitual Fundamentação Conceitual 19 2 Fundamentação Conceitual Este capítulo apresenta alguns conceitos importantes que são utilizados ao longo do trabalho. Primeiramente, é apresentado o Session Initiation Protocol

Leia mais

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0 CA Nimsoft Monitor Guia do Probe Monitoramento de conectividade de rede net_connect série 3.0 Aviso de copyright do CA Nimsoft Monitor Este sistema de ajuda online (o Sistema ) destina-se somente para

Leia mais

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões FACSENAC ECOFROTA Documento de Projeto Lógico de Rede Versão:1.5 Data: 21/11/2013 Identificador do documento: Projeto Lógico de Redes Versão do Template Utilizada na Confecção: 1.0 Localização: FacSenac

Leia mais

Prof. Marcelo Cunha Parte 5 www.marcelomachado.com

Prof. Marcelo Cunha Parte 5 www.marcelomachado.com Prof. Marcelo Cunha Parte 5 www.marcelomachado.com Criado em 1974 Protocolo mais utilizado em redes locais Protocolo utilizado na Internet Possui arquitetura aberta Qualquer fabricante pode adotar a sua

Leia mais

1 Lista de exercícios 01

1 Lista de exercícios 01 FRANCISCO TESIFOM MUNHOZ 2007 1 Lista de exercícios 01 1) No desenvolvimento e aperfeiçoamento realizado em redes de computadores, quais foram os fatores que conduziram a interconexão de sistemas abertos

Leia mais

Uc-Redes Técnico em Informática André Luiz Silva de Moraes

Uc-Redes Técnico em Informática André Luiz Silva de Moraes Roteiro 2: Conceitos Básicos de Redes: parte 1 Neste roteiro são detalhados os equipamentos componentes em uma rede de computadores. Em uma rede existem diversos equipamentos que são responsáveis por fornecer

Leia mais

tendências Unificada Comunicação Dezembro/2012 INFORMATIVO TECNOLÓGICO DA PRODESP EDIÇÃO 05 Introdução Como Implementar Quais as Vantagens

tendências Unificada Comunicação Dezembro/2012 INFORMATIVO TECNOLÓGICO DA PRODESP EDIÇÃO 05 Introdução Como Implementar Quais as Vantagens tendências EDIÇÃO 05 Dezembro/2012 Comunicação Unificada Introdução Como Implementar Quais as Vantagens Componentes das Comunicações Unificadas 02 04 05 06 Introdução Nos últimos anos, as tecnologias para

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Capítulo 1 Gustavo Reis gustavo.reis@ifsudestemg.edu.br - O que é a Internet? - Milhões de elementos de computação interligados: hospedeiros = sistemas finais - Executando aplicações

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Protocolo. O que é um protocolo? Humano: que horas são? eu tenho uma pergunta

Protocolo. O que é um protocolo? Humano: que horas são? eu tenho uma pergunta Protocolo O que é um protocolo? Humano: que horas são? eu tenho uma pergunta Máquina: Definem os formatos, a ordem das mensagens enviadas e recebidas pelas entidades de rede e as ações a serem tomadas

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

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP Visão Geral As redes convergentes trilharam um longo caminho desde a década de 1990. Novas aplicações, como as mensagens instantâneas,

Leia mais

Um pouco sobre Pacotes e sobre os protocolos de Transporte

Um pouco sobre Pacotes e sobre os protocolos de Transporte Um pouco sobre Pacotes e sobre os protocolos de Transporte O TCP/IP, na verdade, é formado por um grande conjunto de diferentes protocolos e serviços de rede. O nome TCP/IP deriva dos dois protocolos mais

Leia mais

Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus

Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus Uso de Virtual Lan (VLAN) para a disponibilidade em uma Rede de Campus Edson Rodrigues da Silva Júnior. Curso de Redes e Segurança de Sistemas Pontifícia Universidade Católica do Paraná Curitiba, Fevereiro

Leia mais

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway Introdução Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores Protocolos ARP e ICMP Aula 18 A camada de rede fornece um endereço lógico Uniforme, independente da tecnologia empregada pelo enlace

Leia mais

Camada de Rede. Prof. Leonardo Barreto Campos 1

Camada de Rede. Prof. Leonardo Barreto Campos 1 Camada de Rede Prof. Leonardo Barreto Campos 1 Sumário Introdução; Internet Protocol IP; Fragmentação do Datagrama IP; Endereço IP; Sub-Redes; CIDR Classes Interdomain Routing NAT Network Address Translation

Leia mais

1.1 Motivação e âmbito... 1 1.2 Objetivos e abordagem... 3 1.3 Organização do presente texto... 4

1.1 Motivação e âmbito... 1 1.2 Objetivos e abordagem... 3 1.3 Organização do presente texto... 4 Índice de figuras XVII Índice de tabelas XXII Agradecimentos XXIII Nota prévia XXIV 1- Introdução 1 1.1 Motivação e âmbito... 1 1.2 Objetivos e abordagem... 3 1.3 Organização do presente texto... 4 2 -

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Motivação Realidade Atual Ampla adoção das diversas tecnologias de redes de computadores Evolução das tecnologias de comunicação Redução dos

Leia mais

Interconexão de redes locais. Repetidores. Pontes (Bridges) Hubs. Pontes (Bridges) Pontes (Bridges) Existência de diferentes padrões de rede

Interconexão de redes locais. Repetidores. Pontes (Bridges) Hubs. Pontes (Bridges) Pontes (Bridges) Existência de diferentes padrões de rede Interconexão de redes locais Existência de diferentes padrões de rede necessidade de conectá-los Interconexão pode ocorrer em diferentes âmbitos LAN-LAN LAN: gerente de um determinado setor de uma empresa

Leia mais

SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL. Curso Técnico em Informática

SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL. Curso Técnico em Informática SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL Curso Técnico em Informática Estrutura de Endereçamento IP e Mascara de Subrede Endereçamento IP e Classes Autoridade para Atribuição de Números da Internet http://www.iana.org/

Leia mais

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais

Uc-Redes Técnico em Informática André Luiz Silva de Moraes

Uc-Redes Técnico em Informática André Luiz Silva de Moraes Roteiro 2: Conceitos Básicos de Redes: parte 1 Neste roteiro são detalhados os equipamentos componentes em uma rede de computadores. Em uma rede existem diversos equipamentos que são responsáveis por fornecer

Leia mais

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação 1 Introdução à Camada de Transporte Camada de Transporte: transporta e regula o fluxo de informações da origem até o destino, de forma confiável.

Leia mais

Documento: Treinamentos pfsense Versão do documento: 2014. Treinamentos pfsense. Página 1 de 10

Documento: Treinamentos pfsense Versão do documento: 2014. Treinamentos pfsense. Página 1 de 10 Treinamentos pfsense Página 1 de 10 Definições, Acrônimos e Abreviações Abreviação / Sigla WAN LAN UTM pfsense BGP Descrição Wide Area Network - Rede de longa distância (interface de rede para links de

Leia mais

NETALARM GATEWAY. Manual do Usuário

NETALARM GATEWAY. Manual do Usuário Índice 1. Introdução...3 2. Requisitos Mínimos de Instalação...3 3. Instalação...3 4. Inicialização do Programa...5 5. Abas de Configuração...6 5.1 Aba Serial...6 5.2 Aba TCP...7 5.2.1 Opções Cliente /

Leia mais

Unidade 2.1 Modelos de Referência

Unidade 2.1 Modelos de Referência Faculdade INED Curso Superior de Tecnologia: Banco de Dados Redes de Computadores Disciplina: Redes de Computadores Prof.: Fernando Hadad Zaidan 1 Unidade 2.1 Modelos de Referência 2 Bibliografia da disciplina

Leia mais

Rede GlobalWhitepaper

Rede GlobalWhitepaper Rede GlobalWhitepaper Janeiro 2015 Page 1 of 8 1. Visão Geral...3 2. Conectividade Global, qualidade do serviço e confiabilidade...4 2.1 Qualidade Excepcional...4 2.2 Resiliência e Confiança...4 3. Terminais

Leia mais

Autenticação modo Roteador. Após finalizar a configuração, seu computador obterá o IP e a página de configuração do ATA poderá ser acessada.

Autenticação modo Roteador. Após finalizar a configuração, seu computador obterá o IP e a página de configuração do ATA poderá ser acessada. 2. Conecte a porta WAN do GKM 2210 T ao seu acesso à internet (porta ethernet do modem). O LED WAN acenderá; 3. Conecte a porta LAN à placa de rede do PC. O LED LAN acenderá; 4. Conecte o(s) telefone(s)

Leia mais

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

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula Complementar - EQUIPAMENTOS DE REDE 1. Repetidor (Regenerador do sinal transmitido) É mais usado nas topologias estrela e barramento. Permite aumentar a extensão do cabo e atua na camada física

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

CONHECIMENTOS ESPECÍFICOS

CONHECIMENTOS ESPECÍFICOS CONHECIMENTOS ESPECÍFICOS Acerca das características da arquitetura dos computadores que Julgue os itens a seguir, acerca de sistemas operacionais. devem ser consideradas no projeto e na implantação de

Leia mais

Intelbras GKM 2210T. 1. Instalação

Intelbras GKM 2210T. 1. Instalação 1 Intelbras GKM 2210T 1. Instalação 1º Conecte a fonte de alimentação na entrada PWR, o LED Power acenderá; 2º Conecte a porta WAN do GKM 2210 T ao seu acesso à internet (porta ethernet do modem). O LED

Leia mais

Maestro. Arthur Kazuo Tojo Costa 317497. Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação

Maestro. Arthur Kazuo Tojo Costa 317497. Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação Maestro Arthur Kazuo Tojo Costa 317497 Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação Introdução Sistema Operacional de Redes Detalhes do hardware Multiplexação

Leia mais

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s):

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s): Professor(es): Fernando Pirkel Descrição da(s) atividade(s): Definir as tecnologias de redes necessárias e adequadas para conexão e compartilhamento dos dados que fazem parte da automatização dos procedimentos

Leia mais

REDES HETEROGENEAS E CONVERGENTES

REDES HETEROGENEAS E CONVERGENTES 26/07/12 09:56 REDES HETEROGENEAS E CONVERGENTES das vantagens das redes convergentes valor agregado B) simplicidade C) praticidade D) operacionalização E) manutenção das vantagens do VoIP manutenção de

Leia mais

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Material de apoio 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura

Leia mais

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

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 5-1. A CAMADA DE TRANSPORTE Parte 1 Responsável pela movimentação de dados, de forma eficiente e confiável, entre processos em execução nos equipamentos conectados a uma rede de computadores, independentemente

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