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

Transcrição

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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