Arquitectura de administracin OSI

Introduccin
Aunque en la prctica se utilizan arquitecturas de administracin diferentes a la OSI, es importante estudiarla
por dos razones:
1. La arquitectura OSI sirve como base de TMN (Telecommunications Management Network)
2. La arquitectura OSI incluye los cuatro submodelos (informacin, organizacin, comunicacin y
funcional) y por tanto puede ser utilizada como una arquitectura de referencia.
Comparada con la arquitectura de administracin de Internet (donde se utiliza el protocolo SNMP), OSI es ms
compleja, pero ofrece mejores opciones para modelar los objetos administrados. El management frameworkse
describe en el apndice 4 del modelo de referencia OSI de la ISO (ISO 7498-4).
En esta arquitectura las funciones de administracin se realizan a travs de la cooperacin de sistemas
abiertos.
El submodelo de informacin utiliza un enfoque orientado a objetos en la abstraccin de recursos relevantes a
la administracin. Este enfoque permite desarrollar un repertorio amplio para estructurar la base de informacin
de administracin (MIB). Para OSI, una MIB es la coleccin de informacin de administracin que hace visible el
sistema administrado.
El submodelo organizacional est basado en administracin cooperativa distribuida en una red de sistemas
abiertos. Los roles (manager agente) se diferencian de acuerdo con "la actitud" que el sistema adopte frente a
ciertos recursos (es decir, el rol puede cambiar).
El submodelo de comunicaciones est soportado en el modelo de comunicaciones de siete capas de OSI. Este
submodelo incorpora tres mecanismos para el intercambio de informacin de administracin:
1. Comunicacin entre procesos de administracin de la capa 7 (administracin de los sistemas)
2. Comunicacin entre entidades de administracin especficas a una capa (administracin de la capa)
3. Comunicacin entre entidades de protocolo normal (operacin de la capa).
El submodelo funcional subdivide el sistema de administracin en cinco reas funcionales (fault, configuration,
accounting, performance y security) y busca definir funciones de administracin genricas que soporten uno o
ms reas funcionales.

Submodelo de informacin
[Definicin: El submodelo de informacin (de una arquitectura de administracin) busca controlar los mtodos
utilizados para modelar y describir los objetos administrables. Adems, una definicin estndar de objetos
administrables es un prerrequisito para interoperabilidad de la administracin: permite a redes heterogneas
interactuar con propsitos de administracin.]
ISO aplica un enfoque totalmente orientado a objetos para construir su (complejo) modelo de informacin. 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 estn descritas en la managed object boundaryde 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 abstraccin de los recursos desde el punto de
vista de la administracin. Los valores "reales" de los atributos y las operaciones se "mapean" del recurso real.
El modelo de informacin de OSI tambin incorpora la herencia del enfoque orientado a objetos. Una MOC
puede ser definida como una subclase de una o ms superclases, MOC que heredar las caractersticas de las
superclases. Estas caractersticas pueden ser refinadas o expandidas. Un ejemplo de jerarqua hereditaria
sera:

Device
o Printer

Laser printer

HP LaserJet

El soporte de comportamiento alomrfico (allomorphic) es opcional. Esto significa que un recurso concreto (para
ser ms precisos, el MO que lo representa) puede ser visto de diversas formas (del griego llo: otro
ymorph: forma):
como un MO
como una instancia de diferentes MOCs en la jerarqua 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 formulacin de algoritmos
de administracin porque los recursos pueden separarse en grupos que, desde el punto de vista de la
administracin, sern tratados de manera similar. El alomorfismo tambin permite utilizar nuevas versiones de
hardware o software que son administradas por viejas herramientas, facilitando a los proveedores agregar
nuevas caractersticas a sus productos y permitir la interoperabilidad sin tener que adherirse de manera rgida a
las definiciones de clases de objetos estndar.
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 lnea (macro expansion) por la correspondiente definicin de plantilla.
OSI-SMI utiliza las siguientes estructuras genricas 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 ms alto; otras plantillas pueden ser utilizadas para
definir esta de manera ms exacta utilizando una descomposicin descendente (por ejemplo, la clase est
compuesta por paquetes, el paquete est compuesto por atributos, notificaciones, comportamientos y
parmetros).

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 definicin 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 trminos de "reusabilidad" de especificaciones, el modelo de informacin de la arquitectura OSI es
"altamente granular" ya que no slo permite el reuso de las definiciones de MOCs sino que permite el reuso de
cada especificacin de plantilla (template).

Ls descripcin 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 genrico como counters, gauges, thresholds, names, timers al igual que de tipos ms
complejos definidos en ISO 101165-2 en X.721. Los valores y operaciones permitidos estn
especificados para cada atributo, permitiendo restringir rangos de valores y aplicar proteccin 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 travs del uso de un solo comando. Los atributos pueden ser de dos
categoras: singled valued y set valued (El atributo single valued es administrado como un slo dato con
respecto a las modificaciones. Aunque no es obvio, un atributo es considerado de este tipo si un slo
valor un conjunto de valores ordenados se asocia con l. Un atributo set valued es una coleccin de
valores que no est ordenado y se define utilizando la construccin "set of"). Las operaciones
orientadas a atributo exitentes son:
o get: lee el valor de un atributo
o

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 especficas a ese MO (por ejemplo "reset MO"). Una
plantilla (template) de accin es utilizada para especificar acciones. Adems de las acciones
(ACTIONS), que definen libremente operaciones especficas a un MO, hay dos operaciones
predefinidas que siempre afectan al MO en su totalidad: create MO (instanciacin dinmica) 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 estn orientadas a atributos).

Un conjunto de notificaciones (NOTIFICATIONS). Un MO tambin puede ser un recurso autnomo

en el cual pueden ocurrir eventos asincrnicos. Las notificaciones son mecanismos utilizados para
informar sobre eventos que pueden ser iniciados por un MO sin necesidad de que el sistema de
administracin lo solicite. La plantilla (tamplate) de notificacin es utilizada para describir las
notificaciones que pueden (aunque no necesariamente) ser especficas a un MO.

El comportamiento (BEHAVIOUR) respectivo que es especificado en la plantilla de comportamiento.

Esta plantilla (template) registra la semntica de los atributos, las operaciones y las notificaciones e
indica las relaciones con otros MOs, efectos laterales, etctera. El comportamiento generalmente se
describe de manera informal utilizando lenguaje (ingls) normal. Tambin existen enfoques que
incorporan formal descriptions techniques (FDTs) para describir el comportamiento; incluyen un
lenguaje de descripcin y uno de especificacin (SDL, ITU-T Z.100) que han sido agregados a la serie
de estndaraes ISO 10165. Sin embargo, requieren una extensin al lenguaje GDMO (GDMO+).

Paquetes condicionales (CONDITIONAL PACKAGE) que permitan incorporar variantes de ciertas

propiedades y funciones. Cuando se "instancia" un MO, una decisin sobre sus caractersticas es
tomada basada en condiciones if, colocadas en la definicin de la MOC, para saber si dicho paquete
formar parte integral del MO (es decir, el condicional colocado en la plantilla de definicin de la clase
especifica cundo el paquete estar o no estar presente en una instancia de dicha clase). Esto puede

hacer ms fcil mapear un MO a un recurso real. Los paquetes condicionales ofrecen un alto nivel de
flexibilidad en la especificacin al permitir una "asociacin tarda" al recurso real.

La ubicacin de una clase en la jerarqua 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 informacin de la arquitectura OSI

El submodelo de informacin de la arquitectura de administracin OSI utiliza tres estructuras de rbol que
buscan satisfacer diferentes requerimientos.
1. 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 raz de este
rbol no tiene nombre.
2. El rbol de herencia (inheritance tree): contiene las definiciones de las MOCs y muestra como estas
estn relacionadas a travs del uso del principio de herencia. El rbol se construye a partir de las
referencias a las superclases. La raz de este rbol se llama TOP.
3. El rbol de contencin (containment tree): muestra la estructura real de la MIB (Management
Information Base) de un sistema. Tambin es llamado Management Information Tree (MIT). Este rbol
es utilizado para dar el nombre a los objetos administrables. La raz de este rbol se llama ROOT.

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

La jerarqua 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 genrico (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 expansin que se pueden reemplazar -insertarse o
quitarse de algn slot, rack o baha del elemento de red-. Incluye tarjetas de lneas telefnicas,
procesadores, unidades de potencia). Si se crea una instancia de circuit pack, las propiedades de la
superclase sern propiedades de esta instancia.
El rbol de contencin 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 posicin ocupada en el
slot, rack baha (equipment holder). En la jeraqua de clases tanto el slot (equipment holder) como
el circuit pack son subclases de equipment, pero para el rbol de contencin 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 notificacin y tipos de accin. El proceso de
registro provee un valor nico que es una secuencia de nmeros que representan cualquier
informacin. 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 nmeros es nica y slo puede representar la plantilla
(template) que define la clase circuit pack.

NOTA: La arquitectura de administracin de Internet (que utiliza SNMP), en su submodelo de informacin

tambin registra su informacin de administracin, pero slo utiliza el rbol de registro. SNMP no utiliza los
conceptos del enfoque orientado a objetos.
El modelo de informacin de la arquitectura OSI ha predefinido varias MOCs genricas que pueden reutilizarse
como superclases. Entre ellas estn LOG RECORD (la superclase de diferentes registros), DISCRIMINATOR y
SCHEDULER (padres de las MOCs utilizadas para controlar funciones de administracin como reporte de
eventos. Varias entidaes de protocolo tambin 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 administracin de sistemas (ISO 10165-9).

Desde el punto de vista de administracin, los recursos reales pueden ser elementales o compuestos. Por
ejemplo, un hub (concentrador) puede tener ms 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 jerarquas de contenido. MOs compuestos contienen ostros
MOs. Los primeros reciben el nombre de MOs superiores, los ltimos MOs subordinados (definicin de la clase
Hub-Object).
Un atributo obligatorio de la definicin 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 jerarqua de contenido. Cada sistema tiene una raz local (local root) -aunque puede ser
ms de una-, subordinada al rbol de informacin de administracin (MIT) global, quin inicia en la raz global
(ROOT) (ISO 10165-1). Esta jerarqua 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 travs 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 adems 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 concatenacin 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 jerarqua, de manera completa y sin ambigedades un MO. Esto recuerda el modelo de informacin del
servicio de directorio X.500 (ahora LDAP). Un MO se agrega a un nombre nico local en el rbol de nombres a
travs de una plantilla (template) name-binding. La jerarqua de herencia y la jerarqua de contenido son dos
estructuras mutuamente independientes de la MIB. La herencia se relaciona con las clases, el contenido
(contencin) con las instancias.
Los MOs no pueden "sustentarse" de forma autnoma y deben visualizarse en un contexto (es decir, "existen" al
relacionarse con otros MOs). Los atributos pueden ser parte de una relacin, por ejemplo un counter y su
correspondiente valor de umbral (threshold). Los atributos de un MO pueden sealar (apuntar a) otros MOs (por
ejemplo, is-owned-by, is-backed-by). Adems, como se mencion antes, el proceso de name-binding puede
colocar MOs en una relacin de contencin (contenido). Las relaciones tambin pueden ser descritas en las
plantillas de comportamiento. ISO ofrece otra posibilidad: modelamiento de relaciones entre MOs a travs de
un MO de relacin. Un modelo de relacin general (General Relationship Model, GRM) fue desarrollado en los
estndares ISO 10165-7 y en el ITU- X.725. GRM permite que una relacin administrativa sea descrita como
una MOC. Las operaciones definidas para esta clase incluyen bind (que adiciona un MO a una relacin
existente) y unbind; establish (que establece una relacin) y terminate, query (que obtiene informacin sobre las
relaciones) y notify. Los roles y la cardinalidad pueden incluirse en la definicin de la clase. La primera
aplicacin de este estndar (septiembre de 1996) se encuentra en el ambiente de TMN, donde ste se utiliza
para modelar el nivel de red (network).

Submodelo de organizacin
[Definicin: El submodelo de organizacin (de una arquitectura de administracin) define los actores
(elementos que participan en la administracin), sus roles y las reglas de cooperacin entre ellos. Los modelos
de cooperacin pueden ser agent-manager o peer-to-peer. Pueden definirse dominios para agrupar recursos
que sern administrados. En estos dominios se definen polticas (reglas) especficas de administracin. Los
dominios y las polticas son objetos administrables.]
La arquitectura de administracin OSI (ISO 10040) define dos roles para los sistemas: un rol de manager y otro
de agente (agent).

En principio, los sistemas OSI pueden asumir ambos roles, incluso de forma simultnea. La asignacin del rol
puede cambiar dinmicamente dependiendo de los procesos de comunicacin de administracin individual. Los
MOs (objetos administrables) son considerados activos en el sentido que ellos son autnomos para "activar"
notificaciones de eventos asicrnicamente (realmente, es la implementacin del MO dentro del agente quien se
responsabiliza de generar los reportes de eventos; el recurso en s mismo puede ser pasivo). Como lo muestra
la figura, se utiliza un modelo de cooperacin asimtrico.
OSI provee un concepto de dominio extensible y flexible, en el cual se diferencia entre dominio
organizacional y dominio administrativo.

Los dominios organizacionales son MOs (objetos administrables) agrupados...

de acuerdo a la funcin (por ejemplo, para administracin de seguridad, administracin de desempeo,

etc.)
dentro de un rea funcional para facilitar establecer una poltica comn (management procedure class)

asignacin temporal de roles agent y manager.

Los dominios administrativos agrupan los MOs (objetos administrables) que tienen la misma, y nica,
autoridad administrativa. Estos dominios se utilizan para:
crear y manipular dominios organizacionales
controlar el flujo de acciones entre dominios (que pueden llegar a estar traslapados)
Un dominio tambin es un objeto que se puede administrar (es decir, un dominio es un MO -managed object-) y
puede ser descrito con una especificacin para una clase MOC.
Una poltica de administracin, especificada como un conjunto de reglas, puede ser asignada a un dominio.
Estas reglas pueden restringir el comportamiento de los objetos MOs a los cules se les aplique, pero dichas
reglas no pueden contradecir el comportamiento "natural" del objeto MO. Una poltica, al igual que un
dominio, tambin es un objeto administrable -MO-. Los dominios y las polticas se administran con la ayuda de
las funciones de administracin correspondientes que conforman el submodelo funcional.
Para lograr que los sistemas cooperen efectivamente, ellos deben conocer la funcionalidad relevante a la
administracin de los otros sistemas. El trmino management knowledge engloba el conocimiento que
el manager y los agentes deben tener como soporte para ejecutar las diferentes aplicaciones de administracin
en forma dsitribuida. Incluye protocol knowledge (el contexto de las aplicaciones), functional
knowledge (unidades funcionales soportadas y las funciones de administracin de sistemas) y MO
knowledge (MOCs definidas, entidades de MOs). Debido a que muchas versiones concretas de management
knowledge pueden existir, sera til -donde se pueda- "predefinir" perfiles.

Submodelo de comunicaciones
[Definicin: El submodelo de comunicaciones (de una arquitectura de administracin) establece y define los
elementos y conceptos necesarios para que los componentes del sistema (actores) puedan intercambiar
informacin de administracin (por ejemplo, quines pueden comunicarse, especificar los servicios y protocolos,
definir la sintaxis y la semntica de los formatos de intercambio, adems de los protocolos de administracin
que se colocarn dentro de la arquitectura de comunicaciones utilizada). La comunicacin puede establecerse a
travs del intercambio de informacin de control, solicitudes de informacin de estado o generacin de
mensajes de eventos.]
El submodelo de comunicaciones de la arquitectura de administracin OSI incorpora tres categoras diferentes
de administracin: administracin de sistemas (systems management -SM-), administracin de capa (layer
management -LM-) y administracin de protocolo (protocol management, conocido tambin como layer
operation).

La arquitectura de administracin OSI no define cmo las tres categoras de administracin interactuarn, ni
describe el tipo de interaccin que existe con la administracin local (es decir, el sistema operativo). Esto es
compresible desde el punto de vista del submodelo de comunicaciones (es decir, la estandarizacin), pero no
desde el punto de vista de la implementacin. Todas las categoras de administracin tienen acceso a la
informacin puesta en la MIB.
1. Administracin de sistemas
La administracin de sistemas est relacionada con la administracin total de los sistemas en cooperacin. Las
aplicaciones de administracin de sistemas (systems management applications, SMA) involucran la cooperacin
de sus procesos de aplicacin correspondientes (systems management application processes, SMAP). La
administracin induce a relaciones asimtricas, que explica porque un proceso SMAP puede asumir el rol de
manager o de agente para una aplicacin especfica. 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 aplicacin de administracin es la systems management

applications entity (SMAE), que utilizando los propocolos de administracin de sistemas (systems management
protocols) adecuados, intercambia informacin de administracin con las SMAEs de otros sistemas. Este tipo de
comunicaciones de administracin son la norma en la arquitectura de administracin 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 estn CMIP sobre LLC y CMIP sobre SONET ECC.
La arquitectura de administracin de OSI especifica que la informacin de administracin que es intercambiada
entre los procesos de aplicacin sobre los SMAE pueden basarse en servicios diseados especialmente para
eso (ISO 9595, ISO 9596). Estos servicios reciben el nombre de common management information
services (CMIS) y el correspondiente protocolo de administracin 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 informacin completo (containment tree) de la MIB, llamado
elmanagement information tree (MIT). CMIS es(son) un servicio(s) orientado(s) a conexin que utiliza(n)
el association control service element (ACSE) para la administracin de la conexin de servicios y ROSE
(Remote Operation Service Element) para la transmisin de operaciones de administracin. CMIS incorpora los
siguientes grupos de servicios:

Administracin de asociacin: utilizando los servicios ACSE, inicializa (initialitizing), termina

(terminating) y aborta (aborting) conecciones CMIP.
Ejecucin 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 dinmicamente MOs (M-CREATE), borra
MOs (M-DELETE) y cancela operaciones de lectura solicitadas con antelacin (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 sern
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 seleccin de MOs y el paso de parmetros 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
informacin de la arquitectura OSI-NM e incorpora su flexibilidad y capacidades. Para la seleccin de objetos
administrables estos se identifican con la jerarqua del rbol de contencin (containment tree). Para cualquier
servicio, CMIS proporciona:

Un conjunto de MOs potencialmente relevantes a esta invocacin al servicio como un subrbol con una
profundidad especfica 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 seleccin
de objetos mltiples con el parmetro "scope". En estos servicios, el objeto base se refiere al objeto
administrable que ser utilizado como punto de partida para la seleccin del mbito (scoping). El
parmetro scope especifica la posicin en la jerarqua 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 tambin facilita el reinicio
(reset); por ejemplo, con una sola operacin 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 travs de filtraje. Un filtro consta de una o
ms sentencias sobre la existencia o valores de los atributos de los MOs. El filtro es especificado en los
parmetros CMIS filter y por consiguinete se utiliza en la seleccin de objetos relacionados con los
atributos. Continuando con el ejemplo mencionado, se podra 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 conexin son
atributos de la claseport).
Condiciones de sincronizacin apropiada pueden ser solicitadas cuando ms 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
operacin es ejecutable para todos los objetos con los cuales se desea sincronizar.

Como sucede normalmente con los (complejos) servicios de OSI, CMIS tambin 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
sincronizacin. 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 ms de
un reply sea retornado en la respuesta de una misma operacin.
La siguiente tabla muestra un resumen de las primitivas de CMIS y sus parmetros.

EVENTREPORT

CANCELGET

SET

ACTION CREATE DELETE

GET

Re
Rsp
q
Con
Ind
Parmetros
f
Invoke Identifier
M M(=)
Linked Identifier
Mode
M
Base object class
Base object instance
Scope
Filter
Managed object class
M
U
Managed object instance
M
U
Access control
Syncronization
Attribute identifier list
Modification list
Get invoke identifier
Action type
Action information
Reference object instance Superior object instance
Attribute list
Current time
U
Action reply
Event type
M C(=)
Event time
U
Event information
U
Event reply
C
Errors
C

Re
Re
Re
Re
Re
Rsp
Rsp
Rsp
Rsp
Rsp Req Rsp
q
q
q
q
q
Con
Con
Con
Con
Con
Ind
Ind
Ind
Ind
Ind
Ind Conf
f
f
f
f
f
M
M M
M M
M M M(=) M
M
M M(=)
C
C
C
C
M
M
M
M
M
M
M
M
M
M
U
U
U
U
U
U
U
U
C
C
C
M
C
C
C
C
C
U
C
U
C
U
U
U
U
U
U
U
U
U
M
M
M C(=) U
U
U
C
U
U
C
U
U
U
U
U
C
C
C
C
C
C
C

Primitivas de CMIS y sus parmetros

[M : mandatory] [C : conditional] [U : user option] [- : not applicable]
Invoke ID (ID asignado a esta operacin), Linked ID (utilizado si multiples respuestas deben ser enviadas para
una misma operacin), Mode (confirmado o no confirmado), Access control (entrada para las funciones de
control de acceso, utilizada en la iteraccin entre el manager y el agente), Get invoke ID (ID asignado a la
operacin 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 (operacin no realizada, respuesta simple, respuesta mltiple).

CMIS tambin ofrece una lista de valores de error que pueden ser reportados:

ERROR
Access denied
Class instance conflict
Complexity limitation
Duplicate invocation
Duplicate MO instance
Get list error
Invalid argument value

EVENT
REPORT

GET

SET

X
X
X
X

X
X
X
X

ACTION CREATE DELETE

X
X
X
X

X
X

X
X
X
X

X
X
X
X

CANCEL
GET

Invalid attribute value

Invalid filter
Invalid object instance
Missing attribute value
Invalid scope
Mystyped argument
No such action
No such argument
No such attribute
No such event type
No such invoke identifier
No such object class
No such object instance
No such reference object
Processing failure
Resource limitation
Set list error
Sync not supported
Unrecognized operation

X
X

X
X
X

X
X

X
X

X
X
X
X

X
X

X
X
X
X
X

X
X

X
X

X
X

X
X

X
X
X
X
X
X
X
X
MO: Managed object
Errores de CMIS

X
X
X
X
X
X

X
X
X
X
X

X
X
X
X

X
X

X
X

2. Administracin de capa (layer management)

La administracin 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 administracin
especficas de la capa son las pruebas de loop (para la capa fsica) y el intercambio de administracin de
enrutamiento (para la capa 3 o internetworking).
Aunque la arquitectura de administracin OSI explicitamente designa la administracin de capa como una
categora, la ISO poco ha trabajado en esta rea -excepto para los protocolos de intercambio de informacin de
enrutamiento y catlogos para los objetos administrados de las capa 3 y 4. Sin embargo, varias
especificaciones para administracin de capa fueron desarrolladas por la IEEE para los estndares de IEEE
802.X.
La entidad de comunicacin de la administracin 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 informacin de administracin especfica a la capa, est habilidada para cargar parmetros del
procolo y puede activar o reconfigurar recursos de la capa. Una LME tambin puede actuar en representacin
del sistema de administracin.
3. Administracin de protocolo (protocol management)
Por supuesto, las funciones y la informacin de administracin son tambin un elemento de los protocolos
normales de las diferentes capas. Entre dichos ejemplos estn los tamaos de las ventanas, tiempos de espera,
parmetros del protocolo para la fase de establecimiento de la conexin, informacin 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 administracin
del protocolo. Esto ha sido tenido en cuenta en el diseo de los protocolos ms nuevos (ISDN, ATM), pero an
queda mucho por hacer.

Submodelo funcional
[Definicin: El submodelo funcional (de una arquitectura de administracin) divide la complejidad de la
administracin en reas funcionales de administracin e intenta especificar funciones de administracin
genricas. El modelo funcional proporciona las bases para construir libreras de soluciones de administracin
parciales y facilitar la delegacin de funciones de administracin a diversos agentes/personas.]
La administracin OSI tiene cinco reas funcionales: administracin de fallas (fault management),
administracin de configuracin (configuration management), administracin de estadsticas y contabilidad
(accounting management), administracin de desempeo (performance management) y administracin de
seguridad (security management). En ocasiones, cuando en la literatura de redes se hace relacin a estas
reas funcionales se utiliza la sigla FCAPS. Dentro de la arquitectura de administracin 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 revisin general de FCAPS
1.1. Administracin de configuracin
El trmino configuracin tiene un significado diferente, dependiendo del contexto. Una configuracin puede ser:

Una descripcin de un sistema distribuido basada en la ubicacin fsica (y geogrfica) de los recursos
(cables, componentes de red, nodos, software), que incluye "cmo estos recursos estn
interconectados" y la informacin sobre sus relaciones lgicas. Esta descripcin puede abstraerse del
arreglo fsico de los recursos basada en diferentes puntos de vista: organizacional, geogrfico,
administrativo o aspectos relacionados con seguridad.
Un proceso para manipular la estructura del sistema distribuido donde se establecen o modifican
parmetros que controlan la operacin del sistema y ajustan el ambiente requerido para su operacin
normal.
El resultado del proceso de configuracin, el sistema generado (configurado) en el sentido de un
conjunto de ciertos valores de los parmetros que son caractersticos para la operacin normal del
recurso.

El contexto indicar que significado utilizar.

La configuracin, como el proceso de adaptacin de los sistemas a un ambiente operativo, inmplica instalar
nuevo software, actualizar software viejo, conectar dispositivos, hacer cambios en la topologa de la red o en el
trfico de la misma. Aunque la configuracin se acompaa de procedimientos para hacer cambios e
instalaciones fsicas, normalmente es intensiva en procesos controlados por software y ajuste de parmetros
(de configuracin) que incluye entre otros: parmetros de seleccin de funciones, parmetros de autorizacin,
parmetros de los protocolos (longitud de los mensajes, tamaos de ventanas, timers, prioridades), parametros
de conexin (tipo y clases de dispositivo, velocidad de transmisin, paridad), entradas en las tablas de
enrutamiento, servidores de nombres, directorios, al igual que parmetros de filtraje para firewalls y routers (por
direccin, tipo de protocolo), parmetros para el algoritmo de spanning tree, parmetros para los enlaces
conectados a los routers (interfaces, ancho de banda), mxima cuota de los usuarios, etc.
Los siguientes aspectos se presentan en relacin con el proceso de configuracin y las herramientas que
ayudan a configurar componentes:

Lugar desde donde se realiza la configuracin: Una configuracin puede hacerse en el mismo
componente ("me siento frente al router y lo configuro") o puede realizarse de forma remota ("a travs
de un modemrealizo la configuracin"); puedo configurar un componente y copiar esta configuracin a
los componentes similares, o puedo configurarlos desde una estacin seleccionada (estacin de

administracin 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 tcnicas (el editor, el tipo de terminal, los protocolos utilizados no son
compatibles), razones de organizacin de la red o razones de seguridad.
Almacenamiento de la configuracin. La configuracin puede almacenarse en NVRAM, en dicos duro o
diskette (dentro de un componente) haciendo que la configuracin se pueda cambiar rpidamente
cambiando el disco o, incluso, recargando la configuracin a travs de la red. Una configuracin puede
ser almacenada en un boot server y se puede "invocar" a travs de los protocolos adecuados.

Validez de una configuracin. Una configuracin esttica es aquella donde cada reconfiguracin implica
interrumpir la operacin del componente (apagar y prender o reiniciar el sistema). Una configuracin
dinmica, por otra parte, permite hacer cambios en la configuracin 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 parmetros que pueden ser modificados rpidamente o pueden ser aplicados al mismo tiempo a
varios componentes o dispositivos. El sistema de configuracin y la documentacin de la configuracin
deben estar protejidos de uso no autorizado (passwords, reas fsicas restringidas, seguridad del
protolo de configuracin).

La administracin de la configuracin implica establecer parmetros, definir valores de umbral (threshold),

establecer filtros, asignar nombres a los objetos administrados, proveer la documentacin de los cambios de
configuracin y cambiar configuraciones cuando sea necesario. Las herramientas para la administracin de la
configuracin deberan cubrir:
Autotopologa y autodescubrimiento de los componentes de red, permitiendo extrapolar una descripcin
de la configuracin a partir de un ambiente real (la herramienta genera la configuracin de la red
"preguntndole" a los componentes)
Sistemas para describir la documentacin de las configuraciones, bases de datos maestras

Herramientas para generar mapas de red para visualizar datos de configuracin.

Herramientas para activar sistemas de backup de la configuracin actual.

Herramientas para establecer e invocar parmetros de configuracin y estados del sistema

Herramientas para distribuir software y controlar el uso de licencias

Herramientas para supervisar y controlar la autorizacin

1.2. Administracin de fallas

La administracin de fallas est relacionada con la deteccin, aislamiento y elimininacin 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
administracin de fallas en redes de computadores y sistemas distribuidos es ms difcil por una diversidad de
de razones que incluyen, entre otros, el mayor nmero de componentes involucrados, la amplia distribucin
fsica de los recursos, la heterogeneidad de los componentes de hardware/software y los diferentes unidades de
la organizacin involucradas (diferentes personas). Una falla puede ser definida como una desviacin 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, lneas dedicadas,
canales virtuales)
2. El sistema de transmisin (transceivers, concentradores, switches, servidores de acceso, routers)
3. Sistemas finales (clientes, servidores)

4. El software de los componentes

5. La operacin incorrecta por parte de usuarios y operadores.
La funcin de administracin de fallas es detectar y corregir fallas rpidamente para asegurar un alto nivel de
disponibilidad de un sistema distribuido y de los servicios que ste presta. La tareas que involucra son:
Monitoreo del sistema y de la red
Respuesta y atencin a alarmas

Diagnstico de las causas de la falla (aislar la falla y analizar la causa que la origina)

Establecer la propagacin de errores

Presentar y evaluar medidas para recuperarse de los errores

Operacin de sistemas de tiquetes de problemas (trouble tickets systems, TTS)

Proporcionar asistencia a usuarios (help desk)

Las siguientes capacidades tcnicas pueden ayudar en el anlisis de fallas

Autoidentificacin de los componentes del sistema
Poder realizar pruebas, por separado, con los componentes del sistema

Facilidades de seguimiento (tracing)

Disponer de una bitcora (log) de errores

Eco de los mensajes en todas las capas de protocolo

Posibilidad de revisar los vaciados (dumps) de memoria

Mtodos para generar errores a propsito en ambientes predefinidos para el sistema

La posibilidad de iniciar rutinas de autoverificacin y la transmisin de datos de prueba a puertos

especficos (test de loops, test remotos) al igual que pruebas de asequibilidad con paquetes ICMP (ping
o traceroute).

Establecer opciones para valores de umbral

Activacin de reinicios planificados (dirigidos a puertos, grupos de puertos o componentes especficos)

Disponibilidad de sistemas para realizar tests especiales (osciloscopios, reflectmetros, probadores de

interfaces, analizadores de protocolos, monitoreadores de hardware para supervisin de lneas).

Soporte de mecanismos de filtraje para mensajes de fallas o alarmas y correlacin de eventos para
reducir el nmero de eventos relevantes y para anlisis de las causas de los problemas.

Interfaces de herramientas de administracin de fallas a sistemas de tiquetes de problemas y help desk

(soporte tcnico). Es decir, propagacin automtica de notificaciones y correcciones de fallas.

1.3. Administracin del desempeo

En trminos de sus objetivos, la administracin del desempeo podra ser vista como una continuacin
sistemtica de la administracin de fallas. Mientras la administracin 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 administracin de desempeo, que busca que el sistema, como un todo, se comporte bien. Este

"comportarse bien" es el primer problema que debe resolver la administracin del desempeo, es decir, la
definicin 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 organizacin).
Su importancia se incrementa a medida que ms relaciones entre el proveedor y el cliente se involucran en la
implementacin de redes corporativas o sistemas distribuidos. La interface de servicio es definida como sigue:

Especificacin del servicio y el tipo de servicio (determinstico, estadstico, el mejor posible)

Descripcin de los parmetros de QoS relevantes (con valores cuantificables, incluyendo valores de
uso, valores promedio, valores lmite)

Especificacin de las operaciones de monitoreo (informacin relacionada con los mtodos de medida,
puntos de medida, y valores de medida; especificacin del reporte de medida)

Descripcin de reacciones a cambios de los parmetros de QoS mencionados antes.

Sin embargo, es difcil y no siempre es posible proporcionar una definicin completa de una interface de servicio
sobre la base de lo escrito antes. Los siguientes problemas tienden a aparecer:
Problemas en el mapeo vertical de QoS: gracias a que los sistemas de comunicacin son sistemas por
capas, los parmetros de QoS especficos a la capa N tiene que ser mapeado sobre los parmetros de
QoS de las capas (N+1) (N-1). Por ejemplo, un parmetro de la QoS orientada a la aplicacin
(digamos, calidad de transmisin de voz) se debe mapear a la QoS dependiente de la red (jitter). Las
jerarquas de QoS an no estn definidas definitivamente para todas las jerarquas 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 ms de un carrier participa en una red corporativa, el
resultado puede ser la concatenacin 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 caractersticas de calidad de servicio o al menos utiliza
protocolos de negociacin de QoS, protocolos de reservacin de recursos o protocolos de
administracin estandarizados. Cuanto ms complejo sea el servicio, menos probable es que se reunan
estos requerimientos.

Mtodos de medicin: la forma ptima para calcular la QoS sera aplicar mtodos de medida basados
en cantidades visibles en la interface de servicio antes que utilizar un anlisis de la tecnologa
suministrada por el proveedor. La tecnologa puede cambiar rpidamente y, adems, las cantidades
medidas no son de inters del cliente (para l deben ser convertirlas a los parmetros de QoS).

Por lo tanto, la administracin del desempeo incorpora todas las medidas requeridas para asegurar que la
calidad de servicio cumpla con un contrato de nivel de servicios. Esto incluye:
Establecer mtricas y parmetros de calidad de servicio
Monitorear todos los recursos para detectar cuellos de botella en el desempeo y traspasos de los
umbrales

Realizar medidas y anlisis de tendencias para predecir fallas que puedan ocurrir.

Evaluar bitcoras histricas (logs)

Procesar los datos medidos y elaborar reportes de desempeo

Llevar a cabo planificacin de desempeo y de capacidad (capacity planning). Esto implica proporcionar
modelos de prediccin simulados o analticos utilizados para chequear los resultados de nuevas
aplicaciones, mensajes de afinamiento y cambios de configuracin.

Sistemas de monitoreo, analizadores de protocolos, paquetes estadsticos, generadores de reportes y software

de modelamiento son algunas de las herramientas tpicas en esta rea de administracin de redes
(desempeo).
1.4. Administracin de contabilidad (administracin de usuarios)
La administracin de usuarios comprende tareas como administracin 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 utilizacin). Las estrategias y procedimientos para
signacin de costos no puede y no debe ser establecido rgidamente por un sistema de contabilidad; este es
tema de una poltica de arreglo de cuentas (contabilidad). Es importante que la administracin de contabilidad
sea capaz de ajustarse a los lineamientos de una poltica de contabilidad.
La administracin de contabilidad incluye la recopilacin de datos de uso (uso de recursos o de servicios
basados en el monitoreo y la medicin), definir unidades de contabilizacin, asignar cuentas, mantener
bitcoras de contabilidad, asignar costos a las cuentas asignadas, asignar y monitorear las cuotas asignadas,
mantener estadsticas de uso, y finalmente, definir polticas de contabilidad y tarifas, que permitirn generar
facturas y cargos a los usuarios. Si varios proveedores estn involucrados en la prestacin de los servicios, las
reglas de conciliacin tambin pertenecen a la administracin de contabilidad. Este proceso puede realizarse
por un procedimiento de repartir ingresos, mediante una tarifa plana o un precio para cierta unidad de trfico.
Cmo se implemente el sistema de contabilidad, qu enfoque se utilizar para recopilar los parmetros de
contabilidad y cmo sern distribuidos los costos es una decisin administrativa: esta decisin puede ser
influenciada por polticas de la organizacin.
Una vez establecidos los costos fijos y variables de todos los componentes (sistemas de cableado,
componentes de red, trayectorias de conexin, servidores, servicios) para ser incluidos en los clculos, el costo
debe ser asignado al usuario apropiado. Hay muchas formas ingeniosas de recopilar y trasladar estos costos.
Entre ms sutil sea el enfoque ms complicado e intensivo en costos es el procedimiento de contabilidad (los
servicios de contabilidad tambin tienen un costo!)
Los parmetros "de uso" utilizados para calcular los costos incluye la cantidad de paquetes o bytes transmitidos,
duracin de la conexin, ancho de banda y QoS de la conexin, localizacin de los participantes en la
comunicacin, conversin de costos para servicios de gateway, uso de recursos en los servidores, y uso de
productos de software (control de licencias). Adems de los costos variables tambin se tienen en cuenta los
costos fijos (espacio de oficina, costo del mantenimiento, depreciacin de muebles y equipos, etc.).
Para resumir, las funciones de administracin de contabilidad comprenden al menos funciones de
administracin de consumo (generacin, correccin de errores, acumulacin, correlacin, agregacin y
distribucin de consumo; revisin de consumo y validacin de llamadas de solicitudes de servicio), funciones
de procesamiento de contabilidad (pruebas, supervisin, administracin del flujo y administracin de la
recopilacin de datos de consumo), funciones de control (administracin de tarifas, control de cambios en el
sistema de tarifas, control de generacin de registro, control de transferencia de datos, control de
almacenamiento de datos), y funciones de cargos (generacin de cargos, produccin de facturas, proceso de
pagos, recopilacin de deudas, reconciliacin 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 mltiples, diferentes
proveedores, suscriptores mviles, servicio de roaming). De esta forma, la administracin de contabilidad debe
dirigirse a la recopilacin distribuida de datos de consumo, requerimientos de mejoras de desempeo para la
recopilacin de consumo y generacin de reportes (lo ms prximo a tiempo real), y multiples estrategias de
asignacin de cargos.
Los datos necesarios para la administracin de usuarios y la administracin de la contabilidad incluye: detalles
del suscriptor (datos demogrficos, identificacin del contrato, informacin de crdito, historia del suscriptor),

informacin del contrato sobre servicios que cubre, validez del contrato, usuarios autorizados, cuotas, acuerdo
de nivel de servicios, detalles de pagos y facturacin, informacin de tarifas, informacin de consumo y
parmetros del sistema gestin.
A partir de esta lista no exaustiva, es obvio que la administracin de contabilidad tiene una relacin muy
estrecha a la capa de administracin del negocio y los servicios.
1.5. Administracin de seguridad
Esta rea de administracin NO tiene que ver (directamente) con la seguridad de la administracin (es decir,
que la administracin se realice de manera segura) sino con la administracin de la seguridad en los sistemas
distribuidos. El punto de inicio para la discusin son los recursos de la compaa que "vale la pena" proteger. La
informacin, la infraestructutura de IT y los servicios son recursos valiosos y estn expuestos a amenazas o a
un uso inadecuado. Son necesarias, para prevenir daos y perdidas, establecer las medidas de seguridad que
busquen "enfrentar" las amenazas y riesgos obtenidos cono resultado de los anlisis de seguridad del sistema
en red.
Las amenazas tpicas son creadas por:

Ataques pasivos: espionaje de informacin, a travs de anlisis de trfico de la red hecho de forma
oculta (sniffers) para robo de informacin (como passwords)
Ataques activos: suplantacin de usuarios, spoofing, manipulacin de secuencias de mensajes -al
modificar dicha secuencia-, modificacin de los mensajes, manipulacin de los recursos al recargar su
uso, reconfiguracin no autorizada, reprogramacin de sistemas, etctera (acceso no autorizado, virus,
ataques de negacin de servicios, etc.)

Malfuncionamiento de los recursos

Comportamiento inapropiado o deficiente y respuestas de operacin incorrectas

Las metas y los requerimientos de seguridad se establecen a partir de anlisis de amenazas y los valores
(recursos y servicios) que necesitan proteccin. Las polticas de seguridad definidas idenficarn los
requerimientos de seguridad. Ejemplos de polticas de seguridad son "los passwords deben ser cambiados
cada tres semanas", "slo los gerentes de segunda lnea tienen acceso a los datos del personal", "Todos los
ataques que afecten la seguridad del sistema sern registrados y se les har un seguimiento". Estas polticas
sirven como marco de referencia para los servicios de seguridad necesarios y su implementacin. La
administracin de seguridad comprende entonces:
Realizar anlisis de amenazas
Definir e implementar polticas de seguridad

Chequeo de la identidad (autenticacin basada en firmas digitales, certificacin)

Establecer e implementar controles de acceso

Garantizar la confidencialidad (encripcin)

Asegurar la integridad de los datos (autenticacin de mensajes)

Monitoreo de los sistemas para prevenir amenazas de seguridad

Elaborar reportes sobre el estado de la seguridad y su vulneracin o intentos de vulneracin

Podra asumirse que un conjunto de procedimientos de seguridad reconocidos , cuya mayor parte est
disponible como software de dominio pblico, ya existe en el rea de administracin de seguridad.

El principal problema es encontrar la forma correcta de incorporar estos procedimientos a una arquitectura de
administracin y controlarlos de una manera uniforme dentro del marco de las polticas de seguridad.

2. Modelo funcional OSI-NM

En la arquitectura de administracin OSI, para cada una de las SMFAs se han definido cierto nmero de
funciones de administracin generales (Systems Management Functions, SMFs) buscando especificar o detallar
mejor cada rea de administracin FCAPS.

La definicin de una SMF implica la especificacin de las MOCs relacionadas. Cierta SMF puede soportar
requerimientos para una o ms de las SMFAs; un ejemplo es la funcin de administracin de reporte de
eventos. Cada SMF provee un mapeo sobre CMIS. Una aplicacin de administracin puede hacer uso de las
SMFs como funciones predefinidas genricas.
Algunas de las SMFs son funciones tan complejas que, para flexibilidad y reuso, se definen normalmente de
forma general. Modelos para funciones especficas son utilizados para definir las funciones y la informacin de
administracin asociada como clases de objetos de soporte a la administracin. Las funciones especificadas por
la administracin de sistemas OSI (ISO 10164-n) incluye la siguiente lista, en la cual el nmero ncorresponde al
nmero en el documento OSI:

1. Object management function: esta funcin provee un esquema uniforme que resume un nmero de
notificaciones predefinidas para creacin 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 manipulacin entre MOs,

utilizando, por ejemplo, caractersticas como "operado por", reemplazado por, "primario/secundario". Se
tiene una plantilla para describir los roles y las propiedades de MOs relacionados (La interrelacin de
MOC se encuentra descrita en el modelo de informacin de la arquitectura de administracin OSI)

4. Alarm reporting function: esta es una clasificacin 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 definicin de la posible causa y del problema especfico (communicaction protocol error, I/O device
error)

5. Event report management function: esta funcin debe especificar las condiciones que puedan ser
satisfechas por posibles reportes de eventos, que sern enviados a destinos especificados.

6. Log control function: Proporciona las operaciones para recopilar y archivar las notificaciones generadas
por los MOs en bitcoras. Se define un modelo genrico para las bitcoras y su manejo.

7. Security alarm reporting function: es una funcin anloga a la funcin de reporte de alarmas que
relaciona especficamente aquello relacionado con la administracin de seguridad.

8. Security audit trail function: Esta funcin es un refinamiento de la funcin de control de bitcoras (logs)
en la cual los requerimientos relacionados con el archivado y recopilacin de notificaciones y
operaciones relevantes a la seguridad son realizadas a travs de la generacin de reportes especiales.

9. Objects and attributes for access control: una definicin de las operaciones para introducir y manipular
las reglas de control de acceso asegura que los MOs sean protegidos de operaciones de administracin
externa no autorizada. Cuando se realicen (o se intenten) solicitudes de informacin de administracin
no autorizadas debe existir la manera de reportar dicho evento. Esto tambin aplica para al intento de
establecer conexiones de comunicaciones para administracin no autorizadas. La funcin de decisin
de control de acceso (ADF) permite la formulacin de diferentes polticas de seguridad. Sobre esta
base,la funcin deejecucin del control de acceso (AEF), que puede configurarse entre el iniciador y el
objetivo de una funcin de administracin, asegura que las polticas de seguridad sean ejecutadas.

10. Usage metering function for accounting purpose: la definicin de un esquema de descripcin uniforme
para los datos de contabilidad de uso de recursos y las especificacin de la funcionalidad requerida
para recopilar estos datos aseguran que un eficiente y efectivo intercambio de informacin de
contabilidad sea soportado.

11. Metric objects and attributes: un modelo genrico para el monitoreo de umbrales proporciona la
funcionalidad para el monitoreo continuo de atributos dinmicos y la activacin de alarmas cuando los
umbrales seleccionados son excedidos.

12. Test management function: Una taxonoma general para pruebas (tests) es utilizada para proveer
operaciones de inicio y finalizacin 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 ms utilizadas son aquellas de los test de conformidad.

13. Summarization function: esta funcin permite que los datos dentro de un agente sean reprocesados y
reducidos aun antes de ser enviados al sistema de administracin. Los algoritmos estadsticos para
calcular promedios y desviaciones estndar son proporcionados para esta funcin.

14. Confidence and diagnostics test categories: La taxonoma presentada para la funcin de administracin
de pruebas (tests) se refina a travs de la definicin de categoras de pruebas concretas que soportan
tests sobre la disponibilidad y desempeo funcional de los recursos. Ejemplos de categoras 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 administracin sobre la base de
peridos seleccionables. En particular, esta permite que cualquier operacin sea iniciada o terminada
diariamente, semanalmante o mensualmente de forma recurrente.

16. Management knowledge management function: permite a un sistema consultar a otro sobre cules son
las capacidades, relacionadas con la administracin, que soporta. Incluye MOCs soportadas, MIT,
relaciones entre MOs, esquemas de nombres, dominios, polticas y usuarios.

17. Changeover function: permite comunicar relaciones y roles entre MOs que permiten redundancia y
recuperacin de fallas automtica.

18. Software management function: esta funcin se utiliza para modelar la activacin y la desactivacin de
software al igual que los aspectos interactivos de la descarga del software.

19. Management domains and management policy management function: Esta funcin est relacionada con
establecer y administrar dominios y asignar polticas -en otras palabras, reglas o polticas de
comportamientoque deben implementarse.

20. Time management function: define un servicio de tiempo genrico utilizando protocolos de
sincronizacin de tiempo y varios mecanismos de sincronizacin de tiempo con propsitos de
administracin.

21. Command sequencer: Este mecanismo de control utiliza un lenguaje de scripting para la ejecucin de
funciones de administracin. Puede mejorar la forma en que la funcionalidad de la administracin es
"elaborada" para un agente permitindole la delegacin dinmica, a travs de scripts antes que una
implementacin esttica. Este SMF es el enfoque que tiene OSI para la administracin por delegacin.

22. Response time monitoring function: esta funcin mide retardos y retardos de ida y vuelta (round-trip
delay) de los PDUs para una conexin punto a punto o multicast predeterminada sobre la base de
diferentes procedimientos de evaluacin.
En conexin con la definicin de las SMFs, un amplio rango de especificaciones genricas para clases de
objetos administrables (MOC para soporte y control) fueron estandarizadas para describir objetos para los "log",
objetos para "test", objetos para control, estadsticas, procedimientos de medida de desempeo y
procedimientos de contabilidad (accounting). Vese ISO 10164 e ISO 10165-2.
El modelo funcional est siendo expandido continuamente. Permitiendo as que la funcionalidad de la
administracin sea ms y ms formalizada para ser definida genricamente, permitiendo el reuso como
mdulos de aplicacin dentro de las soluciones de administracin. Otro aspecto importante es que actualmente
se desarrollan lenguajes de administracin por delegacin: dependiendo de la disponibilidad y la necesidad,
podran ser utilizados para asignar dinmicamente cierta funcionalidad de administracin a componentes
individuales del sistema distribuido.