Esta seção discute sobre as possibilidades de protocolos a serem utilizados em uma implementação do modelo proposto. Os protocolos são sugeridos genericamente, e exemplos são apresentados. Como regra geral, procura-se utilizar protocolos abertos e padronizados nas comunicações. Apesar de alguns protocolos padrão poderem, eventualmente, não serem os mais adequados para tarefas mais críticas, esta escolha permite que uma implementação do modelo seja mais aberta de forma a propiciar maiores facilidades na implementação de novos módulos.
Protocolos dos alvos
Os protocolos utilizados para se realizar a comunicação com os alvos são, na verdade, definidos pelos dispositivos que contêm os alvos. Estes protocolos são, então, dependentes dos fornecedores dos dispositivos, que podem optar por utilizar protocolos padrão ou implementar seus protocolos proprietários. Os protocolos mais comuns encontrados nos alvos são Telnet e SNMP, mas dispositivos mais modernos utilizam HTTP para gerenciamento de configuração, e espera-se que brevemente um número maior de equipamentos suporte também o protocolo COPS. Felizmente os protocolos proprietários são mais raros de serem encontrados.
Apesar da diversidade de possibilidades, os protocolos dos alvos não são uma questão crítica, visto que os elementos intermediários são responsáveis por executar a tradução de protocolos. Assim, quando dois roteadores diferentes, que usam protocolos diferentes, devem ser programados para priorizar um fluxo definido, a tarefa de programação percebe os roteadores diferentes como sendo iguais, devido à tradução de protocolos executada pelos consumidores de políticas associados. Traduções similares também ocorrem nos monitores de QoS e identificadores de alvos.
Protocolos dos elementos intermediários
Os protocolos utilizados para a comunicação com os elementos intermediários devem ser adequados para a realização de algumas operações. Os requisitos para os protocolos de comunicação com os consumidores de políticas são:
1) Permitir a transferência de políticas e notificações do ambiente de gerência para um consumidor de políticas;
2) Permitir a transferência de políticas entre base de políticas e consumidores de políticas;
3) Permitir a notificação do ambiente de gerência sobre problemas decorrentes da implantação de políticas; e
4) Permitir a notificação da base status sobre a implantação de uma política aplicada em um alvo.
As necessidades de notificações apontam principalmente para a utilização de alguma versão do SNMP. Como COPS também possui serviços de notificação, o mesmo também poderia ser utilizado. A transferência de políticas, cujas mensagens são maiores que as mensagens geradas pelas notificações, pode ser realizada por algum protocolo de transferência de arquivos. A opção mais óbvia nesse caso é a utilização de FTP ou HTTP, mas o acesso via LDAP também é uma opção interessante, principalmente se a base de políticas for implementada através de um serviço de diretórios. Este último caso é a tendência apontada pelo IETF, mas esta opção ainda encontra-se em processo de padronização no IETF.
A comunicação com os monitores de QoS apresenta os mesmos requisitos que a comunicação com os consumidores de políticas. Como tal, os mesmos exemplos de protocolos anteriormente citados podem ser utilizados para implementar a comunicação dos monitores de QoS com os outros elementos do modelo (ambiente de gerência e bases de dados).
Os requisitos para a comunicação com os identificadores de alvos são:
1) Permitir a transferência de regras de descoberta do ambiente de gerência para os identificadores de alvos;
2) Permitir a transferência, do ambiente de gerência para os identificadores de alvos, de um grupo de endereços de rede que já são conhecidos, mas necessitam ainda da identificação de suas capacidades em relação aos serviços de fornecimento de QoS;
3) Permitir a transferência, dos identificadores de alvos para a base de associações, do conjunto de alvos descobertos, suas identificações e associações com os dispositivos que contenham tais alvos.
4) Notificar o ambiente de gerência quando um bloco de alvos for descoberto, sendo que um bloco pode ser composto por um ou mais alvos.
As notificações enviadas dos identificadores de alvos para o ambiente de gerência tendem a ser maiores que as notificações geradas pelos consumidores de políticas e monitores de QoS. As notificações dos identificadores de alvos devem descrever blocos de alvos encontrados, e o tamanho de cada bloco pode variar de poucos bytes (por exemplo, se o bloco for constituído de apenas um alvo) até muitos bytes (se o bloco contiver vários alvos). Logo, os mecanismos de notificação do SNMP (ou mecanismos similares como COPS) são menos adequados no caso dos identificadores de alvos. Requisições HTTP utilizando mensagens POST poderiam ser utilizadas. Um identificador de alvos mandaria uma mensagem POST ao ambiente de gerência (que se comportaria como um servidor Web nesta operação) e receberia como resposta uma pequena página de confirmação.
Uma solução ainda possível para o acesso aos elementos intermediários é a utilização de Script MIB [QUI 99]. Tal solução visa a implementação de facilidades para a criação de um ambiente de gerência que opere utilizando a delegação de tarefas a gerentes de rede intermediários (MLM – Mid-Level Managers) [GOL 96]. Como os elementos intermediários do modelo proposto acabam na realidade desempenhando tarefas de gerentes intermediários, a utilização de Script MIB é uma alternativa consistente e interessante. No capítulo 5 será apresentado um exemplo onde Script MIB é utilizada em uma implementação do modelo.
Protocolos das bases de dados
Indiretamente, alguns protocolos para acesso às bases de dados foram citados nos itens anteriores. Neste item, o uso específico de alguns destes protocolos é sugerido e justificado.
Os protocolos utilizados para acessar as informações das bases de dados são diferentes entre si porque a natureza de cada base é também diferente. A base de políticas deveria ser acessada usando-se um serviço de diretórios como o LDAP [STR 2001] (FIGURA 4.1, setas 2, 7 e 12). Visto que as políticas são informações que possuem pouca atualização, mas podem ser acessadas diversas vezes, um protocolo de poucas escritas e muitas leituras como o LDAP é mais adequado.
As informações das bases de status e associações são mais dinâmicas, e o protocolo LDAP, neste caso, deveria ser evitado. Uma implementação possível poderia utiliza as mensagens InformRequest do SNMPv2 [CAS 96] para atualizar as informações de estado (setas 4 e 8). As mensagens InformRequest, de acordo com as definições do IETF, podem ser encaradas como traps SNMP com confirmações. Assim, os monitores de QoS, percebendo uma degradação, podem atualizar a informação de estado de um fluxo ou agregado monitorado notificando a base de status. Os consumidores de políticas podem também notificar a base status quando a implantação de uma política falhar.
A interação com a base de associações acaba tornando-se uma questão mais complicada quando a base implementada não utiliza um protocolo padrão, e isso tende a acontecer porque as associações não podem ser implementadas, por exemplo, utilizando um serviço de diretórios porque os dados da base freqüentemente sofrem alterações. Isso faz com que a base de associações acabe sendo implementada através de bancos de dados de mercado (por exemplo, Oracle [LON 2000] e Sybase [PAN 96]) que não possuem interfaces de comunicação padronizadas. Por fim, o ambiente de gerência e os identificadores de alvos poderiam também ter acesso à base de associações através de HTTP combinado com o uso de um mecanismos de scripts como o PHP4 [PHP 2001] (setas 11 e 14). Isso abstrairia a implementação da base, fornecendo uma interface única de comunicação.
A TABELA 4.2 resume os possíveis protocolos apresentados utilizados na comunicação entre os elementos do modelo. Células marcadas com um X denotam que o protocolo da linha pode ser utilizado na comunicação com o elemento da coluna.
TABELA 4.2 – Protocolos e elementos do modelo
Alvos midores Consu- Monitores cadores Identifi- ciações Asso- Políticas Status
SNMP x x x x -- -- x
HTTP x x x x -- x --
Telnet x x x x -- -- --
COPS -- x -- -- -- -- --
É importante notar que uma implementação do modelo poderia utilizar outros protocolos além dos protocolos discutidos. Entretanto, espera-se que implementações diversas utilizem protocolos que funcionalmente sejam similares aos protocolos sugeridos nesta seção. Por exemplo, na gerência de uma rede ATM, o conjunto de protocolos utilizados pode ser diferente do conjunto anteriormente discutido. Nem por isso, uma rede ATM não poderá implementar uma solução baseada no modelo. A diferença, entretanto, é que a solução ATM utilizará alguns protocolos diferentes, mas funcionalmente similares àqueles aqui sugeridos.