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

Reconfigurac¸ ˜ao Dinˆamica de Classes DiffServ

no Suporte a QoS face `a Dinˆamica da Rede

1_{Faculdade de Computac¸˜ao - Universidade Federal Uberlˆandia (UFU)}

Caixa Postal 593 - 38400-902 - Uberlˆandia - MG

2_{Faculdade de Sistemas de Informac¸˜ao (FIMES)}

Caixa Postal 104 - 75830-000 - Mineiros - GO Resumo

Com o crescimento exponencial e a disseminac¸˜ao da Internet, uma grande quan-tidade de equipamentos e servic¸os tˆem sido criados, o que aumenta o congestionamento na rede. A maioria desses servic¸os contempla m´ıdias cont´ınuas como ´audio e v´ıdeo, altamente sens´ıveis ao estado rede, que demandam garantias de desempenho, ou seja, Qualidade de Servic¸o. Dentre os v´arios trabalhos que avaliam a provis˜ao de QoS na Inter-net, destaca-se a Arquitetura DiffServ. Prop˜oe-se neste trabalho a adic¸˜ao de elementos na Arquitetura DiffServ para fornecer suporte `as exigˆencias de QoS posto que a mesma n˜ao contempla negociac¸˜ao global de recursos nem monitoramento do desempenho contratado. Palavras-Chave: Arquitetura DiffServ, QoS, Bandwidth Broker, CORBA, Linux.

1. Introduc¸˜ao

Com a convergˆencia dos mercados de entretenimento, telefonia fixa e m´ovel, bem como da Internet, a disponibilidade de banda de transmiss˜ao e garantias na oferta de servic¸os tˆem se mostrado cada vez mais importantes. Na Internet, o m´aximo que conseguimos utilizando o protocolo TCP, por exemplo, ´e garantir a entrega de pacotes sem perdas, duplicac¸˜oes e erros. Para algumas aplicac¸˜oes, como FTP e Telnet, esta abordagem ´e v´alida, mas para muitas outras, a convergˆencia desses mercados pouco resolve.

Nesse contexto, destacamos as aplicac¸˜oes multim´ıdia (fluxos cont´ınuos de ´audio e/ou v´ıdeo) as quais exigem certas garantias de recursos para um funcionamento ade-quado. Nessa ´otica, a Qualidade de Servic¸o (QoS) pode ser definida como um servic¸o da rede para as aplicac¸˜oes que demandam de garantias de recursos. V´arios estu-dos s˜ao realizaestu-dos pela IETF (Internet Engineering Task Force) para criar um padr˜ao de provis˜ao de QoS na Internet. Nesses estudos destacam-se o IntServ (Integrated

Services [Braden et al. 1994, Wroclawski 1997]), o MPLS (Multi Protocol Label Swit-ching [Rosen et al. 2001]) e o DiffServ (Differentiated Services [Blake et al. 1998]).

Entre as v´arias propostas, a Arquitetura DiffServ destaca-se at´e o momento pela sua simplicidade de configurac¸˜ao e escalabilidade em relac¸˜ao `as demais. Em sua concepc¸˜ao, fluxos que possuem as mesmas necessidades s˜ao agregados em uma ´unica classe. J´a os parˆametros de QoS s˜ao definidos em classes que deveriam ter prioridades diferentes. Assim, n˜ao h´a a necessidade de se guardar informac¸˜oes acerca de cada fluxo.

Algumas quest˜oes ainda n˜ao foram definidas nessa Arquitetura. Dentre elas, n˜ao ´e especificado como o SLA (Service Level Agreement) ´e estabelecido entre o usu´ario e

o Dom´ınio DiffServ. Tamb´em n˜ao ´e especificado nenhum controle de admiss˜ao, ou seja, fluxos podem ser associados a uma classe que n˜ao ´e mais suportada. Por fim, pela di-versidade de fluxos e parˆametros associados `a QoS, a classificac¸˜ao dinˆamica dos mesmos constitui um atrativo para estudo.

Propomos neste artigo a especificac¸˜ao de um modelo que oferec¸a a classificac¸˜ao dinˆamica de fluxos, reclassificac¸˜ao quanto `as alterac¸˜oes da banda desejada e adaptac¸˜ao do fluxo de m´ıdia, caso n˜ao seja poss´ıvel a reclassificac¸˜ao do mesmo em decorrˆencia da falta de recursos. Outro aspecto tamb´em considerado ´e o mapeamento dos parˆametros de QoS da aplicac¸˜ao no n´ıvel do usu´ario para os da rede. Para tanto, um modelo baseado em

brokers espec´ıficos ´e apresentado.

Este artigo apresenta na Sec¸˜ao 2 a Arquitetura DiffServ bem como trabalhos re-lacionados e as respectivas abordagens para o problema de provis˜ao de QoS na Rede Internet. Na Sec¸˜ao 3, apresentamos um modelo baseado em brokers para a gerac¸˜ao dinˆamica de classes, mapeamento e monitoramento de QoS utilizando os conceitos da Arquitetura DiffServ. A Sec¸˜ao 4 descreve as tecnologias utilizadas para implementac¸˜ao do modelo proposto. A Sec¸˜ao 5 descreve a atuac¸˜ao do Monitor-Adapter quando ocorre uma quebra do contrato de reserva de recursos pr´e-estabelecido. Finalmente, a Sec¸˜ao 6 tece considerac¸˜oes finais sobre o trabalho.

2. Qualidade de Servic¸o e Arquitetura DiffServ

A Internet n˜ao oferece nenhum suporte na provis˜ao, monitoramento e adaptac¸˜ao de parˆametros de QoS. Para uma dada aplicac¸˜ao, QoS pode ser definida como um conjunto de parˆametros e respectivas restric¸˜oes que devem ser satisfeitas para que a aplicac¸˜ao opere dentro dos padr˜oes especificados [da Rocha and Filho 2000].

A Arquitetura DiffServ (Fig. 1) ´e baseada no seguinte modelo: o tr´afego que entra na rede ´e classificado e acondicionado junto aos n´os de fronteira, ou n´os de borda. No n´ucleo da rede, os pacotes recebem encaminhamento de acordo com o c´odigo DSCP (DiffServ Code Point) presente no campo DS Field (campo ToS para IPv4 ou campo Traffic Class para IPv6) do cabec¸alho do pacote IP (Internet Protocol) [Nichols et al. 1998, Grossman 2002].

DSCP Marcação

DSCP Marcação

Fonte de Mídia Recptor de Mídia

Tráfego de Egresso Ingresso

Tráfego de

SLA (Service Level Agreement)

Domínio DiffServ Policiamento

Fig. 1. Arquitetura DiffServ.

O Dom´ınio DiffServ ´e um conjunto de n´os DiffServ que interpretam da mesma maneira os valores do campo DS Field do cabec¸alho dos pacotes IP. O tr´afego de ingresso ´e classificado, de forma que grupos de pacotes sejam encaminhados atrav´es do Dom´ınio DiffServ respeitando as regras da disciplina de fila atribu´ıda a cada grupo. A classificac¸˜ao de pacotes que possuem o mesmo Comportamento Agregado (Behaviour Aggregate (BA))

´e feita atrav´es 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 `as disciplinas de fila de cada classe implementar os PHB. Cada classe ´e “dona” de uma disciplina de fila que, por sua vez, pode manter outras classes.

O SLA (Service Level Agreement) ´e um contrato entre o usu´ario e o provedor de servic¸os. O usu´ario 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 restric¸˜oes impostas pelos parˆametros de QoS negociados com o usu´ario. O contrato SLA poder´a ser composto de v´arias TCA (Traffic Conditioning Agreement). TCAs s˜ao sub contratos que especificam as regras de classificac¸˜ao, marcac¸˜ao, descarte e modelagem para que sejam aplicadas sobre os v´arios fluxos de m´ıdia cobertos pelo SLA. V´arias s˜ao 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 ´e especificado na camada de controle de recursos (RCL - Resource Control Layer),

que ´e sub-dividida em duas sub-camadas: a primeira camada composta pelo RCP

(Re-source Control Point) ´e respons´avel por gerenciar e distribuir recursos na rede; a segunda

formada por dois componentes, o RCA (Resource Control Agent) respons´avel pelo con-trole de admiss˜ao e o AMW (Application Middleware) respons´avel por disponibilizar uma interface a partir da qual o usu´ario fornece os parˆametros de QoS. A ˆenfase do trabalho est´a na modelagem do gerenciamento de QoS em um Dom´ınio DiffServ, mostrando a importˆancia de se separar esses elementos.

Para aplicac¸˜oes telem´aticas, enquadradas como aplicac¸˜oes de tempo real, a negociac¸˜ao dos parˆametros de QoS n˜ao ´e conhecida pelo usu´ario, tornando dif´ıcil o seu fornecimento ao Application Middleware descrito anteriormente. Para contornar este pro-blema, Rossano [Pinto et al. 2003] emprega al´em de um Bandwidth Broker, um Intercep-tador de QoS (IQoS). O IQoS ´e respons´avel pela negociac¸˜ao e mapeamento autom´atico dos parˆametros de QoS da aplicac¸˜ao para a rede. Adicionalmente, uma implementac¸˜ao e testes sobre Plataforma Linux com aplicac¸˜oes que contemplam fluxos de ´audio e v´ıdeo confirmaram o mapeamento autom´atico dos parˆametros de QoS.

Na linha de trabalhos pr´aticos, Kuznetsov [Kuznetsov ] apresenta um estudo uti-lizando 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 su-portadas pelo kernel. Constituiu objeto de avaliac¸˜ao a classificac¸˜ao e policiamento dos roteadores de borda e de n´ucleo do Dom´ınio DiffServ. Destaca-se aqui a importˆancia na escolha da disciplina de policiamento de uma dada classe.

Dentre as deficiˆencias presentes na Arquitetura DiffServ, destacam-se a falta de mecanismos de controle de admiss˜ao, de controle de negociac¸˜ao recursos e de monito-ramento. Na Arquitetura DiffServ a proposta n˜ao ´e oferecer uma garantia absoluta dos parˆametros de QoS, mas acomodar v´arios fluxos de m´ıdia numa mesma classe e, assim, na configurac¸˜ao de um dom´ınio, v´arias classes de servic¸os s˜ao criadas. Cada classe possui uma largura de banda associada. Quando o usu´ario deseja utilizar um servic¸o na rede, ele informa os valores dos parˆametros que atendem as suas necessidades.

3. Modelo Proposto para Incorporac¸˜ao de QoS com DiffServ

Prop˜oe-se neste trabalho elementos capazes de: a. mapear os parˆametros de QoS do n´ıvel do usu´ario para o n´ıvel de rede; b. negociar a banda de transmiss˜ao para que a aplicac¸˜ao seja informada se pode ou n˜ao ser atendida segundo o contrato pr´e-estabelecido; c. oferecer uma banda dispon´ıvel com adaptac¸˜ao do fluxo na origem face `as taxas de perda acima de um percentual especificado, se a banda de transmiss˜ao n˜ao 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.

TCD TCD TCD TCD

Monitor − Adapter

IQoS IQoS

Bandwidth Broker

Fig. 2. Elementos do Modelo Proposto

IQoS - Interceptor QoS

O IQoS ´e o elemento respons´avel por receber da aplicac¸˜ao do usu´ario os parˆametros de QoS. Ap´os a traduc¸˜ao, o BB ´e contactado a fim de que o dom´ınio DiffServ dˆe um tratamento adequado ao fluxo a ser criado. Com a utilizac¸˜ao do IQoS a aplicac¸˜ao n˜ao precisa se preocupar com todos os aspectos de requisic¸˜ao de banda. Portanto, o IQoS exporta um conjunto de interfaces que as aplicac¸˜oes utilizem a QoS na rede.

Se a rede n˜ao tiver condic¸˜oes para suportar a QoS exigida por um usu´ario, este deve ser notificado. Uma alternativa ´e que o usu´ario diminua as suas exigˆencias e fac¸a uma nova negociac¸˜ao de servic¸os. Caso contr´ario, ele receber´a o tratamento BE (Better

Effort). O fato da rede n˜ao suportar as exigˆencias de QoS n˜ao significa que os fluxos

n˜ao poder˜ao ser criados, mas apenas que o Dom´ınio DiffServ n˜ao ir´a prover nenhuma garantia. Outra tarefa do IQoS ´e a de sinalizar o BB ap´os a finalizac¸˜ao de um fluxo, pois as configurac¸˜oes das classes e dos filtros precisam ser desfeitas.

BB - Bandwidth Broker

Na Arquitetura IntServ um novo fluxo s´o ´e iniciado quando os recursos requisitados s˜ao reservados. A reserva ´e feita atrav´es do RSVP (Resource Reservation Protocol) que sina-liza todos os roteadores a reservarem recursos para o fluxo em particular. No DiffServ n˜ao existe nenhum elemento na rede que fac¸a esse papel de controlador de admiss˜ao. Mesmo que os recursos sejam reservados por uma classe, ´e necess´ario saber o estado da rede.

A tarefa do BB consiste em controlar a admiss˜ao de fluxo, negociar a largura de banda com o IQoS e configurar as classes e filtros no Dom´ınio DiffServ. O BB deve ser ´unico em cada dom´ınio de forma a evitar conflitos de configurac¸˜ao. Com a alterac¸˜ao da utilizac¸˜ao da rede ou pela renegociac¸˜ao feita pelo usu´ario, o BB dever´a sinalizar o TCD para a redefinir as classes. Para que o BB possa saber quais s˜ao 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 localizac¸˜ao dentro do Dom´ınio DiffServ.

TCD - Traffic Control Daemon

O TCD deve ser instanciado em todos os roteadores. Sua func¸˜ao ´e a de ser um mediador entre o BB e o roteador. Ele ´e dependente do sistema operacional pois deve saber como este ´ultimo trata o controle de tr´afego e quais as ferramentas utilizadas para isso. Ap´os o recebimento de uma sinalizac¸˜ao do BB, o TCD deve criar e/ou remover disciplinas de filas, classes ou filtros.

Monitor-Adapter

Ap´os a admiss˜ao de um fluxo, um contrato de servic¸o com a caracterizac¸˜ao da QoS que o usu´ario deseja receber ´e utilizado para que n˜ao ocorra nenhuma violac¸˜ao. Quando a violac¸˜ao ´e detectada uma nova readaptac¸˜ao da rede ou do servic¸o tem que ser realizada.

O Monitor-Adapter possui a func¸˜ao de monitorar os parˆametros da rede relacio-nados com os servic¸os. Com base nas pol´ıticas previamente estabelecidas, ele pode re-quisitar que o BB reconfigure o Dom´ınio DiffServ. Se a reconfigurac¸˜ao n˜ao for poss´ıvel, duas alternativas s˜ao poss´ıveis: a. o usu´ario ser´a notificado e poder´a fazer uma nova negociac¸˜ao; b. os parˆametros dos servic¸os sofrem atenuac¸˜oes para adequac¸˜ao `a situac¸˜ao da rede. O monitoramento ´e realizado nos roteadores de bordas.

4. Arquitetura de Implementac¸˜ao do Modelo Proposto

O desenvolvimento dos componentes do modelo (Fig. 2) est´a em conformidade com a Especificac¸˜ao CORBA (Common Object Request Broker Architecture [OMG 1999b]). CORBA define uma linguagem neutra, IDL (Interface Definition Language), que per-mite descrever a especificac¸˜ao de um objeto CORBA atrav´es 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) dis-pon´ıvel no ambiente de desenvolvimento JavaTM _{2 [Microsystems 2000] (Java}TM _IDL).

Suportando a especificac¸˜ao CORBA/IIOP [OMG 1999b] e com suporte ao mapea-mento IDL/Java [OMG 1999a], JavaTM _{IDL implementa um ORB para linguagem Java.}

Para usar Java IDL faz-se necess´ario a instalac¸˜ao da Plataforma JavaTM 2 JDK 1.4 ou superior que j´a inclui o compilador idltj, al´em das classes org.omg.CORBA,

org.omg.CORBA.ORBeorg.omg.CosNaming.

Os fluxos de ´audio e v´ıdeo foram simulados atrav´es do aplicativo RUDE

(Real-time UDP Data Emitter). A ferramenta RUDE ´e utilizada para gerar o tr´afego na rede de

acordo com um arquivo de script. Nesse arquivo s˜ao passados parˆametros como o tempo de durac¸˜ao, in´ıcio de cada fluxo, porta de origem, porta de destino, enderec¸o de destino, tamanho dos pacotes, taxa de gerac¸˜ao dos pacotes e, opcionalmente, a definic¸˜ao do campo DS Field do pacote. J´a o aplicativo CRUDE (Collector for RUDE), recebe o tr´afego gerado pelo programa RUDE e cria um arquivo de log. A partir desse arquivo podem ser geradas informac¸˜oes para a an´alise do desempenho da rede, tais como: porcentagem de perda de pacotes, vaz˜ao, atraso fim-a-fim, jitter, entre outros.

Em todos os computadores do Dom´ınio DiffServ foi utilizado o Sistema Operacional Linux Slackware 10.2. Para a configurac¸˜ao do controle de tr´afego

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 2.6.15.6.

5. 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 `a rede uma taxa maior do que a contratada prejudicando o

“fluxo01-af1”. Ap´os 5 segundos o Monitor-Adapter detecta quebra de contrato e informa o BB

qual aplicac¸˜ao ´e a respons´avel. Segundo a pol´ıtica de policiamento o BB concede o tratamento BE para o “fluxo02-af1”. No momento em que ocorre a mudanc¸a de classe o

“fluxo01-af1” passa a utilizar toda a banda de transmiss˜ao da classe.

Fig. 3. Avaliac¸ ˜ao da Gerac¸ ˜ao de Fluxo com DiffServ.

6. Conclus˜ao

A Arquitetura DiffServ destaca-se entre as alternativas para fornecer Qualidade de Servic¸o em redes de computadores porque permite a adic¸˜ao de elementos capazes de prover a reconfigurac¸˜ao dinˆamica dos n´os de um Dom´ınio DiffServ com agregac¸˜ao de fluxos, o que implica em um n´ıvel de sinalizac¸˜ao menor se comparado com arquiteturas que imple-mentam o controle individual desses fluxos.

A negociac¸˜ao global de recursos permite um acordo dinˆamico entre o usu´ario da aplicac¸˜ao e o Dom´ınio DiffServ (SLA). Isso ´e realizado juntamente com o monitoramento do desempenho contratado, o que possibilita uma readaptac¸˜ao do fluxo de acordo com os recursos dispon´ıveis no momento da requisic¸˜ao de servic¸os da rede.

A forma como o Bandwidth Broker estabelece uma relac¸˜ao a cada requisic¸˜ao de aplicac¸˜oes e a avaliac¸˜ao da situac¸˜ao da rede provˆe um refinamento na provis˜ao de QoS para as aplicac¸˜oes. Estas ir˜ao receber uma classe de acordo com o seu pedido, consi-derando o estado atual da rede. O projeto encontra-se em fase de implementac¸˜ao dos componentes BB, TCD e do ambiente visual para an´alise da situac¸˜ao do BB.

Referˆencias

Almesberger, W. (1999). “Linux Network Traffic Control - Implementation Overview”. In 5th Annual Linux Expo, pages 153–164.

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

archi-tecture for Differentiated Services ”. Tecnhinal Report RFC 2475, Internet Engineering Task Force.

Braden, R., Clack, D., and Shenker, S. (1994). “Integrated Services in the Internet Archi-tecture: an Overview”. Tecnhinal Report RFC 1633, Internet Engineering Task Force. da Rocha, C. G. and Filho, G. L. (2000). “Framework para provis˜ao de Qualidade de

Servic¸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 athttp://lartc.org/lartc.pdf.

Kuznetsov, A. N. “IPROUTET2 Utility Suite Howto”. www.linuxgrill.com.

Microsystems, S. (2000). “JavaTM 2 Software Development Kit”. Sun Microsystems. http://www.java.sun.com/products/.

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 athttp://www.ietf.org.

OMG (1999a). “Java Language Mapping to OMG IDL”. Document formal/99-07-59, Object Management Group. URL athttp://www.omg.org.

OMG (1999b). “The Common Object Request Broker: Architecture and Specification -Version 2.3.1”. Document formal/99-10-07, Object Management Group.

Pinto, R. P., Guimar˜aes, E. G., Cardozo, E., and Magalh˜aes, M. F. (2003). “Incorporac¸˜ao de Qualidade de Servic¸o em Aplicac¸˜oes Telem´aticas”. In XXI Simp´osio Brasileiro de

Redes de Computadores - SBRC 2003, pages 331–346.

Politis, G., Sampatakos, P., and Venieres, I. (2000). “Design of a Multi-layer Bandwidth Broker Architecture”. Lecture Notes in Computer Science, 1938.

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.