Submodelo de comunicaciones, OSI-NM

Arquitectura de administración OSI

Submodelo de comunicaciones

[Definición: El submodelo de comunicaciones (de una arquitectura de administración) establece y define los elementos y conceptos necesarios para que los componentes del sistema (actores) puedan intercambiar información de administración (por ejemplo, quiénes pueden comunicarse, especificar los servicios y protocolos, definir la sintaxis y la semántica de los formatos de intercambio, además de los protocolos de administración que se colocarán dentro de la arquitectura de comunicaciones utilizada). La comunicación puede establecerse a través del intercambio de información de control, solicitudes de información de estado o generación de mensajes de eventos.]

El submodelo de comunicaciones de la arquitectura de administración OSI incorpora tres categorías diferentes de administración: administración de sistemas (systems management -SM-), administración de capa (layer management -LM-) y administración de protocolo (protocol management, conocido también como layer operation).

La arquitectura de administración OSI no define cómo las tres categorías de administración interactuarán, ni describe el tipo de interacción que existe con la administración local (es decir, el sistema operativo). Esto es compresible desde el punto de vista del submodelo de comunicaciones (es decir, la estandarización), pero no desde el punto de vista de la implementación. Todas las categorías de administración tienen acceso a la información puesta en la MIB.

1. Administración de sistemas

La administración de sistemas está relacionada con la administración total de los sistemas en cooperación. Las aplicaciones de administración de sistemas (systems management applications, SMA) involucran la cooperación de sus procesos de aplicación correspondientes (systems management application processes, SMAP). La administración induce a relaciones asimétricas, que explica porque un proceso SMAP puede asumir el rol de manager o de agente para una aplicación específica. El rol puede cambiar y en un sistema OSI es posible para un proceso SMAP coexistir con diferentes roles.

La parte relevante a comunicaciones de una aplicación de administración es la systems management applications entity (SMAE), que utilizando los propocolos de administración de sistemas (systems management protocols) adecuados, intercambia información de administración con las SMAEs de otros sistemas. Este tipo de comunicaciones de administración son la norma en la arquitectura de administración de OSI y a menudo requieren que el sistema tenga funcionalidad completa OSI (todas las siete capas). Claro que existen enfoques donde se utilizan menos capas y pueden soportar la arquitectura OSI-NM (OSI Network Management), entre ellas están CMIP sobre LLC y CMIP sobre SONET ECC.

La arquitectura de administración de OSI especifica que la información de administración que es intercambiada entre los procesos de aplicación sobre los SMAE pueden basarse en servicios diseñados especialmente para eso (ISO 9595, ISO 9596). Estos servicios reciben el nombre de common management information services (CMIS) y el correspondiente protocolo de administración asociado, common management information protocol (CMIP). CMIS se utiliza(n) para acceder y manipular MOs (remotos), permitiendo que las operaciones sean llevadas a cabo sobre el árbol de información completo (containment tree) de la MIB, llamado el management information tree (MIT). CMIS es(son) un servicio(s) orientado(s) a conexión que utiliza(n) el association control service element (ACSE) para la administración de la conexión de servicios y ROSE (Remote Operation Service Element) para la transmisión de operaciones de administración. CMIS incorpora los siguientes grupos de servicios:

Administración de asociación: utilizando los servicios ACSE, inicializa (initialitizing), termina (terminating) y aborta (aborting) conecciones CMIP.
Ejecución de operaciones: lee atributos de los MOs (M-GET), modifica/establece atributos en los MOs (M-SET), inicializa acciones en los MOs (M-ACTION), crea dinámicamente MOs (M-CREATE), borra MOs (M-DELETE) y cancela operaciones de lectura solicitadas con antelación (M-CANCEL).
Notifica eventos: Transmite las notificaciones de los MOs (M-EVENT-REPORT).

Algunos servicios son servicios confirmados, otros pueden ser servicios no confirmados. Las primitivas de servicios son pasadas al protocolo CMIP, con ellas se construyen los PDUs de CMIP que a su vez serán colocados (encapsulados) dentro de los servicios de ROSE de acuerdo al estandar OSI. Es importante anotar que CMIP puede utilizar otras pilas de protocolos como CMIP over TCP (RFC 2126).

La selección de MOs y el paso de parámetros a los MOs proporcionados por CMIS/CMIP al igual que las estructuras de los PDUs de CMIP estan, por supuesto, estrechamente relacionadas al submodelo de información de la arquitectura OSI-NM e incorpora su flexibilidad y capacidades. Para la selección de objetos administrables estos se identifican con la jerarquía del árbol de contención (containment tree). Para cualquier servicio, CMIS proporciona:

Un conjunto de MOs potencialmente relevantes a esta invocación al servicio como un subárbol con una profundidad específica dentro del containment tree. Esta facilidad es llamada scoping. Todos los servicios al menos identifican una clase MOC y una instancia; algunos servicios permiten la selección de objetos múltiples con el parámetro "scope". En estos servicios, el objeto base se refiere al objeto administrable que será utilizado como punto de partida para la selección del ámbito (scoping). El parámetro scope especifica la posición en la jerarquía de objetos. Algunos conjuntos posibles de MOs son "base object only", "nth level below base object", "base object and all subordinate objects up to the nth level" y "base object and complete subordinate subtree". El ambito también facilita el reinicio (reset); por ejemplo, con una sola operación CMIS se puede reinicar "each fifth ports of the interface cards" ó "all the ports of a card".

La posibildad de escoger ciertos objetos de un conjunto a través de filtraje. Un filtro consta de una o más sentencias sobre la existencia o valores de los atributos de los MOs. El filtro es especificado en los parámetros CMIS filter y por consiguinete se utiliza en la selección de objetos relacionados con los atributos. Continuando con el ejemplo mencionado, se podría utilizar el filtraje para decir los siguinete "of the ports listed, only those ports that support HDLC interface and have a connection rate of 64 kbps should be reset" (aquí se está asumiendo que el tipo de interface y la velocidad de la conexión son atributos de la clase port).
Condiciones de sincronización apropiada pueden ser solicitadas cuando más de un objeto MO está siendo accedido. Dependiendo de los requerimientos (si desea conectarse con "todos" los objetos de una lista, o "con los que se pueda"), puede requerirse un chequeode antemano para asegurar que la operación es ejecutable para todos los objetos con los cuales se desea sincronizar.

Como sucede normalmente con los (complejos) servicios de OSI, CMIS también permite subconjuntos agrupados en unidades funcionales (FUs) que siempre describen cierta funcionalidad. Esto permite configurar las entidades CMIS/CMIP. El Kernel FU inicialmente ofrece los servicios de CMIS sin scoping, filtraje o sincronización. Si las funciones suplementarias son requeridas, se debe seleccionar el Multiple-object-selection FU ó el Filter FU junto con el Kernel FU. La unidad funcional Multiple Reply hace posible que más de un reply sea retornado en la respuesta de una misma operación.

La siguiente tabla muestra un resumen de las primitivas de CMIS y sus parámetros.

**Primitivas de CMIS y sus parámetros**
[M : mandatory] [C : conditional] [U : user option] [- : not applicable]
	EVENT- REPORT		GET		SET		ACTION		CREATE		DELETE		CANCEL- GET
	Req	Rsp	Req	Rsp	Req	Rsp	Req	Rsp	Req	Rsp	Req	Rsp	Req	Rsp
Parámetros	Ind	Conf	Ind	Conf	Ind	Conf	Ind	Conf	Ind	Conf	Ind	Conf	Ind	Conf
Invoke Identifier	M	M(=)	M	M	M	M	M	M	M	M(=)	M	M	M	M(=)
Linked Identifier	-	-	-	C	-	C	-	C	-	-	-	C	-	-
Mode	M	-	-	-	M	-	M	-	-	-	M	-	-	-
Base object class	-	-	M	-	M	-	M	-	-	-	M	-	-	-
Base object instance	-	-	M	-	M	-	M	-	-	-	U	-	-	-
Scope	-	-	U	-	U	-	U	-	-	-	U	-	-	-
Filter	-	-	U	-	U	-	U	-	-	-	-	-	-	-
Managed object class	M	U	-	C	-	C	-	C	M	C	-	C	-	-
Managed object instance	M	U	-	C	-	C	-	C	U	C	U	C	-	-
Access control	-	-	U	-	U	-	U	-	U	-	U	-	-	-
Syncronization	-	-	U	-	U	-	U	-	-	-	-	-	-	-
Attribute identifier list	-	-	U	-	-	-	-	-	-	-	-	-	-	-
Modification list	-	-	-	-	M	-	-	-	-	-	-	-	-	-
Get invoke identifier	-	-	-	-	-	-	-	-	-	-	-	-	M	-
Action type	-	-	-	-	-	-	M	C(=)	-	-	-	-	-	-
Action information	-	-	-	-	-	-	U	-	-	-	-	-	-	-
Reference object instance	-	-	-	-	-	-	-	-	U	-	-	-	-	-
Superior object instance	-	-	-	-	-	-	-	-	U	-	-	-	-	-
Attribute list	-	-	-	C	-	U	-	-	U	C	-	-	-	-
Current time	-	U	-	U	-	U	-	U	-	U	-	U	-	-
Action reply	-	-	-	-	-	-	-	C	-	-	-	-	-	-
Event type	M	C(=)	-	-	-	-	-	-	-	-	-	-	-	-
Event time	U	-	-	-	-	-	-	-	-	-	-	-	-	-
Event information	U	-	-	-	-	-	-	-	-	-	-	-	-	-
Event reply	-	C	-	-	-	-	-	-	-	-	-	-	-	-
Errors	-	C	-	C	-	C	-	C	-	C	-	C	-	C

Invoke ID (ID asignado a esta operación), Linked ID (utilizado si multiples respuestas deben ser enviadas para una misma operación), Mode (confirmado o no confirmado), Access control (entrada para las funciones de control de acceso, utilizada en la iteracción entre el manager y el agente), Get invoke ID (ID asignado a la operación M-GET anterior y actual), y Reference-object instance (especifica una instancia existente de un objeto de la misma clase a la que pertenecerá el objeto administrable que será creado).

En las siguientes diagramas de tiempo para el servicio M-GET se muestran tres posibilidades de las diversas que se pueden dar (operación no realizada, respuesta simple, respuesta múltiple).

CMIS también ofrece una lista de valores de error que pueden ser reportados:

**Errores de CMIS**
ERROR	EVENT REPORT	GET	SET	ACTION	CREATE	DELETE	CANCEL GET
Access denied		X	X	X	X	X
Class instance conflict		X	X	X	X	X
Complexity limitation		X	X	X		X
Duplicate invocation	X	X	X	X	X	X	X
Duplicate MO instance					X
Get list error		X
Invalid argument value	X			X
Invalid attribute value					X
Invalid filter		X	X	X		X
Invalid object instance					X
Missing attribute value					X
Invalid scope		X	X	X		X
Mystyped argument		X	X	X	X		X
No such action				X
No such argument	X			X
No such attribute					X
No such event type	X
No such invoke identifier							X
No such object class	X	X	X	X	X	X
No such object instance	X	X	X	X	X	X
No such reference object					X
Processing failure	X	X	X	X	X	X	X
Resource limitation	X	X	X	X	X	X	X
Set list error			X
Sync not supported		X	X	X		X
Unrecognized operation	X	X	X	X	X	X
MO: Managed object

2. Administración de capa (layer management)

La administración de capa trabaja con funciones, servicios y protocolos que son especificados para una capa y no requieren los servicios de otras capas (superiores) del modelo OSI. Ejemplos de funciones de administración específicas de la capa son las pruebas de loop (para la capa física) y el intercambio de administración de enrutamiento (para la capa 3 o internetworking).

Aunque la arquitectura de administración OSI explicitamente designa la administración de capa como una categoría, la ISO poco ha trabajado en esta área -excepto para los protocolos de intercambio de información de enrutamiento y catálogos para los objetos administrados de las capa 3 y 4. Sin embargo, varias especificaciones para administración de capa fueron desarrolladas por la IEEE para los estándares de IEEE 802.X.

La entidad de comunicación de la administración de capa se denomina (N)-Layer Management Entity (LME) y el protocolo correspondiende (N)-Layer Management Protocol. La LME controla las entidades de la capa; esta monitorea información de administración específica a la capa, está habilidada para cargar parámetros del procolo y puede activar o reconfigurar recursos de la capa. Una LME también puede actuar en representación del sistema de administración.

3. Administración de protocolo (protocol management)

Por supuesto, las funciones y la información de administración son también un elemento de los protocolos normales de las diferentes capas. Entre dichos ejemplos están los tamaños de las ventanas, tiempos de espera, parámetros del protocolo para la fase de establecimiento de la conexión, información de errores y elementos de los recursos que soportan la calidad de servicio, etc.

Esto es deseable siempre que se pueda reconocer los diferentes elementos relacionados con la administración del protocolo. Esto ha sido tenido en cuenta en el diseño de los protocolos más nuevos (ISDN, ATM), pero aún queda mucho por hacer.