Reconfiguração Dinâmica de Classes DiffServ no Suporte a QoS face à Dinâmica da Rede

Transcrição

1 Reconfiguração Dinâmica de Classes DiffServ no Suporte a QoS face à Dinâmica da Rede Lucio Agostinho 1, Diego S. Silveira 1, Rayner G. Sousa 2, Luis F. Faina 1 1 Faculdade de Computação - Universidade Federal Uberlândia (UFU) Caixa Postal Uberlândia - MG 2 Faculdade de Sistemas de Informação (FIMES) Caixa Postal Mineiros - GO Resumo Com o crescimento exponencial e a disseminação da Internet, uma grande quantidade de equipamentos e serviços têm sido criados, o que aumenta o congestionamento na rede. A maioria desses serviços contempla mídias contínuas como áudio e vídeo, altamente sensíveis ao estado rede, que demandam garantias de desempenho, ou seja, Qualidade de Serviço. Dentre os vários trabalhos que avaliam a provisão de QoS na Internet, destaca-se a Arquitetura DiffServ. Propõe-se neste trabalho a adição de elementos na Arquitetura DiffServ para fornecer suporte às exigências de QoS posto que a mesma não contempla negociação global de recursos nem monitoramento do desempenho contratado. Palavras-Chave: Arquitetura DiffServ, QoS, Bandwidth Broker, CORBA, Linux. 1. Introdução Com a convergência dos mercados de entretenimento, telefonia fixa e móvel, bem como da Internet, a disponibilidade de banda de transmissão e garantias na oferta de serviços têm se mostrado cada vez mais importantes. Na Internet, o máximo que conseguimos utilizando o protocolo TCP, por exemplo, é garantir a entrega de pacotes sem perdas, duplicações e erros. Para algumas aplicações, como FTP e Telnet, esta abordagem é válida, mas para muitas outras, a convergência desses mercados pouco resolve. Nesse contexto, destacamos as aplicações multimídia (fluxos contínuos de áudio e/ou vídeo) as quais exigem certas garantias de recursos para um funcionamento adequado. Nessa ótica, a Qualidade de Serviço (QoS) pode ser definida como um serviço da rede para as aplicações que demandam de garantias de recursos. Vários estudos são realizados pela IETF (Internet Engineering Task Force) para criar um padrão de provisão de QoS na Internet. Nesses estudos destacam-se o IntServ (Integrated Services [Braden et al. 1994, Wroclawski 1997]), o MPLS (Multi Protocol Label Switching [Rosen et al. 2001]) e o DiffServ (Differentiated Services [Blake et al. 1998]). Entre as várias propostas, a Arquitetura DiffServ destaca-se até o momento pela sua simplicidade de configuração e escalabilidade em relação às demais. Em sua concepção, fluxos que possuem as mesmas necessidades são agregados em uma única classe. Já os parâmetros de QoS são definidos em classes que deveriam ter prioridades diferentes. Assim, não há a necessidade de se guardar informações acerca de cada fluxo. Algumas questões ainda não foram definidas nessa Arquitetura. Dentre elas, não é especificado como o SLA (Service Level Agreement) é estabelecido entre o usuário e

2 o Domínio DiffServ. Também não é especificado nenhum controle de admissão, ou seja, fluxos podem ser associados a uma classe que não é mais suportada. Por fim, pela diversidade de fluxos e parâmetros associados à QoS, a classificação dinâmica dos mesmos constitui um atrativo para estudo. Propomos neste artigo a especificação de um modelo que ofereça a classificação dinâmica de fluxos, reclassificação quanto às alterações da banda desejada e adaptação do fluxo de mídia, caso não seja possível a reclassificação do mesmo em decorrência da falta de recursos. Outro aspecto também considerado é o mapeamento dos parâmetros de QoS da aplicação no nível do usuário para os da rede. Para tanto, um modelo baseado em brokers específicos é apresentado. Este artigo apresenta na Seção 2 a Arquitetura DiffServ bem como trabalhos relacionados e as respectivas abordagens para o problema de provisão de QoS na Rede Internet. Na Seção 3, apresentamos um modelo baseado em brokers para a geração dinâmica de classes, mapeamento e monitoramento de QoS utilizando os conceitos da Arquitetura DiffServ. A Seção 4 descreve as tecnologias utilizadas para implementação do modelo proposto. A Seção 5 descreve a atuação do Monitor-Adapter quando ocorre uma quebra do contrato de reserva de recursos pré-estabelecido. Finalmente, a Seção 6 tece considerações finais sobre o trabalho. 2. Qualidade de Serviço e Arquitetura DiffServ A Internet não oferece nenhum suporte na provisão, monitoramento e adaptação de parâmetros de QoS. Para uma dada aplicação, QoS pode ser definida como um conjunto de parâmetros e respectivas restrições que devem ser satisfeitas para que a aplicação opere dentro dos padrões especificados [da Rocha and Filho 2000]. A Arquitetura DiffServ (Fig. 1) é baseada no seguinte modelo: o tráfego que entra na rede é classificado e acondicionado junto aos nós de fronteira, ou nós de borda. No núcleo da rede, os pacotes recebem encaminhamento de acordo com o código DSCP (DiffServ Code Point) presente no campo DS Field (campo ToS para IPv4 ou campo Traffic Class para IPv6) do cabeçalho do pacote IP (Internet Protocol) [Nichols et al. 1998, Grossman 2002]. Fonte de Mídia Marcação DSCP Marcação DSCP Recptor de Mídia Tráfego de Ingresso Policiamento SLA (Service Level Agreement) Tráfego de Egresso Domínio DiffServ Fig. 1. Arquitetura DiffServ. O Domínio DiffServ é um conjunto de nós DiffServ que interpretam da mesma maneira os valores do campo DS Field do cabeçalho dos pacotes IP. O tráfego de ingresso é classificado, de forma que grupos de pacotes sejam encaminhados através do Domínio DiffServ respeitando as regras da disciplina de fila atribuída a cada grupo. A classificação de pacotes que possuem o mesmo Comportamento Agregado (Behaviour Aggregate (BA))

3 é feita através de classes que podem manter dois tipos de Comportamento por Etapa (Per Hop Behaviour (PHB)): classes AF (Assured Forwarding) que podem manter grupos de PHB com diferentes prioridades de encaminhamento e descarte de pacotes; e classes EF (Expedited Forwarding) que possibilitam alto nível de prioridade de encaminhamento de pacotes. Cabe às disciplinas de fila de cada classe implementar os PHB. Cada classe é dona de uma disciplina de fila que, por sua vez, pode manter outras classes. O SLA (Service Level Agreement) é um contrato entre o usuário e o provedor de serviços. O usuário compromete-se em gerar um fluxo de mídia com características que respeitem o contrato acordado. O provedor compromete-se a encaminhar o fluxo de mídia segundo as restrições impostas pelos parâmetros de QoS negociados com o usuário. O contrato SLA poderá ser composto de várias TCA (Traffic Conditioning Agreement). TCAs são sub contratos que especificam as regras de classificação, marcação, descarte e modelagem para que sejam aplicadas sobre os vários fluxos de mídia cobertos pelo SLA. Várias são as abordagens e propostas de uso da Arquitetura DiffServ no suporte ao oferecimento de QoS na Internet. Na proposta de Politis [Politis et al. 2000], o Bandwidth Broker é especificado na camada de controle de recursos (RCL - Resource Control Layer), que é sub-dividida em duas sub-camadas: a primeira camada composta pelo RCP (Resource Control Point) é responsável por gerenciar e distribuir recursos na rede; a segunda formada por dois componentes, o RCA (Resource Control Agent) responsável pelo controle de admissão e o AMW (Application Middleware) responsável por disponibilizar uma interface a partir da qual o usuário fornece os parâmetros de QoS. A ênfase do trabalho está na modelagem do gerenciamento de QoS em um Domínio DiffServ, mostrando a importância de se separar esses elementos. Para aplicações telemáticas, enquadradas como aplicações de tempo real, a negociação dos parâmetros de QoS não é conhecida pelo usuário, tornando difícil o seu fornecimento ao Application Middleware descrito anteriormente. Para contornar este problema, Rossano [Pinto et al. 2003] emprega além de um Bandwidth Broker, um Interceptador de QoS (IQoS). O IQoS é responsável pela negociação e mapeamento automático dos parâmetros de QoS da aplicação para a rede. Adicionalmente, uma implementação e testes sobre Plataforma Linux com aplicações que contemplam fluxos de áudio e vídeo confirmaram o mapeamento automático dos parâmetros de QoS. Na linha de trabalhos práticos, Kuznetsov [Kuznetsov ] apresenta um estudo utilizando a Plataforma Linux e o Pacote IPROUTE2 [Kuznetsov ], com o intuito de avaliar o desempenho das ferramentas bem como o comportamento das disciplinas de fila suportadas pelo kernel. Constituiu objeto de avaliação a classificação e policiamento dos roteadores de borda e de núcleo do Domínio DiffServ. Destaca-se aqui a importância na escolha da disciplina de policiamento de uma dada classe. Dentre as deficiências presentes na Arquitetura DiffServ, destacam-se a falta de mecanismos de controle de admissão, de controle de negociação recursos e de monitoramento. Na Arquitetura DiffServ a proposta não é oferecer uma garantia absoluta dos parâmetros de QoS, mas acomodar vários fluxos de mídia numa mesma classe e, assim, na configuração de um domínio, várias classes de serviços são criadas. Cada classe possui uma largura de banda associada. Quando o usuário deseja utilizar um serviço na rede, ele informa os valores dos parâmetros que atendem as suas necessidades.

4 3. Modelo Proposto para Incorporação de QoS com DiffServ Propõe-se neste trabalho elementos capazes de: a. mapear os parâmetros de QoS do nível do usuário para o nível de rede; b. negociar a banda de transmissão para que a aplicação seja informada se pode ou não ser atendida segundo o contrato pré-estabelecido; c. oferecer uma banda disponível com adaptação do fluxo na origem face às taxas de perda acima de um percentual especificado, se a banda de transmissão não puder ser atendida, mesmo depois de negociada. A Fig. 2 ilustra estes elementos: IQoS (Interceptor QoS), BB (Bandwidth Broker), TCD (Traffic Control Daemon) e Monitor-Adapter. IQoS Monitor Adapter Bandwidth Broker TCD TCD TCD TCD IQoS Fig. 2. Elementos do Modelo Proposto IQoS - Interceptor QoS O IQoS é o elemento responsável por receber da aplicação do usuário os parâmetros de QoS. Após a tradução, o BB é contactado a fim de que o domínio DiffServ dê um tratamento adequado ao fluxo a ser criado. Com a utilização do IQoS a aplicação não precisa se preocupar com todos os aspectos de requisição de banda. Portanto, o IQoS exporta um conjunto de interfaces que as aplicações utilizem a QoS na rede. Se a rede não tiver condições para suportar a QoS exigida por um usuário, este deve ser notificado. Uma alternativa é que o usuário diminua as suas exigências e faça uma nova negociação de serviços. Caso contrário, ele receberá o tratamento BE (Better Effort). O fato da rede não suportar as exigências de QoS não significa que os fluxos não poderão ser criados, mas apenas que o Domínio DiffServ não irá prover nenhuma garantia. Outra tarefa do IQoS é a de sinalizar o BB após a finalização de um fluxo, pois as configurações das classes e dos filtros precisam ser desfeitas. BB - Bandwidth Broker Na Arquitetura IntServ um novo fluxo só é iniciado quando os recursos requisitados são reservados. A reserva é feita através do RSVP (Resource Reservation Protocol) que sinaliza todos os roteadores a reservarem recursos para o fluxo em particular. No DiffServ não existe nenhum elemento na rede que faça esse papel de controlador de admissão. Mesmo que os recursos sejam reservados por uma classe, é necessário saber o estado da rede. A tarefa do BB consiste em controlar a admissão de fluxo, negociar a largura de banda com o IQoS e configurar as classes e filtros no Domínio DiffServ. O BB deve ser único em cada domínio de forma a evitar conflitos de configuração. Com a alteração da utilização da rede ou pela renegociação feita pelo usuário, o BB deverá sinalizar o TCD para a redefinir as classes. Para que o BB possa saber quais são os TCDs espalhados pelo domínio, todos os TCDs devem se registrar no BB fornecendo as características de suas interfaces de rede e a sua localização dentro do Domínio DiffServ.

5 TCD - Traffic Control Daemon O TCD deve ser instanciado em todos os roteadores. Sua função é a de ser um mediador entre o BB e o roteador. Ele é dependente do sistema operacional pois deve saber como este último trata o controle de tráfego e quais as ferramentas utilizadas para isso. Após o recebimento de uma sinalização do BB, o TCD deve criar e/ou remover disciplinas de filas, classes ou filtros. Monitor-Adapter Após a admissão de um fluxo, um contrato de serviço com a caracterização da QoS que o usuário deseja receber é utilizado para que não ocorra nenhuma violação. Quando a violação é detectada uma nova readaptação da rede ou do serviço tem que ser realizada. O Monitor-Adapter possui a função de monitorar os parâmetros da rede relacionados com os serviços. Com base nas políticas previamente estabelecidas, ele pode requisitar que o BB reconfigure o Domínio DiffServ. Se a reconfiguração não for possível, duas alternativas são possíveis: a. o usuário será notificado e poderá fazer uma nova negociação; b. os parâmetros dos serviços sofrem atenuações para adequação à situação da rede. O monitoramento é realizado nos roteadores de bordas. 4. Arquitetura de Implementação do Modelo Proposto O desenvolvimento dos componentes do modelo (Fig. 2) está em conformidade com a Especificação CORBA (Common Object Request Broker Architecture [OMG 1999b]). CORBA define uma linguagem neutra, IDL (Interface Definition Language), que permite descrever a especificação de um objeto CORBA através de suas interfaces. Essas interfaces descritas em IDL podem ser implementadas em uma linguagem para a qual o mapeamento IDL esteja disponível, como JAVA ou C++, por exemplo. Em nosso projeto todos os componentes foram criados em linguagem JAVA. Como infra-estrutura CORBA utiliza-se o ORB (Object Request Broker) disponível no ambiente de desenvolvimento Java TM 2 [Microsystems 2000] (Java TM IDL). Suportando a especificação CORBA/IIOP [OMG 1999b] e com suporte ao mapeamento IDL/Java [OMG 1999a], Java TM IDL implementa um ORB para linguagem Java. Para usar Java IDL faz-se necessário a instalação da Plataforma Java TM 2 JDK 1.4 ou superior que já inclui o compilador idltj, além das classes org.omg.corba, org.omg.corba.orb e org.omg.cosnaming. Os fluxos de áudio e vídeo foram simulados através do aplicativo RUDE (Realtime UDP Data Emitter). A ferramenta RUDE é utilizada para gerar o tráfego na rede de acordo com um arquivo de script. Nesse arquivo são passados parâmetros como o tempo de duração, início de cada fluxo, porta de origem, porta de destino, endereço de destino, tamanho dos pacotes, taxa de geração dos pacotes e, opcionalmente, a definição do campo DS Field do pacote. Já o aplicativo CRUDE (Collector for RUDE), recebe o tráfego gerado pelo programa RUDE e cria um arquivo de log. A partir desse arquivo podem ser geradas informações para a análise do desempenho da rede, tais como: porcentagem de perda de pacotes, vazão, atraso fim-a-fim, jitter, entre outros. Em todos os computadores do Domínio DiffServ foi utilizado o Sistema Operacional Linux Slackware Para a configuração do controle de tráfego

6 utilizou-se o software tc (Traffic Control) e as disciplinas de filas HTB, TCINDEX e GRED [Almesberger 1999, Hubert 2002, Almesberger et al. 1999], disponíveis no kernel Monitoramento de uma classe AF A Fig. 3 ilustra o comportamento do fluxo02-af1 que na marca dos 25 segundos quebra o contrato e submete à rede uma taxa maior do que a contratada prejudicando o fluxo01- af1. Após 5 segundos o Monitor-Adapter detecta quebra de contrato e informa o BB qual aplicação é a responsável. Segundo a política de policiamento o BB concede o tratamento BE para o fluxo02-af1. No momento em que ocorre a mudança de classe o fluxo01-af1 passa a utilizar toda a banda de transmissão da classe. Fig. 3. Avaliação da Geração de Fluxo com DiffServ. 6. Conclusão A Arquitetura DiffServ destaca-se entre as alternativas para fornecer Qualidade de Serviço em redes de computadores porque permite a adição de elementos capazes de prover a reconfiguração dinâmica dos nós de um Domínio DiffServ com agregação de fluxos, o que implica em um nível de sinalização menor se comparado com arquiteturas que implementam o controle individual desses fluxos. A negociação global de recursos permite um acordo dinâmico entre o usuário da aplicação e o Domínio DiffServ (SLA). Isso é realizado juntamente com o monitoramento do desempenho contratado, o que possibilita uma readaptação do fluxo de acordo com os recursos disponíveis no momento da requisição de serviços da rede.

7 A forma como o Bandwidth Broker estabelece uma relação a cada requisição de aplicações e a avaliação da situação da rede provê um refinamento na provisão de QoS para as aplicações. Estas irão receber uma classe de acordo com o seu pedido, considerando o estado atual da rede. O projeto encontra-se em fase de implementação dos componentes BB, TCD e do ambiente visual para análise da situação do BB. Referências Almesberger, W. (1999). Linux Network Traffic Control - Implementation Overview. In 5th Annual Linux Expo, pages Almesberger, W., Salim, J., Kuznetsov, A., and Knuth, D. (1999). Differentiated Services on Linux. Tecnical Report ietf internet draft, Internet Enginnering Task Force. Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and Weiss, W. (1998). An architecture for Differentiated Services. Tecnhinal Report RFC 2475, Internet Engineering Task Force. Braden, R., Clack, D., and Shenker, S. (1994). Integrated Services in the Internet Architecture: an Overview. Tecnhinal Report RFC 1633, Internet Engineering Task Force. da Rocha, C. G. and Filho, G. L. (2000). Framework para provisão de Qualidade de Serviço em Redes IP. In II Workshop RNP2. Grossman, D. (2002). New Terminology and Clarification for DiffServ. Tecnhinal Report RFC 3260, Internet Engineering Task Force. Hubert, B. (2002). Linux Advanced Routing and Traffic Control HOWTO. LARC. URL at Kuznetsov, A. N. IPROUTET2 Utility Suite Howto. Microsystems, S. (2000). Java TM 2 Software Development Kit. Sun Microsystems. Nichols, K., Blanke, S., Baker, F., and Black, D. (1998). Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Tecnhinal Report RFC 2474, Internet Engineering Task Force. URL at OMG (1999a). Java Language Mapping to OMG IDL. Document formal/ , Object Management Group. URL at OMG (1999b). The Common Object Request Broker: Architecture and Specification - Version Document formal/ , Object Management Group. Pinto, R. P., Guimarães, E. G., Cardozo, E., and Magalhães, M. F. (2003). Incorporação de Qualidade de Serviço em Aplicações Telemáticas. In XXI Simpósio Brasileiro de Redes de Computadores - SBRC 2003, pages Politis, G., Sampatakos, P., and Venieres, I. (2000). Design of a Multi-layer Bandwidth Broker Architecture. Lecture Notes in Computer Science, Rosen, E., Viswanathan, A., and Callon, R. (2001). Multiprotocol Label Switching Architecture. Tecnhinal Report RFC 3031, Internet Engineering Task Force. Wroclawski, J. (1997). The Use of RSVP with IETF Integrated Services. Tecnhinal Report RFC 2210, Internet Engineering Task Force.