El modelo de gestión de red 051
Equilibrar las responsabilidades de los agentes y plataformas de interconexión de sistemas abiertos - y sus
protocolos de interacción - es complejo, pero OSI ayuda por las funciones que ofrecen carecen de SNMP de
Internet.
Yechiam yemení
YECmAM yemini es un miembro del
Departamento de Ciencias de la Computación
de la Universidad de Columbia, donde sirve
presendy como el director del Centro de
Tecnología Avanzada del Estado de Nueva
York en los sistemas informáticos y de
información.
20
aquí fueron dramáticos cambios en la estructura
y función de sys TEMS en red dentro de las
empresas en la última década. A partir de los
datos aislados-ing proceso de islas, TEMS
informáticos en red sys han convertido en
complejo
sistemas de toda la empresa de misión crítica. El trabajo de la red, el
ordenador, y la propia empresa rápidamente se están convirtiendo en
indistinguibles. Estos cambios conducen a importantes riesgos y costos
Expo seguro asociado a las operaciones. Por ejemplo, los fallos de una red
bancaria pueden paralizar sus Func, los retrasos de las operaciones de
seguridad a través de los cuellos de botella del sistema de corretaje pueden
Costin dólares y los clientes, y la pérdida de los informes de laboratorio del
hospital pueden prevenir el diagnóstico y la atención oportuna. El objetivo de
la red de gestión de las tecnologías Ment es reducir los riesgos y los costos
asociados con la exposición de las operaciones de sistemas de la empresa.
Los sistemas de gestión son responsables de moni tor, interpretar y
controlar los Func red. Un sistema de gestión típica se representa en la Fig.
1. Los vendedores equipan sus dispositivos con el software de agente para
controlar y recopilar los datos operativos (por ejemplo, las estadísticas de
error) en bases de datos locales, y / o detectar eventos excepcionales (por
ejemplo, tasas de error exceden del umbral). estaciones de trabajo de la
plataforma de gestión de consulta de datos del dispositivo, o para obtener
notificaciones de eventos a través de protocolos de gestión. La gestionar
Ment herramientas compatible con la plataforma para mostrar los datos
gráficamente, lo interpretan, y las operaciones de control.
Este paradigma de gestión es platfonn centrado.
aplicaciones de gestión están centralizados en formas Plat,
separados de los datos gestionados y funciones de control en los
dispositivos. Plataforma-Cen gestión cados refleja más edad am-
ENVI red donde los dispositivos carecen de recursos para ejecutar
el software de gestión, los datos y las funciones de gestión eran
relativamente simples, y las organizaciones de la red podrían
destinar el personal necesario para las operaciones de la manija.
Las implicaciones ofthese ciones assump y su validez para las redes
actuales serán consideradas más adelante.
0163-6804 / 93/1993 $ 03.00 © IEEE
El principal reto de la gestión ización estándar es desarrollar
convenciones para apoyar la gestión inte rallada de redes heterogéneas.
-Centrados plataforma de gestión requiere unos pocos nor mas. En
primer lugar, el acceso de las plataformas de dispositivos de múltiples
proveedores debe ser unificada a través de un protocolo de hombre
agement estándar. En segundo lugar, las bases de datos de gestión del
agente deEl estructura, manipulados por el pro tocolo, deben
normalizarse. En conjunto, estas normas permiten una plataforma para
el acceso y la información gestionada Ulate manip en agentes de
dispositivos de múltiples proveedores. Los els mod gestión OSI e
Internet buscan estandarizar las dos áreas.
en movimiento meramente la información de gestión de dispositivos a
las plataformas, sin embargo, es insuficiente para Elim inate la maldición de
la heterogeneidad. Dos rreras de barras adicionales para la gestión integrada
surgen: plataforma y la heterogeneidad semántica.
medios de heterogeneidad plataforma de aplicaciones de gestión que
debe replicarse para cada plataforma importante. Por ejemplo, un
vendedor de dispositivo que desee ofrecer seis aplicaciones a través de
cinco plataformas pueden necesitar para desarrollar y mantener
30productversions. No tanto, una serie de consorcios reciente (por
ejemplo, OSF, XOPEN, POSIX) están llevando a cabo estándares de la
plataforma de gestión.
la heterogeneidad semántica surge cuando se utilizan
diferentes dispositivos de información diferente para representar
comportamientos de red similares. Un programa de gestión de apli
cación requiere un modelo semántico uniforme de la información
gestionada que procesa. Es necesario estandarizar el significado de
la información gestionada. Varios comités de IEEE y CCITT
protocolo persiguen este reto, la creación de normas de información
gestionados por lazos protocolo enti.
¿Por qué es difícil de Gestión?
C onsidere
complejidades dede
un ejemplo gestión
una redtrar. Las tormentas
de "tormenta" que implican una
para ilus
rápida escalada de la cascada de fallos no son infrecuentes en las
redes. La Figura 2 representa
IEEE Communications Magazine · Mayo de 1993
 Plataforma de gestión

Protocolo de administración

Sistema de Computación de red de la empresa

• Higo u re 1. Arquitectura de un sistema de gestión de red.

un T11inkmultiplexing un gran número de conexiones (por ejemplo, circuitos

virtuales X.25 o TCP) a una serverlhost. Supongamos que una ráfaga larga
de ruido interrumpe el enlace causando la pérdida de paquetes (Fig. 2a). los
protocolos de nivel de enlace lógico (por encima de la capa física) de (C)

invocación automática de retransmisión matic. Dan lugar a una explosión de

tareas de misión retrans en la cola del procesador de interfaz (Fig. 2b)
cargar su cola y que conduce a su thrashing. Superior entidades de nivel de
transporte tiempo de espera y responder con una explosión de activi dades (retransmisiones b)

correctivas (por ejemplo, conexiones de reset). Este procesamiento ráfaga

de comunicaciones en CPUs anfitrión (Fig. 2c) conduce a su thrashing,
también. Servidor

=== 0
Generalmente, los mecanismos de pila de protocolo manejar los Interfaz 0 O pérdida de tramas (a)
problemas de capa inferior a través de acciones correctivas en las capas
superiores. Estos mecanismos pueden escalar los mismos problemas que
pretenden resolver.
¿Cómo se pueden monitorizar IORS tales Behav fallo de red • Higo u re 2. Formación de una tormenta de red.

compleja, detectan y manejan? SUP pose que variables operativas

pertinentes (por ejemplo, T1 bit-error tarifas y el tamaño de la interfaz
de pro cesador cola) pueden ser observados como se representa en la
Fig. 3. La formación de tormentas se pudo detectar a partir de la
correlación de la repentina crecimiento de las tasas de error y el
crecimiento resultante en tamaño de la cola.

¿Qué información de gestión debe ser usado para capturar estos

comportamientos? El protocolo simple de administración de redes
(SNMP) utiliza el modelo pastel asim para la estructura de infor
mación administrado (SMI) [2] que participan seis tipos de datos
definidos por la aplicación y tres genéricos.

comportamientos temporales se describen en términos de contadores y

medidores. Un contador de error representa los errores acumulativos
(integral) desde el arranque de dispositivo (el área bajo la curva de tasa de
error en la Fig. 3). Un indicador puede modelar la longitud de la cola. Los
valores de estas variables gestionadas pueden ser registro ed en la base de
un agente de información de gestión (MIB) [3], donde pueden ser
consultados por una plataforma. Un contador de errores, sin embargo, no es
útil para detectar cambios rápidos en las tasas de error para identificar una
tormenta. Una plataforma debe probar el contador de frecuencia para esti
aparean su segunda derivada, lo que lleva a tasas de votación poco
realistas.
gestión OSI utiliza un modelo -oriented objeto de información
gestionada [9, 10]. Los comportamientos de interés: el ruido, errores, y
la longitud de la cola son dif rentes formas de una serie de tiempo. Un
genérico lograron
• Higo u re 3. comportamientos temporal de correlación.
objeto de la clase (MO) se puede definir para describir una serie de
tiempo general. Este MO puede incluir los atributos de datos de la serie
temporal y operaciones (métodos, acciones) para calcular las funciones
de la serie temporal (por ejemplo, derivados). Este MO también puede pro
vide eventos genéricos notificaciones (por ejemplo, cada vez que algunas
series función oftime excede del umbral). El ic clase serie MO tiempo
gener puede ser especializado para definir subclases MO para modelar la
tasa de error de bit de la Tllink y la longitud de la cola del procesador cara
inter. Una plataforma de gestión puede Cre instancias de estos OMs
comió, dentro de bases de datos de agentes de dispositivos. El agente del
dispositivo puede monitorear los comportamientos de la red respectives y
registrar la respectiva

IEEE Communications Magazine · Mayo de 1993 21

OSI
árbol de información de gestión
ciones de gestión
COMMUNICA
requieren de CMIP: Crear / Eliminar
Get / Set / Acción
transporte orientado a
conexión y se basan
en la capa de
aplicación theOSI
ambiente.
• Higo u re 4. arquitectura general de un sistema operativo! sistema de gestión.
valores en estos M 0 instancias. Además, la forma plat puede inscribirse
con el agente para recibir notification ciones de eventos que describen los
cambios rápidos de las tasas de error y cola del procesador excesiva.
Para identificar una tormenta, es necesario detectar no
sólo la tasa de errores y la interfaz de colas de eventos de
umbral, sino identificar la correlación entre ellos. tunate
Unfor? Y, los procesos de observación utilizados para la
detección de eventos puede resultar en la descorrelación de
IORS Behav. excesos de umbral deben sostenerse sobre la
ventana suficiente para dar lugar a la notificación de eventos
y evitar alarmas falsas. La implementación puede usar
diferentes tasas de muestreo y dows Gana de detección para
la tasa de error y longitud de la cola. Por lo tanto, cualquiera
de los eventos se pueden detectar por separado, o los
eventos se pueden detectar en orden temporal invertida.
Este efecto descorrelación de observaciones puede conducir
a ERRO interpretación nea. A menudo, cientos o miles de
alerta pueden ser generados por un fallo. Estos eventos
deben ser correlacionados para detectar la fuente del
problema.
Para empeorar las cosas, los dispositivos que intervienen en la
formación de tormentas se fabrican típicamente por diferentes
proveedores. Los datos administrados y su significado mayvary mucho
entre los dispositivos, lo que hace difícil su interpretación. Además, las
redes a menudo son operados por múltiples organizaciones, cada sible
respon para un dominio diferente. Fallos escalada a través de tales
límites del dominio pueden ser particularmente Cultto difi detectar y
mango. En el ejemplo, los Tllinks pueden ser gestionados por una
compañía telefónica mientras que las capas de arriba son operados por
una organización de usuarios. El usuario puede no ser capaz de observar
el comportamiento de la Tllayer y la compañía telefónica puede
22
Token Ring
no ser capaz de observar el comportamiento de las capas superiores.
051 Modelo de Gestión de Información
general
T modelo
Fig. 4. Lade gestión que
plataforma OSI [5]
de gestión dese
losrepresenta en del protocolo de
usos izquierda
información de gestión común (CMIP) para acceder a la información
gestionada, proporcionado por un agente que reside en un centro de LAN a
la derecha. El agente mantiene una base de datos de árbol de información
de gestión (MIT). Los modelos del MIT un concentrador usando OMs para
representar las LAN, las interfaces y los puertos. Una plataforma puede
utilizar CMIP para crear, eliminar, recuperar o OM cambio en el MIT;
invocar acciones; o recibir notificaciones de eventos.
El MIT contiene casos de OM organizados en un árbol
jerárquico de base de datos, similar a la
directorio X.500 árbol [12]. instancia Un MO incluye atributos que
sirven como su nombre distintivo relativo (RDN). El RDN atributos
identifican de forma única la instancia entre los hermanos de su
padre MIT. En el ejemplo de cubo de la Fig. 4, un número
tificación puerto iden se puede usar como el RDN para identificar
los puertos de A dado interfaz MO. Por RDN con catenating a lo
largo de la trayectoria de MIT de la raíz a un nodo dado, se
obtiene un nombre distintivo único (DN). Este DN es utilizado por
CMIP para identificar un nodo y acceder a la información
gestionada.
En contraste con SNMP MIB, el MIT es una base de datos dinám ic
a. SNMP también utiliza un árbol [3] para almacenar información
gestionada. Sin embargo, la estructura de la MIB es estática y se
determina en su tiempo de diseño. CMIP proporciona Crear / primitivas
Eliminar para cambiar el MIT dinámicamente. Una base de datos
dinámica
IEEE Communications Magazine · Mayo de 1993
 operaciones Los objetos gestionados
atributos
instancias

en el MIT

Agente

detección de eventos

procesamiento discriminador

para la gestión
Obtener! Set! Acción Notificación de eventos
entidades

CMISE

ACSE CMIP

• Figura 5. Gestionado arquitectura de comunicación infonnation.

puede proporcionar la flexibilidad y la eficiencia en el acceso a la información

Gestión de servicios de comunicación
gestionada. entidades gestoras pueden controlar el contenido y la estructura
de la base de datos. La base de datos también puede ser flexible organizado
M-INITIALlZE: Establecer asociación de gestión de M-TERMINACIÓN: Finaliza la gestión de la
para reflejar configuraciones de dispositivos específicos. Astatic base de
asociación M-ABORTO: Sin confirmar la terminación
datos estruc tura puede conducir a dificultades en el manejo compos
estructuras de dispositivos ITE. Los diferentes componentes pueden requerir
sus propios modelos de bases de datos. Sin embargo, no se pueden unificar
en un solo MIB debido a su estructura estática. Por lo tanto, hubs complejas a
menudo incluyen múltiples agentes SNMP (cada manipulación de un
componente diferente). Un MIT dinámica permite que estos diferentes
modelos de bases de datos a unificarse con facilidad.

Una base de datos de gestión dinámica, sin embargo, presenta M-GET: Recuperar información M-CANCELACIÓN-GET: Cancelar recuperaciones M-SET: Cambiar un valor de atributo

complejidades de implementación significativos. Los recursos necesarios M-ACCIÓN: invocar una operación MO M-EVENT-REPORT: Generar un informe de eventos MO a un gerente

para almacenar y procesar la información hombre de edad no se pueden

predecir en tiempo de diseño. Los gerentes pueden extender el MIT allá de
los recursos disponibles del mediador. Los cambios en el MIT puede resultar
en la corrupción de la base de datos. Por ejemplo, un MO puede ser
• Tab es decir, 1. PAE proporcionada por una entidad CMISE.
eliminado mientras que otros OMs contienen punteros relación con él.
diseñadores de software de aplicación no pueden compartir un único modelo
de los contenidos del MIT, ya que cada aplicación tiene que construir y Tain
principal de su propio subconjunto del MIT. consultas y respuestas, las notificaciones de eventos de manejar, y
proporcionan invocaciones remotas de Func MO. CMISE utiliza los
servicios de elemento de OSI associ del servicio de control de ación
(ACSE) y el elemento de servicio de operaciones a distancia (ROSE)
para soportar estos servicios [12]. Una estructura típica de un entorno
Modelo de Gestión de Comunicación com municación agente se muestra en la Fig. 5. Una organización
simétrica gobierna la estructura de entidades pares de gestión.

O comunicaciones de gestión
orientado a la conexión del SIy requieren
de transporte se basan en el entorno
de la capa de aplicación OSI. (Consulte la referencia [12] para OSI
detalles de capa de aplicación.) Agentes (entidades gestionadas) y los
administradores (hombre entidades envejecimiento) son vistos como
aplicaciones pares que utilizan los servicios de una gestión común infor
mación elemento de servicio (CMISE) al intercambio de información
gestionada [6]. CMISE ofrece puntos de acceso Ser vice (PAE) para el
apoyo controlado Asso asocia- entre los gestores y agentes.
Asociaciones se utilizan para el intercambio de información gestionada
La sección superior de la Fig. 5 describe el ture STRUC del MIT.
instancias MO y sus atributos, operaciones y notificaciones de eventos se
representan como rectángulos sombreados en la parte superior. El agente
de OSI proporciona funciones de selección para localizar los registros de
MO que se accede por get / set PAE / Acción de CMISE. El agente
también ofrece detección de eventos y hacia adelante ing de las
notificaciones a las entidades gestoras inscrito
( a través de los registros del MIT) para recibirlos. Una entidad CMISE
proporciona SAPs (representadas en la Tabla 1) para soportar las
comunicaciones con el agente. se dis-

IEEE Communications Magazine · Mayo de 1993 23


• Fig u re 6. aggr egated y recuperación selectiva.
• La Figura 7. Ejemplo de una Mo.
parches / recibe CMIP PDU s a / desde otros elementos de
servicio tales como ACSE y ROSE. Estas son las PDU
intercambios a través de un transporte orientado a la conexión.
CMIP PDU se ve mejor como ERS carri de solicitudes y
respuestas generadas por las primitivas CMISE respectives.
Por ejemplo, un CMISE M-GET accede por un gestor genera
una CMIP GET -request PDU al agente y las PDU respec tiva
GET-respuesta del agente.
Las interacciones llevadas a cabo por las aplicaciones de gestión
de los compañeros se confirman por lo general a través del modelo de
solicitud-respuesta estándar OSI. Por ejem plo, una invocación por un
gestor de los resultados de SAP M-INI TIALIZE en una invocación
CMISE de la ACSE a través de una PDU CMIP. La ACSE gestor envía
una solicitud de asociación a un compañero. La ACSE pares en el
agente pasa la solicitud CMIP a CMISE del agente. Una PDU de
confirmación y luego se propagan de vuelta de CMISE del agente a
través de
Estado
el tiempo de actividad
• Fig u re 8. Un subclase de nodo.
24
un ACSE y de vuelta al gestor de origen.
Los servicios centrales de CMISE proporcionan acceso a la
información gestionada. El constructo GET proporciona medios para la
recuperación a granel y el filtrado de la información del agente. Esto se
ilustra en la Fig. 6. Para accom recuperación mayor Plish, un GET
solamente necesita especificar un subárbol del MIT desde la que los
datos se va a recuperar. Este subárbol se especifica mediante su nodo
de base y el alcance de la solicitud GET. A las especificaciones ify un
criterio de selección, un GET debe proporcionar un fil ter definido por un
lenguaje sencillo. La recuperación de todos los datos de puerto en
SalesNet cuyas tasas de error superar cierto umbral se ilustra en la Fig.
6. El GET solicitud identifica el alcance de la búsqueda y el filtro y el
agente realiza la búsqueda y selección.
La invocación remota de operaciones se lleva a cabo a través
de M-ACCIÓN. Es necesario especificar la instancia de MO, la
acción que se debe invocar y los parámetros que se pasa a ella.
La invocación es apoyado a través de la rosa. Las notificaciones
de eventos se manejan al inscribirse registros apropiados en el
MIT, usando M-crear. Un gestor utiliza M Crear para colocar un
objeto edad evento de notificación-hombre en el MIT. Tras la
detección de un evento, el agente utiliza el MIT para identificar los
abonados para las notificaciones. Un M-EVENT-notificación es
generado para cada uno de tales abonado.
Modelo SMI
T estructura
modelo juega unlapapel
que de central administrada
información en la norma OSI.
(SMI)Se introduce en
[8] y se elabora en las directrices para las definiciones de objetos
gestionados (GDMO) [10]. Este modelo se basa en un extender ed
orientado a objetos ( 00) modelo de datos [16]. OM, al igual 00 clases,
proporcionan plantillas a las operaciones encapsu finales de datos y
de gestión (métodos, acciones) asociados a entidades gestionadas.
MO extiende el concepto de clase para incluir cationes notifi evento.
Las notificaciones de eventos añaden una nueva dimensión.
Tradicional 00 el software asume un modelo síncrono de la
interacción entre un objeto y sus usuarios (programas). Los
programas pueden llamar a los métodos de forma sincrónica. Por
otra parte, los acontecimientos pueden ocurrir independientemente y
de forma asíncrona con los cálculos de dirigentes que acceden a
ellos.
El MO soportes modelo de herencia. Una definición MO puede
incluir atributos, operaciones y eventos de un MO más general. Por
ejemplo, un gen eral MO que describe una interfaz puede ser usado
para definir interfaces especializadas (por ejemplo, Ethernet, Token
Ring). Los datos, operaciones y eventos asociados
Habla a
IpSystem
IEEE Communications Magazine · Mayo de 1993
 <Clase-label> clase de objeto gestionado
[DERIVADA DE <clase de etiqueta> [, <clase de etiqueta> l *; l [alomórfica SET
<clase-label> [, <Clase de etiqueta> l *; l
[POR CARACTERIZADA <package-label> [, <Paquete-label> l *; l
[Lotes condicionales <paquete-label> presente IF <condición de definiciones>
[, <Paquete-label> presente IF <condición de definiciones> l *; l [PARÁMETROS
<parámetro-label> [, <parámetro-label> l *; l registrado como <object-identifier>

• La Figura 9. SampleMOclass plantilla.

eventLogRecord clase de objeto gestionado DERIVADA DE

LogRecord;
CARACTERIZADO POR PAQUETE eventLogRecordPackage
ATRIBUTOS managedObjectClass GET, GET managedObjectInstance ;;; lotes condicionales

eventTimePkg PAQUETE ATRIBUTOS GET eventTime ;;

Presente si el parámetro de tiempo de evento estuvo presente en el informe de eventos CMIP; Registrado como
{smi2MobjectClass 5};

• Fig u ra 10. Ejemplo de eventLogRecord.

con una interfaz MO será heredado por estas subclases especializadas.

La herencia es principalmente un mecanismo de táctica syn como uno
podría simplemente incluir las definiciones de la superclase en la
subclase initions MO def para lograr el mismo efecto. Para ilus trar
herencia, considere un MO definir una clase de nodo de objetos como sistema
se muestra en la Fig. 7. formas elipsoidales describen los atributos de
datos. formas rectangulares describen las operaciones de prueba y
comienzan un nodo. Los eventos se describen mediante formas
triangulares. eventForwardingDiscriminator

Consideremos ahora una especialización de un "nodo" un IpSystem

MO. Un IpSystem se puede definir como una subclase de nodo. Se
hereda todos los atributos del nodo, operaciones y eventos. El IpSystem
puede reemplazar algunos de estos componentes hereditarios (por
ejemplo, una nueva operación de inicio) y añadir nuevos atributos,
operaciones y eventos.

Las relaciones son significativas en la gestión

Las relaciones entre los elementos de datos gestionados son de

gran importancia en la correlación de información. En el ejemplo de
tormenta anterior, era necesario a las observaciones correlato de
errores de la capa física con las de un procesador de interfaz de
• la figura 11 Ure. La jerarquía de clases MO
cola de tareas manipu- retransmisión Han. Habría sido necesario
representar las relaciones entre estos objetos para poder
correlacionar sus comportamientos. El modelo de información de información asociada con todos los puertos contenida en una interfaz
gestión de OSI, en contraste con SNMP, proporciona medios dada, por la que atraviesa los respectivos punteros de relación. Por
explícitos para representar tionships rela. supuesto, el recorrido puede requerir sustanciales interacciones
gestor-agente para recuperar y punteros dereference. Esto podría
haber sido sim plified si el protocolo incluyó recorrido primi tivos (GET
Un MO puede incluir atributos de relación con punteros a las -al lado) para seguir punteros de relación, de manera similar a las
OM relacionados. Por ejemplo, un atributo de puerto que bases de datos de red.
representa la relación "con CONTENIDA-in" puede incluir un
puntero al objeto de interfaz que lo contiene. El valor del puntero
es el identificador de ruta de nombre distintivo (DN) del objeto GDMO proporciona la sintaxis de MO Definiciones

cara entre en el MIT.

El modelo OSI incluye una serie de relaciones genéricos que se
puede usar en el modelado de MO tal como "se-contenía-in" "es de
igual de'(para el protocolo lazos enti), y 'es de copia de seguridad
de'(para sistemas o nentes compo). el uso de la relación de atributos
es similar a las técnicas utilizadas en el modelo de red de bases de
datos [17]. se logra gran generalidad en resentir rep, en principio,
cualquier modelo de entidad-relación. Por ejemplo, se pueden
identificar fácilmente y recuperar
El GDMO introduce extensiones considerables de ASN.l para manejar
la sintaxis de las definiciones de información gestionados. Una nueva
estructura de la lengua (plantilla), se introduce para combinar las
definiciones. Plantillas desempeñan un papel similar al de ASN.l
Macro, excepto que no se prestan a simples extensiones de los
compiladores ASN.l. Una plantilla de muestra es la plantilla MOciass
(Fig. 9). Se utiliza para definir MO estruc tura y registrar las
definiciones de la norma ISO regis árbol tración.

IEEE Communications Magazine · Mayo de 1993 25

 sistema de clase de objeto gestionado
DERIVADA DE superior;
CARACTERIZADO POR PAQUETE systemPackage
ATRIBUTOS systemid GET, GET operationalState, usageState GET, GET administrativeState
REEMPLAZAR, Gestión de Tate GET; ATTRIBUTE GROUPSstate, relación;

NOTIFICACIONES objectCreation, objectDeletion, objectNameChange, attributeValueChange, estatal

Cambio, ......, environmentalAlarm ;;; lotes condicionales

dailyScheduling presente si tanto la programación semanal y un paquete de programador externo

no está presente en una instancia

repairStatusPkg atributos de paquete ...

Presente si tanto la programación semanal y un paquete de programador externo no

están presentes en una instancia

Inscrito como smi2MOBJECTClass {l4};

• Higo u re 1 2. subconjunto esquemática del sistema de Mo.

La <clase-label> es un lugar-soporte para un nombre de MO.
El "derivado de" sección describe las superclases cuyas
definiciones son heredados por el MO. El "caracterizado por"
parte incluye el cuerpo de atributos de datos, operaciones y
notificaciones de eventos encapsulados por el MO. "edades",
"Paquete paquetes condicionales" y "Parámetros" son plantillas
utilizadas para combinar las definiciones de atributos,
operaciones y notificaciones de eventos. Los "registrada como"
parte registros de la defini ción MO en el árbol de registro ISO.
LogRecord (su superclase). Incluye definiciones tomadas de un
paquete para la edad eventLogRecordPack y un paquete condicional
eventTimePkg, y se ha registrado en el árbol de registro OSI como el
subárbol etiquetada 5 bajo la etiqueta smi2Mob jectClass. Los
atributos se siguieron con descriptores como consigue!
REEMPLAZAR, que denota el modo de acceso de lectura / escritura.
Note la declaración informal de la estafa DICIÓN bajo las cuales las
definiciones del lote condicional deben ser incluidos. Por lo tanto, la
compilación automática de las definiciones, a diferencia de SNMP
MIB, puede ser imposible.

Un ejemplo de definición de una eventLogRecord (Fig. 10)

[9], utilizando esta plantilla, sigue. Un eventLogRecord hereda Las definiciones de la información gestionada (D MI) [9] definen una
los atributos de un general jerarquía de clases como se representa en la Fig. II. Cajas representan
diferentes clases de MO, mientras que el árbol representa la herencia
relationsamong ellos.
Sistema Estos OM genéricos se centran en las definiciones de las diversas
formas de gestión de registros. El modus operandi del sistema es la
herramienta principal en la construcción de las OM asociadas con un sistema
SnaNode Elemento
dado. Incluye atributos para identificar el sistema, representar a su estado
operativo y administrativas nacionales, y proporcionar notificaciones
genéricos y paquetes de definiciones para el manejo de las operaciones de
iprouter iPHost Interfaz Protocolo
mantenimiento ULed sched. Un subconjunto esquemática de su definición se
proporciona en la Fig. 12.

XXRouter YYRouter
a / cd yo TCP ICMP Por ejemplo, consideremos el problema de la desa oping una
A jerarquía de clases para modelar sistemas de red típica trabajado,
como una especialización del sistema de MO. Una jerarquía de clases
:
fddi
posible se ilustra en la figura 13. Esta jerarquía considera dos clases de
sys tems:. Sistemas complejos (como en la parte izquierda deEl árbol)
y sistemas simples, o elementos (como en el lado derecho del árbol).
• Higo u re 1 3. Una jerarquía de clases de MO para representar los dispositivos en red.

Poniendo todo junto

un edificio 051 Gestionado Elemento

En esta sección se completa la imagen a través de un breve esbozo de

OSI modelado de un concentrador LAN. Typ componentes de cubo iCal y
sus ciones RELA de contención se representan en la Fig. 14.

Paso 1: Identificar estructura de clases y herencia Relat iones Entre OM - Un MO

debe diseñarse para cada componente administrado. El

primer paso
es a
identificar las similitudes de los elementos gestionados y capturarlos en
• Higo u re 14. componentes de cubo típicos y contención. las clases de MO, con el uso de la herencia.

26 IEEE Communications Magazine · Mayo de 1993

Una posible jerarquía de herencia de clase se representa en la Fig.
15. (Por ejemplo, los componentes EtherPort y Port Token puede
compartir algunos atributos, operaciones, y eventos. El MO
describirlos se pueden desarrollar como especialización de un
objeto puerto genérico).

Paso 2: Diseño y especificaciones ify Estructuras cal MO Syntacti Uso de GDMO - Utilizando el EtherChannel

GDMO, definir atributos, operaciones y notificaciones de eventos

gestionada para cada una de las clases de MO necesarios. Un
ejemplo de las definiciones MO puerto se muestra en la Fig. 16.
TokenRingChannel FDDIChannel
bibliotecas MO definidos por el protocolo comités com (por ejemplo,
FDDI) puede ser utilizada para componentes de captura
estandarizada. • Fig u ra 1 5. Un jerarquía de clases para OMs cubo.

Paso 3: Diseño de la estructura del MIT genérico para el dispositivo

- Diseño del MIT sigue el árbol de contención de la Fig. 14. puerto de clase de objeto gestionado DERIVADA DE elemento;
Cada componente se sustituye byrespec tiva CARACTERIZADO POR PAQUETE portPackage
mes instancias. por cada
ATRIBUTOS número_puerto GET, GET portStatus, ...; OPERACIONES
MO, es necesario para identificar atributos respectivos que forman un
diagnosticar, desconexión, conexión ...; NOTIFICACIONES portFailure,
nombre distintivo relativo único (RDN). Para cada componente del
portlnitialized ..;
dispositivo, la instancia de MO respectives debe ser creado en el MIT
(utilizando un CMIP Crear primitivo). Dinámicos objetos gestionados
Inscrito como {. . . . . . };
(por ejemplo, diferentes logs) se pueden crear y eliminar por los
administradores de red durante el tiempo de funcionamiento. Relación
• la figura 16. Definiciones Ejemplo ofportMO.
atributos valores se establecen después de las instancias MO
respectivos se encuentran en el MIT. Por ejemplo, un "contenido-in"
relación puede estar asociada con pares de puertos de tarjetas. Una
instancia de un EtherPort MO puede incluir un puntero a la instancia operaciones extrínsecos al MIT y su contenido.
EtherCard MO. Del mismo modo, una instancia EtherCard puede Por el contrario, SNMP persigue un simple estática MIB,
apuntar a una instancia etherchannel (sub neto) para representar la tratando de minimizar y limitar la demanda de recursos del
relación "unido a". agente. Los recursos de memoria y de procesamiento necesaria
para manejar el MIB pueden ser evaluados cuidadosamente
planificadas y en tiempo de diseño. Como siempre, el poder de
modelado de datos de SNMP está limitado. Por ejemplo,
sistemas compuestos pueden necesitar instancias múltiples PLE
Evaluación crítica
MIB para representar sus diferentes partes. Estos MIB no se
pueden combinar en una base de datos GLE pecado ni acceder
T modelo OSIpara
siva marco se busca proporcionar
el manejo unde
de la gestión comprehen
arbi trari? Y los sistemas desde un solo agente. Por lo tanto, un sistema compuesto
complejos. Vamos a evaluar brevemente algunas ventajas y desventajas requiere la mayor cantidad de agentes SNMP como sus
asociadas con esta generalidad, y contrastar las opciones de OSI con las componentes. Como otro ejemplo, la falta de modelado explícito
del SNMP a Internet. de los límites de las relaciones de la capacidad de las
aplicaciones a los datos correlativos administrado. Las recientes
Gestionado información ModeJ propuestas de SNMP V.2 [4] buscan resolver algunos de ciones
OSI proporciona una extendida 00 base de datos de marco de trabajo Limita el modelado de información de SNMP.
para gestionada modelo de información. Se trata de imize máximo la
información de potencia de modelado para manejar sistemas
complejos. bases de información de gestión, sin embargo, necesidad
de equilibrar en conflicto requisitos de funcionalidad y en tiempo real
por Formance bajo las limitaciones de recursos. Aún no se ha Gestionado Acceso a la Información ModeJ

establecido si las opciones de diseño OSI pueden golpear dicho saldo.
Por ejemplo, una base de datos dinámica MIT puede memorizar y / o
procesamiento de agente fácilmente saturar los recursos. La demanda
de evento noti caciones puede atar los recursos de procesamiento y
comuni cación del mediador, hambrientos GET o acción peticiones (y
viceversa).
El modelo OSI introduce dos importantes cionalidades FUNC que faltan en
SNMP: a granel y recuperaciones selectivas. Ambas capacidades son
fundamentales en el control ling el flujo de información de gestión. Con la
recuperación mayor a cabo, los administradores se ven obligados a seguir
un gran número de solicitudes de sondeo. Sin recuperación selectiva
(filtrada), los administradores ven obligados a recuperar grandes
cantidades de datos irrelevantes.

En general, el rendimiento de 00 bases de datos aún no se
entiende [16]. Eliminación de los registros MO puede dar lugar a
punteros de relación huérfanos, requir ing recolección de basura
complejo a los agentes. Varios administradores que realizan actividades
CREATEIDELETE pueden conducir a vistas inconsistentes del MIT.
Complejidad del modelo de información puede dar lugar a dificultades de
conformidad. Por ejemplo, el tic seman de notificaciones de eventos debe ser
formalmente Cap tured para permitir especificaciones de criterios de
conformidad. El significado de los acontecimientos, sin embargo, está ligado al
dispositivo
invocación explícita de las operaciones del mediador es anoth er
capacidad de OSI que falta de SNMP. Remota cationes INVO son
importantes para la distribución de los cálculos de gestión para agentes y
mejorar el control sobre las actividades gerente del mediador. También
pueden reducir la complejidad de los agentes ciones-gerente interac
limitándola a las interfaces de procedimiento. SNMP es compatible con
invocaciones implícitos como los efectos secundarios de las solicitudes
SET. Una operación de diagnóstico, por ejem plo, puede ser invocada por
un "conjunto" de una variable respectivo. invocaciones implícitas oferta sólo
se limitan capa-

IEEE Communications Magazine · Mayo de 1993 27

 bilidades en los parámetros que pasan y en Sincronización ¿ing
invocaciones con los gerentes. Además, aumentan la complejidad del
La administración agente ya las solicitudes SET deben ser atrapados para invocar
procedimientos respectivos.
debe perseguir
Modelo de comunicación
gestión OSI utiliza el puerto trans orientado a la conexión y las
flexibles
interacciones confirmados. Estos proporcionan capacidad RELI y
permiten la recuperación a granel; una sola GET puede dar lugar a
múltiples ligado respuestas. Que requieren, sin embargo, el entorno de
comunicación compleja y ocasionar fallas en la sensibilidad. Durante red
de tensión tiempo, las conexiones no pueden ser más de tiempo
ción de decentraliza
suficientemente largo sostenible para llevar a cabo las funciones de
gestión necesarias. entidades de gestión pueden tener que gastar mucho
tiempo y recursos en el han dling conexiones perdidas. puerto trans
basado en la conexión puede convertirse en un obstáculo en el
responsibili vínculos a cumplimiento de las interacciones de gestión en un momento en que
más se necesitan.
los dispositivos y la
Por el contrario, las comunicaciones SNMP utilizan un transporte con
automatización nectionless datagramas (UDP), con aire puesto firme interacciones GET /
SET y notificaciones de eventos no confirmados (trampas). La
máxima de gestionar responsabilidad de garantizar una comunicación fiable se pasa a las
aplicaciones Agente / administrador. Porejemplo, los administradores
pueden detectar la pérdida de una petición GET / SET cuando la
mentfunctions a través confirmación GET RESPONSE no llega. Pueden ignorar la pérdida, vuelva
a emitir la solicitud, o elegir otras alternativas a la recuperación. Durante el
de software de tiempo de estrés, los administradores pueden flexionar ibly ajustar sus
cálculos a la pérdida de mango, en lugar de enfrentarse a un todo-o-nada
elección de un servicio de conexión fiable. Un modelo de datagramas
aplicación.
requiere un entorno de comunicación simple que es fácil de implementar.
Gerentes, sin embargo, sólo se puede recuperar la información que se
ajusta dentro de una única trama UDP. Esto limita a granel mecanismos de
recuperación.
El paradigma de gestión de la plataforma centrada
¿Qué tan útil es el modelo OSI en el apoyo a la gestión de plat forma
centrada? El modelo OSI pre escribas poderosos agentes que
requieren recursos computacionales sustanciales, a la par con los
recursos disponibles en la plataforma. Esto plantea ques ciones
interesantes relativas a la asignación de responsabilidades entre las
plataformas y agentes. Si los agentes han de ser tan ful poder, qué
funciones deben ser eliminados de ellos y asignar a los
administradores de la plataforma y por qué? Si la plataforma es jugar
un papel incidental en gestionar ción, ¿requiere un protocolo completo,
o incluso ninguna, en general la gestión? ¿Por qué no limitar los
intercambios con agentes en las API específicas de la aplicación (por
ejemplo, el uso de rosas o una RPC)? ¿Cómo funciona un modelo de
acceso máxima, que expone los detalles del objeto inter nales de
entidades gestionadas de una forma plat, sirven una plataforma
mínima? Sin embargo, si la plataforma está a ser máxima, ¿por qué se
necesitan agentes máximas? El equilibrio entre las complejidades y
responsabilidades de los agentes, plataformas, y sus protocolos de
interacción todavía no se entiende.
¿Qué tan útil es la plataforma centrada en gestionar ción? sufre de
administración de plataforma centrada limitaciones técnicas fundamentales
[18]. En primer lugar, es infranqueable. Las tasas a las que se debe
acceder y se procesan objetos de dispositivo normalmente exceden la
capacidad de la red / plataforma. Plataforma de procesamiento y / o de
gestión de recursos de comunicación pueden ser saturados rápido como
tamaño de la red, la velocidad y aumento de la complejidad. En segundo
lugar, durante los momentos de estrés
28
la plataforma debe aumentar sus interacciones con los agentes, en un
momento en que la red es menos ble capa de manejar estos. Gestión
de respuesta en tiempo y fiabilidad, además, tienden a estirarse en un
momento de estrés, cuando más se necesita una respuesta rápida y
fiable. En tercer gestión, plataforma centrada puede dar lugar a una
intensa y poco realista microgestión de agentes de aplicaciones de la
plataforma. En cuarto lugar, la heterogeneidad de la plataforma y la
heterogeneidad semántica, que surge en el contexto de la gestión de la
plataforma centrada en crear barreras en el desarrollo de la gestión de
aplicaciones Ment.
paradigmas de gestión alternativos son ed necesidad de
reflejar las necesidades y oportunidades de las redes
emergentes y resolver las limitaciones de la gestión de la
plataforma centrada. La administración debe perseguir la
descentralización flexible del sibi Respon? Dades para aparatos
y automatización máxima de las funciones del hombre agement
través de software de aplicación. Investigación hacia tales
gestión distribuida se describe en la referencia [18]. Una gestión
por delegación paradigma (MBD) se utiliza para distribuir
aplicaciones de gestión a los agentes de dispositivos Dynam
camente. programas de aplicación de gestión son del egated
por las plataformas de dispositivos a los agentes que las
ejecutan bajo el control de la plataforma remota. MBD por
plataformas MITS para asignar de forma flexible Sibi gestión
respon? Dades a los dispositivos, y los dispositivos de
programa, incluso para llevar a cabo la gestión autónoma.
conclusiones
yo t es útil reconsiderar las cuestiones centrales de la
gestión de la red: ¿Cuál debe ser monitoreado? ¿Cómo se
debe interpretar? ¿Cómo debería esto Ysis anal puede
utilizar para controlar el comportamiento de la red? normas
de protocolo de gestión proporcionan estructuras de tics
Syntac para organizar y acceder a información gestionada.
Tal syntacticframeworkcan puede utilizar ful para permitir
respuestas sistemáticas a estas preguntas. Sin embargo, la
semántica de la información gestionada, en lugar de su
sintaxis, es la clave para las respuestas. Clear1y, los datos
que deben ser controlados necesidades que se deriva del
modelo que se utiliza para interpretar los datos. El modelo
debe basarse en los tics Seman de la red comportamiento
operativo. U Nfor damente, la manera en que las
interacciones entre los procesos de red conducen a fallos o
rendimiento inef ficiencies no se entiende bien.
Se necesita una investigación significativa para desarrollar una
mejor comprensión de las operaciones de red y construir capacidad
de gestión eficaz. Normalización de la sintaxis información gestionada
se ve mejor como un primer paso hacia el manejo de la semántica de
las operaciones de trabajo netos. necesidades y escenarios de
gestión de red es probable que continúe y el cambio como nuevos
tipos de redes, nuevas aplicaciones y tecnologías de gestión surgen
apuesta ter largo de la próxima década. A medida que mejora nuestra
comprensión de la semántica de las operaciones, las nuevas
estructuras sintácticas a la manejabilidad de apoyo seguirán
surgiendo. La normalización de estos mecanismos es probable que
continúe y evolucionar de una manera no asim ilar a la evolución del
SNMP.
IEEE Communications Magazine · Mayo de 1993
 [13] BN MeandzUa y J. Westcott, ed., The First IFIP Internacional
Expresiones de gratitud
Simposio sobre gestión de red integrada, (Holanda del Norte, mayo de 1989).

El autor agradece el apoyo a la investigación proporcionada
por la dación Nacional de Ciencia Foun (NSF)
underprojectnumber NCR-9I-06127.
referencias
[1] JD Case, et a /., " Un Simple Network Management Protocol
(SNMP) ", RFC 1157, mayo de 1990.
[2] M. Rose y K. McCloghrie, "Estructura y Identif icación de Man
agement información para Internets basados ​en TCP / IP ", RFC 1155, mayo
1990.
[3] K. McCloghrie y M. Rose, "Base de Información de Gestión de
Internets basadas en IP de gestión de red de TCP /: MIB-II ", RFC
1213, Marzo., 1991
[4] JD Case, et a /., " Introducción a la simple gestión de Proto
Col (SMP) Marco ", borrador, julio de 1992.
[5] 051. 1.5.0" 10040 Sistemas de Gestión de Información general, 1991. [6] 051, ISO, 9595 Tecnología de
la Información, Interconexión de sistemas abiertos,
Common Management Information Services Definiciones de 1991. [7] 051. 1.5.0" 9596 Tecnología de
la Información, de sistemas abiertos · Intercon
nection, ción de Información de Gestión Común Protocolo Specifica, 1991.
[8] 051. 1.5.0" 10165 · 1 Tecnología de la Información, de sistemas abiertos · Inter
conexión, Modelo de Gestión de la Información, 1991. [9] 051. 1.5.0" 10165 · 2 tecnología de la
información, sistemas abiertos · Inter
conexión, Definición de Gestión de la Información, 1991. [10] 051.1.5.0" 10165 · 4 tecnología de la
información, sistemas abiertos · Inter
conexión, Guidelinesforthe Definitionsof objetos gestionados, 1991. [11] K. McCloghrieand M. Rose,
"Información de Gestión Común Ser
vicios y Protocolo sobre TCP / IP (CMOT) ", RFC 1189, marzo de 1991. [12] MT Rose, el libro
abierto, una perspectiva práctica de OSI (prEN
tice Hall, 1990).
[14] I. Krishnan y W. Zimmer, ed., El Segundo IFIP Internacional
Simposio sobre gestión de red integrada, (Holanda del Norte, abril de 1991).
[15] A. Kershenbaum, M. Malek, y M. Wall, eds., Administración de redes
y Taller de Control, Tarrytown, NY (Plenum Press, Sept.
1989).
[dieciséis] MI. Horowitz, ed., Orientada a objetos y bases de datos Appl icaciones
(Prentice Hall. 1989). [17] J. Ullman, Principios de base de datos y conocimiento sistemas de base,
vols. YO & II. 3d ed. (Computer Science Press, 1988).
[18] Y. yemení, G. Goldszmidt, y S. yemení, "Gestión de Redes
por delegación," El Segundo Simposio Internacional sobre integrat ed de gestión de red, (Holanda
del Norte, abril de 1991).
Biografía
Yechiam yemini ha sido miembro de la ment Informática Salir de la Universidad de Columbia desde 1980, donde
actualmente se desempeña como director del Centro de Tecnología Avanzada estado de Nueva York en los
sistemas informáticos y de información. H es principales intereses de investigación incluyen las redes de
ordenadores, gestión de redes, obras netas de alta velocidad, protocolos, sistemas distribuidos y análisis de
rendimiento. Ha publicado y dado numerosas conferencias en estas áreas. La investigación en el laboratorio
Distributed Computing y Comunicaciones (DCC) resultó en diseño y gestión de las tecnologías de red que
han sido amplia mente exportados, aplicados por cientos de sitios y comercializados por la industria ING
plomo. Ha sido co-fundador, director y principal asesor científico de Comverse Technology Inc., un fabricante
de tecnología IC gh hi éxito publ del mensaje multimedia commun ordenadores icación com.

Revista de Comunicaciones IEEE · Diciembre de 1991 29