-7- PLATAFORMAS DE SOPORTE PARA APLICACIONES DE GESTIÓN

-7-

PLATAFORMAS DE SOPORTE PARA APLICACIONES DE GESTIÓN

•COMUNICACIÓN ENTRE GESTORES Y AGENTES: MODELO OSI

•SERVICIOS SOPORTADOS POR CMISE

•COMUNICACIÓN ENTRE GESTORES Y AGENTES POR SNMP

•SNMP VS CMIP

•INTERTRABAJO CMIP/SNMP POR PODER (PROXI)

•ARQUITECTURA DE GESTIÓN DISTRIBUIDA

•CORBA

•INTER-OPERABILIDAD E INTEGRACIÓN CON CORBA

•ARQUITECTURAS DE GESTIÓN BASADAS EN WEB

•VISIÓN DE LUCENT

COMUNICACIÓN ENTRE GESTORES Y AGENTES (I) : Modelo OSI

SISTEMA GESTIONADOR SISTEMA GESTIONADO

RED DE COMUNICACIONES

GESTOR FUNCIONES GESTIONADAS AGENTE

Unidades de Datos de Protocolo(PDU) CMIP

ISO 9596 CMISE (GESTOR)ISO9595

ROSE

Presentación(ASN1,BER)

SESIÓN

ACSE

Transporte Red

Enlace datos

Física

CMISE (AGENTE)ISO9595

ROSE

Presentación(ASN1,BER)

SESIÓN

ACSE

Transporte Red

Enlace datos

Física

RFC 1006

TCP IP Red de

acceso

RFC 1006

TCP IP Red de

acceso

Reglas de Codificación Básicas

CMIS

FUENTE MANU MALEK

Proceso de Aplicación SMAE

CMISE ROSE SMASE ACSE

Las aplicaciones se definen en la capa 7 así:

•SMAE: System Management Application Entity

•ASE: Application Service Elements

•ACSE: Association Control Service Element

•SMASE:System Management Application Service Element

•CMISE: Common Management Information Service Element

(equivalente al SNMP de TCP/IP),

(soporta varios servicios de gestión de información comunes (CMIS) y el protocolo asociado de comunicaciones es (CMIP))

•ROSE: Remote Operation Service Element

FUENTE: Halsall 13.2.4 SMAE pag. 828

COMUNICACIÓN ENTRE GESTORES Y AGENTES (II): Modelo OSI

COMUNICACIÓN ENTRE GESTORES Y AGENTES (III): Modelo OSI Ejemplo: G784 para la interfase de mensajes de control y gestión de elementos de red en SDH:

Capa OSI función Recomendación ITU-T o estándar ISO

7 Aplicación CMISE-ISO 9595

ACSE –X217, X227 ROSE –X219, X229 6 Presentación X216, X226

5 Sesión X215, X225

4 Transporte X214, X224, ISO 8073

3 Red Control de red

embebido SDH ISO 8473

Red

pública de paquetes X.25

LAN

ISO 8473

2 Enlace Suministrada por el cliente la capa de red

X710 SERVICIOS SOPORTADOS POR CMISE (I):

M-GET: permite a un gestor leer atributos de objetos gestionados

M-SET: permite a un gestor remplazar los valores de los atributos por valores nuevos M-EVENT-REPORT: permite a un agente transferir la notificación emitida por un

objeto gestionado

M-ACTION: permite a un gestor pedir que un objeto gestionado realice una acción

M-CREATE: permite a un gestor pedir crear una manifestación de un objeto gestionado M-DELETE: permite a un gestor borrar una manifestación de un objeto gestionado

M-CANCEL-GET: permite a un gestor abortar una operación de lectura

Tambien se permite :que una única petición se extienda a un conjunto de objetos, por : elección de un sub-árbol de una jerarquía de nombres (delimitación) y en forma selectiva con criterio de filtrado.

El criterio de la sincronización de la información puede ser: “atómico”, o

“de mejor esfuerzo”

X 710 SERVICIOS SOPORTADOS POR CMISE (II):

M-GET: C

M-SET: C/NC

M-EVENT-REPORT:

M-ACTION: C/NC

M-CREATE: C

M-DELETE: C

M-CANCEL-GET: C

Forma del diálogo:

C modo confirmado, se espera una respuesta.

NC modo no confirmado, no se espera una respuesta

COMUNICACIÓN ENTRE GESTORES Y AGENTES POR

SNMP (I)

(PROTOCOLO GESTIÓN DE RED SIMPLE)

GESTOR AGENTE

SISTEMA GESTIONADOR SISTEMA GESTIONADO

FUNCIONES GESTIONADAS

SNMP (GESTOR) UDP

IP

ACCESO DE RED (Ej.: X25)

SNMP (AGENTE) UDP

IP

ACCESO DE RED (Ej.: X25)

SNMP PDUs

RED DE COMUNICACIONES (Ej.: X25)

PROTOCOL DATA UNIT

FUENTE MANU MALEK

COMUNICACIÓN ENTRE GESTORES Y AGENTES POR

SNMP (II)

GESTOR SNMP

AGENTE SNMP

GetRequest GestResponse GetNextRequest Trap

SetRequest

Tiene Cinco mensajes de Unidades de Datos de Protocolos (PDUs) Releva por

“polling”

los datos

Es responsable por el filtrado de los datos

•SNMP fue originalmente diseñado para gestionar Routers y Bridges en redes TCP/IP

•Es simple pero ineficiente

•No provee mecanismos de seguridad de autenticación y control de acceso

•Restringe el tamaño máximo de los mensajes

COMUNICACIÓN ENTRE GESTORES Y AGENTES POR

SNMPv2 (III)

GetRequest GestResponse GetNextRequest Trap

SetRequest

GetBulkRequest GestBulkResponse InformRequest

InformRequestRespo nse

AGENTE GESTOR

GESTOR

PERMITE COMUNICACIÓN GESTOR-GESTOR

PERMITE A UN

MENSAJE ACCEDER A MÚLTIPLES

OBJETOS EN UNA MIB

AGREGA ASUNTOS DE SEGURIDAD:

Data Encryption Standard (DES) para proteger los mensajes

Usa el algoritmo Message Digest (MD5) para

Autenticación

Control de acceso para los permisos de lectura escritura de algunas vistas de MIBs específicas

SNMP vs CMIP

Area SNMP CMIP

Aplicación

Basado en “polling”

Soporta requerimientos de items de datos simples

Soporta un subgrupo de los tipos ASN.1

Aplicaciones Interactivas

Aplicaciones orientadas al archivo

Aplicaciones de guardar y enviar

Soporta todos los tipos ASN.1

MIB

MIB estática, requiere múltiples instancias para sistemas compatibles

MIB dinámicas proveen medios explícitos de representar relaciones

Aplicabilidad/

extensibilidad

Adecuado para componentes acoplados débilmente

Poco extensible

Adecuado para objetos complejos de conmutación

Básicamente extensible.

Costo

Pocos insumos para la primer aplicación

Costosas MIBs adicionales

Costosa la primera aplicación

Bajo costo incremental para agregar objetos.

INTERTRABAJO CMIP/SNMP Gestión Por Poder (PROXY)

MIB GDMO

CMISE Servicios CMIS

PROXY

SNMP APLICACIONES

GESTIONADORAS GESTOR

ISO/ITU

MIB GDMO

CMISE Servicios CMIS

GESTOR

RECURSOS GESTIONADOS

MIB INTERNET

AGENTE INTERNET

Servicios SNMP

AGENTE

SNMP Servicios

SNMP MIB INTERNET

EMULACIÓN DE SERVICIO

(ALCANCE) (FILTRADO) (OPERACIONES)

(TRANSFERENCIA DE MENSAJES)

MENSAJES CMIP MENSAJES SNMP

FUENTE MANU MALEK y NMF (TMForum)

ARQUITECTURA DE GESTIÓN DISTRIBUÍDA (OMA) (I)

•EL GRUPO DE GESTIÓN OBJETO (OMG) se formó en 1989 para:

direccionar los problemas de desarrollar aplicaciones distribuidas, portables, para sistemas heterogéneos.

•Hoy lo forman 800miembros.

•La especificación llave es la OMA y su núcleo es la especificación CORBA (Common Object Request Broker Architecture).

•OMA usa 2 modelos relacionados para describir como objetos distribuidos y las interacciones entre ellos, pueden ser

especificados por caminos independientes de las plataformas:

-El Modelo Objeto

-El Modelo de Referencia

-El Modelo Objeto define como las interfaces de los objetos se

distribuyen a través de ambientes heterogéneos. Para ello define un objeto como una entidad encapsulada con identidad distintiva

inmutable cuyo servicio es accedido sólo a través de interfaces bien definidas, y cuyos detalles de implementación y su localización se mantienen ocultos a los clientes.

-El Modelo de Referencia: caracteriza las interacciones entre los Objetos (Provee categorías de interfaces enganchadas entre sí por Objects Request Broker).

ARQUITECTURA DE GESTIÓN DISTRIBUÍDA (OMA) (II)

OBJECT REQUEST BROKER (ORB) INTERFACES

DE APLICACIÓN

SERVICIOS OBJETO

INTERFACES DE DOMINIO

CORBA (Common Object Request Broker Architecture)

IDL Interface Definition Language ORB Object Request Broker

FUENTE: OMG

INTERFACES:

PRIVADA DE ORB

PUEDE SER ADAPTADORA A MÚLTIPLES OBJETOS

IDÉNTICA PARA TODAS LAS IMPLEMENTACIONES ORBs ESPECÍFICA DE CABOS Y ESQUELETOS

NUCLEO ORB

ADAPTADOR DE OBJETO

INTERFAZ DE ESQUELETO

DINÁMICA

(DSI)

INTERFAZ DE DEFINICIÓN DE

LENGUAJE

(IDL)

DE ESQUELETO

INTERFAZ DE INVOCACIÓN

DINÁMICA

(DII)

STUB (CABOS)

IDL

INTERFAZ ORB

CLIENTE IMPLEMENTACIÓN

DEL OBJETO

IN ARG. (operaciones) OUT ARG+VALORES

FUENTE: Douglas Schmidt---

University of California , Irvine

ARQUITECTURA de INTER-OPERABILIDAD del protocolo CORBA

ATM DRIVER

IP

CAPA DE RED

AAL5

CONFIABLE

VME

TCP

CAPA DE TRANSPORTE

ATM-IOP

SECUENCIA

VME-IOP IIOP

COMPONENTE ADAPTADOR DE TRANSPORTE

ORB

ESIOP GIOPlite

COMPONENTE DE MENSAJE

GIOP

ORB

API DE PROGRAMACIÓN CORBA ESTÁNDARD

CONFIGURACIONES DE PROTOCOLOS

GIOP General InterOperability Protocol

ESIOP Environment-Specific Inter-ORB Protocol IIOP Internet Inter-ORB Protocol

IOP Inter-ORB Protocol

IOR Interoperable Object Reference

Ejemplo: TRANSACCIÓN EN CORBA

FUENTE :

Deeper Inside Corba Services Max Dolgicer

CORBA 2.0

DBMS OBJETO A OBJETO B DBMS

OTS

1 2

3

4

5

6 6

1- OBJETO A COMIENZA LA TRANSACCIÓN 2- OBJETO A ACTUALIZA SU BASE DE DATOS 3- OBJETO A INVOCA AL OBJETO B

4- OBJETO B ACTUALIZA SU BASE DE DATOS 5- OBJETO A COMPROMETE LA TRANSACCIÓN 6- EL SERVICIO DE TRANSACCIÓN OBJETO (OTS) COORDINA LO COMPROMETIDO EN DOS FASES

INTEGRACIÓN DE LA TECNOLOGÍA CON CORBA

FUENTE: WADE-LEWIS TRINITY COLLEGE DUBLIN ACCESO DEL STAFF OPERACIONAL O EL CLIENTE

CONTROL DE LOS RECURSOS DE RED POR PARTE DEL

PROCESO DEL NEGOCIO

ARQUITECTURAS DE GESTIÓN BASADAS EN WEB (I)

•

•

FUENTE:Integrated Management of Networked Systems Hegering-Abeck-Neumair

JMAPI

•Separa la gestión en 2 componentes: la consola de gestión (cliente) y la plataforma (servidor)

•La plataforma:

Formada por una estructura núcleo gestionadora de objetos que permite a la aplicación coordinar la creación, manipulación, y eliminación de un objeto gestionado

Incorpora interfaces para:

•Base de datos (JDBC)

•Comunicación con agentes implementados en JAVA con Remote Method Invocation (RMI)

•Comunicación con agentes implementados en SNMP para acceder a Management Information Base (MIB) de Internet

•La consola de gestión:

Provee un ambiente operacional de aplicaciones que son los Java Applets, permite Comunicación con la plataforma y con la librería de clases :

Módulo de Visión de Administración (AVM) que ofrece mecanismos de coordinación e integración para diferentes aplicaciones rodando al mismo tiempo en la consola.

Las aplicaciones son agentes de gestión Java [Interfaz de Programación de Aplicación (API)] , también es posible acceder a los agentes SNMP

El Modelo Objeto JMAPI es un refinamiento del modelo de objetos Java.

Despachadores de eventos en AGENTES Java transmiten notificaciones de eventos , hay

ARQUITECTURAS DE GESTIÓN BASADAS EN WEB (II)

ARQUITECTURAS DE GESTIÓN BASADAS EN WEB (II)

WBEM

El objetivo fue desarrollar una arquitectura para la Gestión : abierta, neutral a los vendedores, distribuida, basada en WEB, para cubrir una empresa por entero.

La nueva arquitectura se llamó Gestión de hipermedia (HMM) y se pensó que cubra como paraguas a todas las aproximaciones a la gestión.

Los elementos centrales a la arquitectura de tecnología de WEB fueron:

•browsers de Web y

•protocolos de gestión basados en HTTP luego transformado en Protocolo de gestión de hipermedia (HMMP) y abandonado.

Actualmente los componentes de la arquitectura son:

-CIM (el Modelo de Información Común) modelo para la descripción de la información de gestión

-MOF (Formato de Objeto Gestionado) una especificación de sintaxis -XML (Lenguaje Aumentado Extensible) ) La gramática usada se llama:

Definición de Tipo de Documento(DTD) En el nuevo emprendimiento se mapea el CIM con el XM, éste se usa para representar clases e instancias, esto permite que cualquier browser que lleve el XML pueda ser usado para ver y manejar la información de gestión

No se usa protocolo de gestión especializado alcanza con HTTP para transferir información.

VISIÓN DE LUCENT DEL

MARCO DE TRABAJO TÉCNICO (I)

FUENTE: Bell Labs Technical Journal 4Q2000

VISIÓN DE LUCENT DEL

MARCO DE TRABAJO TÉCNICO (II)

FUENTE:

Bell Labs

Technical Journal 4Q2000

CONCLUSIONES:

-Comunicación entre gestores y agentes CMISE-CMIP, SNMP -Inter-trabajo y comparación entre SNMP y CMIP

-Plataformas de gestión distribuidas abiertas CORBA, DCOM, DPE -Integración e Inter-operabilidad con CORBA

-Arquitecturas de gestión basadas en WEB: JMAPI, WBEM -Otras arquitecturas de gestión: EJB

-Modelo de Lucent