1

Notas sobre

T M N

Telecommunications Management Network

2

Notas sobre TMN

3.4 Telecommunications Management Network (TMN)

3.4.1 IntroducciónUna red de gestión de telecomunicaciones (Telecommunications Management Network: TMN) presentaun modelo real , orientado a objeto , actualizado y ampliamente aplicable , definido por un número deestándares y basado sobre el modelo de comunicaciones de siete capas OSI (las funciones y arquitecturade TMN son tratadas más adelante).Como consecuencia de la aplicación de la arquitectura de OSI , TMN es bastante similar a la gestión dered OSI basada en CMIP , descripta en la sección 3.4.2.2.2. Sin embargo , no son idénticos: TMN ha sidodesarrollado para su proyección al futuro (los servicios de gestión OSI pueden ser considerados como unsub-set de servicios TMN)Los estándares de gestión de red TMN han sido y son conceptualizados para satisfacer el rango másamplio posible de demandas conocidas hoy , tomando totalmente en consideración requerimientosmodernizados, y con la cooperación de un amplio rango de instituciones estandarizantes involucradas.Las instituciones participantes en la estandarización de TMN ó vinculadas con estas actividades incluyena :

. ITU/T

. ETSI

. ISO

. Network Management Forum

. ANSI , etc.

La idea de manejar objetos gestionados por los Sistemas de Gestión de Red en una manera orientada aobjeto surgió en los principios de los ‘80s , y a posteriori , también comenzó la conceptualización de lagestión OSI.El estudio del concepto de TMN comenzó en 1985 por la ITU. El grupo IV de estudio de la ITU apuntó adesarrollar una manera más comprensiva y estandarizada para manejar elementos de red inteligente en unSistema de Gestión de Red orientada a objeto. Como primer resultado formal , la recomendación M.30 sepublicó en 1988.M.30 resume los principios fundamentales de TMN. Más tarde , se introdujeron varias revisiones y larecomendación M.30 fue sustituida por la recomendación M.3010 en 1991. La primera recomendacióndefiniendo los principios fundamentales fue seguida por varias otras tratando cada aspecto importante deTMN , tal como modelos de gestión de red , funciones de gestión de red , protocolos e interfacesestándares , la manera de gestionar arquitecturas estándar de red (ej. SDH) , interconexión de redes ySistemas de Gestión de Redes , etc. Estándares de TMN han sido también desarrollados y aprobados porel comité T1 de ANSI.Hasta el momento , sin embargo , el campo de tratamiento de los estándares TMN no está completo; sudesarrollo está en progreso. Se planearon nuevos estándares para gestión de red inteligente y paraB-ISDN , etc. También un número de recomendaciones requeridas para gestionar redes ATM estánsiendo desarrolladas actualmente.La serie de recomendaciones de ITU-T relacionadas con TMN se ilustran en la tabla 3.4.1.Los estándares más importantes y relevantes de ANSI incluyen : T1.204 , T1.208 , T1.210 , T1.214 ,T1.214 a , T1.215 , T1.224 , T1.227 , T1.228 , y T1.229. Los estándares de ANSI y de ITU-Tgeneralmente se corresponden a ó están basados en varios estándares de ISO de la serie ISO 9595 , 9596 ,10040 , 10164 y 10165.Los Sistemas de Gestión de Red TMN están concebidos para ser capaces de gestionar:. Redes telefónicas. Redes LAN y WAN. Redes ISDN. Redes de Servicios Móviles. Servicios de Red Inteligente y de Valor Agregado. Redes Digitales avanzadas de Banda Ancha , tales como:

. redes SONET/SDH

. redes ATM

. redes B-ISDN , etc

3

A efectos de facilitar la operación , las implementaciones prácticas de TMN generalmente tienen unainterface gráfica de usuario (GUI).El campo de implementaciones prácticas de Sistemas de Gestión de Red TMN es muy limitado aún.TMNs serán más utilizadas en el curso de la década. En el caso de redes SONET/SDH , sin embargo ,debido a circunstancias favorables y requerimientos especiales , Sistemas de Gestión de Red TMN son deposible predominancia en nuestros días. Esfuerzos recientes apuntan a desarrollar Sistemas de Gestión deRed en el campo en el cual, el concepto de TMN pueda también ser aplicado a redes ATM , ISDN ,B-ISDN , celular móvil , y otros tipos de sistemas de comunicación.

3.4.2 Conceptos claves de la gestión de red

3.4.2.1 EvoluciónTeoría y práctica de la gestión de red han surgido en los primeros tiempos de las telecomunicaciones ,mucho antes que se desarrollaran las tecnologías sofisticadas de comunicación de datos en banda ancha ,tales como SONET/SDH , ATM , etc.Impulsadas por la demanda creciente sobre calidad de red y costos operacionales en aumento (mas

precisamente: por la necesidad de reducir esos costos) , se tornaron más utilizadas las herramientas degestión en redes LAN y WAN ; adicionalmente , en una manera relativamente simple , también seaplicaron medios de gestión en redes analógicas de comunicación de voz (telefonía).Con el incremento de volumen de computadoras y otros dispositivos inteligentes , los elementos desistemas interdependientes tenían que ser interconectados por diferentes herramientas de comunicación(líneas de comunicación de datos , LANs , etc). Redes de gran escala , con topologías complejas hanevolucionado en este sentido. Sin embargo , si una red no opera de modo confiable , sino se puedenidentificar posibles errores por métodos simples , y sino se pueden mantener bajo control a determinadosparámetros operacionales de la red , y eventualmente ser modificados , los usuarios no obtendrándemasiados beneficios de la red implementada con gran costo y penuria.

El desarrollo de Sistemas de Gestión de Red estuvo motivado por la intención de eliminar los problemasenunciados arriba.

4

Eventualmente , la gestión de red apunta a permitir al personal autorizado , a monitorear ó cambiarimportantes parámetros operacionales de la red , utilizando uno ó más terminales de gestión. En lapráctica , los Sistemas de Gestión de Red están implementados con software apropiado , el campo delcual básicamente se extiende a todos los elementos inteligentes de la red y a algunos elementos dehardware suplementarios ubicados en los nodos de la red.La ventaja y resultado de la aplicación de un Sistema de Gestión de Red puede ser resumido como sigue:. Incremento de confiabilidad (disminución de tiempo requerido para detección de error , diagnóstico ycorrección de error , incremento de eficiencia de los esfuerzos apuntados a la corrección de errores , laposibilidad de reenrutar tráfico de red automáticamente si alguna parte de la red opera en déficit). Incremento de seguridad (acceso a la red controlado y regulado para cada usuario y de acuerdo aautorizaciones y autenticaciones predefinidas).. Nuevos servicios provistos a los usuarios de red (adquisición de información de tarificación , de tráfico ,etc).. Monitoreo computarizado efectivo de sistema (almacenando información de tarificación , estadística,seguimiento y evaluación de carga y performance de la red , así como estadísticas de errores , soporte deestrategias de desarrollo de red , etc.)

En conclusión , los objetivos de los Sistemas de Gestión de Red son:. Costos operacionales decrecientes. Aumento en la calidad de los servicios.

El logro de estos objetivos es compartido por :. Usuarios. Operadores de red. Proveedores de servicios. Fabricantes de equipamiento de comunicaciones

La operación de un Sistema de Gestión de Red prácticamente significa ejecutar los siguientes pasosesenciales:a. Adquirir y recolectar datos característicos acerca de los elementos de la red , acerca de su operación einterrelación en la red (condiciones operacionales , performance , condiciones de falla y tipos deeventuales malos funcionamientos , relación entre elementos vecinos , parámetros de tráfico y carga , etc.)b. Almacenar y evaluar los datos recolectados a través de un centro de procesamiento de datos delsistema.c. Controlar la operación de la red (modificando la funcionalidad de algunos elementos en la red si esnecesario) como conclusión y resultado de la evaluación.En la medida en que un Sistema de Gestión de Red debe ejecutar tareas de gestión de servicios y /onegocios (ver sección 3.4.3.3) , pueden ser necesario pasos adicionales como parte de la operación , talescomo:d. Registro de contratos de servicio y gestión de servicios de clientee. Elaboración de planes de negocios y diseños técnicosf. Modelado y simulación de procesos técnicos y/o financieros , etc

Notar que la demanda de ejecución de los pasos operacionales listados de a) a f) requiere la habilidad deuna arquitectura de red sofisticada , la presencia de elementos de red apropiadamente elaborados , asícomo un Sistema de Gestión de Red apropiado. Esto significa que las técnicas eficientes de gestión de redpueden ser consideradas como resultado de una asociación y desarrollo inseparables de las tecnologías decomunicación LAN/WAN y los métodos de gestión de red propiamente dichos. La gestión de red esenriquecida con más y más herramientas efectivas por la evolución de las tecnologías de lascomunicaciones.En lo que concierne a las soluciones de red actuales , no todos los pasos arriba descriptos han sidocomúnmente percibidos y elaborados hasta ahora.La cronología de la evolución viene representada también por la secuencia de items a) a f). En el primerescalón de desarrollo , la “gestión de red” estaba limitada a simplemente visualizar condiciones de falla(por ejemplo , por el destello de indicadores luminosos en el equipo) y supervisarlas por parte delpersonal operativo. De acuerdo al sentido presente de la terminología no puede ser considerada enabsoluto como gestión de red. El primer paso significativo en el camino para lograr una supervisión dered eficiente , fue la asociación de las condiciones de falla y otros parámetros del sistema porcomputadoras , y su almacenamiento automático. La disponibilidad de los datos almacenados proveyeron

5

una oportunidad conveniente para su evaluación programada. El incremento en el tamaño de la red yvolumen de los datos resultaron en la mejora de los algoritmos de evaluación.Los datos colectados y su evaluación permitieron luego que la operación apropiada de la red se restaureautomáticamente en el caso de ciertas fallas del sistema (ej.: por medio de elementos de sistema stand-by/hot stand-by ó mediante una predeterminada reconfiguración del sistema). El control de la operación dela red por parte de un Sistema de Gestión de Red fue aplicado únicamente en LANs sofisticadas por unconsiderable período de tiempo. Las redes WAN tradicionales , sin embargo , basadas en tecnología PDHampliamente utilizada aún hoy , ofreció un número limitado de medios para un control de red apropiado.Como efecto de la nuevas tecnologías de comunicación (tal como SONET/SDH y ATM) el contrasteusual entre LANs y WANs , comunicación de voz y datos , tiende a desvanecerse ó desaparecer. Este esun momento importante en la promoción de la evolución de los métodos de gestión de red yprobablemente resulte en una teoría homogénea de gestión de red. Productos reales de gestión de redapropiados para satisfacer gestión de servicios , planeamiento tanto de negocios como técnico , y tareasde modelado , están apareciendo en estos días.TMN es un estándar de gestión actualizado que permite la construcción de Sistemas de Gestión de Redcon el más comprensivo set de funciones de gestión de red explotando las facilidades de las másactualizadas tecnologías de comunicación.

3.4.2.2 Sistemas estándares de Gestión de Red.En general , diferentes tipos de redes (LANs , WANs , ISDN , sistemas de comunicación de voz y datos ,tanto como redes públicas y privadas , etc) establecen diferentes requerimientos para la gestión de red.Como se vió anteriormente , en el transcurso del desarrollo tecnológico , los sistemas de gestión setornaron apropiados para completar un número creciente de tareas. Al principio , sin embargo , elloscomprendieron componentes hardware-software individuales , de proveedores específicos , y comoconsecuencia , los Sistemas de Gestión de Red de diferentes proveedores se desarrollaron en direccionesdiversas y específicas.A efectos de evitar esta confusa situación , de acuerdo con la filosofía de los sistemas abiertos recientes ,la interconectividad de diferentes redes debe ser asegurada: las redes y sus sistemas de gestión tienen queser operadas en un ambiente multiproveedor. Consecuentemente , en orden a cumplir con esterequerimiento , estándares internacionales tienen que definir las características sustanciales de losSistemas de Gestión de Red (interfaces , protocolos , arquitectura de sistemas , etc). La importancia de laestandarización es aún creciente.El amplio rango de recomendaciones elaboradas y/ó aceptadas por la mayoría de las institucionesinternacionales de estandarización (ANSI , CCITT , ITU-T sucesor de CCITT en 1993 , ISO , IEC , ETSI, etc , y especialmente el Network Management Forum) apunta a la independencia de usuariointernacionalmente aceptada respecto a los equipos de los fabricantes / proveedores. Prácticamente , apesar de los esfuerzos para estandarizar características cruciales de los sistemas (similar a algunos otroscampos de las soluciones hardware / software) , hay varios sistemas de gestión compitiendo entre sí en elmercado mostrando un grado limitado de estandarización. Los sistemas basados en estándares de factoson también a menudo considerados como sistemas estándar.Los Sistemas de Gestión de Red más frecuentemente utilizados en los 90s , fueron los siguientes:. gestión basada en SNMP. gestión basada en (OSI) CMIP. TMN

3.4.2.2.1 Gestión basada en SNMPEl estándar de gestión de red , Simple Network Management Protocol (SNMP) referente al protocoloaplicado , ha sido definido por la Comunidad de Internet (Internet Community) para gestionar redes queimplementan el suite de protocolos TCP/IP , tales como LANs Ethernet y segmentos Internet. SNMP esun estándar de facto , y ha estado disponible desde 1990. La estandarización de su segunda versión(SNMPv2) fue requerida en 1993 y concluida en 1994.En realidad , SNMP es un set de estándares de protocolos que definen las reglas del intercambio deinformación entre las entidades del software de gestión de red ; esto es , entre el gestor (manager) , elagente (agent) , y la base de información de gestión (Management Information Base: MIB).El gestor (manager) es un elemento de software que se ejecuta en la estación de gestión de red y cumpleel rol de mediador entre el operador humano y el Sistema de Gestión de Red propiamente dicho.El agente (agent) es el elemento de software instalado en los elementos inteligentes de red gestionados yrepresenta a los recursos gestionados de esos elementos.MIB es la base de datos lógica conteniendo información de gestión de red local residente en cada uno delos agentes. El gestor está a cargo del comando de un superset de MIBs de agentes. La MIB puede incluir

6

un número de objetos estándar. Los tipos de objetos estándar son acomodados (de acuerdo a la sintaxis desu nombre estándar) en una estructura jerárquica de árbol aplicada en la gestión de TCP/IP ,constituyendo la estructura de información de gestión (Structure of Management Information: SMI). Cadanodo del árbol representa un grupo de objetos gestionados , y cada grupo incluye un número de objetos.Cada objeto puede tener valores. El valor actual de un objeto gestionado refleja el estado presente delrecurso gestionado representado por el objeto en cuestión. Los valores de los objetos deben cumplir con ladefinición de tipo del objeto dado. Los tipos de objetos permitidos están también definidos , tales comoentero (integer) , cadena de bit (bit string) , etc. Los objetos estándar involucrados son descriptos con unasintaxis estandarizada , definida en la recomendación X.208 de la ITU-T , conocida como notaciónsintáctica abstracta uno (Abstract Syntax Notation One: ASN.1). Esto significa que SMI es similar a lagestión basada en (OSI) CMIP , pero los objetos definidos en SNMP son diferentes (ver sección 3.4.2.2).El gestor puede enviar requerimientos (request) periódicamente a los agentes , a efectos de colectarinformación actual acerca de su estado (polling) , ó para modificar variables de las MIBs de los agentes.Concordantemente , los tipos de requerimientos de los gestores son GET y SET. El agente puede tambiénenviar un TRAP al gestor automáticamente a efectos de notificarle de un evento si es necesario.A pesar de la disponibilidad de TRAPs , SNMP es un protocolo básicamente soportado en polling , y noregido por eventos. Es principalmente concebido para proveer funcionalidad de gestión a nivel de red yde elemento de red. En oposición a la gestión de red OSI (CMIP) ó TMN , el modelo de objeto de SNMPes menos flexible y menos eficiente.SNMP no puede ser considerado como un verdadero Sistema de Gestión de Red orientado a objeto.Las diferencias entre SNMPv1 y SNMPv2 son de importancia , siendo una de las mejoras que SNMPv2(a diferencia de SNMPv1) puede soportar comunicación entre entidades de gestor.Una de sus ventajas , sin embargo , es que puede ser operado facilmente y no requiere recursos dehardware sofisticados. Como consecuencia práctica , a pesar de todas sus desventajas , los Sistemas deGestión de Red basados en SNMP son también competidores significantes de la gestión de red OSI , yhan sido más ampliamente utilizados hasta ahora. Como una tendencia en el desarrollo de la tecnología delas comunicaciones , se deben mencionar lo esfuerzos que se han hecho para asegurar la interoperabilidadde los diferentes Sistemas de Gestión de Red , tales como SNMP ,OSI/CMIP , y TMN.Los Sistemas de Gestión de Red SNMP son primariamente aplicados para gestionar:. LANs y redes corporativas basadas en TCP/IP. segmentos de red InternetSin dejar de lado que TMN es considerado como el Sistema de Gestión de Red ideal para redes SDH yATM , los productos de red ATM existentes permiten , predominantemente , la aplicación de SNMP ,dada la actual carencia de estándares TMN apropiados.

3.4.2.2.2 Gestión basada en CMIPLa gestión basada en (OSI) CMIP define un verdadero Sistema de Gestión de Red orientado a objetobasado en la arquitectura de comunicaciones de OSI de siete capas.. (El modelo de referencia OSI sedefine en la series de recomendaciones X.200 de CCITT/ITU-T , y en estándar 7498 de ISO). Laestandarización del modelo OSI comenzó en los últimos años de los 80s , y no ha sido totalmenteterminado hasta ahora. Los primeros estándares de gestión de OSI fueron definidos por ISO ; más tardefueron adoptados y desarrollados por CCITT/ITU-T (recomendaciones de la serie X.700) y otrosinstitutos de estandarización.Los Sistemas de Gestión de Red basados en (OSI) CMIP pueden ser aplicados para gestionar:. Redes de área local (LANs). Redes corporativas y redes privadas de área amplia (WANs). Redes nacionales e internacionalesEl protocolo de séptima capa (aplicación) utilizado por la gestión OSI es el protocolo común deinformación de gestión (Common Management Information Protocol: CMIP). En un ambiente degestión basado en (OSI) CMIP , el proceso de aplicación de usuario (cuya operación está basada en elprincipio de manager/agent) es provisto con el servicio común de información de gestión (CommonManagement Information Service: CMIS) en función de una interface de programa de aplicación (API)por la denominada entidad de aplicación de gestión de sistemas (Systems Management ApplicationEntity: SMAE) , la cual está implementada en la séptima capa (Aplicación) del modelo de siete capasISO/OSI.

(La operación de la gestión está basada en el principio de manager/agent. Las funciones de manager ,agent , y MIB son básicamente similares a las de SNMP , ó mas característicamente a las de TMN. Versecciones 3.4.2.2.1 y 3.4.3.5 respectivamente)

7

Los siguientes son los elementos más importantes de la interface de programa de aplicación de gestiónOSI:. elemento común de servicio de información de gestión (Common Management Information Service

Element: CMISE). elemento de servicio de operación remota (Remote Operation Service Element: ROSE). elemento de servicio de aplicación de gestión de sistemas (Systems Management Application Service

Element: SMASE). elemento de servicio de control de asociación (Association Control Service Element: ACSE). transferencia de archivo , acceso , y gestión (File Transfer , Access , and Management: FTAM)

El CMISE es responsable por la generación de requerimientos (requests) estándares básicos y elprocesamiento de mensajes de respuesta según lo definido por el CMIS. El CMIS puede ser utilizado porun proceso de aplicación en un ambiente de gestión centralizado ó descentralizado para intercambiarinformación y comandos para el propósito de sistemas de gestión. (ver recomendación X.710 de ITU-T).El ROSE controla y supervisa las interacciones entre entidades remotas de una aplicación distribuida ,donde esas interacciones pueden ser modeladas y soportadas como operaciones remotas. Una operaciónremota es requerida por una entidad ; la otra entidad intenta ejecutar la operación remota y luego reportarel resultado del intento. (Ver recomendaciones X.219 y X.229 de ITU-T).El SMASE provee servicios (de gestión de sistemas) que dan soporte a funciones de gestión específicas(ver recomendación X.750 de ITU-T).El ACSE es responsable de ejecutar la negociación inicial a efectos de decidir si se puede establecer unaconexión de datos y ponerla a disposición de la comunicación. De acuerdo a la definición de larecomendación X.217: “ ACSE provee facilidades básicas para el control de una asociación de aplicaciónentre dos entidades de aplicación. ACSE incluye dos unidades funcionales opcionales. Una unidadfuncional soporta el intercambio de información soportando autenticación durante el establecimiento de laasociación. La segunda unidad funcional soporta la negociación del contexto de aplicación durante elestablecimiento de la asociación” (ver recomendaciones X.217 y X.227 de la ITU-T)FTAM organiza y gestiona acceso a archivos para propósitos de aplicación , de acuerdo a lasespecificaciones de ANS.1 (ver recomendación X.209 de ITU-T).En términos del principio de manager/agent , el manager como un elemento de software del sistemapuede generar operaciones de gestión en la forma de requests CMIS a cualquiera de los agentes softwarevía el protocolo de gestión CMIP. El agente retransmite esos requests a los objetos gestionados (managedobjects: MOs) correspondientes , los cuales representan los recursos físicos y lógicos a ser gestionados ,y los ejecuta sobre los MOs apropiados.CMIP puede también proveer reportes manejados por eventos para el manager y puede identificar eventossubstanciales que influenciaron el estado de los objetos gestionados.Los requests CMIP/CMIS , generados por el manager al agente a efectos de iniciar una operación , sonlos siguientes:. M-GET (obtiene un valor de atributo de uno ó más objetos gestionados). M-SET (establece/modifica el valor de atributo de uno ó más objetos gestionados). M-ACTION (ejecuta una acción específica sobre uno ó más objetos gestionados). M-CREATE (crea un nuevo objeto gestionado). M-DELETE (elimina uno ó más objetos gestionados). M-CANCEL-GET (cancela una operación M-GET requerida previamente y aún pendiente)

Adicionalmente , el agent puede enviar al manager:. M-EVENT-REPORT (notifica al manager acerca de un evento que aconteció en el objeto gestionado)

La selección de los objetos gestionados que tienen que ser afectados por una operación CMIP/CMIS dada, es facilitada por la observación y el filtrado. La observación establece la identificación de los objetosgestionados a los cuales se les va a aplicar un filtro. El filtrado establece un conjunto de tests a cadamiembro del grupo de los objetos gestionados , previamente observados , para extraer un subset de ellos.El modelo de objeto de la gestión OSI está basado en las recomendaciones X.722 de CCITT/ITU-T ,ampliamente conocida como GDMO( Guidelines for the Definition of Managed Objects). La estructurade información de gestión (SMI) está descripta en las recomendaciones X.720 de CCITT/ITU-T. SMI essimilar a aquella de SNMP ; sin embargo , los objetos estándar involucrados y sus atributos sondiferentes. Los objetos estándar en la gestión OSI son también descriptos utilizando sintaxis ASN.1 ,definida en la recomendación X.208 de ITU-T.

8

CMIP es un protocolo real manejado por eventos ; el modelo de objeto de GDMO es más comprensibleque aquél de SNMP. Eso significa que la gestión OSI es más apropiada para gestionar redes grandes ycomplejas.La aplicación de Sistemas de Gestión de Red basados en (OSI) CMIP se está difundiendo gradualmente.Su significancia crecerá en el futuro (particularmente para proveedores de servicios detelecomunicaciones). Sin embargo , TMN , como sistema de gestión estandarizado , más comprensible ,basado en OSI , parece ser un muy fuerte competidor de CMIP.

3.4.3 Funciones y Arquitectura de una TMNLas funciones y arquitectura de una TMN pueden ser consideradas en varias dimensiones. Cadadimensión está definida (ó será definida) por estándares existentes (ó en desarrollo).Las recomendaciones M.3010 de la ITU-T tratan:. Funciones asociadas con TMN. Aspectos de arquitecturas TMN. Arquitectura lógica estratificada de TMNLas funciones asociadas con una TMN están clasificadas en términos de la gestión OSI ;concordantemente , se definen cinco áreas funcionales de gestión en la sección 3.4.3.1En lo que concierne a la arquitectura general de TMN , se consideran tres aspectos básicos en ITU-TM.3010:. Arquitectura funcional de TMN. Arquitectura de información de TMN. Arquitectura física de TMNAdicionalmente , M.3010 describe cuatro+uno estratos de gestiónTodos estos aspectos serán tratados aquí en secuencia didáctica , diferentemente a su orden en M.3010

3.4.3.1 Arquitectura funcionalLa arquitectura funcional de TMN está basada en un número de bloques de función TMN. Estosrepresentan las funciones apropiadas requeridas por TMN para cumplir su función general de gestión dered. Estas son realmente ejecutadas por elementos de la arquitectura física de TMN (ver sección 3.4.3.2).De acuerdo a la recomendación M.3010 , algunos de los bloques de función están parcialmente dentro yparcialmente fuera de TMN. Esos bloques de función son el bloque de función workstation (estación detrabajo) , el bloque de función Q adaptor (adaptador Q) , y el bloque de función network element(elemento de red). Esto significa que estos bloques de función (además de aquellas funciones definidaspor la recomendación M.3010) pueden incluir un rango de funcionalidad (y proveerlas por parte de TMN)no cubierto por las recomendaciones TMN.La recomendación M.3010 define cinco bloques de función:

. Bloque de función de sistemas de operaciones (Operations Systems Function: OSF)

. Bloque de función de elemento de red (Network Element Function: NEF)

. Bloque de función de estación de trabajo (Worstation Function: WSF)

. Bloque de función de mediación (Mediation Function: MF)

. Bloque de función de adaptador Q (Q Adaptaor Function: QAF)

Los requerimientos de comunicación de datos de estos bloques de función son satisfechos por la

. Función de comunicación de datos (Data Communication Function: DCF)

El bloque OSF procesa información relacionada a la gestión de telecomunicaciones con el propósito demonitorear/coordinar y/ó controlar funciones de telecomunicaciones incluyendo funciones de gestión.El bloque NEF se comunica con la TMN con el propósito de ser monitoreado y/ó controlado.El NEF también incluye funciones de telecomunicaciones que son materia de gestión , pero no son partede la TMN. Estas funciones están representadas para la TMN por el NEF.El bloque WSF provee los medios para interpretar la información de TMN por parte del usuario , yviceversa. Partes de WSF pueden también estar ubicadas fuera del campo de TMN.El bloque MF actúa sobre la información transferida entre un OSF y un NEF ó QAF para asegurar que lainformación satisfaga las expectativas de los bloques de función asociados al MF.El bloque QAF es utilizado para conectar un bloque de función similar a NEF (no-TMN-compatible) conun OSF , ó un bloque de función similar a OSF (no-TMN-compatible) con un NEF. Esto significa que lainformación entre un bloque de función TMN-compatible y un bloque de función no-TMN-compatible

9

será traducida por el QAF. Una parte dada de las funciones del QAF están definitivamente fuera de laTMN.Cada uno de los bloques de función antes mencionados está compuesto de componentes funcionalesbásicos , los cuales han sido identificados como bloques elementales de construcción de la TMN.DCF se aplica a transferir información entre los bloques de función TMN.Cada par de bloques funcionales de TMN que intercambian información de gestión , están separados porpuntos de referencia: esto es , los puntos de referencia son fronteras entre dos bloques de función degestión.Se definen tres clases de puntos de referencia en términos de TMN:

. Puntos de referencia q

. Puntos de referencia f

. Puntos de referencia x

Adicionalmente , se consideran dos clases de puntos de referencia no-TMN:

. Puntos de referencia g

. Puntos de referencia m

Las definiciones de estos puntos de referencia serán explicadas en la sección 3.4.3.2 , en conexión con laarquitectura física de TMN.

3.4.3.2 Arquitectura FísicaLa arquitectura física de TMN describe los bloques de construcción física (elementos físicos) de unsistema de gestión de red TMN y contiene reglas exactas para sus relaciones. El estándar relacionado esla recomendación CCITT/ITU-T M.3010.La M.3010 define los elementos físicos de TMN como sigue:

. Sistema de operaciones (Operations System: OS)

. Estación de trabajo (Workstation: WS)

. Elemento de red (Network Element: NE)

. Red de comunicación de datos (Data Communication Network: DCN)

. Dispositivo de mediación (Mediation Device: MD)

. Adaptador Q (Q Adaptor: QA)

Adicionalmente , M.3010 también define reglas para el intercambio de datos entre elementos físicos :

. Interfaces estándares

Las interfaces estándares definen:

. Suite de protocolo

. Los mensajes transportados por el protocolo

El OS ejecuta funciones del sistema de operaciones (OSFs , ver sección 3.4.3.1). Este , prácticamente esel corazón en si mismo , responsable por la gestión de la red controlando la operación de sus elementos.En lo que a su realización respecta , el OS está básicamente constituido por uno ó más centros deprocesamiento , ejecutando la tarea de juntar información desde los elementos de red y procesándola deacuerdo a las funciones del Sistema de Gestión de Red. (Apropiadamente ,el sistema de operacionescumple los requerimientos de los sistemas abiertos).Conectado a una y la misma red , más de un sistema de operaciones puede participar en los procesos degestión. Basado sobre el principio de división de tareas , ellos pueden ejecutar un set predefinido de tareasy estar interconectados a través de la red de comunicación de datos.La WS ejecuta funciones de workstation (WSFs). Ellas son la representación física de las interfaceshombre-máquina necesarias por medio de las cuales los operadores pueden comunicarse con la TMN.Las workstations son preferiblemente computadoras en si mismas , equipadas con capacidades gráficaseficientes a efectos de ser capaces de satisfacer los requerimientos de los operadores.Los NEs ejecutan funciones de elemento de red (NEFs). Los NEs son básicamente , dispositivos detelecomunicaciones gestionables (ej.: switches , multiplexores , cross-conects) ubicados en los nodos dela red a ser gestionada. Ellos proveen las funciones adecuadas en la operación de red , y usualmente

10

pueden ser identificados con una dirección simple por el sistema de operaciones de la TMN. Las partesdel equipamiento que constituyen los elementos de red son dispositivos inteligentes controlados por suspropias microcomputadoras y equipados con interfaces estándares. A través de la interface estándar , elelemento de red puede transferir mensajes hacia la estación de operaciones e informarle acerca del estadoactual de los elementos y recibir comandos de control desde ella. Generalmente , los elementos de red sondispositivos que cumplen con los requerimientos de las recomendaciones TMN ; sin embargo , loselementos de red que no cumplen los estándares TMN pueden también formar parte de la red detelecomunicaciones.La DCN es una red que ejecuta la función de comunicación de datos (DCF). Esta transmite mensajesrequeridos para ejecutar funciones de gestión entre el OS y los NEs. La información es intercambiada através de la DCN , usando protocolos estándares según lo establecido por las interfaces estándares. Larecomendación M.3010 de CCITT/ITU-T define la red de comunicación de datos de un Sistema deGestión de Red TMN en términos abstractos. En la práctica , esta red puede ser implementadaseparadamente de la red de telecomunicaciones gestionada (ej.: puede ser implementada con líneasarrendadas , utilizar la red pública de datos, etc) , ó aun , (parcial ó completamente) por la propia redgestionada. Si la DCN utilizada para propósitos de gestión es implementada independientemente de la redgestionada , esto resultará en la ventaja de que los problemas en la red de telecomunicaciones gestionadano afectarán la funcionalidad del sistema de gestión. Una desventaja obvia de este método comparado conel segundo es la inversión más alta y mayores costos de mantenimiento y un sistema global máscomplejo. Una forma práctica de realización debe siempre establecerse en concordancia con losrequerimientos , en el más alto grado posible. Las DCNs de gestión están a menudo soportadas por la redgestionada (debido a la estructura relativamente simple y el menor tamaño principalmente) en el caso deLANs , y esta es casi la solución exclusiva para redes construidas con tecnología SDH/SONET. Esto aposteriori es justificado por la alta confiabilidad de las redes SDH/SONET (reasegurado por elementos dered confiables y por topologías de red redundantes) , y adicionalmente por la disponibilidad de canales decomunicación reservados para propósitos de gestión en la estructura de trama de SDH/SONET.Los dispositivos de mediación (MD) ejecutan funciones de mediación (MFs). Ellos pueden adaptar lainformación transferida entre el OS ó el DCN y aquellos elementos TMN-compatibles ubicados en la red ,la cual aún requiere operaciones apropiadas (almacenamiento , adaptación , filtrado , etc) a ser ejecutadassobre los datos intercambiados. Debiera notarse que se puede observar confusión respecto a lainterpretación de MF. Los usuarios están inclinados a referirse al QA como un dispositivo de mediación.QAs ejecutan funciones de adaptador Q (QAFs). Ellos logran el intercambio de información entre el OS óla DCN , aplicando protocolos estándares , y los eventuales NEs no-estándares ubicados en la red. Porejemplo , los QAs pueden establecer una interconexión entre una DCN estándar y los elementos de redno-estándares conectados usando interfaces Qx , y luego la MD convertirlo en interface Q3.Las interfaces estándares definen las formas y reglas del intercambio de información que puede serllevado a cabo a través de los puntos de referencia de una red TMN. Las definiciones de una interfaceestándar incluyen descripciones de las interfaces hardware , descripciones de los protocolos decomunicaciones como reglas de intercambio de datos , así como el modelo de información ; esto es , laestrategia de trabajo interno a nivel sistema entre elementos que toman parte en la comunicación. Cadauna de las definiciones de interface involucra la definición de las familias de protocolos y de protocolos.Los puntos de referencia son conceptos abstractos que representan fronteras teóricas entre los elementosfísicos de una TMN. Hay un número de puntos de referencia estándares bien definidos en una red TMN.Ellos se indican por letras minúsculas , mientras las mayúsculas apropiadas simbolizan las interfacescorrespondientes. Los puntos de referencia e interfaces definidos en TMN son:

. El punto de referencia “q” puede estar ubicado entre cualesquiera dos de los siguiente bloques defunción: OSF , QAF ,MF , y NEF. Esto significa que el punto de referencia “q” puede ser encontradoentre ya sea el OS y un NE , ó entre el OS y un QA , ó entre el OS y un dispositivo de mediación , ó entrecualesquiera de los elementos arriba mencionados y la DCN ó entre dos OS pertenecientes a la mismaTMN. La interface “Q” permite el intercambio de datos a través del punto de referencia “q”. Actualmente, se distinguen dos tipos de interfaces “Q” ; estas son interfaces Q3 y Qx. Los suites de protocolo “Q”apropiados son los protocolos Q3 y Qx. Los protocolos “Q3” son implementaciones completas delmodelo de referencia OSI de siete capas , mientras que los protocolos “Qx” solamente cumplen con lastres capas más bajas del modelo OSI. Q3 se aplica para conectar los elementos funcionales que soncompletamente TMN-compatibles , mientras que Qx puede ser usado en casos especiales cuando lainterface Q3 no puede ser implementada (debido a la presencia de cualquier equipamiento que no cumplecon TMN).

11

. El punto de referencia “f” está ubicado entre bloques de función OSF ó MF y una WSF. Esto significaque el punto de referencia “f” puede ser encontrado entre la DCN (ó un dispositivo de mediación) y unaWS conectada a ella. La correspondiente interface “F” permite el intercambio de datos a través de unpunto de referencia “f” (esto es , la interface “F” es aplicada en casos donde la WS no está conectadadirectamente al OS , sino que a través de la DCN). El suite de protocolo apropiado es el protocolo “F”.. Un punto de referencia “x” está ubicado entre OSFs de dos TMNs ó entre el OSF de una TMN y lafuncionalidad similar a OSF de otra red no-TMN. Esto significa que un punto de referencia “x” puede serencontrado entre las DCNs de dos TMNs , ó este se encuentra entre una TMN y otro sistema gestionadoque no cumple con los estándares de TMN. Una interface “X” correspondiente permite el intercambio dedatos entre los dos Sistemas de Gestión de Red. El suite de protocolo apropiado es el protocolo “X”.Adicionalmente , la recomendación M.3010 define dos puntos de referencia adicionales , ubicados fueradel área de los elementos estándares de TMN:

. El punto de referencia “g” está ubicado entre el usuario humano y la WSF

. El punto de referencia “m” está ubicado entre el QAF y un elemento que no conforma a lasrecomendaciones TMN

Las especificaciones de interfaces estándar , primariamente aquellas de la familia de interface “Q” y loscorrespondientes protocolos , son altamente significantes en relación con la operación de TMN. Unnúmero de recomendaciones CCITT/ITU-T tratan la especificación de protocolos TMN (M.3020 ,M.3300 , Q.811 , Q.812 , etc). Debería notarse que , sin embargo ,el rango de estándares que especificaninterfaces estándar , incluyendo la interface “Q” , no está completo aún.Un ejemplo de una arquitectura física simplificada para una TMN como se presenta en la recomendaciónM.3010 , se muestra en la figura 3.4.1. Una representación más ilustrativa de la arquitectura física de unaTMN puede ser vista en la figura 3.4.2.

12

3.4.3.3 Arquitectura lógica estratificada de una TMNDe acuerdo a la terminología TMN , las OSFs de la gestión de red están separadas en cuatro capasjerárquicas. Cada capa de la jerarquía dada define un grupo apropiado de operaciones de gestión. Estascapas son construidas una sobre otra ; ellas (y sus operaciones apropiadas) están muy interrelacionadas.El estándar TMN define las siguientes cuatro capas de la OSF:

. Capa de gestión de elemento de red (NE).

. Capa de gestión de red.

. Capa de gestión de servicio.

. Capa de gestión de negocio.

Las OSFs en estas capas interactúan con las OSFs en las mismas u otras capas dentro de la misma TMN através de un punto de referencia “q3” , y con aquellas de otra TMN a través de un punto de referencia “x”.Adicionalmente , la gestión de un elemento de red está basada en los datos colectados acerca de losrespectivos elementos de la red , los elementos de red en si mismos pueden ser considerados como la capamás baja en la jerarquía.En contraste con las cuatro capas de OSF , la capa de los elementos de red no involucra OSF , pero estárelacionada con la NEF.Ejecutemos brevemente una revisión de las funciones incluidas en las capas dadas de la jerarquía , desdeabajo hacia arriba.Los elementos de red son componentes básicos de la red gestionada , instalados como dispositivos físicos, especificados por funciones e interfaces estándares , capaces de distribuir datos en su operación , yproveer medios para ser controlados en una forma específica por el sistema de gestión. El concepto deNEs está claramente definido en los estándares TMN (ver sección 3.4.3.2).La capa de gestión de elemento de red gestiona cada elemento de red sobre una base individual ó engrupo. La gestión de NE incluye la reunión de datos de cada uno de los elementos de red y el controlindividual de ellos. En esta capa , las decisiones sobre el cambio de estado de cualquiera de los NEsindividualmente deben basarse en información acerca del mismo elemento , y no puede depender delestado de cualquier otro de los NEs ó del estado de la red entera.La gestión básica de fallas , así como las operaciones de gestión de performance , tales como monitoreo ymuestra de condiciones de faltas ó performance de tráfico de cualquiera de los elementos simples de red ,así como la toma de acciones elementales para eliminar un error (ej.: conmutar a un canal auxiliar dentrodel mismo elemento de red , etc) son ejecutados por la capa de gestión de NE. (ver también secciones3.4.1 , 3.4.2 , y 3.4.3).La capa de gestión de red tiene la responsabilidad por la gestión de la red completa como es soportada porla capa de gestión de elemento. Esta capa transgrede la competencia de la gestión de elemento de red y esresponsable por la interconexión y cooperación de todos los elementos de red en el sistema gestionado.

13

Las tareas de esta capa incluyen gestión de configuración (ambas , estática y dinámica ; ver sección 3.4.3), gestión de eventos , faltas , y performance a nivel de red (todo esto empleando una aproximación desistema , ej.: por aplicación de algoritmos de evaluación y correlación de error/performance) , así comola gestión de seguridad (monitoreando los requests de usuario y tomando las acciones apropiadas aefectos de prevenir cualquier acceso no autorizado a la red).La gestión de servicio se relaciona con y es responsable de los aspectos contractuales de los serviciosprovistos a clientes ó disponibles para potenciales nuevos clientes. La gestión de servicio apunta aestablecer relaciones entre los servicios provistos por la red y los requerimientos de los usuarios óclientes. Los clientes y los contratos de servicio son grabados , los cliente y los parámetros de servicioapropiados son relacionados , se traza la calidad de servicio , las quejas de los clientes son reportadas , ynuevas órdenes son aceptadas y procesadas , etc , en esta capa de gestión.La gestión de negocio es responsable por la empresa total. Tiene que ver con aspectos técnicos y denegocios en función de un complejo orgánico de la actividad de los operadores de red , y tiene laresponsabilidad por la empresa total. Las funciones incluidas en esta capa son tarificación y contabilidad(accounting) , gestión de mantenimiento , control de costos , control de inventario de repuestos , diseño denuevos elementos de red y/o nuevos servicios de red , modelado técnico y optimización , y planeamientoy evaluación de réditos de nuevas inversiones , etc.La capa de gestión de negocio incluye funcionalidad propietaria. A efectos de prevenir acceso a sufuncionalidad , las OSFs en la capa de gestión de negocios no tienen generalmente puntos de referencia“x” e interfaces “X”. Esta capa se incluye en la arquitectura TMN para simplemente facilitar lasespecificaciones requeridas por las otras capas de gestión. Sin embargo , aún puede ser necesario que lacapa de gestión de negocios interactúe con otros sistemas de gestión ó información. La tarea de estasinteracciones deberían ser resueltas por soluciones especiales de software.Las capas lógicas de la jerarquía de gestión no están definidas en total detalle por los estándaresexistentes.Las tareas y procesos de las diferentes capas y las reglas de intercambio de datos entre ellas no estánexactamente determinados al presente.La estructura de capas está esquemáticamente cubierta por las recomendaciones M.30 y M.3010. En laliteratura técnica , la discusión de funcionalidad de gestión de red es a menudo confinada a un simplelistado de funciones de gestión sin detalle de sus jerarquías.En la práctica presente , las soluciones estándares están mayormente restringidas a realizar las capas degestión de elemento de red y gestión de red. Frecuentemente usadas , funciones de gestión estándar (versección 3.4.3.4) esencialmente corresponden a las tareas de estas dos capas de gestión. Aún ,relativamente pocas companías ofrecen soluciones reales para la gestión de servicio. En algún grado ,productos de gestión de red apropiados para ejecutar tareas de gestión de negocios están ahoramayormente bajo desarrollo.Como consecuencia , las herramientas existentes prometiendo resolver tareas de más alto nivel de lagestión de red pueden ser consideradas como productos de software propietario , específico delfabricante.La arquitectura estratificada de las funciones del sistema de operaciones , tal como se define en larecomendación M.3010 se muestra en la figura 3.4.3.En referencias técnicas , las capas lógicas de las funciones de gestión son a menudo ilustradas por unapirámide (ver figura 3.4.4) , indicando que la mayor cantidad de datos elementales puede ser encontradaen la capa de base , pero el grado de su complejidad (en la medida en que los datos son procesados) seincrementa a través del ascenso en las capas.Es quizás inútil notar que una similitud resaltable puede ser establecida entre el modelo de gestión de redfuncional con forma de pirámide y la estructura de una jerarquía de información de gestión de negociotípica. En general , esta puede también ser dividida en varias capas entre la capa operativa y la capamáxima de control de gestión. Es también obvio que puede requerirse una interrelación cercana entre lagestión de red a nivel de capa de negocio y la capa controlante superior del sistema de informaciónrelevante de gestión de negocio. (funciones interrelacionantes son facturación , contabilidad (accounting),control de costo , y gestión de inventario , por ejemplo). El establecimiento de interconexión on-lineentre los Sistemas de Gestión de Red TMN y los sistemas de información de gestión de negocio puederepresentar uno de los más importantes esfuerzos de desarrollo futuros por el lado de los fabricantes desoftware de ambas familias de productos (ver sección 3.4.6) .

14

FIGURE 3.4.4 Pyramidal illustration of TMN Logical Layered Architecture

15

3.4.3.4 Funciones asociadas con una TMNEn lo que respecta al área funcional de gestión de TMN , la recomendación M.3010 lista cinco funcionesde gestión y se refiere a la recomendación X.700 de OSI. Las funciones de gestión de red TMN sonclasificadas por la recomendación M.3400 de la ITU-T en más detalle (ver tabla 3.4.1). (Recordar quemétodos organizados de gestión de red son el resultado de una evolución natural , y obviamente , lamayoría de los items definidos como funciones TMN estándares pueden también ser encontradas enSistemas de Gestión de Red y estándares establecidos antes de la aparición de TMN. Aún , como unaspecto nuevo de estructuración de arquitecturas de sistemas , la funcionalidad de gestión se divide encapas jerárquicas en términos de TMN.)En referencia a la sección 3.4.3.3 , se debe notar que los estándares existentes de TMN con respecto a ladefinición de capas son bastante esquemáticos , especialmente en relación a funciones pertenecientes a lascapas superiores de gestión. Sin embargo , todos los datos colectados en el campo de las funciones degestión definidas por la M.3400 de ITU-T y listadas debajo pueden también ser relacionados a lasfunciones de las capas de gestión más altas , al menos en una forma condensada y evaluada. Aun , ellasrepresentan tareas que básicamente tienen que ser implementadas justo en la capas de elemento de red óde gestión de red. Como excepción , la gestión de accounting (contabilidad) puede ser estrictamenterelacionada a las capas más altas en la arquitectura.Las funciones de gestión estándares de TMN de acuerdo a las definiciones de la recomendación ITU-TM.3400 son:. Gestión de Performance. Gestión de Fallas (ó mantenimiento). Gestión de Configuración. Gestión de Contabilidad (Accounting). Gestión de SeguridadAunque no se considera como una función de gestión independiente en sí misma , y los estándares de

TMN no la cubren el momento , el proceso de descargar programas desde el Sistema de Gestión de Red alos elementos inteligentes de red as través de la red de comunicación de datos está cercanamenterelacionado a las funciones de gestión de red.

3.4.3.4.1 Gestión de performanceLa gestión de performance (algunas veces también referida como gestión de tráfico y performance)provee funciones para evaluar y reportar sobre el comportamiento del equipamiento detelecomunicaciones y la efectividad de la red y/o elementos de red. Puede involucrar la medición de laintensidad del flujo de datos (tráfico) a lo largo de las diferentes rutas de la red ,coleccionando ,evaluando y mostrando los datos medidos de esta forma , así como también la determinación de índicesde eficiencia y el cálculo del análisis de tendencia. La información colectada y evaluada en este procesopuede ser utilizada similarmente a y en conexión con los datos colectados en el campo de la gestión defallas.Sobre la base de estos datos , se puede establecer el nivel de carga de tráfico y se puede determinar si unared dada cumple con lo requerimientos de performance necesarios. (Si ocurre alguna congestión , las rutasde red sobrecargadas pueden ser aliviadas por una reconfiguración de sistema ó por alteración de laestrategia de ruteo actual. La intervención automática en la operación de la red puede ser ejecutada por elSistema de Gestión de Red. Si se ha observado una carencia permanente de capacidad de red , se deberíatomar la decisión para efectuar nuevas inversiones e incrementar la capacidad de red (ver también sección3.4.2).

3.4.3.4.2 Gestión de FallasLa gestión de fallas (ó de mantenimiento) (algunas veces también referida como gestión de eventos yerrores) es un set de funciones las cuales habilitan la detección , aislamiento , y corrección de operacionesanormales en la red de telecomunicaciones y su ambiente. Su propósito es detectar y registrar eventos quehan ocurrido en diferentes partes de la red , luego establecer la causa de estos eventos con el mayor gradode detalle y seguridad. Todo ello está apuntado , primero que nada , a explorar los errores y ser capaces derepararlos en el tiempo más corto posible.La gestión de fallas puede ser confinada al simple registro de estados de las alarmas originados por loselementos de red separados y la generación de mensajes de error apropiados a efectos de informar aloperador. Un método más sofisticado y efectivo es correlacionar estos eventos individuales y evaluar sucorrelación por medio de algoritmos apropiados. Los algoritmos de correlación pueden necesitarse paraidentificar causas de malfuncionamientos y localizar sus fuentes con precisión en situaciones complejas.Esto es , un error elemental puede generar un número de reportes de error , y , en oposición , un reportede error puede referirse a varios eventos ó estados de alarma (rotura de equipamiento , caída de vínculos ,

16

congestión de tráfico , etc) Si se necesitan por la cantidad ó tipo de fallas , tests especiales de prueba óotras rutinas de pruebas especiales serán iniciadas a efectos de localizar a los elementos defectuosos delsistema. Con el análisis de las interrelaciones de los estados de alarmas elementales y evaluando losresultados de las rutinas de test se puede arribar a un diagnóstico preciso aun si métodos individuales hansido insatisfactorios.Como resultado de aplicar la gestión de evento y error , una gran parte de malfuncionamientos pueden serdescubiertos y eliminados antes que puedan causar problemas detectables por los usuarios. En algunoscasos , el impacto de fallas emergentes puede ser eliminado por una reconfiguración automática ydinámica de las rutas de red (ver también sección 3.4.3). La reconfiguración automática puedegeneralmente ser efectiva en redes con alto grado de conectividad topológica y (si ocurre algo simplecomo la ruptura de un cable) en una configuración de red en anillo ó en caso de congestión de tráfico ,etc.La gestión de fallas está también relacionada con el mantenimiento de estadísticas. Las estadísticaspueden asistir al operador en la decisión de si una red cumple con los requerimientos apropiados(confiabilidad , performance , etc) ó no.

3.4.3.4.3 Gestión de ConfiguraciónLa gestión de configuración provee funciones para operar , controlar , identificar , y colectar datos desdeó proveer datos a elementos de red.En la práctica de gestionar redes de telecomunicaciones actuales de banda ancha , la gestión deconfiguraciones generalmente incluye dos funciones esenciales lógicamente diferentes. En particular:gestión de configuración estática , y dinámica.La gestión de configuración estática involucra la asignación y desasignación de elementos de red a ódesde la red lógicamente , así como el registro , indicación , muestra y reporte de la topología de la red ylistado del equipamiento de red conjuntamente con sus parámetros de sistema , tales como tipo ,localización topológica , direcciones físicas y simbólicas , etc. En el caso de redes pequeñas y simples ,(en conjunto con el registro de parámetros de equipamiento) , la gestión de configuración estática puedetambién involucrar el control de inventario ; sin embargo , en el caso de redes complejas , esta funcióndebería ser manejada separadamente.La gestión de configuración dinámica involucra el establecimiento de las rutas actuales para lasinterconexiones requeridas vía la red. Esto implica la reconfiguración de la red mediante elestablecimiento de una posible nueva ruta , si la ruta actual desaparece , ó bien la cancelación de la ruta sillega un requerimiento de cancelación de la misma. En términos de la gestión de configuración dinámica, la presentación de la topología de red tiene que reflejar las rutas y conexiones actuales en la red.

3.4.3.4.4 Gestión de Contabilidad (Accounting)La gestión de contabilidad (a veces también referida como gestión de tarificación y contabilidad ) es unset de funciones que habilita la medición del uso del servicio de red y la determinación del costo de dichouso. La gestión de contabilidad debería proveer facilidades para colectar registros de contabilidad yestablecer parámetros de tarifación para la utilización del servicio.En el campo de la gestión de contabilidad , se miden el tiempo y otras características del acceso de red deusuario y se calculan los datos necesarios para cobrar sobre la base de varios parámetros (listas de precios, contratos de cliente , tiempo de uso , servicios utilizados , etc). La información de tarifación ycontabilidad es colectada , clasificada , y registrada. Sobre esta base , se pueden preparar las facturas y serenviadas a los clientes , se puede calcular el ingreso redituable y se lo puede asentar , etc.

3.4.3.4.5 Gestión de SeguridadLa gestión de seguridad involucra el establecimiento de clases de autenticación , el chequeo deautorización de usuarios para acceder a la red , el control de passwords , y la toma de otras posiblesmedidas para prevenir de cualquier acceso no autorizado a la red. Puede ser una tarea especial laprotección de intervenciones no autorizadas a los terminales de gestión , de acuerdo a los requerimientosde seguridad establecidos. Dependiendo de los requerimientos especiales establecidos en acuerdo con elpropósito de una red , las funciones contenidas dentro de la gestión de seguridad pueden diferir deaplicación a aplicación.

3.4.3.4.6 DescargaLa descarga de nuevas versiones de software , tablas de ruteo , tablas de conmutación , u otros segmentosde programa desde el centro de gestión a los elementos inteligentes de red , constituye una tareaimportante de un Sistema de Gestión de Red. La descarga de software provee algunos medios paraejecutar también el control remoto de los elementos de red. Por medio de la descarga de software , por

17

ejemplo , se puede modificar la operación de un elemento de red , se puede activar una nueva versión desoftware , ó se puede simplemente modificar la tabla de configuración almacenada en un elemento de red.Una de las formas prácticas para resolver la gestión de configuración puede ser modificar las tablas deconfiguración por descarga de software. Mientras que las especificaciones de la descarga de software enLANs están incluidas en el estándar IEEE 803.1 , no hay , por el momento , una recomendación generalpara esta forma de control remoto de elementos de red gestionados con TMN. (Para la gestión de SDH , larecomendación G.784 de la ITU-T asigna este item para un estudio adicional).

3.4.3.5 Arquitectura de información.Las características generales del modelo de información de TMN son discutidas por las recomendacionesM.3010 y M.3100 de CCITT/ITU-T. Recomendaciones adicionales tratan los modelos de informaciónpara gestión de redes SDH y PDH (ej.: recomendación G.774).Esencialmente , la gestión de red involucra el intercambio de información entre procesos de gestión.El modelo de información de gestión de red TMN se soporta , en gran medida , sobre el modelo degestión de red OSI/CMIP. La arquitectura de información de TMN está basada sobre un modelo orientadoa objeto , aplica intercambio de información orientado a transacción , y utiliza el principio así llamado deagent/manager (agente/gestor).Los conceptos básicos usados en la definición de la arquitectura de información de TMN son similares aaquellos aplicados en SNMP y OSI/CMIP (ver secciones 3.4.2.2.1 y 3.4.2.2.2). Ello son:

. Objeto gestionado (Managed Object: MO)

. Agente (Agent)

. Gestor (Manager)

. Base de Información de Gestión (Management Information Base: MIB)

Los MOs son abstracciones de los recursos físicos ó lógicos a ser gestionados en orden a monitorear laoperación de la red y a prevenir desordenes en la operación de la red. Un objeto gestionado generalmenteno se corresponde a un simple elemento de red según se definió como parte de la arquitectura física (versección 3.4.3.2). En la mayoría de los casos , un objeto gestionado representa uno de los componentesimportantes de un elemento de red físico (puede ser la unidad de control de un circuito dado) ó un recursológico (ej.: el estado de un elemento físico básico). Cada elemento gestionado debe tener un nombresimple y único ; su condición actual es una función del tiempo.Un objeto gestionado está definido por:

. Sus atributos visibles en su frontera

. Las operaciones de gestión que pueden ser aplicadas a él.

. El comportamiento exhibido por él en respuesta a la operaciones de gestión

. Las posibles notificaciones ó mensajes que él puede emitir durante su operaciónUn gestor es un elemento de sistema cuya tarea es enviar requerimientos de gestión hacia los agentes parapropósitos de control , coordinación y monitoreo , ejecutando operaciones sobre los agentes con la ayudade esos requerimientos y la recepción de mensajes emitidos por los objetos gestionados y retransmitidospor los agentes al gestor. En la práctica , el rol del gestor es ejecutado por una workstation (esto es , elcorrespondiente software de gestión de red ejecutándose en la workstation) la cual , en turno , es una parte(elemento físico) del Sistema de Gestión de Red (ver sección 3.4.3.2).Un agente es un elemento de sistema hacia el cual se dirigen los comandos de gestión para propósitos decontrol , coordinación , y monitoreo. Los agentes ejecutan operaciones sobre los objetos gestionados deacuerdo a los requerimientos del gestor , y retransmiten mensajes emitidos por los objetos gestionadoshacia el gestor. En la práctica , la función del agente es ejecutada por un elemento de red inteligente delSistema de Gestión de Red (esto es , por el programa ejecutándose en él).Por definición , puede existir una relación de muchos-a-muchos entre gestores y agentes. Esto significaque un gestor puede estar involucrado en el intercambio de información con varios agentes , y un agentepuede intercambiar información con varios gestores.La base de información de gestión (MIB) es una base de datos que contiene datos pertenecientes a losobjetos gestionados del sistema. Similar al concepto aplicado en el caso de SNMP y OSI/CMIP , cadauno de los agentes tiene su propia MIB , el gestor está en comando de un super set de MIBs de agentes(ver sección 3.4.2.2.1). El set de reglas describiendo la estructura de un base de información de gestión esllamada estructura de información de gestión (SMI)La interacción entre un agente , un gestor , y los objetos gestionados de acuerdo a ITU-T M.3010 semuestra en la figura 3.4.5.

18

El gestor y el agente se comunican utilizando protocolos “Q” estándares construidos de acuerdo almodelo de comunicación de siete capas de OSI.Los componentes de un protocolo Q son:

. Interface de aplicación (estructura comando/respuesta)

. Protocolo de aplicación (la séptima capa del modelo OSI)

. Protocolos de soporte (capas 4-6 del modelo OSI)

. Protocolos de red (capas 1-3 del modelo OSI)

Los elementos esenciales de la interface de aplicación TMN son altamente similares a aquellos de lagestión OSI/CMIP (ver sección 3.4.2.2.2). Ellos son:

. Elemento de Servicio Común de Información de Gestión (Common Management Information ServiceElement: CMISE)

. Elemento de Servicio de Operación Remota (Remote Operation Service Element: ROSE)

. Elemento de Servicio de Aplicación de Gestión de Sistemas (Systems Management Application ServiceElement: SMASE)

. Elemento de Servicio de Control de Asociación (Association Control Service Element: ACSE)

. Transferencia de archivo , acceso y gestión (File Transfer , Access and Management: FTAM)

La disposición de las capas de protocolo Q en el modelo de comunicación de siete capas de OSI semuestra en la figura 3.4.6.

19

3.4.3.5.1 El Modelo de Objeto basado en OSIEl modelo de objeto proporciona una descripción formal de objetos estándares aplicados en el sistema ydefine las relaciones entre ellos. Los objetos están agrupados juntos para formar clases de objetos: losmiembros que pertenecen a la misma clase tendrán las mismas características dadas en cuanto a lo que laclasificación respecta. Además , las clases de objetos pueden también ser agrupadas juntas para formarclases de objetos más generales. Como consecuencia , los objetos estándares son dispuestos en unaestructura arbórea jerárquica. Cada nodo del árbol representa un grupo de objetos gestionados , y cadagrupo incluye un número de objetos.Aspectos básicos del modelo de objeto de TMN y del modelo de información son descriptos en larecomendación M.3010 ; un catálogo de clases de objetos de TMN se proporciona en la recomendaciónM.3180 (ver tabla 3.4.1). Junto con las definiciones de clases de objetos básicas , M3010 define larelación Agent/Manager como Conocimiento de Gestión Compartida (Shared Management Knowledge:SMK).En la práctica , los modelos de objetos aplicados en los sistemas de gestión TMN usados presentementese soportan fuertemente sobre los principios de gestión de OSI , es decir , recomendaciones X.722(GDMO) y X.208 (ASN.1) de CCITT/ITU-T. Ver también la sección 3.4.2.2.

3.4.3.5.2 Modelos de Objetos Distribuidos y Gestión de ServicioLa evolución de las tecnologías de comunicaciones es reflejada por la evolución de TMN yadicionalmente por la evolución de su modelo de objeto. Focalizando en el segundo , y considerando lascapas jerárquicas de la gestión de red descripta en la sección 3.4.3.3 (representando la dimensión másilustrativa de esta evolución) , los primeros pasos escalando esta jerarquía fueron el modelado deelementos simples de red y luego la definición de los modelos de la red completa. El próximo paso quedebería ahora ser pergeniado es la gestión de servicio. Una de las principales dificultades en esta fase dedesarrollo es que los sets de gestión de servicio tienen diferentes requerimientos para el modelo de objetoque la gestión sobre el elemento y la capa de gestión de elemento.Desde el punto de vista del modelo de objeto , las principales diferencias entre elementos de red yservicios de telecomunicaciones son que (no intentando ser exhaustivos): el número de NEs esgeneralmente mucho mayor que el número de servicios ; los servicios son , sin embargo , máscomplicados , más dinámicos que los NEs , y son de carácter distribuido mientras los NEs no lo son.De acuerdo a los dos primeros pasos de desarrollo mencionados más arriba , el modelo de objeto actualbasado en OSI (Systems Management Guidelines for the Definition of Managed Objects: GDMO) esestático , construido utilizando una aproximación de sistema centralizado , y básicamente precondicionala inteligencia central. La mayoría de las operaciones ejecutadas sobre los objetos GDMO usandoCMIS/CMIP son relativamente simples ; estas operaciones generalmente se relacionan a un grupo deobjetos y su extensión está determinada por las condiciones dadas de filtrado y campo de acción. Sinembargo , ellas son muy efectivas en manejar una gran cantidad de objetos relativamente simples deacuerdo a lo requerido por las capas de gestión de elemento de red , y de gestión de red , cuyosrequerimientos fueron su guía de diseño.La tecnología de telecomunicaciones reciente , tomando por ejemplo el servicio de cliente extremo aextremo , representa un ambiente complejo , integrado , el cual necesita la disponibilidad de gestión deservicio ,y como tal , requiere interoperabilidad , flexibilidad , y procesamiento de objeto distribuido porparte del Sistema de Gestión de Red. La gestión de servicio involucra la resolución del problema de cómoefectuar la integración y gestión de servicios diferentes como telefonía , vídeo , Internet ,y CATV , ycomo gestionar servicios que transitan a través de dominios de diferentes redes de telecomunicaciones y/óproveedores de servicios estando geográficamente dispersos , probablemente teniendo diferentestecnologías de servicio , aplicando varias políticas de negocios y de tráfico , etc.GDMO no es realmente apropiado para el modelado de objetos de gestión distribuida y para la realizaciónde las funciones de gestión apropiadas que son necesarias para la gestión de servicio.Para superar este problema y satisfacer los requerimientos de una aproximación a un sistema distribuido ,la ITU-T definió el modelo de referencia para procesamiento distribuido abierto (Reference Model forOpen Distributed Processing: RM-ODP) y la arquitectura de gestión distribuida abierta (Open DistributedManagement Architecture; ODMA) en las recomendaciones X.901 a 4 y X.703 , respectivamente. RM-ODP presenta los principios y la definición básica de un sistema distribuido ; no involucra directivas paraimplementaciones prácticas. ODMA está orientada al desarrollo de la gestión OSI hacia un ambiente deprocesamiento distribuido.El TeleManagement Forum también trata de estandarizar un modelo de objeto para gestión de servicio.Uno de los resultados de este esfuerzo de desarrollo fue OMNIPoint (Open Management InteroperabilityPoint) , una solución estándar proveyendo definición de clase de objeto y especificando una arquitectura

20

de gestión integrada. Recientemente , el Forum prestó su atención a las últimas soluciones en el campode la tecnología de gestión de red , tal como la integración de CORBA y TMN.La arquitectura de intermediario de requerimiento de objeto común (Common Object Request BrokerArchitecture: CORBA) es una solución para el procesamiento de datos distribuido orientado a objeto ,desarrollado por el Object Management Group. CORBA fue presentado en 1991 , mientras que CORBA2.0 fue adoptado en 1994. Por ahora , CORBA se ha constituido en un estándar de facto en este campo.CORBA define una estructura general para el desarrollo de programas orientados a objetos distribuidos(la gestión de red es una de sus posibles aplicaciones). CORBA incluye un modelo de objeto ; se definenadicionalmente las operaciones posibles sobre ellos y se especifica la forma en que esas operacionespueden ser ejecutadas. CORBA también define un lenguaje de programación independiente , llamadolenguaje de definición de interface (Interface Definition Language: IDL) , y las interfaces deprogramación apropiadas. El mecanismo de comunicación que satisface los requerimientos de los objetosgestionados (como contraparte de CMIS/CMIP en GDMO) es provisto por el intermediario derequerimiento de objeto (Object Request Broker: ORB).Como fue verificado en teoría y por algunos modelos de software realizados , CORBA puede serefectivamente aplicado para la gestión de servicios de comunicaciones. Esto no significa que los modelosde objeto OSI tradicionales , tales como GDMO (junto con CMIS/CMIP) tendrán que simplemente serreemplazados por CORBA en cualquier momento. Mejor , ellos deberían ser integrados , GDMO siendousado para las capas de gestión de elemento de red y de gestión de red , mientras que CORBA usado parala gestión de servicios. Las principales razones de este argumento son que a pesar de todas las ventajas deCORBA en la gestión de servicio , GDMO es más efectivo en la capa de elemento , y adicionalmente ,razones económicas requieren que los nuevos desarrollos no influencien desventajosamente en lautilización de las implementaciones existentes.La integración de CORBA y TMN , sin embargo , no puede ser resuelta sin algunas dificultades. Elprotocolo CMIP , los servicios apropiados definidos por CMIS y el modelo de objeto GDMO , sonbastante diferentes de aquellos protocolos , servicios , y modelos de objeto representados por CORBA.A efectos de construir facilidades de CORBA dentro de TMN , los dos modelos de objeto diferentes , lasfunciones de gestión apropiadas y las operaciones relacionadas deberían ser combinadas. Laspublicaciones reportan respecto a soluciones especiales de software en este campo , y simultáneamente, elNMF hace esfuerzos para elaborar métodos estándares para satisfacer este requerimiento.Sin embargo , aplicaciones recientes de CORBA tienen que ser consideradas como solucionespropietarias , puesto que ni la forma de la integración TMN-CORBA , ni los objetos TMN de capa deservicio han sido estandarizados hasta ahora.Uno de los más recientes resultados en este aspecto es la arquitectura de red de información detelecomunicaciones (Telecommunications Information Networking Architecture: TINA) , habiendo sidodesarrollada por el TINA Consortium. TINA especifica un modelo de información independiente de latecnología para sistemas de telecomunicaciones , basado sobre operaciones distribuidas. De acuerdo atodas las indicaciones , TINA no se escapará de ser integrada con TMN.

3.4.4 Interconexión de Redes Gestionadas

3.4.4.1 Trabajo cooperativo entre sistemas diferentes de gestión de redComo resultado del desarrollo técnico reciente , las redes de telecomunicaciones se han globalizado ;redes públicas y privadas , LANs , y WANs no pueden ser separadas con precisión. Esto significa que (enla mayoría de los casos) , los servicios de red pública serán actualmente realizados por un número deproveedores de red y/ó servicio , y utilizando un número de elementos de red originarios de diferentesvendedores y fabricantes. Una simple conexión extremo a extremo , satisfaciendo las demandas actualesde los usuarios , puede transitar a través de caminos en redes públicas y privadas , ISDN , SDH , ATM ,red móvil , LAN , WAN.Esta situación conduce tanto a operadores de redes públicas , como de redes privadas , a integrar susSistemas de Gestión de Red al más alto grado posible. Ultimamente , también han surgido requerimientosde establecer una gestión extremo a extremo.En cuanto a los aspectos técnicos de TMN se refiere , un incremento del trabajo cooperativo de diferentesSistemas de Gestión de Red debe aún ser implementado.De acuerdo a la recomendación M.3010 de ITU-T , las jerarquías TMN pueden interactuar por muchasrazones , tales como:

. para manejar las interacciones requeridas para proveer servicios de valor agregado

. para manejar un número de TMNs geográficas/funcionales como una TMN simple

21

. para proveer servicios extremo a extremo

Como se describe en la sección 3.4.3.2 , las OSFs ubicadas en la misma TMN pueden intercambiarinformación vía el punto de referencia “q” , utilizando una interface “Q” , mientras que diferentessistemas TMN estándares pueden ser interconectados vía los puntos de referencia “x” y puedenintercambiar información utilizando intefaces “X” estándares. Si se tuviera un Sistema de Gestión de Redque no cumple con los estándares TMN , el trabajo cooperativo entre un sistema TMN y un sistema no-TMN puede teóricamente también ser establecido a través de la interface “X”. En el último ocaso , elsistema no –TMN debe ser capaz de comunicarse a través de esta interface “X” , manejar el protocoloapropiado , y procesar formatos de datos de acuerdo a las MIBs de la TMN. A efectos de hacer esto ,sinembargo ,se deberán aplicar soluciones de software sofisticadas.En al práctica , se han hecho esfuerzos para resolver el problema de integración de gestión de OSI ySNMP , ó TMN y SNMP. Las soluciones dirigidas a este propósito involucran la conversión de protocoloapropiada y la traducción de la información de gestión.

3.4.4.2 Redes virtuales , Gestión de red de clienteLos Sistemas de Gestión de Red TMN también habilitan a establecer redes virtuales dentro de las rutasde comunicación de la red global.Los usuarios de una red virtual tendrán una experiencia similar al uso de una red separada , siendoindependiente del sistema de comunicación completo , con la ayuda del cual , la red virtual es realizada.Los nodos y el dominio de usuarios autorizados de una red virtual pueden ser determinados de acuerdocon el usuario ó requerimientos de clientes , independientemente de la ubicación geográfica real de losnodos virtuales requeridos y de los puntos de acceso de usuario (por supuesto , ellos deberían estarcubiertos por la topología de la red global) e independientemente de la relación entre la jerarquía de red ylas ubicaciones de los nodos virtuales.Un centro de gestión separado puede ser asignado a la red virtual ; sin embargo , debe estar subordinadoal sistema de gestión de la red global. Esto significa que la ejecución de las funciones de gestión (gestiónde configuración ,de eventos , de performance , etc) , con respecto a la operación de la red global ,continúa siendo tarea de la gestión de red central. El centro de gestión de la red virtual tendrá derecho amonitorear los parámetros de operación actuales de la red virtual , y también podrá tener competenciarestringida para ejercer influencia activa sobre algunos parámetros de operación en cuanto a la red virtualconcierne.Las redes virtuales tendrán particularmente gran importancia en aquellos casos , cuando los servicios deredes publicas de comunicaciones son utilizados para construir una red privada en parte ó en su totalidad.Los constituyentes de una red pública , designados para formar parte al mismo tiempo , de una redprivada dada , pueden ser considerados como una red privada virtual (Virtual Private Network: VPN). Entales casos los operadores de la red privada querrán gestionar sus propios sistemas de comunicacionescomo un todo , incluyendo aquellas partes siendo utilizadas como una VPN.Los servicios de gestión de red estándares que pueden ser provistos para los clientes por redes públicas dedatos son llamados Gestión de Red de Cliente (Customer Network Management: CNM). La estructura deCNM está definida en las recomendaciones X.160 a 162 de ITU-T. Los estándares dados de ITU-Trelacionados con CNM definen un set de servicios y la forma de sus implementaciones que puedenhabilitar al usuario a gestionar aquellas partes de su red de comunicaciones las cuales están actualmentesiendo proporcionadas por proveedores de servicios públicos. La recomendación X.160 de ITU-T definela arquitectura de CNM para redes públicas de datos. La recomendación X.161 define servicios paraCNM , mientras que la información de gestión para servicio de CNM es especificada en la recomendaciónX.162.Adicionalmente , la recomendación M.3010 de ITU-T provee una oportunidad para que operadores de redprivada incorporen el concepto de CNM en el campo de TMN.Como se describe en la recomendación M.3010 , la funcionalidad de TMN ofrecida por proveedores deservicio puede ser accedida a través de servicios CNM , siendo estos servicios implementados comointeracciones de gestión entre usuarios y TMN , ó entre TMNs. En ambos casos , el punto de referenciaCNM (el punto de referencia entre el cliente y el proveedor de servicio) definido en la recomendaciónX.160 , tiene que ser implementado por un punto de referencia x de TMN , como se define en M.3010.Recientemente , se han realizado esfuerzos para implementar el concepto de CNM en asociación conredes de datos de alta velocidad.

22

3.4.5 Gestión de SDH/SONET

3.4.5.1 Una breve exploración de las tecnologías de comunicaciones SDH y SONETSDH (Synchronous Digital Hierarchy) implica el concepto de un sistema poderoso de telecomunicacionesde banda ancha , definido por un número de estándares internacionales , publicados por el CCITT/ITU-T.Las primeras recomendaciones , incluyendo principios de SDH , fueron publicadas por el CCITT en 1988(CCITT G.707 , G.708 , G.709). SDH es la contraparte de SONET (Synchronous Optical Network) , elpredecesor de SDH. SONET fue originalmente desarrollado y propuesto por Bellcore (U.S.). Ahora estáestandarizado por ANSI , siendo ANSI T1.105 el estándar base de SONET. Los conceptos y arquitecturasde SDH y de SONET son bastante similares (SONET puede ahora ser considerado prácticamente unsubset de SDH) , pero hay también diferencias , primero que nada , relacionadas con las tasas estándaresde transmisión de bit definidas en las respectivas jerarquías de señal. Recientemente , se ha producido unacoordinación más estrecha entre las instituciones internacionales de estandarización de SDH y de U.S.SONET.SDH y SONET son tecnologías avanzadas de telecomunicaciones , una de sus más importantescaracterísticas es que soportan efectivamente gestión de red. Tienen ventajas significantes sobre lossistemas digitales de transmisión de datos PDH (Plesiochronous Digital Hierarchy) , tradicionalmentebasados en PCM.

3.4.5.2 SDH/SONET y TMNLos principios de gestión de redes SDH/SONET por medio de una TMN no difieren de aquellos que sedescribieron en otra parte de la sección 3. De todos modos , y en relación a la gestión de redSDH/SONET , es importante enfatizar las siguientes circunstancias significantes:

. SDH/SONET son las primeras tecnologías de comunicaciones que han sido diseñadas con particularatención a los aspectos de gestión de red

. En el curso del desarrollo de los estándares de TMN y entre las tecnologías de comunicaciones másimportantes y actualizadas , SDH/SONET son las primeras en haber alcanzado un grado apropiado deestandarización , permitiendo que un sistema comprensible de gestión de red como TMN sea capaz desatisfacer los requerimientos actuales de los usuarios (por supuesto , todos estos prevalecen dentro delos incuestionables límites del presente estado de los estándares de TMN ; ver también las secciones3.4.1 , 3.4.3.3 , y 3.4.3.5.2)

. La aplicación de gestión de red TMN no está solamente soportada por la pulida y organizadaarquitectura de sistemas de SDH/SONET y los estándares de TMN , sino que también por el hecho deque en la práctica , los dispositivos de sistemas SDH/SONET (multiplexores add-drop , cross-connects ,etc) están actualmente equipados con las interfaces apropiadas de TMN , por lo cual ellos son ahoracapaces de manejar protocolos Q e implementar gestión de red TMN

. La complejidad y alta performance de las redes SDH obviamente requieren las facilidades de la gestiónde red TMN , y como consecuencia , la gestión de red TMN es casi la única tecnología que está siendoaplicada para gestionar redes SDH en implementaciones prácticas.

3.4.5.3 Transmisión de Información de Gestión a través de una red SDH/SONETComo se mencionó anteriormente en la sección 3.4.3.2 , en redes SDH/SONET , la información degestión es usualmente transferida vía la propia red gestionada ; esto es , la DCN del sistema de gestión esrealmente una parte de la red total.Los factores más importantes de la tecnología SDH/SONET en relación a la gestión de red TMN son:

. La estructura de trama de SDH permite que la información de gestión sea transferida en los bytes dedatos D1 , ... , D12 de la sección de encabezamiento (Section OverHead: SOH en la trama STM-1/OC –3) , a través de la red

. Las características singulares de las redes SDH/SONET (alta confiabilidad de los elementos de red en simismos , la disponibilidad de mecanismos de protección auto-recuperantes rápidos y automáticos entopologías de anillo redundante , y la aplicabilidad de recupero de error (error recovery) en redes conalta conectividad , permitiendo que la comunicación a través de la red se reestablezca en el caso defallas , hacen que las redes SDH/SONET sean altamente apropiadas para soportar la DNC del sistemade gestión en la propia red gestionada , sin impactar en la seguridad de la operación (ver también lasección 3.4.3.4.2)

23

En una aproximación más cercana a la trama SDH/SONET , es posible encontrar que el área de la secciónde encabezamiento (SOH) de la trama STM-1/OC-3 de SDH/SONET , contiene (y transfiere) un númerode bytes de datos , siendo característico de la operación de red y jugando un rol significante en la gestiónde red.En la SOH , los bytes de control de paridad B1 y B2 indican errores de bit de la sección del generador ymultiplexor , respectivamente , mientras que los bytes D1 , .... , D12 contienen información procesada delestado de gestión (cada uno de los bytes en la trama STM-1/OC-3 de SDH/SONET representa un canal decomunicación con una tasa de bit de 64 kbps. Esto significa que los bytes D1-D12 aseguran unacapacidad total de comunicación de 768 kbps para gestión de red). El canal de comunicaciónrepresentado por los bytes de gestión D1-D12 puede transferir información de gestión de nodo a nodo(ej.: de multiplexor add-drop a multiplexor add-drop) a través de la red propia ; adicionalmente (luego delas conversiones de protocolo necesarias) , esta información puede ser “posicionada“ en la interface Qestándar de cualquier equipamiento de nodo y retransmitida al sistema de operaciones del centro degestión de red.Los mensajes de estado y alarma transportados por el SOH puede ser accedido en los puntos de monitoreo“S” de los multiplexores y regeneradores. Esta información disponible en los puntos “S” no aparece enuna forma estructurada adecuada. Por lo tanto , tiene que ser convertida a mensajes orientados a objetopor una función de conversión incluida en el dispositivo dado. Los mensajes orientados a objeto seránluego retornados al módulo agregado de transferencia STM-N y transferidos en el SOH de un nodo a otroen la red. A efectos de obtener acceso local a estos mensajes , es necesario disponer de una interface “Q”estándar que ejecute la conversión de protocolo e interfaceo de señal necesarias. La salida de la interface“Q” puede entonces ser conectada por ejemplo al sistema de operaciones local del centro de gestión dered. Notar que los multiplexores y cross-connects generalmente tienen interfaces “Q” , pero losregeneradores no.La figura 3.4.7 ilustra el esquema de flujo de datos de gestión en la sección de multiplex de una red SDH.

24

3.4.5.4 Estructura de redes SDH/SONET gestionadas

3.4.5.4.1 Consideraciones generalesLa arquitectura física de una red SDH gestionada está en acuerdo con los principios descriptos en lasección 3.4.3.2.Es razonable , sin embargo , que al ejecutar el diseño de un Sistema de Gestión de Red SDH/SONET , enparticular , se deberían tener en consideración los aspectos de diseño y arquitectura de la propia redSDH/SONET gestionada.Adicionalmente , (básicamente como oposición del requerimiento presentado arriba) , es fácil ver que , enla práctica , seguridad y confiabilidad de la red SDH/SONET diseñada están esencialmente determinadaspor la estructura del Sistema de Gestión de Red correspondiente.De los argumentos presentados arriba , se puede concluir que el diseño de una red de comunicacionesSDH/SONET y el Sistema de Gestión de Red correspondiente deberían ser ejecutados en una estrechainterrelación.En el caso de una arquitectura de red simple , el Sistema de Gestión de Red es también relativamentesimple. Como ejemplo , la figura 3.4.8 muestra el esquema de un anillo SDH gestionado con TMN ,consistente de cuatro nodos de red

La operación del Sistema de Gestión de Red ilustrado puede ser brevemente descripto como sigue:El anillo SDH es gestionado por una TMN. La DCN del sistema de gestión es implementada por loscanales de gestión (SOH) disponibles del anillo SDH , el OS (esto es , el centro de gestión de red) estárepresentado por una simple computadora. (Esta computadora también incluye a la workstation deloperador). El centro de gestión está conectado a uno de los cuatro nodos del anillo SDH a través de unainterface “Q” simple.Tomando una arquitectura de red más compleja , la estructura del Sistema de Gestión de Red TMN serátambién más compleja , y su operación requerirá de algoritmos más complejos. A este tópico , se le puedeagregar los siguientes comentarios:

. Los mecanismos de protección de auto-recupero , frecuentemente aplicados en anillos SDH/SONET(apuntados a sostener una comunicación libre de error en el caso de una falla simple) están basados enreacciones automáticas de los elementos de red y funcionaran sin la intervención del sistema de gestiónde red . La tarea de la TMN es simplemente registrar los eventos ocurridos en tales casos.

. En redes con alta conectividad , la TMN es responsable de seleccionar y establecer rutas alternativas aefectos de eliminar las posibles consecuencias de malfuncionamientos en la red. Consecuentemente , losalgoritmos de gestión requeridos en estas redes son generalmente más complejos que aquellos aplicadosen anillos simple con auto-recupero.

. En el curso del establecimiento de sistemas de gestión para redes interconectadas y/ó jerárquicas , el/lossistemas TMN y los algoritmos de gestión deben ser diseñados con gran cuidado. Muy probablemente ,será necesario aplicar más de un OS en este caso. Si es así , tareas , derechos de acceso , privilegios decontrol , y formas de trabajo cooperativo entre los diferentes OSs (centros de gestión) deberían sercuidadosa y claramente definidos.

25

. El diseño de Sistemas de Gestión de Red será más difícil aún si varias redes con diferentes topologías ,construidas utilizando diferentes tecnologías de red (SDH_PDH) ó conteniendo equipamiento dediferentes proveedores , debieran ser gestionadas al mismo tiempo y coherentemente.

3.4.5.4.2 Redes JerárquicasTMN habilita a construir Sistemas de Gestión de Red jerárquicamente , en acuerdo a una eventualarquitectura estratificada de la red a ser gestionada.Consecuentemente , un sistema de gestión de red puede involucrar centros de gestión de red separadospara (por ejemplo) cada uno de las siguientes capas de red:

. Backbone

. Regional

. Sub-regional ó local

Más de un centro de gestión puede pertenecer a una y a la misma capa jerárquica (por ej.: como reservade seguridad en espera (stand-by) , si es necesario) ; los centros pueden conectarse con la DCN en más deun punto a efectos de incrementar la confiabilidad. El número de workstations de operadores puedetambién ser más de uno. Más aún , algunas workstations pueden estar instaladas en locaciones remotas ,separadas del centro de gestión de red. En este caso , la workstation tiene que ser conectada a la DCN através de una interface “F” estándar.Las tareas y privilegios designados a los centros de gestión de las diferentes capas jerárquicas (derechospara acceder datos , privilegios para controlar elementos de red , y para alterar la configuración de la reden las diferentes capas de la red) así como las reglas respecto a cómo los centros de gestión en stand-bydeberían asumir las funciones de gestión de red en caso de emergencia , tienen que ser determinadasdurante el diseño del sistema.La figura 3.4.9 muestra el esquema de un sistema TMN jerárquico gestionando una red SDH estratificada.

La red ilustrada consiste de tres capas: las capas de red nacional , regional , y local. Cada una de ellas estágestionada por un centro de gestión separado ; ellos , en turno , son conectados a sus respectivas capas dered en dos nodos de red , utilizando dos canales de comunicación separados e interfaces Q3 estándares.(Tomando un ejemplo práctico , una de las interconexiones duplicadas puede ser implementada a través

26

de la red gestionada y la otra , a efectos de incrementar la seguridad , a través de un canal decomunicación independiente).Adicionalmente , los centros de gestión son interconectados vía los canales de comunicación apropiados ,utilizando interfaces X. (Estas interconexiones pueden también ser realizadas a través de la red gestionadavía sus canales reservados disponibles especialmente para este propósito.)

3.4.5.4.3 Gestión de elementos de red (NEs) de una red PDHEn la práctica , la gestión de red a menudo tiene que ser extendida a algunos componentes de sistema no-SDH , tales como elementos ó segmentos basados en tecnología PDH interfaceada a la red SDH/SONETgestionada. Esto puede ser más necesario para que la carga de tráfico de PDH pueda ser mapeada dentrode contenedores virtuales de la estructura multiplex de SDH.Sin embargo , esto acarreará la dificultad de que la gestionabilidad de los elementos de red PDH esbastante limitada , tanto en principio como en práctica. Esto es parcialmente porque hay una capacidad decanal escasa para transferir información de gestión en una red PDH , parcialmente porque la tecnología desistemas PDH no soportan funciones de gestión de configuración dinámica , y parcialmente porque loselementos de red PDH no pueden manejar protocolos Q. La gestión de PDH no es siquiera soportada porlos estándares de TMN al presente. De acuerdo a la recomendación M.3180 , existen planes para cubrirequipamiento de transmisión PDH relacionado con el modelo de información de capa de red de TMN.Sin embargo , en la medida en que los Sistemas de Gestión de Red actuales sean capaces de procesarinformación de gestión de red a nivel de elemento en formatos diferentes , no-TMN compatibles (ej.: encódigo ASCII) , la gestión de segmentos de red PDH con limitada funcionalidad resulta aún posible en lapráctica.

3.4.6 TMN y GIS (Geographic Information System)

Los beneficios de GIS podrían ser aplicados para soportar procesos de negocios de proveedores deservicios de telecomunicaciones. Los beneficios de uso son obvios considerando que los servicios detelecomunicaciones están relacionados extremo a extremo , incluyen un número de dominios geográficos, y múltiples proveedores con diferentes infraestructuras de red. La gestión de infraestructuras físicas ylógicas requiere documentación muy segura. El estado-del-arte de los sistemas de documentación trabajancon mapas digitales que pueden ser adquiridos a otros proveedores.Las tareas de gestión de red pueden ser definidas y soportadas en varias capas TMN. El nivel de detalles yel tipo de información requerida difiere en cada capa. Las capas de gestión de Servicio y de gestión deNegocio pueden estar utilizando aplicaciones tridimensionales que pueden no ser requeridas en las capasde gestión de Red y de Elemento.La aplicabilidad de GIS será evaluada para tres capas de TMN. La relación funcional de TMN y GIS semuestra en la figura 3.4.10.

3.4.6.1 Capa de gestión de RedLa presentación y documentación gráfica de redes físicas pertenece a las tareas tradicionales deaplicaciones CAD/CAM. Los principales documentos incluyen cables (tierra y aire) , ductos de cables ,bóvedas y columnas , edificios de las telco , ubicación de equipamiento , asignación de puertos paraconectar pares , y pares a cables , respectivamente ; adicionalmente , también se deben mantener otrosatributos técnicos de componentes. Es dable esperar que los detalles de los atributos de componentes seanmantenidos en la capa de gestión de Red.La aplicaciones de GIS son extremadamente importantes para redes de comunicación inalámbrica , talescomo sistemas de telefonía móvil , URH , y satélites , para analizar los modelos de difusión de onda. Losmodelos también incluyen áreas de cobertura y geografía de las áreas seleccionadas. Items de inventarioson parte de la gestión de configuración estática.Básicamente hay dos tipos de soluciones de gestión de configuración. La gestión de configuracióndinámica significa la configuración inmediata de rutas , sobre la base de datos de status y performance entiempo real , y de facilidades y equipamiento. Es obvio que las aplicaciones GIS no pueden soportar estasfunciones de gestión por sus capacidades de servicios de presentación tridimensional. La gestión deconfiguración estática incluye el cambio y configuración lógica de rutas , configuraciones deequipamiento , ó ambos; mantenimiento de tipos y ubicaciones de equipamiento ; mantenimiento denombres y direcciones físicas y simbólicas ; también se pueden mantener otros atributos y mostrar suinformación. En caso de relativa estabilidad en los parámetros de configuración

27

,las aplicaciones GIS pueden ser utilizadas satisfactoriamente para la representación de rutas físicas ylógicas de la red sobre varios mapas digitales.

Las aplicaciones GIS contribuyen satisfactoriamente a mejorar las gestiones de performance , fallas , yseguridad.Las métricas de performance , perfiles de carga , fallas eventuales e interrupciones , ó violaciones deseguridad , pueden ser posicionadas y representadas sobre los mapas digitales precisos. Este tipo depresentación ayuda a estimar y cuantificar los impactos sobre clientes y áreas de servicio en tiempo realcon los resultados de resolución expeditiva de problemas , balance de carga , y preservación de seguridad.GIS es también una gran ayuda para funciones de mantenimiento preventivo y reactivo. GIS puedeapuntar la localización de fallas con gran seguridad , puede resaltar la ruta óptima para que el grupo detrabajo llegue al sitio , y puede buscar y ensamblar la documentación de soporte apropiada.

3.4.6.2 Capa de gestión de ServicioLa gestión de servicios requiere datos precisos sobre la configuración de servicio , métricas de nivel decalidad de cliente , y métricas reales pactadas sobre acuerdos de nivel de servicio (Service LevelAgreements: SLA). GIS puede asistir para rescatar muy rápidamente , información sobre perfiles de carga, resúmenes de fallas , extensiones de red ,y visualización de áreas de servicio ; también se puede ejecutar, casi en tiempo real , la correlación de esta información , con clientes ,contratos , subcontratos , SLAs ,facturas y presentación de facturas. El resultado es que la calidad de cuidado del cliente es mejorada , ycrece su satisfacción.

3.4.6.3 Capa de gestión de NegocioLa gestión de negocio requiere un número de decisiones tácticas y estratégicas en beneficio de la gestión“top”. Este es el área donde el planeamiento de recurso de empresa (Enterprise Resource Planning: ERP)puede ser más efectivamente utilizado. Este puede soportar decisiones sobre temas complejos einterrelacionados , en donde la visualización sobre la base de GIS puede ser útil. Ejemplos devisualización pueden incluir la vista de segmentos de red , la posición y tamaño de las áreas de servicioexistentes , comparación con estadísticas de ingreso de otros proveedores de servicio por áreas de servicio, antecedentes de datos estadísticos para soportar el marketing , datos demográficos por áreas de servicio ,y nivel de consumo esperado por regiones.La mayoría de estos datos no están disponibles en los sistemas de documentación y gestión tradicionales.GIS y data warehousing combinados pueden ofrecer una mejora significativa en el soporte para la gestióntop de proveedores de servicio y también de empresas.En resumen , la significante colaboración entre TMN ,GIS , y ERP (figura 3.4.11) asegurarán una másalta calidad de intercambio de información y presentación para los proveedores de servicio.

28

3.4.7 Tendencias en la evolución de TMN

Los próximos pasos en la evolución de TMN serán muy probablemente dirigidos por los siguientesfactores , siendo característico de la situación global de la industria de las telecomunicaciones en losprimeros años del siglo 21:

. La importancia creciente de los aspectos comerciales de la operación de red de telecomunicaciones ,tales como rentabilidad de inversiones , costos , beneficios y competitividad de servicios de red , etc

. La evolución de la tecnología de telecomunicaciones de banda ancha y el predominio creciente de lasarquitecturas de red más modernas , tales como ATM , redes inteligentes (Intelligent Networks: IN) ,etc, tanto en los dominios de red públicos y corporativos ó privados

. La proliferación de herramientas hardware/software disponibles en el mundo de las telecomunicaciones

. La esfera perpetuamente creciente de servicios de telecomunicaciones y sus aplicaciones , tales comoservicios móviles , aplicaciones de vídeo y multimediales , el área en crecimiento del uso de Internet ,tales como compras on-line , etc

. La globalización del mundo de las telecomunicaciones , la integración de LANs y WANs , eldesvanecimiento de los límites entre dominios de red públicos y privados , sistemas de transmisión devoz , datos , y vídeo , etc

Como se concluye de todos estos aspectos generales , los siguientes cambios ocurrirán probablemente enla evolución de TMN , en relación a sus características y funcionalidad:

. El foco de la gestión de red se desplazará de la visión central de elemento de red y de red , primero a lagestión de servicio , y luego a la capa de gestión de negocio ; esto significa que se elaborarán losestándares relevantes y las soluciones gradualmente aparecerán en el mercado

. La importancia de la gestión extremo a extremo y la gestión de cliente se incrementarán (ver sección3.4.4.2)

Reflejando estos requerimientos funcionales sobre la plataforma de tecnología de software , hay tareasactuales que se incrementarán (y se han incrementado) , y que deben ser completadas , tales como:

. Definición de modelo estándar de objeto distribuido que satisfaga los requerimientos de gestión deservicio para TMN (ver sección 3.4.3.5.2)

. Definición de estándares y desarrollo de soluciones reales para gestionar tecnologíasde telecomunicaciones modernas actualmente no cubiertas por TMN ( en primer instancia , lo referido aATM)

29

. Integración de TMN con las plataformas foráneas más importantes en el campo de la gestión de red , talcomo SNMP (ver sección 3.4.4.1)

. Mapeo de TMN dentro de algunas de las más recientes arquitecturas de telecomunicaciones (tales comoTINA y IN) teóricamente capaces de ser integradas con TMN (ver sección 3.4.5.2)

. Integración de TMN con algunos sistemas de información externos operados fuera del campo de lastelecomunicaciones que , sin embargo , tienen conexiones funcionales estrechas con TMN , tal comosistemas integrados de gestión de negocios corporativos (ver sección 3.4.3.3) ó (representando uno delos desafíos más recientes para TMN) , Geographic Information Systems (GIS)

Como resultado de los desarrollos presentes y futuros , el campo de las soluciones TMN posibles ,permitidos por la totalidad del set de estándares relacionados , será más y más complejo. Esta situaciónestablece una gran tarea para los operadores y/o diseñadores de red que deben afrontar el problema deespecificar un Sistema de Gestión de Red apropiado para efectivamente satisfacer los requerimientos desu aplicación especial. Esto significa que el diseño y la especificación de una solución TMN real deberíaser ejecutada seleccionando las funciones relevantes de TMN , del set sinfín de posibilidades estándares ,y no simplemente establecer ó requerir el cumplimiento con el “estándar TMN”