Arquitectura de administración OSI

Submodelo funcional

La administración OSI tiene cinco áreas funcionales: administración de fallas (fault management), administración de configuración (configuration management), administración de estadísticas y contabilidad (accounting management), administración de desempeño (performance management) y administración de seguridad (security management). En ocasiones, cuando en la literatura de redes se hace relación a estas áreas funcionales se utiliza la sigla FCAPS. Dentro de la arquitectura de administración OSI reciben el nombre de Systems Management Functional Areas (SMFAs). Algunos autores presentan funciones diferentes a las del modelo de funciones de la arquitectura OSI (FCAPS).

1. Una revisión general  de FCAPS

1.1. Administración de configuración

El término configuración tiene un significado diferente, dependiendo del contexto. Una configuración puede ser:

• Una descripción de un sistema distribuido basada en la ubicación física (y geográfica) de los recursos (cables, componentes de red, nodos, software), que incluye "cómo estos recursos están interconectados" y la información sobre sus relaciones lógicas. Esta descripción puede abstraerse del arreglo físico de los recursos basada en diferentes puntos de vista: organizacional, geográfico, administrativo o aspectos relacionados con seguridad.
• Un proceso para manipular la estructura del sistema distribuido donde se establecen o modifican parámetros que controlan la operación del sistema y ajustan el ambiente requerido para su operación normal.
• El resultado del proceso de configuración, el sistema generado (configurado) en el sentido de un conjunto de ciertos valores de los parámetros que son característicos para la operación normal del recurso.

La configuración, como el proceso de adaptación de los sistemas a un ambiente operativo, inmplica instalar nuevo software, actualizar software viejo, conectar dispositivos, hacer cambios en la topología de la red o en el tráfico de la misma. Aunque la configuración se acompaña de procedimientos para hacer cambios e instalaciones físicas, normalmente es intensiva en procesos controlados por software y ajuste de parámetros (de configuración) que incluye entre otros: parámetros de selección de funciones, parámetros de autorización, parámetros de los protocolos (longitud de los mensajes, tamaños de ventanas, timers, prioridades), parametros de conexión (tipo y clases de dispositivo, velocidad de transmisión, paridad), entradas en las tablas de enrutamiento, servidores de nombres, directorios, al igual que parámetros de filtraje para firewalls y routers (por dirección, tipo de protocolo), parámetros para el algoritmo de spanning tree, parámetros para los enlaces conectados a los routers (interfaces, ancho de banda), máxima cuota de los usuarios, etc.

Los siguientes aspectos se presentan en relación con el proceso de configuración y las herramientas que ayudan a configurar componentes:

• Lugar desde donde se realiza la configuración: Una configuración puede hacerse en el mismo componente ("me siento frente al router y lo configuro") o puede realizarse de forma remota ("a través de un modem realizo la configuración"); puedo configurar un componente y copiar esta configuración a los componentes similares, o puedo configurarlos desde una estación seleccionada (estación de administración de red) para todos los componentes (por ejemplo, un servidor DHCP).  El sistema que está siendo configurado no siempre es compatible con el sistema desde el cual se está configurando y puede deberse a razones técnicas (el editor, el tipo de terminal, los protocolos utilizados no son compatibles), razones de organización de la red o razones de seguridad.
• Almacenamiento de la configuración. La configuración puede almacenarse en NVRAM, en dicos duro o diskette (dentro de un componente) haciendo que la configuración se pueda cambiar rápidamente cambiando el disco o, incluso, recargando la configuración a través de la red. Una configuración puede ser almacenada en un boot server y se puede "invocar" a través de los protocolos adecuados.
• Validez de una configuración. Una configuración estática es aquella donde cada reconfiguración implica interrumpir la operación del componente (apagar y prender o reiniciar el sistema). Una configuración dinámica, por otra parte, permite hacer cambios en la configuración mientras el componente opera y no se requiere "apagarlo".
• Interface de usuario del configurador. La calidad de de la interface de usuario depende de la magnitud de los parámetros que pueden ser modificados rápidamente o pueden ser aplicados al mismo tiempo a varios componentes o dispositivos. El sistema de configuración y la documentación de la configuración deben estar protejidos de uso no autorizado (passwords, áreas físicas restringidas, seguridad del protolo de configuración).

• Autotopología y autodescubrimiento de los componentes de red, permitiendo extrapolar una descripción de la configuración a partir de un ambiente real (la herramienta genera la configuración de la red "preguntándole" a los componentes)
• Sistemas para describir la documentación de las configuraciones, bases de datos maestras
• Herramientas para generar mapas de red para visualizar datos de configuración.
• Herramientas para activar sistemas de backup de la configuración actual.
• Herramientas para establecer e invocar parámetros de configuración y estados del sistema
• Herramientas para distribuir software y controlar el uso de licencias
• Herramientas para supervisar y controlar la autorización

La administración de fallas está relacionada con la detección, aislamiento y elimininación de comportamientos anormales del sistema. Identificar y hacer el seguimiento de las fallas es un problema operacional importante en todos los sistemas de procesamiento de datos. Comparado con sistemas no conectados a una red, la administración de fallas en redes de computadores y sistemas distribuidos es más difícil por una diversidad de de razones que incluyen, entre otros, el mayor número de componentes involucrados, la amplia distribución física de los recursos, la heterogeneidad de los componentes de hardware/software y los diferentes unidades de la organización involucradas (diferentes personas). Una falla puede ser definida como una desviación de las metas operacionales establecidas, de las funciones del sistema o de los servicios. Los mensajes sobre las fallas son dados a conocer por el mismo componente o por los usuarios del sistema. Algunas de las fuentes de fallas son:

1. Los elementos que conforman los enlaces (cables UTP, cables de fibra óptica, líneas dedicadas, canales virtuales)
2. El sistema de transmisión (transceivers, concentradores, switches, servidores de acceso, routers)
3. Sistemas finales (clientes, servidores)
4. El software de los componentes
5. La operación incorrecta por parte de usuarios y operadores.

• Monitoreo del sistema y de la red
• Respuesta y atención a alarmas
• Diagnóstico de las causas de la falla (aislar la falla y analizar la causa que la origina)
• Establecer la propagación de errores
• Presentar y evaluar medidas para recuperarse de los errores
• Operación de sistemas de tiquetes de problemas (trouble tickets systems, TTS)
• Proporcionar asistencia a usuarios (help desk)

• Autoidentificación de los componentes del sistema
• Poder realizar pruebas, por separado, con los componentes del sistema
• Facilidades de seguimiento (tracing)
• Disponer de una bitácora (log) de errores
• Eco de los mensajes en todas las capas de protocolo
• Posibilidad de revisar los vaciados (dumps) de memoria
• Métodos para generar errores a propósito en ambientes predefinidos para el sistema
• La posibilidad de iniciar rutinas de autoverificación y la transmisión de datos de prueba a puertos específicos (test de loops, test remotos) al igual que pruebas de asequibilidad con paquetes ICMP (ping o traceroute).
• Establecer opciones para valores de umbral
• Activación de reinicios planificados (dirigidos a puertos, grupos de puertos o componentes específicos)
• Disponibilidad de sistemas para realizar tests especiales (osciloscopios, reflectómetros, probadores de interfaces, analizadores de protocolos, monitoreadores de hardware para supervisión de líneas).
• Soporte de mecanismos de filtraje para mensajes de fallas o alarmas y correlación de eventos para reducir el número de eventos relevantes y para análisis de las causas de los problemas.
• Interfaces de herramientas de administración de fallas a sistemas de tiquetes de problemas y help desk (soporte técnico). Es decir, propagación automática de notificaciones y correcciones de fallas.

En términos de sus objetivos, la administración del desempeño podría ser vista como una continuación sistemática de la administración de fallas. Mientras la administración de fallas es la responsable de asegurar que una red de comunicaciones o un sistema distribuido (solamente) opere, no es suficiente para satisfacer los objetivos de la administración de desempeño, que busca que el sistema, como un  todo, se comporte bien. Este "comportarse bien" es el primer problema que debe resolver la administración del desempeño, es decir, la definición de la calidad de servicio.

La calidad de servicio (Quality of Service) es un mecanismo para establecer una interface que permita "negociar" entre el proveedor de servicios (es decir, el responsable de de la red de comunicaciones o de la infraestructura de IT) y el cliente (el usuario de los servicios, que puede ser una persona o una organización). Su importancia se incrementa a medida que más relaciones entre el proveedor y el cliente se involucran en la implementación de redes corporativas o sistemas distribuidos. La interface de servicio es definida como sigue:

• Especificación del servicio y el tipo de servicio (determinístico, estadístico, el mejor posible)
• Descripción de los parámetros de QoS relevantes (con valores cuantificables, incluyendo valores de uso, valores promedio, valores límite)
• Especificación de las operaciones de monitoreo (información relacionada con los métodos de medida, puntos de medida, y valores de medida; especificación del reporte de medida)
• Descripción de reacciones a cambios de los parámetros de QoS mencionados antes.

• Problemas en el mapeo vertical de QoS: gracias a que los sistemas de comunicación son sistemas por capas, los parámetros de QoS específicos a la capa N tiene que ser mapeado sobre los parámetros de QoS de las capas (N+1) ó (N-1). Por ejemplo, un parámetro de la QoS orientada a la aplicación (digamos, calidad de transmisión de voz) se debe mapear a la QoS dependiente de la red (jitter). Las jerarquías de QoS aún no están definidas definitivamente para todas las jerarquías de protocolos ni todos los servicios. Este problema se exacerba cuando los servicios de diferentes capas se proveen por diferentes carriers.
• Problemas en el mapeo horizontal de QoS: si más de un carrier participa en una red corporativa, el resultado puede ser la concatenación de diferentes subredes o secciones de troncales que son utilizadas para proveer un servicio con una calidad uniforme de servicio entre dos usuarios. Se asume que cada carrier tiene implementada las mismas características de calidad de servicio o al menos utiliza protocolos de negociación de QoS, protocolos de reservación de recursos o protocolos de administración estandarizados. Cuanto más complejo sea el servicio, menos probable es que se reunan estos requerimientos.
• Métodos de medición: la forma óptima para calcular la QoS sería aplicar métodos de medida basados en cantidades visibles en la interface de servicio antes que utilizar un análisis de la tecnología suministrada por el proveedor. La tecnología puede cambiar rápidamente y, además, las cantidades medidas no son de interés del cliente (para él deben ser convertirlas a los parámetros de QoS).

• Establecer métricas y parámetros de calidad de servicio
• Monitorear todos los recursos para detectar cuellos de botella en el desempeño y traspasos de los umbrales
• Realizar medidas y análisis de tendencias para predecir fallas que puedan ocurrir.
• Evaluar bitácoras históricas (logs)
• Procesar los datos medidos y elaborar reportes de desempeño
• Llevar a cabo planificación de desempeño y de capacidad (capacity planning). Esto implica proporcionar modelos de predicción simulados o analíticos utilizados para chequear los resultados de nuevas aplicaciones, mensajes de afinamiento y cambios de configuración.

1.4. Administración de contabilidad (administración de usuarios)

La administración de usuarios comprende tareas como administración de los nombres, direcciones, incluyendo los servicios relacionados con directorios, permisos para el uso de los recursos y los servicios de contabilidad del uso de los recursos.

Existen costos asociados al proporcionar servicios de comunicaciones y de servicios que deben ser informados a los usuarios del respectivo servicio (cargos de acceso y de utilización). Las estrategias y procedimientos para signación de costos no puede y no debe ser establecido rígidamente por un sistema de contabilidad; este es tema de una política de arreglo de cuentas (contabilidad). Es importante que la administración de contabilidad sea capaz de ajustarse a los lineamientos de una política de contabilidad.

La administración de contabilidad incluye la recopilación de datos de uso (uso de recursos o de servicios basados en el monitoreo y la medición), definir unidades de contabilización, asignar cuentas, mantener bitácoras de contabilidad, asignar costos a las cuentas asignadas, asignar y monitorear las cuotas asignadas, mantener estadísticas de uso, y finalmente, definir políticas de contabilidad y tarifas, que permitirán generar facturas y cargos a los usuarios. Si varios proveedores están involucrados en la prestación de los servicios, las reglas de conciliación también pertenecen a la administración de contabilidad. Este proceso puede realizarse por un procedimiento de repartir ingresos, mediante una tarifa plana o un precio para cierta unidad de tráfico.

Cómo se implemente el sistema de contabilidad, qué enfoque se utilizará para recopilar los parámetros de contabilidad y cómo serán distribuidos los costos es una decisión administrativa: esta decisión puede ser influenciada por políticas de la organización.

Una vez establecidos los costos fijos y variables de todos los componentes (sistemas de cableado, componentes de red, trayectorias de conexión, servidores, servicios) para ser incluidos en los cálculos, el costo debe ser asignado al usuario apropiado. Hay muchas formas ingeniosas de recopilar y trasladar estos costos. Entre más sutil sea el enfoque más complicado e intensivo en costos es el procedimiento de contabilidad (¡los servicios de contabilidad también tienen un costo!)

Los parámetros "de uso" utilizados para calcular los costos incluye la cantidad de paquetes o bytes transmitidos, duración de la conexión, ancho de banda y QoS de la conexión, localización de los participantes en la comunicación, conversión de costos para servicios de gateway, uso de recursos en los servidores, y uso de productos de software (control de licencias). Además de los costos variables también se tienen en cuenta los costos fijos (espacio de oficina, costo del mantenimiento, depreciación de muebles y equipos, etc.).

Para resumir, las funciones de administración de contabilidad comprenden al menos funciones de administración de consumo (generación, corrección de errores, acumulación, correlación, agregación y distribución de consumo;  revisión de consumo y  validación de llamadas de solicitudes de servicio), funciones de procesamiento de contabilidad (pruebas, supervisión, administración del flujo y administración de la recopilación de datos de consumo), funciones de control (administración de tarifas, control de cambios en el sistema de tarifas, control de generación de registro, control de transferencia de datos, control de almacenamiento de datos), y funciones de cargos (generación de cargos, producción de facturas, proceso de pagos, recopilación de deudas, reconciliación externa, procesamiento de contratos). Muchas de las funciones mencionadas son especialmente importantes para las telcos (proveedores de servicios de telecomunicaciones). En tales ambientes, los servicios son a menudo servicios multired (es decir, nodos de red múltiples, diferentes proveedores, suscriptores móviles, servicio de roaming). De esta forma, la administración de contabilidad debe dirigirse a la recopilación distribuida de datos de consumo, requerimientos de mejoras de desempeño para la recopilación de consumo y generación de reportes (lo más próximo a tiempo real), y multiples estrategias de asignación de cargos.

Los datos necesarios para la administración de usuarios y la administración de la contabilidad incluye: detalles del suscriptor (datos demográficos, identificación del contrato, información de crédito, historia del suscriptor), información del contrato sobre servicios que cubre, validez del contrato, usuarios autorizados, cuotas, acuerdo de nivel de servicios, detalles de pagos y facturación, información de tarifas, información de consumo y parámetros del sistema gestión.

A partir de esta lista no exaustiva, es obvio que la administración de contabilidad tiene una relación muy estrecha a la capa de administración del negocio y los servicios.

1.5. Administración de seguridad

Esta área de administración NO tiene que ver (directamente) con la seguridad de la administración (es decir, que la administración se realice de manera segura) sino con la administración de la seguridad en los sistemas distribuidos. El punto de inicio para la discusión son los recursos de la compañía que "vale la pena" proteger. La información, la infraestructutura de IT y los servicios son recursos valiosos y están expuestos a amenazas o a un uso inadecuado. Son necesarias, para prevenir daños y perdidas, establecer las medidas de seguridad que busquen "enfrentar" las amenazas y riesgos obtenidos cono resultado de los análisis de seguridad del sistema en red.

Las amenazas típicas son creadas por:

• Ataques pasivos: espionaje de información, a través de análisis de tráfico de la red hecho de forma oculta (sniffers) para robo de información (como passwords)
• Ataques activos: suplantación de usuarios, spoofing, manipulación de secuencias de mensajes -al modificar dicha secuencia-, modificación de los mensajes, manipulación de los recursos al recargar su uso, reconfiguración no autorizada, reprogramación de sistemas, etcétera (acceso no autorizado, virus, ataques de negación de servicios, etc.)
• Malfuncionamiento de los recursos
• Comportamiento inapropiado o deficiente y respuestas de operación incorrectas

• Realizar análisis de amenazas
• Definir e implementar políticas de seguridad
• Chequeo de la identidad (autenticación basada en firmas digitales, certificación)
• Establecer e implementar controles de acceso
• Garantizar la confidencialidad (encripción)
• Asegurar la integridad de los datos (autenticación de mensajes)
• Monitoreo de los sistemas para prevenir amenazas de seguridad
• Elaborar reportes sobre el estado de la seguridad y su vulneración o intentos de vulneración

El principal problema es encontrar la forma correcta de incorporar estos procedimientos a una arquitectura de administración y controlarlos de una manera uniforme dentro del marco de las políticas de seguridad.

En la arquitectura de administración OSI, para cada una de las SMFAs se han definido cierto número de funciones de administración generales (Systems Management Functions, SMFs) buscando especificar o detallar mejor cada área de administración FCAPS.

La definición de una SMF implica la especificación de las MOCs relacionadas. Cierta SMF puede soportar requerimientos para una o más de las SMFAs; un ejemplo es la función de administración de reporte de eventos. Cada SMF provee un mapeo sobre CMIS. Una aplicación de administración puede hacer uso de las SMFs como funciones predefinidas genéricas.

Algunas de las SMFs son funciones tan complejas que, para flexibilidad y reuso, se definen normalmente de forma general. Modelos para funciones específicas son utilizados para definir las funciones y la información de administración asociada como clases de objetos de soporte a la administración. Las funciones especificadas por la administración de sistemas OSI (ISO 10164-n) incluye la siguiente lista, en la cual el número n corresponde al número en el documento OSI:

1. Object management function: esta función provee un esquema uniforme que resume un número de notificaciones predefinidas para creación de reportes y borrado de MOs y cambios a los atributos de MOs.
2. State Management function: provee operaciones generales para administrar el estado de los MOs. Implica establecer un modelo general de estados y definir un conjunto de operaciones para controlar y monitorear las transiciones de estado.
3. Attributes for representing relationships: da soporte al establecimiento y a la manipulación entre MOs, utilizando, por ejemplo, características como "operado por", reemplazado por, "primario/secundario". Se tiene una plantilla para describir los roles y las propiedades de MOs relacionados (La interrelación de MOC se encuentra descrita en el modelo de información de la arquitectura de administración OSI)
4. Alarm reporting function: esta es una clasificación general de alarmas (es decir, eventos especiales), de acuerdo al tipo de causa ("communications alarm", "quality of service alarm") y se refina de acuerdo a una definición de la posible causa y del problema específico (communicaction protocol error, I/O device error)
5. Event report management function: esta función debe especificar las condiciones que puedan ser satisfechas por posibles reportes de eventos, que serán enviados a destinos especificados.
6. Log control function: Proporciona las operaciones para recopilar y archivar las notificaciones generadas por los MOs en bitácoras. Se define un modelo genérico para las bitácoras y su manejo.
7. Security alarm reporting function: es una función análoga a la función de reporte de alarmas que relaciona específicamente aquello relacionado con la administración de seguridad.
8. Security audit trail function: Esta función es un refinamiento de la función de control de bitácoras (logs) en la cual los requerimientos relacionados con el archivado y recopilación de notificaciones y operaciones relevantes a la seguridad son realizadas a través de la generación de reportes especiales.
9. Objects and attributes for access control: una definición de las operaciones para introducir y manipular las reglas de control de acceso asegura que los MOs sean protegidos de operaciones de administración externa no autorizada. Cuando se realicen (o se intenten) solicitudes de información de administración no autorizadas debe existir la manera de reportar dicho evento. Esto también aplica para al intento de establecer conexiones de comunicaciones para administración no autorizadas. La función de decisión de control de acceso (ADF) permite la formulación de diferentes políticas de seguridad. Sobre esta base,la función de ejecución del control de acceso (AEF), que puede configurarse entre el iniciador y el objetivo de una función de administración, asegura que las políticas de seguridad sean ejecutadas.
10. Usage metering function for accounting purpose: la definición de un esquema de descripción uniforme para los datos de contabilidad de uso de recursos y las especificación de la funcionalidad requerida para recopilar estos datos aseguran que un eficiente y efectivo intercambio de información de contabilidad sea soportado.
11. Metric objects and attributes: un modelo genérico para el monitoreo de umbrales proporciona la funcionalidad para el monitoreo continuo de atributos dinámicos y la activación de alarmas cuando los umbrales seleccionados son excedidos.
12. Test management function: Una taxonomía general para pruebas (tests) es utilizada para proveer operaciones de inicio y finalización de pruebas y los formatos de intercambio para transmitir los resultados de estas pruebas. Las clases de objetos administrados como Test Perfomer, Test Conductor, Test Objects y Uncontrolled Tests son presentados como parte de este SMF. Las definiciones más utilizadas son aquellas de los test de conformidad.
13. Summarization function: esta función permite que los datos dentro de un agente sean reprocesados y reducidos aun antes de ser enviados al sistema de administración. Los algoritmos estadísticos para calcular promedios y desviaciones estándar son proporcionados para esta función.
14. Confidence and diagnostics test categories: La taxonomía presentada para la función de administración de pruebas (tests) se refina a través de la definición de categorías de pruebas concretas que soportan tests sobre la disponibilidad y desempeño funcional de los recursos. Ejemplos de categorías de tests son: pruebas de recursos internos, pruebas de conectividad, pruebas de integridad de datos, pruebas de de protocolos, etc.
15. Scheduling function: soporta el control de tiempo de operaciones de administración sobre la base de periódos seleccionables. En particular, esta permite que cualquier operación sea iniciada o terminada diariamente, semanalmante o mensualmente de forma recurrente.
16. Management knowledge management function: permite a un sistema consultar a otro sobre cuáles son las capacidades, relacionadas con la administración, que soporta. Incluye MOCs soportadas, MIT, relaciones entre MOs, esquemas de nombres, dominios, políticas y usuarios.
17. Changeover function: permite comunicar relaciones y roles entre MOs que permiten redundancia y recuperación de fallas automática.
18. Software management function: esta función se utiliza para modelar la activación y la desactivación de software al igual que los aspectos interactivos de la descarga del software.
19. Management domains and management policy management function: Esta función está relacionada con establecer y administrar dominios y asignar políticas -en otras palabras, reglas o políticas de comportamientoque deben implementarse.
20. Time management function: define un servicio de tiempo genérico utilizando protocolos de sincronización de tiempo y varios mecanismos de sincronización de tiempo con propósitos de administración.
21. Command sequencer: Este mecanismo de control utiliza un lenguaje de scripting para la ejecución de funciones de administración. Puede mejorar la forma en que la funcionalidad de la administración es "elaborada" para un agente permitiéndole la delegación dinámica, a través de scripts antes que una implementación estática. Este SMF es el enfoque que tiene OSI para la administración por delegación.
22. Response time monitoring function: esta función mide retardos y retardos de ida y vuelta (round-trip delay) de los PDUs para una conexión punto a punto o multicast predeterminada sobre la base de diferentes procedimientos de evaluación.

El modelo funcional está siendo expandido continuamente. Permitiendo así que la funcionalidad de la administración sea más y más formalizada para ser definida genéricamente, permitiendo el reuso como módulos de aplicación dentro de las soluciones de administración. Otro aspecto importante es que actualmente se  desarrollan lenguajes de administración por delegación: dependiendo de la disponibilidad y la necesidad, podrían ser utilizados para asignar dinámicamente cierta funcionalidad de administración a componentes individuales del sistema distribuido.

©Oscar Agudelo.  2000-2001. Todos los derechos reservados.