Gestão e controlo de QoS

Apesar de existirem diversos mecanismos de fornecer QoS em redes IP, para que seja possível controlar e garantir essa QoS de uma forma realista, é necessário aliar esses mecanismos a sistemas de gestão e controlo que tirem o máximo proveito dos recursos existentes. Os modelos actualmente mais populares, denominados de Policy Based

Qualidade de Serviço em Redes IP

95

Management (PBM), recorrem à utilização de políticas de gestão, armazenadas em

servidores e implementadas por elementos específicos.

4.4.1 Políticas e servidores de políticas de QoS

A norma desenvolvida pelo IETF para o controlo de políticas de QoS define pontos de imposição de políticas (PEP, Policy Enforcement Points) e pontos de decisão de políticas (PDP, Policy Decision Point) [Yava00] (Figura 16). As políticas estão armazenadas num servidor de políticas (PS - Policy Server) e são transmitidas aos PDPs de modo a estes as imporem em cada um dos PEPs. Os PEPs incluem routers, comutadores e outros equipamentos capazes de actuar como agentes para o controlo de admissão. Normalmente os PEPs trabalham em conjunto com os PDPs por forma a implementar as políticas de QoS definidas pelo administrador da rede (ou, num sentido mais lato, pelo operador). Os PDPs detêm a inteligência necessária para o processamento de políticas abstractas, e respectiva tradução.

Pontos de Implementação de Políticas (PEPs) Router Serviço de directorias LDAP Ferramenta de gestão de policiamento Servidor AAA Pontos de Decisão d Políticas (PDPs) Servidor de Gestáo LDAP DNS DHCP LDAP FireWall Comutador COPS SNMP de PolíticaAplicação Entidades de Rede

Figura 16: Arquitectura de políticas e policiamento do IETF

4.4.1.1 COPS / PEPs / PDPs

Em [Boyl00] é descrito o protocolo COPS (Common Open-Policy Service) que é um protocolo de pergunta e resposta simples utilizado para trocar informação de políticas entre um servidor de políticas (PDP) e os seus clientes (PEPs) conforme se observa na Figura 17.

Serviços Multimédia Sobre Redes Heterogéneas

96

O protocolo COPS define três tipos de mensagens distintas: pedido, decisão e relatório. O PEP efectua pedidos e o PDP responde com decisões. As mensagens de relatório são também enviadas pelo PEP ao PDP mas não necessitam de resposta por parte deste. As mensagens de pedido podem conter um ou mais elementos de política, os quais serão examinados pelo PDP para determinar a resposta. A mensagem resposta, de decisão, indicam ao PEP as acções a tomar em relação ao pedido realizado. As mensagens de relatório são utilizadas, por exemplo, para o PEP passar informação de estado ou de contabilização ao PDP.

Mensagem Mensagem

Pedido COPS Decisão COPS

PEP PDP

Figura 17: Interacção COPS entre PEP e PDP

Existem duas variantes do protocolo COPS: o COPS-PR e o COPS-RSVP. As diferenças entre o COPS-PR e o COPS-RSVP são as seguintes: o COPS-PR apresenta uma arquitectura de provisão. O PEP envia ao PDP um pedido com uma lista de requisitos de políticas. O PDP devolve as políticas (queuing, buffering, prioridade, etc.) numa mensagem de decisão PDP. Após isto, o funcionamento do COPS-PR resume-se quase exclusivamente à manutenção de keep-alives. O PDP pode enviar decisões não solicitadas e o PEP pode fazer novos pedidos ou renovar os existentes. A arquitectura COPS-RSVP é de outsourcing no sentido em que as políticas não estão pré-definidas. O PEP faz pedidos apenas quando surge um evento exterior que o force. No caso do COPS-RSVP, os pedidos efectuados pelo PEP podem incluir a parametrização da política pretendida. A decisão do PDP é relativamente simples, limitando-se a uma aceitação ou rejeição (ou aceitação com alterações).

O COPS pode ser utilizado para o PDP efectuar a configuração inicial dos PEPs do seu domínio e pode ser utilizado para configuração de políticas fluxo a fluxo. No primeiro

Qualidade de Serviço em Redes IP

97

caso (COPS-PR), o PEP quando é activado, envia um pedido ao PDP, de acordo com as suas características para que seja correctamente configurado. No segundo caso (COPS- RSVP), por cada novo fluxo que pretenda ser admitido, o PEP faz um pedido ao PDP que lhe responde com a sua decisão de aceitar ou não o fluxo.

Algumas das decisões passadas pelo PDP ao PEP são a classificação dos pacotes (prioridades), as taxas de transmissão, os dimensionamentos das filas de espera, a formatação do tráfego, a definição das classes de serviço DiffServ e as estratégias de descarte e remarcação de pacotes.

4.4.2 QoS Brokers (Bandwidth Brokers)

Um Bandwidth Broker ou QoS Broker é uma entidade que realiza controlo de admissão e reconfiguração de dispositivos de rede de acordo com um conjunto de condições impostas pelos administradores de rede, com o objectivo de obter QoS extremo- a-extremo (eventualmente atravessando várias redes de vários fornecedores). Um determinado QoS Broker tem o seu domínio de acção bem definido. De modo a garantir QoS estrita, extremo-a-extremo, todos os QoS Brokers no caminho da ligação pretendida devem interagir em concordância.

Um QoS Broker é um PDP e pode também ser visto como um Policy Server (PS). Existem algumas funcionalidades exigidas a um PS que não o são aos QoS Brokers. Neste sentido, um QoS Broker pode ser uma parte de um PS, ou em alternativa, pode interagir com um. De um modo análogo, um QoS Broker pode ser parte integrante de um sistema de gestão de rede (NMS – Network Management System), não se distinguindo deste, ou pode ser uma entidade externa, implementando apenas algumas das funcionalidades do NMS.

Desta forma, o QoS Broker, o PS e o NMS podem ser sistemas distintos ou podem eventualmente estar concentrados numa única entidade. No caso de se tratarem de sistemas distintos, torna-se necessário a existência de interfaces e protocolos entre eles, que permitam o acesso a este sistema partilhado e distribuído. No caso de todas as funcionalidades estarem concentradas apenas numa única entidade, é natural que surjam problemas de escalabilidade à medida que a rede cresce e se torna mais complexa.

De um modo simplificado podemos dizer que um QoS Broker controla e monitoriza os recursos de rede tanto no seu domínio como nas extremidades. Também é sua responsabilidade monitorizar nas extremidades a existência de pedidos de reserva, quer para o interior do seu domínio, quer para o exterior. A informação recolhida é utilizada em

Serviços Multimédia Sobre Redes Heterogéneas

98

conjunção com a informação do PS de modo a tomar as decisões de controlo de admissão. Os SLSs são implementados pelos QoS Brokers dentro do seu domínio. O QoS Broker é também responsável por controlar, conjuntamente com os QoS Brokers vizinhos, as ligações inter-domínio de modo a coordenar os SLSs através de vários domínios.

A coordenação dos SLSs entre os vários domínios poderá ser realizada de um modo agregado nas fronteiras dos domínios. Isto é, todos os fluxos de determinado domínio que tenham características de QoS semelhantes podem ser tratados como um único fluxo, com características iguais à soma dos fluxos individuais. Para um fluxo ser admitido em determinado domínio deve inicialmente ser feito um pedido de alocação de recursos (RAR – Resource Allocation Request) que será analisado pelo QoS Broker de modo a este poder coordenar a alocação e fornecimento dos recursos necessários a todos os fluxos e agregados originados dentro e fora do seu domínio.

Sistema Autónomo #1 Sistema Autónomo #2 Sistema Autónomo #3

QoS Broker #1 QoS Broker #2 QoS Broker #3 SLSs

SLAs SLSsSLAs

Router Fronteira

Router

Fronteira FronteiraRouter

Router Fronteira Router Fronteira Comunicação Inter-Domínio Comunicação Inter-Domínio Serviços dos Utilizadores Serviços dos Utilizadores Pedido de Alocação de Recursos

Figura 18: Exemplo de configuração de rede

Para melhor entender o conceito, a Figura 18 [Neil99] apresenta um exemplo simples de uma configuração de rede. Esta rede é composta por três domínios, os sistemas autónomos #1, #2 e #3 com os respectivos QoS Brokers, QoS Broker #1, QoS Broker #2 e

QoS Broker #3. Também são mostrados os SLSs/SLAs em vigor entre os diferentes

domínios assim como utilizadores individuais do sistema autónomo #1 que fazem pedidos de alocação de recursos ao QoS Broker #1. Neste caso, o “utilizador individual” pode ser, quer um sistema, quer uma aplicação a fazer um pedido de largura de banda. Este é o modelo base desenvolvido pela Internet2 [INTQ].

Qualidade de Serviço em Redes IP

99