1. CMIP - Common Management Information Protocol


Enquanto o CMIS define os serviços para operações de gerenciamento, o CMIP define procedures para a transmissão de informações de gerenciamento e define a sintaxe para o serviço de gerenciamento do CMIS. O CMIP é definido em termos de unidades de dados do protocolo CMIP que são trocadas entre iguais CMISEs levando do serviço CMIS.


1.1. Operação do CMIP

Para entender a operação do CMIP, precisamos vê-lo no contexto com o uso do serviço CMISE e os serviços em que o CMISE confia. O CMIS preve sete serviços para executar operações de gerenciamento, na forma de primitivas de serviço. Em adição, os usuários do CMISE são capazes de estabelecer associações ordenadas para executar operações de gerenciamento. Estes últimos serviços são providos pelo ACSE e são providos pelo CMISE como uma pass-through; o CMIP aqui não é envolvido. Para os serviços de operação de gerenciamento, o CMISE emprega um CMIP para trocar PDUs. O CMIP confia nos serviços do ROSE. Ambos ACSE e ROSE confiam no serviço de apresentação.

As 11 PDUs que o CMIP utiliza:

  • m-EventReport
  • m-EventReport-Confirmed
  • m-Get
  • m-Linked-Reply
  • m-Set
  • m-Set-Confirmed
  • m-Action
  • m-Action-Confirmed
  • m-Create
  • m-Detete
  • m-Cancel-Get-Confirmed
  • Nesse ponto são levantadas três tipos de informação conduzidas pelas unidades de dados. Os argumentos da entrada definem os argumentos , ou parâmetros, conduzidos na unidade de dados que são derivados da primitiva de serviço do CMISE disparador. Os resultados e erros de entrada contém informações da entidade que está executando o resultado da operação de gerenciamento de sistemas. Estes valores são derivados da primitiva response do CMISE.

    A unidade de dados do CMIP inclui um parâmetro linked-Id, em ordem, para múltiplas respostas de link causadas pela operação invocada.

    Como um exemplo do uso do CMIP para implementar um serviço CMIS, a seguinte seqüência de eventos ocorre:

    1. Uma primitiva M-GET.request é recebida do usuário CMISE. Os parâmetros na primitiva distingue esta operação de outras suportadas pelo CMISE, prove informação sobre o objeto gerenciado, e prove outras informações relevantes. O request é manuseado pela máquina do protocolo de informação de gerenciamneto comum (CMIPM).
    2. O CMIPM constrói uma unidade de dados do protocolo de aplicação (APDU) m-Get que contém os parâmetros na primitiva M-GET.request.
    3. O CMIPM usa o serviço RO-INVOKE.request do ROSE para enviar a APDU para o destinatário.
    4. O ROSE transmite a APDU para a CMIPM que estiver respondendo em um RO-INVOKE.indication.
    5. Se a unidade de dados é aceitável, o CMIPM emite um M-GET.indication para o usuário CMISE destinatário, contendo os parâmetros da primitiva request original. Isto é igual ao serviço usado para executar a operação GT requisitada e reportar o resultado.
    6. O usuário CMISE que está respondendo emite uma primitiva M-GET.response para o CMIPM que estiver respondendo. O parâmetro na primitiva distingue esta operação de outras suportadas pelo CMISE, prove a informação requisitada do objeto gerenciado, e prove outra relevante informação. Se esta operação falha, a primitiva inclui um parâmetro de erro para descrever a natureza do erro.
    7. O CMIPM que estiver respondendo contrói uma APDU m-Get que contém os parâmetros na primitiva M-GET.response.
    8. Se a operação é executada com sucesso, o CMIPM usa o RO-RESULT.request do ROSE para enviar a APDU de volta para o sistema que iniciou a operação.
    9. O ROSE transmite a APDU para o CMIPM que iniciador em uma RO-RESULT.indication.
    10. O CMIPM emite um M-GET.confirmation para o usuário CMISE iniciador.

    1.2. O uso do ROSE

    O CMIP faz uso do ROSE para transferir PDUs CMIP. As seguintes regras são aplicadas para o uso do ROSE:

    1. O CMIP sempre usa a associação Classe 3 do ROSE. Ambas a associação iniciadora e a associação de resposta podem invocar operações.

    2. Para confirmar operações CMIP, o CMIP faz uso da operação classe 1 ou classe 2 do ROSE. Que é, no modo reportado é retornado um resultado para sucesso ou falha, e o modo de operação pode ser síncrono (o invoker requer uma resposta antes de invocar outra operação) ou assíncrono (o invoker pode invocar mais operações sem aguardar uma resposta). A escolha da classe de operação é uma importância local.

    3. Para não confirmações de operações CMIS, a classe 5 de operação do ROSE é usada (não responde, operação assíncrona).


    2. Emissões Práticas

    2.1. Performance

    Três competentes requerimentos para um sistema de gerenciamento de redes podem ser especificados:

    1. Não deve rebaixar a operação de rede.
    2. Decisões e ações devem ser feitas rapidamente antes que as condições da rede mudem significativamente.
    3. Devem prover um conjunto de serviços para manusear umem extenso escopo de funções de gerenciamento de redes e prover um monitoramento e controle detalhado.

    2.2. Arquitetura do protocolo

    O documento de estrutura de gerenciamento OSI, ISO 7498-4, faz as seguintes declarações sobre suporte para gerenciamento OSI:

    1. Um sistema aberto deve ter suficiente funcionalidade em todas as sete camadas para suportar uma aplicação de gerenciamento antes que a aplicação possa ser acessada por outro sistema.

    2. Quando a suficiente funcionalidade das sete camadas não existir, o gerenciamento da camada pode ser empregado entre sistemas abertos se o suporte para essas camadas é provido.

    Consideremos o segundo ponto primeiro. Este diz que entidades de gerenciamento de camadas podem transferir informações de gerenciamento diretamente entre iguais sem empregar a camada de aplicação, incluindo o CMIS, para a transferência de qualquer informação. Esta aproximação poderá ser empregado m segmentos de redes locais para reduzir o overhead. Esta capacidade também soma robustez para o design.

    O outro ponto é talvez o mais importante. Neste ponto são dois os interesses:

    1. É desejável executar aplicações de gerenciamento de redes sobre sistemas intermediários , como bridges e roteadores, sem requerer estes serviços para implementar uma arquitetura de sete camadas full-blown.
    2. Igualmente sobre fim de sistemas sem suporte OSI, deve ser desejável produzir a camada mais baixa como possibilitar reduzir processamento e comunicações de overhead.