Network Executive: Uma Ferramenta para Gerência de Redes Baseada em Políticas

Transcrição

1 Network Executive: Uma Ferramenta para Gerência de Redes Baseada em Políticas Gustavo Augusto Faraco de Sá Coelho, Lisandro Zambenedetti Granville, Maria Janilce Bosquiroli Almeida, Liane Margarida Rockenbach Tarouco Universidade Federal do Rio Grande do Sul UFRGS Instituto de Informática Av. Bento Gonçalves, 9500 Bloco IV Porto Alegre, RS Brasil Telefone: {gcoelho, granville, janilce, Resumo. O surgimento de novas aplicações que exigem suporte à QoS tornam as redes de computadores ainda mais heterogêneas e complexas. A gerência de redes atual não é capaz de suprir as novas necessidades dos gerentes de redes. É neste cenário que a Gerência de Redes Baseada em Políticas surge e se mostra eficiente para garantir o funcionamento de serviços com QoS. Este trabalho a- presenta uma solução desenvolvida para atender a esta necessidade por novas ferramentas capazes de gerenciar os novos serviços de rede que estão surgindo. Palavras-chave: gerência de redes baseada em políticas, gerência de QoS, ambientes de gerência, gerência de redes Abstract. The emerge of new applications that demand support of QoS results in more heterogeneous and complex computer networks. The network management used nowadays is unable to support the new needs of network managers. It is in this context that the Policy-based Network Management emerges and shows efficiency to guarantee the operation of QoS services. This work presents a solution developed to supply this need for new software tools able to manage new resources deployed on current networks. Keywords: policy-based network management, QoS management, management environments, network management 1 INTRODUÇÃO Atualmente as redes de computadores estão presentes em praticamente todos os lugares e possuem complexidades e dimensões muito variadas, desde pequenas redes locais até grandes redes metropolitanas e nacionais. Se inicialmente o tráfego destas redes era caracterizado apenas pelo transporte de dados, hoje o tráfego verificado é bastante heterogêneo. As aplicações atuais de voz sobre IP, videoconferência, telemedicina, ensino à distância, entre outras, exigem serviços mais adequados das redes. Se antigamente, o paradigma best-effort do protocolo IP era suficiente, hoje é necessária a existência de serviços de rede que forneçam garantias para que novas aplicações operem de forma eficiente. Neste cenário surge a necessidade de parâmetros de QoS (Quality of Service) capazes de garantir vazão, atraso, jitter e taxa de perdas limitadas. Assim, as redes IP, para suportarem as novas aplicações, devem migrar do paradigma best-effort para um paradigma onde os serviços possuam garantias de QoS. Se para o usuário final as novas aplicações são uma opção atraente, gerando novas oportunidades de negócios, novos meios de se obter conhecimento e tornando as empresas mais ágeis, para o gerente de redes tais aplicações representam novos desafios para o adequado

2 funcionamento da rede. A implantação destas novas aplicações e a adição de novos mecanismos e técnicas capazes de suportá-las, tornam a rede de computadores um ambiente mais heterogêneo e complexo, e portanto mais difícil de ser gerenciado. Neste cenário, a gerência tradicional não é mais suficiente. A quantidade de informações de gerência gerada por uma rede que possui serviços com QoS é tão grande que, ainda que o gerente tenha como extrair tais informações, o mesmo não terá como lidar com a quantidade volumosa de dados existente. Assim, a Gerência de Redes Baseada em Políticas (PBNM - Policy-Based Network Management) [1] surge para auxiliar na gerência de redes complexas. Através do conceito de políticas, o gerente da rede é capaz de definir como a rede deve operar, utilizando para isso uma linguagem mais abstrata do que a utilizada na gerência tradicional. Observa-se que o gerente informa apenas o que ele "quer" e não como isto deve ser feito. Por se tratar de uma tecnologia relativamente nova, as ferramentas comerciais existentes para gerência baseada em políticas diferem bastante entre si quanto aos protocolos utilizados, o que dificulta a interoperabilidade. Ao contrário do que acontece no mercado das aplicações de gerência tradicional onde o SNMP é padrão de fato, não existe uma solução PBNM que se destaque das demais e assim não há nenhum padrão de mercado [2]. As ferramentas disponíveis atualmente, como HP PolicyXpert [3], ExtremeWare Enterprise Manager [4] e Cisco QoS Policy Manager [5], não seguem totalmente os trabalhos do IETF (Internet Engineering Task Force), como a utilização de protocolos abertos e o uso de linguagem natural no processo de definição das políticas [6] [7]. O trabalho apresentado neste artigo é resultado do estudo, desenvolvimento e implementação de uma ferramenta de gerência de redes baseada em políticas. Utilizando padrões definidos pelo IETF como o LDAP e o SNMP, a ferramenta, denominada Network Executive, possui uma interface Web que permite o uso de políticas sobre diversos tipos de dispositivos de rede. A organização do texto é dada da seguinte forma: no começo da segunda seção é apresentado o ambiente de gerência de QoS QAME, no qual o Network Executive é responsável pelas políticas. Os detalhes sobre o Network Executive, juntamente com a sua arquitetura, também serão discutidos ao longo da seção dois. Finalmente o trabalho é encerrado na seção três que apresenta as conclusões e os futuros trabalhos. 2 NETWORK EXECUTIVE Network Executive é a ferramenta de gerência de redes baseada em políticas que integra o sistema QAME. Como já foi mencionado, a ferramenta possui interface Web, implementada através de Applets em Java. Além disso, foi levado em consideração, deste a fase inicial de projeto do sistema, que a ferramenta deveria utilizar padrões já existentes sempre que possível. Por exemplo, as políticas, os alvos e as associações são armazenados em um servidor de diretórios LDAP. O esquema de dados utilizado para armazenar as políticas é semelhante ao recomendado pelo IETF em Snir et al. [8]. Outro protocolo padrão utilizado foi o SNMP para configuração dos alvos quando do processo de aplicação de uma política por um consumidor do sistema. 2.1 QAME Gerenciar uma rede que possui garantias sobre QoS envolve a análise de um volume de informações maior que o encontrado na gerência de redes sem QoS. A gerência tradicional

3 não é capaz de, adequadamente, gerenciar uma rede desse tipo porque o tempo despendido pelo gerente de rede na análise das informações de gerência obtidas é proibitivo. Logo, existe a clara necessidade de se ter um novo esquema de gerência onde o grande volume de dados possa ser reduzido a níveis aceitáveis, de forma a permitir ao gerente de rede resolver os problemas encontrados em tempo hábil. A gerência de redes baseada em políticas é uma alternativa viável a este problema porque permite que o gerente defina ações a serem executadas na rede sem se preocupar intensamente com os detalhes da rede gerenciada. Assim, um novo nível de abstração de informações é apresentado ao gerente de forma que o mesmo consiga definir ações coerentes, em tempo, sem perder a visão geral da rede gerenciada. O ambiente de gerência denominado QAME (QoS-Aware Management Environment) [9] procura fornecer facilidades para que o gerente seja capaz de aplicar a gerência de QoS de forma mais efetiva. QAME suporta a execução de seis principais tarefas de gerência de QoS: implantação, monitoração, manutenção, descoberta, visualização e análise de QoS. A definição de políticas e sua implantação na rede fazem parte da manutenção de QoS do QAME. Para que as tarefas de gerência citadas anteriormente possam ser efetivamente realizadas, a arquitetura do QAME conta com módulos de software disjuntos mas relacionados, que podem estar localizados em vários pontos críticos distintos da rede (figura 1). Ambiente do usuário e bases de dados Implantação, manutenção, descoberta, monitoração, análise e visualização de QoS Network Executive LDAP Políticas Status SNMP HTTP Associações Elementos intermediários LDAP SNMP HTTP Consumidor de políticas Monitor de QoS Identificador de alvos Elementos inferiores Alvos Figura 1 - Escopo do Network Executive na arquitetura QAME No nível mais inferior da arquitetura estão localizados os alvos, que são efetivamente os elementos que implementam uma solução de QoS. Exemplos de alvos são: os algoritmos de escalonamento de filas nas interfaces de saída de um roteador, os processos de conformação de tráfego e prevenção de congestionamento e o algoritmo de marcação de pacotes em serviços diferenciados nas interfaces de entrada. Na camada acima encontramos os elementos intermediários da arquitetura: identificadores de alvos, consumidores de políticas e monitores de QoS. Os identificadores de alvos são agentes especiais que procuram nos dispositivos de uma rede a existência de novos alvos. Sempre que um novo alvo é encontrado o mesmo é cadastrado na base de dados associações.

4 Os consumidores de políticas executam a implantação de uma política nos alvos, traduzindo descrições de políticas em comandos específicos em cada alvo. Para tal, na base de dados associações existe uma correspondência entre os alvos cadastrados e as políticas definidas. Por fim, para garantir que as políticas implantadas estão realmente correspondendo ao esperado, os monitores de QoS analisam o tráfego de segmentos críticos da rede e comparam o comportamento real com o comportamento esperado. Se a diferença de comportamento for maior que um limiar crítico, o monitor de QoS dispara uma notificação indicando uma degradação de QoS ao gerente. No sistema existem três bases de dados principais. A base de associações, já citada anteriormente, a base de políticas e a base de status. A base associações armazena os alvos e elementos intermediários do sistema (consumidores de políticas, identificadores de alvos e monitores de QoS), bem como a correspondência entre estes. Armazena também as associações entre as políticas armazenadas na base políticas e os alvos em que tais políticas estão implantadas. A base status armazena o estado atual de uma política já definida e implantada em um dispositivo, de forma que o gerente da rede possa verificar a efetiva utilização e funcionamento de uma política. Por fim, na parte superior da arquitetura encontra-se o ambiente do usuário, onde o gerente da rede, através de uma interface com tecnologia Web interage com o QAME de forma a gerenciar os seis aspectos relacionados ao QoS citados anteriormente. Como pode ser visto pela figura 1, o QAME apresenta uma arquitetura distribuída, já que os vários elementos podem estar localizados em dispositivos de rede distintos. Por exemplo, um consumidor de políticas pode estar localizado junto ao sistema de gerência, enquanto que outro consumidor pode estar implementado internamente a um roteador que suporte PBNM. Por fim, a figura 1 apresenta também o escopo do Network Executive, explicitando quais os elementos da arquitetura QAME são de responsabilidade do mesmo. A seção a seguir apresenta de forma mais detalhada o funcionamento de Network Executive neste contexto. 2.2 Arquitetura do Network Executive A figura 2 apresenta a arquitetura completa do Network Executive. Interface com usuário (1) (2) LDAP (3) Network Executive Daemon Servidor HTTP (4) (4) Consumidor de políticas Consumidor de políticas (5) (5) (5) Alvo Alvo Alvo Figura 2 - Arquitetura do Network Executive

5 O sistema é basicamente dividido em quatro elementos principais: - A interface do usuário, através da qual o gerente da rede interage com o sistema; - A estação central de gerência, que implementa a lógica das funcionalidades solicitadas pelo gerente; - Os consumidores de políticas, que traduzem as políticas definidas em ações específicas em cada alvo; e - Os alvos, que são programados de acordo com as políticas definidas para a rede onde estes se encontram. Na estação central de gerência ficam o Network Executive Daemon, o servidor LDAP e o servidor HTTP, enquanto que os consumidores de políticas são encontrados nos mais diversos pontos da rede, de preferência próximos dos alvos de forma a minimizar o tráfego de gerência de rede. A peça central do sistema é o Network Executive Daemon. Ele é o responsável por gerenciar as políticas definidas pelo usuário, armazenando e consultando o servidor LDAP e a- cionando os consumidores de políticas responsáveis pelos diversos alvos envolvidos em uma determinada política de QoS. O Network Executive Daemon é implementado na linguagem C e utiliza funções da biblioteca OpenLDAP [10] para acessar o serviço de diretório (figura 2, seta 3) e se comunica com a interface Web (figura 2, seta 1) e os consumidores de políticas (figura 2, seta 4) através de um protocolo proprietário utilizando sockets. O serviço de diretório LDAP utilizado para armazenar as políticas é o OpenLDAP, o qual utiliza o protocolo LDAP versão 1. A interface Web do sistema é implementada em Java versão 1.1 sob a forma de Applets para que qualquer navegador possa utilizar o sistema. É importante ressaltar que a versão do JDK utilizado é a 1.1, pois esta corresponde a versão da Máquina Virtual Java utilizada na maioria dos navegadores, mesmo já estando disponível versões mais novas do JDK, como a Por causa desta escolha, apenas a classe gráfica AWT [11] foi utilizada, em detrimento da classe SWING [12]. Ao mesmo tempo, a escolha pelo Java versão 1.1 teve o objetivo de aumentar o espectro de possíveis usuários da ferramenta já que basta utilizar um navegador atual. As classes que compõe a interface gráfica ficam armazenadas em um servidor HTTP qualquer. No caso da implementação deste sistema foi escolhido o servidor HTTP Apache para Linux. Junto com o Network Executive Daemon, outro elemento importante do sistema são os consumidores de políticas apresentados na figura 2. Eles são responsáveis por implementar as políticas definidas pelo usuário. Sob a responsabilidade de um determinado consumidor de políticas podem estar um ou mais alvos. A única restrição é que estes alvos disponibilizem o mesmo tipo de serviço de QoS. Esta restrição se deve ao fato que existem consumidores de políticas distintos para as diversas tecnologias diferentes utilizadas para se obter serviços com QoS. Assim, um switch ATM estará sob responsabilidade de um consumidor de políticas ATM enquanto que um roteador DiffServ estará sendo gerenciado por um consumidor de políticas DiffServ. A escolha por implementar consumidores de políticas distintos para serviços diferentes visa tornar o sistema mais flexível para futuras expansões, como por exemplo, o desenvolvimento de um novo consumidor de políticas para um nova tecnologia de QoS. Os consumidores de políticas recebem as políticas do Network Executive Daemon através de um protocolo proprietário (figura 2, seta 4), semelhante ao COPS. Os consumidores de políticas implementam as políticas nos alvos (figura 2, seta 5) através do protocolo SNMP. As funções de SNMP são disponibilizadas pela biblioteca NET-SNMP [13] versão para Linux.

6 2.3 Consumidores de políticas Consumidores de políticas são os elementos que tem a função principal de aplicar as políticas nos alvos sob sua responsabilidade [6]. Como o Network Executive segue as recomendações definidas no modelo IETF, as entidades denominadas de consumidores de políticas que estão presentes na figura 2 tem exatamente as mesmas funções do elemento consumidor de políticas definido no modelo IETF. A arquitetura do Network Executive implementa um conjunto de consumidores de políticas, um para cada tipo de tecnologia de QoS que o sistema suporta. Desta forma, um switch ATM estará sob responsabilidade de um "consumidor de políticas para ATM" enquanto que um Bandwidth Broker será gerenciado por um "consumidor de políticas para Bandwidth Broker", por exemplo. Um único consumidor de políticas pode aplicar políticas sobre diversos alvos diferentes, desde que eles implementem a mesma solução de QoS. A decisão de implementar consumidores de políticas diferentes para cada tipo de tecnologia tem o objetivo de tornar o sistema mais apto a futuras expansões. Com isto, o Network Executive é capaz de suportar uma nova tecnologia de QoS com o desenvolvimento de um novo consumidor de políticas para esta tecnologia. Independente do tipo de consumidor de políticas que estiver sendo analisado, o conjunto de mensagens que ele pode receber do Network Executive Daemon deve ser o mesmo para que seja mantida a compatibilidade entre todos os elementos deste sistema PBNM. Consumidor de políticas para bandwidth broker O conceito de Bandwidth Broker apresentado por Nichols et al. [14] se refere ao elemento que tem a função de negociar a reserva de banda em outros elementos que são capazes de reservar recursos da rede. Assim, um Bandwidth Broker para Diffserv é capaz de alocar banda na rede através de uma negociação com um roteador Diffserv que ele conheça. A grande vantagem de se utilizar os serviços de um broker é que com ele o processo de reservar banda em situações que envolvem vários roteadores é simplificado. Nestes casos, é necessário fornecer ao broker apenas os endereços da origem e do destino, que ele será capaz de negociar a reserva dos recursos em todos os roteadores pelos quais irá passar o fluxo das informações. Se o gerente quiser realizar a mesma operação sem utilizar um broker, então será necessário configurar cada um dos roteadores separadamente até que todo o caminho entre os nodos terminais esteja estabelecido. O "consumidor de políticas para bandwidth broker" disponível no Network Executive é capaz de aplicar políticas de QoS em dispositivos que implementem serviços diferenciados [15]. Deve-se observar que ao utilizar os serviços de um broker, o alvo da política passa a ser o broker e não mais os dispositivos subordinados a ele. O consumidor de políticas descrito nesta seção opera com os brokers implementados em [16]. Assim, uma política definida pelo gerente da rede através da interface Web do sistema é enviada pelo Network Executive Daemon para o consumidor de políticas. Este último deve então traduzir as regras para uma interface de acesso utilizada por este tipo de broker. Neste caso, tal interface é uma MIB SNMP para QoS [16]. A reserva da banda é feita através de comandos SET do SNMP na tabela BBServerDiffServTable definida nesta MIB. Na tabela 1, a coluna da direita apresenta os objetos pertencentes à BBServerDiffServTable. Na coluna da esquerda são encontrados os parâmetros utilizados na definição das políticas. Assim, cada linha da tabela representa um mapeamento entre um parâmetro das políticas e o correspondente objeto da MIB implementada pelo broker. É importante notar que este mapeamento é específico para este tipo de broker. Para outras soluções de fornecimento de QoS existiriam traduções diferentes, por exemplo, utilizando-se comandos Telnet, requisições COPS, etc.

7 Tabela 1 - Tradução de políticas para bandwidth brokers Política Endereço IP origem Porta origem Endereço IP destino Porta destino Protocolo Classe de Serviço (vazão, atraso, jitter e fator de perda) Broker Objeto BBServerDiffServSourceAddress Objeto BBServerDiffServSourcePort Objeto BBServerDiffServDestinationAddress Objeto BBServerDiffServDestinationPort Objeto BBServerDiffServProtocol Objeto BBServerDiffServBandwidth, Objeto BBServerDiffServPrio, Objeto BBServerDiffServLimitPrio Como pode-se observar, a relação entre os parâmetros da política e os campos da tabela do broker é bastante direta e simples. O processo mais complexo é a tradução da Classe de Serviço definida na política para os objetos BBServerDiffServBandwidth, BBServerDiffServ- Prio e BBServerDiffServLimitPrio da MIB. É através deste três objetos que é possível obter os parâmetros de QoS que o gerente descreveu na política. 2.4 Esquema de dados O modelo proposto pelo IETF [7] introduz um esquema de dados que deve ser usado para representar as informações do sistema no diretório LDAP. O esquema recomendado para armazenar políticas de QoS é o "QoS Policy Schema" [8]. A utilização de um esquema padrão possibilita que ferramentas PBNM de diferentes fornecedores possam compartilhar o mesmo conjunto de políticas. O Network Executive implementa um esquema de dados parcialmente compatível com o proposto no modelo. Isso se deve ao fato de o modelo original ser relativamente complexo e ainda se encontrar em desenvolvimento (internet draft). Figura 3 - Esquema de dados do Network Executive A figura 3 apresenta o esquema de dados utilizado pelo Network Executive. A árvore de diretório apresentada é suficiente para armazenar todo o conjunto de informações que este sistema PBNM precisa para operar. Observa-se que há sub-árvores para informações sobre usuários, consumidores de políticas, alvos, associações e políticas, sendo que esta última é subdividida em uma árvore para armazenar as classes de serviços e outra para as regras propria-

8 mente ditas. Cada sub-árvore possui uma ou mais instâncias de um determinado tipo de objeto. A seguir são apresentados estes objetos assim como os atributos que cada um possui. - userinstance: username, nome, senha, nível_de_acesso - consumerinstance: ip:porta, tipo, status, descrição - targetinstance: ip:porta, tipo, status, descrição - assoctargetinstance: dn-targetinstance, dn_consumerinstance - assocpolicyinstance: dn-targetinstance, dn-policyinstance - cosinstance: nome, throughput, delay, jitter, lost_factor - policyinstance: nome, ip_origem, porta_origem, ip_destino, porta_destino, protocolo, dn_cosinstance Os campos sublinhados representam os atributos que devem ser únicos, ou sejam, são atributos chave. Todos os atributos que iniciam pelas letras "dn" representam campos que referenciam outras instâncias. Assim, uma instância de assoctargetinstance possui uma referência para uma instância de targetinstance e outra referência para um instância de consumerinstance, por exemplo. Neste caso, uma instância de assoctargetinstance está relacionando um targetinstance com um comsumerinstance, ou seja, um alvo com o consumidor de políticas responsável por ele. 2.5 Exemplo de utilização Um exemplo da interação entre os elementos que compõem o sistema é apresentado a seguir. Neste exemplo será demonstrado como ocorre a criação e a aplicação de uma nova política sobre um determinado alvo. Figura 4 - Network Executive Console 1. O gerente da rede utiliza um navegador para acessar o Network Executive Console. Na tela inicial é necessário fornecer um nome de usuário e uma senha válidos. 2. Após a autenticação do usuário, é apresentada uma nova janela onde é possível gerenciar as políticas, os usuários, os consumidores de políticas, os alvos e as associações. Na figura 4 é apresentada a janela para adição de uma nova política. O

9 gerente deve fornecer o endereço e a porta origem e destino, o protocolo e a classe de serviço. O botão "save policy" dispara o processo de validação, análise e armazenamento da política na base LDAP. 3. Definida a nova política, o gerente deve informar ao Network Executive qual alvo ele deseja associar com a política recém criada. Observa-se que é indicado apenas o alvo e o sistema deve ser capaz de saber qual consumidor de políticas é o responsável por aplicar a política. Esta associação entre consumidores de políticas e alvos é feita quando um novo alvo é adicionado ao sistema. 4. Realizada a associação entre a nova política e o alvo, o gerente deve confirmar o processo de aplicação da política. Após alguns instantes, o usuário é informado sobre o sucesso ou o fracasso da implantação no alvo das regras definidas anteriormente por ele. Comparando-se o modelo de PBNM apresentado por Stevens et al. [7] com a arquitetura do Network Executive descrita anteriormente, pode-se observar que tentou-se seguir ao máximo as recomendações do IETF quando do projeto do Network Executive. Esta preocupação deve-se ao fato de que a maioria das ferramentas comerciais existentes implementa uma solução proprietária [2]. Assim, não há compatibilidade entre soluções de fornecedores diferentes. Como conseqüência desta incompatibilidade não é possível que duas redes adjacentes façam acordos sobre reserva de banda, por exemplo, já que sistemas PBNM diferentes não conseguem se comunicar. Sistemas comerciais que seguirem o modelo definido pelo IETF, assim como ocorreu com o Network Executive, poderão se comunicar com a ferramenta descrita neste trabalho de forma direta e unificada. 3 CONCLUSÕES E TRABALHOS FUTUROS As novas redes de computadores que estão sendo implementadas devem possuir suporte a serviços de QoS, visto que as novas aplicações exigem tais serviços. Para o gerente de redes, estas novas aplicações são responsáveis pelo aumento da heterogeneidade e complexidade da gerência. As soluções para gerência atuais não são capazes de fornecer ao gerente as informações de que ele necessita nem de implementar as ações que o gerente define. Para solucionar esta situação foi desenvolvido o conceito de Gerência de Redes Baseada em Políticas (PBNM). O trabalho descrito aqui apresentou a ferramenta de gerência Network Executive que u- tiliza o conceito de políticas para gerenciar redes com suporte a QoS. Características gerais e a arquitetura da ferramenta também foram descritas. Foi apresentado uma solução integrada para a gerência de QoS denominada de QAME. O Network Executive faz parte do ambiente QAME e interage com os outros elementos deste ambiente compartilhando recursos comuns como bases de dados. Os futuros trabalhos envolvem a implementação do suporte ao protocolo COPS para transporte das políticas entre o Network Executive e os consumidores de políticas do sistema e entre os consumidores de políticas e os alvos. A implementação de funções de replicação e distribuição de vários servidores Network Executive Daemon em grandes redes e a utilização de linguagem natural na interface Web para facilitar a definição das políticas por parte do gerente de redes são pontos que também deverão ser investigados no futuro.

10 REFERÊNCIAS BIBLIOGRÁFICAS [1] QoS Forum: Introduction to QoS Policies. White Paper. Disponível em: < Acesso em: abr [2] Conover, J.: Policy-Based Network Management. Network Computing, Nov Disponível em: < Acesso em: mar [3] HP. PolicyXpert. Disponível em: < policyexpert/index.asp>. Acesso em: nov [4] Extreme Networks. ExtremeWare Enterprise Manager. Disponível em: < Acesso em: jun [5] Cisco. QoS Policy Manager. Disponível em: < cc/pd/wr2k/qoppmn/index.shtml>. Acesso em: dez. de [6] Mahon, H.; Bernet, Y.; Herzog, S.; Schnizlein, J.: Requirements for a Policy Management System. IETF, Nov (Internet draft <draft-ietf-policy-req-02.txt> work in progress). Disponível em: < Acesso em: 19 jan [7] Stevens, M.; Weiss, W.; Mahon, H.; Moore, B.; Strassner, J.; Waters, G.; Westerinen, A.; Wheeler, J.: Policy framework. (Internet draft <draft-ietf-policy-framework-00.txt> work in progress). Disponível em: < Acesso em: nov. de [8] Snir, Y.; Ramberg, Y.; Strassner, J.; Cohen, R.: QoS Policy Schema. (Internet draft <draft-ietf-policy-qos-schema-01.txt> work in progress). Disponível em: < Acesso em: nov. de [9] Granville, L.; Tarouco, L.: QAME - An Environment to Support QoS Management Related Tasks on IP Networks. In: Proc. IEEE International Conference on Telecommunications. Bucharest - Romania, [10] OpenLDAP. Disponível em: < Acesso em: jan [11] Sun Microsystems. Creating a User Interface (AWT Only). Disponível em: <ftp://ftp.javasoft.com/docs/tut-oldui.zip>. Acesso em: [12] Sun Microsystems. Creating a GUI with JFC/Swing. Disponível em: < Acesso em: [13] NET-SNMP. Disponível em: < Acesso em: abr [14] Nichols, K.; Jacobson, V.; Zhang, L.: A Two-bit Differentiated Services Architecture for the Internet. IETF Nov (Request for Comments 2638). Disponível em: < Acesso em: [15] Blake, S.; Black, D.; Carlson, M.; Davies, E.; Wang, Z.; Weiss, W.: An architecture for differentiated service. IETF, Dec (Request for Comments 2475). Disponível em: < Acesso em: 5 jan [16] Granville, L.; Uzun, R.; Tarouco, L.; Almeida, J.: Managing Differentiated Services QoS in End Systems using SNMP. In: Proc. IEEE Workshop on IP-oriented Operations & Management - IPOM Krakow - Polland, 2000.