ACME: Uma ferramenta automatizada para geração e avaliação de qualidade de chamadas VoIP

Transcrição

1 13º Workshop de Gerência e Operação de Redes e Serviços 27 : Uma ferramenta automatizada para geração e avaliação de qualidade de chamadas VoIP Leandro C. G. Lustosa, André A. D. P. Souza, Paulo H. de A. Rodrigues, Douglas G. Quinellato Laboratório de Voz Sobre IP Núcleo de Computação Eletrônica Universidade Federal do Rio de Janeiro (NCE/UFRJ) * Caixa Postal Rio de Janeiro RJ Brasil {leandro,andreabrantes,aguiar}@nce.ufrj.br, douglas@las.ic.unicamp.br Abstract., an automatic tool for the generation and quality evaluation of VoIP calls is presented. analyses link bandwidths and node computing power capacities to determine the maximum number of simultaneous calls between pair of nodes in a given topology, besides supporting pre-programmed schedule of VoIP calls experiments. To demonstrate versatility and efficacy, its use as an IP telephony service monitoring tool in a real environment is shown. Resumo., uma ferramenta automatizada para geração e avaliação de qualidade de chamadas VoIP, é apresentada. A analisa a disponibilidade de banda e capacidade de processamento para determinar o maior número de chamadas simultâneas que um nó pode operar numa determinada topologia, além de suportar a programação antecipada de experimentos. A eficácia e versatilidade da ferramenta é demonstrada com seu uso como um instrumento de monitoração de um serviço VoIP operacional. 1. Introdução A (Automatic Call Measurement Environment) é uma ferramenta capaz de desempenhar duas atividades básicas: a geração de chamadas VoIP (Voz sobre IP) e a aferição da qualidade das chamadas geradas. A ferramenta utiliza o potencial destas duas atividades fundamentais para construir um ambiente automatizado suportando duas classes de experimentos. A primeira classe, denominada experimento de estresse (stress experiment), é utilizada basicamente para a determinação da capacidade (em número de chamadas simultâneas) que um determinado meio (cabeado ou sem fio) ou sistema (serviço ou conjunto de servidores VoIP) pode suportar, sem comprometer a qualidade de voz além de um determinado nível previamente estabelecido. * Parcialmente suportados com recursos da Rede Nacional de Ensino e Pesquisa (RNP). Paulo H. de A. Rodrigues é também professor do Departamento de Computação/IM da UFRJ. Douglas G. Quinellato hoje é membro LAS (Laboratório de Administração e Segurança de Sistemas) do IC/UNICAMP.

2 28 13º Workshop de Gerência e Operação de Redes e Serviços A segunda classe, denominada experimento periódico (periodic experiment), é utilizada para averiguar a variação da qualidade de chamadas ao longo do tempo, possibilitando, inclusive, a monitoração de disponibilidade de um serviço VoIP. A arquitetura da foi desenvolvida a partir de uma infra-estrutura de avaliação de qualidade proposta pelo Laboratório de Voz sobre IP da UFRJ [Lustosa et. al. 2005a]. Esta infra-estrutura prevê que clientes VoIP (telefones IP ou gateways) sejam capazes de avaliar a qualidade da chamada recebida e emitir um registro de detalhamento da chamada (Call Detail Record ou CDR) específico para a qualidade denominado VQCDR (Voice Quality Call Detail Record). O VQCDR contém diversos indicadores referentes à qualidade de voz recebida, além de parâmetros de identificação da chamada e dos terminais envolvidos, podendo incluir um relatório com o histórico da variação dos indicadores de qualidade ao longo de toda a duração da recepção. Os indicadores de qualidade do VQCDR são computados segundo o Modelo-E e suas extensões [ITU-T G , ETSI 2002, ETSI 2003]. Pelo modelo, a degradação da qualidade de voz pode ser causada por diversos fatores [Lustosa et. al. 2004], tais como, perdas de quadros de voz (que podem ocorrer na rede ou nos buffers de compensação de jitter, devido à variação de atraso), o atraso fim-a-fim demasiado (que influi na interatividade da conversa), fatores relacionados ao codec (quantização inerente ao codec, robustez frente à um comportamento de perda, o uso de algoritmos compensadores de perda, detectores de atividade de voz, etc), entre outros. A saída do Modelo E é um fator escalar R, que é mapeável para a escala de pontuação MOS (Mean Opinion Score) [ITU-T P ]. O MOS indica a percepção humana da qualidade de voz e varia de 1 (péssimo) à 5 (excelente). O cômputo do Modelo E, na arquitetura proposta pela UFRJ, é responsabilidade da VQuality (Voice Quality Library) [Lustosa et. al. 2005b], biblioteca desenvolvida em C++ que é integrada aos clientes IP para torná-los aptos a emitir o VQCDR. Com uso do VQCDR, a é capaz de gerar resultados extremamente detalhados e gráficos demonstrativos. Avaliar um determinado meio é uma tarefa mais complexa que a avaliação de uma chamada apenas. Para determinação da capacidade de um enlace, por exemplo, é necessário que diversas baterias de chamadas sejam realizadas para que seja obtida a capacidade de chamadas do enlace. A utiliza um mecanismo automático de execução dinâmica de chamadas para obter este valor dentro de um tamanho máximo para o intervalo de confiança escolhido, impedindo que variações de qualidade das chamadas resulte em resultados imprecisos de capacidade. Diversas ferramentas comerciais possibilitam a avaliação de qualidade de chamadas VoIP [Telchemy 2007, Empirix 2007, Brix 2007, Solarwinds 2007], mas não encontramos nenhuma que objetivasse a determinação de capacidade de enlaces e de servidores. Por meio dessas ferramentas seria até possível determinar a capacidade de um meio, mas seria exigido que todos os cálculos e execução de chamadas fossem realizados de forma manual, o que seria trabalhoso e suscetível a erros humanos em grandes sistemas. O artigo está organizado em oito seções. Na Seção 2, a infra-estrutura de avaliação de chamadas VoIP da UFRJ é descrita. Na Seção 3, a arquitetura da e seus componentes são apresentados. Nas Seções 4 e 5, os conceitos dos experimentos de estresse e dos experimentos periódicos são discutidos. A Seção 6 mostra como

3 4 7 PQ RS * D E A B C F G H I J K L M N O P Q R S T U V W X Y Z 0 # * CISCO IP P HONE 7902 SE RI ES 13º Workshop de Gerência e Operação de Redes e Serviços 29 experimentos são executados concorrentemente. Na Seção 7, o uso da é demonstrado e, por fim, na Seção 8, conclusões e trabalhos futuros são apresentados. 2. Arquitetura de avaliação de qualidade de chamadas VoIP da UFRJ Segundo a arquitetura de avaliação de qualidade proposta pela UFRJ [Lustosa et. al. 2005a], os VQCDRs são coletados por uma entidade denominada VQCDR Server, que possui a responsabilidade de interpretar, autenticar e encaminhar os VQCDRs coletados para serem armazenados em uma base de dados. O VQCDR Server possui três módulos: Collector Module (CM): responsável por coletar e interpretar o VQCDR, além de acionar o Authenticator Module (AM) e o Storage Module (SM). Authenticator Module (AM): responsável por validar os VQCDRs recebidos pelo CM. Para ambientes controlados de testes e medições, o VQCDR Server oferece uma lista de acesso simples baseada em endereços IP. Já em ambientes de produção, que requerem uma verificação mais sofisticada, o uso de AM é mais adequado. Storage Module (SM): responsável por armazenar os VQCDRs coletados pelo CM em uma base de armazenamento. Esta base pode ser, por exemplo, um banco de dados SQL ou um servidor RADIUS. VQCDR Server 3 O AM autentica o VQCR GnuGK Authenticator Module (GnuGk AM) H.323 Gatekeeper GnuGK 4 O AM acessa o GnuGK para validar o Autenticação VQCDR Radius StorageModule (Radius SM) Radius Server 2 O CM coleta o VQCDR e aciona o AM Colector Module (CM) Emissão do VQCDR Armazenamento Caso o VQCDR seja validado, o 5 SM aciona o Radius Server para armazenar o VQCDR Armazenamento 6 O Radius Server recebe o VQCDR e acessa o SQL Server para armazenar as informações do VQCDR em uma base de dados 1 O telefone IP computa a qualidade da chamada e emite um VQCR para o VQCDR Server Telefone IP integrado a VQuality 7 Web Server Estatísticas de qualidade das chamadas são disponibilizadas via interface web SQL Server Figura 1: Arquitetura de avaliação de qualidade de chamadas VoIP da UFRJ A Figura 1 ilustra o funcionamento da arquitetura em linhas gerais: Ao final da chamada, o telefone IP integrado à VQuality avalia a qualidade de voz recebida segundo sua perspectiva, e então, emite um VQCDR contendo indicadores de qualidade e identificadores de chamada (Figura 1-1). Este VQCDR é coletado pelo CM do VQCDR Server (Figura 1-2), que aciona o AM para verificar a legitimidade do VQCDR (Figura 1-3). No caso de um gatekeeper GnuGK [GnuGK 2007], a autenticação é realizada via um módulo específico para o GnuGK (Figura 1-4). Caso o VQCDR seja validado, o SM é acionado para armazenar o VQCDR. No caso de uso de RADIUS, o VQCDR é enviado via protocolo RADIUS para um servidor RADIUS (Figura 1-5). O servidor RADIUS

4 30 13º Workshop de Gerência e Operação de Redes e Serviços então armazena as informações do VQCDR em uma base de dados, que pode ser, por exemplo, um servidor SQL (Figura 1-6). Estas informações são por fim disponibilizadas em forma de gráficos e estatísticas via interface Web (Figura 1-7). A utiliza toda esta infra-estrutura de geração e coleta de VQCDR em sua arquitetura e adiciona ainda novos elementos, os quais são descritos na Seção Arquitetura da A possui uma arquitetura do tipo mestre-escravo. Um elemento central denominado Master (ou simplesmente master) coordena uma série de elementos periféricos denominados Slaves (ou simplesmente slaves), comandando-os a iniciarem chamadas ou se prepararem para receber chamadas. Um slave recebe a denominação de slave passivo quando recebe chamadas e de slave ativo quando inicia chamadas. É importante salientar que um slave pode iniciar uma chamada para um destino que não seja necessariamente um slave. É possível, por exemplo, que um slave ativo chame um telefone IP a fim de averiguar a disponibilidade do sistema a que este telefone IP está associado. Um slave é composto basicamente por dois elementos: (1) um cliente VoIP (VoIP Client, ou simplesmente VC), que é um softphone capaz de realizar chamadas com o uso de um protocolo VoIP qualquer (por exemplo, SIP ou H.323) integrado à VQuality, para possibilitar a emissão de VQCDRs com indicadores de qualidade; (2) um interpretador para possibilitar a interação com o master, que é gerida por um protocolo denominado p, que será discutido na Seção 3.2. Em um experimento de estresse é usual que múltiplas chamadas simultâneas sejam realizadas por um slave. Entretanto, o hardware sobre o qual o slave opera possui uma disponibilidade de recursos em termos de memória e processamento que limita a quantidade de chamadas simultâneas que podem ser realizadas sem que haja comprometimento de qualidade. A partir de certo momento, atrasos demasiados são injetados no processo de codificação/decodificação da voz e descartes nos buffers de compensação de jitter começam a ocorrer com freqüência. Como determinar a capacidade de um slave em receber ou gerar chamadas será apresentado na Seção 3.1. Para avaliar a capacidade de um determinado hardware ou de um enlace de baixa velocidade, possivelmente dois hardwares (um para o slave passivo e outro para o slave ativo) sejam suficientes. O conceito de site permite que uma quantidade maior de chamadas paralelas seja realizada, possibilitando que enlaces de maior velocidade e hardware com maior recurso computacional sejam estressados com o uso de conjuntos de slaves operando sobre hardware de menor poder computacional. Experimentos são sempre realizados entre dois sites compostos de um ou mais slaves. A oferece uma interface Web que opera em um servidor HTTP, denominado User Interface Server (ou simplesmente UIS). Esta interface disponibiliza um mecanismo para que um usuário agende a realização de experimentos e visualize seus respectivos resultados. A Figura 2 ilustra a arquitetura da e seus principais componentes. No momento que o usuário cadastra um novo experimento através da interface Web, os dados referentes a este experimento são armazenados em um banco SQL e o master é

5 13º Workshop de Gerência e Operação de Redes e Serviços 31 informado que um novo experimento foi cadastrado. Ao iniciar o experimento no momento programado, o master lê os parâmetros de configuração do experimento e ordena os slaves dos dois sites envolvidos para que as chamadas sejam realizadas e tenham a qualidade aferida. Ao executar as chamadas, os slaves emitem VQCDRs que são coletados pelo VQCDR Server e armazenados no banco SQL. UIS Notificação de experimento Cadastro e visualização de experimentos Leitura/atualização de informações do experimento SQL Server Master Armazenamento de VQCDR Agendamento e visualização de experimentos Site A p: Comandos master/slave Site B Slave Usuário (browser web) VC Slave Fluxos de voz Slave VC VC Coleta de VQCDR VQCDR Server Figura 2: Arquitetura da O UIS permite também que o usuário seja notificado através de sobre alguns status referentes aos experimentos, como, por exemplo, se algum erro ocorreu, se um experimento de estresse foi finalizado com sucesso, se algum slave está inalcançável, ou que a qualidade obtida está em nível alarmante, indicando que o sistema monitorado por um experimento periódico encontra-se em condição crítica. Todo núcleo da foi desenvolvido em C++, o banco de dados em PostgreSQL e o UIS em PHP. O projeto foi construído objetivando a execução em ambientes Linux, mas pode ser portado para outras versões de Unix. Os fluxos de voz utilizados são gravações com duração de 3 minutos, que mostrou suficiente para a deteção da degradação da voz com o aumento das chamadas simultâneas Determinação de capacidade do slave A capacidade dos slaves deve ser antecipadamente avaliada com experimentos de estresse, para que a limitação computacional não resulte em imprecisão dos experimentos. Na determinação de capacidade, aumenta-se gradativamente o número de chamadas simultâneas, enquanto a qualidade das chamadas executadas permanecerem com avaliação máxima. A condição de parada é o início de degradação de qualidade. Existem três cenários possíveis no processo de determinação da capacidade dos slaves:

6 32 13º Workshop de Gerência e Operação de Redes e Serviços 1. Dois slaves com harware de poder computacional equivalente: A degradação de qualidade ocorre de forma simétrica. Quando a qualidade das chamadas começa a degradar, a capacidade dos slaves é determinada; 2. Um slave com poder computacional sabidamente superior e outro slave com poder computacional inferior: A degradação de qualidade ocorre de forma assimétrica. Quando a qualidade das chamadas começa a degradar, a capacidade do slave de menor recurso é determinada; 3. Um slave S com grande poder computacional e um conjunto de slaves que juntos possuem poder computacional superior ao slave S: A degradação de qualidade ocorre de forma assimétrica. Quando a qualidade das chamadas começa a degradar, a capacidade do slave S é determinada; Na determinação de capacidade o recurso de rede deve ser amplo, garantindo que o fator limitante de capacidade seja o hardware dos slaves Protocolo p O p é o protocolo utilizado na comunicação entre o Master e o Slave. O master comanda os slaves, informando-os para se prepararem para receber um determinado número chamadas (slave passivo); ou ordenado-os a iniciarem um determinado número de chamadas para destinos específicos (slave ativo). Neste processo, a configuração da chamada também é informada: codificador, duração da chamada e destino (IP e porta de sinalização, número telefônico ou usuário). O master também possui a capacidade de ordenar que o slave se registre em um dado servidor, possibilitando assim que o servidor, ou o ambiente associado a um determinado servidor, seja avaliado em um experimento. Neste último caso, informações relativas ao registro no servidor são informadas ao slave (endereço do servidor, conta de acesso e senha). O protocolo possui apenas três mensagens, descritas a seguir: 1. Start: Opera no sentido de master para slave. Comanda o slave a se preparar para receber chamadas, iniciar chamadas ou se registrar em um determinado servidor; 2. Status: Opera no sentido slave para master. É utilizada pelo slave para informar ao master se as chamadas foram realizadas com sucesso ou falha. O slave passivo também usa a mensagem status para informar quando está apto a receber chamadas; 3. Cancel: Opera no sentido de master para slave. Utilizada pelo master para informar ao slave passivo que este não será mais chamado pelo slave ativo. Basicamente o Cancel cancela uma mensagem Start previamente enviada a um slave passivo. A Figura 3 ilustra um experimento realizado entre dois slaves. O master comanda o slave passivo a ficar pronto para receber chamadas (START); O slave passivo informa ao master que está apto a receber as chamadas (STATUS-READY, leia-se STATUS com um indicador READY); O master comanda o slave ativo a iniciar as chamadas (START); As chamadas são iniciadas e o fluxo de voz entre os slaves começa a ocorrer. Caso todas as chamadas ocorram com sucesso, ambos os slaves enviam ao master um STATUS com o indicador OK, caso contrário, é enviado um STATUS com indicador NOK (NOT OK). É importante notar que, caso alguma chamada não obtenha sucesso, toda a operação deve ser repetida, já que é imprescindível que o número correto

7 13º Workshop de Gerência e Operação de Redes e Serviços 33 de chamadas concorrentes seja realizado, para que não se tenha um resultado incorreto da avaliação do ambiente em teste. A Figura 4 também ilustra um experimento realizado entre dois slaves. Entretanto, neste caso, ocorre um erro no slave ativo; O master comanda o slave passivo a ficar pronto para receber chamadas (START); O slave passivo informa ao master que está apto a receber as chamadas (STATUS-READY); O master comanda o slave ativo a iniciar as chamadas (START), porém, por algum motivo, o slave ativo não consegue iniciar as chamadas e envia ao master um STATUS-NOK; O master então envia ao slave passivo um CANCEL, informando que, por algum motivo, o slave não receberá as chamadas que estava esperando. Master Passive Slave Active Slave Master Passive Slave A Passive Slave B START STATUS-READY START START STATUS-READY START STATUS-NOK Voice flows CANCEL STATUS-OK STATUS-OK STATUS-OK Figura 3: Slave para slave com sucesso Figura 4: Slave para slave sem sucesso A Figura 5 ilustra um experimento realizado entre um slave (que neste caso é obrigatoriamente ativo) e um gateway, que pode entregar a chamada em destinos diversos (como, por exemplo, um número de telefone convencional da rede de telefonia pública, um número de um PBX, etc.). Neste caso, o master necessita apenas comandar o slave ativo, logo necessita apenas enviar um START ao slave e esperar por um STATUS-OK, que será recebido caso as chamadas obtenham sucesso. Este tipo de operação é útil, por exemplo, para monitorar a disponibilidade do gateway e sua capacidade de encaminhar chamadas para uma determinada rede. Master Active Slave Asterisk: H.323/SIP and H.323/PSTN GW IVR (PBX, PSTN or SIP) START STATUS-OK Voice flows Voice flows Figura 5: Slave para gateway O p opera sobre TCP e utiliza por padrão a porta 8000 (configurável). Até o momento nenhum mecanismo de criptografia é utilizado, mas aspectos de segurança estão sendo avaliados para aprimoramentos futuros. Para evitar que um master não autorizado comande qualquer slave, listas de acesso podem ser configuradas em cada slave. Entretanto, a mensagem START utilizada para comandar o registro do

8 34 13º Workshop de Gerência e Operação de Redes e Serviços slave é crítica, já que contém senha de autenticação não cifrada. O uso de TLS [Dierks 2006] deve ser suportado para operar com segurança. 4. Experimentos de estresse O objetivo de um experimento de estresse é determinar a capacidade de um determinado meio. A capacidade é o número máximo de chamadas VoIP simultâneas que podem ser realizadas (com uso de um codec específico, como por exemplo, o G.711), sem que a média do MOS das chamadas (dentro de um intervalo de confiança de tamanho máximo) caia abaixo de um valor mínimo previamente estabelecido. Entenda-se meio como um enlace, uma rede, um sistema ou até mesmo um serviço de telefonia VoIP. A determinação da capacidade de um slave, por exemplo, é um experimento de estresse utilizado para avaliar um hardware e exige que o MOS médio não seja inferior ao MOS máximo obtido em condições ideais. É importante comentar que cada codec possui um MOS máximo que pode ser atingido, dada a degradação inerente causada pela compressão de voz. O G.711, por exemplo, obtém um MOS máximo de Teste (Test) Um experimento de estresse é composto por uma série de testes. Cada teste possui um determinado número de chamadas concorrentes. Assim, caso o teste 1 que possui N chamadas simultâneas obtiver um valor médio de MOS igual ou superior ao valor médio de MOS estabelecido, um novo teste (teste 2) é executado. O teste 2 por sua vez, possuirá N + X chamadas simultâneas. Caso o teste 2 atinja resultado maior ou superior ao MOS médio estabelecido, um novo teste (teste 3) é realizado com (N+X)+X chamadas concorrentes. Ou seja, novos testes são executados dinamicamente até que o MOS médio estabelecido seja ultrapassado. O número inicial de chamadas concorrentes (N) e o número de incremento de chamadas (X) são parâmetros configuráveis Bateria (Round) Ao configurar o MOS médio requerido para o experimento, o usuário também configura um grau de confiança (alvo), que é uma percentagem, por exemplo, 10% ou 20%. O resultado de um teste deve possuir obrigatoriamente um tamanho de intervalo de confiança menor ou igual à percentagem pré-definida do valor médio do intervalo. O valor médio do intervalo é o estimador do MOS médio das chamadas. Para atingir o intervalo de confiança alvo (target), o teste deve ser executado repetidas vezes. Cada repetição é denominada bateria (ou round), segundo a nomenclatura da. O experimento permite inclusive que um número mínimo de baterias seja estabelecido. Isso é importante para assegurar que testes com poucas chamadas concorrentes não atinjam o intervalo de confiança alvo sem que a média de MOS tenha realmente convergido. O Quadro 1 ilustra a estrutura de um experimento. São apresentados três testes, sendo que o teste 1 (com 3 chamadas concorrentes) encontra-se expandido, permitindo assim que detalhes relativos às suas cinco baterias sejam visualizados. Este experimento foi configurado para ter um intervalo de confiança alvo de 10 %. Note que o alvo só é atingido na Bateria 5, quando o MOS médio para o teste resulta em 4,08. Ao atingir o alvo, o Teste 2 com 4 chamadas concorrentes é iniciado. É importante destacar que o

9 13º Workshop de Gerência e Operação de Redes e Serviços 35 MOS médio e o intervalo de confiança é sempre calculado com base em todos os MOS de todas as chamadas realizadas por todas as baterias de um mesmo teste. Test 1 3 Chamadas concorrentes Bateria 1 MOS médio= 4.10, Int. de confiança = 0.81, Alvo= 0.41 (10%) Bateria 2 MOS médio = 4.03, Int. de confiança = 0.71, Alvo = 0.4 Bateria 3 MOS médio = 4.08, Int. de confiança = 0.58, Alvo = 0.41 Bateria 4 MOS médio = 4.07, Int. de confiança = 0.42, Alvo = 0.41 Bateria 5 MOS médio = 4.08, Int. de confiança = 0.32, Alvo = 0.41 Test 2 4 Chamadas concorrentes Test 3 5 Chamadas concorrentes 5. Experimentos periódicos Quadro 1: Estrutura do experimento Existem três tipos básicos de experimentos periódicos, listados a seguir: 1. Experimento de monitoração de disponibilidade (availability experiment): Em intervalos regulares um determinado destino é chamado a fim de monitorar sua disponibilidade. No presente momento, apenas o protocolo H.323 é suportado pela, entretanto, o uso de um gateway H.323/SIP possibilita que destinos SIP sejam monitorados. De forma equivalente, o uso de um gateway para a telefonia convencional possibilita que destinos na RTFC (Rede de Telefonia Fixa Comutada) ou em um PBX (Private Branch extension) sejam alcançados, permitindo que o serviço de troca de tráfego com a telefonia convencional seja monitorado. O destino nestes experimentos são normalmente secretárias eletrônicas ou IVRs (Interactive Voice Response), já que estes respondem chamadas automaticamente; 2. Experimento de monitoração de qualidade (quality experiment): Por padrão todo experimento de disponibilidade avalia a qualidade da chamada recebida. A diferença do experimento de qualidade é que ele possibilita a configuração de limiares de alerta. Assim, ao obter medições de qualidade inferiores a um determinado valor, o usuário recebe uma notificação. Os experimentos de disponibilidade e de autenticação só emitem alerta em caso de erro; 3. Experimento de monitoração de autenticação (authentication experiment): Em intervalos regulares o slave tenta se autenticar em um determinado servidor para monitorar se o serviço de autenticação está operando corretamente. Até o presente momento apenas H.323 é suportado. 6. Concorrência de experimentos Segundo a visão da, os recursos utilizados nos experimentos são os slaves. Após cadastrados na, os slaves podem ser incluídos em sites e ser utilizados por qualquer experimento. Slaves podem, inclusive, ser incluídos paralelamente em mais de um site, contando que os sites dos experimentos não possuam slaves em comum. A granularidade de concorrência dos experimentos é o teste; assim, dois experimentos A e B podem ser executados concorrentemente e podem possuir slaves ou

10 36 13º Workshop de Gerência e Operação de Redes e Serviços até mesmo sites em comum. Entretanto, testes dos experimentos A e B nunca ocorrem simultaneamente, já que a excuta apenas um teste por vez. A Figura 6 ilustra a máquina de estados de um experimento periódico de qualidade. Ao ser agendado, o experimento entra no estado Scheduled e permanece neste estado até que esteja na hora programada de seu inicio e que não tenha nenhum experimento em sua frente esperando para ser executado. No momento em que seu primeiro teste (no caso de um experimento de qualidade um teste é uma chamada com aferição de qualidade) começa a ser executado, seu estado muda para Running. Findada a execução do teste, o seu estado muda para Ready-OK, caso o MOS obtido seja maior que o limiar crítico estabelecido. Caso o MOS seja inferior ou igual a este limiar, seu estado vai para Ready Low MOS. Outra possibilidade é que ocorra algum erro e o teste não seja finalizado. Caso um erro esperado ocorra, como por exemplo, indisponibilidade de alcançar o destino, o estado muda para Ready- Can t connect to host, ou outro estado que representa um erro definido. Em último caso, se um erro indefinido e irreversível ocorrer, o estado muda para Undefined error. O estado do experimento sempre retorna para Running quando o próximo teste deste mesmo experimento é executado. Porém, o estado Undefined error não permite mudança. Ready - OK Scheduled Running * Ready Low MOS Undefined error Ready Can t connect to host... Ready Can t authenticate Figura 6: Máquina de estados de um experimento de qualidade Todos os experimentos possuem máquina de estado similar. Um experimento periódico só termina caso seu estado vá para Undefined error. Já os experimentos de estresse terminam quando o MOS limite é alcançado, quando os slaves disponíveis não estão aptos a incrementar o número de chamadas (pois já chegaram ao limite de sua capacidade) ou, em último caso, quando vão para o estado Undefined error. A ordem de execução dos experimentos é uma derivação de um esquema Round- Robin de formato circular. Duas listas são mantidas, uma para os experimentos periódicos em estado Ready e outra para os experimentos de estresse em estado Ready. O scheduler (módulo da que gerencia a concorrência) sempre pega o próximo experimento em estado Ready da lista dos experimentos periódicos. Caso esta lista esteja vazia, ele pega o próximo experimento da lista de experimentos de estresse. Este esquema prioriza os experimentos periódicos, pois estes possuem tempo de resposta crítico por monitorarem serviços. 7. Demonstrações O cenário ilustrado na Figura 7 representa um enlace serial PPP de 500 kbps, interligando dois roteadores Cisco Os dois slaves presentes no cenário foram configurados para marcarem os pacotes IP referentes aos fluxos de voz com DSCP EF [Babiarz 2006], permitindo, assim, que os roteadores pudessem distinguir tais pacotes

11 13º Workshop de Gerência e Operação de Redes e Serviços 37 marcados de outros pacotes referentes ao gerador/refletor de pacotes UDP, utilizado para gerar tráfego concorrente ao tráfego de voz. Slave 1 Voice flows: G.711 Slave 2 Traffic generator 500 kpbs PPP link Priority Queue: 320 kbps guaranteed Concurrent traffic: 200 kpbs Traffic reflector Figura 7: Cenário do experimento de estresse demonstrativo O gerador UDP [Leocadio 2000] foi configurado para gerar uma taxa constante de 200 kbps em direção ao refletor. Os roteadores foram configurados para operar uma fila PQ (Priority Queue) [Cisco Systems 2007] com taxa garantida de 320 kbps para os pacotes marcados com DSCP EF (fluxos de voz). O codec utilizado foi o G.711, portanto, o fluxo de cada chamada correspondia à uma taxa aproximada de 80 kpbs no nível de enlace PPP. Figura 8: Resultado do experimento de estresse demonstrativo A Figura 8 apresenta o resultado do experimento. A ordenada representa o valor médio de MOS e a abcissa o número de chamadas simultâneas de cada teste. Nota-se que com até quatro chamadas concorrentes o MOS obteve o valor máximo, que é 4.41 para o G.711. A partir da quinta chamada o MOS cai abruptamente e o intervalo de confiança (linhas que cortam a curva do MOS) vai subindo gradativamente. O resultado é esperado, já que a PQ de 320 kpbs só acomoda quatro fluxos de voz de 80 kbps. Este experimento foi configurado com intervalo de confiança alvo de 10%. O cenário de demonstração dos experimentos periódicos foi montado para testar o fone@rnp [RNP 2007]. Este serviço utiliza uma arquitetura heterogênea baseada nos padrões H.323 e SIP que, além de interconectar os sistemas PBX de uma série de instituições acadêmicas, fornece uma plataforma para utilização de telefones IP e

12 38 13º Workshop de Gerência e Operação de Redes e Serviços interconexão com a RTFC. O objetivo da demonstração é monitorar o serviço oferecido na UFRJ e em outra instituição fictícia montada nos moldes exatos de uma instituição participante do fone@rnp, que chamaremos de Instituição 1. Como ilustrado na Figura 9, cada instituição monitorada representa um site e possui um slave local. O slave central, por sua vez, representa um terceiro site que interagirá com os sites monitorados. Master VQCDR Server VIS SQL Database ` HTTP WEB Browser: Agendamento e resultado dos esperimentos SIP PBX Site UFRJ SIP Proxy Asterisk: H323/SIP GW Slave Central VoIP/PBX GW H.323 GK SIP Site Institution 1 SIP Proxy PBX Asterisk: H323/SIP GW VoIP/PBX GW H.323 GK PBX PSTN Slave local H.323 PBX PSTN Slave local H.323 Figura 9: Cenário de experimentos periódicos demonstrativos Segundo os moldes do fone@rnp, cada instituição possui um gatekeeper H.323 para atender os usuários H.323, um proxy SIP para atender os usuários SIP, e um gateway para interoperação SIP/H.323 e para encaminhamento de chamadas para a RTFC (Rede de Telefonia Fixa Comutada) e PBX. Seis experimentos periódicos foram montados para cada instituição: 1. SIP : Monitora a disponibilidade de serviço SIP executando chamadas regulares para um softphone SIP configurado com respostas automáticas (autoanswer). O gateway converte a chamada H.323 do pelo slave central para SIP; 2. H.323 : Monitora a disponibilidade de serviço H.323 executando chamadas regulares para o slave local; 3. PBX : Monitora o encaminhamento de chamadas para o PBX executando chamadas regulares para um IVR do PBX. O gateway encaminha a chamada H.323 realizada pelo slave central ao PBX; 4. PSTN : Monitora o encaminhamento de chamadas para a RTFC executando chamadas regulares para um IVR da RTFC (um serviço 0800). O gateway encaminha a chamada H.323 realizada pelo slave central à RTFC; 5. H.323 Authentication: Monitora a autenticação do ambiente H.323 através do processo de autenticações periódicas do slave local ao gatekeeper H.323; 6. Quality: Monitora a qualidade das chamadas realizadas periodicamente entre o slave central e o slave local. Figura 10 apresenta o painel de monitoração da : experimentos com status positivo são mostrados em verde; experimentos problemáticos são mostrados em