IMPLEMENTAO DE POLTICAS DE GERENCIAMENTOCOM LGICA FUZZY E ALGORITMO GENTICO VISANDO

MELHORIA DA QUALIDADE DE SERVIO (QOS)

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de Rezende

Resumo -O Gerenciamento Baseado em Polticas uma tc-nica para coordenar a configurao de diversos equipamentosde uma rede, a partir de contratos administrativos (SLAs).Esses contratos indicam polticas abstratas difceis de sereminterpretadas e implementadas pelos equipamentos de rede,que requerem informaes absolutas. Como a lgica fuzzypossibilita a representao de valores abstratos, um controla-dor fuzzy foi utilizado para implementar um mecanismo deprovisionamento dinmico, reconfigurando os ns de acor-do como trfego. Esse trabalho prope uma metodologia deconstruo de um controlador para configurar o provisiona-mento de rede a partir de polticas de gerenciamento visandomelhorar a QoS em um domnio DiffServ. As funcionalida-des so demonstradas atravs de simulao de uma aplicaode Telefonia IP cruzando um domnio DiffServ.

Palavras-chave: Qualidade de Servio, DiffServ, Provisio-namento de Redes

Abstract - The policy based management is a technique tocoordinate the configuration of several equipments in a net-work, from Service Level Agreements (SLAs). These agree-ments produce abstract policies difficult to be interpreted andimplemented by network equipments, that requires absoluteinformation. As the fuzzy logic has been used to representabstract values, a fuzzy controller was used to implement adynamic provisioning mechanism to reconfigure all nodes ac-cording ingress traffic. This work proposes a methodology tomap management policies in fuzzy controller parameters toachieve the desired QoS in a DiffServ domain. The func-tionalities are demonstrated by simulation of a IP Telephonyapplication crossing a DiffServ domain.

Keywords: Quality of Service, DiffServ, Network Provision-ing

1. INTRODUO

A Diferenciao de Servios (DiffServ)[1] uma propostaque visa oferecer garantias de qualidade de servio (QoS) naInternet, consistindo em prover servios diferenciados para asagregaes de fluxos de dados. A arquitetura DiffServ esca-

Marcial Porto Fernandez pesquisador do Instituto de Computa-o da Universidade Federal Fluminense. Aloysio de Castro P. Pe-droza e Jos Ferreira de Rezende so professores do Programa deEngenharia Eltrica/COPPE e Escola Politcnica da UniversidadeFederal do Rio de Janeiro. E-mails: mfernandez@ic.uff.br, aloy-sio@gta.ufrj.br, rezende@gta.ufrj.br

lvel, oferecendo garantias para as diferentes classes, porm aQoS pode sofrer violaes quando ocorrer congestionamentona agregao de vrios fluxos de uma mesma classe devidoao mau dimensionamento dos recursos, o que compromete aQoS borda-a-borda.

Vi-se, portanto, que essa escalabilidade tem seu preo: nose pode garantir a QoS para todos os fluxos de uma mesmaclasse. O trfego de dados na Internet tem um comporta-mento aleatrio, portanto violaes da QoS so esperadas.Solues como IntServ possibilitam o controle por fluxo dedados, garantindo QoS para cada fluxo individualmente, po-rm apresentam problemas de escalabilidade nos roteadoresde ncleo.

A necessidade de oferecer garantias de QoS na Internet nosleva a mecanismos de provisionamento dinmico. A caracte-rstica aleatria da chegada de fluxos em diferentes classes deservio obriga a utilizao de alguma tcnica de reconfigura-o dinmica dos mecanismos de provisionamento. Em vir-tude da complexidade desses mecanismos,a maioria das em-presas de telecomunicaes tem preferido super-dimensionaros recursos para obter a QoS desejada. Esse procedimento,no entanto, apresenta um custo muito alto, tanto pela capaci-dade no utilizada na maioria do tempo (deve-se provisionarpelo pico) como pela dificuldade do planejamento, pois a es-timativa de trfego futuro tende a ser imprecisa.

Em trabalhos anteriores, mostramos experincias que de-monstraram que um controlador fuzzy reconfigurando dina-micamente os ns conforme o trfego entrante pode melho-rar a QoS em um domnio. Esse controlador mostrou-se efi-ciente para melhorar a qualidade de servio em um dom-nio DiffServ simples[2] e em um domnio complexo comvrias topologias aleatrias de 40 ns[3]. A utilizao docontrolador fuzzy justifica-se pela no linearidade e ausn-cia de um modelo matemtico preciso para tratar estimativade trfego[4]. Comparado a um controlador convencional, ocontrolador fuzzy apresenta vantagens significativas no tra-tamento de variveis imprecisas. Para melhorar a eficinciado controlador fuzzy, foram utilizadas tcnicas baseadas emalgoritmos genticos (AG), que otimizam os parmetros docontrolador fuzzy[5, 6].

O Gerenciamento Baseado em Polticas[7] tem se mostra-do uma tcnica eficaz para coordenar a configurao de umarede para obter a QoS desejada. A maioria dos trabalhos so-bre Gerenciamento Baseado em Polticas foca na especifica-o de polticas e do modelo de informaes das entidadesonde as polticas sero aplicadas. Entretanto, pouco trabalhotem sido feito sobre como as entidades interpretam as polti-cas e definem comandos de configurao nos equipamentosreais[8, 9]. Alm disso, ainda falta estudo sobre aplicao

1

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

de polticas em grandes domnios, onde interpretaes dife-rentes de uma mesma poltica podem causar instabilidades efalhas na operao do sistema[10].

Apresentamos nesse trabalho a arquitetura do sistema degerenciamento baseado em polticas que coordena o provisi-onamento dinmico dos ns de um domnio DiffServ. Apre-sentamos uma proposta de mapeamento de polticas de geren-ciamento em parmetros de controlador fuzzy, que ser utili-zado para reconfigurar o provisionamento de recursos nos nsdo domnio. Mostramos ento, o procedimento de otimizaodo controlador fuzzy para melhorar as mtricas de QoS. Paravalidar a metodologia, foi construdo um controlador fuzzyque implementa as polticas definidas inicialmente. Assim,foi realizada uma simulao desse prottipo, com avaliaode tempo de retardo, variao do retardo e descarte de fluxosde telefonia IP. Posteriormente, apresentamos uma avaliaodo controlador fuzzy mediante a variao de alguns parme-tros.

Esse artigo encontra-se organizado da seguinte forma: aseo2 apresenta a arquitetura do sistema e metodologia pa-ra construo do controlador; a seo3 mostra a metodologiade mapeamento de polticas; a seo4 apresenta a constru-o do controlador fuzzy; a seo5 mostra a otimizao docontrolador fuzzy; a seo6 mostra a implementao do pro-ttipo, seguindo a metodologia proposta; a seo7 apresentaos resultados obtidos na simulao; e, finalmente, a seo8apresenta as concluses do trabalho e sugere temas para tra-balhos futuros.

2. SISTEMA DE PROVISIONAMENTO DI-NMICO DE RECURSOS

Para coordenar a configurao de uma rede com requisi-tos de qualidade, precisamos de um sistema que mantenha oprovisionamento da rede coerente e que, como a arquiteturaDiffServ, tambm seja escalvel. Definiu-se ento um contro-lador que implementa o provisionamento dinmico nos nsa partir das polticas especificadas pelo operador de redes.Abaixo, apresentamos a arquitetura do sistema e a metodolo-gia para a construo desse controlador.

2.1 ARQUITETURA DO SISTEMA DE PROVI-SIONAMENTO DINMICO

A arquitetura do sistema de provisionamento dinmico temcomo objetivo propiciar o melhor desempenho mantendo aescalabilidade do sistema. Apresentamos, na figura1, a ar-quitetura proposta.

Em cada n do domnio, seja de borda ou de ncleo, ocontrolador do n realiza medidas do estado atual, calculao novo valor de configurao, utilizando um mecanismo delgica fuzzy, e aplica o comando de controle no n. Comoa lgica fuzzy relativamente leve comparada ao AG, podeser executada em cada n do domnio sem interferir muitono desempenho do roteador. O intervalo de operao dessecontrolador da ordem de segundos e usar um mecanismocomputacionalmente pesado pode impactar no desempenho

Ncleo

BordaBorda

GerenciadorOtimizao AGAnalisa medidasConfigura ns

Controlador FuzzyColeta medidas

Controlador FuzzyColeta medidas

Controlador FuzzyColeta medidas

Configura

Monitora

Fluxo de dados

Figura 1. Arquitetura do sistema proposto.

do roteador. O n tambm responsvel por coletar as infor-maes do estado do equipamento e inform-las ao Gerenci-ador, utilizando um protocolo de gerenciamento de redes, porexemplo o SNMP (Simple Network Management Protocol).

Algumas decises exigem o conhecimento de um conjun-to de ns (domnio), quando ento o gerenciador de polticasrealiza o clculo e reconfigura todos os ns necessrios. Umexemplo dessa situao quando o retardo na classe maisprioritria no interior do ncleo aumenta e no existem maisrecursos para alocar, obrigando a uma reduo na taxa de en-trada para no haver descarte no ncleo.

O gerenciador, nico no domnio, responsvel por con-solidar todas as informaes colhidas pelos ns que sejamimportantes para funcionamento do domnio. Realiza tam-bm a otimizao com algoritmo gentico e reconfigura to-dos os ns regularmente, utilizando o protocolo COPS (Com-mon Open Policy Service), por exemplo. Como o algoritmogentico exige uma quantidade maior de recursos computa-cionais, poderia interferir no desempenho dos roteadores, sefosse executado neles. Outra observao importante que aotimizao com algoritmo gentico ocorre a intervalos maio-res, da ordem de horas ou dias, portanto a escalabilidade podeser mantida mesmo para grandes domnios.

2.2 METODOLOGIA PARA CONSTRUO DOCONTROLADOR DE PROVISIONAMENTO

A metodologia consiste na realizao de definio, otimi-zao e teste, efetuadas continuamente para manter o siste-ma ajustado topologia usada. Apresentamos, na figura2,o fluxograma da metodologia proposta. Nessa figura, os re-tngulos representam um procedimento da metodologia e osparalelogramos representam as interaes com os usurios dosistema ou com os equipamentos de rede. Vamos supor queos operadores de rede de telecomunicaes devem cumprirmtricas de QoS especificadas em contrato, por exemplo, queo retardo mximo da rede seja de 100 ms.

O ponto de partida do presente trabalho so as especifi-caes de polticas administrativas com base nos requisitosde QoS, conforme mostrado na figura2(a). O detalhamentodessa fase apresentado na seo3.2. A etapa seguinte, fi-gura2(b), mostra a definio do controlador a partir dessaspolticas administrativas, por isso apresentada uma propos-ta de mapeamento de polticas em parmetros do controlador

2

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

Especificao daPoltica

AtendePoltica ?

Incio

Construo doControlador

Fuzzy

Otimizao comAlgoritmoGentico

Mapeamento daPoltica emLgica Fuzzy

Medio do Resultado(Simulao)

Seleo dosValores paraOtimizao

ConfiguraControlador

Fuzzy

(a)(b)

(c)(d)

(e) (f)

(g) (h)

SIMNO

Figura 2. Fluxograma da metodologia proposta.

fuzzy, na seo3.3.A prxima etapa a construo do controlador fuzzy, mos-

trado na figura2(c). Essa etapa, apresentada na seo4, defi-ne os parmetros do controlador fuzzy, como funes de per-tinncia e base de regras, a partir da especificao de polticamapeada na etapa anterior. Uma vez construdo o controla-dor, podemos aplic-lo aos equipamentos da rede ou, comoem nosso experimento, realizar a simulao. Nessa etapa,mostrada na figura2(d), pode-se coletar os valores de entra-da e sada no controlador fuzzy e as medidas de desempenhodesejadas como, por exemplo, retardo e descarte de pacotes.

De posse desses valores, podemos escolher todas as combi-naes de valores de entrada e sada que maximizam as me-didas de desempenho desejadas. Essa etapa mostrada nafigura2(e) e detalhada na seo5.2. A etapa seguinte consis-te na otimizao dos parmetros fuzzy atravs do algoritmogentico, utilizando como referncia de funo objetivo osvalores selecionados no tem anterior. Essa etapa mostradana figura2(f) e detalhada na seo5.3.

A otimizao por algoritmo gentico pode distorcer as fun-es de pertinncia e regras do controlador, fazendo com queo resultado do controlador deixe de cumprir as polticas origi-nais. Na etapa2(g), as novas funes de pertinncia e regrasso avaliadas com a especificao das polticas; caso este-jam em desacordo, o controlador fuzzy precisa ser redefinidona etapa2(c), mostrada com uma linha tracejada. Caso ocontrolador produza um resultado coerente com as polticasoriginais, pode ento ser usado nos equipamentos para funci-onamento normal, conforme indicado na etapa2(h).

A metodologia admite que o processo de otimizao sejarealizado continuamente, adaptando os controladores fuzzyde acordo com as mudanas ocorridas na rede (ativao oudesativao de um canal, alterao no padro de trfego gera-do pelos usurios etc.). Como normalmente essas mudanasso pequenas e eventuais, o algoritmo gentico muito efici-

ente na otimizao. O processo de adaptao mostrado nafigura2, com uma linha cheia, considerando que as polticasadministrativas se mantenham inalteradas. Caso contrrio,deve-se iniciar a metodologia a partir da etapa inicial (figura2(a)).

3. IMPLEMENTAO DE POLTICAS DEGERENCIAMENTO

O Gerenciamento Baseado em Polticas[7] tem se mostra-do uma tcnica eficaz para coordenar a configurao de umarede para obter a QoS desejada. Podemos definir umapol-tica como umaregra que direciona as opes de comporta-mento de um sistema de gerenciamento. Para representar aspolticas, utilizamos a linguagem Ponder[11], apresentada aseguir.

3.1 LINGUAGEM DE ESPECIFICAO DEPOLTICAS: PONDER

A linguagemPonderfoi proposta por Damianouet al.[12]para especificar textualmente polticas de gerenciamento, deacordo com as propostas de Sloman [7] e Lupu[13, 10]. uma linguagem declarativa orientada a objetos e oferece aousurio uma interface simples para especificao de polti-cas, aproximando-se o mximo possvel de regras de polti-cas abstratas. A linguagem Ponder foi escolhida para essetrabalho pois atendeu s necessidades requeridas e as ferra-mentas de auxlio se mostraram eficientes para implementaro prottipo.

Essa linguagem define quatro polticas bsicas:polticade autorizao, que pode ser positiva (auth+), permitindo oacesso a um determinado recurso, ou negativa(auth-), proi-bindo o acesso;poltica de obrigao(oblig), que exige aexecuo de determinada ao (previamente autorizada);po-ltica de proibio(refrain ), que probe a execuo de umaao; epoltica de delegao(deleg), que permite a um ele-mento delegar a outro o controle sobre determinado objeto.

3.2 ESPECIFICAO DAS POLTICAS DEQOS

A partir dos requisitos administrativos, podemos especifi-car a poltica de gerenciamento. Em nosso exemplo, defini-mos a poltica de que toda prioridade deve ser dada clas-se EF(Expedited Forwarding). A classe de melhor esforo,(BE - Best Effort)dever ter a prioridade reduzida sempreque houver queda na qualidade da classe EF. Foram definidasduas especificaes de poltica: uma para o escalonador, apli-cvel em todos os ns, e uma para o condicionador, aplicvelapenas aos ns de borda.

O cdigo1 mostra um trecho da especificao da polticado escalonador emPonder. As linhas 4 a 8 definem os valo-res mximos dos parmetros de QoS para uma determinadaclasse de servio (EF). Podemos ver que o escalonador podevariar de 10% a 90% da banda de sada e o retardo mximo

3

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

de 100 ms. Da linha 10 14, so estabelecidas as restriesbaseadas nos valores previamente definidos. Nas linhas 16 a19, so definidos os eventos de disparo das aes.

Cdigo 1. Exemplo de especificao Ponder do escalonador

/ / E s p e c i f i c a c a o do Con t ro lado r do Esca lonador2 / // / De f i ne l i m i t e s minimos e maximos p e r m i t i d o s

para o esca lonado r4cons t

minsched = 0 . 1 0 ; / / Esca lonador minimo 10%6 maxsched = 0 . 9 0 ; / / Esca lonador maximo 90%

MaxDelay = 1 0 0 ; / / Delay maximo 1 0 0 ms8

/ / De f i ne c o n d i c o e s de r e s t r i c a o10c o n s t r a i n t

bwMin = bwShare < minsched ;12 bwMax = bwShare > maxsched ;

bwInc rease = bwShare < maxsched ;14 bwDecrease = bwShare > minsched ;

16event / / D e f i n i c a o dos e v e n t o sl owde lay = 0 . 3 MaxDelay

18 mediumdelay = 0 . 5 MaxDelayh i g h d e l a y = 0 . 7 MaxDelay

20

/ / A u t o r i z a aumentar esca lonado r se menor quemaxsched

22 auth + i n c r e a s e S c h e d u l e r A u t h {s u b j e c t s ;

24 t a r g e t t ;a c t i o n increaseBW ( ) ;

26 when bwInc rease ;}

28 / / Obr iga aumentar 1 un idade esca lonado rquando r e t a r d o do EF e medio

o b l i g i n c r e a s e S c h e d u l e r 1 {30 s u b j e c t s ;

t a r g e t t ;32 on EF . mediumdelay ;

do increaseBW ( l e v e l ) ;34 }

A partir desse ponto, as polticas sero executadas pelo su-jeito se aplicadas ao alvot. Nas linhas 22 a 27, especificadauma poltica autorizando o controlador a executar o aumen-to da banda (increaseBW()), quando a condio particiona-mento da banda atual (bwIncrease) for menor que o mximopermitido (maxsched). Nas linhas 29 a 34, definida umapoltica determinando que a ao de aumentar a banda (in-creaseBW()), previamente autorizada, seja executada quandoo evento retardo na classe EF for mdio.

3.3 MAPEAMENTO DE ESPECIFICAO DEPOLTICAS EM PARMETROS DE CON-TROLADOR FUZZY

A especificao de polticas traduz uma deciso adminis-trativa em comando do sistema de gerenciamento. Por seremas regras de polticas abstratas e prximas da percepo hu-mana, muito difcil mape-las em regras computacionais,absolutas e exatas por natureza. A lgica fuzzy tem a ca-racterstica de tratar variveis semnticas com certo grau deimpreciso. Por isso, praticamente intuitiva a aproximaodas regras de especificao de polticas de gerenciamento dosatributos de um controlador fuzzy.

A linguagemPonderpermite especificar vrios elementosde polticas de gerenciamento de forma textual. As funesrestrio e evento podem ser representadas por funes depertinncia, enquanto as funes de comando podem ser re-presentadas pela base de regras.

3.3.1 REPRESENTAO DO COMANDO CONS-TRAINT E AUTH

Os comandosconstraint eauth- indicam o limite de restri-o de uma autorizao, geralmente definindo um valor mni-mo ou mximo para certa funo. A associao em operaofuzzy consiste em estabelecer o valor defuzificado da varivelde sada igual ao valor desejado.

Cdigo 2. Mapeamento do comando constraint

c o n s t r a i n t2 bwmin = bwShare < = 0 . 1 0 ;i n s t

4 auth schedu le rM in {s u b j e c t s ;

6 t a r g e t sched ;a c t i o n sched . reduceBW ( ) ;

8 when bwMin ;}

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

PMPB PA

Valor do escalonador (sada)

Figura 3. Funo pertinncia associada comando constraint

Apresentamos, no cdigo2, uma especificao usando oscomandosconstraint eauth-. Nesse caso, a restrio da ban-da mnima do escalonador seja 0.10 (ou seja, 10% da bandatotal). O menor valor atingido por uma funo de pertinncia o centro de gravidade (caso este seja o mtodo de defuzi-ficao utilizado) do menor valor semntico da funo. Ocomandoauth- indica a no autorizao de executar o co-mando de reduzir a banda do escalonador, caso a banda atualseja menor ou igual ao valor mnimo.

A funo de pertinncia do controlador fuzzy correspon-dente a essa especificao mostrada na figura3, onde as va-riveis "PB", "PM" e "PA" significam Prioridade Baixa, Pri-oridade Mdia e Prioridade Alta, respectivamente. Podemosobservar que o centro de gravidade do polgono do valor se-mntico "PB" 0.1. Assim, quando o resultado semntico forapenas "PB" (que o pior caso) o valor defuzificado ser 0.1.Poderamos fazer um mapeamento semelhante para a funo

4

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

peso mximo, que associaria o valor semntico "PA" com ovalor defuzificado 0.9.

3.3.2 REPRESENTAO DO COMANDO EVENT

O comandoevent lista os eventos que disparam comandosde obrigao (oblig) ou proibio (refrain ). Uma ao podeter vrios eventos possveis, conforme a poltica desejada. Omapeamento desse comando uma funo de pertinncia deuma varivel com seus valores semnticos. Assim, o coman-doeventexprime a descrio de uma funo de pertinncia.

Apresentamos, no cdigo3, uma especificao usando umcomandoevent e oblig. Atribumos aos eventos RB, RM eRA, respectivamente, Retardo Baixo, Retardo Mdio e Retar-do Alto, um valor de disparo. Esses eventos sero utilizadosno comandooblig como condio de disparo, na linha 10, eda aosched.increaseBW, na linha 11.

Cdigo 3. Mapeamento do comando event

event2 RB = 0 . 1 ; / / Re ta rdo Baixo

RM = 0 . 5 ; / / Re ta rdo Mdio4 RA = 0 . 9 ; / / Re ta rdo A l t o

6 i n s to b l i g aumentaEsca lonador {

8 s u b j e c t s ;t a r g e t sched ;

10 on c l ass eEF .RA ;do sched . increaseBW ( )

12 }

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

RMRB RA

Retardo na classe EF (entrada)

Figura 4. Funo de pertinncia associada ao comando event

A funo de pertinncia correspondente a essa especifica-o mostrada na figura4. Podemos definir que cada eventoser associado a um valor semntico da funo de pertinn-cia. Podemos notar que a especificaoPonderatribui umvalor absoluto, sendo o critrio de disparo atender ou no aesse valor. Para ser possvel o mapeamento, consideramos ovalor absoluto como o valor central dos valores semnticos earbitramos a forma geomtrica. O valor exato e o formato dopolgono dessas variveis no so importantes, pois poderoser alterados no processo de otimizao.

3.3.3 REPRESENTAO DO COMANDO OBLIG

O comandooblig indica a obrigao de execuo de umaao caso uma determinada condio seja atendida (evento).O mapeamento, portanto, quase que imediato. O parmetroon do comandooblig mapeado na condio do comandoifda base de regras, e o parmetrodo mapeado na ao docomandothen.

Apresentamos, no cdigo4, uma especificao usando ocomandooblig. Consideramos as mesmas funo de per-tinncia apresentada na figuras4. Nesse comando, casoocorra o evento retardo mdio na classe EF (classeEF.RM), disparada a ao de aumentar a banda do escalonador(sched.increaseBW()).

Cdigo 4. Mapeamento do comandooblig

i n s t2 o b l i g aumentaEsca lonador {

s u b j e c t s ;4 t a r g e t sched ;

on c l ass eEF .RM ;6 do sched . increaseBW ( )

}

O cdigo5 apresenta uma descrio JFS[14] da base deregras do controlador fuzzy, a partir da especificao de po-ltica apresentada no cdigo4. Podemos observar que o ma-peamento de um comando increaseBW() foi desdobrado emvrias regrasif then para abranger to-dos os valores semnticos da funo de pertinncia. A partirda aoincreaseBW()em Ponder, definimos trs comandosJFS, por ser exigida a especificao de ao para cada valorsemntico de entrada.

Cdigo 5. Cdigo JFS mapeado a partir com comandooblig

program2 i f c l ass eEF RMand sched PB then sched PM ;

i f c l ass eEF RMand sched PM then sched PA ;4 i f c l ass eEF RMand sched PA then sched PA ;

4. CONSTRUO DO CONTROLADORFUZZY

A lgica fuzzy foi introduzida por Lofti Zedeh[15], comouma generalizao da teoria clssica. A extenso sugeridapor Zadeh est na possibilidade de um determinado elementopoder pertencer a um conjunto com um valor chamado graude pertinncia. Assim, um elemento no simplesmente per-tence ou no pertence a um conjunto, como na lgica clssica,mas poder pertencer a um conjunto com grau de pertinnciaque varia no intervalo [0,1], onde o valor 0 indica uma com-pleta excluso, e o valor 1 representa completa incluso.

A lgica fuzzy utiliza variveis lingsticas no lugar de va-riveis numricas. Variveis lingsticas admitem como va-lores apenas expresses lingsticas, como "muito grande","pouco frio", "mais ou menos jovem", que so representadaspor conjuntos fuzzy. A teoria da construo de um contro-lador fuzzy foi mostrada em Lee[4]. A construo de umsistema de controle fuzzy baseada na idia de se incorporar

5

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

"experincia" ou "conhecimento especializado" de um ope-rador humano para se obter a melhor estratgia de controle.Desse modo, a forma das regras empregadas depende do pro-cesso a ser controlado.

Os controladores fuzzy so a mais importante aplicaoda Teoria Fuzzy. Seu funcionamento diferente dos contro-ladores convencionais, pois estes exigem o desenvolvimen-to das equaes diferenciais que descrevem o sistema. Emum controlador fuzzy, o conhecimento pode ser expresso deforma intuitiva, usando as variveis lingsticas. As aplica-es ideais para utilizao de Controladores Fuzzy so asseguintes[16]:

1. Processos muito complexos, onde no h modelo mate-mtico claro;

2. Processos altamente no lineares ou com comportamen-to probabilstico;

3. Aquelas em que o processamento de conhecimento es-pecializado (formulados lingisticamente) o nicopossvel.

Esses argumentos justificam a escolha do controladorfuzzy para nossa proposta. Apresentamos, a seguir, o con-trolador fuzzy apropriado para controlar o provisionamentodinmico em arquitetura DiffServ obtendo como resultadouma melhor qualidade de servio. A metodologia utilizadapara construo do controlador fuzzy foi baseada na metodo-logia proposta por Cordn e Herrera[17].

4.1 FUNES DE PERTINNCIA

O controlador proposto utiliza variveis lingsticas trian-gulares e trapezoidais, pela possibilidade de serem imple-mentadas com cdigo mais simples e eficiente. Realizamostambm experincia com uma funo gaussiana, porm os re-sultados obtidos no justificaram a complexidade adicionada.

A arquitetura de nosso controlador foi dividida em duaspartes: um controlador do escalonador existente em todos osns do domnio e um controlador do condicionador existenteapenas nos ns de borda.

4.1.1 CONTROLADOR DO ESCALONADOR

A varivel de sada, que possibilita o controle do escalo-nador, depende do tipo do mecanismo utilizado. O escalo-nador controlvel deve ser do tipo WRR (Weighted Round-Robin) ou WFQ (Weighted Fair-Queueing), em que as filasso servidas de acordo com o peso definido na configurao.Alterando-se esse peso, podemos modificar o retardo dos pa-cotes em cada fila (classe).

A primeira varivel de entrada o retardo instantneo dopacote na fila EF. Como os demais tempos do processamen-to do pacote so praticamente irrelevantes, consideramos otempo de espera na fila como o tempo total de permannciano n. Da mesma forma que o tempo de espera do pacote,varivel equivalente seria o tamanho da fila, pois direta-mente proporcional ao retardo esperado. A segunda varivel

de entrada a taxa de descarte por transbordamento da filaBE, indicando a exausto do recurso. Vrios mecanismos degerenciamento ativo de fila podem ser utilizados neste caso,porm devemos considerar que, na ocorrncia de descarte, hescassez de recurso de rede. As variveis semnticas so:

Entrada:

Peso relativo atual do escalonador (EF/BE).

Retardo instantneo na classe EF.

Perda de pacotes na classe BE.

Sada:

Peso relativo no escalonador da fila EF/BE.

4.1.2 CONTROLADOR DO CONDICIONADOR

O condicionador est presente apenas nos ns de borda dodomnio DiffServ. O objetivo principal deste controlador policiar a entrada de fluxos de dados no domnio, de manei-ra que os fluxos bem comportados no sejam penalizados. Avarivel de controle depende do tipo de condicionador utili-zado. De forma geral, seguem a filosofia do balde de fichas(Token Bucket), que um repositrio onde se colocam fichasa uma taxa constante.

A primeira varivel o descarte de pacotes da classe EFno condicionador. Quando um pacote chega ao condiciona-dor e encontra o balde vazio, o mesmo descartado, pelo quepodemos concluir que o trfego entrante maior que a ta-xa contratada para sua entrada no domnio. O condicionador,entretanto, no pode ter o valor da taxa de enchimento do bal-de alterada, pois seu objetivo manter um trfego suavizadoe conforme ao contratado, no havendo sentido em aumentarou reduzir sua taxa. Por outro lado, o PHB EF em um do-mnio DiffServ s deve descartar pacotes na borda[18], sen-do indesejveis os descartes no interior do domnio. Quandono h mais recursos no ncleo do domnio, devemos sina-lizar para os ns de borda uma reduo na taxa de entrada,atravs da reduo da taxa de enchimento do balde. Assim,o valor de retardo mximo nos ns de ncleo enviado aogerenciador, que sinalizar a reduo da taxa de entrada paraos ns de borda.

A segunda varivel de entrada o retardo mximo da clas-se EF no interior do domnio, que indicar a necessidade dereduzir a taxa de enchimento do balde caso o retardo sejamuito alto.

Esta foi a poltica escolhida para tratar congestionamentono ncleo, entretanto poderamos usar, dependendo das con-venincias do contratante, o critrio de manter a taxa contra-tada e recusar a entrada de novas conexes ou cortar algumasconexes (atuando no marcador). As variveis semnticasso:

Entrada:

Taxa atual do Token Bucket do condicionador.

Perda de pacotes na classe EF no condicionador.

Retardo mximo na classe EF nos ns de ncleo.6

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

Sada:

Taxa do Token Bucket do condicionador.

4.2 BASE DE REGRAS

A base de regras o conjunto de regras SE-ENTO dosvalores lingsticos, que representam o comportamento dese-jado do sistema fuzzy. Conforme dito anteriormente, a basede regras deve ser definida de acordo com a poltica admi-nistrativa. Para nosso exemplo, utilizamos um conjunto deregras priorizando a classe EF em qualquer situao e dei-xando para a classe BE um mnimo de 10% da banda.

A escolha dos operadores fuzzy seguiram as recomenda-es e metodologia de Cordn e Herrera[19], conforme o tipode aplicao utilizada em nosso estudo. Os operadores sele-cionados forammximo para unio e interseo (envoltriaexterna de todas as variveis semnticas vlidas), enquanto aimplicao utilizada foi do tipomnimo, a disjuno (OU) dotipo mximo e conjuno (E), do tipomnimo.

O valor de resposta semntico no tem valor prtico, porisso deve ser convertido em um valor discreto (numrico),que ser aplicado ao atuador do controlador. Esse processo chamado de defuzificao. O mtodo mais usual para aplica-o em controladores o do centro de gravidade que consisteem calcular o centro de gravidade da figura obtida atravs dacombinao das funes de pertinncia.

5. OTIMIZAO DO CONTROLADORFUZZY

Com o objetivo de especificar um controlador eficiente,utilizamos algumas ferramentas de otimizao. Na criaode regras, usamos o algoritmo Wang-Mendel[20], que, a par-tir do comportamento desejado, cria um conjunto de regrascoerentes. Para a otimizao dos parmetros das funes depertinncia, usamos um algoritmo gentico que descobre amelhor combinao de parmetros para obter o resultado ide-al.

5.1 VERIFICAO DE REGRAS ATRAVS DOALGORITMO DE WANG-MENDEL

A lgica fuzzy apresenta a vantagem de permitir a repre-sentao de conceitos ambguos e produzir uma resposta efi-caz mesmo com entradas duvidosas. Porm, um comporta-mento eficiente requer a definio de regras coerentes. Paraque isso no dependa inteiramente do trabalho do projetistado sistema, desejvel a introduo de uma metodologia paraproduzir funes de pertinncia e regras coerentes e eficien-tes. Utilizamos o algoritmo Wang-Mendel[20], que, a partirdo comportamento desejado, cria um conjunto de regras coe-rentes. Seu funcionamento bsico apresentado no algoritmo1 seguindo a implementao apresentada por Cox[16].

A maior utilidade dessa metodologia verificar a consis-tncia do conjunto de regras criadas pelo especialista identi-

Algoritmo 1 Algoritmo Wang-MendelEntrada: Base de regras nao verificadacontador(i) 0 {Inicia contador de posto}contradicao(i) 0 {Marca todas as regras no contradi-trias}Normaliza as regras nao verificadas na forma IF IS AND IS AND. . . THEN IS .enquantoExiste regra a ser verificadafaa

seRegra j existe na base de regrasentoRegra no incluida econtador(i) incrementado

seno seRegra ainda no existe e no contradiz nenhu-ma outra regraento

Regra adicionada base de regras econtador(i) incrementado

seno seRegra contradiz alguma regra existenteentoRegra includa na tabela de regras e marcacontradicao(i) = 1 e contador(i) incrementado.

fim sefim enquantoRegras comcontradicao(i) = 0 sao includas na base deregras final.Regras comcontradicao(i) = 1 inclue a regra comcontador(i) maior e descarta a outra.

ficando a ocorrncia de regras contraditrias, que levariam aresultados errneos.

5.2 SELEO DOS VALORES PARA OTIMI-ZAO DO CONTROLADOR FUZZY

O processo de otimizao por AG necessita de uma fun-o objetivo, para onde a otimizao deve convergir. A gran-de dificuldade, no entanto, definir essa funo objetivo[5].No caso do controlador do escalonador, temos como entradaas variveis peso inicial do escalonador, retardo na fila EF edescarte na fila BE e, como sada, o peso do escalonador. Noentanto, a varivel a ser otimizada o retardo da fila EF, quesomente pode ser avaliada em simulao.

Em vista disso, definimos uma metodologia para obter osvalores utilizados na otimizao. Durante a simulao com asfunes de pertinncia arbitradas pelo projetista, armazena-mos todas as combinaes de parmetros de entrada do con-trolador fuzzy e as mtricas de avaliao como, por exemplo,o valor de retardo obtido no perodo seguinte e a taxa de des-carte de cada classe, ou seja, o resultado obtido pela aplicaode parmetros na simulao.

De posse desses valores, escolhemos todas as combinaesde parmetros que produzem um retardo baixo, aquelas queproduzem uma maior reduo no retardo dos pacotes em me-didas consecutivas e aquelas que produzem uma menor taxade descarte agregado (EF + BE). Foi necessrio estabelecerum critrio para a ordenao das medidas, pois elas so inde-pendentes e algumas at contraditrias, como baixo retardo ebaixo descarte. Ordenamos as medidas individualmente porordem crescente, para a primeira e terceira mtrica, e decres-cente, para a segunda mtrica. Calculamos um valor de posto

7

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

igual a mdia da posio de cada parmetro, isto , menorretardo absoluto, maior reduo no retardo e menor descar-te. Como as duas primeiras medidas esto relacionadas aoretardo, podemos dizer que a otimizao utilizou uma ponde-rao de 66% para retardo e 33% para descarte. Assim, esco-lhemos as melhores combinaes de parmetros para nossoproblema, segundo a ponderao escolhida.

5.3 OTIMIZAO DE CONTROLADOR FUZZYATRAVS DE ALGORITMO GENTICO

O controlador definido com funes de pertinncia arbi-tradas pelo projetista e com a base de regras verificado peloalgoritmo de Wang-Mendel, mostrado na seo5.1, garantea definio de um controlador correto, porm ainda sem ga-rantia de eficincia. Para otimizar o resultado do controlador,precisamos escolher os melhores parmetros do controladoratravs da utilizao do algoritmo gentico.

5.4 FUNCIONAMENTO DOS ALGORITMOSGENTICOS

O algoritmo gentico cria inicialmente um conjunto de so-lues, a partir dos valores arbitrados inicialmente (indivdu-os), para um determinado problema. Esse conjunto chama-do de populao. O posto de cada indivduo calculado peloteste da soluo em relao ao valor desejado. Os indivduoscom posto baixo so substitudos por novos indivduos cria-dos a partir de indivduos com posto alto. Esse processo con-tinua at uma soluo ser encontrada ou alguma condio detrmino seja alcanada (por exemplo, nmero de geraes).O indivduo com maior posto a soluo encontrada para oproblema.

A partir da tabela com valores de entrada e sada desejados,escolhidos na seo5.2, o algoritmo gentico cria um indiv-duo, verifica se o resultado calculado se aproxima do valordesejado e pontua cada avaliao. A cada gerao,os indiv-duos mais aptos so selecionados e combinados (atravs decrossover), obtendo-se um conjunto de parmetros otimizadopara a tabela de valores desejados. Eventualmente, os par-metros podem convergir para um bom valor local, mas queno o melhor para o universo. Para evitar isso, aplica-se oprocesso demutao, incluindo no conjunto de avaliao umvalor aleatrio totalmente novo, que pode indicar uma novaregio de otimizao.

Aps uma srie de iteraes, obtemos um conjunto de pa-rmetros otimizado para o controlador. A grande vantagemdesse procedimento a otimizao automtica dos parme-tros das funes de pertinncia, sem depender do critrio doprojetista. No mtodosimples, que tem funcionamento inter-medirio aos mtodosgeracionaleem regime, a avaliao depais e filhos so realizadas em paralelo, possibilitando umamelhor escolha de indivduos. Assim, obtemos uma conver-gncia rpida para o caso da soluo estar prxima ou distan-te do ponto de partida.

A vantagem da utilizao de algoritmo gentico para oti-mizao sua caracterstica de poder ser executado continu-

amente, a partir de medidas de desempenho da rede duranteo funcionamento normal. Esse procedimento permite o ajus-te dos parmetros quando ocorrem modificaes na topologiaou no padro de trfego, durante a operao da rede. A exe-cuo do algoritmo gentico, no entanto, no provoca quedano desempenho da rede, pois a otimizao pode ser realizadaem equipamentos dedicados (os roteadores da rede somenteexecutam o controlador fuzzy). Alm disso, a otimizao noprecisa ocorrer em perodos muito curtos, pois as mudanasque poderiam causar alteraes ocorrem na ordem de dias ousemanas.

A codificao do cromossomo usado foi nmero real comquatro casas decimais, o mecanismo de funcionamento foi omtodo simples, o mtodo de seleo foi da roleta e o cru-zamento foi do tipo multi-ponto. Os mecanismos utilizadosnesse trabalho foram detalhados por Michaelewicz[21].

5.5 PARMETROS DE CONFIGURAO DOALGORITMO GENTICO

A configurao correta dos parmetros do algoritmo ge-ntico , sem dvida, um dos aspectos mais importantes naestratgia dos AGs. No existe uma metodologia genrica,uma vez que tais configuraes dependem da aplicao a serotimizada. importante tambm levar em considerao ostempos de execuo do problema e os recursos computacio-nais disponveis.

Os parmetros do algoritmo gentico utilizado na otimi-zao do controlador fuzzy esto relacionados na tabela1.Foram usados valores dentro das faixas usuais,conforme co-mentados em seguida, porm com os ajustes para melhoriada eficincia.

Tabela 1. Parmetros do algoritmo gentico utilizados.Parmetro Valor

Tamanho da populao 500Taxa de cruzamento 65%

Taxa de mutao 5%Critrio de parada 90% da populao igual

Nmero de geraes 600

Apresentamos a seguir os parmetros mais importantes esua influncia no desempenho do algoritmo.

5.5.1 TAMANHO DA POPULAO

O tamanho da populaoN afeta o desempenho global ea eficincia dos algoritmos genticos, j que uma populaopequena fornece uma cobertura pequena do espao de busca-do problema. Uma grande populao fornece uma coberturamaior do espao de busca, alm de prevenir convergnciasprematuras para solues locais. No entanto, para se traba-lhar com grandes populaes, so necessrios maiores recur-sos computacionais e tempos muito longos para resoluo deproblemas simples.

Assim, a escolha correta do tamanho de populao, queproduz respostas corretas e rpidas, depende do problema e

8

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

da sua formulao. Geralmente, usa-se um tamanho de popu-lao proporcional ao tamanho do cromossomo, isto , quan-to maior for o cromossomo maior dever ser o tamanho dapopulao, para manter uma diversidade razovel. A literatu-ra sugere populaes entre 50 e 100 cromossomos como bomcompromisso cobertura-desempenho[22].

O tamanho da populao utilizada foi de 500 indivduos,que possibilitou uma melhor cobertura do espao, mas quese mostrou eficiente em nossa experincia, pela capacidadecomputacional disponvel.

5.5.2 TAXA DE CRUZAMENTO

A taxa de cruzamentoPC define a probabilidade de ocor-rer um cruzamento. Quanto maior for essa taxa, mais rapi-damente novas estruturas sero introduzidas na populao.Porm, estruturas com boas aptides podero ser substitu-das mais rapidamente, perdendo-se boas oportunidades paraachar uma soluo tima. Com um valor baixo, o algoritmopode tornar-se muito lento, demorando a encontrar a soluoideal. A maior parte da literatura recomenda uma taxa decruzamento entre 50% e 95%[22].

A taxa de cruzamento utilizada foi de 65%, valor usual quese mostrou adequado para nossa experincia.

5.5.3 TAXA DE MUTAO

A taxa de mutaoPM define a taxa de ocorrncia de mu-tao. Uma taxa de mutao baixa diminui a incluso de indi-vduos novos na populao, provocando o encontro de resul-tados baseados em mximos locais, pois restringe o espao debusca. Uma taxa muito alta transforma a busca do algoritmogentico em busca essencialmente aleatria.

Alguns pesquisadores recomendam a escolha da taxa demutao com base no tamanho do cromossomo e da popula-o. De Jong [23] sugere uma taxa de mutao inversamenteproporcional ao tamanho da populao. A maior parte da li-teratura recomenda uma taxa de mutao entre 0,1% e 5%[22].

Utilizamos um valor de taxa de mutao alta (5%), pormdentro da faixa recomendada. Esse valor se justifica pelo fatode usarmos o mtodo de seleo da roleta, que pode produ-zir uma baixa diversidade na populao e no atingir o valormximo global da funo.

5.5.4 NMERO DE GERAES

O nmero de geraes define a quantidade de populaescriadas at a resposta final. Com um valor baixo, podemosencontrar rapidamente uma soluo tima local, porm aindalonge da soluo global. Com um valor alto, temos garantiade encontrar a soluo tima,porm o tempo para chegarmos resposta pode ser longo, alm de, no caso de problemassimples, criarmos novas geraes desnecessariamente, mes-mo aps a soluo tima ter sido encontrada. O valor idealpara este parmetro depende do problema e da sua formula-o. Em nossa experincia, estabelecemos um limite relativo

vlido para qualquer problema: encerramos o processamentodo AG quando 90% da populao for constituda de apenasum indivduo, que a soluo desejada.

O programa JFS[14] oferece apenas duas formas de encer-rar o processamento: pelo tempo decorrido ou pela quanti-dade de geraes. No entanto, para podermos garantir queencontraramos o valor de timo global, estabelecemos que apopulao contivesse pelo menos 90% de um mesmo indiv-duo. Assim fomos obrigados a executar uma grande quanti-dade de geraes e testar se o critrio de fim tinha sido atingi-do. Em todas as otimizaes realizadas, a quantidade de 600geraes foi suficiente para atingir essa meta.

6. IMPLEMENTAO DO PROTTIPO

A partir da metodologia para construir o controlador deprovisionamento apresentada na seo anterior, podemosdescrever, nesta seo, o ambiente de simulao e a imple-mentao do mecanismo de controle para nosso prottipo. Oobjetivo validar a metodologia proposta, para definio deum controlador que implemente uma especificao de polti-cas.

Os experimentos consistiram em realizar diversas simula-es avaliando a QoS dos fluxos de telefonia IP concorrendocom outros fluxos no prioritrios. Comparamos os resulta-dos sem a utilizao de controlador, utilizando um controla-dor convencional e o controlador proposto.

6.1 AMBIENTE DE SIMULAO

A metodologia utilizada para validao do modelo propos-to foi a de simulao, com a plataforma do Network Simu-lator (ns), verso 2.1b8[24]. A ferramenta para especificaoe verificao de polticas foi aPonder Toolkit[11], constitu-da por um editor de polticas e um compilador da linguagem.Foi utilizada averso 1.0.1 doPonder Policy Editore a verso0.2.1 doPonder Compiler. O controlador fuzzy foi desenvol-vido com a ferramenta JFS, de Mortensen[14]. Essa ferra-menta oferece um ambiente para desenvolvimento do prot-tipo (especificao das funes de pertinncia, regras de in-ferncia e defuzificador), alm de permitir verificao inicialdo modelo especificado. Aps o desenvolvimento do modelo, gerada biblioteca em cdigo C, que implementa o controla-dor, sendo, ento, integrada ao simuladorns.

6.2 OTIMIZAO DO CONTROLADOR FUZZY

O controlador definido com funes de pertinncia arbi-tradas pelo projetista, mostrado na seo4.1, e com a basede regras estabelecido a partir da base de conhecimento se-mntico e atravs do algoritmo de Wang-Mendel, mostradona seo5.1, garante a definio de um controlador corretoporm sem garantia de eficincia. Para otimizar o resultadodo controlador precisamos escolher os melhores parmetrosdo controlador atravs da utilizao do algoritmo gentico,detalhado na seo5.3.

9

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

A grande dificuldade para uso do algoritmo gentico defi-nir a funo objetivo para otimizao. Em nossa experincia,a definio da funo objetivo agravado pelo fato de que ovalor a ser otimizado no obtido diretamente da sada docontrolador. Enquanto o controlador do escalonador forneceo peso de configurao do escalonador, a varivel que deveser otimizada o retardo dos pacotes na classe EF, obtidosapenas aps a simulao.

Sendo assim foi definida uma metodologia para obteros valores da funo objetivo utilizados na otimizao. Apartir de funes de pertinncia arbitradas pelo projetis-ta,executamos uma simulao com esses valores. Os par-metros definidos a priori no so crticos, pois o algoritmogentico converge para resultado timo a partir de qualquerponto de partida. Obviamente a convergncia pode ser maisrpida ou mais lenta de acordo com a escolha dos parmetrosiniciais.

Durante a simulao armazenamos todas as combinaesde valores de entrada do controlador fuzzy e o valor de retar-do obtido no perodo seguinte, isto , o resultado obtido pelaaplicao dos valores de entrada do controlador. De possedesses valores, podemos escolher as combinaes de par-metros que produzem um retardo baixo e aquelas que pro-duzem uma maior reduo no retardo dos pacotes entre duasmedidas consecutivas. Finalmente, escolhemos as melhorescombinaes de valores para nosso problema.

Os valores selecionados so utilizados como base de co-nhecimento para a aplicao do algoritmo gentico, que pro-duzir o melhor conjunto de parmetros do controlador fuzzypara atingir a otimizao desejada. Utilizamos como refe-rncia para escolha os 20% melhores valores de retardo e re-duo do retardo. Fizemos experincia escolhendo tambm10% e 30% dos melhores valores, porm os resultados obti-dos foram semelhantes,mostrando que a quantidade de valo-res escolhida no importante para a otimizao, pelo menospara os percentuais testados.

Apresentamos na figura5 o grfico da evoluo da apti-do mdia e aptido mxima ao longo do tempo. Podemosobservar na figura5(a) que a convergncia do controlador doescalonador bastante rpida, atingindo valores semelhantesaps 150 geraes. Na figura5(b) notamos que a conver-gncia um pouco mais lenta, atingindo valores semelhantesaps 500 geraes.

Aps a realizao do procedimento de otimizao obtive-mos como resultado novas funes de pertinncia para o con-trolador fuzzy. Apresentamos na figura6 a funo de perti-nncia da varivelretardo na classe EF, utilizada pelo con-trolador do escalonador. A figura6(a) mostra a funo depertinncia original, especificada pelo projetista, onde nota-mos uma distribuio equilibrada dos valores semnticos aolongo do intervalo de operao. A figura6(b) mostra a fun-o de pertinncia otimizada, obtida aps a aplicao da oti-mizao atravs de algoritmo gentico. Podemos notar que ovalor semntico "RB" (Retardo Baixo) foi reduzido ao mni-mo possvel e que o valor semntico "RM" (Retardo Mdio)e "RA" (Retardo Alto) sofreram um leve deslocamento paraaproxim-los ao valor "RB". Deslocar todos os valores se-mnticos para a esquerda determina que a base de regra exe-cutar mais cedo aes de aumento da banda de sada do esca-

0.7

0.75

0.8

0.85

0.9

0.95

1

0 100 200 300 400 500 600

Apt

ido

Quantidade de geraes criadas

Evoluo de aptido mxima e mdia do Escalonador

Aptido mximaAptido mdia

(a) Controlador do Escalonador

0

20

40

60

80

100

0 100 200 300 400 500 600

Apt

ido

Quantidade de geraes criadas

Evoluo de aptido mxima e mdia do Condicionador

Aptido mximaAptido mdia

(b) Cntrolador do Condicionador

Figura 5. Evoluo da aptido mxima e mdia

lonador, fazendo que se obtenha um valor de retardo menor,comparando-se com o controlador original no otimizado.

A grande vantagem do algoritmo gentico o processocontnuo de otimizao, utilizando valores de vrias simu-laes ou at mesmo de dados reais de uma rede em funcio-namento. Esse procedimento permite a atualizao contnuados parmetros de acordo com a mudana de topologias epadres de trfego, comuns em uma situao real.

6.3 TOPOLOGIA DE SIMULAO

A topologia utilizada para a simulao, apresentada na fi-gura7. Essa topologia forma um domnio DiffServ com cincons, sendo dois de ncleo e trs de borda. Podemos notar queexistem dois pontos de congestionamento, o primeiro entrens de borda e do ncleo e outro entre dois ns de ncleo.

6.4 MODELO DE TRFEGO DE SIMULAO

A aplicao de Telefonia IP foi implementada com trfegosCBR e On-Off exponencial, sobre protocolo UDP. O trfegoCBR tem comportamento determinstico e exige mais banda

10

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Retardo na classe EF (normalizado)

Retardo na classe EF (entrada)

RB RM RA

(a) Controlador no otimizado

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Retardo na classe EF (normalizado)

Retardo na classe EF (entrada)

RB RM RA

(b) Controlador otimizado

Figura 6. Funo de pertinncia de entrada retardo na classeEF

da rede, enquanto o trfego On-Off com distribuio expo-nencial mais prximo de uma conversao normal. No en-tanto, a taxa mdia das fontes On-Off sensivelmente menorque no caso CBR, por isso adicionamos mais fontes de tr-fego On-Off para se obter o congestionamento desejado. Otrfego de voz foi direcionado para classe EF[18] e o trfegoconcorrente para classe BE. O trfego concorrente foi defi-nido como CBR/UDP para provocar uma concorrncia maissevera com o trfego de voz na classe EF.

A figura 8 mostra a quantidade de fontes de trfego devoz(classe EF), utilizada durante o perodo de teste de 100segundos. A variao de trfego serviu para demonstrar ofuncionamento do controlador nessa situao. Cada fonte devoz CBR foi definida com 64 Kbps, ou seja, um canal de vozPCM. No caso de fonte On-off, utilizamos uma taxa de 64Kbps, com tempo de rajada de 400 ms e tempo de silnciode 600 ms,representando uma taxa mdia de 25,6 Kbps. Otamanho do pacote escolhido foi de 576 bytes, que corres-ponde a 91,7% dos pacotes de um codificador G.711 (PCM)a 64 Kbps[25].

Enquanto o trfego CBR variou de 40 a 120 fontes, o tr-fego On-Off variou de 100 a 300 fontes, exatamente porquea taxa mdia do trfego On-Off aproximadamente 2,5 ve-

FONTE

FONTE

10 MBPS

NCLEO NCLEO BORDA DRENO

10 MBPS10 MBPS

10 MBPS

BORDA

BORDA

BE

BE

EF

EF

BE

BE

EF

EF

Figura 7. Topologia de simulao.

zes menor. Utilizamos 300 fontes BE concorrentes, com taxatambm de 64 Kbps. O tempo de propagao de cada enlacede 10 Mbps de 5 ms. Todas as filas tm o tamanho de 50pacotes, representando um retardo mximo de aproximada-mente 23 ms por n.

6.5 CONTROLADOR CONVENCIONAL

Com o objetivo de validar nossa proposta, e tendo em vistaque os resultados com a utilizao de qualquer controladorseriam melhores que a situao sem controlador, definimos,para comparao, um controlador PD (Proporcional e Deriva-tivo). A idia desse controlador guardar as ltimas trs me-didas de retardo da classe EF, ajustar uma reta a esses pontos.A inclinao dessa reta aplicada ao peso do escalonador,aumentando ou reduzindo conforme a inclinao da reta.

7. RESULTADOS

Nesta seo mostramos as tabela de percentil de retardo,percentil da variao do retardo e taxa de descarte em trssituaes: sem a utilizao de controlador, com controladorconvencional e com o controlador fuzzy. Todas as simula-es iniciam com alocao de 50% da banda de sada paracada classe. Para eliminar medidas com a rede sem trfego,iniciamos as medidas aps 5 segundos do incio da simula-o.

Os resultados apresentados aqui usaram o intervalo de 1s entre as amostragens e, conseqentemente, o intervalo deatuao do controlador. O tamanho do pacote escolhido foide 576 bytes. Apresentamos, nas sees7.1 e 7.2, uma dis-cusso sobre o comportamento dos diversos mecanismos decontrole com a variao do intervalo de operao do contro-lador e do tamanho do pacote.

A primeira medida avaliada o retardo fim-a-fim de paco-tes pertencentes classe EF, desde a fonte at o destino dotrfego, mostrada na tabela2. Essa avaliao apresenta o per-centil 50, 90 e 95 para trfegos CBR e On-Off comparando

11

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

0

20

40

60

80

100

120

140

0 10 20 30 40 50 60 70 80 90 100

Qua

ntid

ade

de fo

ntes

EF

Tempo de simulao (seg)

Quantidade de fontes de trfego CBR na classe EF

(a) Fontes CBR

0

50

100

150

200

250

300

350

0 10 20 30 40 50 60 70 80 90 100

Qua

ntid

ade

de fo

ntes

EF

Tempo de simulao (seg)

Quantidade de fontes de trfego OnOff na classe EF

(b) Fontes On-Off Exponencial

Figura 8. Quantidade de fontes de trfego EF durante a si-mulao

as situaes sem controlador, com controlador convencionale com controlador fuzzy. A tabela3 apresenta os valores depercentil 50, 90 e 95 para medidas de variao de retardo pa-ra trfego CBR e On-Off sem o uso de controlador, usando ocontrolador convencional e o controlador fuzzy.

Tabela 2. Retardo na classe EF (ms)Trfego Mdio Perc 50 Perc 90 Perc 95

CBR S/Ctrl 43.4 43.0 65.8 75.3CBR Conven. 33.6 30.3 58.8 71.3CBR Fuzzy 19.3 17.3 34.9 41.1OO S/Ctrl 17.9 16.6 33.2 36.9OO Conven. 14.9 14.7 27.1 32.3OO Fuzzy 5.6 3.7 11.7 12.4

A tabela4 apresenta a taxa de descarte de pacotes (paco-tes descartados/pacotes transmitidos) para o trfego CBR ea tabela5 mostra a taxa de descarte para o trfego On-Off.Mostramos as taxas de descarte nas classes EF e BE sem ouso de controlador, usando o controlador convencional e ocontrolador fuzzy.

Tabela 3. Variao do retardo na classe EF (ms)Trfego Mdio Perc 50 Perc 90 Perc 95

CBR S/Ctrl 1.7 0.4 0.4 7.3CBR Conven. 1.5 0.4 0.4 6.0CBR Fuzzy 1.0 0.4 0.4 0.4OO S/Ctrl 1.2 0.3 3.6 5.7OO Conven. 1.1 0.2 3.3 4.6OO Fuzzy 0.5 0.1 1.3 1.9

Tabela 4. Taxa de descarte com trfego CBRControlador EF BE

Sem Ctrl 0.0198 0.0766Convencional 0.0125 0.0843Fuzzy 0.0068 0.0795

Tabela 5. Taxa de descarte com trfego On-OffControlador EF BE

Sem Ctrl 0.0379 0.1388Convencional 0.0272 0.1439Fuzzy 0.0027 0.1486

Podemos observar que h uma melhora na QoS e reduono descarte da classe EF como controlador fuzzy comparados situaes sem controlador e com controlador convencio-nal. Obviamente, quando se reduz a taxa de descarte da clas-se EF, provocamos um aumento na taxa da classe BE, poisa rede est com sua capacidade esgotada. No entanto, pode-mos observar que o uso do controlador fuzzy diminui a taxade descarte agregada, isto , a soma das taxas das classes EFe BE menor que as demais taxas agregadas, produzindo ummelhor desempenho global.

7.1 AVALIAO DO INTERVALO DE OPERA-O DO CONTROLADOR

O primeiro parmetro avaliado foi o intervalo de operaodo controlador que mostrado na figura9. A figura9(a) mos-tra a avaliao do retardo na classe EF para trfego CBR e afigura 9(b) mostra o retardo para trfego On-Off. Medimoso resultado de percentil 90 do retardo variando o intervalo deoperao do controlador em 0,1 s, 0,5 s, 1 s, 2 s, 5 s e 10s. Utilizamos o tamanho de pacote 576 bytes. Para efeito decomparao, indicamos com uma linha contnua o percentil90 do retardo da situao sem controlador.

Podemos observar que a resposta do controlador fuzzy melhor para qualquer intervalo de operao, sendo pratica-mente constante para intervalos at 2 segundos e aproxima-damente linear para intervalos a partir de 5 s. Esse comporta-mento justificado pela variao do perfil do trfego a cada10 segundos (vide figura8). Somente a partir desse intervalo(10 s), podemos notar uma degradao na resposta do contro-lador fuzzy.

Podemos tambm notar que a diferena do retardo do tr-fego On-Off obtido pelo controlador fuzzy, comparado como caso sem controlador, maior do que no caso com trfego

12

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

20

30

40

50

60

70

80

0.1 0.2 0.5 1 2 5 10

Per

cent

il 90

do

reta

rdo

(mse

g)

Intervalo de operao do controlador (seg)

Avaliao intervalo do controlador com trfego CBR

Sem CtrlCtrl ConvCtrl Fuzzy

(a) Trfego CBR

5

10

15

20

25

30

35

40

45

0.1 0.2 0.5 1 2 5 10

Per

cent

il 90

do

reta

rdo

(mse

g)

Intervalo de operao do controlador (seg)

Avaliao intervalo do controlador com trfego OnOff

Sem CtrlCtrl ConvCtrl Fuzzy

(b) Trfego On-Off

Figura 9. Avaliao do intervalo de atuao do controlador

CBR,mostrando a maior eficincia do controlador fuzzy pa-ra tratar trfego On-Off. O critrio para a escolha do valor1 segundos para intervalo de operao do controlador foi oequilbrio entre resultado da QoS obtida e a sobrecarga com-putacional para ambos os controladores.

Outra concluso desses resultados a demonstrao queo controlador fuzzy implementa um controle mais eficienteque o convencional. Mesmo reconhecendo a maior necessi-dade de recursos computacionais exigidos pelo controladorfuzzy, ele pode ser aplicado em intervalos maiores do que ocontrolador convencional. Assim, podemos indicar, pelo me-nos,um equilbrio na necessidade de recursos computacionaisem ambos os controladores.

7.2 AVALIAO DA VARIAO DO TAMA-NHO DO PACOTE IP

O segundo parmetro avaliado foi o tamanho do pacote,mostrado na figura10. Variamos o tamanho do pacote desde100 bytes, correspondente ao trfego produzido por um codi-ficador H.323, at 576 bytes, correspondente ao trfego pro-duzido por um codificador G.711. Os valores medidos foramo percentil 90 do retardo para pacotes com 100, 300 e 576

bytes. O tempo de operao do controlador foi de 1 segundo.Na avaliao com trfego CBR, mostrada na figura10(a),

podemos notar que com pacotes pequenos (100 bytes) os re-tardos esto prximos, apesar do controlador fuzzy j mos-trar uma pequena superioridade. A justificativa para o retar-do ser baixo com pacotes pequenos em qualquer controlador o melhor intercalamento dos pacotes no escalonador. Como aumento do tamanho dos pacotes o retardo aumenta qua-se linearmente. Para qualquer tamanho de pacote avaliado, opercentil 90 do retardo obtido com controlador fuzzy semprefoi inferior aos retardos obtidos pelo controlador convencio-nal e no caso sem controlador, nesta ordem.

0

20

40

60

80

100 200 300 400 500 600

Per

cent

il 90

do

reta

rdo

(mse

g)

Tamanho do Pacote (bytes)

Avaliao tamanho do pacote

Sem CtrlCtrl ConvCtrl Fuzzy

(a) Trfego CBR

0

5

10

15

20

25

30

35

40

100 200 300 400 500 600

Per

cent

il 90

do

reta

rdo

(mse

g)

Tamanho do Pacote (bytes)

Avaliao tamanho do pacote

Sem CtrlCtrl ConvCtrl Fuzzy

(b) Trfego On-Off

Figura 10. Avaliao da influncia do tamanho dos pacotes

Na avaliao com trfego On-Off, mostrada na figura10(b), podemos notar que o retardo obtido com o controladorfuzzy foi sempre inferior aos retardos obtidos com contro-lador convencional e sem controlador. Observamos tambmque o retardo,nesses dois ltimos casos, semelhante parapacotes pequenos, devido ao melhor intercalamento dos pa-cotes, conforme explicado anteriormente. Com pacotes mai-ores que 300 bytes, os retardos com controlador convencionalso inferiores aos obtidos sem controlador.

Notamos tambm que a diferena do retardo com trfegoOn-Off obtido pelo controlador fuzzy comparado com o con-trolador convencional e sem controlador, maior que no caso

13

Marcial Porto Fernandez, Aloysio de Castro P. Pedroza e Jos Ferreira de RezendeImplementao de Polticas de Gerenciamento com lgica Fuzzy e Alg. Gentico visando melhor QoS

com trfego CBR, mais uma vez mostrando a melhor efici-ncia do controlador fuzzy para tratar trfego On-Off. Final-mente, conclumos que o resultado obtido com o controladorfuzzy melhor que o controlador convencional e sem contro-lador para qualquer tamanho de pacote.

8. CONCLUSO E TRABALHOS FUTU-ROS

Apresentamos nesse trabalho, uma arquitetura de sistemade gerenciamento para manter a QoS em uma arquiteturaDiffServ. Foi proposta, tambm, uma metodologia para re-alizar o mapeamento de polticas de gerenciamento em pa-rmetros de controlador fuzzy. Esse controlador implementaum mecanismo de provisionamento dinmico, que coordena-das pelo sistema de gerenciamento, melhora a QoS no mbitodo domnio.

O gerenciamento baseado em polticas permite que o con-trolador seja genrico, podendo definir o comportamento dosistema de acordo com as decises administrativas do opera-dor de rede do domnio. Alm disso, o comportamento podeser facilmente alterado em todo o domnio, durante o fun-cionamento normal do sistema. A proposta de mapeamentode polticasPonderem parmetros de controlador fuzzy de-monstra a capacidade da lgica fuzzy de representar requisi-tos de QoS abstratos.

As simulaes realizadas para validar o modelo utilizaramexemplo com classes EF e BE. Apesar de conceitualmentesimples, as avaliaes de retardo e variao de retardo sodificultadas pela impreciso e incerteza do trfego que entrano domnio[26]. Os resultados obtidos atravs de simulaodemonstram a viabilidade da proposta, pela sensvel melho-ria nas medidas da qualidade de servio, comparadas quelasdas situaes sem controlador ou com um controlador con-vencional.

Foram realizadas simulaes variando-se o intervalo deoperao do controlador e o tamanho dos pacotes transmi-tidos. Quando variamos o intervalo de operao do contro-lador mostramos que, com intervalo pequeno, o resultado docontrolador fuzzy apenas um pouco melhor que o do con-trolador convencional, tornando-se mais significativo em in-tervalos maiores. O controlador fuzzy mostrou-se mais efici-ente que o convencional para qualquer intervalo de operao.Outra observao importante o intervalo ideal que propor-cional ao tempo mdio das conexes dos fluxos que cruzamo domnio. Comparando os resultados de trfego CBR e On-Off notamos que o controlador fuzzy apresenta-se mais efi-ciente com trfego On-Off, ou seja, trfegos encontrados emuma rede real.

Quando variamos o tamanho do pacote, observamos que,com pacotes pequenos, as medidas de QoS so semelhantespara todas as situaes. Esse fato, j conhecido nas redesATM, demonstra que reduzir os tamanhos dos pacotes umamedida eficaz para melhorar a QoS. Como aumento do tama-nho do pacote, observamos uma degradao na QoS em todasas situaes, porm o controlador fuzzy continua apresentan-do o melhor resultado. Novamente podemos observar queo controlador fuzzy produz um melhor resultado comparati-

vo quando trata trfego On-Off em relao ao trfego CBR,confirmando sua melhor eficincia para tratar trfegos reais.

Finalmente, podemos concluir que mecanismos de provi-sionamento dinmico apresentam vantagens em manter QoS,quando ocorre variaes normais nos fluxos de trfego. Aatitude usual de super-provisionamento possibilita a manu-teno da qualidade, porm o custo para manter essa infra-estrutura extra alto. Mostramos tambm que a lgica fuzzyfoi adequada para tratar trfegos com alta variao, comunsnas situaes reais. A arquitetura proposta permitiu a cons-truo de um sistema escalvel e eficiente. A utilizao degerenciamento baseado em polticas facilitou a especificaodos requisitos de QoS desejados.

Como continuao do trabalho, poder ser definido umcontrolador que inclua suporte a outras classes DiffServ, co-mo AF (Assured Forwarding). Essa classe segue filosofia di-ferente, devendo o controlador tratar variveis distintas dasconsideradas neste trabalho. Assim, teremos um controla-dor completo, com capacidade de ajustar dinamicamente osparmetros de todas as classes DiffServ, de acordo com asvariaes do trfego e polticas especificadas.

Outro desafio o tratamento de redes mveis. Como previsto que qualquer infra-estrutura de redes em um futuroprximo tenha segmentos mveis e areos, seria interessanteavaliara aplicao da metodologia aqui proposta nesse caso.O tratamento de QoS em ambiente mvel ainda um proble-ma em aberto.

Outro trabalho futuro deve ser a avaliao de desempenho,tanto nos equipamentos de rede como no gerenciador cen-tral. Como todas as avaliaes foram realizadas em simula-o, no foi possvel avaliar o impacto dos novos mecanismosadicionados rede.

AGRADECIMENTOS

Esse trabalho foi realizado com recursos da UFRJ, CNPq,CAPES e FAPERJ.

REFERNCIAS

[1] S. Blake, D. Black e M. Carlson, An architecture for differen-tiated services. RFC 2475, dezembro de 1998.

[2] M. P. Fernandez, A. de Castro P. Pedroza e J. F. de Rezen-de, Quality of service in a DiffServ domain using policy-based management, inXVII International Teletraffic Con-gress (ITC17), Salvador, Brazil, dezembro de 2001.

[3] M. P. Fernandez, A. de Castro P. Pedroza e J. F. de Rezen-de, QoS provisioning across a DiffServ domain using policy-based management, in(Globecom 2001), San Antonio, USA,novembro de 2001.

[4] C. C. Lee, Fuzzy Logic in control systems: Fuzzy logic con-troller, Part II, IEEE Transactions on Systems, Man, and Cy-bernetics, vol. 20, no. 2, pp. 419435, maro de 1990.

[5] F. Herrera, M. Lozano e J. Verdegay, Tuning fuzzy logic con-trollers by genetic algorithms,International Journal of Ap-proximate Reasoning, vol. 12, no. 3, pp. 299315, junho de1995.

[6] J. Velasco e L. Magdalena, Genetic algorithms in fuzzy con-trol systems, inGenetic Algorithms in Engineering and Com-puter Science(G. Winter, J. Periaux, M. Galan e P. Cuesta,eds.), pp. 141165, John Wiley & Sons, 1995.

14

Revista da Sociedade Brasileira de TelecomunicaesVolume 18, Nmero 2, outubro 2003

[7] M. Sloman, Policy driven management for distributed sys-tems, Journal of Networking and Systems Management,vol. 2, no. 4, no. 4, pp. 333360, 1994. Plenum Press.

[8] DMTF, Common Information Model (CIM) specificati-on - version 2.2. Distributed Management Task Force.http://www.dtmf.org/spec/cims.html, junho de 1999.

[9] B. Moore, J. Strassner e E. Elleson, Policy core informa-tion model. Internet Draft draft-ietf-policy-core-info-model-08.txt, outubro de 2000.

[10] E. Lupu e M. Sloman, Conflicts in policy-based distributedsystems management,IEEE Transactions on Software Engi-neering, Special Issue on Inconsistency Management, vol. 25,no. 6, no. 6, pp. 852869, 1999. IEEE.

[11] N. Damianou, N. Dulay, E. Lupu e M. Sloman,Ponder Policy Specification Language. http://www-dse.doc.ic.ac.uk/policies/ponder.shtml.

[12] N. Damianou, N. Dulay, E. Lupu e M. Sloman, The Ponderpolicy specification language, inPolicy 2001: Workshop onPolicies for Distributed Systems and Networks, Bristol, UK,pp. 1839, janeiro de 2001.

[13] E. Lupu e M. Sloman, Towards a role based framework fordistributed systems management,Journal of Network andSystems Management, vol. 5, no. 1, pp. 530, janeiro de 1997.Plenum Press Publishing.

[14] J. E. Mortensen, JFS Fuzzy System.http://www.inet.uni2.dk/ jemor/jfs.htm, 1998.

[15] L. A. Zadeh, Fuzzy sets,Information and Control, vol. 8,pp. 338353, 1965.

[16] E. Cox,Fuzzy logic for business and industry. Charles RiverMedia, outubro de 1995.

[17] O. Cordn, F. Herrera e A. Peregrn, A practical study onthe implementation of fuzzy logic controllers,The Internati-onal Journal of Intelligent Control and Systems, vol. 3, no. 3,pp. 4991, junho de 1999.

[18] V. Jacobson, K. Nichols e K. Poduri, An expedited forwardingPHB. RFC 2598, junho de 1999.

[19] O. Cordn, F. Herrera e A. Peregrn, Looking for the best de-fuzzification method features for each implication operator todesign accurate fuzzy models, tech. rep., University of Gra-nada, abril de 1999. Technical Report DECSAI-99108, Dept.of Computer Science and A.I., University of Granada.

[20] L. X. Wang e J. Mendel, Generating fuzzy rules by learningfrom examples,IEEE Transactions on Systems, Man, and Cy-bernetics, vol. 22, no. 2, pp. 14141427, julho de 1992.

[21] Z. Michaelewicz,Genetic algorithms + data structure = evo-lution programs. Springer-Verlag, maro de 1996.

[22] M. Mitchell, An Introduction to Genetic Algorithms. MITPress, maro de 1996.

[23] K. De Jong,An Analysis of the Behavior of a class of GeneticAdaptive System. Tese de Doutorado, University of Michigan,1975.

[24] S. McCanne e S. Floyd, ns Network Simulator - Version 2.http://www.isi.edu/nsnam/ns/, 1998.

[25] H. Hsiung, M. J. Fischer, D. M. Masi, D. Cuffie e S. Scheurich,An approach to IP telephony performance measurement andmodeling in government environments, in9th Annual Confe-rence of the Internet Society, INET99, San Jose, USA, julhode 1999.

[26] D. Lorenz e G. Orda, QoS routing in networks with uncertainparameters, inIEEE Infocom 98, 1998.

Marcial Porto Fernandez graduado em Engenharia Eletrnicapela Universidade Federal do Rio de Janeiro (UFRJ) em 1988, re-cebeu o ttulo de mestre e doutor em Engenharia Eltrica no Gru-po de Teleinformtica e Automao (GTA) na COPPE/UFRJ em

1998 e 2002, respectivamente. Atualmente pesquisador do Insti-tuto de Computao da Universidade Federal Fluminense, Niteri.Suas reas de interesse so Gerenciamento de Redes e Qualidade deServio na Internet.

Aloysio de Castro P. Pedroza graduado em Engenharia Eletr-nica pela Universidade Federal do Rio de Janeiro (UFRJ) em 1975,recebeu ttulo de mestre em Engenharia Eltrica na COPPE/UFRJem 1980 e doutor em Engenharia Eltrica e Cincia da Computaopela Universite Paul-Sabatier/LAAS, Frana, em 1985. Atualmente professor adjunto da UFRJ, Rio de Janeiro. Suas reas de interes-se so linguagens de especificao, verificao e implementao desoftware e hardware de sistemas distribudos.

Jos Ferreira de Rezenderecebeu o diploma de Engenheiro Eletr-nico e o ttulo de Mestre em Engenharia Eltrica pela UniversidadeFederal do Rio de Janeiro (UFRJ) em 1988 e 1992, respectivamente,e o ttulo de Dr. em Cincia da Computao pela Universit Pierreet Marie-Curie (Paris 6), em 1997. Desde 1998 ele professor ad-junto do Programa de Engenharia Eltrica da COPPE/UFRJ. Suasatividades de pesquisa concentram-se nas seguintes reas: aplica-es multimdia distribudas, comunicao de grupo, redes de altavelocidade, redes mveis e QoS na Internet.

15

IntroduoSistema de provisionamento dinmico de recursosArquitetura do sistema de provisionamento dinmicoMetodologia para construo do controlador de provisionamento

Implementao de polticas de gerenciamentoLinguagem de especificao de polticas: PonderEspecificao das polticas de QoSMapeamento de especificao de polticas em parmetros de controlador fuzzyRepresentao do comando PD1T1ptmptmmmnnconstraint e PD1T1ptmptmmmnnauthRepresentao do comando PD1T1ptmptmmmnneventRepresentao do comando PD1T1ptmptmmmnnoblig

Construo do controlador fuzzyFunes de PertinnciaControlador do EscalonadorControlador do Condicionador

Base de Regras

Otimizao do Controlador FuzzyVerificao de regras atravs do algoritmo de Wang-MendelSeleo dos valores para otimizao do controlador fuzzyOtimizao de controlador fuzzy atravs de algoritmo genticoFuncionamento dos algoritmos genticosParmetros de configurao do algoritmo genticoTamanho da populaoTaxa de cruzamentoTaxa de mutaoNmero de geraes

Implementao do ProttipoAmbiente de SimulaoOtimizao do Controlador FuzzyTopologia de simulaoModelo de trfego de simulaoControlador convencional

ResultadosAvaliao do intervalo de operao do controladorAvaliao da variao do tamanho do pacote IP

Concluso e Trabalhos Futuros