TARCISIO DO NASCIMENTO ARAUJO MODELO DE GERENCIAMENTO DE REDES VIRTUAIS EM AMBIENTE OPENFLOW

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

Download "TARCISIO DO NASCIMENTO ARAUJO MODELO DE GERENCIAMENTO DE REDES VIRTUAIS EM AMBIENTE OPENFLOW"

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO TARCISIO DO NASCIMENTO ARAUJO MODELO DE GERENCIAMENTO DE REDES VIRTUAIS EM AMBIENTE OPENFLOW Rio de Janeiro 2015

2 INSTITUTO MILITAR DE ENGENHARIA TARCISIO DO NASCIMENTO ARAUJO MODELO DE GERENCIAMENTO DE REDES VIRTUAIS EM AMBIENTE OPENFLOW Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção do título de Mestre em Sistemas e Computação. Orientador: Prof. Ronaldo Moreira Salles - Ph.D. Rio de Janeiro 2015

3 c2015 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80-Praia Vermelha Rio de Janeiro-RJ CEP Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluílo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do autor e do orientador. XXXXXAraujo, T. N. Modelo de Gerenciamento de Redes Virtuais em Ambiente OpenFlow/ Tarcisio do Nascimento Araujo, orientado por Ronaldo Moreira salles - Rio de Janeiro: Instituto Militar de Engenharia, p.: il., tab. Dissertação (mestrado) Instituto Militar de Engenharia Rio de Janeiro, Redes Virtuais. 2. OpenFlow. 3.FlowVisor I. Modelo de Gerenciamento de Redes Openflow. II. Instituto Militar de Engenharia. CDD xxx.xxx 2

4 INSTITUTO MILITAR DE ENGENHARIA TARCISIO DO NASCIMENTO ARAUJO MODELO DE GERENCIAMENTO DE REDES VIRTUAIS EM AMBIENTE OPENFLOW Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção do título de Mestre em Sistemas e Computação. Orientador: Prof. Ronaldo Moreira Salles - Ph.D. Aprovada em 26 de janeiro de 2015 pela seguinte Banca Examinadora: Prof. Ronaldo Moreira Salles - Ph.D. do IME - Presidente Prof. Carlos Alberto Vieira Campos - D.Sc. da UNIRIO Prof a. Raquel Coelho Gomes Pinto - D.Sc. do IME Rio de Janeiro

5 À minha família 4

6 AGRADECIMENTOS Agradeço em primeiro lugar a Deus que me fortaleceu durante esta jornada e todas as outras de minha vida. Aos meus pais Adelino (in memoriam) e Maria Augusta, pelo amor com que me educaram, e pelo apoio ao longo de todos os meus anos de vida, minha eterna gratidão. A minha esposa Juciara pela compreensão e apoio nos momentos em que este trabalho foi priorizado. A Vitória e Samuel, meus filhos, pelo amor e paciência, mesmo sem entender o que seu pai estava fazendo. Agradeço a todas as pessoas que contribuíram com o desenvolvimento desta dissertação de mestrado, tenha sido por meio de críticas, idéias, apoio, incentivo ou qualquer outra forma de auxílio. Em especial, desejo agradecer aos companheiros de estudo Andres Velastegui e Kananda, pelo apoio no trabalho de programação, fundamental para a pesquisa desenvolvida. E ao meu irmão Tiago, pelo apoio na redação dos artigos na língua inglesa Agradeço ao meu orientador, Prof. Ronaldo Moreira Salles, pelo apoio e orientação na elaboração deste trabalho, sempre de maneira clara e objetiva. Por fim, ao Exército Brasileiro por me proporcionar essa oportunidade de crescimento profissional. E a todos os professores e funcionários da Seção de Engenharia da Computação (SE/8) do Instituto Militar de Engenharia. Tarcisio do Nascimento araujo 5

7 Consagre ao Senhor tudo o que você faz, e os seus planos serão bem sucedidos. Provérbios 16.3 Bíblia Sagrada 6

8 SUMÁRIO LISTA DE ILUSTRAÇÕES LISTA DE TABELAS LISTA DE ABREVIATURAS E SÍMBOLOS INTRODUÇÃO Motivação Objetivo do Trabalho Contribuição Organização da Dissertação REVISÃO DA LITERATURA E TRABALHOS RELACIONADOS Gerenciamento de redes Modelo funcional Sistema para Gerenciamento de rede Monitoração da rede Métricas de desempenho Latency or Delay (Latência ou Retardo): Packet Loss (Perda de pacotes): Jiter (Variação do retardo): Bandwidth (Largura de banda): Available Network (Disponibilidade da rede): Qualidade de Serviço em Rede de Computadores Principais arquiteturas para o provimento de Qualidade de Serviço IntServ DiffServ Acordo de Nível de Serviço (Service Level Agreement - SLA) Qualidade de Experiência (Quality of Experience - QoE) Mapeamento da QoE em parâmetros de QoS Tipos de aplicação quanto a demanda de transmissão Redes Virtualizadas

9 2.2.1 Redes Locais Virtuais (VLANs) Redes Privadas Virtuais (VPNs) Redes de sobreposição (Overlay) Redes Definidas por software Ambiente OpenFlow Principais Componentes Funcionamento Simulador para Ambiente OpenFlow Controlador Floodlight Virtualização Trabalhos relacionados MODELO DE GERENCIAMENTO PROPOSTO Premissas modelo de avaliação do slice critérios para ajustar o desempenho do slice Largura de banda Latência Disponibilidade da rede GIROFLOW Arquitetura Base de Dados Módulos Módulo Configuration management: Módulo Fault management: Módulo Accounting management Módulo Performance management Parametrização Ferramentas utilizadas no desenvolvimento RESULTADOS Ambiente de teste Cenários

10 5.2.1 Cenário 01: Cenário 02: Experimentos Experimento 01: Validação das Interfaces Experimento 02: Análise de performance de 01 (um) slice Avaliação do Experimento Experimento 03: Análise de performance de 02 (dois) slices em conjunto Avaliação do Experimento Comparação com outras soluções CONSIDERAÇÕES FINAIS Utilização do Modelo Trabalhos futuros REFERÊNCIAS BIBLIOGRÁFICAS

11 LISTA DE ILUSTRAÇÕES FIG.2.1 Esquema de funcionamento do Sistema de gerenciamento (KUROSE, 2012) FIG.2.2 Funções DiffServ (KUROSE, 2012) FIG.2.3 Gerenciamento de QoE/QoS adaptado de LIMA (2011) FIG.2.4 Esquema de uma rede Overlay (MIR, 2006) FIG.2.5 arquitetura SDN (KREUTZ, 2014) FIG.2.6 Componentes OpenFlow (MCKEOWN, 2008) FIG.2.7 Tabela de Fluxos adaptado de CONSORTIUM (2011) e MCKEOWN (2008) FIG.2.8 Funcionamento do FlowVisor (SHERWOOD, 2009) FIG.3.1 Algoritmo 1 para ajuste a largura de Banda FIG.3.2 Algoritmo 2 para analisar policies do slice por latência FIG.3.3 Algoritmo 3 para analisar policies do slice por disponibilidade da rede FIG.4.1 Arquitetura GiroFlow Camada FIG.4.2 Arquitetura GiroFlow Interfaces FIG.4.3 Diagrama de Entidade e Relacionamento FIG.4.4 Tela do módulo Configuration management FIG.4.5 Tela do Módulo Fault managemnt FIG.4.6 Tela do Módulo Accounting management FIG.4.7 Tela do Módulo Performance management FIG.5.1 Rede com 01 controlador FIG.5.2 Rede com 02 controlador FIG.5.3 Comparação das soluções utilizadas

12 LISTA DE TABELAS TAB.2.1 Mean Opinion Score - MOS (RIBEIRO, 2011) TAB.2.2 ações do fluxo adaptado de CONSORTIUM (2011) TAB.2.3 Principais Controladores OpenFlow TAB.2.4 Tipos de Mensagem trocada entre controlador e os dispositivos de rede (CONSORTIUM, 2011) TAB.3.1 Relação do tipos de aplicações com as métricas de desempenho TAB.3.2 nível de atendimento do slice por métrica de desempenho da rede TAB.3.3 Índice de atendimento da Aplicação TAB.5.1 Análise desempenho do slice TAB.5.2 Análise desempenho do slice - Ajuste da largura de banda TAB.5.3 Análise desempenho do slice - Ajuste da Disponibilidade da rede TAB.5.4 Índice de disponibilidade de datapaths TAB.5.5 Análise desempenho do slice Internet TAB.5.6 Análise desempenho do slice VideoConferencia TAB.5.7 Análise desempenho do slice VideoConferencia - Ajuste da largura de banda TAB.5.8 Análise desempenho do slice Internet - Ajuste da Disponibilidade TAB.5.9 Trabalhos analisados

13 LISTA DE ABREVIATURAS E SÍMBOLOS ABREVIATURAS ANSI - American National Standard Institute API - Aplication Programming Inteface BE - Best Effort CAIDA - Center for Applied Internet Data Analysis CCITT - Comite Consultaif International Telephonique et Telegraphique CMIP - Common Management Information Protocol DiffServ - Differentiated Services DS - Differentiated Services DSCP - Differentiated Services Code Point FTP - File Transfer Protocol ICMP - Internet Control Message Protocol IEEE - Institute of Electrical Electronics Engineers IETF - Internet Engineering Task Force IntServ - Integrated Services IP - Internet Protocol IPPM - Internet Protocol Performance Metrics ISO - International Organization for Standardization ITU-T - International Telecommunucation Union - Telecommunication Kbps - Kilo Bits per second Mbps - Mbps Mega bits per second MIB - Management Information Base MTBF - Mean Time Between Failures MTTF - Mean Time To Failure MTTR - Mean Time To Repair MOS - Meam Opinion Score NOC - Network Operations Center PHB - Per-Hop-Behavior PHB-AF - Per-Hop-Behavior - Assured Forwarding PHB-EF - Per-Hop-Behavior - Expedited Forwarding 12

14 QoE - Quality of Experience QoS - Quality of Service RSVP - Resource ReSerVation Protocol RTT - Round Trip Time SDN - Redes Definidas por Software SGDB - Sistema Gerenciador de Banco de Dados SIP - Session Initiation Protocol SNMP - Simple Network Management Protocol SLA - Service Level Agreement SLO - Service Level Objective SSL - Secure Socket Layer TCP - Transmission Control Protocol ToS - Type of service TNM - Telecommunication Management Network UDP - User Datagram Protocol WAN - Wide Area Network 13

15 RESUMO Uma das principais propostas para o desenvolvimento de soluções para a internet do futuro e que apresenta menor impacto no tráfego em produção é a virtualização de rede. Dentro desse paradigma destacam-se as Redes Definidas por Software (SDN ), redes que tem como principal inovação a separação dos planos de controle e dados, viabilizando a programação dos equipamentos e não apenas a sua configuração como nas redes tradicionais. Neste sentido a tecnologia OpenFlow apresenta-se como uma das mais promissoras e com maior utilização dentro das soluções apoiadas no paradigma SDN. Sua arquitetura tem como característica a figura do controlador, responsável por definir a maneira como os pacotes devem ser tratados, proporcionando um gerenciamento central de toda a rede. Dentro da tecnologia OpenFlow existe um controlador de propósito especial chamado FlowVisor que permite a divisão das capacidades dos dispositivos de rede, através da criação de slices, que viabilizam o funcionamento de diversas redes virtuais sobre uma mesma infraestrutura física, apoiada na implantação de regras para o encaminhamento dos pacotes junto aos controladores OpenFlow e dos dispositivos de rede. Contudo, o FlowVisor possui uma limitação na sua arquitetura relacionada a ausência de um modelo específico para o gerenciamento dos slices (redes virtuais). Deste modo, este trabalho apresenta um modelo para o gerenciamento dos slices com foco nas características de transmissão dos dados da aplicação em operação na rede, utilizando-se de interfaces automatizadas com o próprio FlowVisor e os controladores em funcionamento na rede para criação e ajuste dos slices e das suas policies (topologias) dentro de uma rede gerenciada pelo FlowVisor. 14

16 ABSTRACT One of the main proposals for developing solutions for the future of the internet is network virtualization, which has less impact on traffic. Within that paradigm, Software Defined Networks (SDN ) stand out as networks that have two main innovations: separation of data and control planes. These innovations enable programming of the equipment and not just its configuration, as in the case of a traditional network. OpenFlow technology appears to be one of the most promising solutions with greater use of supported solutions within the SDN paradigm. Its architecture is characterized by the controller, responsible for defining how the package should be treated and providing central management of the entire network. The technology within the OpenFlow controller includes a special purpose called FlowVisor. It allows the division of the network device capacities by creating slices that enable multiple virtual networks to run on the same physical infrastructure, based on the deployment of rules for routing the packets together with the OpenFlow controllers and network devices. However, FlowVisor has limitation in its architecture related to the lack of a specific model for managing the slices (virtual networks). This work presents a model for management of the slices focusing on the properties of data transmission the application running on the network. It also uses automated interfaces with FlowVisor and Network Controllers for creating and adjusting the slices and policies (tolology) in a network managed by FlowVisor. 15

17 1 INTRODUÇÃO A Internet está baseada na generalidade e heterogeneidade da arquitetura em camadas, ou seja, a mesma é composta de diversificados dispositivos que podem se interconectar de várias modos (independência de camadas). Seu núcleo é formado por computadores com alta capacidade computacional o que a torna transparente e simples, já os equipamentos de borda possuem uma diversidade de funcionalidades para os seus usuários. Além disso, a interligação de diversos Sistemas Autônomos tornam a administração da Internet descentralizada. Esse núcleo simples funcionando com base no princípio Best Effort, melhor esforço, não tem como fornecer informação sobre o funcionamento da rede, dificultando a depuração de problemas nas aplicações e serviços em funcionamento, levando muitas vezes a realização de configurações específicas e adaptações manuais. E, consequentemente, a complexidade cada vez maior no projeto de aplicações novas. Todos esses fatores têm levado a infraestrutura da Internet a uma situação intitulada por diversos pesquisadores como Calcificação (CLARK, 2005). Esses obstáculos levaram a comunidade científica a pensar em novas propostas para atender a essas demandas, o que colabora com a ideia da criação de uma nova Internet (ANDERSON, 2005). Dentro desta perspectiva duas linhas de pesquisa estão sendo discutidas e investigadas. A primeira abordagem chamada de Purista ou Evolucionária, está baseada na ideia principal de substituir os protocolos atuais por outros, mais flexíveis e adaptáveis às novas demandas e requisitos. Contudo, os mesmos continuaram a ser modelados em uma arquitetura com uma única pilha de protocolos, funcionando sobre a infraestrutura física da rede atual (CROWCROFT, 2003). A segunda abordagem chamada de Pluralista ou Limpa, tem como ideia principal que a Internet deve permitir o funcionamento de diferentes tipos de protocolos simultaneamente, sobre uma mesma infraestrutura física atendendo assim a diferentes tipos de aplicações (CROWCROFT, 2003). Nesse paradigma as técnicas de virtualização constituem-se em peças fundamentais para que as soluções possam coexistir de forma paralela em um modelo de múltiplas camadas. Comparando as duas abordagens podemos observar que a linha Purista possui comple- 16

18 xidade maior em relação a abordagem Pluralista. Pois, sua arquitetura deverá ser capaz de solucionar os problemas atuais da Internet e os futuros. Já o paradigma Pluralista é em certo sentido mais simples de construção, porque sua implantação poderá acontecer de forma gradual por meio de uma nova rede virtual para atender a cada nova aplicação (REXFORD, 2010). Porém, mesmo que tais propostas sejam suficientes para suprir as necessidades, sua implantação é extremamente difícil de ser viabilizada, porque atualmente infraestrutura das redes é parte essencial do funcionamento da sociedade, e o medo de que as mudanças possam causar a interrupção de um determinado serviço, acabam fazendo com que as inovações sejam descartadas pelos administradores face ao risco do insucesso. Essa inflexibilidade na mudança da infraestrutura das Redes, também traz um desafio para os pesquisadores da área, pois seus experimentos muitas vezes não são avaliados de maneira adequada em redes reais. Desse modo, as novas tecnologias são testadas apenas em ambientes virtuais que muitas vezes não fornecem os desafios da realidade de uma rede em produção, inviabilizando assim a implementação de qualquer tipo de invocação. O paradigma de Redes Definidas por Software (SDN) aponta para um caminho que pode vencer esse obstáculo, por meio de uma solução que seja implantada de forma gradativa, e que não cause interferência no ambiente em produção. A arquitetura OpenFlow tem-se apresentado como uma das tecnologias mais promissoras e com a maior utilização dentro das propostas que viabilizam a implantação de soluções no paradigma SDN. Esse sucesso deve-se as características do seu protocolo, que permite de um modo bastante flexível a separação entre o plano de dados 1 e o plano de controle 2, permitindo assim a utilização de controladores 3 baseados nas mais diferentes linguagens de programação. (GREENE, 2009). Dentro do ambiente de soluções OpenFlow existe a ferramenta FlowVisor, um controlador de propósito especial que permite a virtualização do plano de controle dentro da arquitetura OpenFlow. O FlowVisor permite a divisão das capacidades dos dispositivos de rede através da criação de fatias isoladas para as diversas aplicações dos usuários, viabilizando o funcionamento de várias redes virtuais sobre uma mesma infraestrutura física, apoiada na implantação de regras para o encaminhamento dos pacotes conforme a 1 Plano de dados é o responsável por gerenciar a comutação e o repasse dos pacotes. 2 Plano de controle realiza a tomada de decisão estabelecendo as rotas da tabela de encaminhamento. 3 Controlador é uma entidade externa aos dispositivos de rede, responsável por gerenciar plano de controle de todos os dispositivos em operação na rede. 17

19 necessidade das aplicações em funcionamento nos outros controladores existentes na rede (SHERWOOD, 2009). Contudo, o FlowVisor não possui em sua arquitetura, uma ferramenta para o gerenciamento dos slices. 1.1 MOTIVAÇÃO O OpenFlow sozinho não viabiliza o funcionamento de múltiplos experimentos em um único equipamento, sendo necessário uma camada de virtualização que no ambiente Open- Flow é proporcionado pelo FlowVisor. Essa ferramenta permite que tabelas de fluxos de um switch com protocolo OpenFlow sejam compartilhadas por vários usuários, formando redes virtuais chamadas de slices. Entre os recursos disponíveis no FlowVisor destaca-se o mecanismo de isolamento de recursos, que garante o isolamento dos slices na rede, de modo que não haja interferência entre eles. No entanto, o gerenciamento de ambientes que utilizam FlowVisor é um tópico pouco explorado, e aplicações desse tipo não são encontradas com facilidade. Dessa modo, torna-se necessário investigar as necessidades de gerenciamento para esse tipo de ambiente a fim de proporcionar uma melhor operação das redes baseadas nesse ambiente. Outro fator motivador, refere-se a vantagem da rede OpenFlow em comparação a uma rede tradicional, quando tratamos de gerenciamento. Tendo em vista que uma rede Open- Flow o controlador viabiliza um verdadeiro gerenciamento centralizado. Esta característica possibilita o desenvolvimento de modelos que priorizem as demandas de transmissão das aplicações. E, por fim, atender ao interesse do Exército Brasileiro de desenvolver conhecimento específico na área de projeto de redes que aumente a eficácia da infraestrutura existente, e melhore a qualidade de serviços prestados. Conforme objetivo estabelecido na Portaria n o 009-DCT, de 21 MAR 12, código 35M OBJETIVO DO TRABALHO O objetivo desse trabalho é desenvolver um modelo para o gerenciamento de redes virtuais em ambiente OpenFlow, com foco no atendimento das demandas de transmissão das aplicações. Para isso, este trabalho apresenta uma ferramenta para complementar o FlowVisor, que utiliza interfaces automatizadas com os elementos da arquitetura Open- 18

20 Flow. 1.3 CONTRIBUIÇÃO Principal: Um modelo para gerenciamento de redes virtuais com foco no atendimento das demandas de transmissão das aplicações. Secundária: Uma ferramenta para a administração de slices em uma rede gerenciada pelo FlowVisor. 1.4 ORGANIZAÇÃO DA DISSERTAÇÃO O trabalho está organizado da seguinte forma: No capítulo 2 é realizada uma revisão a literatura utilizada na dissertação, bem como os principais trabalhos relacionados a pesquisa desenvolvida. No capítulo 3 é explicado o modelo de gerenciamento proposto. No Capítulo 4 é apresentada a arquitetura da ferramenta desenvolvida, no capítulo 5 todos os experimentos realizados e seus resultados são apresentados. E, finalmente, o Capítulo 6 apresenta as conclusões e trabalhos futuros. 19

21 2 REVISÃO DA LITERATURA E TRABALHOS RELACIONADOS A revisão bibliográfica desta dissertação foi divida em 4 (quatro) partes: (i) gerenciamento de redes, (ii) redes virtuais, (iii) ambiente OpenFlow e, (iv) trabalhos relacionados. 2.1 GERENCIAMENTO DE REDES Segundo SAYDAM (1996) podemos definir gerenciamento de redes como: O oferecimento, a integração e a coordenação de elementos de hardware, software e humanos, para monitorar, testar, consultar, configurar, analisar, avaliar e controlar os recursos da rede, e de elementos, para satisfazer às exigências operacionais, de desempenho e de qualidade de serviço em tempo real a um custo razoável. Além desta definição, também é necessário estabelecer uma separação das funções no processo de gerenciamento. Para isso, foi desenvolvido pela ISO (International Organization for Standardization) em conjunto com CCITT (Comite Consultaif International Telephonique et Telegraphique), atualmente ITU-T (International Telecommunucation Union - Telecommunication), o modelo de gerenciamento OSI que tem como marco inicial a publicação do OSI Management Framework (1989) e do OSI System Management Overview (1992) MODELO FUNCIONAL O Modelo funcional é subdividido em cinco áreas que estabelecem o escopo do sistema para gerenciamento de redes, sendo comumente aceitos pelos fornecedores deste tipo de sistemas, como modelo para definição das necessidades de gerenciamento de rede (KUROSE, 2012). Essas áreas são: Fault Mangement (Gerenciamento de Falhas): Tem como meta identificar, localizar e corrigir problemas no hardware ou software da rede. Falha não é igual a erro. Podemos definir falha como uma condição anormal que necessita de ação de gerenciamento para sua recuperação. Uma falha acontece normalmente por erros 20

22 excessivos ou por operações erradas. Como exemplo podemos citar a interrupção do funcionamento de um enlace. Configuration Mangement (Gerenciamento de Configuração): Tem como objetivo registrar informações sobre o hardware e o software, além do histórico das configurações realizadas nos dispositivos, viabilizando a inicialização dos sistemas da rede, bem como do registro da sua topologia e dos seus equipamentos. Accounting Mangement (Gerenciamento de Contabilização): Tem como tarefa registrar o uso dos recursos da rede por parte dos usuários e de suas aplicações. É realizado através de registros históricos, logs ou bilhetagem. Performance Mangement (Gerenciamento de Desempenho): Tem como missão avaliar o desempenho da rede, através da medição, análise e monitoração constante de variáveis preestabelecidas da rede. E também do controle dos recursos existentes, através de ajustes e trocas dos componentes da rede. Security Mangement (Gerenciamento de Segurança): Tem como objetivo controlar o acesso ao hardware e software da rede, bem como das informações de configuração da rede, de acordo com a política de segurança previamente definida. Como exemplo podemos citar o acesso a senhas e arquivos de configuração SISTEMA PARA GERENCIAMENTO DE REDE Outra definição importante é o conceito de sistema para gerenciamento de rede, que pode ser definido como um conjunto de ferramentas para administrar e monitorar a rede, integrados com base nos seguintes princípios (STALLINGS, 2005): Ter somente uma única interface de operador para executar as tarefas de gerenciamento da rede; E que a maioria do hardware e software necessária para o gerenciamento da rede seja incorporado nos equipamentos gerenciados. Os sistemas para gerenciamento de rede funcionam conforme o esquema da figura 2.1 e possuem os seguintes componentes principais (KUROSE, 2012): 21

23 FIG. 2.1: Esquema de funcionamento do Sistema de gerenciamento (KUROSE, 2012) Entidade Gerenciadora: É uma ferramenta que funciona no NOC 4 (Network Operations Center). Sua tarefa é controlar a coleta, o processamento, a análise, e a disponibilização das informações de gerenciamento. Dispositivo Gerenciado: São os dispositivos da rede bem como os seus objetos gerenciados. Esses objetos podem ser componentes de hardware, por exemplo a memória física ou a placa de uma interface de rede, ou software, como por exemplo o protocolo de roteamento. Agente de gerenciamento: Sua missão é responder as solicitações de informações e de ações da entidade gerenciadora, referente ao dispositivo gerenciado no qual está instalado. Além de fornecer informações importantes de modo assíncrono que não foram solicitadas pela entidade gerenciadora. Base de Informações de Gerenciamento (MIB): São as informações organizadas de modo hierárquico. E expressam diversos tipos de valores que são utilizados para o gerenciamento e a análise das redes de computadores. Protocolo de Gerenciamento: É o protocolo utilizado pela entidade gerenciadora 4 NOC é o local onde é realizado o gerenciamento da operação de uma rede. 22

24 e os dispositivos gerenciados. Esse protocolo permite que a entidade gerenciadora obtenha informações sobre o estado dos dispositivos gerenciados, e possa executar alguma ação, mesmo que de forma indiretamente. Dos protocolos de gerenciamento, o mais utilizado é o SNMP 5 (Simple Network Management Protocol) da IETF (Internet Engineering Task Force). Ele obteve grande aceitação por ser de simples implementação, quando comparado ao CMIP 6 (Common Management Information Protocol) da ISO. O SNMP também utiliza poucos recursos para o seu processamento (COMER, 2006). O protocolo SNMP vem embarcado em praticamente todos os equipamentos de rede fabricados atualmente, isso viabiliza o gerenciamento de diferentes tipos de dispositivos em uma mesma rede de computadores. A comunicação entre gerentes e agentes pode ser implementada pela técnica de Polling, onde a interação gerente e agente é baseada no princípio request/response. Ou seja, o gerente solicita ao agente o envio de informação sobre algum dos elementos, e o agente envia os valores constantes em sua MIB. Já na técnica de event-reporting, a iniciativa da comunicação parte do agente. O gerente então fica na espera pela chegada de informações. E quando solicitado, o agente gera um relatório sobre o estado atual do dispositivo. A frequência desse relatório pode ser configurada previamente pelo gerente. Um agente também pode enviar um relatório quando acontece algum evento não previsto ou que seja relevante (KUROSE, 2012). As técnicas de polling e event-reporting são comumente utilizadas em sistemas de gerenciamento, porém a importância dada é diferente entre os sistemas. No modelo TNM (Telecommunication Management Network) o enfoque maior é para a técnica eventreporting. Já no modelo SNMP a importância é maior para técnica de polling. O modelo CMIP usa de maneira balanceada as duas técnicas MONITORAÇÃO DA REDE A monitoração está associada ao gerenciamento de rede. Esta tarefa é responsável por obter as informações que são avaliadas pelos sistemas de gerenciamento (LEINWAND, 1996). 5 SNMP é um protocolo utilizado no apoio ao gerenciamento de uma rede com arquitetura TCP/IP. 6 CMIP é um protocolo também utilizado no apoio ao gerenciamento de rede, porém mas complexo e que utiliza mais recursos quando comparado ao SNMP. 23

25 A coleta das informações no monitoramento visando avaliar o desempenho de uma rede é feita de dois modos: de maneira passiva, onde nenhum recurso da rede é utilizado ou modificado. E a ativa, relacionada com a inserção controlada de pacotes na rede, e a posterior coleta dos mesmos. Como exemplo dessa última, temos a utilização de pacotes ICMP 7 (Internet Control Message Protocol) para obtenção do RTT 8 (Round Trip Time) de uma rede (LEINWAND, 1996). A desvantagem da monitoração ativa está relacionada a possível saturação dos enlaces pelos pacotes relacionados a tarefa de monitorar a rede. E também pela perda de desempenho que algum tipo de aplicação pode sofrer por estar utilizando o mesmo enlace. Já a vantagem da monitoração ativa é a agilidade com que as informações podem ser obtidas quando comparada a monitoração passiva MÉTRICAS DE DESEMPENHO Na Internet existem várias quantidades que estão relacionadas com o desempenho, e com a confiabilidade de seus componentes, do qual necessitaríamos saber o seu valor. Quando uma destas quantidades é especificada, ou seja, quando trata-se da propriedade de um dos componente da Internet, esta quantidade ou propriedade é denominada métrica. Logo, os valores quantificados de uma métrica são denominados medidas (PAXSON, 1998). Quando uma métrica é quantificada, sua medida deve ser apresentada em termos de unidade padronizada. Atualmente os dois principais organismos que procuram construir um conjunto de métricas padronizadas para aplicação na avaliação do desempenho, da qualidade, e da confiabilidade das medições sobre o estado das redes de computadores são, o CAIDA (Center for Applied Internet Data Analysis) e o grupo de trabalho IPPM (Internet Protocol Performance Metrics) da IETF. sendo suas principais métricas: LATENCY OR DELAY (LATÊNCIA OU RETARDO): Representa o tempo total utilizado por um pacote da origem até o destino. Esse tempo total representa a soma dos atrasos no processamento dos elementos da rede, em conjunto com o atraso da propagação do meio de transmissão (BURGESS, 2004). Esse retardo 7 ICMP é um protocolo utilizado para comunicar informações da camada de rede na arquitetura TCP/IP 8é o tempo necessário para uma informação chegar ao destinatário e o remetente receber a confirmação 24

26 pode ser: One-way delay (Retardo unidirecional): Corresponde ao tempo entre a inserção do primeiro bit de um pacote IP, de tamanho D, até a entrega do último bit do mesmo pacote IP ao destino. Como na Internet as rotas são assimétricas, ou seja a rota de origem pode ser diferente da rota de destino, essa medida de retardo ida-e-volta realmente mede o desempenho de dois distintos trajetos ao mesmo tempo (ALMES, 1999c). Round-trip delay (Retardo de ida e volta): Corresponde ao tempo entre a inserção do primeiro bit de um pacote IP1, de tamanho D1, gerado pelo remetente, até a chegada do último bit de outro pacote IP2, de tamanho D2, gerado pelo destinatário, ao remetente do pacote IP1 (ALMES, 1999a). Os principais motivos para medir a latência, segundo a RFC 2679 (ALMES, 1999a) e RFC 2681 (ALMES, 1999c) são: Aplicações interativas como Voz sobre IP e Vídeo Conferência, são afetadas pelos retardos produzidos pela WAN. Por isso, necessitam de um retardo mínimo na recepção de uma resposta da rede. Retardos longos impactam os protocolos da camada de transporte, como por exemplo o TCP. Quanto maior for a média da latência, maior será o impacto na taxa de transmissão fim a fim PACKET LOSS (PERDA DE PACOTES): Ocorre quando o destinatário não recebe o pacote após um tempo limite pré-estabelecido, chamado de timeout. Esse tempo pré-estabelecido irá depender da distância e do percurso realizado pelo pacote, e também pelo tamanho das filas dos dispositivos de roteamento (ALMES, 1999b). As duas maneiras mais utilizadas para avaliar a perda de pacote são: One-way packet loss (Perda de pacotes unidirecional): Corresponde a relação entre a quantidade de pacotes perdidos e a quantidade de pacotes recebidos, no percurso de ida entre o emissor e o receptor. 25

27 Round-trip packet loss (Perda de pacotes ida-e-volta): Corresponde a relação entre a quantidade de pacotes perdidos e a quantidade de pacotes recebidos, no percurso de ida e volta entre o emissor e o receptor. Um dos principais motivos para mediar a perda de pacote, é que ela afeta principalmente as aplicações de transferência de dados. Porque a perda de um pacote significa que a transmissão da mensagem ou do arquivo não foi concluída, necessitando que o pacote perdido seja novamente transmitido. Contudo, em aplicações multimídia o impacto referese a qualidade da transmissão, porque mesmo com a perda de alguns pacotes ainda é possível o entendimento da transmissão. (ALMES, 1999b) JITER (VARIAÇÃO DO RETARDO): Pode ser entendido como a variação no tempo e na sequência de entrega dos pacotes. Onde um dos principais motivos para medir o Jiter deve-se ao fado de ser extremamente danoso a aplicações de mídia contínua (áudio e vídeo). Porque quando esses pacotes são gerados na origem normalmente utilizam taxa constante, mas quando passam pela rede, sofrem retardos diferentes, e chegam ao destino de modo não sincronizado. Normalmente aplicações desse tipo utilizam algum mecanismo de buffer para o recebimento dos pacotes, antes do envio ao usuário (DEMICHELIS, 2002) BANDWIDTH (LARGURA DE BANDA): É definida como a avaliação da capacidade de transmissão de um enlace (LAI, 2000), Pode ser avaliada, dentre outras, da seguinte maneira: Bottleneck Bandwidth (Largura de banda de contenção): Representa a taxa máxima que um fluxo pode atingir em uma rota, sem a concorrência do tráfego (sem carga). Available Bandwidth (Largura de banda disponível): Corresponde a taxa máxima que um fluxo pode atingir em uma rota, com a concorrência do tráfego (com carga). Bandwidth Utilization (Largura de banda utilizada): o tráfego do enlace. É o somatório de todo 26

28 Archievable Bandwidth (Largura de banda alcançável): Representa a taxa de transferência entre o transmissor e o receptor. Levando-se em conta um conjunto de fatores como protocolo de transmissão, hardware, configuração de sistema de transmissão, e o sistema operacional. Os principais motivos para a medição da largura de banda são (LAI, 2000): Adaptabilidade das aplicações a capacidade de transmissão dos enlaces. Exemplo aplicações de vídeo; Escolha do melhor caminho de roteamento para a transmissão de uma aplicação AVAILABLE NETWORK (DISPONIBILIDADE DA REDE): Consiste na proporção de tempo que todos os componentes da rede estão operando corretamente, e disponíveis para uso (MCCABE, 1998). Disponibilidade está associada ao conceito de confiabilidade, que pode ser definida como a probabilidade de estar funcionando continuamente, dentro de um intervalo específico [0,t], dado que ele estava funcionando em t = 0 (LAFRAIA, 2001). Assim, podemos observar que a definição de confiabilidade não leva em consideração os tempos necessários para realização dos reparos, ou recuperação do estado operacional dos sistemas, decorrentes de eventos relacionados a falhas. Na realidade, apenas o tempo de operação contínua, sem interrupções, é considerado. Em outras palavras, confiabilidade está diretamente relacionada ao tempo médio para falhar (SWARZ, 1998). Devido a este comportamento, deve-se medir os valores de TMTF (Mean Time To Failure) e MTTR (Mean Time To Repair) para recuperação do sistema. O TMTF significa tempo médio entre falhas, e representa o tempo transcorrido entre uma falha e outra, (incluindo o tempo necessário para reparo/restauração). Já o MTTR representa o tempo médio para reparo, e significa o intervalo de tempo que inicia no momento em que uma falha é detectada, até o instante em que o sistema ou seus elementos constituintes sejam completamente reparados. Logo, a disponibilidade representa uma função direta do MTTF/(MTTF+MTTR) (SWARZ, 1998). Outro conceito importante é a disponibilidade do serviço que a rede fornece às aplicações. Esta disponibilidade é calculada através da relação entre Uptime e DownTime. Onde UpTime representa o total de tempo acordado do serviço, e DownTime significa o tempo em que o serviço não foi prestado. Assim a disponibilidade do serviço da rede 27

29 para a aplicação é UpTime - DownTime/UpTime. Essa métrica de desempenho pode ser utilizada individualmente para cada componente da rede, ou para a rede de um modo geral, como serviço estabelecido em métrica de desempenho para SLA (Acordo de Nível de Serviço) (MAGALHÃES, 2007). A aplicabilidade de cada métrica está relacionada a situação que se pretende analisar, sendo que a utilização de um conjunto específico dessas métricas é útil quando se aborda o tema do gerenciamento da rede com qualidade de serviço QUALIDADE DE SERVIÇO EM REDE DE COMPUTADORES O tráfego na Internet é muito diversificado, onde cada aplicação necessita de requisitos específicos em termos de métricas de desempenho. Outro fator importante é que a maior parte do tráfego é baseada no protocolo IP, isso representa uma vantagem em termos de equipamentos mais simples e econômicos. Porém, também representa uma desvantagem, pois o protocolo IP devido a sua característica best effort, não prevê qualidade de serviço (QoS) em sua arquitetura. Deste modo, para que a Internet possa evoluir, torna-se necessário definir métodos para prover serviços diferenciados. Este método é chamado de QoS, e possui diferentes definições na literatura. Em (ZHAO, 2000) QoS é descrito como um mecanismo que fornece diferenciação de serviços, e garantias de desempenho para as aplicações na Internet, onde essa diferenciação de serviços representa a ideia de serviços diferentes para aplicações diferentes. Já para ITU-T QoS é o resultado de todo o conjunto do desempenho de um serviço, e indica o grau de satisfação do usuário, ou seja é a percepção do mesmo quanto ao atendimento prestado a ele. Para as redes de computadores, QoS está relacionado a todos os níveis da arquitetura. Porém, grande parte do desenvolvimento tem ocorrido na elaboração de técnicas para implementar QoS utilizado as camadas mais baixas, sobre tudo a camada de rede PRINCIPAIS ARQUITETURAS PARA O PROVIMENTO DE QUALIDADE DE SERVIÇO A IETF apresentou ao longo do tempo, algumas alternativas técnicas para o provimento de serviços com QoS em redes IP, destacando-se a arquitetura de Serviços Integrados (IntServ) e a arquitetura de Serviços Diferenciados (DiffServ). 28

30 INTSERV Tem como característica implementar QoS através de um mecanismos que reserva recursos. Onde antes do início da transmissão, o emissor solicita ao receptor que aloque os recursos necessários para que a transmissão de dados seja realizada com a qualidade requerida pela aplicação. Para isso, as aplicações utilizam o protocolo RSVP (Resource ReSerVation Protocol) que tem como missão, viabilizar a alocação de recursos relacionados a largura de banda, e tempo de persistência da conexão (BRADEN, 1994). O protocolo RSVP tem como principal vantagem a eficácia em garantir os requisitos de QoS, porque provê a granularidade e o controle preciso nas solicitações feitas pelas aplicações. Contudo, sua principal desvantagem está relacionada a escalabilidade. Pois a necessidade de manter os recursos reservados em todos os dispositivos, e o elevado número de mensagem trocadas para a realização da reserva de recursos, acaba por inviabilizar o seu uso (KAMIENSKI, 2000) DIFFSERV Realiza a implantação da QoS através de mecanismos que realizam a priorização de pacotes. Onde o campo DS(Differentiated Services) do pacote IP, é utilizado de maneira a ser compatível com o campo ToS (Type of service) do protocolo IPv4, e do campo Traffic Class do protocolo IPv6. E a partir de uma sequência de procedimentos, os pacotes são classificados, marcados e processados segundo o rótulo DSCP (Differentiated Services Code Point) recebido no momento do envio, Com isso, a arquitetura pode oferecer diferentes classes de serviço (KILKKI, 2008). A arquitetura DiffServ funciona sobre três tipos de elementos funcionais (KUROSE, 2012), conforme a figura 2.2: Funções de Borda: Local por onde os pacotes entram na rede, tem como tarefa classificar os pacotes através de marcação realizada no campo DS, que indica a classe de tráfego da qual o pacote pertence, viabilizando assim diferentes classes de tráfego, com serviços diferenciados dentro do núcleo da Rede. Função Central: Tem como missão o envio do pacote conforme estabelecido para o serviço. Ou seja, quando o pacote chega ao dispositivo de rede é reenviado até o próximo dispositivo, conforme o PHB (comportamento por salto) relacionado a classe de serviço que o pacote pertence. O PHB pode ser de dois tipos: 29

31 PHB-EF (Repasse Acelerado): Estabelece que a taxa de partida para uma classe de tráfego, referente a um dispositivo de rede, deve ser no mínimo igual a taxa configurada. Isso implica que mesmo ocorrendo classes de tráfego que sobrecarreguem os recursos do dispositivo de rede, o mesmo deve manter sempre disponível a quantidade de recurso prevista para todas as classes, independente do volume de pacotes recebidos relacionados às classes no dispositivo. PHB-AF (Envio Assegurado): Prevê classes de tráfego para fornecimento de recursos no dispositivo de rede. E dentro de cada classe, estabelece categorias distintas para descarte preferencial. Na ocorrência de um congestionamento dentro de uma classe AF, o dispositivo de rede descarta os pacotes, conforme estabelecido nas categorias de descarte preferencial. Função de Medição: Tem como tarefa acompanhar o fluxo de entrada dos pacote na rede de acordo com o perfil de tráfego estabelecido. O perfil de tráfego representa uma taxa limite pré-estabelecida para o envio de pacotes na rede, que pode ter um limite para o pico de transmissão, ou para rajadas de fluxos de pacotes. Nos casos em que ocorrerem violação ao perfil de tráfego, os pacotes podem ser descartados, atrasados, transmitidos e remarcados para alguma outra classe. Contudo, essa decisão está relacionada ao estabelecido no SLA(Acordo de Nível de serviço), e não está especificada como tarefa na função de medição, ou na arquitetura DiffServ. FIG. 2.2: Funções DiffServ (KUROSE, 2012) A arquitetura DiffServ não necessita saber a origem do pacote quando o mesmo chega no dispositivo de rede. Basta identificar a classe de serviço, evitando a necessidade de armazenar o par origem e destino da transmissão no dispositivo, o que representa uma simplificação de função, e viabiliza uma maior escalabilidade, se comparado a arquitetura IntServ. Contudo, uma desvantagem é não ter como garantir reserva de recurso na 30

32 transmissão fim-a-fim. Porque, devido a própria concepção da arquitetura, não existe um protocolo como RSVP, para realizar essa reserva de recurso, a fim de atender a demanda da aplicação (STALLINGS, 2005) ACORDO DE NÍVEL DE SERVIÇO (SERVICE LEVEL AGREEMENT - SLA) Pode ser definido como um contrato de serviço estabelecido entre cliente e o provedor de serviços, onde são especificados os detalhes da entrega dos serviços, incluindo os aspectos tecnológicos e referentes a prestação do serviço, bem como das garantias ao cliente, como funcionamento do suporte e tempo de resposta para atendimento de requisições (HORMOZI, 2012). O SLA pode ser construído de várias maneiras, porém é possível identificar uma estrutura básica existente na maioria deles formada por: informações sobre todas as partes interessadas no negócio, os parâmetros do serviço prestado (como classes e volume do tráfego), as métricas para calcular esses parâmetros (métricas de desempenho), o algoritmo para calcular os parâmetros, o objetivo de nível de serviço (SLO), e as ações e penalidades em caso de violação do SLA (SCHNJAKIN, 2010). A definição do SLA é uma tarefa difícil, levando-se em conta que este acordo deve atender de forma clara e inequívoca, fatores relacionados às expectativas dos usuários para seus serviços, e principalmente valores monetários. Além disso deve descrever de forma objetiva, todas as condições de negócio, seu período de vigência, e todas as questões de ordem jurídica (MALKOWSKI, 2010). O gerenciamento do SLA é realizado de forma a verificar se todas as condições definidas para os serviços em funcionamento estão sendo atendidas. Para isso, é habitual utilizar mecanismos de notificação, para informar sobre uma situação não prevista que esteja ocorrendo, e ainda ativar ações de correção, conforme o estabelecido no contrato. O SLA reflete uma mudança no funcionamento da economia em torno da Internet, que deixou de ser orientada ao produto para ser orientada ao serviço. Tornando as tecnologias relacionadas à infraestrutura da Internet, essenciais no suporte ao funcionamento de diversos outros domínios da sociedade. Atualmente, é possível notar uma mudança na demanda dos serviços, que inicialmente eram de ordem estática, pré-definidos dentro de um contexto específico, para serviços que devem ser atendidos de forma dinâmica, onde o fornecimento está relacionado às demandas cada vez mais rápidas dos usuários. 31

33 2.1.8 QUALIDADE DE EXPERIÊNCIA (QUALITY OF EXPERIENCE - QOE) Segundo ITU-T QoE corresponde a uma métrica para avaliação de um serviço ou aplicação percebida de modo subjetivo pelo usuário (ITU-T, 2007) (ITU-SECTOR, 2008). Exitem fatores que podem afetar a QoE: Fatores do ambiente: São geralmente incontroláveis e de difícil avaliação em uma sessão de teste. Exemplo: ruído no ambiente do usuário e iluminação do local. Fatores da fonte: Corresponde aos fatos relacionados com a origem do sinal de transmissão. Como por exemplo, em aplicações de vídeos o nível do som e o movimento médio, podem ter um impacto na percepção do usuário sobre a qualidade do serviço. Fatores da rede: Características de operação da rede, relacionadas às métricas de desempenho como largura de banda e latência, podem afetar de modo diferente a sensibilidade do usuário com respeito a aplicação, e ao serviço prestado. Fatores do receptor: Representa os fatos relacionados ao recebimento dos dados transmitidos que podem afetar a percepção do usuário. Como por exemplo, a existência de buffering e controle de congestionamento no receptor. Existem dois métodos para avaliação de QoE (RIBEIRO, 2011) (KHAN, 2012): Avaliações subjetivas: Aquelas realizadas com base na percepção do usuário final, neste modelo destaca-se a escala MOS 9 (Meam Opinion Score). Avaliações objetivas São aquelas realizadas a partir de modelos matemáticos que estimam a avaliação realizada pelo usuário final. Este modelo, é muitas vezes adotado por sua rapidez na obtenção de resultados, e pelo seu custo quando comparado com o modelo subjetivo. Na área de pesquisa sobre QoE, a escala MOS é mais utilizada como modelo para construção de algoritmos para a avaliação objetiva, de resultado referentes a testes subjetivos. O MOS é formado por uma escala de valores contendo cinco possíveis estágios (TAB 2.1), e necessita de condições especiais como um ambiente calmo, sem luminosidade e equipamentos com condições acústicas e visuais específicas. Outra característica 9 MOS é a medida mais utilizada para avaliar a qualidade de voz em uma chamada telefônica 32

34 é a demora para obtenção dos resultados. Pois do ponto de vista estatístico, é necessário muitas pessoas para validação dos resultados, além disso, existe a demanda de tempo para a análise dos dados colhidos durante a execução da avaliação (XU, 2011). TAB. 2.1: Mean Opinion Score - MOS (RIBEIRO, 2011) MOS Qualidade Prejuízo 5 Excelente imperceptível 4 Bom muito pouco perceptível 3 Razoável pouco perceptível 2 Pobre perceptível 1 Ruim muito perceptível MAPEAMENTO DA QOE EM PARÂMETROS DE QOS Conforme já citado anteriormente, segundo ITU-T QoS é um somatório de parâmetros que mostra a satisfação do usuário com o serviço prestado. Pode-se então concluir, que de certo modo, está adequada ao propósito da QoE. Ou seja a QoE é orientada ao usuário e a QoS é orientada ao desempenho da rede. A QoE é fundamental para a fidelidade do cliente, já as métricas de QoS são normalmente mais fáceis de mensurar pelo provedor de serviço. Logo, é fundamental a elaboração de modelos para gerenciamento da rede que correlacionem as duas formas, de modo a permitir um controle da QoE das aplicações dos usuários baseado em medições de métricas da QoS (LIMA, 2011). FIG. 2.3: Gerenciamento de QoE/QoS adaptado de LIMA (2011) 33

35 Um ciclo para o gerenciamento de QoE/QoS (FIG 2.3) inicia-se com a qualidade de experiência percebida pelo usuário sobre a sua aplicação, expressos através da definição de requisitos qualitativos e/ou quantitativos do desempenho esperado da rede. Então esses requisitos mapeados são transformados em classes de serviços do SLA, pelos usuários e os provedores de serviço. Para depois serem monitorados, auditados e avaliados com o objetivo de constatar a sua eficácia para todas as partes envolvidas TIPOS DE APLICAÇÃO QUANTO A DEMANDA DE TRANSMISSÃO Um ponto importante para a definição dos requisitos de um modelo para gerenciamento de QoE/QoS, é a identificação do tipo de transmissão das informações produzido pelas aplicações que utilizaram a rede. Em relação às características de transmissão da informação, podemos identificar os seguintes tipos de aplicações (BRADEN, 1994) (PETERSON, 2010): Elásticas ou Aplicações adaptáveis: São aquelas onde o mais importante é a correta recepção dos dados, independente da taxa de transmissão. Como exemplo temos as aplicações de correio eletrônico e FTP Não Elásticas ou Aplicações de tempo real: Possuem rígidas características de reprodução, onde um fluxo de dados em uma transmissão fim a fim não admite atrasos, contudo aceita uma certa quantidade de perda de pacotes. Pode ser subdividas em duas categorias: Intolerantes: São aplicações onde as variações nas taxas de latência e de disponibilidade da rede podem gerar perda de pacotes, o que acaba gerando falhas no funcionamento da aplicação. Exemplo: aplicações relacionadas a área da robótica. Tolerantes: Aceitam uma variação na taxa de latência e ainda assim conseguem produzir um sinal com certa qualidade. Podem ser subdividas em: Não adaptáveis: São aplicações que necessitam de uma taxa de latência e de largura de banda constante. Onde ocorrendo flutuações elevadas nas taxas das métricas de desempenho citadas acabam por gerar sinais com qualidade inaceitável na aplicação. 34

36 Adaptáveis a faixa: São aplicações que ajustam a sua qualidade de funcionamento à banda disponível. Exemplo de aplicações de vídeo, onde os algoritmos de codificação permitem ao usuário escolher uma taxa de transmissão dos bits que está associado a largura de banda disponível, produzindo a execução da aplicação com certa qualidade de reprodução. Adaptáveis ao retardo: São as aplicações que conseguem se adaptar a algum tipo taxa de latência que seja constante, normalmente esse tipo de aplicação faz uso de algum mecanismos de buffering, e assim ajusta o seu ponto de reprodução para essa situação. Como exemplo, aplicações de mídia contínua. O modelo simples da Internet baseado no princípio Best Effort, não contempla os requisitos de QoS e das aplicações atuais. Esse modelo simples que viabilizou seu crescimento em escala global, agora impede a sua evolução. Esse fenômeno chamado pelos pesquisadores de Calcificação da Internet, tem tornado difícil a solução de qualquer dos problemas estruturas da Internet. Portanto, torna-se urgente uma Nova Internet (Internet do Futuro), para atender aos problemas citados e não previstos em seu modelo original (ANDERSON, 2005). 2.2 REDES VIRTUALIZADAS As dificuldades de realizar à implantação de novas soluções no núcleo da rede, sobretudo pela desconfiança dos administradores de que tais inovações possam causar a indisponibilidade de serviços, ou não obtenham o desempenho esperado, tem dificultado a implantação de soluções para o impasse da Calcificação da Internet. Uma opção vista como proposta alternativa para o desenvolvimento de novas soluções para a Internet do Futuro, e que não gera impacto no tráfego em produção é a virtualização de redes. Redes Virtuais constituem-se de um processo que permiti fazer com que os componentes de uma rede física possam particionar suas capacidades, de maneira a realizar simultaneamente múltiplas funções. Estabelecendo assim infraestruturas lógicas distintas e mutuamente isoladas. Esse isolamento, garante que o tráfego experimental não afetará o tráfego de produção (WANG, 2008). Outra característica das redes virtuais, diz respeito a sua topologia que não é necessariamente igual a topologia da rede real. Para representar roteadores virtuais adjacentes 35

37 em roteadores físicos não adjacentes, utiliza-se a técnica de tunelamento, onde túneis são criados entre os roteadores físicos para tornar a rota de transmissão transparente para a topologia virtual. Esse aspecto de mapear a rede virtual em uma rede física permite que as redes virtuais sejam mais flexíveis que as tradicionalmente implementadas (WANG, 2008). Esse modelo tem sido uma das principais abordagens para a implantação de soluções da Internet do Futuro, onde cada rede virtual está isolada com sua própria pilha de protocolos e seu gerenciamento individualizado. Estas redes podem ser implementadas basicamente de quatro modos, descritos nas próximas subseções: (CHOWDHURY, 2010) REDES LOCAIS VIRTUAIS (VLANS) É um conjunto lógico de usuários ou dispositivos que podem estar unidos por função ou aplicativo, independentemente da localização de seus segmentos físicos. A configuração de VLANs é feita no equipamento de rede através de software proprietário do fabricante. Na VLAN é possível eliminar as limitações da arquitetura física, definindo uma segmentação lógica (software), baseada num agrupamento de máquinas com critérios como endereço MAC, números de porta e protocolo REDES PRIVADAS VIRTUAIS (VPNS) São túneis seguros entre pontos autorizados, criados através da Internet ou outras redes públicas e/ou privadas, para tráfego de dados utilizando algum mecanismo criptográfico para proteção da comunicação entre as redes corporativas ou usuários remotos. A VPN também proporciona a redução de custos com comunicações corporativas, porque elimina a necessidade de enlaces dedicados de longa distância que podem ser substituídos por links compartilhados que utilizam a Internet REDES DE SOBREPOSIÇÃO (OVERLAY ) É uma rede virtual que gera uma topologia virtual em cima da topologia física de outras redes (FIG 2.4). Os nós em uma rede de sobreposição são ligados por meio de conexões virtuais que representam o percurso na rede subjacente. Na camada IP os nós representam os roteadores e sistemas terminais, enquanto na camada Overlay, que é uma rede de sobreposição, existe a topologia virtual. As redes de sobreposição são geralmente programadas na camada de aplicação, embora existam implementações nas camadas inferiores 36

38 da pilha de redes. As redes de sobreposição não são restritas geograficamente, e são bastante flexíveis e adaptáveis às mudanças, quando comparadas a qualquer outra rede. Como resultado, as redes sobrepostas têm sido usadas para implantar novos recursos e extensões na Internet. FIG. 2.4: Esquema de uma rede Overlay (MIR, 2006) REDES DEFINIDAS POR SOFTWARE SDN é uma das principais propostas em desenvolvimento pela comunidade científica, apoiada no conceito da virtualização, para a implementação da Internet do Futuro. Sua arquitetura é baseada em quatro características fundamentais (KREUTZ, 2014): Separação entre o plano de controle e o plano de dados. Os dispositivos SDN não possuem mais a funcionalidade de gerenciar o seu plano de controle, realizam apenas o encaminhamento dos pacotes. Onde a decisão sobre como cada pacote deve ser processado, é realizada por um nível superior, chamado de controlador. (GREENE, 2009). O plano de dados é o responsável por gerenciar a comutação, e o repasse dos pacotes com os dados dos usuários pela rede. Já o plano de controle cuida dos protocolos, e da tomada de decisão que estabelece as rotas da tabela de encaminhamento. Nos dispositivos atuais o plano de controle e o plano de dados são construídos, e executados no próprio equipamento, de modo que todas as decisões de roteamento só são possíveis no domínio do protocolo proprietário do equipamento (CASADO, 2009). As decisões relacionadas ao encaminhamento dos pacotes é baseada em fluxo ao invés do destino do pacote. Um fluxo pode ser definido como um conjunto de campos 37

39 de pacotes operando por regras de correspondência é por ações (instruções) (GUDE, 2008). Essa abstração possibilita padronizar o comportamento dos dispositivos de rede como roteadores, switches, firewalls e middleboxes. A programação de fluxos permite uma grande flexibilidade limitada apenas à capacidade da tabela de encaminhamento de fluxo (JAMJOOM, 2014). O gerenciamento do plano de controle é realizado por uma entidade externa aos dispositivos de rede, chamado de controlador SDN ou sistema operacional de rede (NOS). O controlador é uma plataforma de software que fornece os recursos necessário para a realização da programação da tabela de encaminhamento dos dispositivos. Proporcionando, tal qual um sistema operacional, uma abstração que viabiliza o desenvolvimento de soluções particulares para o encaminhamento e roteamento de modo mais simples, se comparado aos modelos de rede tradicionais.(casado, 2009). E a principal característica é a existência de aplicações de software (App) em funcionamento sobre o controlador, que interagem como o plano de dados dos dispositivos da rede (KREUTZ, 2014). FIG. 2.5: arquitetura SDN (KREUTZ, 2014) 38

40 Sua flexibilidade para construção de sistemas em rede, é útil em diversas áreas das computação, tais como: Controle de acesso: A facilidade de se estabelecer rotas para cada fluxo, permite a criação de filtros específicos para o controle de acesso a determinadas classes de tráfego nos diversos dispositivos da rede, que levem em consideração não apenas o caminho do pacote da rede ou o tipo de protocolo, mas a transmissão como um todo e seu impacto no funcionamento da rede (CASADO, 2009). Gerenciamento de redes: O controlador da rede pode fornecer interfaces de programação que viabilizem o desenvolvimento das mais variadas aplicações, para o apoio ao gerenciamento dos diversos problemas oriundos da escalabilidade da rede. (SALVADOR, 2012). Eficiência Energética: Devido a visão centralizada da rede é possível identificar os dispositivos de rede que estão ociosos ou com baixo tráfego, permitindo a realização de mudanças na rede, que viabilizem o desligamento seletivos desses elementos, gerando assim economia no consumo de energia. Tal situação não é possível em redes tradicionais sem a interação humana no desligamento do equipamento e reconfiguração manual da nova rota (GUDE, 2008). Virtualização da rede: é possível a controladores especiais realizarem a virtualização do plano de controle. Permitindo com isso a existência de redes fisicamente virtualizadas apoiadas na implantação de regras para o encaminhamento dos pacotes (SHERWOOD, 2009). 2.3 AMBIENTE OPENFLOW A evolução e o crescimento da Internet, acabou por tornar sua infraestrutura física um serviço comercial, fazendo com que seus equipamentos de redes ficassem como caixas pretas, onde todas as soluções implementadas estão apoiadas em software e hardware proprietário, o que contribuiu de certo modo para citada calcificação da Internet (MCKEOWN, 2008). Tendo essa ideia como princípio motivador, foi criado pela equipe da universidade de Stanford o OpenFlow, atualmente uma das tecnologia mais utilizadas para viabilizar a implementação das Redes Definidas por Software, devido principalmente a sua interface 39

41 de comunicação entre o plano de encaminhamento e o plano de controle bastante flexível, além de ser uma tecnologia open source. O OpenFlow já é adotada por diversos fabricantes de dispositivos para rede como Cisco e HP, sendo utilizada em Data Centers de grande empresas como a Google e Amazon. O projeto OpenFlow tem como meta atender aos requisitos abaixo relacionados (MCKEOWN, 2008): Garantir isolamento entre o tráfego experimental e o de produção; Capacidade de suportar uma diversidade de pesquisas científicas; Possibilidade de ser utilizado em implementação de baixo custo, e com alto desempenho; Estar comprometido com a necessidade dos fabricantes de não exporem o projeto de suas plataformas PRINCIPAIS COMPONENTES A arquitetura OpenFlow é composta pelos seguintes componentes básicos (FIG 2.6): FIG. 2.6: Componentes OpenFlow (MCKEOWN, 2008) Tabela de Fluxos: Contém as linhas que definem os fluxos da rede. Fluxos são formados pela tupla (regras, controles de estatística e ações) (FIG 2.7). Na parte da 40

42 regra (match fields), está contida a definição dos valores de campos e cabeçalho do pacote. É aqui onde o fluxo do pacote é definido. Já a parte dos controles de estatística (counters), é utilizada para registrar estatísticas de utilização, e para eliminar fluxos inativos ou que já não existem mais. E por último, ações (instructions), definem como os pacotes associados aos fluxos devem ser processados, ou seja para onde serão enviados, ou se serão descartados (TAB 2.2) Neste sentido, as linhas da tabela de fluxos são interpretadas pelos dispositivos de rede como decisões em cache do plano de controle em software. Sendo assim, correspondem a menor unidade de informação no plano de dados da rede (MCKEOWN, 2008). FIG. 2.7: Tabela de Fluxos adaptado de CONSORTIUM (2011) e MCKEOWN (2008) TAB. 2.2: ações do fluxo adaptado de CONSORTIUM (2011) Tipo Ação Forward Enqueue Drop Modify Field Processamento Indica o encaminhamento para a porta (física e virtual) especificada. Encaminha um pacote para uma fila anexada a uma porta, onde está definido o padrão de encaminhamento do pacote. Define que todos os fluxos correspondentes serão descartados Consiste na modificação dos cabeçalhos dos pacotes. Controlador: É uma espécie de sistema operacional de rede, responsável por tomar as decisões relativas ao roteamento, removendo ou adicionando linhas na tabela de fluxos conforme as regras estabelecidas. O controlador funciona como uma camada de abstração da infraestrutura física da rede, e tem como meta viabilizar o desenvolvimento de aplicações, e serviços que melhorem o fluxo na rede (GUDE, 2008). Existem várias versões de controlador desenvolvidas em diferentes linguagens de programação (TAB 2.3). 41

43 TAB. 2.3: Principais Controladores OpenFlow Controlador Linguagem Empresa Responsável Nox C++ Nicira/VMWare Pox Python Nicira/VMWare Floodlight JAVA Big Switch Networks Beacon JAVA Stanford University TREMA Ruby/C NEC Corporation Ryu Python NTT Grupo OSRG FlowVisor C Stanford/Nicira RouterFlow Python CNPQ Canal Seguro: Responsável por garantir a confiabilidade e segurança na troca de mensagens entre o controlador e dispositivo de rede, e em última análise, garantir a segurança da rede contra tentativas de sabotagem. A interface de acesso padrão é o SSL, contudo é possível utilizar outros protocolos como o TCP, o que pode ser útil em ambiente virtuais e de experimentação, pela simplicidade de utilização (MCKEOWN, 2008). Dispositivos de rede: Em uma rede OpenFlow, os equipamentos apenas executam as instruções previamente definidas em sua tabela de roteamento pelo controlador. Podem ser de dois tipos: Baseados em hardware: são aqueles onde o fabricante fornece modelos com interface de programação com suporte ao protocolo OpenFlow. Baseados em software: Onde o suporte ao protocolo OpenFlow poder ser usado em ambiente virtualizado (switch lógico). Ou embarcados em um hardware específico como NetFPGA, ou um computador (arquitetura x68) com sistema operacional Linux. (CONSORTIUM, 2011) Protocolo OpenFlow: É o responsável pela comunicação entre o controlador e os dispositivos de rede no ambiente OpenFlow. Realiza a comunicação através de troca de mensagens (TAB 2.4), que podem ser simétricas, assíncronas ou ainda 42

44 iniciadas pelo controlador, essas mensagem trafegam pelo canal seguro definido pela arquitetura. O seu padrão é aberto o que garante maior liberdade de utilização e modificação (MCKEOWN, 2008). TAB. 2.4: Tipos de Mensagem trocada entre controlador e os dispositivos de rede (CON- SORTIUM, 2011) Tipo Mensagem Característica Modificação do estado Configuração Barreira Leitura do estado Packet-out/ Packet-in Objetivo Solicitação de conexão ao dispositivo de rede, além de informações específicas sobre a capacidade do mesmo para o gerenciamento do controlador. Manter atualizada a tabela de fluxo do dispositivo de rede através da adição ou remoção de regras. Definir e consultar parâmetros de configuração do dispositivo de rede. Verificar se mensagens anteriores foram cumpridas, ou então para receber a confirmação de operações concluídas. Obter os status e coletar as estatísticas (contadores)do dispositivo de rede Enviar pacotes completos para o dispositivo de rede. Onde não ocorrendo uma correspondência entre o pacote e alguma linha na tabela de fluxos, faz com que o pacote seja então encaminhado por completo para o controlador (Parcket-In), que por conseguinte reenvia (Packet-out), o pacote com seu respectivo conjunto de ações FUNCIONAMENTO Uma rede OpenFlow funciona conforme estabelecido na programação do plano de controle. Ou seja todas as regras para os fluxos de dados são estabelecidos pelo controlador, e informados aos diversos dispositivos que compõem a rede através dos fluxos de controle. Quando um pacote dá entrada em um dispositivo de rede, os cabeçalhos são analisados com base nas regras definidas na tabela de fluxos, sendo então executados conforme as ações previstas, e também os contadores são atualizados. Caso não tenha uma ação prevista para o pacote, em alguma das linha da tabela de fluxos, esse pacote é enviado ao controlador. Normalmente, esta situação acontece apenas com os primeiros pacotes de 43

45 um novo fluxo que chega ao controlador. A partir disso é estabelecido uma nova regra no dispositivo de rede, ou então o controlador pode definir que determinados tipos de pacote, como por exemplo de controle (DNS, ICMP, DHCP), sejam enviados diretamente para ele (ROTHENBERG, 2010). As principais ações associadas aos fluxos podem ser: Encaminhar o fluxo de pacotes para uma porta (ou portas); Alterar os campos do cabeçalho; Encapsular e enviar o pacote para o controlador; Descartar pacote, como medida de segurança semelhante a regras de Firewall; Encaminhar o pacote para processamento normal (fora do OpenFlow). Essa última ação, garante que o tráfego experimental não interfira no processamento padrão de produção. Essa segmentação do tráfego, viabiliza o funcionamento híbrido de equipamentos que ora processam tráfego legado, e ao mesmo tempo e de maneira isolada, o tráfego das redes OpenFlow (ROTHENBERG, 2010) SIMULADOR PARA AMBIENTE OPENFLOW A implantação de uma rede com tecnologia OpenFlow requer diversos componentes em sua infraestrutura, tais como máquina controladora, utilizando algum sistema operacional de rede, como por exemplo o Floodlight ou POX, e dispositivos de redes com suporte ao protocolo OpenFlow. Além disso, é necessário toda infraestrutura física que interligue esses elementos por um canal seguro para o efetivo funcionamento de uma SDN. Contudo, nem sempre o pesquisador tem toda essa infraestrutura a sua disposição para realização de seus experimentos. Para resolver esse problema, podemos utilizar o simulador MiniNet, aplicativo desenvolvido pela equipe da universidade Stanford, e utilizado para a prototipagem de uma rede SDN com tecnologia OpenFlow, onde é possível implementar um protótipo da rede, que se deseja construir de maneira rápida, e em um único computador (LANTZ, 2010). O MiniNet permite a simulação do Controlador OpenFlow, (chamado ovsc), que tem como característica principal o autoaprendizado dos switchs. Também é possível utilizar outros controladores como POX de maneira remota. Outro componente importante do 44

46 MiniNet é o Open vswitch, um switch virtual que oferece a mesma estrutura para tratamento de pacotes dos switchs com protocolo OpenFlow CONTROLADOR FLOODLIGHT O Floodlight é um projeto de controlador SDN mantido pela Big Switch Networks, e é oriundo do projeto Beacon da Universidade de Stanford. Atualmente é um dos controladores mais utilizados tanto em pesquisas como em desenvolvimento de projetos comerciais, devido principalmente ao suporte a linguagem Java, à instalação fácil, e à sua interface web bem amigável (FLOODLIGHT). O Floodlight é compatível com switchs virtuais, como os existentes no Mininet, e com switchs que tem o protocolo OpenFlow embarcado. Sua estrutura modular, permite o desenvolvimento de APIs, para atender às mais diversas demandas de projeto. E por ser Open Source, é possível utilizar muitas dessas APIs desenvolvidas, facilitando o trabalho dos programadores que podem reutilizar os códigos em seus projetos (FLOODLIGHT) VIRTUALIZAÇÃO Em ambiente OpenFlow também é possível a implementação de soluções que realizem a virtualização da rede física. Atualmente a solução mais utilizada é o FlowVisor (SHERWOOD, 2009). O FlowVisor é como um controlador especial do OpenFlow, que a semelhança de um proxy transparente, controla a utilização dos diversos dispositivos existentes pelos demais controladores em funcionamento na rede. Isto permite que mais de um controlador utilize uma parte dos mesmos recursos da rede, para isso, a ferramenta utiliza o conceito de slice. Um slice representa uma fatia isolada de recursos da rede, como uma rede virtual. Os recursos de infraestrutura da rede controlado pelo FlowVisor e representado através do slice são: a largura de banda, topologia, ou seja quais dispositivos podem ser acessados, e armazenamento de regras na tabela de encaminhamento. Um slice também representa um único controlador em operação na rede. Os slices possuem policies, que indicam para o FlowVisor quais portas de cada dispositivo podem ser utilizadas pelo slice, formando assim a topologia de rede (Vlan) do slice. Desse modo, o FlowVisor pode realizar a intermediação da troca de mensagens entre os controladores e os dispositivos, verificando assim se as mesmas estão de acordo com a 45

47 política estabelecida. Na FIG 2.8 é demostrado o funcionamento do FlowVisor em uma rede OpenFlow: FIG. 2.8: Funcionamento do FlowVisor (SHERWOOD, 2009) (1) O controlador OpenFlow envia as mensagens de controle aos dispositivos existentes na rede; (2) A mensagem enviada pelo controlador é analisada com base nas regras estabelecidas para o Slice, e então são traduzidas para serem enviadas aos dispositivos pelo FlowVisor; (3) A mensagem é então enviada para o dispositivo correspondente; (4) As mensagens trocadas entre os dispositivos e controladores segue de maneira análoga. No ambiente OpenFlow o isolamento de tráfego pode ser implementado basicamente de duas maneiras, através do isolamento no compartilhamento do recurso, quando o objetivo é garantir que um elemento virtual não interfira no desempenho dos demais elementos virtuais. E no isolamento da comunicação entre os nós virtuais, neste caso o objetivo é garantir que a comunicação de uma rede virtual só alcance os nós que de fato pertença a essa rede virtual. Em uma ambiente OpenFlow o isolamento da comunicação é feito 46

48 pelos switchs OpenFlow, e o isolamento dos recursos pelo FlowVisor (SHERWOOD, 2009) (MCKEOWN, 2008). Um outro aspecto importante no FlowVisor é que a divisão do plano de controle da rede é realizado de forma a manter os slices isolados uns dos outros, com isso o FlowVisor executa a virtualização do plano de controle da rede, mas compartilha o plano de dados dos dispositivos da rede. Essa divisão tem o objetivo de compartilhar os cinco recursos primitivos da rede: isolamento de banda, descoberta de topologia, engenharia de tráfego, monitoramento de CPU e controle das tabelas de encaminhamento. Desse modo, o FlowVisor permite que o controle global da rede fique distribuído, porém o gerenciamento dos slices fica centralizado no FlowVisor (SHERWOOD, 2009). 2.4 TRABALHOS RELACIONADOS Trabalhos sobre virtualização, destacam a relevância da separação adequada de banda disponibilizada, topologia e tabela de encaminhamento entre os slices da rede como um dos pontos essenciais para alcançar uma completa virtualização da rede. Em relação a largura de banda, podemos destacar ainda a importância de que cada slice deva possuir sua própria fração da banda, sendo que a falta de mecanismos para realizar o isolamento poderá resultar na interferência entre os diferentes ambientes virtualizados, de modo que uma rede virtual possa comprometer o rendimento de toda a infraestrutura existente (KANADA, 2012) e (SHERWOOD, 2009). Embora o FlowVisor tenha a capacidade de funcionar em um ambiente com diversos controladores, soluções que implementem um gerenciamento completo para alocação de recursos em redes com infraestrutura virtualizada, ainda constituem-se em um problema pouco explorado (TAKAHASHI, 2012). Dos trabalhos que não utilizam o FlowVisor, podemos citar FERNANDES (2010) onde é apresentado um mecanismos de gerenciamento e controle de redes virtualizadas, que utiliza o isolamento dos recursos usados por cada ambiente virtual no domínio de controle Xen, porém apresenta-se como uma solução específica para a plataforma de virtualização Xen e que além disso, necessita da utilização de mecanismo para marcação de pacotes. No trabalho de MIN (2010) é demonstrada uma solução de roteamento em redes virtuais apoiada em NetFPGA (LOCKWOOD, 2007), onde foi desenvolvida uma aplicação para funcionar no NOX controller (GUDE, 2008) composta de quatro entidades: ENVI (special backend server), LAVI (Network and Flow Visualization), Network monitoring 47

49 e QoS routing. Porém, falta um maior detalhamento dos algoritmos implementados no Network monitoring e QoS routing. Em PUSCHITA (2010) é desenvolvido um modelo denominado INAME QoS, cujo objeto é realizar o gerenciamento do QoS de forma descentralizada, onde a escolha do melhor caminho fim-a-fim é realizada pelas próprias entidades envolvidas na transmissão. Porém, falta um melhor detalhamento da solução aplicada para a virtualização da rede. Já em EGILMEZ (2012) é apresentada uma aplicação chamada OpenQoS, cuja proposta é a implantação de um roteamento dinâmico dos fluxos entrantes na rede, a partir dos critérios de QoS. Porém, dos parâmetros de QoS apresentados e previstos para utilização na decisão do roteamento da aplicação, somente a vazão disponível é de fato usada. No trabalho de KASSLER (2012) uma arquitetura para fornecimento de QoS é apresentada. Essa solução utiliza os princípios de QoE em conjunto com o protocolo SIP, visando a tomada de decisão na priorização do tráfego e no roteamento. Porém, o trabalho não apresenta nenhum experimento que comprove a sua viabilidade, e nenhuma tecnologia foi citada para a construção da aplicação proposta além do protocolo SIP. Em MATTOS (2011) é apresentado o OMNI (OpenFlow Management Infrastructure), uma ferramenta de gerenciamento baseada em um sistema multiagentes com o objetivo de fornecer QoS em ambiente OpenFlow. Contudo, nessa solução os agentes OMNI apenas realizam a migração de fluxos entre redes OpenFlow. Existem trabalhos que buscam integrar OpenFlow com outras plataformas como o Xen. Em MATTOS (2012) é apresentado uma solução denominada QFlow. Seu objetivo é implementar QoS através de um controle da utilização dos dispositivos da rede. Contudo, essa solução necessita da instalação desse mecanismo de encaminhamento dedicado em cada switch no domínio 0 do Xen, dificultando o atendimento de múltiplas redes virtuais. Também existem trabalhos que propõem o aperfeiçoamento da ferramenta FlowVisor. Em SALVADORI (2011) é proposta uma solução denominada ADVisor que tem como objetivo implementar um novo mecanismo de isolamento entre as topologias virtuais. Contudo, esta proposta ainda apresenta a necessidade de configuração manual dos equipamentos de rede, não apresentando as alterações do protocolo OpenFlow, o que viabilizariam as configurações dos datapaths pelo FlowVisor, como definição de escalonadores e a alocação de filas. Encontramos trabalhos que fazem uso de algum dos mecanismos utilizados por diferentes versões do FlowVisor (SHERWOOD, 2009), com o objetivo de melhorar o gerenci- 48

50 amento dos recursos entre os diferentes slices em funcionamento na rede. Em MIN (2012) é adotado como solução para alocação de banda a utilização do campo VLAN PCP para marcação dos pacotes. Contudo o próprio autor, informa que o uso do VLAN PCP é apenas uma solução temporária, necessitando que futuras versões implementem um controle específico de QoS. Alem disso, esta solução depende que classes de tráfego definidas sejam configuradas diretamente nos datapaths por comando. O próprio FlowVisor vem sendo aprimorado, como por exemplo a atualização para o protocolo OpenFlow v1.0 que apresentou como inovação o uso da ação enqueue para encaminhar pacotes através de fila configurada em uma porta do datapath, mas que não possui mecanismo para viabilizar controle de recursos. A versão 0.10 do FlowVisor (AL-SHABIBI, 2012), apresenta melhorias no tratamento das mensagens do tipo enqueue, possibilitando a criação de filas junto aos flowspaces, através da definição de novos parâmetros para entradas de fluxos. Ações do tipo output podem também ser redefinidas para ações do tipo enqueue. Contudo, a principal limitação dessa solução ainda está relacionada ao fato de serem necessárias que as definições de fila no datapath sejam configuradas manualmente por aplicações externas, restringindo assim o gerenciamento das classes de serviço pelo FlowVisor. Em ISHIMORI (2012) é apresentado o QoSFlow, uma ferramenta que propõem isolamento dos recursos das redes virtuais no âmbito do plano de encaminhamento, através de uma arquitetura que utiliza dois componentes principais: datapath e controlador QosFlow. Contudo, necessita utilizar uma ferramenta fora do protocolo, como dpctl para configurar as filas dos dispositivos de rede utilizados na arquitetura. Já em GOMES (2013) é realizado a integração do QoSFlow à arquitetura Flowvisor. Nesta solução é desenvolvida fvctlqos, uma API responsável por relacionar as filas dos dispositivos de rede com QoSFlow, aos slices do FlowVisor. Em todos esses trabalhos, as soluções propostas abordam os problemas relacionados ao gerenciamento das redes pela visão tradicional da camada de rede. Não observado as diferentes demandas de transmissão relacionadas aos diferentes tipos de aplicações. Esta dissertação de mestrado propõe um modelo para gerenciamento das redes virtuais em ambiente OpenFlow, onde a principal inovação em relação a propostas anteriores, é o foco no atendimento das demandas de transmissão das aplicações. Para isso, este trabalho apresenta uma ferramenta para complementar o FlowVisor, que utiliza interfaces automatizadas com os elementos da arquitetura OpenFlow. 49

51 3 MODELO DE GERENCIAMENTO PROPOSTO Neste Capítulo apresentaremos o modelo proposto para o gerenciamento da rede com foco na aplicação. Para tanto, a proposta foi dividida em 03 (três) partes: (i) premissas, (ii) modelo de avaliação do slice 10 e (iii) critérios para ajustar o desempenho do slice. 3.1 PREMISSAS Uma das principais inovações do ambiente OpenFlow para provimento de QoS em relação às arquiteturas tradicionais como, IntServ e DiffServ (vide seção do Capítulo 2), é o isolamento do tráfego. Essa característica é obtida através do isolamento do compartilhamento dos recursos da infraestrutura de rede, onde uma rede virtual não interfere no desempenho da outra, garantindo assim que as regras de QoS definidas sejam respeitadas. E também, através do isolamento da comunicação entre os dispositivos de uma rede virtual, os dispositivos pertencentes a uma rede virtual somente alcancem os dispositivos que fazem parte dessa rede virtual. Isto viabiliza que o tráfego de uma rede virtual não prejudique o tráfego de outra, e assim as regras definidas para QoS nas diferentes redes virtuais sejam implementadas sem qualquer tipo de interferência. Observando essas características citadas, o modelo proposto estabelece as seguintes premissas para realizar o gerenciamento de redes virtuais com foco no atendimento das demandas de transmissão das aplicações: A garantia do isolamento da comunicação na rede é realizada pelos dispositivos com o protocolo OpenFlow; O isolamento dos recursos de infraestrutura da rede é garantido pelo FlowVisor; A rede virtual é representada pelo slice do FlowVisor; e Um controlador de rede estará sempre associado a um dos tipos de aplicações, conforme classificação citada na seção do Capítulo representa uma fatia isolada de recursos da rede, como uma rede virtual 50

52 3.2 MODELO DE AVALIAÇÃO DO SLICE O primeiro passo para realizar o gerenciamento da rede, com foco na demanda de transmissão das aplicacões é identificar os principais tipos existentes. Conforme explicado na seção do Capítulo 2, podemos classifica-lás em: (i)elástica, (ii) Não elástica intolerante, (iii) Não elástica tolerante não adaptável, (iv) Não elástica adaptável a faixa e (v) Não elástica tolerante adaptável ao retardo. Outro fator fundamental no gerenciamento da rede, com foco na demanda de transmissão das aplicacões é identificar quais métricas são mais adequadas para avaliação do desempenho, da qualidade, e da confiabilidade das medições sobre o estado da rede, em relação aos tipos de aplicações já mencionados. Neste caso, após análise dos tipos de métricas de desempenho citadas na seção do Capítulo 2, o modelo proposto optou pelas seguintes métricas: Latência: Essa métrica foi selecionada devido à sua maior representatividade na transmissão fim-a-fim, quando comparada às métricas de perda de pacote e jiter. Isto afeta, para mais ou para menos, todos os tipos de aplicações. Outro fator importante, é a possibilidade de subdividir a mensuração da métrica, em partes relacionadas à rota utilizada pela aplicação na rede virtual. Banda: Essa métrica foi selecionada porque impacta, de um modo geral, em todos os tipos de aplicações. E neste trabalho, a banda estará sempre relacionada à largura de banda utilizada. Disponibilidade: Essa métrica foi selecionada, pela sua característica de estar relacionada ao serviço prestado pela rede à aplicação. Outro fator importante, é a possibilidade de subdividir a mensuração da métrica, em partes relacionadas à rota utilizada pela aplicação na rede virtual. Neste rabalho, disponibilidade estará sempre relacionada à disponibilidade da rede O princípio fundamental do QoS, explicado na seção do Capítulo 2, é que aplicações diferentes, necessitam de serviços diferentes (ZHAO, 2000). Sendo assim, buscou-se relacionar os tipos de aplicações com as métricas de desempenho selecionadas, de modo a identificar as métricas essenciais e as desejáveis, com o objetivo de avaliar o desempenho do slice conforme o tipo da aplicação (TAB 3.1). 51

53 TAB. 3.1: Relação do tipos de aplicações com as métricas de desempenho Tipo Aplicação Métrica Essencial Métrica Desejável Elásticas Disponibilidade Banda e Latência Não Elásticas Intolerante Disponibilidade e Latência Banda Não Elásticas Não Adaptável Banda e Latência Disponibilidade Não Elásticas Tolerante Adaptável a Faixa Não Elásticas Tolerante Adaptável ao Retardo Banda Disponibilidade e Latência Latência Disponibilidade e Banda Conseguir avaliar se o slice está atendendo à demanda de transmissão da aplicação, é uma tarefa essencial para garantir a satisfação do cliente sobre o serviço prestado. Partindo dos conceitos explicados nas seções e do Capítulo 2, o modelo proposto buscou realizar um mapeamento a partir dos valores de referência das métricas definidas para a transmissão da aplicação, (x, y e z em TAB 3.2), com o resultado obtido das medições dessas métricas em relação ao slice, (α 1, α 2, α 3 em TAB 3.2). Para isso, no modelo proposto é realizado o cálculo da mediana de cada uma das 03 (três) métricas de desempenho (α 1, α 2, α 3 ), a partir do histórico de medições dessas métricas no intervalo de tempo definido pelo usuário. O resultado é então comparado com cada um dos valores de referência das métricas definidas para a transmissão da aplicação (x, y e z), e utilizadas na criação do slice. Obtendo desse modo uma relação percentual entre as variáveis (α 1, α 2, α 3 ) e (x, y, z), indicando assim a distância entre a expectativa inicial da aplicação sobre o serviço, e a real utilização do slice pela aplicação (TAB 3.2). Partindo dessa relação entre a expectativa e a realidade da utilização do slice, o modelo propõem mensurar o nível de atendimento de cada uma das 03 (três) métricas de desempenho do slice. Para tanto, é proposto um sistema de classificação de estados que utilizou o MOS como modelo (vide seção do Capítulo 2). O estado Underused indica que para a métrica de desempenho avaliada, esta aplicação está subutilizando o slice. Ou seja, o mesmo pode ser ajustado de modo a reduzir a alocação de recurso sem comprometer o desempenho da aplicação na rede. O estado Right indica que para a métrica de desempenho avaliada, o slice está atendendo à demanda da transmissão da aplicação. É 52

54 o estado ideal, onde todos os slices devem estar. Já os estados Warning, Critical e Down indicam, em níveis diferentes de preocupação, que para a métrica de desempenho avaliada o slice não está atendendo a demanda de transmissão da aplicação, necessitando realizar algum tipo de ajuste no slice ou em suas policies 11, de modo a aumentar e/ou melhorar o recurso previsto para a aplicação (TAB 3.2). TAB. 3.2: nível de atendimento do slice por métrica de desempenho da rede Estado \Métrica x =Banda y=latência z=disponibilidade Underused α 1 0, 4x α 2 0, 4y 0, 4α 3 z Right 0, 4x < α 1 0, 8x 0, 4y < α 2 0, 8y 0, 4α 3 < z 0, 8α 3 Warning 0, 8x < α 1 0, 9x 0, 8y < α 2 0, 9y 0, 8α 3 < z 0, 9α 3 Critical 0, 9x < α 1 x 0, 9y < α 2 y 0, 9α 3 < z α 3 Down x > α 1 y > α 2 α 3 < z Como exemplo da aplicabilidade dessa avaliação podemos supor que o slice A, vinculado a aplicação A, foi criado prevendo 10 Mbps como valor de referência da métrica de desempenho largura de banda (x). Após a utilização do slice por um intervalo de tempo t, resolveu-se avaliar a sua utilização pela aplicação. Para tanto, foi realizado o cálculo da mediana (α 1 ), em um intervalo de tempo t, obtendo-se o resultado 8 Mbps. Isso representa, segundo a tabela TAB 3.2, que pela métrica de desempenho largura de banda (x) o slice A encontra-se no estado Right [α 1 (8) 0, 8x( = 8)]. Os valores estabelecidos para os limites de classificação entre os estado, foram definidos de acordo com uma proporcionalidade encontrada na maioria dos sistemas para monitoramento de redes tradicionais, como o Nagios (BARTH, 2008). Contudo, esses limites podem ser ajustados dentro do código da ferramenta a fim de atender a demandas específicas das equipes de gerenciamento da rede. A partir da mensuração do nível de atendimento do slice por cada uma das 03 (três) métricas de desempenho, o modelo proposto estabelece o índice de atendimento da aplicação. Esse índice representa a média da avaliação das métricas de desempenho, e indica a avaliação geral do slice para a aplicação (TAB 3.3). 11 representam no FlowVisor quais dispositivo de rede, (incluindo a especificação de portas), podem ser utilizadas pelo slice 53

55 O índice é definido com base na importância da métrica de desempenho para a aplicação. Ou seja, métricas de desempenho consideradas essenciais tem peso 2 (dois) e desejáveis tem peso 1 (um). Também é definido um valor para cada estado da métrica de desempenho, que varia de 1 (um) para estado Down até 5 (cinco) para o estado Underused. Logo, quanto mais próximo de 4 (quatro) for o índice melhor é o desempenho do slice para a aplicação (TAB 3.3). O índice serve para priorizar a busca de soluções que melhorem o desempenho do slice para a aplicação. Através de uma indicação para a equipe de administração da rede, sobre quais métricas de desempenho devem ser melhoradas prioritariamente. TAB. 3.3: Índice de atendimento da Aplicação Tipo Aplicação Índice Elásticas Não Elásticas Intolerante Não Elásticas Não Adaptável Não Elásticas Tolerante Adaptável a Faixa Não Elásticas Tolerante Adaptável ao Retardo [(Estado Métrica Disponibilidade 2) + (Estado Métrica Banda) + (Estado Métrica Latência)]/4 [(Estado Métrica Disponibilidade 2) + (Estado Métrica Banda) + (Estado Métrica Latência 2)]/5 [(Estado Métrica Disponibilidade ) + (Estado Métrica Banda 2) + (Estado Métrica Latência 2)]/5 [(Estado Métrica Disponibilidade) + (Estado Métrica Banda 2) + (Estado Métrica Latência)]/4 [(Estado Métrica Disponibilidade) + (Estado Métrica Banda) + (Estado Métrica Latência 2)]/4 Conforme os conceitos sobre Acordo de Nível de Serviço citados na seção do Capítulo 2, é possível observar que o índice de atendimento da aplicação também pode ser utilizado como um indicador de qualidade do SLA. Sendo assim, pode-se estabelecer critérios mais flexíveis do SLA, de modo a permitir ajustes na disponibilidade dos recursos, com o objetivo de atender à real necessidade de transmissão da aplicação. Como por exemplo, em casos onde os valores de referência das métricas de desempenho, estabelecidos durante a criação do slice, indicam que os recursos disponibilizados não estão atendendo a real demanda de transmissão da aplicação, ou estejam superdimensionados. Permitindo assim, uma tarifação também dinâmica e mais justa. 54

56 Exemplificando essa situação, conside um slice B, vinculado a uma aplicação do tipo Não Elástica, Tolerante, Adaptável a faixa. Poderia ser incluído uma cláusula na SLA que previse uma avaliação de desempenho do slice, dentro de um intervalo t. Onde toda vez que o índice de atendimento da aplicação(w) ficasse igual ou menor a três (w 3), fosse autorizado um aumento da largura de banda (métrica considerada essencial para o tipo de aplicação). Ou ainda, um redução da largura de banda, caso o índice de atendimento da aplicação ficasse igual a cinco (w = 5). O aumento e a redução dos recursos, é realizado de acordo com os critérios estabelecidos no modelo proposto para melhorar o desempenho do slice. 3.3 CRITÉRIOS PARA AJUSTAR O DESEMPENHO DO SLICE Após a realização da avaliação de desempenho do slice sob a perspetiva da aplicação, o modelo apresenta a possibilidade da realização, automatizada, de ajuste no slice e em suas policies, conforme o nível de atendimento obtido pela métrica de desempenho, e explicado no modelo de avaliação do slice (vide TAB 3.2), de modo que após o ajuste a métrica fique dentro do limite estabelecido para o estado Right (vide TAB 3.2) LARGURA DE BANDA Para a métrica de desempenho largura de banda, o modelo apresentado propõe que o novo valor de referência dessa métrica para o slice, seja ajustado de acordo com o valor da mediana (α 1 ) obtido durante a avaliação do nível de atendimento da métrica (vide TAB 3.2). De modo que após o ajuste, o valor de referência fique dentro dos limites estabelecidos para a classificação da métrica no estado Right (vide TAB 3.2). Conforme o algoritmo AjustarBandaslice (FIG 3.1), primeiramente é verificado o estado da métrica. Nos casos classificados como Down, Critical ou Warning o novo valor da métrica será [1.3 α 1 ], Já para os casos classificados como underuser o valor será [2.3 α 1 ]. Esse critério busca um equilíbrio no ajuste da largura de banda, evitando que situações atípicas de utilização do slice pela aplicação, modifique radicalmente a divisão existente dos recursos da rede entre os demais slices. Exemplificado podemos supor que o slice A, criado com 10 Mbps de largura de banda (valor de referência da métrica = x), obteve o valor de mediana (α 1 ) = 9 Mbps, após cálculo em um intervalo de tempo t, referente a avaliação da utilização do slice. Esse resultado 55

57 classifica a métrica no estado Warning [α 1 (9) 0, 9(0, 9 10 = 9)]. Pelo algoritmo, o novo valor de referência da largura de banda é 11, 7 Mbps [9 1, 3]. Isso representa que a métrica de desempenho largura de banda do slice A, passará a ser classificada no estado Right [α 1 (9) 0, 8x(0, 8 11, 7 = 9, 36)]. Dentro do mesmo exemplo, caso o valor da mediana (α 1 ) fosse igual a 4 Mbps, sua classificação seria no estado Underuser [α 1 (4) 0, 4(0, 4 10 = 4)], logo o ajuste seria de 9, 2 Mbps [4 2, 3], e a métrica reclassificada no estado Right [0, 4x(0, 4 9, 2 = 3, 68) < α 1 (4) 0, 8x(0, 8 9, 2 = 7, 36)]. Nesses dois exemplos tivemos um aumento de 17% (dezessete por cento), e uma redução de 9% (nove por cento) respectivamente em relação ao valor original da largura de banda. Ou seja, um ajuste diferenciado para cada situação de modo a impactar o menos possível a divisão dos recursos entre os slices. FIG. 3.1: Algoritmo 1 para ajuste a largura de Banda 56

58 O algoritmo prevê ainda a verificação da disponibilidade de banda nos links utilizados pelo slice, antes da realização do ajuste. Essa verificação acontece através de consulta às policies do slice em comparação com as informações registradas na base de dados, referente aos dispositivos de rede e demais slices existentes. O modelo também estabelece que ao ajustar o valor da largura de banda do slice no FlowVisor, o valor de referência da métrica seja atualizado com o mesmo valor. Mantendo assim uma coerência entre o modelo e o slice de modo que ao realizar uma nova avaliação de desempenho o estado de métrica seja atualizado e, consequentemente, o índice de atendimento da aplicação seja atualizado LATÊNCIA Para a métrica de desempenho Latência, o modelo proposto estabelece uma análise das rotas utilizadas pelo slice, com o objetivo de identificar os trechos que apresentam desempenho insatisfatório. Conforme o algoritmo AnalisarPoliticalatencia (FIG 3.2), primeiramente é realizado o cálculo da mediana da latência para cada trecho de enlace vinculado às policies do slice, utilizando para isso o mesmo intervalo de tempo t utilizado para calcular a mediana da métrica latência do slice (vide variável α 2 da TAB 3.2). Feito isso, é disponibilizado informações sobre o slice, o valor de referência da métrica (y), enlace e a mediana do enlace. Permitindo assim a identificação dos trechos que estão abaixo do valor de referência estabelecido para métrica (variável y da TAB 3.2). Após isso, é possível realizar a troca de trechos, produzindo desse modo ajustes nas policies do slice, ou ajustar o valor de referência da métrica de desempenho, em virtude da sua percepção sobre a impossibilidade de atingir o valor previsto, seja pela falta de recursos ou prioridade do slice, (no caso prioridade da aplicação em funcionamento sobre o slice). Também é possível adotar as duas soluções, neste caso após a substituição dos trechos desejados, e em consequência, o ajuste de algumas das policies do slice, atualiza-se o valor de referência da métrica, conforme a disponibilidade do recurso. Então, no próximo intervalo de tempo t, realiza-se uma nova avaliação de desempenho do slice, gerando assim uma nova classificação da métrica conforme TAB 3.2. E, consequentemente, um novo valor para o índice de atendimento da aplicação. Antes da efetivação do ajuste na policy, é verificado se os dispositivo de rede associados ao enlace, já não esá associado a um outro slice. 57

59 FIG. 3.2: Algoritmo 2 para analisar policies do slice por latência DISPONIBILIDADE DA REDE Na métrica de desempenho disponibilidade da rede, o modelo proposto procura realizar uma análise individualizada dos dispositivos de rede que fazem parte das policies do slice. No algoritmo AnalisarPoliticaDisponibilidade (FIG 3.3), primeiramente é realizado o cálculo da disponibilidade de cada dispositivo de rede que pertence às policies do slice. Onde a disponibilidade do dispositivo é definida pela fórmula [(uptime downtime)/downtime] (vide seção do Capítulo 2). E o intervalo de tempo usado para cálculo é o mesmo t utilizado para calcular a disponibilidade do slice (variável α 3 da 58

60 TAB 3.2). Uptime representa o somatório dos tempos previstos de funcionamento do slice, dentro desse mesmo intervalo de tempo t. E o downtime significa o somatório dos tempos de indisponibilidade do dispositivo, no mesmo intervalo de tempo usado para calcular o uptime. A indisponibilidade dos dispositivos de rede do slice é obtida através do monitoramento de mensagens de controle trocadas entre o controlador e os dispositivos de rede. Após o cálculo, o algoritmo apresenta uma relação com a disponibilidade de todos os dispositivos utilizados no slice, possibilitando a identificação dos equipamentos que estão abaixo do valor de referência estabelecido para métrica. Desse modo, o usuário pode decidir entre a troca dos dispositivos com desempenho abaixo do valor de referência, produzindo desse modo ajustes nas policies do slice. Ou ajustar o valor de referência da métrica, em virtude da sua percepção sobre a situação dos recursos, ou prioridade do slice em relação a outros slices, (ou seja a prioridade da aplicação em funcionamento sobre o slice). Também é possível adotar as duas soluções, neste caso substitui-se apenas os equipamentos desejados, e ajusta-se o valor de referência da métrica. Então, no próximo intervalo de tempo t, realiza-se novamente uma avaliação de desempenho do slice, que produzirá uma nova classificação para a métrica, conforme TAB 3.2, e consequentemente, um novo valor para o índice de atendimento da aplicação. Antes da efetivação do ajuste na policy, é verificado se a porta do dispositivo de rede já não esá associado a um outro slice. 59

61 FIG. 3.3: Algoritmo 3 para analisar policies do slice por disponibilidade da rede 60

62 4 GIROFLOW Neste capítulo, apresentaremos a ferramenta desenvolvida para a validação do modelo proposto. Chamamos essa ferramenta de GiroFlow (ARAUJO, 2014), que significa Gerenciador para Infraestrutura de Redes virtuais em ambiente OpenFLOW. O GiroFlow foi apresentado durante 10th International Conference on Network and Service Management, no Workshop on Management of SDN and NFV Systems. O capítulo foi dividido em 04 (quatro) seções: (i) Arquitetura, (ii)base de dados, (iii) módulos da ferramenta e (iv) Ferramentas utilizadas no desenvolvimento. 4.1 ARQUITETURA A arquitetura da Ferramenta GiroFlow funciona como uma camada sobre o controlador da rede e o FlowVisor, potencializando as funções desses componentes da arquitetura OpenFlow, através da utilização de interfaces automatizadas (FIG 4.1). FIG. 4.1: Arquitetura GiroFlow Camada As Interfaces com os atores citados na FIG 4.1 é detalhada na FIG 4.2 e acontece da seguinte maneira: 61

63 Controlador GiroFlow: A interface com o controlador ocorre através da captura das mensagens de controle trocadas entre os dispositivos da rede e o controlador OpenFlow. O controlador, em modo debug, grava essas mensagens em um arquivo. Este arquivo é verificado constantemente pelo programa do módulo Fault Management responsável por detectar mensagens relacionadas a falha em enlace ou dispositivo, com o objetivo de atualizar o banco de dados da ferramenta. Ao atualizar a base de dados é gerado um evento no módulo Fault Management disponível para o usuário (FIG 4.2). GiroFlow FlowVisor: Já a interface com FlowVisor ocorre através da execução do comando de linha fvctl, emitido pelo GiroFlow em diferentes partes da ferramenta. Seja no momento do cadastramento inicial da aplicação visando criação do slice e suas policies. Ou então quando da realização de rotinas relacionadas com avaliação do desempenho do slice, que produzem algum momento ajuste no slice ou em suas policies (FIG 4.2). GiroFlow User: A interface com o usuário ocorre através inserção de dados, bem como a consulta de informações gerenciais (FIG 4.2). FIG. 4.2: Arquitetura GiroFlow Interfaces 62

64 4.2 BASE DE DADOS O objetivo da base de dados utilizada pelo GiroFlow, é armazenar as informações necessárias à implementação do modelo proposto, bem como das interfaces com o FlowVisor e os Controladores. Para isso, buscou-se mapear os principais elementos da infraestrutura de uma rede, relacionados com o gerenciamento do slice (FIG 4.3). FIG. 4.3: Diagrama de Entidade e Relacionamento As entidades citadas no Diagrama de Entidade e Relacionamento significam: Owner: É o usuário responsável pelo slice da aplicação; Resource: Representa qualquer dispositivo da rede. Contém as informações necessárias a criação das policies 12 ; Aplication: É o slice13, contém todas as informações relacionadas a aplicação como: seu tipo, dados do controlador (IP, Port), e valores de referência das métricas de desempenho; 12 representam no FlowVisor quais dispositivo de rede, (incluindo a especificação de portas), podem ser utilizadas pelo slice 13 representa uma fatia isolada de recursos da rede, como uma rede virtual 63

65 History Metrics: Armazena o histórico de medições das métricas de desempenho relacionadas ao slice; History Fault resource: Armazena o histórico de indisponibilidades dos dispositivos da rede; Performance: Armazena o resultado da avaliação, conforme previsto no modelo de gerenciamento; Link: Registra os tipos de links utilizados na rede; Enlace: Registra os enlaces existentes na rede; Route: Registra as rotas utilizadas pelo slice, e juntamente com as entidades Enlace e Resource produz as policies do slice. 4.3 MÓDULOS O GiroFlow é estruturado em módulos conforme as áreas funcionais do modelo de referência OSI para gerenciamento de rede, explicadas na seção do Capítulo 2. Sendo que nesta versão da ferramenta não foi construído o módulo Security Mangement, por entendermos que o foco principal do trabalho é o gerenciamento da rede virtual em relação ao seu desempenho, ficando o desenvolvimento desse módulo para trabalhos futuros MÓDULO CONFIGURATION MANAGEMENT : O módulo de gerenciamento de configuração é responsável por registrar todas as informações relacionadas às demandas da aplicação, visando a criação do slice inicial no FlowVisor, bem como de todas as informações necessárias ao seu gerenciamento, como por exemplo os valores de referência das métricas de desempenho. Também é necessário o registro de todos os dispositivos da rede e enlaces, assim como as rotas que o slice utiliza, e o usuário responsável pelo slice, para que seja realizada a criação das policies do slice. Na FIG 4.4 é apresentada a tela de cadastramento do slice de uma aplicação do tipo elástica, de nome internet, tendo como responsável Tarcisio, e valores de referência para largura de banda = 100 Mps, latência = 4 ms e disponibilidade = 80%, também é registrado informações sobre o controlador como IP, Port e protocolo. 64

66 FIG. 4.4: Tela do módulo Configuration management MÓDULO FAULT MANAGEMENT : O módulo de gerenciamento de falha tem como meta monitorar as mensagens de controle trocadas entre o controlador e os dispositivos de rede, a fim de detectar eventos relacionados a indisponibilidade de dispositivos ou enlaces que impactam o funcionamento do slice. É subdividido em duas partes, uma instalada no mesmo computador do controlador. E outra no menu principal da ferramenta Conforme já explicado na seção 4.1 desse capítulo, referente à arquitetura do GiroFlow, o programa instalado junto ao controlador verifica ininterruptamente o arquivo gerado pelo próprio controlador a fim de atualizar a base de dados da ferramenta desenvolvida sobre eventos de falha em dispositivos ou enlaces. Já o programa em funcionamento no menu principal fornece as informações sobre os slices e suas policies que foram afetados por algum dos eventos ocorridos, bem como possibilidades de solução por parte do administrador da ferramenta, como por exemplo a opção de reconfigurar as rotas na ferramenta proposta, o que gera a execução de comandos no FlowVisor para a reconfiguração das policies do slice afetado. 65

67 Na FIG 4.5 é apresentado um exemplo do arquivo gerado pelo controlador contendo as mensagens de falhas em enlace e dispositivos, caracterizado nas palavras Down e disconnected, e quando a falha termina aparece a mensagem de controle com as palavras Up (que não aparece na FIG 4.5, mas faz parte da lógica do programa), e connected (que aparece na FIG 4.5) FIG. 4.5: Tela do Módulo Fault managemnt MÓDULO ACCOUNTING MANAGEMENT O módulo de gerenciamento de contabilização tem o objetivo de registar o histórico de medições das métricas de desempenho definidas no modelo conceitual. Este módulo é composto por três programas. Um programa regista as medições das métricas de desempenho de cada slice. O outro programa regista as medições da latência de cada enlace. E o último programa exibe o histórico de falhas dos dispositivos de rede registrados pelo módulo de gerenciamento de falha. Todas essas informações registradas no módulo de gerenciamento de contabilização são posteriormente utilizadas para os cálculos de avaliação de desempenho do slice, no módulo de gerenciamento de performance. Na FIG 4.6 temos o exemplo do cadastramento do histórico de medições das métricas de desempenho largura de banda, latência e disponibilidade, relacionadas ao slice da aplicação chamada de internet medida em 02 de dezembro de

68 FIG. 4.6: Tela do Módulo Accounting management MÓDULO PERFORMANCE MANAGEMENT O módulo de gerenciamento de performance possibilita ao administrador da rede realizar uma análise do desempenho do slice em relação ao atendimento das demandas da aplicação, conforme estabelecido no modelo de gerenciamento proposto que foi apresentado no Capítulo 3. Além de permitir o acesso as rotinas relacionadas ao ajuste das métricas de desempenho. Possui as seguintes opções: Realizar cálculo de desempenho do slice, conforme definições estabelecidas na seção 3.2 do Capítulo 4; Ajustar a banda disponível do slice, conforme explicado na seção do Capítulo 3; Consultar o índice de disponibilidade de cada um dos dispositivos que fazem parte das policies do slice, e a possibilidade de realizar a substituição desses equipamentos nas rotas do slice, conforme explicado na seção do capítulo 3; 67

69 Consultar a mediana de cada um dos enlaces que fazem parte das policies do slice, e a possibilidade de realizar modificações nas rotas do slice, conforme explicado na seção do Capítulo 3; FIG. 4.7: Tela do Módulo Performance management Na FIG 4.7 temos um exemplo do resultado do cálculo de desempenho do slice. Na tela aparecem 4 (quatro) slices chamados de internet, sistema de pessoal, vídeo conferência e sistema de saúde, seguido de informações relacionadas às métricas de desempenho na seguinte sequência: Mediana da métrica largura de banda e sua classificação (vide TAB 3.2 do Capítulo 3); Mediana da métrica latência e sua classificação (vide TAB 3.2 do Capítulo 3); Mediana da métrica disponibilidade da rede e sua classificação (vide TAB 3.2 do Capítulo 3) e; Índice de desempenho da aplicação (vide TAB 3.3 do Capítulo 3). 68

70 Nessa tela ainda é possível observar o botão Slice FlowVisor que é utilizado para ajustar a largura de banda do slice, conforme os critérios estabelecidos na seção do Capítulo PARAMETRIZAÇÃO Existe ainda na ferramenta, um programa utilizado para parametrizar o intervalo de tempo t usado nos diversos cálculos do modelo proposto, como por exemplo o cálculo da mediana das métricas de desempenho. Esta opção deve ser configurada antes da execução dos programas do módulo gerenciamento de performance. 4.4 FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO A ferramenta desenvolvida foi construída utilizando a linguagem de programação Java. Essa escolha ocorreu pelo fato do controlador utilizado para realização dos experimentos ser o Floodlight, desenvolvido também em Java. Além disso, a licença de uso para ambos é OpenSource. Outra vantagem é a existência de bibliotecas como OpenFlow Java 1.0.1, que podem ser utilizadas para integração com outras ferramentas, visando futuras melhorias no GiroFlow. O SGBD escolhido foi o Apache Derby, o mesmo utilizado pelo FlowVisor, e também nativo da linguagem Java, sua licença também é OpenSource. 69

71 5 RESULTADOS Neste capítulo apresentaremos as simulações realizadas na ferramenta desenvolvida (GiroFlow). O objetivo destes experimentos é validar o modelo proposto, através de situações que representam as dificuldades encontradas pelas equipes de gerência de redes, durante o processo de administração das redes virtuais. Para isso, o capítulo foi dividido em 03 (três) partes: (i) ambiente de teste, (ii) cenários, e (iii) experimentos. 5.1 AMBIENTE DE TESTE O ambiente de teste utilizou 02 (dois) computadores, interligados em rede através de um cabo crossover. Sendo que no primeiro cenário foi utilizado apenas o primeiro computador. Já no segundo cenário foram utilizados os dois computadores. Na primeira máquina, o processador é um Intel i7, com 4GB de memória RAM, e Sistema Operacional Ubuntu LTS. Nesse computador foi instalado o controlador Floodlight (vide seção do Capítulo 2) o SGBD Apache Derby 14, e o Mininet (vide seção do Capítulo 2),. Na segunda máquina, o processador é um Dual Core com 4GB de memória RAM, e Sistema Operacional Ubuntu LTS. Nesse computador foi instalado apenas o controlador Floodlight. Foi construído um Script em Python com o objetivo de criar os datapaths 15 dentro do Mininet. Simulando desse modo uma rede gerenciada pelo FlowVisor, contendo 15 (quinze) dispositivos de rede (recursos) que serão compartilhados entre os slices, conforme os cenários da FIG 5.1 e FIG CENÁRIOS Visando a realização dos experimentos foram construídos 02(dois) centários. No primeiro foi utilizando apenas um controlador na rede, já no segundo foram usados 02 (dois) controladores ao mesmo tempo, no qual cada controlador representa um slice. 14 O SGBD Derby é um Sistema Gerenciador de Banco de Dados relacional OpenSource baseado em SQL e utilizado pelo FlowVisor e também no desenvolvimento do GiroFlow 15 datapath é um switch lógico emulado no Mininet 70

72 5.2.1 CENÁRIO 01: Neste cenário, FIG 5.1, a rede é gerenciada pelo FlowVisor, em operação na porta 6634, com os comandos de linha da aplicação fvctl sendo executados na porta O controlador Floodlight foi configurado para modo debug usando a porta 6642, e sua página web sendo acessada na porta Os 15(quize) datapaths (S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14 e S15 ) são simulados utilizando o Mininet. FIG. 5.1: Rede com 01 controlador CENÁRIO 02: Neste cenário, FIG 5.2, são utilizados 02 (dois) computadores (A e B). No computador A, ficou instalado o FlowVisor, em operação na porta 6634, com os comandos de linha da aplicação fvctl sendo executados na porta O controlador Floodlight foi configurado para modo debug usando a porta 6642, e sua página web sendo acessada na porta Os 15(quize) datapaths são simulados utilizando o Mininet. Já no computador B, ficou instalado o outro controlador Floodlight configurado para modo debug na porta 6643, e sua página web sendo acessada na porta 8081, a semelhança do computador A. O módulo principal do GiroFlow ficou instalado no computador A, e o programa do módulo Fault management, para obter os dados do controlador, foi instalado em ambos computadores rodando em modo background. 71

73 FIG. 5.2: Rede com 02 controlador 5.3 EXPERIMENTOS EXPERIMENTO 01: VALIDAÇÃO DAS INTERFACES Nesse experimento utilizou-se o cenário 01. Primeiramente foi testada a interface com o FlowVisor através da execução automática dos comandos da aplicação fvctl para a criação do slice e suas policies, a partir dos dados lançados na ferramenta. Em seguida testou-se a interface com o controlador Floodlight, através da inserção de falhas no simulador Mininet em datapaths relacionados ao slice citado (ou seja alguns datapaths foram desconectados temporariamente via console do Mininet). Após a execução do teste, foi possível observar que o controlador Floodlight passou a receber mensagens de falha relacionada aos datapaths desconectados, conforme definido nas policies do slice criado pelo GiroFlow, provando desse modo o funcionamento da interface com o FlowVisor. E também foi constatado que a base de dados do GiroFlow foi atualizada com as mensagens de falha relacionada aos datapaths desconectados, provando o funcionamento da interface com o controlador da rede. 72

74 5.3.2 EXPERIMENTO 02: ANÁLISE DE PERFORMANCE DE 01 (UM) SLICE Nesse experimento utilizou-se o cenário 01. Para fazer essa simulação, foi criado dentro do GiroFlow um registro referente a 01 (um) slice relacionado a uma aplicação do tipo elástica chamada Internet, com rota utilizando apenas enlaces entre os datapaths de cor verde (vide FIG 5.1), tendo os seguintes valores de referência para as métricas de desempenho: largura de banda = 3 Mbps, latência = 4 ms e disponibilidade da rede = 85% 16. Também foi inserido no GiroFlow 30 (trinta) registros relativos ao histórico de medições das métricas de desempenho citadas. Após a execução da rotina para avaliação de desempenho do slice, foi possível observar na ferramenta que nenhuma das métricas de desempenho encontrava-se no estado ideal (Right vide TAB 3.2), conforme demostrado na tabela comparativa TAB 5.1. O valor de referência representa os parâmetros utilizados na criação do slice. Já a mediana é o resultado dos cálculos realizados na ferramenta, dentro de um intervalo de tempo t, a partir do histórico existentes, ou seja os 30 (trinta) registros inseridos e citados anteriormente. E o estado, representa a avaliação do desempenho por métrica do slice realizado pela ferramenta, conforme explicado na seção 3.2 do Capítulo 3. Com o resultado obtido por cada métrica de desempenho (vide TAB 5.1), o índice de atendimento da aplicação ficou em 2, 75 (dois vírgula setenta e cinco). TAB. 5.1: Análise desempenho do slice Tipo indicador Banda Latência Disponibilidade valor referência 4 Mbps 3 ms 80% Mediana 3, 31 Mbps 2, 97 ms 89% Estado Warning Critical Warning No gerenciamento tradicional de redes, a equipe de gerência ao constatar que o desempenho da rede virtual não está atendendo às demandas de transmissão da aplicação do cliente, provavelmente optaria pela solução de aumentar a largura de banda. Tendo essa proposta de solução, foi executada na ferramenta a rotina de ajuste da largura de banda do slice, onde a lógica da rotina foi explicada na seção do Capítulo Dados utilizados na criação do slice no FlowVisor 73

75 Após a execução da rotina citada o valor da largura de banda do slice aumentou para 4, 3 Mbps, conforme demostrado na tabela comparativa TAB 5.2. Onde o valor de referência representa os parâmetros da criação do slice, e nessa caso exibe o novo valor da largura de banda, porém manteve os demais parâmetros. A mediana não é modificada, pois o intervalo de tempo t utilizado na análise de desempenho, bem como o histórico de medições não foram modificados. E apenas o estado da métrica largura de banda foi modificado para o estado ideal (Right), [0, 4x(0, 4 4, 3 = 1, 72) < α 1 (3, 31) 0, 8x(0, 8 4, 3 = 3, 44)], mantendo a mesma avaliação para as demais métricas de desempenho. Com o novo resultado obtido, o índice de atendimento da aplicação aumentou para 3 (três). TAB. 5.2: Análise desempenho do slice - Ajuste da largura de banda Tipo indicador Banda Latência Disponibilidade valor referência 4, 3 Mbps 3 ms 80% Mediana 3, 31 Mbps 2, 97 ms 89% Estado Right Critical Warning Porém, em uma rede gerenciada pelo modelo proposto, a equipe de gerência ao constatar que o desempenho da rede virtual não está atendendo as demandas de transmissão da aplicação, observaria que o slice está relacionado a uma aplicação do tipo elástica, e que sua métrica de desempenho essencial é a disponibilidade da rede. Por isso, a transação anterior foi desfeita, sendo então executado na ferramenta as rotinas de ajuste nas policies do slice, através da substituição dos datapaths com índice de disponibilidade abaixo do valor de referência, conforme explicado na seção do Capítulo 3. Após executar a rotina citada, a média do índice de disponibilidade de todos os dispositivos componentes das policies do slice ficou em 100%, conforme demostrado na tabela comparativa TAB 5.3. E como o histórico de medições, utilizado para calcular a mediana da disponibilidade de rede para o slice não pode ser modificado, será necessário executar novamente a rotina de análise de performance, em um novo intervalo de tempo t, para que o novo histórico possa produzir uma nova mediana com valor de 100%, classificando desse modo a métrica no estado ideal Right (vide TAB 5.3). Com isso, o índice de atendimento da aplicação aumentará para 3, 2 (três vírgula dois), desde que as demais métricas permaneçam com as mesmas avaliações obtidas na tabela comparativa TAB

76 TAB. 5.3: Análise desempenho do slice - Ajuste da Disponibilidade da rede Tipo indicador Banda Latência Disponibilidade valor referência 4 Mbps 3 ms 80% Mediana \índice 1 3, 31 Mbps 2, 97 ms 100% \100% Estado Warning Critical Right AVALIAÇÃO DO EXPERIMENTO 02 Ao analisar o resultado do experimento 02, é possível observar que o índice de atendimento da aplicação ficou maior na segunda solução implementada (FIG 5.3). Indicando que o modelo proposto pode auxiliar as equipes de gerência de redes, na identificação das ações prioritárias para melhoria do desempenho da rede virtual (slice), bem como ser utilizado como indicador de qualidade do SLA, porque viabiliza o estabelecimento de critérios para a realização dinâmica de ajuste na porópia SLA. Seja para atender a necessidade de transmissão da aplicação, ou pela impossibilidade de atende-lá, por limitações de recursos ou por motivo de prioridade. No caso do experimento 02, o ajuste dinâmico na SLA fica evidenciado no momento em que o valor de referência da largura de banda é atualizado, pois esse valor é utilizado como parâmetro para a criação do slice. FIG. 5.3: Comparação das soluções utilizadas 1 média dos índices de disponibilidade dos dispositivos de rede relacionados a policies do slice 75

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

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

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

Serviços de Comunicações. Serviços de Comunicações. Módulo 7 Qualidade de Serviço em redes IP. condições de rede existentes em cada momento

Serviços de Comunicações. Serviços de Comunicações. Módulo 7 Qualidade de Serviço em redes IP. condições de rede existentes em cada momento Módulo 7 Qualidade de Serviço em redes IP 7.1. O porquê da Qualidade de Serviço 7.2. Mecanismos para QoS 7.3. Modelo de Serviços Integrados - IntServ 7.4. Modelo de Serviços Diferenciados - DiffServ 1

Leia mais

QoS em Redes IP: Arquitetura e Aplicações

QoS em Redes IP: Arquitetura e Aplicações QoS em Redes IP: Arquitetura e Aplicações Mário Meireles Teixeira mario@deinf.ufma.br Motivação Atualmente, funcionam sobre as redes IP aplicações cujos requisitos elas não foram projetadas para atender

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

Gerenciamento de redes

Gerenciamento de redes Gerenciamento de redes Gerenciamento de Serviços Gerenciamento de QoS (Qualidade de serviço) slide 1 Qualidade de serviços: aplicações de multimídia: áudio e vídeo de rede ( mídia contínua ) QoS rede oferece

Leia mais

5º Semestre. AULA 02 Introdução a Gerência de Redes (Arquitetura e Áreas de Gerenciamento)

5º Semestre. AULA 02 Introdução a Gerência de Redes (Arquitetura e Áreas de Gerenciamento) Disciplina: Gerência de Redes Professor: Jéferson Mendonça de Limas 5º Semestre AULA 02 Introdução a Gerência de Redes (Arquitetura e Áreas de Gerenciamento) 2014/1 Agenda de Hoje Evolução da Gerência

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

Além do melhor esforço

Além do melhor esforço Além do melhor esforço Redes Multimídia Prof. Emerson Ribeiro de Mello Instituto Federal de Santa Catarina IFSC campus São José mello@ifsc.edu.br 25 de agosto de 2011 1 / 42 Sumário 1 Além do melhor esforço

Leia mais

Redes WAN Conceitos Iniciais. Prof. Walter Cunha

Redes WAN Conceitos Iniciais. Prof. Walter Cunha Redes WAN Conceitos Iniciais Prof. Walter Cunha Comutação por Circuito Todos os recursos necessários em todos os subsistemas de telecomunicação que conectam origem e destino, são reservados durante todo

Leia mais

1.1 Transmissão multimídia em redes

1.1 Transmissão multimídia em redes 1.1 Transmissão multimídia em redes Pode-se dividir a parte de transmissão multimídia em redes de computadores como mostra a figura 1, ou seja, a parte de conferência (que requer interatividade) e a parte

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

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

REDES VIRTUAIS PRIVADAS

REDES VIRTUAIS PRIVADAS REDES VIRTUAIS PRIVADAS VPN Universidade Católica do Salvador Curso de Bacharelado em Informática Disciplina: Redes de Computadores Professor: Marco Antônio Câmara Aluna: Patricia Abreu Página 1 de 10

Leia mais

ANEXO II PROJETO BÁSICO - INTERNET

ANEXO II PROJETO BÁSICO - INTERNET 1. Objetivo 1.1. Contratação de serviços para fornecimento de uma solução de conexão IP Internet Protocol que suporte aplicações TCP/IP e disponibilize a PRODEB acesso a rede mundial de computadores Internet,

Leia mais

Apostila de Gerenciamento e Administração de Redes

Apostila de Gerenciamento e Administração de Redes Apostila de Gerenciamento e Administração de Redes 1. Necessidades de Gerenciamento Por menor e mais simples que seja uma rede de computadores, precisa ser gerenciada, a fim de garantir, aos seus usuários,

Leia mais

Serviços Diferenciados

Serviços Diferenciados Qualidade de Serviço I Serviços Diferenciados rffelix70@yahoo.com.br Níveis de QoS Reserva de Recursos Fim-a-Fim Protocolo de Sinalização. Priorização de Recursos de Acordo com SLAs préestabelecidos. O

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

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

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

QoS for voice applications

QoS for voice applications QoS for voice applications MUM Brazil 2011 Currículo Antonio Nivaldo F. Leite Junior Graduação em Ciências da Computação; Graduação em Comunicação Social c/ ênfase em Pub. e Propaganda; Pós-graduação em

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

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

Aplicando políticas de QoS. MUM Brasil São Paulo Outubro/2008. Sérgio Souza

Aplicando políticas de QoS. MUM Brasil São Paulo Outubro/2008. Sérgio Souza Aplicando políticas de QoS MUM Brasil São Paulo Outubro/2008 Sérgio Souza Nome: País: Sergio Souza Brasil Tecnólogo em Processamento de Dados Consultor independente atuando há vários anos em implementação,

Leia mais

de Telecomunicações para Aplicações Multimídia Distribuídas Infra-estrutura Infra-estrutura de Telecomunicações Serviço Multicast

de Telecomunicações para Aplicações Multimídia Distribuídas Infra-estrutura Infra-estrutura de Telecomunicações Serviço Multicast Departamento de Engenharia de Telecomunicações - UFF Infra-estrutura de Telecomunicações Comunicação Multicast Infra-estrutura de Telecomunicações para Aplicações Multimídia Distribuídas Profa. Débora

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

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 Agenda Motivação Objetivos Histórico Família de protocolos TCP/IP Modelo de Interconexão Arquitetura em camadas Arquitetura TCP/IP Encapsulamento

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

Assumiu em 2002 um novo desafio profissional como empreendedor e Presidente do Teleco.

Assumiu em 2002 um novo desafio profissional como empreendedor e Presidente do Teleco. VPN: Redes Privadas Virtuais O objetivo deste tutorial é apresentar os tipos básicos de Redes Privadas Virtuais (VPN's) esclarecendo os significados variados que tem sido atribuído a este termo. Eduardo

Leia mais

Aplicação ao Gerenciamento de Redes de Telecomunicações

Aplicação ao Gerenciamento de Redes de Telecomunicações Aplicação ao Gerenciamento de Redes de Telecomunicações Este tutorial apresenta o modelo TMN (Telecommunications Management Network) para gerenciamento de redes de Telecomunicações criado pelo ITU-T (International

Leia mais

Gerência de Redes e Serviços de Comunicação Multimídia

Gerência de Redes e Serviços de Comunicação Multimídia UNISUL 2013 / 1 Universidade do Sul de Santa Catarina Engenharia Elétrica - Telemática 1 Gerência de Redes e Serviços de Comunicação Multimídia Aula 3 Gerenciamento de Redes Cenário exemplo Detecção de

Leia mais

Introdução as Redes de Computadores Transparências baseadas no livro Computer Networking: A Top-Down Approach Featuring the Internet James Kurose e Keith Ross Redes de Computadores A. Tanenbaum e Prof.

Leia mais

2 Avaliação de desempenho de uma rede de telecomunicações

2 Avaliação de desempenho de uma rede de telecomunicações 2 Avaliação de desempenho de uma rede de telecomunicações Ao longo do presente capítulo são introduzidos os principais elementos qualitativos e quantitativos capazes de permitir a avaliação do desempenho

Leia mais

MSc Eliton Smith elitonsmith@gmail.com. Gerenciamento e Administração de Redes

MSc Eliton Smith elitonsmith@gmail.com. Gerenciamento e Administração de Redes MSc Eliton Smith elitonsmith@gmail.com Gerenciamento e Administração de Redes 2 Gerência de Redes ou Gerenciamento de Redes É o controle de qualquer objeto passível de ser monitorado numa estrutura de

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

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

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

Revisão. Karine Peralta karine.peralta@pucrs.br

Revisão. Karine Peralta karine.peralta@pucrs.br Revisão Karine Peralta Agenda Revisão Evolução Conceitos Básicos Modelos de Comunicação Cliente/Servidor Peer-to-peer Arquitetura em Camadas Modelo OSI Modelo TCP/IP Equipamentos Evolução... 50 60 1969-70

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

Rede de Computadores II

Rede de Computadores II Rede de Computadores II Slide 1 SNMPv1 Limitações do SNMPv1 Aspectos que envolvem segurança Ineficiência na recuperação de tabelas Restrito as redes IP Problemas com SMI (Structure Management Information)

Leia mais

1 Redes de comunicação de dados

1 Redes de comunicação de dados 1 Redes de comunicação de dados Nos anos 70 e 80 ocorreu uma fusão dos campos de ciência da computação e comunicação de dados. Isto produziu vários fatos relevantes: Não há diferenças fundamentais entre

Leia mais

Figura 1 - Comparação entre as camadas do Modelo OSI e doieee. A figura seguinte mostra o formato do frame 802.3:

Figura 1 - Comparação entre as camadas do Modelo OSI e doieee. A figura seguinte mostra o formato do frame 802.3: Introdução Os padrões para rede local foram desenvolvidos pelo comitê IEEE 802 e foram adotados por todas as organizações que trabalham com especificações para redes locais. Os padrões para os níveis físico

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES Eriko Carlo Maia Porto UNESA Universidade Estácio de Sá eriko_porto@uol.com.br Última revisão Julho/2003 REDES DE COMPUTADORES INTRODUÇÃO EVOLUÇÃO DOS SISTEMAS DE COMPUTAÇÃO Década de 50 introdução dos

Leia mais

Tópicos Especiais em Redes de Telecomunicações

Tópicos Especiais em Redes de Telecomunicações Tópicos Especiais em Redes de Telecomunicações Redes definidas por software e Computação em Nuvem Prof. Rodrigo de Souza Couto PARTE 1 REDES DEFINIDAS POR SOFTWARE (SDN) 2 Bibliografia Esta aula é baseada

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

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 WAN. Prof. Walter Cunha

Redes WAN. Prof. Walter Cunha Redes WAN Conceitos Iniciais Prof. Walter Cunha Comutação por Circuito Todos os recursos necessários em todos os subsistemas de telecomunicação que conectam origem e destino, são reservados durante todo

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

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

INTERNET = ARQUITETURA TCP/IP

INTERNET = ARQUITETURA TCP/IP Arquitetura TCP/IP Arquitetura TCP/IP INTERNET = ARQUITETURA TCP/IP gatewa y internet internet REDE REDE REDE REDE Arquitetura TCP/IP (Resumo) É útil conhecer os dois modelos de rede TCP/IP e OSI. Cada

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

Fundamentos de Rede. Aula 01 - Introdução e Redes

Fundamentos de Rede. Aula 01 - Introdução e Redes Fundamentos de Rede Aula 01 - Introdução e Redes Contextualização Séculos XVIII e XIX - Revolução Industrial máquinas mecânicas, taylorismo, fábricas hierarquia, centralização da decisão, mainframes Séculos

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

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

A Camada de Transporte

A Camada de Transporte A Camada de Transporte Romildo Martins Bezerra CEFET/BA s de Computadores II Funções da Camada de Transporte... 2 Controle de conexão... 2 Fragmentação... 2 Endereçamento... 2 Confiabilidade... 2 TCP (Transmission

Leia mais

Universidade Tuiuti do Paraná Faculdade de Ciências Exatas. Tecnologia de Análise e Desenvolvimento de Sistemas. TCP/IP x ISO/OSI

Universidade Tuiuti do Paraná Faculdade de Ciências Exatas. Tecnologia de Análise e Desenvolvimento de Sistemas. TCP/IP x ISO/OSI Universidade Tuiuti do Paraná Faculdade de Ciências Exatas Tecnologia de Análise e Desenvolvimento de Sistemas TCP/IP x ISO/OSI A Internet não segue o modelo OSI. É anterior a ele. Redes de Computadores

Leia mais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT 15.565 Integração de Sistemas de Informação: Fatores Tecnológicos, Estratégicos e Organizacionais 15.578 Sistemas de Informação Global:

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

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

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1 Descritivo Técnico 16/02/2011 Página 1 1. OBJETIVO O SLAview é um sistema de análise de desempenho de redes IP por meio da monitoração de parâmetros de SLA (Service Level Agreement, ou Acordo de Nível

Leia mais

Aula 01 Introdução ao Gerenciamento de Redes

Aula 01 Introdução ao Gerenciamento de Redes Aula 01 Introdução ao Gerenciamento de Redes Leonardo Lemes Fagundes leonardo@exatas.unisinos.br São Leopoldo, 15 de outubro de 2004 Roteiro Apresentação da disciplina Objetivos Conteúdo programático Metodologia

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

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

Curso de Tecnologia em Análise e Desenvolvimento de Software

Curso de Tecnologia em Análise e Desenvolvimento de Software Curso de Tecnologia em Análise e Desenvolvimento de Software Disciplina: Redes de Computadores 2. Arquiteturas de Redes: Modelo em camadas Prof. Ronaldo Introdução n Redes são

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Aula 01 Introdução Prof. João Henrique Kleinschmidt Santo André, julho de 2013 Roteiro PARTE I Apresentação da Disciplina Apresentação do Professor Metodologia

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES 09/2013 Cap.3 Protocolo TCP e a Camada de Transporte 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura da bibliografia básica. Os professores

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

Técnico em Informática. Redes de Computadores 2ºE1/2ºE2

Técnico em Informática. Redes de Computadores 2ºE1/2ºE2 Técnico em Informática Redes de omputadores 2ºE1/2ºE2 SUMÁRIO 2.1 Introdução 2.2 Vantagens do Modelo de amadas 2.3 Modelo de inco amadas 2.4 Funções das amadas 2.5 Protocolos de Rede 2.6 Arquitetura de

Leia mais

Disciplina: Ferramentas de Gerenciamento

Disciplina: Ferramentas de Gerenciamento PROF. RENÊ FURTADO FELIX rffelix70@yahoo.com.br Disciplina: Ferramentas de Gerenciamento Aula 2 Janeiro de 2013 H T T P : / / W W W. R E N E C O M P U T E R. N E T / F _ G E R E N C I A M E N T O. P H

Leia mais

Tenha a mesma experiência de rede que os seus clientes Fechando a lacuna da ativação

Tenha a mesma experiência de rede que os seus clientes Fechando a lacuna da ativação Documento técnico Tenha a mesma experiência de rede que os seus clientes Fechando a lacuna da ativação Introdução Tradicionalmente, os testes de ativação das Camadas 2/3, como RFC 2544 têm sido conduzidos

Leia mais

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal:

Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Emissor: Receptor: Meio de transmissão Sinal: Redes - Comunicação Comunicação é o ato de transmissão de informações de uma pessoa à outra. Comunicação sempre foi, desde o início dos tempos, uma necessidade humana buscando aproximar comunidades distantes.

Leia mais

AULA 01 INTRODUÇÃO. Eduardo Camargo de Siqueira REDES DE COMPUTADORES Engenharia de Computação

AULA 01 INTRODUÇÃO. Eduardo Camargo de Siqueira REDES DE COMPUTADORES Engenharia de Computação AULA 01 INTRODUÇÃO Eduardo Camargo de Siqueira REDES DE COMPUTADORES Engenharia de Computação CONCEITO Dois ou mais computadores conectados entre si permitindo troca de informações, compartilhamento de

Leia mais

MONITORAÇÃO DE REDE. Prof. José Augusto Suruagy Monteiro

MONITORAÇÃO DE REDE. Prof. José Augusto Suruagy Monteiro MONITORAÇÃO DE REDE Prof. José Augusto Suruagy Monteiro 2 Capítulo 2 de William Stallings. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3rd. Edition. Addison-Wesley, 1999. Baseado em slides do Prof. Chu-Sing

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

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

Roteadores de Serviços Integrados CISCO ISR G2

Roteadores de Serviços Integrados CISCO ISR G2 Roteadores de Serviços Integrados CISCO ISR G2 Visão geral sobre Desempenho Descrição do Conteúdo Os roteadores de serviços integrados de nova geração (ISR G2) proporcionam uma plataforma para serviços

Leia mais

Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/

Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ STJ 2008 Com relação a transmissão de dados, julgue os itens

Leia mais

Faculdade Anhanguera de São Caetano do Sul

Faculdade Anhanguera de São Caetano do Sul Faculdade Anhanguera de São Caetano do Sul Redes Locais Curso: Tecnologia em Redes de Computadores Prof:Eduardo M. de Araujo Site-http://professoreduardoaraujo.com ARQUITETURA DE REDES Hierarquia de Protocolos

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

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

Gerência de Redes. Arquitetura de Gerenciamento. filipe.raulino@ifrn.edu.br

Gerência de Redes. Arquitetura de Gerenciamento. filipe.raulino@ifrn.edu.br Gerência de Redes Arquitetura de Gerenciamento filipe.raulino@ifrn.edu.br Sistema de Gerência Conjunto de ferramentas integradas para o monitoramento e controle. Possui uma interface única e que traz informações

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

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

Gerência de Redes de Computadores Gerência de Redes de Computadores As redes estão ficando cada vez mais importantes para as empresas Não são mais infra-estrutura dispensável: são de missão crítica, ou

Leia mais

Capítulo 9. Gerenciamento de rede

Capítulo 9. Gerenciamento de rede 1 Capítulo 9 Gerenciamento de rede 2 Redes de computadores I Prof.: Leandro Soares de Sousa E-mail: leandro.uff.puro@gmail.com Site: http://www.ic.uff.br/~lsousa Não deixem a matéria acumular!!! Datas

Leia mais

O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento. Padrões. Padrões. Meios físicos de transmissão

O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento. Padrões. Padrões. Meios físicos de transmissão O que é uma rede industrial? Redes Industriais: Princípios de Funcionamento Romeu Reginato Julho de 2007 Rede. Estrutura de comunicação digital que permite a troca de informações entre diferentes componentes/equipamentos

Leia mais

Francisco Tesifom Munhoz X.25 FRAME RELAY VPN IP MPLS

Francisco Tesifom Munhoz X.25 FRAME RELAY VPN IP MPLS X.25 FRAME RELAY VPN IP MPLS Redes remotas Prof.Francisco Munhoz X.25 Linha de serviços de comunicação de dados, baseada em plataforma de rede, que atende necessidades de baixo ou médio volume de tráfego.

Leia mais

Serviços Diferenciados na Internet

Serviços Diferenciados na Internet Serviços Diferenciados na Internet FEUP/DEEC/RBL 2002/03 José Ruela Serviços Diferenciados na Internet O IETF desenvolveu um modelo de Serviços Diferenciados - Differentiated Services (DiffServ) - que

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

Protocolos de gerenciamento

Protocolos de gerenciamento Protocolos de gerenciamento Os protocolos de gerenciamento têm a função de garantir a comunicação entre os recursos de redes homogêneas ou não. Com esse requisito satisfeito, operações de gerenciamento

Leia mais

Data de entrega: 07.abr.2015 Entregar exercício impresso Será descontado 2 pontos para cada dia de atraso

Data de entrega: 07.abr.2015 Entregar exercício impresso Será descontado 2 pontos para cada dia de atraso FACULDADE PITÁGORAS Curso Superior em Tecnologia: Redes de Computadores DESEMPENHO DE REDES Prof. Ulisses Cotta Cavalca EXERCÍCIOS Métricas e variáveis de redes Data de entrega:

Leia mais

Fig. 1: Relatório de lucratividade de setembro de 1998 a setembro de 1999 ( )

Fig. 1: Relatório de lucratividade de setembro de 1998 a setembro de 1999 ( ) 1, This article presents a purpose of QoS for IP networks. It shows how Internet Service Providers can guaranty QoS, according with the type of flow being controlled. We have described how a high speed

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

Rede d s d e d Com o pu p t u ado d r o es Conceitos Básicos M d o e d los o de d Re R de d s:

Rede d s d e d Com o pu p t u ado d r o es Conceitos Básicos M d o e d los o de d Re R de d s: Tecnologia em Redes de Computadores Redes de Computadores Professor: André Sobral e-mail: alsobral@gmail.com Conceitos Básicos Modelos de Redes: O O conceito de camada é utilizado para descrever como ocorre

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

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 1- MODELO DE CAMADAS 1. INTRODUÇÃO A compreensão da arquitetura de redes de computadores envolve a compreensão do modelo de camadas. O desenvolvimento de uma arquitetura de redes é uma tarefa complexa,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores... 1 Mobilidade... 1 Hardware de Rede... 2 Redes Locais - LANs... 2 Redes metropolitanas - MANs... 3 Redes Geograficamente Distribuídas - WANs... 3 Inter-redes... 5 Software de Rede...

Leia mais

GERÊNCIA INFRAESTRUTURA Divisão Intragov - GIOV INTRAGOV Rede IP Multisserviços

GERÊNCIA INFRAESTRUTURA Divisão Intragov - GIOV INTRAGOV Rede IP Multisserviços GERÊNCIA INFRAESTRUTURA Divisão Intragov - GIOV INTRAGOV Rede IP Multisserviços Julho 2013 Milton T. Yuki Governo Eletrônico (e-gov) Público Alvo Cidadão/Sociedade Órgãos de Governo Serviços e-gov para

Leia mais

Arquiteturas de Redes Prof. Ricardo J. Pinheiro

Arquiteturas de Redes Prof. Ricardo J. Pinheiro Fundamentos de Redes de Computadores Arquiteturas de Redes Prof. Ricardo J. Pinheiro Resumo Arquiteturas de Redes Organizações de padronização Modelos de referência Modelo OSI Arquitetura IEEE 802 Arquitetura

Leia mais