Submodelo de información en OSI

Arquitectura de administración OSI

Submodelo de información

[Definición: El submodelo de información (de una arquitectura de administración) busca controlar los métodos utilizados para modelar y describir los objetos administrables. Además, una definición estándar de objetos administrables es un prerrequisito para interoperabilidad de la administración: permite a redes heterogéneas interactuar con propósitos de administración.]

ISO aplica un enfoque totalmente orientado a objetos para construir su (complejo) modelo de información. Este modelo es llamado Structure of Management Information (SMI) (ISO 10165x). Los objetos administrables (Managed Objets: MOs) son instancias de las clases objeto administrable (Managed Object Classes: MOCs) cuyas propiedades visibles externamente están descritas en la managed object boundary de la clase respectiva. Esta managed object boundary incluye los atributos, las operaciones definidas, notificaciones y descripciones de comportamiento de la clase. Esta boundary implementa una abstracción de los recursos desde el punto de vista de la administración. Los valores "reales" de los atributos y las operaciones se "mapean" del recurso real.

El modelo de información de OSI también incorpora la herencia del enfoque orientado a objetos. Una MOC puede ser definida como una subclase de una o más superclases, MOC que heredará las características de las superclases. Estas características pueden ser refinadas o expandidas. Un ejemplo de jerarquía hereditaria sería:

Device

Printer

Laser printer

HP LaserJet

El soporte de comportamiento alomórfico (allomorphic) es opcional. Esto significa que un recurso concreto (para ser más precisos, el MO que lo representa) puede ser visto de diversas formas (del griego állo: otro y morphé: forma):

como un MO ó
como una instancia de diferentes MOCs en la jerarquía de herencia

Esto permite, por ejemplo, administrar una impresora laser concreta como una entidad de la clase "laser printer" o como una entidad de la clase "output device". El alomorfismo permite simplificar la formulación de algoritmos de administración porque los recursos pueden separarse en grupos que, desde el punto de vista de la administración, serán tratados de manera similar. El alomorfismo también permite utilizar nuevas versiones de hardware o software que son administradas por viejas herramientas, facilitando a los proveedores agregar nuevas características a sus productos y permitir la interoperabilidad sin tener que adherirse de manera rígida a las definiciones de clases de objetos estándar.

GDMO

Un metalenguaje de plantillas (templates) simple (ISO 10165-4), basado en ASN.1 (ISO 8824), es utilizado para describir las MOCs. Este metalenguaje está descrito en Guidelines for Definition of Managed Objects (GDMO) (ISO 10165-4). Dicho documento especifica un formato y los lineamientos para las definiciones de las MOC. En las definiciones de plantilla se puede hacer referencia a otras (definiciones de) plantillas. Cada referencia a otra plantilla puede ser reemplazada en línea (macro expansion) por la correspondiente definición de plantilla.

OSI-SMI utiliza las siguientes estructuras genéricas para las plantillas:

Managed object class
Package
Parameter
Attribute
Attribute group
Behavior
Action
Notification
Name-binding

La plantilla (template) managed object class es el nivel más alto; otras plantillas pueden ser utilizadas para definir esta de manera más exacta utilizando una descomposición descendente (por ejemplo, la clase está compuesta por paquetes, el paquete está compuesto por atributos, notificaciones, comportamientos y parámetros).

Plantilla que define una clase de objeto administrable (MOC)

MANAGED OBJECT CLASS

[DERIVED FROM
[,]*;
]

[CHARACTERIZED BY
[,]*;
]

[CONDITIONAL PACKAGE
PRESENT IF conditional-definition
[, PRESENT IF conditional-definition]*;
]

REGISTERED AS {object-identifier-value};

Ejemplo de una plantilla para la definición de la clase para el objeto administrable Hub (IEEE 802.3)

Hub MANAGED OBJECT CLASS

DERIVED FROM ISO/IEC 10165-2: top;

CHARACTERIZED BY
   BEHAVIOUR hubBehaviour;
   ATTRIBUTES
     HubId                         GET,
     NumberOfRelays                GET,
     RelayActive                   GET,
     TimeSinceHubSystemReset       GET,
     HubResetTimeStamp             GET,
     HubHealth                     GET,
     GroupMap                      GET;
   ACTIONS
     ResetHubSystemAction,
     RealyChangeoverAction;
   NOTIFICATIONS
     HubHealt,
     GroupRelayConfigChange,
     PropietaryExtensionAlarm;

REGISTERED AS {iso(1)std(0)iso8802(8802)csma(3)hubmgt(18)objectclass(0)hubobjectClass(X)};

HubName NAME-BINDING
   SUBORDINATE OBJECT CLASS          Hub;
   NAMED BY SUPERIOR OBJECT CLASS    ISO/IEC 10165-2:System:
   WITH ATTRIBUTE                    HubID;
   BEHAVIOUR                         HubIDBehaviour,
REGISTERED AS {iso(1)std(0)iso8802(8802)csma(3)hubmgt(18)namebinding(3)hubname(X)};

HubID ATTRIBUTE
   WITH ATTRIBUTE SYNTAX              IEEE802CommonDefinitions.uniqueIdentifier,
   MATCHES FOR                        Equality
   BEHAVIOUR                          HubIDBehaviour,
REGISTERED AS {iso(1)std(0)iso8802(8802)csma(3)hubmgt(18)attribute(4)hubid(X)};

En términos de "reusabilidad" de especificaciones, el modelo de información de la arquitectura OSI es "altamente granular" ya que no sólo permite el reuso de las definiciones de MOCs sino que permite el reuso de cada especificación de plantilla (template).

Ls descripción de una clase de objeto administrable (MOC) incluye:

Los atributos (ATTRIBUTES) que son visibles en la managed object boundary y caracterizan las propiedades y el estado del objeto administrable. Los tipos de atributos utilizados dependen del objeto que está siendo modelado. Los atributos pueden ser asociados con tipos ASN.1 o puede derivarse de un atributo genérico como counters, gauges, thresholds, names, timers al igual que de tipos más complejos definidos en ISO 101165-2 ó en X.721. Los valores y operaciones permitidos están especificados para cada atributo, permitiendo restringir rangos de valores y aplicar protección de escritura. Plantillas de atributos se utilizan para describir atributos. Una plantilla de grupo (ATTRIBUTE GROUP) hace posible que los atributos sean combinados en grupos que pueden ser accedidos (leidos ó establecidos por defecto) a través del uso de un solo comando. Los atributos pueden ser de dos categorías: singled valued y set valued (El atributo single valued es administrado como un sólo dato con respecto a las modificaciones. Aunque no es obvio, un atributo es considerado de este tipo si un sólo valor ó un conjunto de valores ordenados se asocia con él. Un atributo set valued es una colección de valores que no está ordenado y se define utilizando la construcción "set of"). Las operaciones orientadas a atributo exitentes son:

get: lee el valor de un atributo
replace: escribe el valor de un atributo
replace-with-default
add: agrega un valor a atributos set-valued
remove: remueve un valor de atributo de cierto set-valued
set-by-create: asigna un valor solo cuando el MO está siendo creado
not-modify: evita que el atributo sea refinado al crear subclases

Un conjunto de acciones (ACTIONS). Operaciones complejas que afectan todo el MO (objeto administrable). Pueden definirse para que sean específicas a ese MO (por ejemplo "reset MO"). Una plantilla (template) de acción es utilizada para especificar acciones. Además de las acciones (ACTIONS), que definen libremente operaciones específicas a un MO, hay dos operaciones predefinidas que siempre afectan al MO en su totalidad: create MO (instanciación dinámica) y delete MO (las acciones, create MO y delete MO se consideran operaciones orientadas a objetos y son diferentes de las listadas antes -get, replace, add, remove, etc.- que están orientadas a atributos).
Un conjunto de notificaciones (NOTIFICATIONS). Un MO también puede ser un recurso autónomo en el cual pueden ocurrir eventos asincrónicos. Las notificaciones son mecanismos utilizados para informar sobre eventos que pueden ser iniciados por un MO sin necesidad de que el sistema de administración lo solicite. La plantilla (tamplate) de notificación es utilizada para describir las notificaciones que pueden (aunque no necesariamente) ser específicas a un MO.
El comportamiento (BEHAVIOUR) respectivo que es especificado en la plantilla de comportamiento. Esta plantilla (template) registra la semántica de los atributos, las operaciones y las notificaciones e indica las relaciones con otros MOs, efectos laterales, etcétera. El comportamiento generalmente se describe de manera informal utilizando lenguaje (inglés) normal. También existen enfoques que incorporan formal descriptions techniques (FDTs) para describir el comportamiento; incluyen un lenguaje de descripción y uno de especificación (SDL, ITU-T Z.100) que han sido agregados a la serie de estándaraes ISO 10165. Sin embargo, requieren una extensión al lenguaje GDMO (GDMO+).
Paquetes condicionales (CONDITIONAL PACKAGE) que permitan incorporar variantes de ciertas propiedades y funciones. Cuando se "instancia" un MO, una decisión sobre sus características es tomada basada en condiciones if, colocadas en la definición de la MOC, para saber si dicho paquete formará parte integral del MO (es decir, el condicional colocado en la plantilla de definición de la clase especifica cuándo el paquete estará o no estará presente en una instancia de dicha clase). Esto puede hacer más fácil mapear un MO a un recurso real. Los paquetes condicionales ofrecen un alto nivel de flexibilidad en la especificación al permitir una "asociación tardía" al recurso real.
La ubicación de una clase en la jerarquía de herencia de MOCs es indicada por referencia a las superclases a partir de las cuales las especificaciones para las propiedades de un MO son heredadas.

Estructuras de árbol del submodelo de información de la arquitectura OSI

El submodelo de información de la arquitectura de administración OSI utiliza tres estructuras de árbol que buscan satisfacer diferentes requerimientos.

El árbol de registro (registration tree): Utilizado por OSI y la ITU, es una estructura en la cual se indexan todos los documentos y las especificaciones de plantillas (templates) predefinidas. De esta forma las especificaciones pueden ser reutilizadas en definiciones de nuevas MOCs. La raíz de este árbol no tiene nombre.
El árbol de herencia (inheritance tree): contiene las definiciones de las MOCs y muestra como estas están relacionadas a través del uso del principio de herencia. El árbol se construye a partir de las referencias a las superclases. La raíz de este árbol se llama TOP.
El árbol de contención (containment tree): muestra la estructura real de la MIB (Management Information Base) de un sistema. También es llamado Management Information Tree (MIT). Este árbol es utilizado para dar el nombre a los objetos administrables. La raíz de este árbol se llama ROOT.

Una de las dificultades que se tienen al comenzar a estudiar el submodelo de información es perderse en este "bosque". Debe quedar claro lo siguiente:

La jerarquía de clases utiliza el árbol de herencia. Estas clases son "las maquetas o planos" a partir de los cuales se pueden crear objetos administrables. A medida que se desciende en el árbol, las clases se van refinando. Una clase de equipo genérico (equipment) se define a partir de la superclase top. Una clase circuit pack tiene propiedades adicionales a las definidas en las clase equipment (circuit pack es una clase que representa unidades o tarjetas de expansión que se pueden reemplazar -insertarse o quitarse de algún slot, rack o bahía del elemento de red-. Incluye tarjetas de líneas telefónicas, procesadores, unidades de potencia). Si se crea una instancia de circuit pack, las propiedades de la superclase serán propiedades de esta instancia.
El árbol de contención se utiliza para identificar las instancias de una clase de manera exacta. Siguiendo con el ejemplo del circuit pack, este es nombrado de acuerdo a su posición ocupada en el slot, rack ó bahía (equipment holder). En la jeraquía de clases tanto el slot (equipment holder) como el circuit pack son subclases de equipment, pero para el árbol de contención es, por ejemplo, el puerto 2 de la interface de red 1 del hub 2 (H2.IF1.P2).
El árbol de registro se utilizado para indexar las definiciones de las clases, las propiedades de las clases como los atributos, grupos de atributos, tipos de notificación y tipos de acción. El proceso de registro provee un valor único que es una secuencia de números que representan cualquier información. Por ejemplo, la plantilla (template) que define la clase circuit pack puede tener el valor de registro {0 0 13 3100 0 3 30}. Esta secuencia de números es única y sólo puede representar la plantilla (template) que define la clase circuit pack.

NOTA: La arquitectura de administración de Internet (que utiliza SNMP), en su submodelo de información también registra su información de administración, pero sólo utiliza el árbol de registro. SNMP no utiliza los conceptos del enfoque orientado a objetos.

El modelo de información de la arquitectura OSI ha predefinido varias MOCs genéricas que pueden reutilizarse como superclases. Entre ellas están LOG RECORD (la superclase de diferentes registros), DISCRIMINATOR y SCHEDULER (padres de las MOCs utilizadas para controlar funciones de administración como reporte de eventos. Varias entidaes de protocolo también han sido modeladas con GDMO, tales como la entidad "transport connection" (ISO 10165-5 e ISO 10737) y los MOs de los sistemas de aplicaciones (ISO 10165-8) y los ambientes de los protocolos de administración de sistemas (ISO 10165-9).

Desde el punto de vista de administración, los recursos reales pueden ser elementales o compuestos. Por ejemplo, un hub (concentrador) puede tener más de una interface que, a su vez, puede tener varios puertos. Por esto los recursos modelados por los MOs deben reflejar estos hechos. Esto puede hacerse utilizando plantillas "name-binding" que se utilizan para crear jerarquías de contenido. MOs compuestos contienen ostros MOs. Los primeros reciben el nombre de MOs superiores, los últimos MOs subordinados (definición de la clase Hub-Object).

Un atributo obligatorio de la definición de cada MOC, es uno que le "dé" un nombre. El valor de este atributo, el nombre "real", no es asociado hasta que el objeto sea creado. El supuesto es que cada MO de un sistema OSI se incorpora en una jerarquía de contenido. Cada sistema tiene una raíz local (local root) -aunque puede ser más de una-, subordinada al árbol de información de administración (MIT) global, quién inicia en la raíz global (ROOT) (ISO 10165-1). Esta jerarquía de contenido por naturaleza produce un árbol de nombres que genera nombres únicos de manera global.

Por ejemplo, si el objeto IF, una entidad de la clase "interface", es asignada, a través de name-binding, a los objetos H1 y H2 de la clase "hub", entonces los nombres H1.IF y H2.IF son únicos de forma global, porque H1 y H2 son sistemas OSI. Si además la interface (IF) tiene los puerto P1 y P2 asociados, entonces H1.F1.P2 designará el segundo puerto de una interface instalada en el hub H1. Cada etiqueta de nivel en el árbol MIT es conocida como RDN (relative distinguished name). La concatenación de RDNs genera un identificador completo de una instancia de un MO, que es conocido como DN (distinguished name) porque permite identificar, dentro de la jerarquía, de manera completa y sin ambigüedades un MO. Esto recuerda el modelo de información del servicio de directorio X.500 (ahora LDAP). Un MO se agrega a un nombre único local en el árbol de nombres a través de una plantilla (template) name-binding. La jerarquía de herencia y la jerarquía de contenido son dos estructuras mutuamente independientes de la MIB. La herencia se relaciona con las clases, el contenido (contención) con las instancias.

Los MOs no pueden "sustentarse" de forma autónoma y deben visualizarse en un contexto (es decir, "existen" al relacionarse con otros MOs). Los atributos pueden ser parte de una relación, por ejemplo un counter y su correspondiente valor de umbral (threshold). Los atributos de un MO pueden señalar (apuntar a) otros MOs (por ejemplo, is-owned-by, is-backed-by). Además, como se mencionó antes, el proceso de name-binding puede colocar MOs en una relación de contención (contenido). Las relaciones también pueden ser descritas en las plantillas de comportamiento. ISO ofrece otra posibilidad: modelamiento de relaciones entre MOs a través de un MO de relación. Un modelo de relación general (General Relationship Model, GRM) fue desarrollado en los estándares ISO 10165-7 y en el ITU- X.725. GRM permite que una relación administrativa sea descrita como una MOC. Las operaciones definidas para esta clase incluyen bind (que adiciona un MO a una relación existente) y unbind; establish (que establece una relación) y terminate, query (que obtiene información sobre las relaciones) y notify. Los roles y la cardinalidad pueden incluirse en la definición de la clase. La primera aplicación de este estándar (septiembre de 1996) se encuentra en el ambiente de TMN, donde éste se utiliza para modelar el nivel de red (network).