 | |
REDESII | | |
 Primitivas CMIS
-
m-EventReport.- Notifica un evento de manera asíncrona.
-
m-EventReport-Confirmed.
-
m-Get.- Obtiene información de un objeto gestionado.
-
m-Set.- Modifica la información contenida en un OG.
-
m-Set-Confirmed.
-
m-Action. Invoca una operación sobre un objeto gestionado.
-
m-Action-Confirmed.
-
m-Create. Crea un nuevo objeto gestionado de una clase determinada.
-
m-Delete. Elimina un OG.
-
m-Cancel-Get- Cancela una petición M-Get previa.
La operación de los servicios de gestión requiere el uso de ROSE.
Soporte ACSE y ROSE
ACSE El establecimiento de la conexión agente/gestor se realiza mediante ACSE, negociándose durante
el mismo las
unidades funcionales de CMIS que se van a utilizar (aquellas que ambos sean capaces de soportar).
ROSE Se usa asociación ROSE clase 3 (ambos extremos pueden invocar operaciones)
Para operaciones confirmadas, se utilizan operaciones clase 1 o 2. Ambos retornan respuesta y el modo
puede ser síncrono
(cada petición debe esperar a la respuesta del anterior) o asíncrono (puede haber varias peticiones
pendientes).
Para operaciones no confirmadas, clase 5 (sin respuesta, asíncrono).
La arquitectura de gestión OSI define un objeto gestionable como la interfaz conceptual que han de presentar
los
dispositivos que ofrecen funciones de gestión. El proceso de supervisión y control de un objeto gestionable
se realiza
mediante una serie de interacciones. Estas interacciones son de dos tipos:
v De operación: el gestor solicita algún dato al objeto gestionable o desea realizar alguna acción sobre
él.
v De notificación: cuando el objeto gestionable intenta enviar algún dato al gestor como consecuencia
de algún evento
ocurrido en el dispositivo.
Un objeto gestionable se caracteriza además por un conjunto de atributos que son las propiedades o características
del
objeto, y un comportamiento en respuesta a las operaciones solicitadas.
En la siguiente figura se presenta un ejemplo de estas interacciones.
La comunicación entre el gestor y el objeto gestionable no es directa, se realiza mediante un intermediario:
el agente
de gestión (esto se corresponde con un modelo centralizado gestor-agente). La función del agente es
controlar el flujo de
información de gestión entre el gestor y el objeto. Este control lo realiza comprobando una serie de
reglas de gestión (por
ejemplo que el gestor tenga la capacidad para solicitar una determinada operación), que han de cumplirse
para poder
realizar la operación. Estas reglas se incluyen en los datos como parte de la solicitud de una operación.
El flujo normal de información de gestión y control entre el gestor y el agente se realiza mediante
el protocolo CMIP,
perteneciente al nivel de aplicación OSI.
El protocolo permite que un sistema se pueda configurar para que opere como gestor o como agente.
La mayoría de las
realizaciones prácticas de sistemas gestionados se configuran con unos pocos sistemas operando en modo
gestor,
controlando las actividades de un gran número de sistemas operando en modo agente.
Comparación SNMP/CMIP A continuación se hace una comparación entre los protocolos SNMIP y CMIP:
SNMP está basado en técnicas de sondeo, mientras que CMIP utiliza una técnica basada en eventos. Esto
permite a CMIP
ser más eficiente que SNMP en el control de grandes redes.
CMIP es un protocolo orientado a conexión mientras que SNMP es un protocolo sin conexión. Esto significa
que la carga
de proceso de SNMP es reducida, pero cuando se envía un mensaje nunca se puede asegurar que el mensaje
llega a su
destino. La seguridad de los datos no es prioritaria para SNMP.
CMIP permite la implementación de comandos condicionales sofisticados, mientras que SNMP necesita el
nombre de cada
objeto.
CMIP permite, mediante una única petición, la recogida de gran cantidad de datos de los objetos gestionables,
enviando
información de retorno en múltiples respuestas. Esto no está permitido en SNMP.
CMIP está especialmente preparado para gestionar grandes redes distribuidas, mientras que SNMP está
recomendado para
la gestión inter-red.
CMIP realiza una distinción clara entre los objetos y sus atributos. SNMP no permite esto, lo cual hace
imposible la
reutilización de atributos y definiciones.
En el caso de CMIP se han planteado dos aproximaciones posibles:
La estrategia de pasarela, similar a la seguida en el caso anterior y que consiste en mapear cada objeto
del modelo CMIP
(GDMO) y cada operación dentro del entorno CORBA. La desventaja de esta aproximación radica en que,
al existir una
correspondencia uno a uno entre uno y otro entorno, no se obtiene ningún valor añadido de la integración.
La aproximación mediante la definición de objetos abstractos. En este caso, un grupo de objetos del
entorno CMIP se
mapea mediante un único objeto CORBA, el cual representa entidades de gestión de nivel superior. Mediante
este modelo
se saca el mejor partido de ambas tecnologías.
CORBA también se perfila como alternativa de implantación de los objetos de nivel de servicio del modelo
TMN, todavía
por definir.
| 
