Definição do Mecanismo de Controlo de Admissão para o Modelo de Serviço de LCT-UC 1

Transcrição

1 Definição do Mecanismo de Controlo de Admissão para o Modelo de Serviço de LCT-UC 1 Davide Lourenço, Marília Oliveira, Gonçalo Quadros, Edmundo Monteiro {pdavide, marilia, quadros, edmundo}@dei.uc.pt Laboratório de Comunicações e Telemática Centro de Informática e Sistemas da Universidade de Coimbra Polo II, Pinhal de Marrocos, 3030 Coimbra Sumário Para fornecer um serviço com qualidade, os sistemas de comunicação têm de ter capacidade para regularem a quantidade de tráfego suportada. O Controlo de Admissão dota os sistemas com esta funcionalidade. Neste contexto é apresentada uma estratégia de Controlo de Admissão para integrar num sistema capaz de suportar Qualidade de Serviço em redes IP. 1. Introdução A motivação subjacente ao desenvolvimento de novos modelos de serviço para as redes IP é o suporte de aplicações geradoras de tráfego com diferentes requisitos de Qualidade de Serviço (QoS), não compatíveis com o tradicional paradigma best-effort, actualmente em utilização na Internet. Neste contexto, está a ser desenvolvido no Laboratório de Comunicações e Telemática da Universidade de Coimbra (LCT-UC) um modelo de serviço para as redes IP cujo objectivo é fornecer diferentes níveis de serviço a tráfego com diversos requisitos de QoS. O modelo do LCT-UC adopta uma estratégia segundo a qual os recursos de rede são partilhados de forma justa por todos os fluxos suportados. Desta forma, para que a rede possa dar resposta aos requisitos de QoS das aplicações é fundamental que tenha capacidade para gerir os seus recursos e regular a carga a que está sujeita. Estas funcionalidades são fornecidas pelos mecanismos de Controlo de Admissão (CA) e Policiamento de Tráfego (PT). Neste documento é definida uma estratégia que, com base no nível de congestão experimentado pelo sistema de comunicação, permite suportar a tomada de decisão do mecanismo de controlo de admissão. A métrica de QoS do LCT-UC [QUADROS98] é utilizada para fornecer a imagem dinâmica do estado de congestão. 1 Trabalho parcialmente financiado pelo Programa de Investigação PRAXIS XII do Ministério da Ciência e Tecnologia, sob o contrato PRAXIS/P/EEI/10168/1998 (Projecto QoS II - Qualidade de Serviço em Sistemas de Comunicação por Computador). 1

2 2. Apresentação do Modelo de Serviço do LCT-UC O modelo de serviço do LCT-UC segue o paradigma de funcionamento da estratégia Differentiated Services (Diffserv) [BLAKE98] proposta pelo Internet Enginnering Task Force (IETF 2 ). Mantendo as características de simplicidade, robustez e escalabilidade, base do sucesso das redes IP, a agregação de fluxos com idênticos requisitos de QoS num conjunto limitado de classes constitui uma forma de fornecer QoS às aplicações. Neste contexto, e de acordo com a sensibilidade das aplicações a atrasos e a perdas, o LCT-UC propõe um novo PHB (Per-Hop Behaviour), designado por D3 Dynamic Degradation Distribution [QUADROS00], que agrega os fluxos em quatro classes servidas segundo o conceito multiple-class-best-effort. Esta abordagem baseia-se nos estudos de Gollick [GOLLICK99] segundo o qual, a maior parte das aplicações pode ser agrupada em quatro classes, utilizando como critério de classificação as características de qualidade de serviço - atraso e perdas. Sem introduzir grande complexidade no tradicional modelo das redes IP, por um lado, e adoptando tecnologias amplamente divulgadas, por outro, o modelo do LCT-UC fornece tratamento diverso a fluxos classificados em função da sensibilidade que as aplicações geradoras apresentam face a variações de QoS (mais precisamente, no que respeita às duas características anteriormente referidas [QUADROS99]). O modelo adopta uma estratégia em que a degradação das condições de serviço, provocada pelo aumento da carga na rede, é absorvida em grande parte pelas classes menos importantes, sendo, desta forma, protegidas as classes mais sensíveis. Subjacente a esta estratégia, o modelo faz a redistribuição dinâmica dos recursos - memória e largura de banda dos interfaces - pelas diferentes classes de serviço (CoS). Com este propósito é utilizada a métrica de QoS do LCT-UC, que considera o impacto que a degradação de serviço (experimentado por cada classe) tem no funcionamento das aplicações, como suporte do processo de alocação de recursos. A métrica do LCT-UC permite quantificar a QoS fornecida às aplicações, tendo em consideração a natureza heterogénea das características em causa (atrasos e perdas), através de índices de congestão 3. 2 < 3 A métrica do LCT representa o impacto que os atrasos e as perdas existentes nos encaminhadores têm no desempenho das aplicações sob a forma de índices de congestão. Desta forma, a métrica é constituída por um índice relativo a atrasos (IcA) e um índice relativo a perdas (IcP). 2

3 O processo de redistribuição de recursos é desencadeado de modo a igualar os índices de congestão (IcA e IcP) em todas as CoS, tornando, no entanto, o seu impacto dependente da maior, ou menor, importância relativa de cada uma. Com o objectivo de realizar encaminhamento com QoS no modelo de serviço do LCT-UC, está igualmente a ser desenvolvido um mecanismo (QoSR-LCT 4 ) que utiliza os índices de congestão como métrica no cálculo de caminhos. Este mecanismo, que está a ser implementado sobre o protocolo de encaminhamento dinâmico Open Shortest Path First (OSPF 5 ), associa a cada ligação um custo, cujo valor é calculado pela combinação linear ponderada dos dois índices de congestão. Este custo é calculado para cada uma das CoS implementadas, sendo a sensibilidade da classe a atrasos e a perdas quantificada pelos pesos utilizados na referida combinação. Como será apresentado posteriormente, é este valor custo de ligação - que constituirá a condição de admissão do mecanismo de CA na aceitação de um novo fluxo. Funcionando segundo o paradigma de melhor serviço possível em cada uma das classes, o modelo não oferece garantias firmes no que respeita ao desempenho do sistema de comunicação. Por outro lado, como não utiliza nenhum mecanismo de reserva de recursos, a qualidade de serviço fornecida em cada classe é dependente da quantidade de recursos (como já referido, memória e largura de banda dos interfaces) disponível em cada encaminhador. Neste contexto, torna-se incontornável a introdução de um mecanismo que dote o sistema de comunicação da capacidade de gerir os seus recursos e regular a carga a que está sujeito, controlando desta forma a degradação de qualidade de serviço observada em cada classe. Estas funcionalidades são fornecidas pelos mecanismos de Controlo de Admissão e de Policiamento de Tráfego. 3. Estratégia de Controlo de Admissão A definição da estratégia de CA é directamente influenciada pelas características do sistema de comunicação, em particular pelas características do modelo de QoS adoptado. Assim, em termos de CA, um modelo que fornece garantias de desempenho quantitativas apresenta requisitos bem diferentes dos apresentados por um modelo que apenas estabelece garantias qualitativas ou, ainda, das de um modelo que apenas garante a diferenciação de tratamento de fluxos, agrupados num conjunto de classes servidas o melhor possível. O grau 4 QoSR Quality of Service Routing [OLIVEIRA99]; 5 Definido pelo RFC1247 [MOY91]. 3

4 de eficiência que se pretende obter na utilização dos recursos do sistema de comunicação é igualmente, factor condicionante na definição da estratégia de CA. Desta forma, o mecanismo de CA deverá implementar a estratégia mais adequada ao modelo de serviço em causa, tendo em consideração, nomeadamente, o tipo de garantias fornecidas e o grau de eficiência pretendido na utilização dos recursos do sistema de comunicação. Por outro lado, e dependendo mais uma vez do modelo adoptado, a estratégia de CA pode adoptar um carácter implícito ou explícito. Nos modelos que efectuam reserva de recursos, o mecanismo de CA é implícito ao procedimento de reserva, isto é, um fluxo só é aceite se o sistema de comunicação tiver disponível a quantidade de recursos requerida pelo processo de reserva. O modelo Integrated Services (Intserv) [BRADEN94] proposto pelo IETF adopta este paradigma de funcionamento, utilizando o protocolo de sinalização Resource Reservation Protocol (RSVP 6 ) para efectuar a reserva de recursos. Nos modelos de serviço em que não são efectuadas reservas, os recursos do sistema de comunicação são partilhados pelos fluxos suportados, sendo a QoS fornecida a cada fluxo (ou agregados de fluxos) dependente do nível de congestão a que o sistema está sujeito. À semelhança do Diffserv, o modelo do LCT-UC segue este modo de funcionamento, tornando-se essencial a introdução de um mecanismo que capacite o sistema de comunicação da possibilidade de regular a quantidade de tráfego suportado Âmbito do CA no contexto do modelo de serviço do LCT-UC O objectivo do CA no contexto do modelo de serviço do LCT-UC é controlar e limitar a degradação de QoS experimentada pelas aplicações suportadas no sistema de comunicação. Assim, pretende-se implementar um mecanismo que condicione a admissão de tráfego (em cada uma das CoS), ao estado de congestão do sistema de comunicação. Esta estratégia segue a abordagem de Jamin [JAMIN96], segundo a qual a decisão de aceitação de um novo fluxo, em modelos de serviço cuja qualidade não é mensurável de forma quantitativa, deve ser suportada pelo estado de congestão do sistema de comunicação. Com o propósito apresentado é definido, para cada CoS, um limiar de congestão (Icmax) a partir do qual não é aceite mais tráfego. A atribuição deste valor tem ainda subjacente o compromisso QoS versus eficácia de utilização de recursos, sendo permitido ao gestor do domínio ajustar os 6 Definido pelo RFC 2205 [BRADEN97]. 4

5 limiares de congestão em função dos acordos/compromissos de serviço (Service Level Agreement - SLA) estabelecidos com os seus clientes. A imagem dinâmica do estado de congestão do sistema de comunicação é obtida pela métrica de QoS utilizada no modelo, sendo quantificada, como já referido, através de dois índices de congestão IcP (índice de congestão relativo a perdas) e IcA (índice de congestão relativo a atrasos). O mecanismo QoSR promove a divulgação dos índices de congestão no sistema de comunicação e calcula os percursos com base nos mesmos valores. Este mecanismo tem em consideração a sensibilidade a perdas e a atrasos de cada uma das CoS para combinar de forma linear os índices de congestão. Desta forma a cada percurso é atribuído um custo reflexo do estado de congestão do sistema de comunicação e das características de cada classe de tráfego. Este valor é então comparado com o limiar da CoS pretendida no sentido de verificar a possibilidade de admissão de um novo fluxo. À semelhança do modelo Diffserv, a CoS pretendida pela aplicação é especificada através da marcação do campo DSCP 7 (Differentiated Service Code Point) do cabeçalho IP de cada pacote (datagramas IP). Os pacotes que não tenham o campo DSCP marcado ou que o tenham com uma codificação desconhecida do domínio serão agregados na classe best effort isto é, na CoS menos favorecida em termos da QoS pelo PHB D3. De salientar ainda que o processo de admissão é selectivo, já que os limiares de admissão são diferentes para cada classe, sendo mais apertados para as classes mais bem tratadas e mais amplos para as restantes. Esta abordagem traduz-se na possibilidade de suportar um maior número de fluxos nas classes menos exigentes no que diz respeito à QoS que esperam do sistema de comunicação. De seguida é apresentado o mecanismo que implementa a estratégia de CA nos encaminhadores de entrada do domínio. 7 Redefinição do campo Type of Service (ToS) [NICHOLS98]. 5

6 4. Mecanismo de Controlo de Admissão A estratégia de CA apresentada define que a decisão de aceitação de um novo fluxo tem por base o resultado da comparação entre o custo associado ao percurso calculado pelo mecanismo QoSR e o limiar de congestão (Icmax) definido para a CoS pretendida. Do ponto de vista funcional, o nó cliente desencadeia o serviço de comunicação, cabendo ao encaminhador de entrada do domínio verificar se os pacotes recebidos pertencem a um fluxo já suportado ou, caso contrário, submeter o primeiro pacote do fluxo não reconhecido ao mecanismo de CA. O pedido de aceitação apresenta-se assim implícito ao processo de admissão, não ocorrendo nenhum pedido explícito de aceitação. Se o custo associado ao percurso calculado apresentar um valor inferior ao limiar máximo de congestão definido para essa classe, o fluxo é aceite pelo sistema de comunicação. Desta forma, a informação necessária à identificação unívoca do fluxo (campos: DSCP, endereço/porto fonte e endereço/porto destino) é inserida na estrutura de dados que contém os fluxos suportados nesse encaminhador de entrada. Se, pelo contrário, não existem condições para que o fluxo possa ser suportado isto é, a condição de aceitação não é verificada - a mesma informação é inserida na estrutura de dados que identifica os fluxos recusados. Neste caso, será ainda utilizado o protocolo ICMP 8 para gerar e enviar uma mensagem de erro (do tipo ICMP_UNREACH) ao nó que desencadeou o serviço de comunicação. Ao mecanismo de CA só é submetido o primeiro pacote de cada fluxo, sendo os seguintes alvo de processamento normal, no caso dos fluxos suportados, ou descartados (de imediato numa das primeiras verificações da camada protocolar IP), no caso de fluxos com referência na estrutura que identifica os fluxos que foram recusados. O funcionamento lógico do mecanismo descrito é apresentado de forma simplificada pelo fluxograma da Figura 1. 8 A utilização deste protocolo segue a estratégia preconizada no desenvolvimento do modelo de serviço do LCT-UC no que respeita à adopção de tecnologias já utilizadas e amplamente divulgadas nas actuais redes IP. 6

7 Figura 1 - Funcionamento lógico do mecanismo de CA Como referido, no encaminhamento dinâmico implementado pelo mecanismo QoSR, o caminho mais interessante para os pacotes de cada classe é determinado através da combinação linear ponderada dos índices de congestão. No âmbito do CA, a utilização dos índices considerados de forma isolada ou a sua combinação linear ponderada é ainda uma questão em aberto Estruturas de dados Para dar suporte ao mecanismo CA é definida a estrutura de dados apresentada na Figura 2. Esta estrutura é constituída por um array onde são identificadas as quatro CoS implementadas pelo PHB D3 do LCT-UC e por duas listas ligadas que identificam os fluxos suportados e os fluxos recusados em cada uma das CoS. 7

8 Figura 2 - Estrutura de dados de suporte ao mecanismo de CA A dimensão da estrutura estática (array) reflecte, assim, o número de CoS implementadas pelo modelo. Cada posição do array contém a identificação da CoS (código DSCP), o valor máximo do nível de congestão (isto é, o custo máximo aceitável para o percurso) a partir do qual não é aceite mais tráfego (LIMIAR) e o número de fluxos suportados (QTD) pela CoS. Cada posição contém ainda uma ligação à lista que identifica os fluxos suportados e uma ligação à lista que identifica os fluxos recusados pela CoS. As listas ligadas são estruturas dinâmicas actualizadas no decurso do funcionamento do encaminhador com informação referente quer aos fluxos suportados, quer aos recusados. Como se pode ver através da Figura 4.2, em ambas as listas é definida uma ligação entre cada célula representativa de um fluxo e a posição do array que caracteriza a CoS a que este pertence. Comum às células de ambas as listas são os campos, endereço IP origem, porto origem, endereço IP destino e porto destino que identificam univocamente cada fluxo. 8

9 4.2. Gestão de Classes A definição dos campos que constituem cada uma das células das estruturas dinâmicas tem subjacente a gestão adequada dos fluxos suportados e recusados por cada uma das quatro classes implementadas. Desta forma, as células da estrutura identificadora dos fluxos suportados, além dos já referidos campos que permitem identificar cada um dos fluxos, contêm o número de pacotes processados (N_DAT_PRC) e ainda uma variável T_LIVE que permite identificar se o fluxo permanece activo. Com base nesta variável são removidas da estrutura as células que representam fluxos não activos, isto é, fluxos dos quais não foi processado qualquer pacote durante um período de tempo predefinido. Na estrutura dos fluxos recusados, além dos campos de identificação de cada um dos fluxos, é definida uma variável (T_DROP) que determina o período de validade de cada célula na estrutura, findo o qual a célula será removida da lista. No contexto do mecanismo de CA, se o pacote em processamento pertencer a um fluxo com referência nesta estrutura será de imediato descartado. Um fluxo só pode voltar a ser submetido ao mecanismo de admissão, depois de removida a entrada que o identifica na estrutura de fluxos recusados, ou seja, ao fim do período definido pela variável T_DROP. Ainda no que respeita à gestão de classes, apresenta-se em aberto a possibilidade de utilizar no tráfego TCP a informação de controlo de sessão, assim como, a utilização de sinalização RSVP quando disponível Enquadramento do Mecanismo A Figura 3 apresenta o enquadramento dos mecanismos de CA e PT no protótipo do encaminhador que implementa o modelo de serviço do LCT-UC. Este protótipo faz parte da plataforma de desenvolvimento utilizada no LCT-UC, constituída por um conjunto de máquinas Intel, a cujo sistema operativo FreeBSD é adicionado a tecnologia ALTQ para implementar cada uma das filas que servem as diferentes CoS suportadas pelo modelo. Nesta figura, onde são identificados os dois andares de processamento do referido protótipo, os mecanismos de CA e PT são implementados ao nível do fluxo interagindo directamente com as funções que constituem a camada protocolar IP (IP Processing) do kernel do sistema operativo FreeBSD. 9

10 Figura 3- Enquadramento do módulo de CA A combinação dos mecanismos representados no andar de processamento de classes (Classifier, Scheduler, Monitor e Dropper) permite fornecer aos pacotes em processamento os serviços de encaminhamento definidos pelo PHB D3 proposto pelo LCT-UC. A entrada de pacotes na fila IPNTRQ é um processo assíncrono desencadeado por interrupções de software (ipintr). Quando um pacote 9 é recebido, estas interrupções de média prioridade (splnet) são activadas pela camada de interface 10, sendo invocadas as funções da camada protocolar IP para o processar. Como as interrupções de hardware, geradas pelo interface de rede à chegada de pacotes, têm uma prioridade de execução mais elevada (splimp), vários pacotes podem ser colocados na fila IPINTRQ antes que a interrupção de software possa ocorrer. A função ipintr remove cada um dos pacotes existentes na IPINTRQ retornando quando a fila fica vazia. Depois de retirado da fila é verificado pelo MONITOR se o pacote em processamento pertence a um fluxo já suportado, sendo neste caso submetido o mecanismo do PT. Por outro lado, se o pacote em processamento pertencer a um fluxo ainda não suportado, a rotina que implementa o mecanismo de CA é executada. Em conformidade com a decisão tomada com base na informação da congestão do sistema de comunicação, ambos os mecanismos actuam, ou não, no módulo de descartagem de pacotes (DROPPER). A informação de congestão é fornecida depois de encontrado o próximo destino para o pacote (rotina implementada no ip_output), segundo o percurso calculado pelo mecanismo de QoSR. 9 Cada pacote é transportado em unidades de memória designadas no FreeBSD por mbuf s (memory buffers); 10 A camada de interface equivale à camada de ligação lógica no modelo de referência OSI. 10

11 O mecanismo de CA está a ser implementado através da introdução de alterações nas funções que constituem o IP Processing, tendo em consideração a estratégia definida e a sequência de processamento apresentada. 5. Conclusões e trabalho futuro A capacidade de regular a carga num sistema de comunicação apresenta-se como factor crítico em modelos de serviço que, sem efectuarem reservas de recursos, fornecem serviço com qualidade. O modelo de serviço do LCT-UC encaixa-se neste conceito e, embora sem fornecer garantias quantitativas, disponibiliza a tráfego agregado em quatro classes, serviços diferenciados pela qualidade. No âmbito do modelo do LCT, a introdução de um mecanismo de controlo de admissão de fluxos tem por objectivo controlar a degradação do serviço fornecido em cada uma das CoS regulando o tráfego suportado em cada classe. Neste documento é apresentada uma estratégia que condiciona a admissão de um novo fluxo ao nível de congestão do sistema de comunicação, representado pelo custo associado a cada percurso. Como trabalho futuro pretende-se continuar a implementar a estratégia apresentada e, através de um conjunto de testes delineados para o efeito, aferir a sua real capacidade no controlo da degradação da qualidade de serviço nas classes suportadas pelo PHB D3. 11

12 REFERÊNCIAS [BLAKE98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998; [BRADEN94] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC 1633, June 1994; [BRADEN97] Resourse ReSerVation Portocol Funtional specification RFC 2205; [GOLLICK99] J. Gollick, Catching the Multimedia Wave, Data Communications, March [JAMIN96] S. Jamin, P. Danzig, S. Shenker, L. Zhang A Measuremente-based Admission Control Algorithm for Integrated Services Packet Networks (Extended Version), ACM/IEEE Transactions on Networking, 1996; [MOY98] OSPF Version 2 RFC 1247; [MONTEIRO96] E. Monteiro, G. Quadros, F. Boavida, A Scheme for the Quantification of Congestion in Communication Services and Sytems in AAVV, Proceeedings of the Third International Workshop on Services in Distributed and Networked Environments, Macau, June 1996; [NICHOLS98] Nichols, K., et al., Definition of Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers, RFC 2474, December 1998; [OLIVEIRA99] M. Oliveira, B. Melo, G. Quadros, E. Monteiro, Encaminhamento com Qualidade de Serviço: Estratégia QoSR-LCT Proceedings of Encontro de Engenharia Informática - EEI 99 da Ordem dos Engenheiros, Universidade do Minho, Braga, Portugal, December [QUADROS99] G. Quadros, E. Monteiro, F. Boavida, Approach to the Dynamic Forwarding of Packets in a Differentiated Service Based Router, Proceedings of SPIE International Symposium on Voice, Video, and Data Communications, Conference on Qaulity of Service Issues Related to Internet II, Boston, Massachusetts, USA, September 1999; [QUADROS98] G. Quadros, E. Monteiro, F. Boavida, A QoS Metric for Packet Networks, Proceedings of SPIE International Symposium on Voice, Video, and Data Communications, Conference 3529A, Hynes Convention Center, Boston, Massachusetts, USA, 1-5 November 1998; [QUADROS00] G. Quadros, A. Alves, E. Monteiro, F. Boavida, An Approach to Suport Traffic Classes in IP Networks, Proceedings of QofIS' The First International Workshop on Quality of future Internet Services, Berlin, Germany, September