UMA PROPOSTA PARA FORNECIMENTO DE QOS PARA APLICAÇÕES LEGADAS EM REDES TCP/IP

Transcrição

1 UMA PROPOSTA PARA FORNECIMENTO DE QOS PARA APLICAÇÕES LEGADAS EM REDES TCP/IP Lisandro Zambenedetti Granville Luciano Paschoal Gaspary Liane Margarida Rockenbach Tarouco {granville, Universidade Federal do Rio Grande do Sul - UFRGS Instituto de Informática - PPGC Av. Bento Gonçalves, 9500 Bloco IV Campus do Vale CEP Tel.: Fax.: Resumo: Fornecer QoS em redes de computadores atualmente é uma necessidade. Aplicações dependentes do tempo e de missão crítica precisam de garantias e qualidade dos serviços de rede utilizados. Em redes TCP/IP, ainda que tais serviços fossem implantados rapidamente, as aplicações já existentes não estariam preparadas para utilizar as facilidades de QoS. Os autores acreditam que seria interessante um gerente da rede poder programar requisitos de QoS para aplicações legadas, priorizando o tráfego oriundo de algumas aplicações (ex.: ferramenta de videoconferência) ou o de determinados hosts. Este artigo apresenta uma proposta para fornecimento de QoS para aplicações legadas em redes TCP/IP. A proposta se baseia na utilização da MIB RMON2 para determinar o comportamento dos hosts e das aplicações mais utilizadas por eles. A coleta de estatísticas ao longo do tempo permite a determinação de padrões de utilização da rede. Com base nessa baseline, realiza-se a programação do fornecimento de QoS da rede. Palavras-chave: QoS, serviços diferenciados, RSVP, RTP, RTCP. 1. INTRODUÇÃO O fornecimento de QoS em redes de computadores vem se tornando uma necessidade quando as aplicações envolvidas possuem características especiais. Redes tradicionais operam no paradigma de best effort onde nenhuma garantia sobre os serviços de rede é fornecida. Neste ambiente, aplicações de missão crítica e aplicações dependentes de restrições temporais não podem operar adequadamente. Fornecer QoS em um ambiente onde as aplicações necessitam de garantias de rede é essencial. Algumas redes de computadores suportam QoS pois foram construídas com este conceito em mente (ex.: redes ATM). Outras redes, como as baseadas em TCP/IP, não foram originalmente criadas com mecanismos para fornecimento de QoS. Nessas redes, criar novos mecanismos é essencial para que as mesmas não se tornem obsoletas. Esforços nesse sentido podem ser observados, por exemplo, através do projeto Internet2 [1] e seu QBone. Do ponto de vista do gerenciamento de redes, QoS passa a ser um recurso a mais que deve ser gerenciado. Como um gerente de rede pode perceber as necessidades de QoS das aplicações e usuários existentes? Este artigo apresenta uma proposta para fornecimento de QoS em redes TCP/IP baseada na observação do comportamento das aplicações e usuários através da MIB RMON2 [2]. O fornecimento de níveis de QoS é realizado com a utilização de serviços e protocolos definidos pelo IETF [3].

2 O trabalho está organizado da seguinte forma: a seção 2 caracteriza as aplicações em rede existentes, enquanto na seção 3 são apresentadas as estratégias de fornecimento de QoS para tais aplicações. Na seção 4 a MIB RMON2 é apresentada. Na seção 5 apresenta-se a proposta para fornecimento de qualidade de serviço baseada nas estratégias de QoS e na MIB RMON2. Por fim, as conclusões são apresentadas na seção CARACTERIZAÇÃO DE APLICAÇÕES EM REDES Atualmente existem diversos esforços no sentido de se utilizar as redes de computadores como meio de transmissão de informações especiais. Os principais exemplos são o tráfego de voz e vídeo. As redes passam a fornecer suporte para o transporte de diversos tipos de tráfegos com o objetivo de atender, com uma mesma infra-estrutura, necessidades diferentes dos usuários. Caracterizar esses tráfegos é importante para se definir os requisitos de fornecimento de QoS que as redes de computadores devem possuir [4]. Pode-se dividir as aplicações em redes em três grandes categorias: aquelas que dependem muito de características temporais da rede, aquelas que não dependem dessas características e aquelas consideradas de missão crítica. 2.1 Aplicações tradicionais O grupo das aplicações tradicionais é composto por aplicações onde as características temporais pouco ou nada afetam o comportamento das mesmas. Nesse grupo encontram-se as aplicações de transferência de arquivos e as de correio eletrônico, entre outras. As aplicações que não dependem de características temporais são hoje largamente encontradas na Internet. Os requisitos de gerenciamento deste tipo de rede são amplamente conhecidos e testados. Os serviços de rede operam no paradigma best effort, onde as informações trafegam pela rede de acordo com a carga existente no momento do trânsito. Nenhuma reserva de recursos é utilizada e, diante de congestionamentos, as informações podem ser descartadas. Nenhum esquema de prioridade das informações é aplicado: todas as informações são igualmente importantes. 2.2 Aplicações de missão crítica Aplicações de missão crítica são aplicações que nem sempre dependem de restrições temporais, mas que requerem um tratamento especial da rede de computadores. Os serviços de rede devem apresentar qualidade e garantias, principalmente em relação à entrega das informações. O tempo pode não ser importante em determinadas situações, mas a consistência dos dados sim. Entre as aplicações de missão crítica, pode-se citar as de realização de backups distribuídos. Quando um backup é iniciado, todos os recursos da rede devem ser dedicados a essa tarefa. Os recursos que sobram podem então ser utilizados por outras aplicações. O tempo total do backup é menos importante que a validade dos dados copiados. 2.3 Aplicações multimídia As aplicações multimídia são as principais representantes das aplicações onde pequenas diferenças no tempo de entrega dos pacotes afetam sensivelmente o comportamento das mesmas. Nesse grupo se encontram as aplicações de tempo real, videoconferência, ensino a distância e telemedicina, por exemplo.

3 A consistência dos dados trocados é menos importante que o tempo de troca em si. Mecanismos de retransmissão para correção de dados corrompidos não são utilizados, sendo considerados até mesmo prejudiciais. De que vale o reenvio de um quadro corrompido em uma videoconferência se novos quadros com informações mais atuais já foram enviados? Os recursos de rede a serem utilizados são aqueles que garantem a entrega das informações em tempos conhecidos. A consistência das informações é menos importante que sua rápida transmissão. Para a implementação de aplicações dependentes do tempo e aplicações de missão crítica é clara a necessidade de serviços de rede mais adequados. As aplicações devem contar com uma rede de transporte onde o comportamento possa ser previsto. Para esse tipo de rede, o gerenciamento passa a lidar com características específicas ligadas às questões temporais e de prioridades. É importante que o gerente da rede possa gerir os recursos existentes de forma que o comportamento da rede tenha uma qualidade aceitável, para que as aplicações dependentes do tempo possam ser implantadas. Assim, além das características normais da rede, a solução de gerenciamento deve estar atenta às questões temporais e de QoS das redes gerenciadas [5]. 3. FORNECIMENTO DE QoS As redes de computadores devem utilizar estruturas especiais para o fornecimento de QoS. De acordo com a rede, um conjunto de estruturas diferentes é aplicado. Por exemplo, em redes ATM o protocolo de sinalização utilizado é diferente do protocolo de sinalização utilizado em uma rede TCP/IP. Como mencionado anteriormente, redes ATM foram originalmente construídas tendose em mente os conceito de QoS. Redes TCP/IP, por outro lado, operam apenas no paradigma best effort e fornecer QoS é importante quando aplicações mais complexas exigem serviços de rede com garantias. O fornecimento de QoS em redes ATM é mais natural e eficiente do que o realizado em redes TCP/IP. Entretanto, acredita-se que as redes TCP/IP continuarão sendo as mais utilizadas mundialmente e ATM passará a ser utilizado como ferramenta de interconexão. Do ponto de vista do usuário, o que é percebido são as estruturas do TCP/IP, ainda que estas possam se utilizar dos serviços ATM. O fornecimento de QoS deve ser percebido tanto pelo usuário da rede, quanto pelo gerente da mesma. Como a rede percebida é baseada em IP, nossos estudos são baseados no fornecimento de QoS através do uso de soluções baseadas em IP. A implementação dessas soluções pode utilizar ATM internamente, mas isto não é percebido. Assim, soluções ATM não são abordadas neste trabalho, e nos restringiremos às soluções IP para fornecimento de QoS. 3.1 Em ambientes best effort: RTP/RTCP O RTP (Real Time Protocol) e o RTCP (Real Time Control Protocol) [6] são protocolos de transporte criados para a transmissão de informações de aplicações de tempo real. O termo tempo real significa que as mensagens devem ser enviadas com o menor atraso possível. Os protocolos por si só não fornecem nem implementam QoS, mas são importantes ferramentas para as aplicações que se utilizam principalmente de serviços de redes best effort. A grande vantagem na utilização de RTP como protocolo de transporte, no lugar do TCP ou UDP, é que a aplicação pode verificar o estado da rede utilizada e perceber, por

4 exemplo, a presença de congestionamentos. Formalmente, a aplicação pode monitorar a rede e verificar se os parâmetros necessários para a mesma continuar operando adequadamente estão sendo mantidos. Em um ambiente best effort a rede não possui nenhum compromisso em manter os parâmetros necessários para o funcionamento das aplicações. Nessas condições, as aplicações devem proceder com adaptações, de forma a utilizar os recursos de rede disponíveis. Para que essa adaptação seja possível, é necessário que as aplicações entendam quais os recursos disponíveis. Os protocolos TCP [7] e UDP [8] implementam abstrações que não permitem verificar o estado da rede. Logo, o RTP e o RTCP são a escolha natural nesse ambiente. Apesar de serem mais amplamente utilizados em ambientes best effort, os protocolos RTP e RTCP podem ser utilizados conjuntamente com os serviços Soft QoS e Hard QoS. Em ambiente Soft QoS os fluxos são tratados de forma diferenciada, mas dentro de um mesmo fluxo não existe nenhuma garantia de que, por exemplo, perdas irão ocorrer. A percepção dessas condições pela aplicação é conseguida através do RTP/RTCP. Em ambientes Hard QoS teoricamente os protocolos não precisariam ser utilizados, pois a rede garante os serviços contratados. Ainda assim, o uso de RTP/RTCP implementa uma maior robustez das aplicações, mesmo em ambiente onde os serviços são garantidos. 3.2 Soft QoS através de Differentiated Services Determinadas aplicações simplesmente não podem operar em ambiente best effort. A solução definitiva para o problema é a reserva de recursos da rede para que as aplicações possam ter garantias de que sempre terão os recursos necessários para operar. Esta categoria define redes com características Hard QoS. Entretanto, fornecer estes serviços não é uma tarefa trivial e envolve muitas mudanças da arquitetura de rede. Uma outra categoria de serviços, que fornece uma solução intermediária, é conhecida como Soft QoS. Redes que operam com Soft QoS tratam fluxos de dados diferentes de forma diferente. Para cada tipo de fluxo, determinadas ações são tomadas nos roteadores da rede. Como existe um esquema de prioridade nos fluxos, aplicações críticas acabam utilizando prioridades maiores, enquanto que aplicações menos importantes utilizam prioridades menores. Os roteadores tratam primeiro as informações de maior prioridade. A implantação de serviços Soft QoS em redes TCP/IP é conseguida com a utilização das definições do IETF de serviços diferenciados (differenciated services) [9]. A idéia geral é a identificação de fluxos de dados e do tratamento diferenciado, por parte dos roteadores, de cada um desses fluxos. Quando uma aplicação envia pacotes de dados, estes pacotes fazem parte de um determinado fluxo. Quando chegam em um roteador, pacotes de um fluxo são enfileirados junto com outros pacotes do mesmo fluxo. Cada fila é então tratada separadamente, de acordo com uma política adotada. Para que os pacotes de um fluxo sejam identificados, as definições dos serviços diferenciados utilizam o campo ToS (type of service tipo de serviço) dos pacotes IP. Nos serviços diferenciados o campo ToS é chamado de DS Field (Diffrenciated Services Field). Cada valor no DS Field identifica um pacote dentro dos fluxos existentes. Para cada valor possível do DS Field são definidas políticas de tratamento nos roteadores entre a origem e destino de um fluxo. Em cada roteador do caminho, o tratamento para um mesmo fluxo pode ser diferenciado. Existem duas abordagens em relação ao tratamento dos pacotes das aplicações junto aos serviços diferenciados. As abordagens procuram responder a seguinte pergunta: Quem deve atribuir um valor ao DS Field: a aplicação ou o serviço de rede?

5 Em nossa opinião, acreditamos que esta função deve ser executada por um serviço de rede. A justificava para isso está baseada no fato de que todas as aplicações inevitavelmente desejam que seus fluxos sejam aqueles que possuem um melhor tratamento pela rede. Se a marcação do DS Field for feito pelas aplicações, todas atribuirão valores ótimos ao campo. Por outro lado, se a atribuição for feita por um serviço de rede, mesmo que uma aplicação deseje um tratamento diferenciado, este será atribuído pela rede e não pelo desenvolvedor. 3.3 Hard QoS através de RSVP As garantias que se possui na utilização dos serviços de uma rede que opera sobre Soft QoS são limitadas. A rede pode enfrentar congestionamentos indesejados e descartar informações importantes. Mesmo com o esquema de prioridade dos fluxos, as informações podem ser perdidas e as aplicações mais críticas deixarem de funcionar adequadamente. Quando uma aplicação necessita de fortes garantias sobre o funcionamento da rede, reserva de recursos deve ser aplicada para que tais garantias possam ser alcançadas. Diz-se que uma rede que fornece serviços para a reserva de recursos é uma rede que opera sobre Hard QoS. As aplicações devem, previamente à troca de informações, reservar todos os recursos necessários para que os dados a serem transmitidos sejam feitos com garantia. A reserva de recursos envolve a utilização de protocolos de sinalização. Todos os equipamentos do caminho entre a origem e o destino de um fluxo devem fornecer os recursos solicitados. Se algum equipamento intermediário não puder fornecer tais recursos, então todo o caminho não pode fornecer, e o fluxo não poderá ser tratado da forma que foi solicitada. Em relação às infra-estruturas de rede, fornecer serviços Hard Qos envolve a substituição de equipamentos e softwares. As modificações necessárias são mais profundas que as necessárias para o fornecimento de Soft Qos. Apesar disso, em determinados ambientes o uso de Hard QoS é obrigatório, enquanto que em outros apenas a existência de Soft QoS, ou até mesmo best effort, é suficiente. A implementação de um serviço Hard QoS envolve a reserva prévia de recursos da rede. Esta reserva só pode ser feita utilizando-se um protocolo de sinalização, que negocia os parâmetros de funcionamento solicitados pela aplicação com cada equipamento que faz parte do caminho entre origem e destino de um fluxo. O IETF possui grupos de trabalho que pesquisam tais protocolos de sinalização. Dentre estes protocolos, o RSVP (Resource ReSerVation Protocol) [10] é atualmente o mais importante, por se suportado em equipamentos de roteamento TCP/IP. O RSVP é um protocolo onde o caminho de negociação de recursos é percorrido ao contrário, do destino para origem. Inicialmente construído para fazer reserva de recursos para aplicações multimídia, o RSVP pode ser utilizado junto a qualquer aplicação de missão crítica existente. O fluxo de informações pode ser tanto unicast quanto multicast, o que torna o RSVP o protocolo ideal para ser utilizado em aplicações colaborativas que envolvem a interação entre várias pessoas ao mesmo tempo. Na hierarquia de protocolos, os recursos a serem reservados pelo RSVP podem utilizar outros protocolos de sinalização. Por exemplo, a reserva de recursos em um backbone ATM recebe requisições RSVP, mas mapeia tais requisições para os protocolos de sinalização ATM [11]. É importante notar que tal interação entre protocolos de sinalização não é percebida pela aplicação solicitante. Para esta, apenas as interações com o RSVP são percebidas. A implantação de QoS em uma rede TCP/IP precisa ser baseada na real utilização dos recursos da rede pelas aplicações e usuários. Se uma rede necessita de Hard QoS, o

6 fornecimento de Soft QoS é insuficiente. Na próxima seção apresenta-se a MIB RMON2, que permite entender o comportamento de aplicações e usuários em uma rede de computadores. 4. DERIVAÇÃO DOS REQUISITOS DAS APLICAÇÕES 4.1 Monitoração RMON2 O padrão RMON2 é uma alternativa interessante para monitorar e caracterizar o tráfego de protocolos de alto nível. RMON2 é uma MIB, padronizada em 1997 na RFC2021 [2], composta dos seguintes grupos: - protocol directory (protocoldir): é um repositório que indica todos os protocolos que o probe é capaz de interpretar; - protocol distribution (protocoldist): agrega estatísticas sobre o volume de tráfego gerado por cada protocolo, por segmento de rede local; - address map (addressmap): associa cada endereço de rede ao respectivo endereço MAC, armazenando-os em uma tabela; - network-layer host (nlhost): coleciona estatísticas sobre o volume de tráfego de entrada e saída das estações com base no endereço do nível de rede; - network-layer matrix (nlmatrix): provê estatísticas sobre o volume de tráfego entre pares de estações com base no endereço do nível de rede; - application-layer host (alhost): agrega estatísticas sobre o volume de tráfego de entrada e saída das estações com base em endereços do nível de aplicação; - application-layer matrix (almatrix): coleciona estatísticas sobre o volume de tráfego entre pares de estações com base no endereço do nível de aplicação; - user history collection (usrhistory): amostra periodicamente objetos especificados pelo usuário (gerente) e armazena as informações coletadas de acordo com parâmetros definidos também pelo usuário; - probe configuration (probeconfig): define parâmetros de configuração padrões para probes RMON; - rmon conformance (rmonconformance): descreve requisitos de conformidade para a MIB RMON Usuários x Volume de Acessos Obter informações sobre como um usuário ou até mesmo um departamento utiliza a rede é essencial se o administrador está interessado em traçar seu perfil de utilização para, a partir daí, fornecer QoS para determinados usuários e aplicações, dependendo dos requisitos necessários pelos mesmos. Informações relativas ao volume de acessos realizados por um determinado usuário podem ser obtidas através de consultas ao grupo network-layer host da MIB RMON2. Este grupo permite decodificar pacotes com base em seus endereços de rede. Como conseqüência, administradores podem observar além dos roteadores que interligam as sub-redes e identificar as reais estações que estão se comunicando [12]. O grupo é formado por uma tabela de controle (hlhostcontrol) e uma tabela de dados (nlhost) (figura 4). A tabela de controle possui uma entrada para cada interface (sub-rede) que está sendo monitorada. Cada entrada contabiliza informações como: número total de quadros recebidos pela interface que o probe opta por não contabilizar, número de vezes que uma entrada foi adicionada ou removida da tabela de dados e número máximo admissível de entradas, para a interface em questão, na tabela nlhost [13].

7 A função da tabela nlhost, por sua vez, é coletar estatísticas básicas sobre o tráfego de entrada e saída de cada equipamento descoberto, considerando endereços do nível de rede. Logo que uma nova entrada é adicionada à tabela hlhostcontrol, o monitor começa a observar e coletar endereços de rede na interface correspondente. A cada novo endereço identificado, uma entrada é adicionada à tabela nlhost [13]. hlhostcontrolindex hlhostcontroldatasource hlhostcontrolnldroppedframes hlhostcontrolnlinserts hlhostcontrolnldeletes hlhostcontrolnlmaxdesiredentries hlhostcontrolaldroppedframes hlhostcontrolalinserts hlhostcontrolaldeletes hlhostcontrolalmaxdesiredentries Tabela hlhostcontrol hlhostcontrolindex nlhosttimemark protocoldirlocalindex nlhostaddress Objetos Colunares (ip/ethernet) (ip/ethernet) (ip/llc) (ip/llc) (ip/ethernet) (ip/ethernet)... Figura 1. Tabelas do grupo nlhost Objetos Colunares nlhostinpackets nlhostoutpackets nlhostinoctets nlhostoutoctets nlhostoutmacnonunicastpkts nlhostcreatetime Tabela nlhost Na figura 1, é possível verificar que a tabela de controle possui três entradas. Isto indica que o probe está analisando pacotes em três segmentos de rede distintos. No primeiro segmento, foram identificados pacotes provenientes de quatro dispositivos, conforme pode ser observado na tabela nlhost. O segundo índice (nlhosttimemark) desta tabela indica o instante, em timeticks, que a entrada foi criada ou atualizada pela última vez. A presença de um contador de tempo como índice da tabela de dados permite que o administrador, no momento da consulta, informe que deseja receber o valor apenas dos objetos que sofreram modificação após um determinado instante. Deste modo, o tráfego de gerenciamento entre a estação central e os probes pode ser bastante reduzido. O terceiro índice, protocoldirlocalindex, indica o tipo de encapsulamento observado. Os tipos de encapsulamento que o probe é capaz de analisar são catalogados no grupo protocol directory. Por fim, o quarto índice da tabela de dados indica o endereço do nível de rede do dispositivo identificado. Um exemplo das informações obtidas com uma consulta ao grupo nlhost é apresentado na tabela 1. Consultas periódicas a este grupo permitem avaliar que usuários e em que momentos do dia mais acessam a rede. Tabela 1 - Exemplo de informações obtidas com consulta ao grupo nlhost HostAddress InPkts OutPkts InOctets OutOctets OutMacNon UnicastPkts Usuários x Aplicações e Protocolos Utilizados Determinar padrões de utilização da rede dos usuários requer do administrador um conhecimento pontual sobre os protocolos e aplicações que cada um deles executa, o instante em que isto ocorre e as estações com as quais mais se comunicam, tanto local como remotamente [13]. Estas informações podem ser obtidas através de consultas aos grupos aplication-layer host e application-layer matrix.

8 O grupo application-layer host é formado por uma tabela de controle (hlhostcontrol), que é a mesma do grupo network-layer host, e uma tabela de dados (alhost), conforme ilustrado na figura 2. A tabela alhost permite ao administrador observar o tráfego de entrada e saída de um equipamento, considerando os protocolos de nível de aplicação. O termo nível de aplicação refere-se a todos os protocolos acima do nível de rede [12]. hlhostcontrolindex Tabela hlhostcontrol hlhostcontrolindex alhosttimemark protocoldirlocalindex nlhostaddress protocoldirlocalindex Objetos Colunares (ip/ethernet) (http/tcp/ip/ethernet) hlhostcontroldatasource hlhostcontrolnldroppedframes hlhostcontrolnlinserts hlhostcontrolnldeletes hlhostcontrolnlmaxdesiredentries (ip/ethernet) (http/tcp/ip/ethernet) hlhostcontrolaldroppedframes hlhostcontrolalinserts hlhostcontrolaldeletes hlhostcontrolalmaxdesiredentries Figura 2. Tabelas do grupo alhost Objetos Colunares alhostinpackets alhostoutpackets alhostinoctets alhostoutoctets alhostcreatetime Tabela alhost Há uma ou mais entradas na tabela alhost para cada protocolo do nível de aplicação descoberto. Estas entradas são organizadas também por endereços do nível de rede, de modo que é possível saber, por exemplo, o volume de tráfego HTTP proveniente ou destinado a uma determinada estação. A tabela é indexada por cinco objetos: - hlhostcontrolindex: indica um dos segmentos onde o probe está atuando; - alhosttimemark: filtro de tempo; - protocoldirlocalindex: identidade do protocolo do nível de rede; - nlhostaddress: o endereço de rede; - protocoldirlocalindex: identidade do protocolo do nível de aplicação. Observe que o objeto protocolodirlocalindex é utilizado duas vezes para indexar a tabela; é válido ressaltar que são utilizadas duas instâncias distintas deste objeto: uma para identificar o protocolo do nível de rede e outra, para o protocolo do nível de aplicação [13]. A tabela 2 ilustra um exemplo de informações obtidas com uma consulta ao grupo alhost. Consultas periódicas a este grupo permitem determinar as aplicações e protocolos que os usuários mais utilizam, bem como os horários em que estes acessos ocorrem. Tabela 2 - Exemplo de informações obtidas com consulta ao grupo alhost HostAddress Protocol InPkts OutPkts InOctets OutOctets HTTP SMTP FTP HTTP Usuários x Comunicações Estabelecidas Para ir além e conhecer com quem os usuários da rede se comunicam e que protocolos estão envolvidos, pode-se recorrer ao grupo aplication-layer matrix. Este grupo opera com a coleta de estatísticas em pares de estações, com base no endereço do nível de rede. É composto por várias tabelas; duas delas são ilustradas na figura 3.

9 hlmatrixcontrolindex Tabela hlmatrixcontrol hlmatrixcontrolindex almatrixsdtimemark protocoldirlocalindex nlmatrixsdsourceaddress nlmatrixsddestaddress protocoldirlocalindex Objetos Colunares (ip/ethernet) (http/tcp/ip/ethernet) hlmatrixcontroldatasource hlmatrixcontrolnldroppedframes (ip/ethernet) (http/tcp/ip/ethernet) hlmatrixcontrolnlinserts hlmatrixcontrolnldeletes hlmatrixcontrolnlmaxdesiredentries hlmatrixcontrolaldroppedframes hlmatrixcontrolalinserts hlmatrixcontrolaldeletes hlmatrixcontrolalmaxdesiredentries Figura 3. Tabelas do grupo almatrix A tabela de controle (hlmatrixcontrol) é similar às tabelas de controle já apresentadas anteriormente. A tabela de dados (almatrixsd) armazena informações sobre o volume de tráfego monitorado entre os pares e é indexada pelos seguintes objetos [13]: -hlmatrixcontrolindex: indica um dos segmentos onde o probe está atuando; -almatrixsdtimemark: filtro de tempo; -protocoldirlocalindex: identifica de forma unívoca um protocolo do nível de rede; -nlmatrixsdsourceaddress: identifica a estação que originou os pacotes; -nlmatrixsdestaddress: identifica a estação que recebeu os pacotes; -protocoldirlocalindex: identidade do protocolo do nível de aplicação. Assim, para o par de estações origem-destino selecionados nos índices anteriores, este índice seleciona uma entrada única na tabela almatrixsd, que agrega estatísticas sobre o protocolo de aplicação que esteja sendo utilizado entre este par de estações. A tabela 3, abaixo, ilustra um exemplo de resultados que são obtidos ao realizar-se uma consulta à tabela almatrixsd. Como é possível observar, a tabela contabiliza o tráfego da origem para o destino e do destino para a origem em duas entradas distintas. Tabela 3 - Exemplo de informações obtidas com consulta à tabela almatrixsd Objetos Colunares almatrixsdpkts almatrixsdoctests almatrixsdcreatetime Tabela almatrixsd SDSourceAddress SDDestAddress Protocol SDPkts SDOctets altavista.digital.com 16 (http/tcp/ip/ethernet) altavista.digital.com (http/tcp/ip/ethernet) ftp.microsoft.com 17 (ftp/tcp/ip/ethernet) ftp.microsoft.com (ftp/tcp/ip/ethernet) (http/tcp/ip/ethernet) (http/tcp/ip/ethernet) Através de consultas periódicas ao probe RMON2, é possível determinar com quem uma determinada estação está se comunicando, que protocolos estão sendo utilizados e o volume de tráfego imposto por eles. A tabela 4 ilustra um exemplo de quadro demonstrativo das comunicações mantidas por uma estação de endereço em um intervalo de tempo compreendido entre t 1 e t 2. As informações retornadas indicam que o usuário na máquina está acessando via um navegador de Internet o site de procura Alta Vista e o servidor WWW da própria empresa. Além disto, está recuperando, via o protocolo FTP, um arquivo na Microsoft.

10 Tabela 4 - Comunicações mantidas por Endereço Destino Protocolo Bytes altavista.digital.com HTTP ftp.microsoft.com FTP HTTP FORNECIMENTO DE QoS As aplicações existentes atualmente não se utilizam de serviços Hard QoS e Soft QoS. Os serviços Hard QoS obrigam as aplicações a interagirem com APIs de programação na reserva dos recursos da rede. As aplicações não estão prontas para fazer esta reserva, e o método utilizado nesse processo ainda não é padronizado. Assim, quase não existem aplicações que se utilizam dos serviços Hard QoS diretamente. Em relação aos serviços Soft QoS, as aplicações devem marcar seus pacotes para que os mesmos sejam tratados diferentemente pela rede. Para cada fluxo um comportamento especial é tomado nos roteadores. A API de sockets fornece possibilidades, ainda que complexas, para que as aplicações procedam com esta marcação. Por outro lado, atualmente evidencia-se que muito poucas aplicações utilizam essas facilidades. Por fim, aplicações que se utilizam dos serviços best effort formam o maior número de ferramentas. Aqui existem dois casos: ou as aplicações confiam na rede de computadores e nos serviços oferecidos e são implementadas sem tomar consciência do estado da rede. Tais aplicações podem enfrentar problemas quando a rede de computadores apresentar congestionamentos. Outra situação é a das aplicações que utilizam best effort, mas verificam o estado da rede. Neste caso, as adaptações ocorrem, e a verificação do estado da rede é feita através do uso de RTP/RTCP. Existe atualmente um número considerável de aplicações que operam neste paradigma, principalmente aplicações de videoconferência. Tomando o quadro atual do relacionamento entre aplicações existentes e serviços QoS oferecidos, propomos a arquitetura de fornecimento de QoS apresentada nesta seção. A arquitetura é baseada nas seguintes considerações: - A derivação do comportamento das aplicações é feita através de consultas à MIB RMON2; - A monitoração dos recursos da rede é feita através de consultas à MIB-II nos roteadores; - Quando não existe solicitação explícita de recursos nas aplicações, seja através de RSVP ou a marcação de pacotes no DiffServ, o nível de QoS requerido é derivado da observação dos fluxos gerados; - O modelo assume que os recursos da rede podem ser sempre atualizados, não considerando, por exemplo, restrições financeiras. 5.1 Recolhimento de dados das aplicações Para se verificar o comportamento das aplicações que não solicitam QoS explicitamente através de RSVP, ou que não utilizam marcação do DS Field nos pacotes IP, é necessária a análise constante dos fluxos de dados gerados. A partir destes fluxos será possível verificar quais as necessidades de QoS das aplicações e proceder com o fornecimento dos parâmetros verificados.