UNICAMP – Universidade Estadual de Campinas

FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO
Departamento de Engenharia de Computação e Automação Industrial

Mestrado em Engenharia Elétrica

 

 

 

 

 

 

 

 

 

Modelagem de uma Rede com suporte a QoS para Serviços Diferenciados

 

Trabalho de Pós-Graduação apresentado ao Departamento de Engenharia de Computação e Automação Industrial como avaliação parcial da Disciplina de Introdução à Teoria de Agentes – IA009, para a Faculdade de Engenharia Elétrica e de Computação, Universidade Estadual de Campinas.

Professor: Ricardo Ribeiro Gudwin

 

 

 

 

 

 

 

GIOVANI MOTTER

RA: 014863

 

 

 

 

 

Campinas, 08 de dezembro de 2002





Modelagem de uma Rede com suporte a QoS para Serviços Diferenciados


  1. Introdução
  2. O TCP (Transmission Control Protocol) é atualmente o protocolo do nível de transporte mais utilizado na Internet. Aplicações populares como Web, FTP e correio eletrônico, utilizam nas pontas destas aplicações os serviços confiáveis do TCP (CYCLADES, 1999). O desempenho fim-a-fim que os usuários experimentam destes serviços depende muito do próprio desempenho do TCP. No entanto, no que diz respeito ao oferecimento de Qualidade de Serviço (QoS – Quality of Service) na Internet, as redes baseadas na tecnologia TCP/IP – plataforma padrão na Internet – tradicionalmente oferecem apenas serviços de melhor esforço (BE – Best Effort). Com este modelo de serviço a rede não pode fornecer garantias quanto a taxas de perda, largura de banda ou atraso, além disso, o tratamento fornecido aos fluxos de tráfego é similar para todos os tipos de aplicações e usuários.

    Com o avanço das aplicações Internet surgiu-se a necessidade do estabelecimento de classes de serviços com diferentes prioridades e certas garantias de disponibilidade de recursos da rede. Uma das propostas para atender esta demanda é a arquitetura de serviços diferenciados (DiffServ – Differentiated Services), cujo objetivo é fornecer diferentes classes de serviço aos fluxos de maneira escalável. A essência do modelo de Serviços Diferenciados consiste em dividir os fluxos de tráfego em classes distintas e marcar os pacotes para identificar a classe correspondente. Os pacotes então recebem um tratamento específico, de acordo com a classe de serviço a que pertencem (STARDUST, 2002).

    Objetivando visualizar o funcionamento e o comportamento de uma arquitetura de serviços diferenciados para o fornecimento de QoS, modelaremos esta arquitetura como uma rede de agentes semiônicos, utilizando a ferramenta SNTool para as simulações. As próximas seções descrevem o modelo implementado e os resultados das simulações.

     

     

  3. Descrição da Arquitetura de Serviços Diferenciados
  4. O modelo Diffserv (Differentiated Services) proposto pelo IETF (Internet Engineering Task Force) foi desenvolvido com o objetivo de se criar uma arquitetura escalável para garantir QoS através da diferenciação dos serviços. A idéia deste modelo é garantir a escalabilidade através da agregação de diversos fluxos em um número fixo de classes de serviço, para provimento de diferentes níveis de QoS.

    As classes de serviço desejadas pelas aplicações são marcadas no campo DS – Differentiated Services, antigo campo TOS, no cabeçalho IP dos pacotes a serem enviados. De acordo com as diferentes classes de serviços solicitadas no campo DS, os roteadores darão o tratamento adequado a estes tráfegos, proporcionando-lhes níveis diferentes de QoS. O tratamento que uma determinada classe irá receber depende de um conjunto de regras que definem a forma de classificação, de tratamento, condicionamento e encaminhamento dos pacotes pertencentes a uma classe.

    O modelo DiffServ define três grupos de encaminhamento: Encaminhamento Expresso (EF – Express Forward), Encaminhamento Garantido (AF – Assured Forward), e Encaminhamento pelo Melhor Esforço (BE – Best Effort). Os dois grupos que possuem um diferencial no atendimento são os grupos EF e AF.

    A possibilidade de descarte em serviços da classe EF é mínima; a classe AF apresenta possibilidades de descartes maiores, dependendo do tipo de serviço desta classe (ouro, prata ou bronze) e do nível de descarte; a possibilidade de descarte no serviço BE é muito grande comparada com as demais classes de serviço.

    Ao receber um pacote, um roteador que implementa qualidade de serviço por serviços diferenciados primeiramente verifica como este pacote deve ser atendido (classe de serviço através do campo TOS). De acordo com a classe de serviço do pacote e com a disponibilidade de recursos de rede para o encaminhamento do mesmo, este pacote é atendido (entregue), ou descartado, forçando um reenvio do mesmo pelo emissor. As classes de serviço que fornecem algumas garantias de qualidade de serviço são a EF e a AF, esta última com algumas classes de serviço (ouro, prata e bronze) e níveis de descarte.

     

  5. Modelagem de uma Rede com suporte a QoS (DiffServ)
  6. Para a modelagem de uma rede com suporte a QoS em um domínio DiffServ, utilizamos a ferramenta SNTool para a definição da rede de agentes semiônicos. A Figura 1 ilustra a página com os lugares e os arcos que compõem o modelo.

    Figura 1: Modelagem da Rede com suporte a QoS (DiffServ)

    Nesta implementação, verificamos um agente fonte, responsável por introduzir novos agentes no sistema, identificado pelo lugar origemPacotes. Este lugar, ainda, é realimentado pelos pacotes que devem ser reenviados pelo roteador, pois houve algum erro durante a comunicação, ou não havia recursos suficientes para o atendimento do pacote.

    Um agente vertedouro, responsável por retirar agentes do sistema, é verificado no atendimento de um pacote. Um pacote, ao ser atendido com sucesso, é retirado do sistema.

    Algumas classes foram definidas para a implementação proposta:

     

     

  7. Simulação
  8. Para a simulação do modelo proposto utilizando a ferramenta SNTool, alguns índices foram verificados para que a simulação se tornasse a mais próxima da real. A Figura 2 mostra o estado da rede após o envio de 57 pacotes pelo agente fonte do sistema (origemPacotes). Na inicialização da página, os agentes que implementam funções são inseridos nos lugares, além dos agentes que são inseridos no agente fonte (100 agentes).

    Figura 2: Estado da rede durante a execução

    Na inicialização dos pacotes, adotamos um sorteio, através da geração de um número randômico (entre 0 e 1), e se o resultado deste sorteio apresentasse um índice maior que 0,85, então o pacote correspondente seria marcado como um pacote para ser manipulado pela classe de serviço EF; se o resultado fosse entre 0,5 e 0,85, então o pacote seria marcado como um pacote da classe de serviço AF; caso contrário, seria um pacote sem QoS, ou seja, seria marcado como BE. Para tanto, podemos observar uma distribuição de pacotes diferenciada entre as classes de serviço.

    A Figura 3 ilustra o estado da rede após a execução e atendimento dos 100 pacotes que foram gerados pelo agente fonte. Podemos observar nos estados internos dos agentes de manipulação de pacotes que a rede apresentou um comportamento esperado após a simulação, pois os índices de pacotes criados para cada tipo de serviço, além do número de pacotes atendidos e descartados obedeceram as configurações dos sorteios e os índices de descarte dos agentes de manipulação. Os resultados são sensíveis à geração de número aleatórios, que, em alguns casos, pode causar resultados não satisfatórios.

    Figura 3: Estado da rede após entrega de todos pacotes

    Ao variarmos alguns parâmetros podemos verificar comportamentos diferentes na rede. Por exemplo, ao diminuirmos a taxa de sucesso para pacotes marcados com tratamento BE, isto implica em um aumento de retransmissões no sistema, e um número maior de iterações para finalizar a execução e as transmissões. Esse impacto também é verificado se alterarmos parâmetros nos manipuladores para as classes de serviço EF e AF; a classe de serviço EF deve (ou deveria) apresentar taxas de perdas muito próximas de zero, e a classe de serviço AF deve apresentar garantias maiores e consideráveis quando comparada ao melhor-esforço (BE).

    Em uma outra situação, se considerarmos uma rede rápida e confiável, onde o tempo de atraso e a possibilidade de falhas é despresível, configuramos os parâmetros relacionados à taxa de sucesso de transmissão com um valor muito próximo a 1 (0,999 para EF, 0,98 para AF e 0,96 para BE). Com estas configurações, o comportamento da rede é muito próximo ao ideal (sem descarte de pacotes).

    Diferentes situações podem ser simuladas utilizando este modelo, o que pode vir ao auxílio de um administrador de rede para um melhor gerenciamento e aproveitamento dos recursos de rede.

     

  9. Conclusão
  10. De uma maneira geral, QoS especifica o grau de satisfação ou visão do usuário com relação à prestação de um serviço e pode ser definida quantitativamente em termos de parâmetros como, por exemplo, taxa de perda, atraso fim a fim, e jitter (variação do atraso). A provisão de QoS é fundamental para os negócios e aplicações de tempo real, tais como: telemedicina, videoconferência e educação à distância. Portanto, uma explosão considerável de atividade de pesquisa vem sendo conduzida no desenvolvimento de protocolos e arquiteturas para suportar tanto o tráfego tradicional, quanto o tráfego multimídia e de tempo real na Internet.

    Mecanismos de QoS fornecem serviços melhorados para os usuários da rede enquanto o administrador da rede gerencia os recursos da rede eficientemente. Estes mecanismos incluem ambos mecanismos de manipulação de tráfego e mecanismos de configuração. Os pontos de decisão de políticas fornecem um gerenciamento unificado para estes mecanismos de QoS.

    A criação de um modelo de um processo organizacional através de uma rede de agentes pode trazer resultados muito próximos aos reais em suas simulações. Neste trabalho, modelamos uma arquitetura de rede com suporte a QoS por serviços diferenciados e fizemos as simulações com o auxílio da ferramenta SNTool, e obtivemos resultados muito próximos aos reais, o que pode ser de fundamental importância para um melhor gerenciamento dos recursos de uma rede.

     

  11. Referências
    1. CYCLADES; 1999. Guia Internet de Conectividade. 5. Ed. São Paulo : Cyclades Brasil.
    2. DEITEL, Harvey M.; "JAVA: Como Programar", 3ª Ed. Bookman – Porto Alegre, 2001.
    3. STARDUST TECHNOLOGIES, INC; 1999. QoS Fórum. The Need for QoS - White Paper. http://www-sop.inria.fr/rodeo/rserban/Files/Need_for_QoS-v4.pdf. Acesso em: 30 outubro 2002
    4. Sun Microsystems; J2SE 1.4.1 API Specification. Disponível em: <http://java.sun.com/j2se/1.4.1/docs/api/>. Acesso em: 30 outubro 2002.
    5. SNTool; Semionic Network Toolkit. Disponível em: <http://sntool.sourceforge.net/>. Acesso em 30 outubro 2002.