Prólogo Este libro pretende ser una guía introductoria al mundo de la gestión de red. A lo largo de las páginas siguientes se ha tratado de dar más una visión general de las arquitecturas y entornos de gestión de red que de definir las funcionalidades específicas de un determinado protocolo de gestión de red. El contenido del presente texto constituye el temario básico para la asignatura de gestión de red que se imparte en la ETSE de Telecomunicaciones de Barcelona (Universitat Politècnica de Catalunya). Últimamente, aspectos como el control, la gestión de red o la gestión de servicios están teniendo cada vez más una mayor importancia para los operadores de red. Una de las razones fundamentales está en que los clientes cada vez exigen mayor calidad de servicio a un menor precio. El factor externo lo constituye el hecho de que actualmente, con la liberación del mercado de las telecomunicaciones, los usuarios pueden elegir libremente su operador de red. De esta forma, se ha desatado la competencia entre operadores para mantener la mayor cuota de mercado posible. Hay que tener en cuenta que, desde un punto de vista técnico, la fidelidad del cliente se puede obtener o mantener mejor si la calidad del servicio que proporciona el operador de red es la óptima. En el texto se realiza una descripción pormenorizada de cada entorno de gestión; el temario que se ha planteado se divide en tres grandes áreas, empezando por la gestión de servicios, introduciendo el sistema de señalización nº 7, las redes inteligentes y TINA. A continuación, en la segunda parte, basada en los grandes estándares de gestión, se dedican varios capítulos a los protocolos, recomendaciones y estándares más utilizados. En la tercera parte, se abordan los aspectos más prácticos o de aplicación y se describe cómo se realiza la gestión en redes avanzadas como son BRDSI o UMTS. Finalmente, se da un repaso a las plataformas y herramientas de gestión de red más importantes disponibles en el mercado.
2 Gest Gestió iónn de ser servi vici cios os 2.1 Introducción al sistema de señalización nº 7 (SS7)............ ..................................................... 17 2.1.1 Arquitectura de la red SS7/CCS .................................................... .............................. 18 2.1.2 Tipos de protocolos .................................................. ................................................... 20 2.2 Redes inteligentes......................................................................................................................22 2.2.1 Contexto y objetivos .............................................. .................................................... ..22 .. 22 2.2.2 Introducción a las redes inteligentes .............................................................. .............. 22 2.2.3 Evolución de la red inteligente ............................................................................ ........ 23 2.2.4 Componentes de la red inteligente inteligente avanzada (Advanced Intelligent Network, AIN) ....23 2.2.5 Arquitectura funcional de la red inteligente................................................................. 24 2.2.6 Dimensionado de un SCP ................................................... ......................................... 26 2.2.7 Modelo de llamada básico de la red inteligente.. ......................................................... 29 2.3 TINA (Telecommunications Information Networking Architecture). .................................... 29 2.3.1 Arquitectura de computación TINA ................................................... ......................... 30 2.3.2 Arquitectura de servicio TINA ................................................ .................................... 31 2.3.3 Arquitectura de red TINA......................... ........................................................ ........... 32 2.3.4 Arquitectura de gestión TINA ................................................ ..................................... 32 2.3.5 Evolución de la red inteligente hacia TINA ................................................................ 34 2.4 Creación de servicios ........................................................ ...................................................... 34 2.4.1 Entorno de creación de servicios ............................................ ..................................... 36
3 Soluciones para la gestión de redes 3.1 Evolución de las redes de telecomunicaciones ................................................... .................... 37 3.2 Modelos para la monitorización y el control de red......................................................... red ......................................................... ....... 42
Gestión de red
10
3.2.1 Arquitecturas propietarias............................. ....................................................... ........ 42 3.2.2 Plataformas de gestión.................................................................................................44 3.2.3 Clases de productos de gestión ................................................. ................................... 44 3.2.4 Productos de gestión de LANs standalone...................................................................44 3.2.5 Gestión de LANs de PCs ................................................... .......................................... 46 3.2.6 Sistemas de gestión de elementos de red de área local (LAN) .................................... 47 3.2.7 Integradores para gestión de LANs..............................................................................48 3.3 Mecanismos para la detección de configuraciones de red ......................................................52 3.3.1 RPE (Regulated Poll Emission).................................................................. ................. 53 3.3.2 Modelado de la duración de un ciclo de consultas de eestatus .................................... 53 3.3.3 Duración media del tiempo de ciclo de K intentos ...................................................... 54 3.3.4 Número esperado de intentos de polling en un ciclo ................................................... 55 3.3.5 Flujos del ciclo de polling............................................................................................56 3.3.6 Análisis del retardo......................................................................................................57
4
Entornos de gestión de telecomunicaci ón orientados a objetos
4.1 Introducción a la orientación a objetos ...................................................................................59 4.2 Objetos gestionados y el entorno gestor/agente ................................................ ...................... 59
5
Gestión según OSI
5.1 Modelo funcional ........................................................... ..................................................... ....63 5.2 Modelo de organización..........................................................................................................64 5.3 Modelo de comunicaciones: CMIP...................................................... ................................... 64 5.3.1 Caracterí sticas principales del protocolo CMIP ..........................................................66 5.3.2 Servicios usados por CMIP ............................................... .......................................... 67 5.3.3 Servicios ofrecidos por CMIP ................................................... .................................. 67 5.3.4 Primitivas CMIP ........................................................... ............................................... 68 5.3.5 Arquitectura de comunicaciones............................................... ................................... 69 5.3.6 X/Open Abstract Data Manipulation Application Program Interface XOM ............... 70 5.3.7 X/Open Management Protocols Application Program Interface (XMP) ..................... 71 5.3.8 CMIS/P++....................................................................................................................72 5.4 Modelo de información...........................................................................................................72 5.4.1 MIB (Management Information Base) ....................................................... .......................... 76 5.4.2 GDMO (Guidelines for Definition of Managed Objects) ....................................................77
6
Red de gesti ón de las telecomunicaciones (TMN)
6.1 6.2 6.3 6.4 6.5
Arquitectura f ís ica...................................................................................................................83 Modelo organizativo .................................................... ....................................................... ....84 Modelo funcional ........................................................... ..................................................... ....85 Modelo de información...........................................................................................................86 Implementación f í sica de las funciones de la TMN................................................................87
Í ndice
7
11
Áreas funcionales de gesti ón 7.1 Gestión de fallos .....................................................................................................................91 7.1.1 Identificación de fallos en redes de comunicaciones ................................................... 92 7.2 Gestión de configuración ................................................. ....................................................... 94 7.3 Gestión de prestaciones...........................................................................................................94 7.4 Gestión de tarificación ..................................................... ....................................................... 95 7.5 Gestión de seguridad...............................................................................................................95
8
Funciones de gesti ón de la red de se ñalización
8.1 Controles de flujo MTP en la red de señalización...................................................................97 8.1.1 Gestión del enlace de señalización ..............................................................................98 8.1.2 Gestión del tráfico de señalización .................................................... .......................... 98 8.2 Control de flujo de tráfico de señalización..............................................................................99 8.2.1 Gestión de rutas de señalización..................................................................................99 8.3 Control nodal MTP ......................................................... .................................................... ..101 8.3.1 Controles SCCP............................................... ........................................................ ..103 8.3.2 Controles de congestión automáticos.........................................................................103 8.4 Gestión de fallos ...................................................................................................................103 8.5 Arquitectura de gestión de red de señalización.....................................................................104 9
Gestión de redes virtuales
9.1 Introducción ................................................. ........................................................ ................. 105 9.2 Estándares de VLAN ............................................................................................................105 9.3 Gestión de red en VLAN ......................................................................................................105 9.3.1 Seguridad en VLAN ....................................................... ........................................... 106
10 Gestión de la red B-RDSI
10.1 Introducción a la gestión de la red B-RDSI ..........................................................................110 10.2 Interfaces en la red de gestión de banda ancha. ....................................................................112 10.2.1 Interfaces definidas por el ATM Forum ............................................ ........................ 112 10.3 ATM Forum..........................................................................................................................113 10.3.1 ILMI ..........................................................................................................................113 10.3.2 Celdas OAM ..................................................... ........................................................ .114 ...... 10.4 IETF en ATM .......................................................................................................................114 10.4.1 AToM: RFC 1695......................................................................................................114 10.5 Tendencias y análisis comparativo entre estándares de gestión ATM .................................. 114 10.6 Control de tráfico en redes ATM ................................................ .......................................... 115 10.6.1 Calidad de servicio ....................................................................................................115 10.6.2 Parámetros de tráfico .................................................... ............................................. 116 10.6.3 Descriptores de tráfico...............................................................................................117 10.6.4 Mecanismos de control de tráfico..............................................................................117 10.7 Funciones de control de congestión .................................................... .................................. 118 10.7.1 Control de flujo..........................................................................................................119
Gestión de red
12
10.8 Recuperación en redes ATM.................................................................................................120 10.8.1 Mecanismos de recuperación ATM alternativos .......................................................120 10.8.2 Redes de protección ATM ....................................................... .................................. 121 10.8.3 Redes reconfigurables................................................................................................121 10.8.4 Redes ATM autorecuperables....................................................................................122 10.8.5 Autorecuperación con backup de VPs semidedicados...............................................122 10.8.6 Restauración multicapa..............................................................................................123
11 Gestión en redes de comunicaciones m óviles
11.1 Introducción a las comunicaciones personales......................................................................125 11.1.1 Comparación entre la gestión en sistemas cableados y sistemas de comunicación móviles ..........................................................................................127 11.1.2 Arquitectura de la red GSM.......................................................................................128 11.2 Arquitectura de las redes PCS...............................................................................................130 11.2.1 Caracterí sticas de los sistemas basados en PCS.........................................................130 11.2.2 Servicios PCS ....................................................... ..................................................... 135 11.2.3 Gestión de movilidad.................................................................................................136 11.2.4 Gestión de recursos....................................................................................................136 11.2.5 Métodos de acceso en PCS........................................................................................137 11.2.6 Protocolo de señalización ............................................... ........................................... 137 11.2.7 Red inteligente para servicios personales en redes de comunicaciones móviles avanzadas ........................................................... .......................................... 138 11.3 Funciones de gestión. Objetos gestionados...........................................................................139 11.4 Red inteligente y sistemas de comunicación móviles ....................................................... ....140 11.4.1 Caracterí sticas de los servicios UPT..........................................................................140 11.4.2 Seguridad en la red .................................................. .................................................. 142 11.4.3 Servicios UPT de red inteligente sobre red GSM......................................................142 11.4.4 Red inteligente en GSM: CAMEL.............................................................................149 11.5 Evolución de PCS hacia sistemas de tercera generación.......................................................149 11.5.1 Arquitectura de la red UMTS ................................................ .................................... 150 11.5.2 Estructura de directorios en la red fija. Bases de datos distribuidas .......................... 151 11.5.3 Distribución de información en las bases de datos ................................................. ...152 11.5.4 Conclusiones..............................................................................................................153
12 Gestión en Internet
12.1 Introducción ................................................. ........................................................ ................. 155 12.2 Evolución ......................................................... ............................................................ ......... 156 12.3 Estructura de la información de gestión................................................................................156 12.4 Sintaxis ASN.1......................................................................................................................157 12.4.1 Tipos simples.............................................................................................................158 12.4.2 Tipos estructurados....................................................................................................158 12.4.3 Tipos etiquetados (tagged ) ........................................................................................159 12.4.4 Subtipos ASN.1 ........................................................ ................................................. 159 12.5 Bases de información de gestión (MIB)................................................................................160 12.5.1 MIB-I.........................................................................................................................164
Í ndice
13
12.5.2 MIB-II........................................................................................................................164 12.5.3 MIBs experimentales.................................................................................................168 12.5.4 MIBs privadas............................................................................................................169 12.6 Simple Network Management Protocol (SNMP)..................................................................169 12.6.1 Operaciones de SNMP...............................................................................................171 12.6.2 Codificación para la transferencia de la información de gestión: BER .....................173 12.7 Configuración y rendimiento de una red gestionada por el protocolo SNMP.......................173 12.7.1 Interrogación ( polling) de estatus de dispositivos......................................................174 12.7.2 Interrogación ( polling) de descubrimiento ( Discovery).............................................174 12.7.3 Interrogación ( polling) de configuración de topologí a ..............................................174 12.7.4 Interrogación ( polling) de chequeo de configuración de dispositivo.........................174 12.7.5 Interrogación ( polling) de estatus de estación de sondeo...........................................174 12.7.6 Otras aplicaciones......................................................................................................174 12.8 Marco administrativo ................................................... ....................................................... ..175 12.9 Configuraciones para el uso del protocolo SNMP en entornos heterogéneos.......................175 12.9.1 Sistemas de gestión de red basados en SNMP emergentes........................................175 12.9.2 Sistemas de gestión de LANs heterogéneas...............................................................176 12.9.3 Valoración crí tica de las MIB en SNMP ...................................................................177 12.10 Conclusiones sobre SNMP ................................................... ............................................... 177 12.11 Comparación entre los protocolos CMIP y SNMP..............................................................177 12.12 SNMPv2 ........................................................... ......................................................... .......... 178 12.12.1 Operaciones de SNMPv2 ............................................... .......................................... 179 12.13 SNMPv3 .......................................................... .......................................................... .......... 180 12.14 Remote Network-Monitoring (RMON)...............................................................................181 12.15 RMON 2..............................................................................................................................183 12.16 RMON 3..............................................................................................................................184
13 Gestión distribuida
13.1 Distributed Computing Environment (DCE).........................................................................185 13.1.1 Componentes principales de DCE .............................................. ............................... 185 13.1.2 Restricciones en el uso de DCE.................................................................................186 13.1.3 Razones para escoger DCE........................................................................................186 13.2 Distributed Management Environment (DME).....................................................................186 13.3 CORBA. Gestión según OMG..............................................................................................188 13.3.1 Arquitectura CORBA ............................................ .................................................... 189 13.3.2 Pasarela CORBA/CMIP ............................................................................................191 13.3.3 Conclusiones..............................................................................................................192 13.4 Distributed Component Object Model (DCOM) ..................................................................192 13.4.1 OLE y el modelo de objeto COM..............................................................................193 13.5 Gestión basada en agentes inteligentes móviles....................................................................193 13.5.1 Introducción a los agentes inteligentes ................................................................. .....193 13.5.2 Clases de agentes inteligentes....................................................................................194 13.5.3 Agentes móviles ........................................................................................................195 13.5.4 Arquitecturas de comunicaciones basadas en agentes .............................................. .195 13.5.5 Gestión basada en agentes ...................................................... ................................... 197 13.5.6 Procesos elásticos ...................................................... ................................................ 200
15.1 Common Information Model (CIM) ................................................... .................................. 208
16 Plataformas de gestión de red
16.1 Plataformas de gestión ..................................................... ..................................................... 209 16.2 Plataforma de gestión de red OpenView ...............................................................................210 16.3 SunNet Manager (SUN)........................................................................................................210 16.4 IBM System View para AIX ..................................................................................................211 16.5 SPECTRUM de Cabletron....................................................................................................212 16.6 TME10 (Tivoli Management Environment) ................................................... ...................... 212
Anexo I: recomendaciones y normas ........................................................ .......................................... 221 Anexo II: direcciones en Internet........................................................................................................225
1. Introducción
15
1 Introducción La gestión de red trata sobre la planificación, la organización, la supervisión y el control de elementos de comunicaciones para garantizar un adecuado nivel de servicio, y de acuerdo con un determinado coste. Los objetivos principales de la gestión de red consisten en mejorar la disponibilidad y el rendimiento de los elementos del sistema, así como incrementar su efectividad. Desde el momento en que las redes se consideran cada vez más una parte importante y estrátegica de las empresas, industrias u otros tipos de instituciones y como resultado de las cada vez mayores dimensiones que están adoptando, resulta pues más importante su control y gestión con el fin de obtener la mejor calidad de servicio posible. Tradicionalmente, en la gestión de las redes se ha partido de soluciones propietarias y cerradas con un ámbito de actuación limitado a la propia empresa o dominio de la institución. Con el tiempo, la evolución tecnológica ha permitido la entrada de múltiples fabricantes de equipos, de la misma forma que otros fabricantes de reputado nombre han desaparecido y, en consecuencia, también el apoyo que prestaban a sus soluciones de red. Por tanto, bien sea porque ha ocurrido la absorción de empresas o bien por diversificación de las fuentes de los equipos, las redes actuales son cada vez más heterogéneas en equipos. Uno de los problemas más graves que tienen estas redes es que los equipos que las constituyen son de fabricantes distintos, con lo cual la única forma de gestionarlas es a partir de sistemas de gestión que utilicen estándares abiertos con el fin de compatibilizar protocolos e información. De esta forma, durante la década de los noventa, se han ido desarrollando diversas iniciativas con el objetivo de ofrecer recomendaciones y estándares abiertos para tratar de dar solución a estas nuevas problemáticas, como por ejemplo mediante el protocolo de gestión SNMP o el CMIP. Para proporcionar una calidad de servicio adecuada mediante la gestión de redes, se parte de unos recursos humanos que mediante una serie de herramientas aplican unas determinadas metodologías a la red. Este texto versa sobre herramientas y métodos que se pueden emplear en la gestión de red. Las recomendaciones sobre esta temática provienen de diversos grupos de estandarización. La más importante, la ITU–T, ha definido la red de gestión de las telecomunicaciones (TMN). Estas recomendaciones definen cinco áreas funcionales para la gestión de red, las de supervisión y fallos, configuración, tarificación, prestaciones y seguridad. La organización de la gestión puede estructurarse también según un criterio temporal. De esta forma, se puede hablar de un control operacional que opera a muy corto plazo y a bajo nivel, una administración que opera a corto plazo y a bajo-medio nivel, un análisis de la gestión que opera a medio plazo y a medio-alto nivel y finalmente una planificación a largo plazo y a más alto nivel.
En el control operacional, las operaciones realizadas a este nivel deben quedar registradas, para su posterior análisis por el administrador de red. Es el caso de operaciones tales como la recogida de datos sobre prestaciones y utilización de la red, la evaluación de alarmas, la diagnosis de problemas, el arranque y la parada de los componentes de la red, la ejecución programada de pruebas preventivas, la modificación de configuraciones o la carga de nuevas versiones de software. Las funciones principales de la administración consisten en seguir las tareas de control operacional y en elaborar informes periódicos para su posterior análisis. Por ello se ocupa de tareas como la evaluación de la calidad de servicio, la evaluación de tráfico, el mantenimiento de registro histórico de problemas, el mantenimiento de inventario, el mantenimiento de configuraciones, la contabilidad de red y de control de acceso. El objetivo del análisis es garantizar la calidad de servicio y, finalmente, la planificación se encarga de las decisiones dependientes del negocio al que se dedica la empresa.
1.1 Monitorización, control, gestión Llegados a este punto, sería conveniente distinguir entre monitorización, control y gestión de una red. Se utiliza el término monitorización para designar el tipo de acciones consistentes en obtener información de la red con el fin de detectar anomalías. Estas acciones son pasivas y su único objetivo es conocer el comportamiento respecto al tráfico del sistema. Una vez se conoce el sistema se puede proceder al control: para ello se establece una señalización o plano de control en toda red que se ocupa de regular activamente las comunicaciones y, en general, el tráfico de la red. Un ejemplo de red de control es el sistema de señalización nº 7. Finalmente, la gestión se define a partir del plano de gestión que integran las redes más avanzadas como RDSI, GSM, etc. Como ejemplo de red de gestión se puede citar la TMN (Telecommunications Management Network ) definida por la ITU-T. Según las áreas funcionales de gestión definidas por la ITU-T, la monitorización de red se utiliza para proporcionar información en la gestión de las funciones de prestaciones, fallos, contabilidad y en determinados aspectos de configuración, mientras que el control de red se aplica a las funciones de configuración y seguridad. En el proceso de monitorización de la red se consideran una serie de aspectos como son: en primer lugar, una definición de la información de gestión que se monitoriza, una forma de acceso a la información de monitorización, un diseño de los mecanismos de monitorización y, finalmente, un procesado de la información de monitorización obtenida. Por otra parte, la información de monitorización puede clasificarse según su naturaleza temporal en: información estática que se almacena en los elementos monitorizados (p.e. inventario); información dinámica que se almacena en los propios elementos o en equipos especializados (p.e. cambios de estado o fallos) e información estadística que se genera a partir de la información dinámica y que puede residir en cualquier lugar que tenga acceso a la información dinámica (p.e. rendimientos). Los mecanismos de monitorización se basan fundamentalmente en un sondeo o polling por parte de la estación gestora, esto es, en un acceso periódico a la información de gestión almacenada en los nodos gestionados. Este método tiene la ventaja de que los objetos que se gestionan únicamente deben estar preparados para responder, con lo que es más simple. Otros mecanismos que se emplean, desde el punto de vista del agente gestionado, se denominan event reporting o notificaciones, donde son los propios recursos quienes envían mensajes bajo ciertas condiciones; de esta forma tienen como ventaja el hecho que se minimiza el tráfico de gestión por la red. Otros métodos son mixtos, se basan en proxies, sondas, etc, y combinan los dos mecanismos anteriores.
2 Gestión de servicios Una parte cada vez mayor de los ingresos que obtienen los operadores de red parte de los servicios de valor añadido que aportan los proveedores de servicios. Para soportar estos servicios se hace necesario una infraestructura basada en las redes inteligentes y cada vez más en lo que se ha denominado últimamente inteligencia de red basada en estándares, como por ejemplo TINA.
2.1 Introducción al sistema de señalización nº 7 (SS7) La red de señalización nº 7 (también denominada Channel Common Signalling, CCS) es la red que se ocupa de la señalización y constituye el soporte básico de las redes inteligentes. Esta red se define de forma separada de la red de transporte de información. En su forma básica consta de nodos llamados puntos de señalización (SPs) interconectados por enlaces de transmisión. La red se constituye con los siguientes tipos de nodos: Service Switching Point (SSP). Punto de conmutación de servicio Signal Transfer Point (STP). Punto de transferencia de señal Service Control Point (SCP). Punto de control de servicio Intelligent Peripheral (IP). Periférico inteligente
y de diversas configuraciones de interconexiones entre los nodos, formadas por Signaling Links (SLs) o enlaces de señalización [BLA2, RUS1]. SCE SCP: Punto de control de servicios SSP: Punto de conmutación de Servicios STP: Punto de transferencia de señalización SMS: Sistema de gestión de servicios IP: Periférico inteligente SDP: Punto de datos de servicios
SCP
SMS
SDP Red de señalización SS7
IP
STP AD/SN SSP
Local Local
Terminal del usuario
RTC
A
Fig. 2.1 Esquema de bloques de la red SS7 en un entorno de red inteligente
La red SS7 constituye la base de la red inteligente y de lo que se ha venido a llamar más recientemente inteligencia de red. En los próximos capítulos se describirán más pormenorizadamente sus funciones y componentes.
2.1.1 Arquitectura de la red SS7/CCS La arquitectura de la red SS7/CCS (señalización por canal común) está formada por nodos y diversos tipos de enlaces que están configurados de forma que aporten la máxima fiabilidad al sistema. A continuación se describen las características principales de estos tipos de nodos. Punto de conmutación de servicio (SSP) Los puntos de conmutación de servicio (SSP) son centros de conmutación equipados para manipular señalización troncal así como señalización de servicios o servicios de transacciones con las bases de datos dentro y fuera de la red. También transfieren mensajes SS7 a otros puntos de señalización dentro de la red. Los puntos de señalización se despliegan en pares, por cuestiones de redundancia y diversidad; de esta forma en caso de fallo siempre puede desviarse el tráfico por rutas alternativas. El objetivo consiste en mantener el máximo del tiempo posible la red operativa. Punto de transferencia de señal (STP) Los STP o conmutadores de alta fiabilidad que enrutan mensajes SS7 entre los nodos de la red y se basan en la información del propio mensaje o bien en información almacenada en tablas de encaminamiento. Se despliegan de forma separada para permitir mayor fiabilidad al sistema y asegurando la duplicidad del software. Los STP proporcionan una transferencia de mensajes eficiente entre todos los nodos de señalización en una red SS7. Pueden realizar funciones de gateway para transferir mensajes de señalización a otras redes de señalización SS7 (uso de MTP). También el encaminamiento especializado es función del SCCP (acceso a bases de datos). Cada número concreto accede a un servicio diferente. Existe una tabla en cada STP que indica para cada número el SCP y el enlace que se debe utilizar para enviar el mensaje. El número de enlaces en cada ruta suele ser de 1 a 16. Los STP utilizan enlaces para sus interconexiones que suelen calcularse para un 40 % de su capacidad. La idea es que si uno de ellos (enlace o STP) falla, el otro soporte hasta un 80 % de tráfico, dentro todavía del margen de capacidades. Cada enlace de su grupo de enlaces se identifica con un Signaling Link Code (SLC). Los enlaces que conectan centrales entre sí y/o tándems de acceso y SCP's a STPs se denominan enlaces de acceso o enlaces A . Cada nodo se conecta como mínimo con un par de nodos jerárquicos (superiores e inferiores) para mayor fiabilidad. Cada SCP suele tener un mínimo de tres enlaces y un máximo de cinco enlaces a cada par de STPs a los que está conectado. Se trata de una limitación por hardware (existente en centrales de AT&T), según el número de tarjetas front-end (a 2 enlaces por tarjeta) que puede soportar el SCP.
Fig. 2.2 Esquema de red SS7 con los enlaces tipo A
Los enlaces B (o enlaces puente) se establecen entre pares de STP en el mismo nivel jerárquico (p.e. regiones distintas). En este caso se aconseja una diversidad de tres caminos para cada conjunto de enlaces, con un máximo de ocho enlaces.
STP
STP Enlaces B
Enlaces SS7 Enlaces B STP
STP
Fig. 2.3 Esquema de red SS7 con los enlaces tipo B
Los enlaces que conectan pares de STP j untos se denominan enlaces C o cross links, con al menos dos enlaces para cada conjunto de enlaces. La principal función de los enlaces C es llevar mensajes de gestión de red. Se implantan al menos dos STP por región.
Fig. 2.4 Esquema de red SS7 con los enlaces tipo C
Los enlaces en diagonal o enlaces D conectan STPs de diferentes niveles jerárquicos (p.e. STP local y STP regional). Generalmente se disponen con al menos tres rutas alternativas. Cada conjunto de enlaces tiene un máximo de ocho enlaces. Los enlaces que conectan SPs a STPs diferentes del par asociado originariamente se denominan extended links o enlaces E. Un mínimo de uno y un máximo de 16 enlaces E se utilizan desde cada SP/SSP para conectar a sus compañeros STPs en una nueva área de servicio. Los enlaces F o fully associated links se conectan directamente entre SPs/SSPs siempre que no hayan STPs. Como máximo se utilizan16 enlaces y no hay conexión a nodos inteligentes de la red. Los nombres de estos enlaces sólo determinan las funciones que realizan puesto que físicamente son idénticos. En una configuración en un único nivel, un par de STPs proporciona todos los encaminamientos de mensajes de señalización dentro de su área de servicio. Esto incluye mensajes database query type y call setup type. En la configuración a dos niveles, existen pares de STPs a nivel local (LSTP) y pares de STPs a nivel regional (RSTP). Punto de control de servicio (SCP) Los SCP son bases de datos multifuncionales, centralizadas, on-line, que almacenan datos de clientes y lógica de servicio para responder a peticiones procedentes de SSPs. Por ejemplo, convertir números 800 (900) en encaminamientos para números de la red básica, validar números, etc. Se despliegan de forma separada para permitir mayor fiabilidad al sistema y asegurando copias duplicadas del software. Por razones de fiabilidad, los SCPs se duplican siempre, pudiendo o no estar duplicadas las bases de datos asociadas (SDPs).
2.1.2 Tipos de protocolos Los SL o Signaling Links conectan todos los nodos de la red SS7. Cada enlace se administra de forma diferente según los nodos a los que conecta. Son enlaces síncronos bidireccionales a 64Kbps (56 Kbps en U.S.). El protocolo SS7 es el modelo en capas que cubre la comunicación entre nodos inteligentes en la red CCS.
Enlace Físico Fig. 2.5 Torre de capas del protocolo SS7
Message Transfer Part (MTP) MTP (Message Transfer Part ): realiza las funciones de transporte de las capas inferiores comunes a todas las aplicaciones de los niveles superiores, selección del enlace de señalización, detección y corrección de errores, conexión física a los enlaces. También proporciona gestión de red para el control de flujo en caso de congestión de l a red. A nivel de red el protocolo proporciona encaminamiento dentro de la señalización de red, control de fallos y congestión de la red y distribución de la carga. Sus tareas se dividen en tres funciones: Señalización de gestión de tráfico. Señalización de gestión de enlaces. Señalización de gestión de rutas. Signaling Connection Control Part (SCCP) SCCP ( Signaling Connection Control Part): contiene funciones de transporte de alto nivel necesarias para soportar partes de aplicación de alto nivel. Proporciona funciones de encaminamiento, servicios orientados a conexión y no orientados a conexión. También se ocupa de la gestión de bases de datos duplicadas. Integrated Services Digital Network - User Part (ISDN-UP) ISDN-UP: proporciona control de llamada para ISDN (RDSI) y mensajes de señalización entre centrales.
Transaction Capabilities Application Part (TCAP) TCAP (Transaction Capabilities Application Part): soporta la transferencia de información que no está asociada con el circuito de control, por ejemplo la petición/respuesta de la base de datos tipo 800. Operations Maintenance Administration Part (OMAP) El protocolo OMAP (Operations Maintenance Administration Part) se ocupa de las siguientes funcionalidades de red: prestaciones, monitorización, encaminamiento y verificaciones.
2.2 Redes inteligentes En este apartado se describen las ideas fundamentales de lo que constituye la integración de los servicios de valor añadido en las redes de telecomunicaciones. El tipo de sistema resultante se denomina red inteligente [FAY1, BLA1].
2.2.1 Contexto y objetivos Las redes inteligentes surgen como una aplicación de las funcionalidades del sistema de señalización nº 7. Esta infraestructura de señalización común es la que permitirá más adelante el rápido desarrollo, desde un punto de vista técnico, de los servicios de la red inteligente. Esta red inteligente que va evolucionando hacia una red inteligente avanzada (Advanced Intelligent Network, AIN) tiene que verse también en el contexto de la red de gestión de las telecomunicaciones (Telecommunications Management Network, TMN) y al mismo tiempo con los avances que se están produciendo hacia la especificación de lo que es TI NA. Los objetivos de este apartado consisten en especificar e introducir los conceptos básicos de las redes inteligentes mostrando la evolución que han seguido los servicios a partir de la integración de ordenadores en los elementos de red del sistema. Se trata también de establecer una relación entre los conceptos de señalización, gestión de red y red inteligente.
2.2.2 Introducción a las redes inteligentes La red inteligente es i nteligente porque es programable, es decir, la i ntroducción de ordenadores y, por tanto, de software en los nodos de la red permite configurar mediante programación el comportamiento, los servicios y, por tanto, la inteligencia del sistema. El motivo básico del desarrollo de esta red es el de obtener mayores beneficios para el operador dado que aumenta el tráfico telefónico y también los ingresos debido a las suscripciones de los usuarios a los nuevos servicios. Otro nuevo factor de beneficio se deriva del hecho que una red con ordenadores integrados permite obtener una inteligencia de red y gestionar mejor los recursos del sistema con el fin de optimizar el rendimiento y reducir costes en el servicio.
Por otra parte, la red inteligente está diseñada para permitir una creación y/o modificación de los servicios de forma sencilla y rápida con el fin de adaptarse fácilmente a las continuas y cambiantes demandas de los clientes. Por último, el surgimiento de nuevos servicios e infraestructuras de tipo inteligente obedece, en general, a la continua evolución tecnológica de los siste mas de comunicaciones. Los tipos de servicios diseñados para la red de comunicaciones pueden ser servicios de red que comportan un flujo de señalización para mejorar la transferencia de la información, o bien servicios de valor añadido que comportan un flujo de datos para mejorar el proceso de información. Son únicamente estos últimos, los servicios de valor añadido, los que se consideran específicos de las redes inteligentes. La ITU-T ha especificado una serie de servicios inteligentes conocidos como CS1 (Capability Services 1), más recientemente ha aparecido un nuevo conjunto denominado CS2 y se está trabajando en la especificación de un CS3. Dentro de los tipos de servicios CS1, en los que se basan la gran mayoría de infraestructuras de operadores de servicio actuales, pueden citarse los siguientes: servicios de tarificación en llamadas (números 900,...), servicios de encaminamiento, numeración, captura/entrega de información u otros servicios de valor añadido. Finalmente, entre los servicios especificados en CS2 destacan los servicios de interconexión con otras redes, multiconferencia, movilidad personal, movilidad de terminal y servicios multimedia, así como la creación y gestión de estos servicios (CS2/CS3).
2.2.3 Evolución de la red inteligente Desde un principio, la red inteligente partió de los sistemas de comunicaciones basados en un control por programa almacenado (Stored Program Control, SPC). Es decir, el primer paso se constituyó con la incorporación en las primeras centrales de un control basado en una unidad de proceso (ordenador). Posteriormente se introdujeron en las centrales mecanismos de conmutación digital y los sistemas de transmisión digital. Llegados a este punto, todo estaba preparado para la implementación de una red de señalización por canal común. Esta red de señalización, basada en el protocolo nº 7, permitió que las centrales de comunicaciones pudieran transferir la información de control de forma más adecuada y, por tanto, se entendieran mejor entre ellas para poder pasar a introducir una inteligencia en la red. La introducción de los servicios según la demanda de los clientes dió lugar finalmente a la red inteligente actual.
2.2.4 Componentes de la red inteligente avanzada (Advanced Intelligent Network, AIN) La red CCS (Common Channel Signaling) consta de nodos llamados puntos de señalización (SPs) interconectados por enlaces de señalización. La arquitectura AIN incluye nuevos sistemas de red físicos y sistemas operativos, así como nuevo software para los sistemas de red y sistemas de operación existentes. La AIN integrada en la red básica permite operar a ordenadores inteligentes, llamados nodos, localizados en la red CCS. La red inteligente incluye en su forma básica los siguientes nodos: Service Switching Point (SSP). Punto de conmutación de servicio Signal Transfer Point (STP). Punto de transferencia de señal
Service Control Point (SCP). Punto de control de servicio Service Management System (SMS). Sistema de gestión de servicios Signaling Links (SLs). Enlaces de señalización
Además, la red inteligente suele dotarse ta mbién de los siguientes elementos: Intelligent peripheral (IP). Periférico inteligente Service Data Point (SDP). Punto de datos del servicio Service Creation Environment (SCE). Entorno de creación de servicios Adjunct (AD). Adjunto Services Node (SN). Nodo de servicios
En la figura 2.1 se muestra el entorno de red descrito. La arquitectura de protocolos de comunicaciones de la red inteligente está formada en torno al SS7 y se denomina INAP (Intelligent Network Application Protocol, INAP). A continuación, se describen con mayor detalle los nodos que constituyen la red. SMS: realiza funciones de mantenimiento, administrativas y de provisión para los SCPs. También realiza la función de creación de servicios. SCP: simbolizados por triangulos, para mostrar sus capacidades para realizar decisiones. Los AIN SCPs contienen programas lógicos de servicios que reflejan los servicios de clientes y que interactúan con SSP para gestionar decisiones en el procesado de llamadas. STP: como STP, proporcionan servicio de encaminamiento en la red de forma ininterrumpida. SSP: dispone de software especial para proporcionar servicios AIN. IP (Intelligent Peripherals): añaden funciones de comprensión a la red tales como reconocimiento de voz, síntesis y anuncios de voz específicos. Adjuntos: nodos AIN que se conectan a los SSPs y que realizan las mismas f unciones que SCPs. NAP (Network Access Point): son conmutadores que proporcionan una funcionalidad de servicios limitada a determinados clientes. Los NAP no acceden a las AIN SCPs pero proporcionan servicios AIN a través de conexiones a AIN SSPs. El SSP tiene un software especial que permite proporcionar servicios AIN. El SSP cuando es alertado por mecanismos de disparo de peticiones de servicio AIN, suspende la función de procesado de la llamada. Envía un mensaje de consulta a través de la red CCS al SCP para pedir instrucciones por el procesado de la llamada.
2.2.5 Arquitectura funcional de la red inteligente La arquitectura funcional de la red inteligente se caracteriza por un modelo conceptual, es decir una abstracción que facilita la definición de interfaces abiertos y normalizados para posibilitar la creación de servicios avanzados y abiertos en un entorno multifabricante.
El modelo conceptual define las estructuras lógicas y funcionales, así como las características de los servicios básicos. Se puede estructurar en los cuatro planos siguientes: plano de servicio (perspectiva del usuario), plano funcional global (perspectiva del diseñador del servicio), plano funcional distribuido (relacionado con la arquitectura de la red) y plano físico (relacionado con la arquitectura de la red). El plano de servicio presenta una descripción del servicio desde el punto de vista del usuario. Se trata de una visión orientada al servicio en la que no hay información sobre la realización de los servicios en la red. En el plano funcional global se da una visión de las distintas funcionalidades de una red inteligente, que se considera una entidad única que contiene el modelo de proceso de llamadas y los bloques constructivos independientes del servicio (SIBs). En el plano funcional distribuido se especifica la distribución de las funciones de una red inteligente mediante entes funcionales (FEs) y acciones de entes funcionales (FEAs). Finalmente, en el plano físico se indica la forma de implementar la red inteligente. Se identifican los distintos tipos de entes físicos (PEs), las FEs que realizan y los protocolos que emplean para comunicarse. A continuación se presentan las entidades funcionales definidas en la primera fase de especificación de servicios (CS1): CCF: función de control de llamadas (tareas clásicas: señalización, reserva de circuitos,...). CCAF: función de agente de control de llamadas (intermediario entre usuarios y procesos de llamadas analógicas, RDSI,...). SSF: función de conmutación del servicio (intercepta llamadas de IN) . SCF: función de control de servicio (lógica de control de los servicios de IN). SRF: funciones de recursos especializados (interacciones con usuario: DTMF/voz, anuncios,...). SDF: función de datos del servicio (acceso a datos de servicio y red). SMF: función de gestión del servicio. SCEF: función de entorno de creación de servicios. SMAF: función agente de gestión de servicios. SMAF SMF SCEF
SDF
SCF
SSF
CCF
Fig. 2.6 Estructura de entidades funcionales correspondiente a la red inteligente
Se puede establecer una correspondencia entre entidades funcionales y entidades a nivel físico (FEsPEs) para cada nodo de la arquitectura. De esta forma, un SSP dispone de las funciones SSF/CCF y opcionalmente puede incluir SCF, SRF o SDF. Un SCP dispone de SCF y opcionalmente puede incluir SDF. Un nodo IP dispone de SRF. Un Adjunto dispone de SCF y SDF. Finalmente, un nodo de servicio dispone de SSF/CCF, SCF y SDF y opcionalmente puede incluir una SRF.
2.2.6 Dimensionado de un SCP En este apartado se presenta un posible diseño para dimensionar un nodo SCP. El nodo se descompone en una serie de entidades funcionales [ATS1]. A continuación se describe la notación básica que se ha empleado: DMF: Data Managing Function CHF: Communication Handling Function SHF: Service Handling Function SSP: Service Switching Point SH: Service Handler CH: Communications Handler DM: Data Manager
SHF
DMF
CHF
SMS
SCP SSP
Fig. 2.7 Esquema de funcionalidades del nodo SCP
Sea la DMF la función de procesado de la llamada, la CHF la función que realiza de interfaz de comunicaciones con el módulo SSP y la SHF el programa del servicio lógico que ejecuta el SLP. Sean: M SH : número de SH’s. M CH : número de CH’s M DM : número de DM’s t SH : tiempo de procesado en SH permitido para una única llamada (s). t CH : tiempo de procesado en CH permitido para una única llamada (s). t DM : tiempo de procesado en DM permitido para una única llamada (s).
p: prestaciones de un único SH (MIPS). c: prestaciones de un único CH (MIPS). q: prestaciones de un único DM (MIPS). P: cantidad de procesado en SH para una única llamada (pasos/lla mada). C: cantidad de procesado en CH para una única lla mada (bits/llamada). Q: cantidad de procesado en DM para una única llamada ( pasos/llamada). V: condición de tráfico: número máximo de ll amadas procesadas simultáneamente. El coste K para un único servicio y para un único SCP es: K = K SH M SH + K CH M CH + K DM M DM
=
(*)
PV CV QV 1 + K DM = K SH + 1 + + K CH qt DM + 1 ct CH pt SH Con: K SH : coste para un único SH. K CH : coste para un único CH. K DM : coste para un único DM. t SH
≥ 0, t CH ≥ 0, t DM ≥ 0
t SH + t CH + t DM
≤ T
Para simplificar, se adoptan los parámetros M co mo enteros, de la forma:
*
K
PV + K CH CV + K DM QV = K SH pt SH ct CH qt DM t SH + t CH + t DM
si
*
K
= T
PV QV + K CH CV + K DM = K SH ( ) − − pt ct q T t t CH SH SH CH
Para obtener una solución de coste mínimo se igualan la s derivadas parciales de cada variable a cero:
obtenemos M SH , M CH y M DM y sustituimos en (*), con *
K
≈ K
Ejemplo Sean las siguientes relaciones:
P C Q : : p c q
= 1:1 :1
Fracciones de tiempo procesando en cada módulo: (t SH , t CH , t DM ) = (0.068,0.096,0.136) M SH : M CH : M DM
= 14.7 : 10.4 : 7.3
K SH : K CH : K DM * K donde
= 1: 2 : 4
(t SH + t CH + t DM ) = 0.3
Una llamada se procesa por un único módulo para cada tipo de función. La proporción de tiempo invertido para procesar en cada módulo viene dada por: P C Q : : p c q
Por otra parte, se desprecia el retardo en las conexiones entre módulos.
2.2.7 Modelo de llamada básico de la red inteligente Para proporcionar los servicios de red inteligente, algunas funciones de procesado de la llamada se desplazan desde el conmutador y se convierten en programas lógicos de servicio residentes en el SCP. Estos programas lógicos de servicio interactúan con información enviada desde el SSP para proporcionar direcciones de control de llamada. ¿Cómo el SSP determina qué tipo de información del cliente se envía al SCP? Se dirige funcionalmente por el modelo de llamada básico de la red inteligente. Este modelo de llamada básico define puntos en llamada (PIC) como posiciones que proporcionan cinco áreas de disparo lógico, denominadas puntos de detección de disparo (TDPs), donde la información almacenada se transfiere al SCP.
Un trigger es la traslación de un software que puede emplazarse en contra de las líneas de un cliente o un código de dial seleccionado dentro del plan de dialing de oficina. Cada punto de detección de disparo puede proporcionar multiples disparos. La información recogida en un punto de detección de disparo es lo que define un tipo de servicio AIN. Un ejemplo de tipo de servicio es el número de llamante recogido en el punto de detección de disparo del intento originante y que podría usarse para proporcionar un servicio de dialing activado por voz. Tal como se ve en el modelo, no todos los puntos en la llamada tienen puntos de detección de disparo, y por eso no pueden disparar la tr ansmisión de información recogida en el punto de control de servicio (SCP). Los puntos en llamada representan una secuencia de acciones de procesamiento de llamada basadas en el conmutador. Para proporcionar servicios AIN, los disparos en el SSP deben interactuar con los programas lógicos de servicio del SCP. Los programas lógicos de servicio proporcionan la lógica que determina los servicios disponibles al cliente. El mensaje desde el SSP contiene información que permite al SCP el registro del grupo cliente que contiene el pr ograma lógico de servicio.
2.3 TINA (Telecommunications Information Networking Architecture). El consorcio TINA (TINA-C) comprende la mayor parte de los grandes operadores de red y fabricantes de ordenadores, y fue fundado en 1992 [INO1]. El principal logro de la arquitectura TINA es proporcionar una arquitectura de servicios de redes de servicios de telecomunicaciones. Especifica una plataforma distribuida orientada a objetos, basada en el estándar OMG CORBA, y una arquitectura de aplicación de telecomunicaciones. Proporciona una arquitectura de red de información de telecomunicaciones para que pueda ser utilizada por todo tipo de red (RTC, RDSI, B-RDSI, etc.) para aplicaciones de telecomunicaciones. TINA define a los servicios de telecomunicaciones y a los sistemas de gestión como aplicaciones basadas en software que operan en una plataforma de computación distribuida CORBA. Para ello, se intenta obtener un entorno de desarrollo de aplicaciones de red, gestión y operaciones que sean de fácil utilización y mantenimiento. El trabajo de TINA-C ha sido fuertemente influenciado por las especificaciones de INA definidas por Bellcore. Si bien las especificaciones de TINA fueron confidenciales hasta 1995, actualmente se pueden consultar en el web: http://www.tinac.com/.
TINA surgió como solución a los nuevos servicios de telecomunicaciones que requieren un acceso y una gestión más flexibles de lo que las redes actuales pueden proporcionar. La arquitectura se basa en computación distribuida, orientada a objetos, y en otros conceptos y estándares de las industrias de telecomunicaciones y ordenadores, como ODP, IN, TMN, ATM, CORBA. La arquitectura TINA se estructura en cuatro grandes áreas: arquitectura de computación, arquitectura de servicio, arquitectura de red y arquitectura de gestión. - Arquitectura de computación: esta arquitectura define un conjunto de conceptos y principios para el diseño y construcción de software distribuido y el entorno de soporte de software, basado en principios orientados a objetos. Esta arquitectura está basada en el modelo de referencia para procesado distribuido abierto (RM-ODP). - Arquitectura de servicio: define un conjunto de conceptos y principios para el diseño, especificación, implementación y gestión de servicios de telecomunicaciones. Pueden identificarse tres conceptos fundamentales: conceptos de sesión, relacionados con actividades de servicios y relaciones temporales, conceptos de acceso, relacionados con asociaciones de terminal y usuario con redes y servicios, y conceptos de gestión, relacionados con temas de gestión de servicios. - Arquitectura de red: define un conjunto de principios y principios para el diseño, especificación, implementación y gestión de redes de transporte. Aspectos básicos de esta arquitectura es el modelo de información de recursos de red genéricos, la definición de los grafos de conexiones que proporcionan una visión de conectividad orientada al servicio, y la gestión de conexiones. - Arquitectura de gestión: define un conjunto de conceptos y principios para el diseño, especificación e implementación de sistemas de software que se usan para gestionar servicios, recursos, software, así como otras tecnologías subyacentes.
2.3.1 Arquitectura de computación TINA La arquitectura de computación define los conceptos de modelado que deberían de usarse para especificar el software orientado a objetos en sistemas TINA. Además define un entorno de proceso distribuido (DPE) que proporciona un sistema de soporte que permite a los objetos localizar e interactuar entre ellos. Estos conceptos se basan en el Reference Model for Open Distributed Processing (RM-ODP). El modelado computacional utiliza los objetos computacionales como las unidades de programación y encapsulación. Los objetos interactúan entre ellos mediante el envío y la recepción de información a/desde interfaces. Un objeto puede proporcionar muchas interfaces, del mismo o diferente tipo. Existen dos tipos de interfaces: operational interface y stream interface (fig. 2.9). - Una interfaz operacional define operaciones que permiten que funciones de un objeto que ofrece (servidor) sean invocadas por otros objetos (clientes). Una operación puede tener argumentos de entrada y devolver resultados. - Una interfaz de flujo no tiene operaciones, es decir, no hay parámetros de entrada/salida, peticiones, resultados o notificaciones. El establecimiento de un flujo entre este tipo de interfaces permite el paso de otras informaciones estructuradas, tales como flujos de bits de vídeo o voz. Estos flujos se establecen mediante la interacción con componentes de red y servicio.
Las interfaces se especifican independientemente de cualquier lenguaje de programación mediante una notación específica. Esta notación se denomina TINA Object Definition Language (TINA ODL), y es una extensión del Object Management Group´s Interface Definition Language (OMG IDL). El lenguaje consiste en un conjunto de plantillas que permiten la especificación de las entidades de computación TINA básicas: bloques de construcción, objetos e interfaces. Los conceptos de modelado de la información permiten ver el estado, las relaciones y el comportamiento de las entidades de información en el dominio del problema bajo estudio (notación casi GDMO-GDR). Los conceptos de modelado de ingeniería definen la máquina TINA-C abstracta que se basa en un entorno de procesado distribuido (DPE, Distributed Processing Environment).
2.3.2 Arquitectura de servicio TINA
Proporciona medios para construir servicios y un entorno de soporte al servicio (servicios de telecomunicaciones, de gestión o de usuario final). Desde el punto de vista de computación describe cómo debería estar estructurado un servicio distribuido para proporcionar sus funciones al usuario. Para ello, identifica componentes software en tiempo de ejecución (run-time) tales como: agentes de usuario, agentes terminal, sesión de servicio, gestor de suscripciones o gestor de sesión de comunicaciones. La capa de servicio TINA pasa sus requerimientos de gestión en forma de Management Contexts (MgmtCtxt), que se transportan por una construcción denominada transacción de servicio. Si bien la capa de recursos TINA se construye siguiendo una estructura DPE, es plenamente interoperable con TMN. Por otra parte, TINA se orienta a sesión por lo que se obtiene un nuevo conjuntos de funciones de gestión representadas por MgmtCtxts en cada sesión de servicio. Las fases de transacción de un servicio son tres: Fase de set-up: se interpretan los MgmtCtxts y se reservan los recursos necesarios. Fase de ejecución: una vez se ha autorizado el acceso, se ejecuta la sesión de servicio TINA. Fase de wrap-up: se informa de la gestión (QoS) si es necesario.
Sesión de
usuario
Sesión de acceso
Sesión de servicio
Sesión de usuario
Sesión de comunicación
Sesión de acceso
Fig. 2.8 Concepto de sesión en TINA
Gestión de red
32
Con TINA se reemplaza el concepto de llamada por el de sesión, entendiendo este último como el propósito de un servicio de realizar un conjunto de actividades durante un periodo específico de tiempo. Se definen cuatro tipos específicos de sesiones desde el punto de vista de la información que tratan: sesión de servicio, sesión de comunicación, sesión de usuario y sesión de comunicación. En la figura 2.8 se relacionan gráficamente estos tipos de sesión. Las sesiones de comunicaciones y sesiones de acceso son independientes del servicio, mientras que las sesiones de servicio y sesiones de usuario son dependientes del servicio. El propósito de estos conceptos de sesión es separar los diferentes ámbitos y promocionar la distribución de funcionalidad.
2.3.3 Arquitectura de red TINA La arquitectura de red intenta proporcionar un conjunto de conceptos genéricos que describen redes de transporte de una forma independiente a la tecnología (Network Resource Information Model, NRIM). El NRIM define un modelo de recursos de red que proporciona las abstracciones necesarias al software de servicio. El software de servicio usa NRIM cuando se necesitan establecer las conexiones de red y cuando el servicio es responsable de la gestión de un conjunto de recursos de la red (subredes, elementos de red, pistas, conexiones, etc). Se pueden considerar los siguientes niveles de gestión: Nivel de elementos de red: aspectos referidos a la información requerida para gestionar recursos de equipos específicos proporcionada por las funciones de la capa de elementos de r ed. Nivel de gestión de recursos: información para la representación de la red, tanto lógica como físicamente. Nivel de gestión de servicios: gestión de software de los servicios, configuración de los servicios, y utilización de recursos para proporcionar el servicio.
El concepto de grafo de conexión se utiliza para proporcionar una visión de conectividad orientada al servicio. Un grafo de conexiones presenta vértices y puertos, con puertos conectados por líneas para representar conectividad. Hay dos tipos de grafos de conexiones: grafos de conexión lógica donde los vértices representan objetos, los puertos representan interfaces de flujos y las líneas flujos. En cambio, en el grafo de conexiones físicas, los vértices representan nodos físicos, los puertos, puntos de acceso a red y las líneas, conexiones.
2.3.4 Arquitectura de gestión TINA La arquitectura de gestión define un conjunto de principios de gestión de entidades en un sistema TINA. Está basada principalmente en la gestión OSI y en estándares TMN. Las áreas funcionales de gestión son las ya clásicas cinco definidas por la TMN en la ITU: fallos, rendimiento, seguridad, configuración y tarificación. En TINA además, se subdivide la gestión de configuración en gestión de conexiones y en gestión de (configuración de) recursos. A menudo se utiliza otro tipo de clasificación y también se pueden definir los siguientes planos: Gestión de computación: relacionada con la gestión de los ordenadores, las plataformas, y el software que se ejecuta en esa plataforma. No concierne a lo que las aplicaciones hacen ni a su gestión específica. Su principal interés es el e mpleo, la instalación, y la carga de software. Gestión de las telecomunicaciones: se refiere a los servicios de telecomunicaciones, el software de control y la gestión de redes de transmisión y conmutación.
Estos dos tipos de gestión se dividen en subtipos de gestión. La gestión de telecomunicaciones se divide, al igual que en TMN, en gestión de servicio, red y elemento. Por su parte, la gestión computacional se puede dividir en distintas áreas de interés. Notación de interfaz operacional COa
CO Interfaz
Cliente
Servidor
Notación de interfaz de flu o COc
COd Fuente
Productor
Sumidero Consumidor
Fig. 2.9 Tipos de interfaz de objeto computacional
Los principales objetos computacionales de la arquitectura de servicio relacionada con una sesión de acceso son los siguientes (Fig. 2.10). El UAP (User Application) representa una variedad de aplicaciones de servicio en un sistema de usuario. GSEP (Generic Session End Point) es un objeto computacional independiente del servicio que modela el mínimo conjunto de capacidades como un extremo final de una sesión de acceso por medio de la interacción con el agente de usuario para realizar el control de la sesión de servicio. El UA (User Agent) representa a un usuario en el dominio del proveedor de servicios. El PPrf (Personal Profile) mantiene las restricciones y preferencias relacionadas con el usuario en acceso al servicio y ejecución de sesión. El Ucxt (User Context) mantiene el conjunto de recursos disponibles al usuario para la ejecución de servicios. TE-A es el equipo terminal A. El SSM (Service Session Manager) soporta las capacidades de servicio que se comparten entre los usuarios en una sesión de servicio manteniendo el seguimiento y control de los recursos. El USM (User (Service) Session Manager) comprende el control de servicio y de sesión de las sesiones de usuario (servicio). El SubAgt (Subscription Agent) es un punto de contacto para acceder a la información de suscripción para agentes de usuario. Finalmente, el SF (Service Factory) controla el ciclo de vida de los objetos de la sesión de servicio de acuerdo a las peticiones realizadas desde agentes de usuario. UAP
Sesión de acceso
SF
UA UCxt
SSM
USM
GSEP
PPrf
SubAgt
TE-A
Fig. 2.10 Objetos computacionales relacionados con una sesión de acceso
2.3.5 Evolución de la red inteligente hacia TINA Existen dos posibles vías para implementar TINA en las redes inteligentes. En un primer caso (Open Switch Path), la solución se basa en una amplia distribución de funciones inteligentes sobre una red de servidores y terminales, y un gestor-agente dedicado a controlar las funciones de conmutación. La red inteligente avanza desde SCPs muy poco centralizados a una web de servidores de red que soportan perfectamente la interacción CPE-CPN (Customer Premises Network) y los equipos de provisión de servicios. Los servidores de red están diseñados para soportar funciones o servicios específicos. La interacción entre componentes software está soportada por plataformas basadas en CORBA gracias al IDL (Interface Definition Language). El uso de interfaces públicas permite definir una señalización abierta de servicios específicos. La capacidad de cargar código desde los servidores de la red a las CPEs aumenta la flexibilidad de este enfoque. La segunda opción (Bridge to Legacy Path) sigue la línea de la actual implementación de la red inteligente, y tiene influencia en los sistemas SCP y SMS. La mayor parte de la inteligencia se despliega en una red de servidores que proporcionan funciones avanzadas. El control sobre las funciones avanzadas se ejerce por el protocolo actual INAP o sus futuras versiones. La inteligencia de red avanza desde SCPs centralizados a una web de servidores de red diseñados para proveer funciones específicas. Las interacciones con los CPEs no se soportan directamente, están mediadas por equipos de red (SSPs en el plano de control y IP/SN en el plano del usuario). La interacción entre los elementos de software dentro de la capa inteligente se soporta por plataformas CORBA, las funciones de gestión están integradas con las de control gracias al uso de estas plataformas. Es necesario dar un nuevo paso con el fin de superar la segunda generación de RI e influenciar en los servicios ofrecidos en la era de la multimedia. La inteligencia se soporta por una infraestructura de computación, pues las aplicaciones, de acuerdo con la arquitectura TINA, funcionan sobre los nodos de computación. Cada nodo de computación está agrupado en un entorno de procesado distribuido (DPE). La comunicación entre los nodos de conmutación está soportada por conexiones ATM. Los servidores son especializados en función de las funciones que proveen a la infraestructura o bien a los usuarios finales. Las aplicaciones de red proveen funciones de servicio (por ejemplo la gestión y el control de la información proporcionada), funciones de recursos (usadas para ejercer el control y la gestión en el nivel de red), y funciones de elementos (que proveen un control específico sobre los elementos individuales de la red). Las aplicaciones de tipo gateway soportan la interoperabilidad con los sistemas antiguos, por ejemplo pasarela CORBA a SS7. Los equipos de red pueden ser introducidos fácilmente en la infraestructura si vienen provistos de APIs de control y gestión con interfaces públicas, los equipos van desde servidores de información, hasta routers o conmutadores abiertos. Un entorno de construcción de aplicación potente como (Application Construction Environment, ACE), inspirado en el concepto de creación de servicio total, completa la infraestructura. Todos los componentes del servicio están ya diseñados, coordinados y creados. Los diseños de servicio especifican todas las relaciones y limitaciones e ntre el servicio lógico y el resto de funciones.
2.4 Creación de servicios En el pasado, los servicios al cliente eran controlados por la central local. Con la red inteligente, la inteligencia reside en otros elementos de la red, lo que significa que se necesitan nuevos métodos y procedimientos para crear y proveer servicios.
La red inteligente proporciona un buen número de potenciales beneficios. Permite la introducción de nuevos servicios menos larga temporalmente que los métodos clásicos, reduce el coste de los nuevos servicios y permite a las compañías telefónicas ser menos dependientes del proveedor de los conmutadores. Con la nueva red inteligente, los nuevos servicios se pueden diseñar a partir de las ideas de clientes. El proceso de creación de servicios se ha diseñado e implementado para realizar esos beneficios. La creación de servicios incluye todas las actividades y herramientas necesarias para desarrollar un servicio nuevo o modificado. La creación de servicios se define como el conjunto de actividades que deben realizarse para crear un nuevo servicio y las capacidades de las operaciones asociadas para soportarlo. Hay dos partes importantes en la creación de servici os: Proceso: las actividades para generar una nueva idea de servicio, evaluando el nuevo concepto de servicio, documentando, diseñando, probando y desarrollando una nueva lógica de servicio. Entorno: los aspectos físicos de la creación del servicio, incluida la estructura organizacional y los ordenadores.
Se pueden distinguir las siguientes fases en la creación del servicio: a) Idea del servicio b) Análisis de necesidades y descripción del servicio c) Especificación del servicio d) Desarrollo del servicio e) Verificación del servicio f) Despliegue del servicio g) Configuración h) Testeo y mantenimiento a) La creación de servicio empieza con una idea. Una idea de servicio puede originarse de muy diferentes fuentes. Las compañías telefónicas desarrollarán nuevos servicios en sus esfuerzos para mejorar los servicios existentes (NO-AIN). Otras fuentes de ideas de creación de servicios son: clientes, gentes de marketing quienes proporcionan nuevos conceptos de servicio a clientes, otros personales de compañías telefónicas quienes tienen acceso a nuevos conceptos de servicio, reguladores gubernamentales, proveedores de servicio mejorados, sesiones de brainstorming en casa. b) Siempre que se origina una nueva idea de servicio, se precisa un análisis de necesidades. Un comité de análisis de necesidades estudiaría todos los departamentos, incluyendo: operaciones, red, marketing, facturación, tarifas y departamento de temas de negocios corporativos. El comite evalúa un nuevo servicio basado en analisis económicos, análisis de mercado, análisis de red y las evaluaciones de las alternativas de servicio. c) Si la idea de servicio pasa el test de criterios de servicio, se convierte en una descripción escrita en donde se describe cómo el cliente quiere el servicio. La descripción del servicio es el paso para una especificación detallada del servicio.
d) En el paso de desarrollo de servicio es donde se crean los servicios realmente. Aquí, un creador de servicios usa la especificación de servicios junto con el conocimiento de la red para producir un programa lógico de servicio, que contiene las instrucciones reales para ejecutar el servicio. e) El programa lógico de servicio debe pasar un proceso de verificación, que consta de un sistema de test de la lógica de servicio. f) Después que el programa lógico de servicio se ha verificado, se descarga el programa en el host de lógica de servicio (SCP o adjunto). g) El programa lógico de servicio debe aprovisionarse con datos específicos del cliente (p.e. información de encaminamiento según la hora del día). El programa lógico de servicio es configurado según las especificaciones del abonado, bien sea mediante representantes del servicio de la compañia telefónica o posiblemente por el propio abonado. h) Muy importante: debe realizarse la comprobación de extremo a extremo del software, del nuevo servicio para garantizar un servicio de mantenimiento al cliente. Después de la configuración, los simuladores deben usarse para probar llamadas al nuevo servicio: si son aceptables, se activa el servicio. La activación del servicio debe coordinarse entre los administradores del SCP, el STP y el SSP. El mantenimiento se refiere a todas las actividades asociadas con el soporte corriente de un servicio desplegado. Cada paso individual del proceso produce su propia salida que contribuye a la creación de un nuevo o rediseñado servicio.
2.4.1 Entorno de creación de servicios El entorno de creación de servicios se refiere a los recursos usados para el soporte del proceso de creación de servicios, incluyendo estructura de la organizacion, computación y capacidades de comunicación. El entorno de creación de servicios consiste de cinco áreas: análisis, desarrollo, producción, red y integración/prueba. El entorno de análisis es el conjunto de herramientas y facilidades que soportan la generación, formalización y verificación de las especificaciones de datos y servicio del usuario, funcionales y niveles físicos. El entorno de desarrollo es el conjunto de herramientas y facilidades que soportan el diseño, la codificación y prueba de aplicaciones de servicio. El entorno de producción es el conjunto de herramientas y facilidades que soportan la conversión del software fuente en imágenes ejecutables específicas de la plataforma, y la configuración de componentes de software para redes específicas y plataformas de operación. El entorno de red es el conjunto de herramientas y facilidades que soportan: instalación de imágenes ejecutables en la cima de plataformas en lugares específicos; prueba en la instalación de imágenes ejecutables; aislamiento de problemas de software; introducción de corrección de programas temporales para emergencias fijas. El entorno de integración y revisión es el conjunto de herramientas y facilidades que soportan: introducción física de imágenes ejecutables en la cima de cada paltaforma; prueba y integración de imágenes ejecutables en cada plataforma; verificación de fiabilidad de la red en presencia de nuevos componentes de software.
3 Soluciones para la gestión de redes A lo largo de los años se han requerido diversas soluciones, generalmente de tipo propietario, para la gestión de las redes de comunicaciones. Actualmente, con el mayor número y heterogeneidad de elementos junto a la mayor importancia que han adquirido las redes de comunicaciones para la empresa, se exigen nuevos enfoques. 3.1 Evolución de las redes de telecomunicaciones
Las redes de telecomunicaciones dentro del ámbito informático han evolucionado a partir de la necesidad de compartir información y procesos con usuarios remotos. En una primera fase se desarrollaron los grandes ordenadores: éstos eran extremadamente engorrosos de utilizar y caros. Estos primeros ordenadores tenían un uso local y eran manejados por una única persona o interfaz. Posteriormente, los sistemas operativos pemitieron el acceso de múltiples usuarios que interactuaban en principio también en un modo local. La gestión de los equipos, cuando existía, era pues necesariamente local, y los mecanismos específicos de cada fabricante de ordenador.
Impresoras Bancos de memoria
Ordenador multiacceso
Operador
Terminales locales Fig. 3.1 Esquema de un sistema formado por un único ordenador multiacceso y con gestión local
Más adelante, el uso de redes de telecomunicaciones permitió el acceso remoto de equipos terminales a los grandes ordenadores. Las redes de tecnología conmutada y el uso de módems eran más baratos
de utilizar que el coste que comportaba la disposición de múltiples ordenadores. El único ordenador era de tipo multiacceso y se accedía a éste de modo local, o remotamente mediante el uso de módems y equipos terminales (inicialmente teletipos). La gestión de red seguía siendo básicamente de tipo centralizado y basada en métodos del fabricante del mismo ordenador. Si bien esa gestión ya no cubría todos los elementos que entraban en la red de comunicaciones. Terminales locales Terminales remotos RTC Ordenador multiacceso
Módem
Módem
Fig. 3.2 Esquema de un sistema formado por un único ordenador multiacceso y con conexión a terminales de acceso remoto mediante el uso de módems
A medida que creció el uso del ordenador y aumentó el número de conexiones de equipos terminales a éste, fue necesario reducir la cantidad de módems utilizados debido a sus elevados costes. La solución fue la introducción del multiplexor que permitía integrar múltiples conexiones de equipos terminales en una sola línea de comunicación con lo que aumentaba el rendimiento. De esta forma, no eran necesarios tantos módems y se reducía el coste de las telecomunicaciones. Ordenador multiacceso
MUX
MUX
Módem
Módem
Terminal remoto RTC Terminales locales
Fig. 3.3 Esquema de un sistema formado por un único ordenador con conexión de terminales de acceso remoto a través de multiplexores
A medida que el progreso tecnológico abarataba los costes de la introducción de ordenadores en la empresa, las redes pasaron de tener configuraciones centralizadas a configuraciones de tipo distribuido con múltiples ordenadores. De esta forma, si bien en un principio se seguían utilizando redes RTC con módems, eran los ordenadores multiacceso quienes se interconectaban de forma interna. La gestión de red empezó a pasar de modelos centralizados a plantearse de modo distribuido o jerárquicamente distribuido en función del rango de los ordenadores en la red.
Ordenador multiacceso
MUX MUX
Módem
Ordenador multiacceso
Módem
Terminales remotos
MUX
Terminales locales
RTC
Terminales locales
Módem
Fig. 3.4 Esquema de un sistema formado por un conjunto de ordenadores actuando de forma distribuida conectados a través de una RTC
Conforme la interacción mutua del sistema distribuido de ordenadores iba aumentando fue haciéndose más necesario el uso de líneas dedicadas que permitieran reducir el coste debido al tráfico de información por las redes. Las empresas alquilaban líneas a los operadores de redes y eso permitía ofrecer costes menores en comunicaciones. La gestión de red se plantea de forma distribuida. A raíz del crecimiento del tráfico telefónico en las redes de ordenadores se hace cada vez más necesario el empleo de líneas telefónicas privadas en las grandes corporaciones. A medida que la tecnología avance, se introduciran, además, líneas digitales que se adecuen mejor al tráfico generado por las comunicaciones entre ordenadores.
Fig. 3.5 Esquema de un sistema formado por un conjunto de ordenadores que actúan de forma distribuida, conectados vía líneas dedicadas
Ordenador Ordenador
Red de paquetes
Fig. 3.6 Esquema de un sistema formado por un conjunto de ordenadores que actúan de forma distribuida, conectados según una red digital o de paquetes
La entrada de las comunicaciones de tipo digital permitió optimizar la transferencia de información entre ordenadores. Nacieron redes como RDSI de conmutación de circuitos para terminales multimedia y otras redes basadas en conmutación de paquetes como la que utiliza la norma X.25.
Más adelante, con el empleo masivo de terminales tipo PC en las grandes corporaciones, se desarrollaron redes locales en conexión con redes de área extendida para poder cubrir las distancias correspondientes a campus o ciudades. Otros estándares como Frame Relay o ATM se han desarrollado para permitir esa interconexión de redes locales que pueden estar situadas de forma remota. En estos casos la proliferación de múltiples fabricantes distintos en el desarrollo de los terminales y dispositivos de interconexión de red hace complicada la gestión de este tipo de redes heterogéneas. Es por ello que a partir de esos momentos, resulta evidente la necesidad de diseñar mecanismos de estandarización para poder gestionar la creciente complejidad de los sistemas de redes.
LAN
WAN, B-RDSI Pasarela
Ordenador
Ordenador
Pasarela
LAN Pasarela
LAN
Fig. 3.7 Esquema de un sistema formado por un conjunto de redes locales interconectadas por una red de paquetes, una red de área extendida (WAN) o una red de tipo B-RDSI
De esta forma, surgieron diversos organismos de estandarización que trataron de solucionar el problema de la gestión en redes heterogéneas, como IETF que definió el protocolo SNMP o como ISO, que hizo lo propio con el protocolo CMIP. Se puede, pues, hablar de distintos tipos de gestión según las configuraciones de los escenarios, es decir, una gestión autónoma donde las redes tienen gestión local en cada nodo; una gestión homogénea con redes homogéneas con un único nodo de gestión centralizado; finalmente, una gestión heterogénea, con la ampliación de las redes con la interconexión de productos heterogéneos. Este sería el caso del siguiente ejemplo: una organización que interconecta sus sistemas de información con diferentes redes de comunicaciones. El caso de utilizar sistemas de gestión de red propietarios trae consigo las siguientes consecuencias: un plano de usuario (operador de red) con una multiplicidad de interfaces de usuario; un plano de aplicación (de gestión) con distintos programas de aplicación con funcionalidad similar; y, finalmente, un plano de información (de gestión): con una duplicidad y posible inconsistencia de la información almacenada en las bases de datos. Todo ello, dificulta el cumplimiento de que la gestión de red sea efectiva desde el punto de vista del coste.
Como solución se plantea una gestión integrada, en la que se normalizan las comunicaciones con la especificación de un protocolo entre elemento de red y centro de gestión, y la normalización de la información donde el centro de gestión debe poder conocer a los elementos de red mediante su nombre y sus propiedades visibles. Por tanto, debe haber también una definición sintácticamente uniforme de los elementos de red. Existen una serie de modelos de gestión normalizados, en los cuales es posible el acceso uniforme a los recursos gestionados. Se normaliza el protocolo de comunicaciones, el modelo de información de gestión y las definiciones de información de gestión. Los modelos de gestión de red tradicionales más importantes son la arquitectura TMN (ITU-T), el modelo de gestión OSI (ISO) con el protocolo CMIP y el modelo de gestión Internet (IETF), basado en el protocolo SNMP. Más recientemente, han adquirido importancia el modelo DMI (DMTF), la gestión por agentes inteligentes y la gestión por webs.
3.2 Modelos para la monitorización y el control de red
La gestión de red ha evolucionado desde la gestión basada en arquitecturas de red de tipo propietario hasta el uso, hoy ya masivo, de plataformas de gestión basadas principalmente en sistemas operativos UNIX o NT. Estas plataformas de gestión se implementan según una integración de aplicaciones compatibles y que permiten una gran flexibilidad de uso en la gestión de redes heterogéneas [GHE1]. Existen también los productos específicos para la gestión de redes de área local, tanto para segmentos independientes como específicos, para redes de PCs o para determinados elementos de red. Finalmente, existen también los integradores de sistemas de gestión. 3.2.1 Arquitecturas propietarias
Desde siempre los fabricantes líderes en sistemas de gestión han tratado de imponer estándares de Actualmente se trata de una tendencia que está cayendo en desuso. Las razones principales se basan en la cada vez menor cuota de mercado de estos fabricantes líderes y de la cada vez mayor complejidad de los entornos de red, formados por extensas interconexiones de redes y servicios que dificultan su control y gestión por parte de unos pocos fabricantes.
facto.
Entre las arquitecturas de red más importantes se encuentran: IBM, Xerox, Novell, Ungerman-Bass, 3 COM, Banyan, Proteon y AT&T. A continuación se describen algunas de ellas. IBM network management architecture:
Open network management (ONA) es el marco de trabajo para los sistemas de gestión IBM. Se definen tres grandes tipos de elementos que realizan funciones de gestión: - Puntos focales, que proporcionan control centralizado, p. e. Netview. - Puntos de entrada, que pueden ser dispositivos SNA en general. - Puntos de servicio, que proporcionan servicios de gestión SNA.
Dispositivo SNA Fig. 3.8 Esquema de la arquitectura de gestión de red IBM
Las plataformas de gestión que utilizan la arquitectura de red IBM pueden ser: Netview para la gestión de redes SNA, LAN Network Manager para la gestión de redes Token Ring y Netview/6000 para la gestión SNMP (Karat). Novell:
Novell utiliza un sistema operativo de red, basado en una evolución del Netware. Recientemente Novell ha introducido CMISE y CMIP en sus sistemas de gestión de red. Actualmente Novell está migrando su torre de protocolos IPX al estándar IP. Arquitectura de gestión de red AT&T:
La arquitectura del sistema de gestión múltiple de red, UNMA (Unified Network Management Architecture) de AT&T está basada en OSI. UNMA consiste de una arquitectura en tres capas ligadas. El nivel más bajo está formado por los elementos de la red, es decir, componentes físicos y lógicos que comprende la red que se quiere gestionar. El segundo nivel lo forman Element Management Systems (EMS), que administran y gestionan elementos de red. El tercer nivel consiste de sistemas de gestión integrados que unen conjuntamente los EMSs de los tres niveles. NE
NE Gestión de elementos
NE
NE
Gestión de elementos
Sistema de gestión integrado Interfaz de usuario unificado Fig. 3.9 Esquema de arquitectura de red de AT&T
Las plataformas de gestión utilizan una integración de aplicaciones para poder adaptarse al entorno cambiante y complejo de los elementos de red que se quieran gestionar. Entre las aplicaciones más usuales que se incorporan, destacan los MIB browser (navegadores u hojeadores de MIB) como interfaces de usuario del protocolo SNMP; el discover , que permite autodescubrir equipos y topologías de la red; la programación de sondeos de variables de la MIB; la programación de acciones ante alarmas; y, finalmente, los visualizadores gráficos de valores de variables de MIB. Dentro de la categoría de sistemas basados en UNIX podemos encontrar los siguientes: - Enterprise Management Architecture de Digital (PolyCenter) - OpenView Network Management server de HP - SunNet Manager de Sun Microsystems (Solstice) - Spectrum de Cabletron - DualManager de Netlabs (OverLord) - NMC 3000 de Network Managers - NetExpert de Objective Systems Integrators - NMS/Core de Teknekron Communications Systems - Network Knowledge Systems de Applied Computing Devices - IBM Netview/6000 para AIX - TME 10 de Tivoli. Las plataformas de gestión posibilitan mayor grado de integración multifabricante que el esquema gestor de gestores. Las interacciones con otros sistemas de gestión de diferentes fabricantes se realizan a través de un interfaz de programación de aplicaciones estándares (API) y un conjunto estándar de definiciones de datos de gestión. 3.2.3 Clases de productos de gestión
Se pueden distinguir las siguientes clases de productos de gestión para LANs: - Productos standalone, dirigidos especialmente a monitorización, análisis de test, seguridad y necesidades de tarificación. - Plataformas de gestión de red que proporcionan un entorno en el cual las aplicaciones pueden ser desarrolladas, mejoradas e intercambiadas. - Herramientas de gestión de LANs de PCs, que incluyen soluciones de propósito especial como una combinación de funciones de sistemas operativos en LANs y añadidos especiales. - Sistemas de gestión de elementos LAN basados en estándares abiertos o de facto que ofrecen una aceptable funcionalidad a elementos LAN, tales como segmentos LAN, hubs cableados, dispositivos de interconexión LAN, FDDI, PBXs y conexión a integradores de gestores de red. - Integradores que probablemente soportan elementos de gestión de sistemas LAN, MAN, y WAN en la misma plataforma. 3.2.4 Productos de gestión de LANs standalone
Los productos standalone sirven áreas funcionales especiales sin intención de aplicabilidad a la integración de gestión de LANs. Esto es, instrumentos de test de LANs, analizadores de LAN, sistemas de monitorización de LAN, u otros instrumentos especiales.
Los productos standalone suelen evaluarse de acuerdo a los siguientes criterios: - interfaz de usuario - protocolos que son soportados - nivel de decodificación - el tipo de LANs/WANs soportadas - buffers de captura - filtros - soporte para monitorización distribuida - niveles de disparo - búsquedas - etiquetas temporales - generadores de tráfico - chequeo de cables - convención en el nombrado - diagnóstico por sí mismo - impresión por hard-copy - protección de passwords Entre los instrumentos más importantes para tests de LANs se incluyen: óhmetros, testers, conectores coaxiales, conectores en T, terminadores, osciloscopios y reflectores en el dominio temporal. Los analizadores de LANs tienen como fin el soporte de gestión de prestaciones y de fallos. En general ofrecen indicaciones sobre: - Servicio: retardos, tiempo de transferencias, tiempo de diálogo. - Uso: uso global del ancho de banda, uso específico por aplicaciones y/o usuarios. - Perfiles de usuario: qué aplicaciones y qué actividades. - Perfiles de servidores: uso interno, colas,... Los sistemas analizadores de LANs, suelen permitir la monitorización de precisión y disponer de herramienta de diagnóstico para gestores de red. Analizan tanto redes Ethernet como Token Ring (entre otros protocolos). Verifican tráfico en tiempo real, conectividad y problemas asociados, actividades de ficheros en tiempo real, conectividad con bridges y retardos asociados, test de hardware para servidores y simulación de cargas. Los sistemas de monitorización de LANs forman una familia de herramientas que soportan monitorización continua, ofreciendo una unidad de colección de datos en cada segmento LAN. Las funciones que suele realizar el software son del tipo: número de canales de entrada, filtros, etiquetas temporales, estaciones de monitorización, buffers (colas), niveles de disparo, presentación, lista de alarmas, protocolos medidos, encabezamientos, estadísticas y informes de errores, interfaz a bases de datos u otros y soporte SNMP. Entre los productos más representativos, se suele citar el Sniffer (llamado Watchdog) de Network General. Existen equipos más recientes como el Network Advisor de HP o el Trakker de Concord Communications. Existen también instrumentos especiales de LANs. Estos instrumentos especiales soportan áreas de gestión de LANs específicas. Por ejemplo, la tarificación utiliza en particular dos tipos de productos: medidores de software y herramientas de gestión de pruebas de auditabilidad, así como herramientas de documentación.
Los sistemas de gestión de LANs de PCs están orientados a supervisión de eestatus, determinación de fallos y muy básicas capacidades de administración. Actualmente las últimas versiones de Windows NT (Microsoft) está aportando interesantes novedades para la administración y monitorización de las redes locales de PCs. Además, y aparte de IBM, han dominado el mercado otras compañías como Novell, 3Com y Banyan. Otros productos interesantes en el área de LANs de PC son StarLAN de AT&T y LocalTalk de Apple. Como resultado de la tremenda presión de los usuarios hacia aplicaciones multiprotocolo, interoperabilidad, etc. las compañías líderes han reaccionado hacia: - Abrir gateways a TCP/IP. - Acuerdos de cooperación (p.e. IBM y Novell, IBM y 3Com, Banyan y Novell). - Soporte de SNMP sobre un redes locales. - Soporte de CMOT sobre redes con muchos nodos. - Adquisición de productos de monitorización para proporcionar a los usuarios con monitorización mejorada y gestión. Actualmente son las plataformas abiertas de gestión de red las que constituyen la base común para que a través de APIs (interfaces de programación de aplicaciones) las aplicaciones de gestión puedan realizar la recogida de datos de los elementos de red. Estas aplicaciones son accesibles normalmente por medio de lenguaje C y permiten que una aplicación pueda invocar una función de otra. DMI (Desktop Management Interface) fue el primer API de gestión de PCs independiente de protocolos y sistemas operativos (abril 1994). Es uno de los principales componentes de la solución de gestión de DMTF (Desktop Management Task Force), consorcio industrial que persigue proveer una plataforma PC susceptible de ser gestionada en modo flexible. Los ficheros MIF (Management Information Format) provistos con cada producto gestionable definen, por su parte, los atributos gestionables del estándar en categorias tales como sistemas PC, servidores, impresoras, adaptadores LAN, módems y aplicaciones software. La arquitectura DMI incluye el nivel de servicio, un programa local que recoge información de los productos, gestiona esa información en bases de datos MIF, y la pasa a las aplicaciones de gestión cuando es solicitada. Controla, además, su comunicación con las aplicaciones de gestión de MI (Management Interface) y con los productos gestionables a traves de CI (Component Interface). SMS (Systems Management Server) de Microsoft es otra plataforma diseñada para soportar tareas de gestión de sistemas, tales como inventarios hardware y software LAN y distribución electrónica de software, en entornos LAN Manager y Windows NT Advanced Server (NTAS) de Microsoft, Netware de Novell, Pathworks de Digital y LAN Server de IBM. Sobre plataformas Window NTAS, SMS utiliza DMI. La estrategia de gestión LAN de Microsoft se centra fundamentalmente en el control de los sistemas conectados a la LAN, dejando la gestión de dispositivos de red, como routers y hubs, a soluciones de mayor nivel que incluyan estaciones basadas en SNMP. NMS (Netware Management System) de Novell es una familia de productos software que constituye una solución abierta para la gestión de LANs NetWare y dispositivos de internetworking como routers y hubs. NMS comprende tres productos software que corren sobre una consola central y agentes que residen en los dispositivos de la red. El software de gestión de NMS corre bajo PCs Windows y sus funciones clave son la exploración y mapeo de dispositivos de interconectividad, gestión de
direcciones de red, rastreo de condiciones de alarmas y su almacenamiento en una base de datos. Dispone de una herramienta de análisis experto para la solución de problemas y dispone de la capacidad de gestionar cualquier dispositivo SNMP. 3.2.6 Sistemas de gestión de elementos de red de área local (LAN)
Los sistemas de gestión de elementos de redes deárea local gestionan LANs de propósito general. Los sistemas de gestión de elementos en esta sección están agrupados en: - ethernet - token Ring - concentradores cableados, hubs - dispositivos de interconexión - backbones de LANs, como por ejemplo FDDI - plataformas de gestión LAN Los segmentos de redes de área local basados en Ethernet son todavía líderes en el mercado. Por ello, es extremadamente importante proporcionar capacidades de monitorización y gestión para esos segmentos. Las empresas líderes en este campo son DEC a través de Ethernim y HP, con LANProbe, Probeview y Openview. IBM está liderando este mercado con herramientas de gestión token ring y con la gama de productos LAN Network Manager. Hay dos opciones de gestión básicas: gestión standalone de componentes conectados, o centralizados y gestión integrada via Netview. Los productos de gestión de redes LAN de IBM gestionan LANs al nivel de estación de trabajo, y con Netview como computador Host. Ellos hacen seguimiento y control de acceso a dispositivos en cada LAN. IBM tiene cinco grandes productos de gestión de redes Token-Ring: - IBM LAN Network Management versión 1.0. - IBM LAN Network Management versión 1.1. - IBM LAN Network Management Entry. - IBM LAN Station Manager. - IBM 8230 Controlled Access Unit (CAU). Se pueden distinguir las siguientes funciones en la gestión de elementos token ring como las más importantes: - monitorización activa - monitorización de errores en el anillo - servidor de parámetros al anillo - servidor de configuración del anillo - servidor de puente LAN - trazas y prestaciones - gestor de estaciones - unidad de acceso controlado - gestor de LANs - Netview (punto de control SNA)
Por otra parte, los concentradores cableados y hubs están llegando a ser el objetivo de la gestión de redes en LAN. Muchos analistas predicen que la gestión de red basada en bridges y routers va encaminada a gestión basada en hubs. Uno de los sistemas de gestión más representativos es el que Cabletron presenta con el Spectrum Network Management. Respecto a las redes de alta velocidad, se identifican casi exclusivamente como redes FDDI y Fast/Gigabit Ethernet. Los estándares de gestión en algunos tipos de redes todavía no están completamente definidos. Los sistemas de gestión de elementos para LANs interconectados emplazan tanto gestión de LANs como gestión de WANs en el mismo lugar, el control del centro de gestión de red. Cada objeto gestionado individual, tales como repetidor, puente, brouter, router , y gateway es parte del segmento de LAN local. Pero al mismo tiempo, los mismos componentes son parte de la topología MAN y/o WAN. Como productos destacados se puede citar el CiscoWorks de Cisco. Finalmente, la mayor parte de sistemas de gestión de elementos multisegmento tienen la capacidad de ofrecer gestión multisegmento desde plataformas estándares o propietarias. Éstas combinan fast packet , conmutación, tecnologías de encaminamiento con FDDI, ethernet y hubs token ring que se gestionan desde una plataforma común y ofrecen mejores prestaciones por el menor coste. 3.2.7 Integradores para gestión de LANs
Para la gestión de redes heterogéneas se han adoptado diversas estrategias a lo largo del tiempo. Al principio era usual utilizar una integración de gestión de LANs jerárquica, mediante un esquema de gestor de gestores. Este esquema era válido pero no permitía suficiente flexibilidad en los cambios de configuración de la red, ya que exigía la modificación de los programas continuamente. El procesado de la información y la fiabilidad de un único nodo jerárquico superior (gestor de gestores) era también una limitación en redes de muchos nodos. Gestor de gestores Aplicaciones de integrador
SGE de elementos LAN
SGE de hubs cableados
SGE PBX
Equipos de test de LANs
Analizadores LAN
SGE de puentes/routers
Monitores LAN
Objetos gestionados SGE: Sistema de gestión de elementos
Fig. 3.10 Configuración como gestor de gestores de redes
A medida que los fabricantes se fueron enfrentando con el problema de la gestión de gestores fueron adoptando otras soluciones como el uso de integración de gestión de LANs con plataformas. Actualmente el uso de plataformas de gestión que utilizan APIs (Applications Programming Interfaces) está muy extendido. Finalmente, con el uso masivo de Internet, la gestión de red mediante webs y navegadores se está haciendo cada vez más normal, si bien los estándares están aún poco desarrollados.
A1
AN
A2
Plataforma para soluciones de fabricantes utilizando el
Applications Programming Interface (API) SGE de elementos LAN
Equipos de test de LANs
SGE de hubs cableados
SGE PBX
Analizadores LAN
SGE de puentes/routers
SGE de PC-LANs
Monitores LAN
Objetos gestionados SGE: Sistema de gestión de elementos
Fig. 3.11 Configuración como gestor que integra APIs para gestión de redes heterogéneas
Las aplicaciones sobre plataformas de gestión más frecuentes son las siguientes: - gestión de equipos específicos - gestión de incidencias a través de un Trouble Ticket System - gestión de inventario - gestión de cableado - interacción con otros sistemas de gestión - gestión de fallos mediante sistemas expertos - gestión de sistemas,... Por otra parte, las plataformas de gestión requieren de una integración entre esas aplicaciones. Existen tres tipos de integración entre aplicaciones: integración de comunicaciones, integración de interfaces de usuario e integración de información. Sólo las dos primeras están solucionadas con el uso de una plataformas de gestión: las comunicaciones, dado que todas las aplicaciones usan los servicios de comunicaciones (API) de la plataforma y el interfaz de usuario, puesto que las aplicaciones comparten el interfaz de usuario de la plataforma.
LAN Interfaz de usuario (motif, GUI, windows,...) Elementos de servicio - Comunicación interna - Interfaz a agentes - Aplicación entre funciones
Elementos de servicio con aplicación: - Configuración - Fallos - Prestaciones - Seguridad - Tarificación
Gateways a agentes propietarios, de facto o abiertos
Agente propietario
Eventos Mensajes Alarmas
Agente de facto
Agente abierto
Reacciones Comandos
Fig. 3.12 Arquitectura genérica de un producto de gestión d e LANs actual
Respecto a la integración de información, se implementa una base de datos local de gestión dado que las aplicaciones de gestión requieren almacenar datos localmente, como datos de topología, datos administrativos, etc. Estos datos pueden formar parte de las MIB, pero no es frecuente. Las plataformas y algunas aplicaciones incorporan el uso de bases de datos relacionales para el almacenamiento local. Cada aplicación tiene necesidades de almacenamiento diferentes, pero con frecuencia existen datos comunes entre ellas. Como consecuencia, cada aplicación tiene su propia base de datos. Dado que las plataformas actuales no permiten una integración de la información entre las aplicaciones (sólo admiten una emulación de consolas), se definen dos enfoques diferentes para su solución: un esquema universal de almacenamiento de datos, o bien el desarrollo de aplicaciones a la medida. La integración puede realizarse de dos formas: mediante el uso de una plataforma o bien mediante el uso de un integrador. Con los productos de integración, se pueden identificar dos grandes grupos: productos de emulación de consolas e integradores avanzados. Las soluciones más importantes basadas en productos de emulación de consolas son: - Netview (IBM) - Accumaster Integration (AT&T) - DECmcc (DEC) A continuación, en las siguientes figuras se presentan esquemáticamente las funcionalidades de estos integradores.
3. Soluciones para la gestión de redes
51
Netview Ayudas a instalación Comandos de facilidades CLISTs Ayudas a escritorio Hardware monitor (NPDA)
Módulos de presentación: Interfaz de línea de comandos Creación MAP DEC Windows Módulos funcionales:
Interfaz
Ejecución Registro Dominios Alarmas Analizador de prestaciones Historia Diagnosis DECnet
Reposición de la información de gestión
Módulos de acceso DECnet phase IV DECnet OSI SNMP TCP/IP Ethernet Bridge/router
Fig. 3.15 DECmcc Director
3.3 Mecanismos para la detección de configuraciones de red En el momento de proceder a la obtención de la configuración topológica de una red se pueden aplicar diferentes mecanismos de búsqueda y detección de los nodos que configuran la red. Normalmente eso se realiza con la aplicación Discover desde una plataforma de gestión de tipo convencional. En el proceso de detección se envían de modo secuencial mensajes ICMP (Internet Control Message Protocol) a cada uno de los nodos, que la aplicación presenta en pantalla en el caso de que los nodos estén activos. En el caso de que no contesten al cabo de un determinado tiempo, los nodos se dan por inactivos; sin embargo, existen una serie de problemas en el caso de que se produzca una inundación de mensajes ICMP no reconocidos que afecten al tráfico normal. La solución a este tipo de problemas pasa por restringir el número de mensajes que pueden estar no reconocidos (N) en un determinado instante. Por ejemplo, es el caso de la plataforma OpenView, que utiliza N=3 con el algoritmo COP-N. La tasa a la que se emiten las peticiones es inversamente proporcional al tiempo requerido para resolverlas, ya que no hay control explícito en la tasa de consultas. Sin embargo, la tasa de consultas podría ser más alta de lo deseable si el tiempo de reconocimiento es corto y todos los nodos interrogados responden al mismo tiempo. El problema puede ser la generación de ráfagas de mensajes en el momento de descubrir series de nodos. Una política de gestión usual es utilizar un sistema con N=3 y un tiempo de timeout de 10 segundos. Este tiempo de timeout se suele duplicar en los tres subsiguientes intentos. A partir de esta disposición, surgen nuevos problemas, como es el retardo que se produce en el sistema si los nodos son ilocalizables que llega a ser de 2,5 minutos. (10 + 20 + 40 + 80 = 150 seg.). Si existe alguna parte de la red cortada, ello produce bloqueos sucesivos del sistema. Una posible solución pasa por aumentar N; sin embargo, en este caso, las ráfagas podrían ser mayores. Una posible solución pasa por prevenir inundaciones, se diseña un algoritmo RPE (Regulated Poll Emission) en el que los mensajes de prueba se emiten a una tasa que no supera un determinado nivel,
3. Soluciones para la gestión de redes
53
soportable por la red (p.e. usando el sistema operativo Unix). Los nodos pueden ser consultados concurrentemente sin recibir reconocimientos. 3.3.1 RPE (Regulated Poll Emission)
Este algoritmo permite que las peticiones de interrogación de eestatus puedan generarse en ráfagas dependiendo de la estrategia escogida de ordenación. Para ello, la solución pasa por utilizar un mecanismo de leaky bucket , en la que un número específico de pings puede transmitirse dentro de un tramo específico de tiempo. Los mensajes se enviarían en intervalos de tiempo no menores que τ. Si el tiempo de emisión de los mensajes de polling de longitud constante es C, con C < τ, entonces la tasa de transmisión de polling máxima es 1/ τ a pesar del estado de los nodos interrogados o la secuencia con la que éstos son interrogados. Para acelerar el proceso de los reconocimientos (acknowledgments) se implementan registros de pings no reconocidos en una estructura indexada de datos ordenados por la dirección IP de destino. Para acelerar la gestión de los timeout s se registran los pings no reconocidos de forma que son indexados por el tiempo en que se ordena un timeout . Cada registro en una tabla tendría un puntero en el registro de la otra para asegurar su borrado automático y efectivo cuando suceda un timeout . El RPE tiene una serie de ventajas, ya que el método permite un número arbitrario de peticiones de eestatus simultáneas, permite un rápido cambio en los mapas de eestatus de los nodos de red y previene la liberación de ráfagas de mensajes de petición de estatus en la red. En cuanto a las limitaciones, cabe decir que no hay un control sobre la tasa de recepción de reconocimientos (ack. ICMP), con el consiguiente peligro de ráfagas de respuestas en caso de recuperación o desbloqueo de la red. 3.3.2 Modelado de la duración de un ciclo de consultas de eestatus
La duración de la consulta viene determinada por el número de reintentos en la obtención del estatus de un nodo. En el caso del método COP-N el tiempo de espera es hasta la próxima consulta, mientras que en el RPE es el tiempo en que la petición de polling está almacenada. Sea un ciclo de polling con K intentos. La duración del intento k (1 <= k <= K) consta de: C: tiempo de emisión de la petición de polling. T K : intervalo de timeout . AK : tiempo en recibir un reconocimiento (ack) p K : probabilidad de que el k-ésimo intento no sea reconocido. 1 - p K : probabilidad de que el k-ésimo intento sea recibido antes del timeout . Ejemplo: K = 4. T 1 = 10, T 2 = 20, T 3 = 40, T 4 = 80 segundos, por tanto, ∑ T i = 150segundos .
Fig. 3.16 Esquema de la duración de los ciclos de consulta
Un intento de polling no está reconocido si ocurre uno cualquiera de los siguientes eventos: a) El mensaje de polling ICMP se pierde en su viaje con probabilidad γ 1 . b) El nodo no es alcanzable porque el camino está cortado con probabilidad γ 2 . c) Pérdida del mensaje de reconocimiento, por ejemplo debido a congestión en la red, con probabilidad γ 3 . d) El ack. no se devuelve antes que expire el timeout con probabilidad Pr ( AK ≥ T K ) . Luego, PK = 1 − (1 − γ 1 )(1 − γ 2 )(1 − γ 3 )Pr ( AK ≤ T K ) ya que los cuatro sucesos pueden ocurrir independientemente. El tiempo de acknowledgment AK se ve afectado por los γ i . AK depende de la topología así como de los niveles de congestión, lo que complica el análisis. La solución pasa por adoptar una AK distribuida exponencialmente con media equivalente al tiempo de viaje de la red gestionada, con lo que E [ AK ] podría ser de menos de 10 mseg. o de varios segundos. De hecho, el valor de las probabilidades γ i podría variar con la secuencia de nodos que deben ser interrogados, o por aquellas consultas que se han iniciado y no se han contestado. 3.3.3 Duración media del tiempo de ciclo de K intentos
Sean las siguientes definiciones: C: tiempo en emitir un mensaje de polling ICMP S K : tiempo restante de resolver la interrogación al comienzo del k-ésimo intento S 1 : tiempo en tomar la decisión de si el nodo interrogado es alcanzable o no.
Para otros intentos aparte del k-ésimo, se requiere un intento subsiguiente con probabilidad p K y resulta innecesario con probabilidad 1 - p K . Si un (k + 1) intento no es necesario, la duración del k-ésimo intento será el comienzo de la emisión al retorno del reconocimiento. Si se necesita, el resto del ciclo de polling incluye el k-ésimo timeout y la duración del (k + 1) intento, S K +1 : S k = C + (1 − p k ) Ak + p k (T k + S k +1 )
con k = 1, 2, 3,... K-1.
En el k-ésimo intento, el resto del ciclo de polling finaliza AK si el: S K = C + (1 − p K ) AK + p K (T K )
La duración media de la etapa final del ciclo de polling es pues: E [S K ] = E [C ]+ (1 − p K ) E [ AK ]+ p K E [T K ]
La duración media del tiempo restante del ciclo de polling al comienzo del k-ésimo intento es: E [S k ] = E [C ]+ (1 − p k ) E [ Ak ]+ p k ( E [T k ]+ E [S k +1 ])
con k = K-1, K-2, ..., 2, 1. 3.3.4 Número esperado de intentos de polling en un ciclo
El número esperado de intentos de polling en un ciclo determina el ancho de banda necesario. En general se asume que los eventos en intentos de polling sucesivos dentro de un ciclo son independientes. Aunque no resulta cierto, ya que si un nodo no es alcanzable en el primer intento, casi seguro no lo será en los intentos subsiguientes. K −1
Se requeriran K intentos con probabilidad ∏ p i . i −1
Si N p denota el número de intentos de polling requeridos dentro de un ciclo, bajo la suposición de independencia: K −1
K −1
K −1
k =1
j =1
k =1
E [ N p ] = ∑ K (1 − p k )∏ p j + K ∏ p k
al primer intento tenemos, (1 − p1 ) , con dos intentos sólo p1 (1 − p 2 ) . Si S p denota el tamaño de un mensaje de polling, X denota el máximo flujo bajo el cual se realiza cualquier mecanismo de envío de polling. La máxima demanda de ancho de banda de polling viene acotada por S p XE N p .
3.3.5 Flujos del ciclo de polling a) Método COP-N La tasa máxima resulta ser: X N =
N E [S 1 ]
K
El período de congelamiento resulta ser:
∑= T , expresado como la suma de los intervalos de timeout i
i 1
si N nodos inalcanzables son interrogados en rápida sucesión. Si la red funciona perfectamente, la tasa N * resulta ser: X N = con a como el tiempo de reconocimiento medio en ausencia de fallos o a + C pérdida de paquetes. C es el tiempo transcurrido al emitir un polling ICMP. Si a es pequeño, las ráfagas de consultas podrían degradar el comportamiento de la aplicación.
b) Método RPE Sea τ el tiempo mínimo entre emisiones de consultas ICMP. Sea, pues,
1
la tasa máxima para el
τ
envío de peticiones ICMP. Luego, τ > C a causa de las limitaciones del hardware y del software de E [S 1 ] los equipos. Por tanto, debe cumplirse que τ < si se quiere tener más tasa que en el método N COP-N. Sea M el máximo número de nodos permitido para que peticiones de polling no sean reconocidas, es decir, M como el número de entradas de la lista de registros. De forma que, en general se cumpla que M>>N. Luego, el número medio de peticiones de polling residentes en memoria resultará ser de XE [S 1 ]. De forma que XE [S 1 ] ha de ser menor que M para que el sistema funcione correctamente. Así:
1 M X < min , τ E [S 1 ] donde τ es controlable y M dependiente de la memoria disponible. Los factores que limitan la tasa de polling son la saturación del sistema operativo y/o la red con mensajes de polling, con lo que τ crece. Conforme crecen los retardos de propagación, transmisión, congestión, timeout s, o la alta incidencia de fallos en los nodos, entonces E [S 1 ] resulta ser un valor alto. M nunca será un límite si es mayor que N. En el método COP-N, con N<
3. Soluciones para la gestión de redes
57
3.3.6 Análisis del retardo Sean n > N nodos ordenados para ser interrogados en el tiempo t y, de éstos, los primeros N sean nodos inalcanzables o caídos, mientras que el estado del resto n-N nodos es desconocido. Sea M el máximo número permisible de ciclos de polling no resueltos bajo el método RPE que, en E [S 1 ] general, es mucho mayor que . Luego, en estas condiciones se puede calcular el retardo como: τ
a) Método COP-N K
Los ciclos de polling para los N nodos fallidos tardan
∑= T
k
segundos. Durante este periodo los otros
k 1
nodos no pueden interrogarse. Puede suponerse también que la interrogación de estatus del último nodo de la cola se iniciará en el tiempo: t + (n − N − 1) E [S 1 ]+
K
∑= T
segs. para n >= N + 1.
k
k 1
b) Método RPE Si M es muy grande, y se cumple que n (
mejor con el mecanismo de control de tasa τ si
K
∑= T
k
k 1
Para n = N + 1 , el n-ésimo ciclo de polling se iniciará antes que el mecanismo de tasa constante: K
∑= T
k
τ
≤
k 1
N
ya que τ es mucho menor, en general, que el otro término. El método RPE puede sincronizarse para limitar el ancho de banda de las interrogaciones o sostener la actividad de las interrogaciones de acuerdo con las necesidades.
4. Entornos de gestión de telecomunicación orientados a objetos
59
4 Entornos de gestión de telecomunicación orientados a objetos A medida de que las redes de comunicaciones tienden cada vez más a ser sistemas complejos, es necesario tener metodologías de modelado formales para entender, describir, construir operar y gestionarlas [BA1].
4.1 Introducción a la orientación a objetos El modelado orientado a objetos puede definirse como una formalización de la habilidad humana de categorizar cosas. Se puede distinguir entre el modelado orientado a objetos, más abstracto, menos detallado y más comprensivo de la visión del sistema, que se aplica mejor en las fases iniciales del proceso de diseño de una red, y la programación orientada a objeto, que concierne a los detalles de diseño del sistema a bajo nivel y a la eficiencia en la implementación. En este caso, el uso de lenguajes de programación orientados a objetos se podría utilizar para implementar un modelo orientado a objetos.
4.2 Objetos gestionados y el entorno gestor/agente El tema de comunicación entre objetos en una programación orientada a objetos es aplicable de forma directa: un objeto recibe un mensaje y responde a éste. Se trata en un principio de la arquitectura de gestión más básica, esto es, el sistema gestor/agente. Un lenguaje de programación orientado a objeto podría usarse como para implementar un modelo de red orientado a objetos. En un modelo de red orientado a objetos, cada clase que se especifica tiene un propósito. Cada clase en el modelo tiene un referente en el sistema real. Las clases de objetos deben especificarse para todo un conjunto de funciones: físicas, lógicas, humanas, etc. en el modelo de red. El núcleo de las propiedades especificadas en una clase de objetos son los atributos, funciones y cápsulas. Las clases se organizan en una jerarquía de herencia con una generalización que se incrementa hacia arriba y una especialización que se i ncrementa hacia abajo. En teoría de la especialización, generalización y especialización se describen formalmente en términos de una propiedad tomada como base. Esto implica que cuando se decide especializar una nueva clase de objetos de una clase de objetos existente, se debe seleccionar una base de especialización. La base de especialización actúa como un factor que permite distinguir entre subclases.
La especialización cualititativa ocurre cuando la propiedad tomada como base es un atributo superclase que puede poseer uno de un conjunto enumerado de valores. Si la propiedad tomada como base es un atributo numérico de la superclase, la especialización ocurre restringiendo el dominio de valores que se le permite poseer al atributo en la subclase. En algunas ocasiones es necesario usar más de una propiedad como base para la misma especialización: esto se conoce como especialización compuesta.
Multiplexor Velocidad del puerto
Velocidad del puerto < 45 Mbps
Velocidad del puerto >= 45 Mbps
Multiplexor banda estrecha
Multiplexor ancha
banda
Fig. 4.1 Base cuantitativa de la especialización
Servicios de llamada al cliente Tipo de servicio Número de versión software Fecha de inicio servicio Tipo de servicio = Llamada en espera
Tipo de servicio = Multiconferencia
Servicio llamada en espera
Servicio multiconferencia
Tipo de servicio = Trazas llamada Servicio trazas llamada
Fig. 4.2 Base cualitativa de la especialización
Las clases se especializan desde sus superclases usando una base formal de especialización. Si se usa un atributo como la propiedad de base de una especialización, las subclases creadas tienen valores restringidos por el dominio del atributo. El atributo, escogido como propiedad de base, podría tener un valor continuo o un valor discreto. La partición del dominio de la base atributo en las subclases se considera en función de criterios de completitud y solapamiento. Podrían considerarse simultáneamente múltiples propiedades para su uso como base compuesta de especialización.
4. Entornos de gestión de telecomunicación orientados a objetos
Disjuntos
Solapados
Completos
Más deseable
No deseable
Incompletos
Deseable
Lo menos deseable
Fig. 4.3 Modos de subclases para bases seleccionadas de especialización
Para el desarrollo de productos o redes usando metodologías de modelado orientado a objetos, la arquitectura de la red debe organizarse usando jerarquías de herencia y agregación. La jerarquía de herencia debe enumerar todas las versiones y diferentes configuraciones que la red o el producto pueda manifestar. En la figura aparece como ejemplo la jerarquía de agregación que se manifiesta en la arquitectura de la red inteligente.
SCE SCP: Punto de control de servicios SSP: Punto de conmutación de servicios STP: Punto de transferencia de señalización SMS: Sistema de gestión de servicios IP: Periférico inteligente SDP: Punto de datos de servicios SCE: Entorno de creación de servicios AD: Adjunto SN: Nodo de servicios
Terminal de usuario A
SMS
SCP
SDP Red de señalización SS7
IP
STP AD/SN SSP
Local RTC
Local
Fig. 4.4 Esquema de arquitectura de la red inteligente
5 Gestión según OSI El fundamento del sistema de gestión OSI es la base de datos que contiene información relativa a los recursos y elementos que deben ser gestionados (MIB). La estructura de gestión de información (SMI) identifica los tipos de datos que pueden ser usados en la MIB y cómo se representan y nombran los recursos dentro de la MIB [STA2]. Cada recurso que se monitoriza y controla por el sistema de gestión OSI se representa por un objeto gestionado, como por ejemplo: conmutadores, estaciones de trabajo, PBX, programas en cola, algoritmos de encaminamiento, etc. En este caso de gestión, la complejidad de la gestión se traslada al agente (que reside en un ordenador). Los protocolos de gestión permiten realizar funciones más complejas dado que el modelo de información también es complejo. La evolución de este tipo de gestión permitirá realizar una gestión integrada en entornos heterogéneos (p.e. TMN). Las recomendaciones de la serie X.700 permiten hablar de una serie de modelos de gestión de sistemas. Son los siguientes: - Modelo de comunicaciones: se detalla el protocolo de gestión y el servicio que proporciona. - Modelo de información: se definen los recursos de red usando una sintaxis abstracta. - Modelo funcional: se definen las funciones de gestión que proporcionan una interfaz a la aplicación de gestión. - Modelo de organización: se exponen las posibles subdivisiones de la red en dominios de gestión.
5.1 Modelo funcional El modelo funcional describe las cinco áreas en las que tradicionalmente se ha dividido la gestión de red: gestión de fallos, gestión de configuración, gestión de prestaciones, gestión de contabilidad y gestión de seguridad. El sistema de gestión basado en OSI define una serie de niveles con interfaces de gestión que interactúan con la base de datos MIB. El nivel de aplicación interactúa, a su vez, con otros procesos de gestión mediante el protocolo CMIP (Fig. 5.1).
OSI ha definido cinco grandes áreas de gestión (SMFAs) denominadas de fallos, contabilidad, prestaciones, seguridad y configuración (Fig. 5.2). Estas áreas están a su vez constituidas por diversas funciones específicas (SMF) que realizan procesos de gestión, interactuando con los servicios CMISE.
Proceso de aplicación de gestión de sistemas Interfaz de gestión de sistemas Entidad de aplicación
LME de gestión de sistemas
CMIP
Entidad de presentación LME Entidad de sesión Entidad de LME transporte LME Entidad de red
Proceso agente
LME Base de datos de información de gestión
Interfaz de gestión de capas
MIB
LME Entidad de nivel de enlace LME Entidad física LME: layer-management entity
Fig. 5.1 Marco de gestión OSI
5.2 Modelo de organización El modelo de organización parte de una estructura de red dividida en dominios de gestión. La división del entorno se realiza a partir de dos aspectos principales: políticas funcionales (p. e. dominios con una misma política de seguridad, contabilidad,...), o bien otras políticas, como dominios geográficos, tecnológicos, etc. La red se estructura en dominios administrativos, con la necesidad de establecer y mantener las responsabilidades de cada dominio. Por otra parte, el sistema permite que dentro de un dominio, se pueda reasignar dinámicamente el papel de gestores y agentes.
5.3 Modelo de comunicaciones: CMIP El Common Management Information Protocol (CMIP) se define en el estándar 9596 de OSI. Este protocolo ofrece un mecanismo de transporte en la forma de servicio pregunta-respuesta para capas OSI. La especificación del protocolo describe precisamente cómo se ejecutan los servicios CMIS
individuales. En la figura 5.3 se pueden observar los estándares relacionados con la gestión definida por OSI.
Áreas funcionales de gestión específicas (SMFA) Gestión de fallos
Gestión de contabilidad
Gestión de objetos Gestión de información de eventos
Gestión de configuración
Gestión de estados
Registro de contabilidad
Gestión de relaciones
Información de seguridad y alarmas
Control de registros
Gestión de prestaciones
Monitorización de carga de trabajo
Gestión de seguridad
Información de alarmas
Pruebas de Control de seguridad-audit. acceso
Gestión de test
Sumarización
Funciones de estión del sistema (SMF) Servicios CMISE Event report
Get Create
Action
Set Delete
Cancel-Get
Fig. 5.2 Funciones de gestión de sistemas
Una parte de la especificación del protocolo CMIP es la definición de la Abstract Syntax Notation (ASN.1) para codificación y decodificación de unidades de datos del protocolo CMIP (PDUs). Estos aspectos se estudiarán en el capitulo 12, relativo a Internet. A lo largo de la evolución del protocolo CMIP han surgido variantes del protocolo para diferentes entornos. Por ejemplo, existe una versión de CMIP sobre protocolos TCP/IP denominada CMOT, o bien el caso de una versión de CMIP sobre protocolos IEEE de LANs denominada CMOL. En la figura 5.4 se detallan los subniveles que forman el nivel de aplicación en un entorno de gestión según el estándar OSI (Entidad de Aplicación de Gestión de Sistemas, SMAE).
5.3.1 Características principales del protocolo CMIP Entre las características más importantes del protocolo CMIP se pueden destacar las siguientes: - CMIS/CMIP requiere de gran cantidad de memoria y capacidad de CPU. - Se generan largas cabeceras en los mensajes de los protocolos. - Las especificaciones son dificiles de realizar y tediosas de implementar en aplicaciones. - La comunicación con los agentes está orientada a conexión. - La estructura de funcionamiento es distribuida. - Permite una jerarquía de sistemas de operación. - El protocolo asegura que los mensajes llegan a su destino. El hecho de que se trate de una gestión conducida por eventos se traduce en que: - El agente notifica al gestor de sucesos la información concerniente a los recursos gestionados. - El agente es responsable de monitorizar los recursos. - Presenta la ventaja de que existe menor gestión de tráfico. - Presenta la desventaja de tener agentes más complejos.
Gestión del marco de trabajo 7498-4 X.700
Tutorial de gestión del sistema
Introducción a la gestión de sistemas 10040 X.701 Modelo de información de gestión 10165-1 X.720 Funciones de gestión de sistemas 10164-n X.7nn
Servicio de información de gestión común 9565 X.710
Guias para la definición de objetos gestionados 10165-4 X722 Definición de información de gestión 10165-2 X.721 Definiciónes de objetos gestionados
Protocolo de información de gestión común 9596-1 X.711
MAPDUs: unidad de datos de protocolo de aplicación de gestión. CMIPDUs: unidad de datos de protocolo de información de gestión común.
Fig. 5.4 Gestión en el nivel de aplicación
5.3.2 Servicios usados por CMIP CMIP hace uso de ACSE ya que establece y finaliza asociaciones para el intercambio de información de gestión. El tipo de asociación se especifica en el campo Application Context de la primitiva de asociación de ACSE (manager, agent, o manager-agent ). Es usado directamente por el usuario de gestión. El protocolo CMIP también hace uso de ROSE, ya que es usado por CMISE para la solicitud de ejecución de operaciones remotas. El gestor solicita una operación remota, el agente lo intenta ejecutar y devuelve el resultado del intento. ROSE se utiliza por aplicaciones tipo cliente-servidor.
5.3.3 Servicios ofrecidos por CMIP A través de CMISE (Common Management Information Service Element), CMIP proporciona tres tipos de servicio: - Manejo de datos: usado por el gestor para solicitar y alterar información de los recursos del agente. - Informe de sucesos: usado por el agente para informar al gestor sobre diversos sucesos de interés. - Control directo: usado por el gestor para solicitar la ejecución de diversas acciones en el agente. También hace uso del servicio de operaciones remotas proporcionado por ROSE.
5.3.4 Primitivas CMIP Existen las siguientes primitivas CMIP para petición de operaciones: - M-EVENT-REPORT (conf/no-conf) -> notificaciones Informa de un evento acerca de un objeto gestionado desde una capa de usuario de servicio CMISE. - M-GET (conf) -> manejo de datos Pide la obtención de información de gestión desde una capa de usuario de servicio CMISE. - M-SET (conf/no-conf) -> manejo de datos Pide la modificación de información de gestión desde una capa de usuario de servicio CMISE. - M-ACTION (conf/no-conf) -> control directo Pide que una capa de usuario de servicio CMISE realice una acción. - M-CREATE (conf/no-conf) -> control directo Pide que una capa de usuario de servicio CMISE cree una instancia de un objeto gestionado. - M-DELETE (conf/no-conf) -> control directo Pide que una capa de usuario de servicio CMISE borre una instancia de un objeto gestionado. - M-CANCEL-GET (conf) -> control directo Pide que una capa de usuario de servicio CMISE cancele una petición previa de invocación de un servicio M-GET. La estructura de los mensajes de operaciones CMIP tiene los siguientes campos de información: - Object Class - Object Instance - Scope (subarbol, niveles,...) - Filter (todos los objetos con determinadas condiciones lógicas) - Access Control - Synchronization - Attribute Identifier List Se definen las siguientes primitivas CMIP para transmisión de resultados: - M-EVENT-REPORT-RES - M-GET-RES - M-SET-RES - M-ACTION-RES - M-CREATE-RES - M-DELETE-RES - M-LINKED-REPLY Las primitivas de servicio M-GET, M-ACTION y M-DELETE son primitivas que pueden especificar operaciones en múltiples objetos, incluyendo un parámetro de enlace para proporcionar múltiples
réplicas a una única petición. Aunque la primitiva M-SET también permite la especificación de múltiples objetos, no soporta respuestas enlazadas. Para las cuatro primitivas se proporcionan herramientas para la selección de objetos, basadas en el filtrado, la sincronización y la contención (scope).
5.3.5 Arquitectura de comunicaciones A continuación se presenta en la figura la torre de protocolos OSI que soporta el estándar de gestión CMIP:
Aplicación de gestión ASE específica de gestión FTAM
Nivel 7
CMISE CCR ACSE
ROSE
ACSE
Nivel OSI de presentación
Nivel 6
Nivel OSI de sesión
Nivel 5
Nivel OSI de transporte Subred 1 X25
Nivel 4 Subred 2 802.3
Nivel 1-3
Fig. 5.5 Arquitectura de niveles definida para el protocolo CMIP
Actualmente las plataformas de gestión con protocolo CMIP de diferentes fabricantes presentan información que es propietaria, de forma que existe una cierta incompatibilidad si se quieren utilizar conjuntamente en la gestión de una red. En la figura adjunta se describe esta situación. Finalmente, y más recientemente, se ha presentado el interfaz XOM/XOP, definido por la asociación X/Open para la coexistencia de protocolos SNMP con CMIP. A partir de unos proxies se permite la complementariedad de gestión de ambos protocolos en redes grandes. En entornos locales se utiliza SNMP y, a nivel de red de área extensa, se suele hacer uso del protocolo CMIP.
Fig. 5.6 Sistemas de gestión de red basados en CMIP emergentes
5.3.6 X/Open Abstract Data Manipulation Application Program Interface XOM API (XOM) define un interfaz de programación de propósito general a gestión de objetos OSI (gestión de objetos como la creación, el examen, la modificación y el borrado de objetos potenciales de información compleja). OSI Abstract Data Manipulation
La arquitectura de información XOM (XOM Information Architecture) especifica el intercambio entre cliente y servicio, y que el servicio mantiene y hace accesible al cliente. La arquitectura proporciona una base para especificar interfaces de servicio, como por ejemplo, cómo el cliente comunica con el servicio, cómo el servicio comunica con el cliente en respuesta, y cómo componentes del servicio comunican unos con otros. La arquitectura no dicta la estructura física de la información ni cómo el servicio la mantiene internamente. La XOM Information Syntaxes define la sintaxis permitida de valores atributo. Las sintaxis son similares a los tipos y constructores de tipos de ASN.1. La XOM Service Interface especifica: - Los tipos de datos del interfaz de servicio (p.e. booleano, objeto, string,..) - Las funciones que el servicio hace dsponibles al cliente (p.e. copy, create, get, put, remove,..). - Los códigos de retorno de las funciones de interfaz de servicio (p.e. codificación invalida, errores permanentes,...). El XOM Workspace Interface define tipos que especifican la parte inicial de la representación de objetos y algunas estructuras de datos asociadas. También proporciona una definición de macros para cada función interfaz de servicio, que usa la estructura de datos definida para llamar la
implementación de las funciones apropiadas para los argumentos particulares. La especificación XOM incluye también Object Management Package donde se define la jerarquía de clases y algunas clases de objetos.
5.3.7 X/Open Management Protocols Application Program Interface (XMP) La X/Open Management Protocols Application Program Interface (XMP) define un Application Program Interface (API) para servicios de información de gestión. La interfaz se diseñó para ofrecer servicios que están relacionados con los estándares CMIS/CMIP y SNMP. El XMP opera entre una aplicación de usuario y el software común definido por la X/Open y aísla la parte del programador de todas las operaciones del software X/Open. Permite la manipulación de diferentes estructuras de información de gestión descritas en ISO 10165 y RFC 1155.
Programa de gestión API XOM
Paquete XOM
API XMP
Gestión de paquetes de servicio Paquete comun
Paquete DMI
Paquete Paquete CMIS SNMP
Espacio de trabajo de los objetos gestionados Fig. 5.7 Relación entre XOM y XMP
La especificación XMP describe un número de funciones con muchas clases y objetos OM, que se utilizan como argumentos y resultados de las funciones. La interfaz modela interacciones de gestión como peticiones de servicio. Estas peticiones de gestión se realizan a través de un número de funciones interfaz, que usan un número de argumentos de entrada. Cada petición válida causa una operación realizada por agente o notificación direccionada al gestor. Después de algunas operaciones, un estatus o los resultados de las operaciones pueden devolverse. Todas las interacciones gestoragente se realizan durante una sesión, que se representa por un objeto usado en la mayor parte de las funciones interfaz. La tarea del programador es crear funciones de llamada que invoquen operaciones CMISE o SNMP.
5.3.8 CMIS/P++ CMIS++ es una nueva versión de CMIS que proporciona mucha más potencia expresiva, mientras que CMIP++ soporta evaluación remota y minimiza el tráfico de gestión requerido para la obtención de información de gestión. Esta extensión de la arquitectura se justifica por los requerimientos que presenta la gestión de redes como SDH.
5.4 Modelo de información El modelo de información proporciona una representación de los recursos gestionados. En el esquema de la figura 5.8 se muestra el proceso de obtención de la información de gestión del entorno de red.
Operaciones gestión Gestor
Agente
Operaciones gestión Notificaciones
Notificaciones
Entorno local
Fig. 5.8 Esquema del proceso de gestión en un entorno de red
El objetivo consiste en modelar los aspectos de gestión de los recursos reales, así como definir una estructura para la información de gestión que se transmita entre sistemas. Este modelado se estructura en función de unos objeto gestionados (MO: Managed Object ) que se pueden definir como abstracciones de un recurso que representa sus propiedades para el propósito de su gestión (p.e. entidad de capa, conexión, item de un equipo de comunicaciones físico). Para el caso que nos ocupa, sólo es necesario definir los aspectos del recurso útiles para su gestión. De la misma forma no se define la relación entre el recurso y su abstracción como objeto gestionado, que suele ser definido por el fabricante. Entre los componentes de un objeto gestionado, pueden distinguirse una serie de atributos visibles, las operaciones de gestión de sistemas permitidas sobre el objeto, el comportamiento del objeto en respuesta a las operaciones de gestión, las notificaciones que puede enviar, los paquetes condicionales que pueden ser encapsulados en el objeto (características opcionales del objeto), la posición del objeto en la jerarquía de herencia o bien la especificación de las clases de objetos alomórficas con su clase. Por otra parte, el modelo de información hace uso de los principios de diseño orientado a objetos. Para ello, se requiere adaptar un enfoque que permita estandarizar especificaciones de una manera modular. El enfoque elegido debe proporcionar una fácil capacidad de extensión del protocolo y de los procedimientos. También se debe permitir la reutilización de especificaciones anteriores. Finalmente, hay que tener en cuenta que el ámbito de diseño es aplicado a la especificación de información transmitida en los protocolos de gestión, no a la implantación.
Antes de seguir adelante es necesario repasar una serie de conceptos relacionados con el diseño orientado a objetos que se utilizan en la gestión OSI. El árbol de registro sirve para que todos los elementos definidos en una MIB puedan tener asignados un Object Identifier (OID). Los OIDs de gestión de sistemas se registran por debajo de: {joint-iso-ccitt ms (9)} que es el identificador principal (top). Por debajo de éste, se asignan otros identificadores que dependiendo de la concreción de la información y forma donde se definan, van creando las hojas del árbol de registro. Las ramas sucesivas del árbol son las siguientes: smo (0) cmip (1) function (2) smi (3) El encapsulamiento es una relación de inclusión entre un objeto gestionado y sus atributos, notificaciones, operaciones y comportamiento. Asegura la integridad de los objetos gestionados. Las operaciones sobre un objeto se realizan mediante el envío de mensajes al objeto. Por otra parte, no es visible la operación interna del objeto, salvo cuando se hayan definido atributos, operaciones o notificaciones para mostrar esta información. En cuanto a las clases y ejemplares, se diferencia entre los aspectos relativos a la definición de los objetos y los aspectos de implementación de estos objetos. Es decir, la definición de objetos nos lleva a clases de objetos como un conjunto de objetos gestionados que comparten los mismos nombres, conjuntos de atributos, notificaciones y operaciones de gestion (packages) y que comparten las mismas condiciones para la presencia de estos packages (lotes). Dan como resultado un texto con definiciones de clases. Por otra parte, la implementación de objetos como ejemplares (o instancias) de las clases dan lugar como resultado a instancias existentes en un agente en un momento dado. Una clase de objeto es un conjunto de ejemplares de objetos gestionados con las mismas propiedades. Una especialización genera una nueva clase (subclase) por extensión de otra ya existente (superclase), añadiendo nuevas propiedades. Por tanto, introduce una relación de herencia. Las propiedades de una clase se pueden extender a partir de la ampliación con nuevos atributos, la extensión/restricción de los rangos de atributos, la ampliación con nuevas acciones o notificaciones o bien la ampliación de los argumentos de acciones y notificaciones. Existe una TOP o superclase superior de la jerarquía de la herencia que contiene las propiedades comunes a todos los objetos gestionados. Por otra parte, se permite sólo la herencia estricta de las propiedades, es decir, que una subclase se especialice mediante la adición de nuevas propiedades (no se pueden quitar propiedades). También se permite herencia múltiple, lo que conlleva una serie de beneficios: una mayor reutilización de las definiciones de clases y una mejora de la capacidad de un sistema gestor para reconocer clases no conocidas. Ejemplo de jerarquía de herencia:
Fig. 5.9 Esquema un árbol de jerarquía de herencia
Los atributos de objetos gestionados representan las propiedades de un objeto gestionado. Los atributos tienen un valor asociado que puede ser un conjunto o una secuencia de elementos. Puede haber constricciones en el valor de un atributo o entre valores de distintos atributos. Por otra parte, los atributos pueden ser obligatorios o contenidos en paquetes condicionales (opcionales). También se permiten atributos multivaluados y atributos de grupo. El comportamiento (behaviour) define a los miembros de la misma clase si exhiben el mismo comportamiento (interactúan) ante la misma operación de gestión. El comportamiento de un objeto se define por la semántica de atributos, las operaciones y notificaciones, la respuesta a operaciones de gestión sobre el objeto, las circunstancias bajo las que se emiten las notificaciones, las dependencias entre valores de atributos particulares y los efectos de las relaciones entre los objetos. Los paquetes condicionales (packages) definen los atributos opcionales, las notificaciones, las operaciones y los comportamientos que están o todos presentes o ausentes a la vez en un objeto gestionado (p. e. correo electrónico con paquete condicional de seguridad). La condición de presencia da idea de las capacidades del recurso, mientras que el atributo packages informa de los paquetes condicionales que soporta el objeto. El alomorfismo es la capacidad de un ejemplar de una subclase de simular el comportamiento de su superclase. Permite la extensión de una clase de tal manera que continúe la interoperabilidad cuando el gestor o el objeto gestionado no incluyan esta extensión. Por otra parte, se necesita para posibilitar la migración de versiones de gestión. Existen una serie de constricciones para las subclases alomórficas: esto es, deben incluir un atributo que identifique las superclases alomórficas de esa subclase, y el rango de valores de un atributo heredado debe ser el mismo o un subconjunto del rango de la superclase. Existen también las superclases no restringidas, que son superclases sin restricciones en sus valores. Se especializan subclases alomórficas con distintas restricciones que no serían permitidas en un alomorfismo directo entre ellas. La determinación del comportamiento alomórfico se representa mediante un argumento en la petición de la operación. También puede representarse si se proporciona una lista ordenada de clases conocidas por el sistema gestor. Por otra parte, la clase que se aplique será aquella que sea superclase alomórfica permitida y que aparezca primera en la lista.
Existen una serie de operaciones posibles sobre objetos. Una operación en un objeto gestionado sirve para afectar la gestión del sistema. Se pueden definir dos clases de operaciones: las operaciones aplicables a atributos y las operaciones aplicables a objetos globalmente. Las operaciones orientadas a atributos son las siguientes : Get Attribute value, Replace Attribute value, Set-to-default value, Add member y Remove member. Las operaciones sobre objetos pueden ser: Create object, Delete object y Action object . Los efectos de estas operaciones pueden ser directos o indirectos. Las acciones representan la capacidad del objeto de realizar una acción distinta ante cambios en las propiedades. Son útiles para modelar la ejecución remota de comandos. La notificación es un informe emitido por el objeto cuando se cumplen determinadas condiciones. Las condiciones de las notificaciones se especifican en la definición. Por otra parte, se define un EFD (Event Forwarding Discriminator) que permite filtrar las notificaciones que llegan a los gestores. Como resumen se puede decir que para la definición de clases se parte de la posición en la jerarquía de herencia, los atributos de la clase, los comportamientos, las acciones, las notificaciones, y las clases alomórficas. Las propiedades anteriores se pueden agrupar en paquetes (obligatorios o condicionales).
raíz sistema
sistema
PC
Unidad disco
Estación de trabajo
PC
Placa red
Unidad disco
Fig. 5.10 Esquema de árbol de agregación
Una jerarquía de agregación refleja la relación de contención entre instancias de objetos. Cuando se establece una jerarquía de agregación, una instancia subordinada está contenida en una única instancia superior. Tiene como utilidad la estructuración de instancias de objetos en los agentes (usado por los parámetros de filtrado y ámbito del CMIP. También permite realizar operaciones con una gran potencia). Define también el nombrado de los ejemplares desde el gestor. En la figura 5.10 se muestra un ejemplo de árbol de agregación. Para el nombrado de instancias, cada clase de objetos gestionados debe tener al menos un atributo que proporcione un nombre distintivo a los ejemplares de esa clase. Este atributo es el Relative
(RDN). El nombre de una instancia es la concatenación de RDN de sus antecesores en la jerarquía de agregación.
Distinguished Name
Un ejemplo de nombre completo de instancia es el siguiente: SistemaId=DEPART3@PCId=PCMarketing@UnidadID=DiscoA
raíz sistema SisID=ST5
PC PCid=PC7
Unidad disco Unid=B
sistema SisID=ST8
PC PCId=PC2
Estación de trabajo WSId=Sun5
Placa red PlacaId=Eth1
Unidad disco UnID=C
SisId=ST5@PCId=PC2@UnID=C Fig. 5.11 Esquema de nombrado completo de instancia
El name binding proporciona restricciones para organizar la jerarquía de agregación. Por ello, se definen junto a la definición de clases. La estructura de un name binding se compone de una clase subordinada, una clase superior permitida y un atributo identificador para el nombrado de la clase subordinada. Hay que decir que pueden existir (y es deseable) varios name bindings para una misma clase subordinada.
5.4.1 MIB (Management Information Base) Una MIB es un conjunto de definiciones de uno o varios recursos formado por clases de objetos gestionados, acciones, notificaciones, atributos, sintaxis, etc, y los name bindings. Actualmente hay una gran variedad de MIBs definidas y normalizadas. Una MIB no tiene por qué ser autocontenida, ya que permite referencias a otras MIBs. La sintaxis de MIBs se basa en la notación GDMO (Guidelines for Definition of Managed Objects). Existen una serie de criterios para implementar una MIB, como son el uso de herencias de definiciones ya existentes y el establecer ligaduras de nombrado siempre que sea posible. Una MIB puede interpretarse como la extracción de árbol de herencia y extracción de los posibles árboles de agregación (a partir de las ligaduras de nombrado), así como para ver la capacidad de gestión que ofrece: atributos que se pueden leer (o leer y controlar).
5.4.2 GDMO (Guidelines for Definition of Managed Objects) La notación GDMO proporciona las pautas para la definición de MIBs. Por ello, se hace uso de unas macros que se definen mediante macros ASN.1. La norma proporciona además normas útiles para diseñar MIBs, como son el agrupamiento de datos, el uso de herencia y la definición de relaciones. Existen una serie de macros GDMO para la definición de: - MANAGED OBJECT - PACKAGES - PARAMETER - NAME BINDING - ATTRIBUTE - ATTRIBUTE GROUP - BEHAVIOUR - ACTION - NOTIFICATION A continuación se especifican las plantillas correspondientes a las macros anteriores, para ello se utiliza la siguiente notación: Notación: MAYUSCULAS: palabras clave [MAYUSCULAS]: palabras clave opcionales : texto para rellenar obligatoriamente [texto]: texto o partes opcionales [texto]*: partes opcionales que pueden aparecer varias veces - comentarios| Alternativas ; fin de package (lote) y de cada constructor supporting productions: amplia información sobre algún elemento definido en las plantillas.
Plantilla de object class (clase de objeto): MANAGED OBJECT CLASS DERIVED from ; CHARACTERIZED BY | [, | ]*; CONDITIONAL PACKAGES PRESENT IF [, PRESENT IF ]*; REGISTERED AS {nº de registro}
Plantilla de Package (lote): PACKAGE [BEHAVIOUR [, *;] [ATTRIBUTES propertylist []* {, propertylist []* }*;] [ATTRIBUTES GROUPS ]* [, ]*]*;] [ACTIONS ]* [,]*]*;] [NOTIFICATIONS ]* [,]*]*;] [REGISTERED AS {nº de registro}]; suporting productions propertylist -> [REPLACE-WITH-DEFAULT] [DEFAULT VALUE value-specifier] [INITIAL VALUE value-specifier] [PERMITTED VALUES type-reference] [REQUIRED VALUES type-reference] [get-replace] [add-remove] value-specifier -> value-reference | DERIVATION RULE GET |REPLACE | GET-REPLACE add-remove -> ADD | REMOVE | ADD-REMOVE
Plantilla de attribute (atributo) ATTRIBUTE DERIVED from ; o WITH ATTRIBUTE SYNTAX ; [MATCHES FOR [EQUALITY | ORDERING | SUBSTRINGS |SET-COMPARISON | SET-INTERSECTION],*;] [BEHAVIOUR [, *];] [PARAMETERS [, *];] [REGISTERED AS {nº de registro}];
Plantilla de behaviour (comportamiento) BEHAVIOUR DEFINED AS ““;
Plantilla de notification (notificación) NOTIFICATION [BEHAVIOUR [, *];] [PARAMETERS [, *];] [WITH INFORMATION SYNTAX [AND ATTRIBUTE IDS ] []*];] [WITH REPLY SYNTAX ; ] REGISTERED AS {nº de registro};
Plantilla de action (acción) ACTION [BEHAVIOUR [, *];] [MODE CONFIRMED;] [PARAMETERS [, *];] [WITH INFORMATION SYNTAX [WITH REPLY SYNTAX ; ] REGISTERED AS {nº de registro};
Plantilla de name binding (ligazón de nombres) NAME BINDING SUBORDINATE OBJECT CLASS [AND SUBCLASSES]; NAMED BY SUPERIOR OBJECT CLASS [AND SUBCLASSES];
6 Red de gestión de las telecomunicaciones (TMN) La TMN (Telecommunications Management Network) proporciona funciones de gestión y comunicaciones para la operación, la administración y el mantenimiento de una red de telecomunicaciones y sus servicios en un entorno de multiples fabricantes [SLO1]. Existieron dos motivaciones básicas para el desarrollo de la arquitectura TMN: una es la creciente heterogeneidad en la tecnología para la construcción de redes de telecomunicación, y la coexistencia de redes analógico-digitales; otra se deriva de las mayores demandas sobre: posibilidad de introducir nuevos servicios, alta calidad de servicios, posibilidad de reorganizar las redes. métodos eficientes de trabajo para operar las redes y competencia entre e mpresas operadoras privadas. La TMN define la relación entre los bloques funcionales básicos constituyentes de la red (sistemas de operación (OS), red de comunicaciones de datos, elementos de red (NE)) a través de interfaces estándares. Introduce el concepto de control de subred (conjunto de elementos de red agrupados según un determinado criterio (p.e. función, provedor,…) y es tratada como una sola entidad por la aplicación de gestión. El dispositivo que implementa la funcionalidad OAM&P de subred, el elemento gestor (EM), simplifica la comunicación entre OSs y NEs. Desde el punto de vista de la arquitectura, el EM es un punto de gestión flexible que une la realización del fabricante con los sistemas de gestión de la red, utilizando las interfaces y modelos de información definidos en la TMN. Las recomendaciones que regulan la TMN son las de la serie M.3XXX de la ITU-T. En estas recomendaciones se definen los siguientes modelos y arquitecturas: - Arquitectura física: estructura y entidades de la red. - Modelo organizativo: niveles de gestión. - Modelo funcional: servicios, componentes y funciones de gestión. - Modelo de información: definición de recursos gestionados. Las recomendaciones para la red TMN son las siguientes: M.3000. Introducción a la recomendación TMN. M.3010. Principios para una red de gestión de telecomunicaciones. M.3020. Metodología para la especificación de la interfaz T MN. M.3100. Modelo de información de elementos de red genéricos. M.3101. Requerimientos para conformar objetos gestionados en TMN M.3100. M.3180. Catálogo de información de gestión TMN.
M.3200. Introducción a los servicios de gestión TMN. M.3300. Capacidades de gestión TMN presentadas en la interfaz F. M.3400. Funciones de gestión TMN. M.xfunc. Servicios de gestión TMN y funciones para la interfaz X. M.xinfo. Identificación de la información que se intercambia vía la interfaz X para diferentes casos de acceso.
Red TMN F Estaciones de trabajo
F
Red de comunicación de datos
X
Q3
Q3
Dispositivos de mediación
Qx
Qx
Q3
Red de comunicación de datos Adaptadores a interfaz Q
6.1 Arquitectura física La arquitectura física de TMN proporciona la manera de transportar la información de los procesos relacionados con la gestión de las redes de telecomunicaciones. Los componentes que forman esta arquitectura física son los siguientes: - sistemas de operaciones (OS) - redes de comunicaciones de datos (DCN) - dispositivos mediadores (MD) - estaciones de trabajo (WS) - elementos de red (NE) - adaptadores Q (QA).
TMN
OS
X/F/Q3
X
F
DCN
WS
G
Q3/F MD X Q3 QA
QX F
DCN X/F/Q3
WS X/F/QX
QX NE
G
QA
NE
Fig. 6.2 Arquitectura física de la TMN
Las interfaces TMN se basan en conceptos del modelo de referencia OSI (ITU-T X.200):
Interfaz Qx: es una interfaz apropiada para pequeños elementos de red que requieran unas pocas funciones OAM utilizadas con gran frecuencia. Utilizada normalmente por los NEs y MDs más complejos. Interfaz Q3: soporta un complejo conjunto de funciones y requiere el servicio de bastantes protocolos para poderlas ofrecer. Para las OSs y los NEs se encuentra especificada en los documentos T1.2041989 y T1.208-1989 de ANSI. Está compuesta por: Modelo de comunicaciones: protocolo CMIP Modelo de información: semántica de datos (MIB’s GDMO).
Interfaz X: soporta el conjunto de funciones para la interconexión de diferentes OSs, ya sea entre entornos de TMNs o no. Requiere de las 7 capas de OSI, según está definido en la normativa T1.217 de ANSI. Los mensajes y protocolos definidos para la interfaz X podrían usarse igualmente en la interfaz Q3. Interfaz F: soporta el conjunto de funciones para la interconexión de estaciones de trabajo con componentes físicos de la red de comunicaciones que contengan las OSF o las MF.
6.2 Modelo organizativo El modelo organizativo (de capas de TMN) definido por la ITU-T establece las siguientes capas de gestión: - gestión comercial - gestión de servicios - gestión de red - gestión de elementos de red - elementos de red. Este modelo va más allá del que se define para una organización de la red desde un punto de vista técnico, puesto que cubre variados aspectos de administración en el sector del marketing y los servicios, requeridos por las empresas proveedoras de servicios. A continuación se describen las funciones relacionadas con la organización de la TMN. Ésta se estructura mediante un modelo de capas:
Capa de gestión comercial: soportada por un sistema de operación comercial (OS) con las siguientes funciones asociadas: - gestión completa y responsabilidad de empresa total - tareas de asignación de objetivos - acción ejecutiva Capa de gestión de servicios : soportada por un sistema de operación de servicios (OS) con las siguientes funciones asociadas: - interfaz con clientes y otras administraciones - interacción con proveedores de servicios - mantenimiento de los acuerdos de nivel de servicio - mantenimiento de datos estadísticos - interacción entre servicios Capa de gestión de red : soportada por un sistema de operación de red (OS) con las siguientes funciones asociadas: - provisión, cese o modificación de las capacidades de la red para el soporte de servicios a clientes. - control y coordinación de todos los elementos de la red con su ámbito y dominio.
Capa de gestión de elementos de red : soportada por un sistema de operación de elementos de red (OS, MD) con las siguientes funciones asociadas: - mantenimiento estadístico, control y coordinación de elementos de la red. Capa de elementos de red : que forma los elementos de la red (NE).
6.3 Modelo funcional El modelo funcional se compone de Bloques de Servicios, Componentes y Funciones de gestión. La idea consiste en descomponer las funcionalidades de mayor a menor nivel en bloques reaprovechables (según las necesidades desde el punto de vista de los operadores).
Servicios de gestión TMN Los servicios de gestión que se definen son del siguiente tipo: - Administración de abonados. Administración de encaminamiento y análisis de digitos. Administración de medidas y análisis de tráfico. Administración de la tarificación. - Gestión de la seguridad de la TMN. Gestión de tráfico. Gestión del acceso de abonado. Gestión de circuitos entre centrales y equipo asociado. Gestión de la red de conmutación. Gestión de equipos en la instalación del usuario. Gestión del servicio controlado por el abonado. Gestión del sistema de señalización por canal común. Gestión de redes inteligentes. Gestión de la TMN. - Administración de instalación del sistema. Administración de calidad de servicio y funcionamiento de la red - Restablecimiento y recuperación. - Gestión de materiales. - Programa de trabajo del personal.
Componentes y funciones de gestión De los muchos componentes que define TMN, un ejemplo de componente del servicio de gestión podría ser: - vigilancia de alarmas.
Funciones de gestión Para el caso del componente de vigilancia de alarmas del citado ejemplo se podrían utilizar las siguientes funciones: - funciones de informes de alarmas - funciones de informes resumidos de alarmas - funciones de criterios de sucesos de alarmas - funciones de gestión de indicación de alarmas - funciones de control de registro de alarmas.
6.4 Modelo de información El modelo de información utilizado en TMN es el definido por el interfaz Q3 en la semántica de datos (MIBs GDMO). A continuación se muestra en la figura 6.3 adjunta un esquema con los niveles de estructura de protocolo del punto de referencia Q3.
Aplicación de gestión ASE específica de gestión FTAM
Nivel 7
CMISE CCR ACSE
ROSE
ACSE
Nivel OSI de presentación
Nivel 6
Nivel OSI de sesión
Nivel 5
Nivel OSI de transporte Subred 1 X25
Nivel 4 Subred 2 802.3
Nivel 1-3
CMISE: servicio asociado al protocolo CMI FTAM: gestión y acceso para la transferencia de ficheros ROSE: elemento de servicio de operaciones remotas ACSE: elemento de servicio de control de asociaciones CCR: recuperación, concurrencia y entrega.. Fig. 6.3 Esquema de capas del interfaz Q3
Los niveles 1 a 3 del interfaz Q3 vienen definidos por el estándar Q.811 que especifica diversas configuraciones de acceso: - CONS1: Para redes X.25 sobre redes públicas de datos. - CONS2: RDSI canal D. - CONS3: RDSI canal B. - CONS5: Protocolo MTP del SS7. - CONS6: X.25 sobre LANs. - CLNS1: Red Ethernet. - CLNS2: X.25 con protocolo ISO/IP.
Para los niveles altos, se utiliza la recomendación Q.812 que define dos tipos de perfiles de protocolo: perfiles para servicios de tipo transacción y perfiles para servicios de tipo transferencia de ficheros. El nivel de aplicación suele cubrirse mediante el protocolo CMIP.
6.5 Implementación física de las funciones de la TMN La implantación física de sistemas de gestión ha seguido una progresión con el tiempo desde sistemas centralizados (sistemas de operaciones con toda la inteligencia y elementos de red sin inteligencia) a sistemas distribuidos (red de sistemas de operación con inteligencia distribuida, más SNCs centros de gestión de la subred, más elementos de red inteligentes). Aplicaciones de gestión de servicio
MIB
M
OS de servicio CPN
DUA OS de red CPN
OS de servicio PN
A
MIB A
M
A
MIB M A
DUA M DSA
DSA
A MIB
DSA
OS de servicio PN
DUA M
OS A de red PN Aplicaciones
de gestión de red
MIB
OS de red PN
MIB OS de servicio CPN
OS de red CPN
Directorio
DSA
M
A M DUA
M
M
M
Aplicaciones de gestión de red
Aplicaciones de gestión de servicio
A Aplicaciones de gestión de red
MIB
OS A de red PN Aplicaciones
de gestión de red
MIB
Fig. 6.4 Esquema de sistemas de gestión de red y servicios
La estrategia de diseño de una TMN depende en gran medida de la topología y las posibilidades de las redes de telecomunicaciones (TNs), que la TMN deberá gestionar. La aproximación tradicional para proporcionar comunicaciones entre NEs y que los soporten los OSs es diseñar una TMN dedicada. Sin embargo, con los modernos NEs inteligentes, y la diversidad de caminos necesaria para proporcionar robustez a la red frente a fallos, esta aproximación no es la más económica. En la figura 6.4 se representan unos sistemas de gestión de proveedores de servicio privados y públicos (en la parte superior) que gestionan sistemas de operaciones de operadores de red (parte inferior). Se observan las correspondientes interacciones entre gestores y agentes de cada sistema de operación y con las bases de datos de gestión (MIBs) de los equipos. También se observa un sistema
7 Áreas funcionales de gestión Se puede definir la gestión de red como la planificación, la organización, la supervisión y el control de elementos de comunicaciones para garantizar un adecuado nivel de servicio, y de acuerdo con un determinado coste. Las recomendaciones de la OSI, posteriormente recogidas por la ITU, definen las siguientes áreas funcionales para la gestión de red:
Supervisión y fallos: conjunto de facilidades que permiten la detección, aislamiento y corrección de una operación anormal. Configuración: facilidades que permiten controlar, identificar, recoger y proporcionar datos a objetos gestionados, con el propósito de asistir a operar servicios de interconexión. Contabilidad: facilidades que permiten establecer cargos por el uso de determinados objetos e identificar costes por el uso de éstos. Prestaciones: facilidades dedicadas a evaluar el comportamiento de objetos gestionados y la efectividad de determinadas actividades. Seguridad: aspectos que son esenciales en la gestión de red y que permiten proteger los objetos gestionados.
Sistema de red Políticas de gestión
Control Gestores Interpretan
Monitor
Recursos
Fig. 7.1 Flujo de información de gestión
El esquema de funcionamiento que sigue un sistema de gestión (Figs. 7.1 y 7.2) parte de las mediciones que se realizan de los recursos de la red a partir de los agentes que los mismos nodos contienen. Estos nodos, a través de sus agentes, proporcionan la información a los gestores de la red. Los gestores, a partir de los parámetros definidos en sus políticas de gestión, actúan sobre la red mediante mensajes de control sobre los agentes de los nodos, optimizando el funcionamiento a través de cambios de configuración, etc. Este control realizado sobre la red modifica las condiciones del tráfico y el ciclo se repite realizando nuevas mediciones sobre los recursos.
El esquema de funcionamiento general de una plataforma de gestión puede verse en la figura 7.3. En este esquema, el usuario a través de una interfaz unificada tiene acceso a la información procedente de diversas aplicaciones de gestión (gestores). Esto se requiere así puesto que la diversidad de elementos de red procedentes de diferentes fabricantes junto con la enormidad de funciones de gestión definidas por los estándares aconseja el procesado en paralelo.
Interfaz a usuario unificado Presentación de información de gestión de red a los usuarios
Aplicación de gestión de red Elemento de aplicación
Aplicación de gestión de red Elemento Elemento de aplicación de aplicación
Servicio de transporte de datos de gestión
Módulo de acceso MIB
MIB
Pila de protocolos de comunicaciones
Redes gestionadas
Fig. 7.3 Modelo de referencia de un sistema de gestión de red
Los elementos de aplicación corresponden a funciones diferentes que son aprovechables por las diferentes aplicaciones. El servicio de transporte y las pilas de protocolos implementadas suelen ser también de tipo variado dada la complejidad de interconexión de redes que forman los sistemas de comunicaciones actuales.
7.1 Gestión de fallos La gestión de fallos se ocupa del conjunto de facilidades que permiten la detección, aislamiento y corrección de una operación anormal. El determinar el máximo de información sobre los fallos es el elemento fundamental para su buena gestión. La información de fallos debe permitir detectarlos y aislarlos. Los fallos: se detectan normalmente ante cambios de estado en los dispositivos.
Estatus y supervisión de red
Usuario
Monitorización
Alarmas de dispositivos
Etiquetado de problemas
Seguimiento de problemas dinámico
no
conocido?
sí
Unir a problemas conocidos
Back-up, reconfiguración
Back-up y reconfiguración
Determinación problema
Diagnosis y reparación
conocido? no Diagnosis y reparación
sí Implementar solución
Monitorizar y verificar correción no
Recuperación por la red
conocido? sí Restauración Actualizar bases de datos Distribuir informes Fin
Fig. 7.4 Secuencia de operaciones realizadas en un sistema para corregir fallos
Existen una serie de problemas relacionados con la detección de fallos. Por ejemplo, fallos no observables que sólo permiten detectar efectos laterales, o bien el caso de fallos inciertos, en los que la información sobre el fallo puede no ser fiable en cuanto a su fuente.
Por otra parte, también existen una serie de problemas en la fase correspondiente al aislamiento de fallos. Puede darse el caso de una detección de múltiples fallos por una sola causa e incluso el caso de detección de fallos por múltiples causas. En la figura 7.4 se puede observar el proceso seguido por una aplicación de gestión de alarmas en su recorrido hasta determinar correctamente la causa concreta del fallo y el porqué de las alarmas generadas. Como ejemplos de tecnologías que permiten tratar los fallos de conectividad en redes TCP/IP existen programas como PING o TRACEROUTE. Para la detección de fallos se puede utilizar el programa PING, que realiza un sondeo periódico del recurso mediante el protocolo ICMP (echo request). Permite también comprobar el tiempo de respuesta. Para el aislamiento de fallos se puede utilizar el programa TRACEROUTE que permite ver la ruta que siguen los paquetes hacia un nodo y que está basado en el parámetro Time To Live de IP.
7.1.1 Identificación de fallos en redes de comunicaciones En este apartado se presenta un análisis introductorio a la identificación de fallos en redes de comunicaciones. El proceso de gestión de fallos se caracteriza por los siguientes tres pasos: 1) Correlación de alarmas. 2) Identificación de fallos. 3) Pruebas de localización. En los procesos 1 y 2 se correlacionan los fallos observados, o las alarmas enviadas, y se proponen varias hipótesis de fallo a fin de identificar el fallo. Posteriormente, cada una de las hipótesis propuestas se examina para localizar el fallo de una forma más precisa. Existen muchos métodos para llegar a la obtención del fallo en una red. En este caso se presenta una posible metodología basada en el análisis de probabilidades. Se define un objeto como parte de la red que tiene una existencia distinta y separada. A partir de ahí, un grafo dirigido G = (E,D) es un modelo del sistema donde E equivale a los objetos terminales activos y D son las alarmas. Un par (ej, ei) perteneciente a D, denota que un fallo en ei tiene efecto en ej, esto es, ej es dependiente de ei. A cada vértice ei se le asigna un peso pi que es la probabilidad de que el objeto falle independientemente del estado (falle o no falle) de cualquier otro objeto de terminal activo dependiente de éste. Así, a cada par dirigido (ej, ei) se le asigna un peso pji, especificando la dependencia entre las entidades que conecta. Esto es: pji = P(ej falle / ei falle) Cada alarma ai emitida por ei se caracteriza por un dominio de alarmas D(ai) definido como el conjunto de objetos que podría haber causado la alarma. Se define también un cluster de alarmas, como el conjunto de alarmas cuyos dominios interseccionan unos con otros.
Supongamos que ei emite una alarma ai. Asociaremos esta alarma con todos los objetos ej en el gráfico de dependencias con pesos de dependencia pij > W, donde W es un parámetro. Escogiendo diferentes valores de W se pueden crear diferentes asociaciones de entidades con una alarma dada. El problema de encontrar el D(ai) es una variación del problema de fuente única. En este caso, se encuentra el camino de coste mínimo desde el vértice de una fuente en un gráfico a todos los otros vértices en el gráfico. Por ejemplo, mediante el algoritmo de Dijkstra. En este algoritmo se asocia el coste de un camino al producto de pesos pij, donde el problema consistiría en encontrar el camino de coste máximo, que fuera también mayor que W. Ahora bien, si en lugar de adoptar pij escogemos log(pij) como coste del camino y este coste es menor que -log(W), se puede utilizar directamente el algoritmo de Dijkstra de coste de camino mínimo. Como ejemplo, sea la siguiente red de la figura 7.5.
L1
A
B
L4
L3
L2
C
Fig. 7.5 Esquema de conexiones de una red
A partir de la red anterior, se puede construir un gráfico de dependencias, tal como se muestra en la figura 7.6.
7.2 Gestión de configuración La gestión de configuración es un conjunto de facilidades que permiten controlar, identificar, recoger y proporcionar datos a objetos gestionados con el propósito de asistir a operar servicios de interconexión. Entre las tareas relacionadas se puede destacar la definición de información de configuración en los recursos, la modificación de las propiedades de los recursos, la definición y modificación de relaciones entre los recursos, la inicialización y terminación de servicios de red o bien la distribución de software.
7.3 Gestión de prestaciones Representan un conjunto de facilidades dedicadas a evaluar el comportamiento de objetos gestionados y la efectividad de determinadas actividades. Entre los indicadores de prestaciones se pueden definir los que están orientados al servicio, como la disponibilidad, el tiempo de respuesta, y la fiabilidad. En cambio, otros indicadores están orientados a la eficiencia, como el throughput (caudal, flujo) o la utilización. En la figura 7.7 puede observarse el proceso seguido por una aplicación de gestión de prestaciones o rendimientos hasta encontrar unos parámetros de funcionamiento óptimos en la red. Violaciones de los niveles de servicio
Peticiones de servicio con parámetros específicos
Evaluaciones de prestaciones
Monitorizacion de red y seguimiento histórico Ficheros con datos históricos
no
Nivel de servicio adecuado? sí Problema conocido? no
7.4 Gestión de tarificación La gestión de tarificación son un conjunto de facilidades que permiten establecer cargos por el uso de determinados objetos e identificar costes por el uso de éstos. Se puede hablar de criterios sobre tarificación. Entre ellos se pueden destacar: localización geográfica, distancia desde nodo central, zonas temporales (día/semana), descuentos por volumen, precio por paquete, códigos de área, rango de extensión por voz, email, etc, identificación de equipos orientados a datos, etc.
7.5 Gestión de seguridad La gestión de seguridad está relacionada con la generación, distribución y almacenamiento de claves de cifrado, información de passwords (contraseñas) o bien información de control de acceso y autorización que debe mantenerse y distribuirse. Es decir, proporciona facilidades para incorporar mecanismos de seguridad contra los ataques a las comunicaciones, como protección contra interrupción del servicio, captura no autorizada de información, modificación de información o suplantación de entidad.
8 Funciones de gestión de la red de señalización Las funciones de gestión utilizadas en el SS7 se refieren a procedimientos de control de disponibilidad que permiten reconfigurar la red para desviar el tráfico y así poder subsanar mejor los inconvenientes de fallos en nodos y/o enlaces. Además existen los controles de congestión específicos que permiten evitar en lo posible los bloqueos de la red y las posibles pérdidas de información correspondientes. Dado que los enlaces de señalización se diseñan para que el tráfico que soporten sea menor que la capacidad del enlace (40%), las situaciones de congestión se producen generalmente debido a caídas de enlaces o nodos [RUS1].
8.1 Controles de flujo MTP en la red de señalización Las funciones de control de flujo MTP pertenecen al nivel 3. Las funciones atribuidas al nivel 3 pueden dividirse en dos grandes grupos: funciones de manipulación de mensajes de señalización y funciones de gestión de red de señalización, descritas en la recomendación Q.701. Las funciones de manipulación de mensajes de señalización conciernen al encaminamiento, la discriminación y la distribución de mensajes de acuerdo con el estatus actual de los nodos y enlaces de la red, estén disponibles, no disponibles o congestionados. En los siguientes apartados se hará enfasis en las funciones de gestión de red de señalización, que se usan para reencaminar tráfico a otros enlaces cuando los nodos son inalcanzables, y que pueden dividirse en gestión de enlaces de señalización, gestión de tráfico de señalización y gestión de rutas de señalización (recs. Q.701, Q.704). Los controles de flujo MTP se diferencian en que pueden seguir las recomendaciones internacionales o bien dos opciones dentro de las recomendaciones de ámbito nacional. En la red internacional, las prioridades de congestión de mensajes no se asignan dentro del MTP y cualquier decisión para descartar mensajes se toma únicamente a nivel de UP (el descarte podría ser en el nivel MTP sólo en caso de falta de memoria física). En la opción nacional con múltiples niveles de congestión y prioridades de congestión, el MTP reconoce múltiples prioridades de congestión y basa sus decisiones de descarte en esas prioridades, de forma separada, además de cualquier descarte que pudiera haber en el nivel UP. En la opción nacional con múltiples niveles de congestión, pero sin prioridades de congestión, el descarte sólo ocurre en el nivel UP, como en el caso de control internacional.
8.1.1 Gestión del enlace de señalización Las funciones de gestión de los enlaces de señalización son controlar localmente los enlaces de señalización, es decir, activando y desactivando enlaces, y proporcionar la información de estatus sobre la disponibilidad de enlaces locales a la función de gestión de tráfico según la recomendación Q.704. Tiene funciones de soporte de información y no interviene directamente en el control de congestión. Los procedimientos de gestión de enlaces requieren del uso de funciones del nivel 2 Message Transfer Part (MTP) o SAAL para informar de fallos y del estatus de los enlaces a un punto de señalización adyacente. Se definen tres funciones para la gestión de enlaces: - activación de enlace - restauración de enlace - desactivación de enlace Cuando se activa un enlace por primera vez, el nivel 3 direcciona al nivel 2 para empezar el procedimiento de alineamiento y emplazar el enlace en servicio. Antes que puedan enviarse realmente los mensajes, el gestor del enlace también envía mensajes de test sobre el enlace para asegurar la integridad de éste. Una vez se ha activado el enlace y es considerado en servicio, se envía un mensaje SLTM (Signaling Link Test Message) que es contestado con un SLTA ( Signaling Link Test Acknowledgment ). En caso de fallo del enlace, que se determina e informa por parte del nivel 2, se procede a la restauración del enlace. La desactivación se realiza cuando se encuentra al enlace en error y requiere ser emplazado para un alineamiento. Para ello, previamente se desvía el tráfico a otros enlaces y posteriormente se desconecta.
8.1.2 Gestión del tráfico de señalización La gestión de tráfico de señalización realiza el desvío y el control de flujo de tráfico en respuesta a fallos de nodo/enlace y a congestión (Q.704). En el caso de no disponibilidad de enlace/ruta o restricción de ruta, las decisiones de encaminamiento se basan en la información de estatus recibida desde las funciones de gestión de rutas/enlaces de señalización. El objetivo es mantener la conectividad a todos los destinos requeridos. Los mensajes de gestión de tráfico no se propagan a través de la red de señalización SS7, sino que lo hacen punto a punto por la red troncal. La gestión de tráfico proporciona los mecanismos para gestionar el desvío del tráfico debidos a: - no disponibilidad del enlace de señalización - disponibilidad del enlace de señalización - no disponibilidad de la ruta de señalización - disponibilidad de la ruta de señalización - restricción de la ruta de señalización - disponibilidad del punto de señalización. Tipos de mensajes involucrados: - Changeover: desvía el tráfico fuera del enlace caído.
- Changeback: se utiliza cuando un enlace caído es restaurado. - Emergency changeover: cuando se inicia un procedimiento de changeover pero el buffer de transmisión no puede leerse. - Forced rerouting: se inicia cuando una ruta a un destino específico no está disponible. - Controlled rerouting: procedimiento para restaurar el tráfico hacia la ruta más favorable, caso de que haya sido previamente restringida. - MTP restart: restablecimiento de un punto de señalización después de un aislamiento previo del resto de la red. - Management inhibiting: usado por la gestión del enlace para bloquear un enlace de señalización desde el nivel 4. - Flow Control: en el nivel 3, se utiliza para controlar el flujo de los mensajes UP desde la fuente. Por ejemplo, el cambio de enlace ( Link Changeover ) es una función de gestión del tráfico de señalización consistente en el desvío de tráfico, en el caso de caída de enlace o de nodo, a uno o varios enlaces. Se describe en la recomendación Q.704. Existe el procedimiento análogo para recuperar la situación inicial de la red (Changeback ), descrito en la misma recomendación.
8.2 Control de flujo de tráfico de señalización Se trata de un control de flujo integrado en el nivel MTP para regular el exceso de tráfico de control MTP. Cuando se detecta congestión, se advierte a los usuarios para que regulen la carga de señalización en los puntos de origen del tráfico. La razón de este control es que los enlaces de señalización de 64 Kbps podrían ver excedida su capacidad por un exceso de tráfico. El objetivo consiste en proteger las colas del nivel 2 y por tanto los enlaces de señalización. Los controles MTP operan principalmente a nivel 3 MTP. Los procedimientos describen como los puntos de conmutación (SP) responden a la indicación de congestión de un conjunto de rutas ( Transfer Controlled Message, TFC). Los UP en las fuentes SP son informados de los destinos afectados por medio de las primitivas de indicación de congestión MTP-ESTATUS enviadas desde el nivel 3 MTP de la función de gestión de tráfico de señalización a todos los UP conectados. Los UP toman la decisión de reducir el tráfico de señalización hacia el destino afectado, en una o en varias de las rutas que lo interconecten. Los controles de flujo MTP se diferencian, tal como se ha descrito anteriormente, en que pueden seguir las recomendaciones internacionales o bien dos opciones dentro de las recomendaciones de ámbito nacional (recs. Q.704); esto es: - controles internacionales - opción nacional con prioridades de congestión - opción nacional sin prioridades de congestión.
8.2.1 Gestión de rutas de señalización El objetivo de la gestión de rutas de señalización es asegurar que los SP estén informados en cada momento de la disponibilidad de rutas en la red. La gestión de rutas no pertenece a un enlace en concreto (como la gestión de tráfico) sino que afecta por entero a un punto de señalización. La disponibilidad o no de las rutas, las restricciones de tráfico, etc, se comunican a la fuente SP de la ruta
de señalización por medio de procedimientos y mensajes explícitos como: TFP, TFA, o TFR. En caso de congestión, se usa el mensaje TFC. Procedimiento TFC
En el enlace congestionado, la función de gestión de rutas de señalización usa el procedimiento TFC para informar a los nodos fuente acerca del estatus de congestión de las rutas de señalización y los enlaces afectados, a fin que éstos puedan reducir el tráfico hacia los enlaces de acuerdo con los mecanismos de control de flujo de tráfico. El mensaje TFC informa del estatus de congestión de la ruta a los nodos fuente. Los procedimientos para la determinación de congestión, o estado de descarte en los enlaces de la red, y cómo estos estados son usados por la función de gestión de rutas, son descritos en Q. 704. Igualmente puede diferenciarse, tal como se ha descrito anteriormente, en que pueden seguir las recomendaciones internacionales o bien dos opciones dentro de las recomendaciones de ámbito nacional, esto es: - controles internacionales - opción nacional con prioridades de congestión - opción nacional sin prioridades de congestión. En la red internacional, las prioridades de congestión de mensajes no se asignan dentro del MTP y cualquier decisión para descartar mensajes se toma únicamente a nivel de UP (el descarte podría ser en el nivel MTP sólo en caso de falta de memoria física). En la opción nacional, con múltiples niveles o estados de congestión (S<=3) y prioridades de congestión (N<=3), el MTP reconoce múltiples prioridades de congestión y basa sus decisiones de descarte en esas prioridades, de forma separada, además de cualquier descarte que pudiera haber en el nivel UP. En la opción nacional con múltiples niveles de congestión, pero sin prioridades de congestión, el descarte sólo ocurre en el nivel UP, como en el caso de control internacional. El uso de direcciones de cluster en la red permite utilizar mensajes de cluster de gestión de rutas. La ventaja de la gestión de rutas de cluster es que un sólo mensaje puede enviarse para direccionar a un grupo entero de puntos de señalización, más que a puntos de señalización i ndividuales. Para la gestión de rutas normal pueden utilizarse los siguientes mensajes: - Transfer-prohibited (TFP) - Transfer-allowed (TFA) - Transfer-restricted (TFR) - Transfer-controlled (TFC) - Signaling-route-set-test (RST) - Signaling-route-set-congestion-test (RCT) Para la gestión de rutas de cluster existen los siguientes mensajes: - Transfer-cluster-prohibited (TCP) - Transfer-cluster-allowed (TCA) - Transfer-cluster-restricted (TCR) - Cluster-route-set-test (CRST)
Dentro de los controles de disponibilidad de red, las recomendaciones de la serie X.700 definen diversos procedimientos para reconfigurar la red en caso de fallo: entre ellos están los de transferencia prohibida y transferencia restringida. Transferencia prohibida ( Transfer Prohibited, TFP) El procedimiento de transferencia prohibida se utiliza hacia nodos adyacentes para desvío de tráfico desde nodos funcionalmente no disponibles. Para dar a conocer la información de prohibición, se envían mensajes TFP a los nodos adyacentes. El procedimiento actúa tanto para nodos como para rutas no disponibles. Una vez desviado el tráfico hacia otras rutas, si se recupera el enlace o la ruta, puede restaurarse la red hacia la situación original si se reenruta el tráfico a su ruta original mediante un procedimiento de transferencia disponible ( TransFer Available, TFA). El procedimiento se describe en la recomendación Q.704. Transferencia restringida ( TransFer Restricted , TFR) El procedimiento de transferencia restringida se utiliza hacia uno o más nodos adyacentes para el desvío de tráfico hacia rutas alternativas (si es posible) en respuesta a una situación de congestión de tráfico. La función de gestión de rutas locales utiliza el mensaje TFR para llevar la indicación a los nodos adyacentes. A la llegada del mensaje, los nodos responden con con un reencaminamiento controlado del tráfico hacia una ruta no congestionada. Una vez se ha descongestionado la ruta original, se emplea un procedimiento TFA con el envío de los mensajes correspondientes a los nodos adyacentes para recuperar la ruta original. El procedimiento se describe en la recomendación Q.704.
8.3 Control nodal MTP Este control sirve para proteger a la red de congestión nodal (en SPs o STPs), posiblemente a raíz de procesados internos en el nodo o de comunicaciones entre procesadores. Las causas pueden ser por limitaciones de capacidad en los enlaces o por fallos en nodos de la red que pueden dar a lugar a cuellos de botella y congestiones en el tráfico. El control nodal puede realizarse a varios niveles del protocolo de señalización. Control nodal de nivel 2 MTP
El control nodal a nivel 2 de MTP se basa en la recomendación Q.703. Los controles de flujo a nivel 2 se basan en un control on/off realizado en respuesta a congestión nodal en SPs o STPs. Control de flujo El mecanismo de control de flujo a nivel 2 se activa cuando se detecta congestión en el extremo final del enlace de señalización. La notificación sobre la detección de congestión se obtiene mediante el envío periódico de LSSUs (Link Estatus Signal Units) con la indicación (“B”) de ocupado al extremo del enlace. En el extremo, se prueba la duración de la congestión; si persiste, se deja el enlace fuera de servicio y se notifica al nivel 3 de gestión de red de lo sucedido. Bloqueo de procesador La recomendación Q.703 cubre además de los mecanismos de control de flujo los bloqueos de procesador. Éstos se producen cuando las funciones del nivel 2 no pueden transferirse al nivel 3, o el nivel 3 no puede acceder al nivel 4, etc. En este caso se envía un flujo continuo de LSSUs con la indicación de estatus PO ( Processor Outage) desde el extremo cercano, donde ocurre el bloqueo, al extremo lejano. Por otra parte, las MSUs recibidas por el extremo cercano se desechan. El extremo
lejano pasa de enviar MSUs a enviar FISUs. En el momento en que se restablece el procesador, el extremo cercano pasa a enviar MSUs y el extremo lejano pasa a reestablecer la comunicación. Control nodal de nivel 3 MTP
La congestión nodal implica que es el propio nodo quien provoca un cuello de botella en la transmisión. El caso de congestión nodal SP o STP se trata en las recomendaciones Q.700 y Q.704, siendo la detección dependiente de la implementación. Se aplican los mismos mecanismos que para la congestión de rutas de señalización. UP no disponible En el caso de que un UP remoto sea designado como no disponible (inalcanzable), se para el tráfico hacia este UP desde la fuente UP (Q.704). El UP inalcanzable (estado UPU) se señaliza a la fuente SP mediante un mensaje UPU retornado desde donde se ha detectado este estado. El MTP en la fuente SP pasa la información UPU al UP afectado vía la primitiva MTP-ESTATUS, identificando el destino afectado (Q.701) y UP. Se espera que la fuente UP pare o reduzca la generación de mensajes hacia el UP de forma apropiada. La recuperación del UP remoto podría tratarse también desde el punto de vista de gestión de fallos y alarmas. Por el momento (recs. 1992), se deja a criterio del UP examinar la disponibilidad. UP en congestión En las recomendaciones Q.704 de 1992 se afirma que el MTP no mantiene información de estatus acerca de la disponibilidad de UP’s remotos. Controles UP de nivel 4
Pueden considerarse los controles de flujo y los bloqueos en UP. Controles de flujo UP Los controles de flujo UP han de responder a la detección de congestión en el protocolo MTP, regulando el tráfico enviado a los destinos congestionados. Tanto el TUP (Q.724) como el ISUP (Q.764) tienen recomendaciones similares para el tratamiento del control de flujo en UP, por lo que se consideran de forma conjunta.
Cuando el MTP en la fuente SP recibe una indicación de congestión, pasa esa información al UP vía la primitiva de MTP-ESTATUS (Q.701), que identifica el destino afectado y el estatus de la congestión si se utilizan múltiples niveles de congestión (p.e. opción nacional). Entonces, el UP reduce el tráfico al destino afectado de forma progresiva. Las bases para el descartado por parte de los controles UP es un tema de implementación sujeto a múltiples variantes de diseño. Los controles UP podrían actuar independientemente de cualquier control en MTP, si bien en determinados casos (p.e. una opcion nacional) podría haber redundancias o malfuncionamiento. Bloqueo UP El bloqueo en TUP se describe en la recomendación Q.724. Los UPs en nodos adyacentes son informados por el control de flujo del usuario y responden parando o reduciendo el tamaño del circuito hacia el nodo afectado.
8.3.1 Controles SCCP El protocolo SCCP se describe en las recomendaciones Q.711 hasta la Q.716. El SCCP, junto al MTP, proporcionan las funcionalidades del nivel 3 de la red. De las cuatro clases de servicio definidas 0 a 3, sólo la clase 3 proporciona control de flujo, vía un mecanismo de ventana usando créditos. Cuando el SCCP recibe una indicación de congestión desde el MTP vía una primitiva MTP-ESTATUS, hace un broadcast de esa información localmente a los subsistemas SCCP concernientes (Q.714). Las recomendaciones no especifican qué es lo que realizan los subsistemas como respuesta, por lo que se deja este mecanismo para libre implementación por parte del fabricante.
8.3.2 Controles de congestión automáticos Los controles de congestión automáticos ( Automatic Congestion Control, ACC) se usan cuando una aplicación de procesamiento de conmutación de llamadas es sobrecargada (Q.724 en TUP, Q.764 en ISUP y Q.542). Definen el uso que hace la red de señalización en respuesta a la congestión detectada en la aplicación de procesado de la llamada. En el caso de TUP se pueden utilizar un par de niveles de congestión para advertir a los nodos adyacentes y así reducir la tasa de llamadas dirigida al nodo congestionado. Si se utiliza el protocolo ISUP, se añade un parámetro a los mensajes generados por el nodo de conmutación. Este parámetro indica el nivel de congestión (1 ó 2) y a su recepción los nodos adyacentes reducen el tráfico hacia el nodo afectado. ISUP también define un mensaje de sobrecarga específico en la rec. Q.763 como una opción nacional. En Q.764, el protocolo ISUP define una opción nacional para reducir el tráfico en caso de un bloqueo de troncales temporal (TTB) en lo que parece ser una función de protección de servicio.
8.4 Gestión de fallos La secuencia de procedimientos que ocurren desde que se detecta un fallo en un enlace, de un conjunto de dos enlaces conectados a un punto de señalización, es la siguiente: Detección desde el punto de señalización de la caída de uno de sus enlaces. Inicio del Link Status Signal Unit LSSU por el nivel 3 de la capa de gestión. La gestión de la capa de nivel 3 instruye a la de nivel 2 enviando un LSSU con el estatus de procesador bloqueado (Processor Outage) al enlace de señalización. Cuando se recibe el mensaje, mantiene todas las MSUs (Message Signal Units) para prevenir la transmisión sobre el enlace caído. La gestión del enlace a nivel 3 pasa ahora al proceso de recuperación del enlace. Pone el enlace fuera de servicio, que inicia cambiando el código del enlace y comenzando el procedimiento de Changeover . Se desvía el tráfico. El procedimiento de Changeover es invocado por la gestión de tráfico del nivel 3. Todos los mensajes no reconocidos en el buffer de transmisión del enlace al punto de señalización se transfieren a un nuevo enlace. Cuando se ha completado este procedimiento, se envía el mensaje de Changeover al punto de señalización proporcionando el código de señalización (SLC). Cuando se recibe por el punto de señalización el mensaje, éste transfiere las MSUs que están todavía en el buffer de transmisión del enlace fallido al nuevo enlace. Entonces, se retransmiten las MSUs sobre el nuevo enlace en ambas direcciones.
Para reconocer la finalización de la transferencia del buffer y la recepción del mensaje de Changeover, el punto de señalización envía el mensaje de Acknowledgement Changeover al otro punto de señalización. Esto significa que ahora puede desviarse el tráfico. Una vez que los mensajes han sido retransmitidos y los buffers han sido retransmitidos, el procedimiento de recuperación de gestión del enlace puede empezar. Se empieza enviando el mensaje de LSSU de alineamiento normal sobre el enlace fallido y empezando el procedimiento de alineamiento. Todos los timers y contadores son puestos a cero. Durante el desvío del tráfico, el problema del corte del procesador se ha trasladado al nuevo enlace, de forma que ambos enlaces son inaccesibles al punto de señalización. La gestión del tráfico debe ahora desviar el tráfico fuera de los enlaces caídos y buscar enlaces alternativos.
8.5 Arquitectura de gestión de red de señalización Las recomendaciones descritas se basan en la congestión de la red de señalización y en sus controles, dejando aparte los controles de la parte de aplicación de procesamiento de la llamada. Es decir, la parte UP se describe como red de señalización. Está aún poco desarrollada la relación entre la UP y la parte de aplicación de procesamiento de la llamada (AP). Sólo se han empezado a utilizar técnicas como el tema UPU. Cada fabricante resuelve de forma libre la relación o interfaz entre UP y conmutación de llamada (AP) en caso de congestión o fallo. El conjunto de los mecanismos de gestión propuestos permite garantizar únicamente un buen comportamiento de la red en entornos locales. En el caso de que se produzcan fallos en diversas partes o nodos de la red, la restauración del sistema puede ser compleja o incluso llegar a ser imposible. Los mecanismos de gestión propuestos tampoco permiten la descongestión en el caso de producirse bucles sin fin en la red. Por esto es recomendable el uso de una red de gestión (TMN) específica, que podría basarse en el protocolo CMIP o bien en técnicas de desarrollo más reciente como es CORBA.
9 Gestión de redes virtuales El uso cada vez más frecuente de elementos de red que actúan a niveles superiores está permitiendo un auge de la gestión basada en la configuración de redes virtuales para obtener mejores rendimientos sobre el tráfico circulante entre los nodos.
9.1 Introducción Una VLAN puede entenderse como un grupo de terminales de usuario, quizás en múltiples segmentos de LAN físicos, que no están restringidos por su localización física y que pueden comunicarse como si estuvieran en una LAN en común. Una VLAN conforma un único dominio de broadcast , lo que permite que cada miembro de esa VLAN reciba paquetes procedentes de otros miembros de esa VLAN y no paquetes de grupos del exterior. No se requiere routing dentro de una VLAN y todos los cambios, movimientos, adiciones, etc. se realizan mediante software.
9.2 Estándares de VLAN Aparte de las múltiples soluciones propietarias implementadas, existen dos estándares propuestos por el IEEE para redes VLAN. Estos son el IEEE 902.10 y el IEEE 802.1Q. Otros estándares han sido propuestos para emular LANs bajo ATM, como los del ATM Forum. Otros provienen del IETF, comenzando por el Spanning Tree, IEEE 802.1D que es un estándar para el control de puentes, conmutadores y el estándar IEEE 802.1p que añade importantes funcionalidades de filt rado en VLAN.
9.3 Gestión de red en VLAN El despliegue de redes conmutadas/VLANs requiere de nuevas perspectivas para la introducción de una gestión de red adecuada. Existen un par de estándares de gestión de red ampliamente utilizados para VLANs: son el protocolo SNMP y el RMON. Ámbos se consideran complementarios y permiten que la escalabilidad y flexibilidad de funcionamiento que presentan las VLAN pueda resolverse adecuadamente mediante las arquitecturas jerárquicamente distribuidas que utilizan los entornos SNMP/RMON. En entornos basados en LANs, RMON ayuda a los gestores de red a determinar cómo segmentar mejor sus redes y hacer un seguimiento de quién está comunicando con cualquier otro. A partir de la
emisión de eventos especiales, un gestor de red puede identificar los usuarios que utilizan más ancho de banda. Estos usuarios pueden entonces ubicarse en sus propios segmentos de red para minimizar el impacto a otros usuarios.
9.3.1 Seguridad en VLAN La dificultad de obtener sistemas seguros basados en redes VLAN se deriva del hecho de que se trata de estándares de comunicación abiertos y de tener que proporcionar seguridad distribuida. Los estándares de seguridad se basan en los protocolos ISAKMP y Oakley que son competidores para establecer una gestión de claves en Internet y que son considerados por el grupo de trabajo Ipsec (IP Security) del IETF. Otra solución de seguridad distribuida fue presentada por Livingston Enterprises y se denomina Remote Authentication Dial-in User Service (RADIUS). Radius soluciona los problemas asociados con encontrar los requerimientos de seguridad de computación remota. La seguridad distribuida separa la autentificación de usuario y la autorización del proceso de comunicaciones y crea una única posición central para datos de autentificación de usuario.
10 Gestión de la red B-RDSI En este capítulo se procede a dar una visión general de este tipo de redes describiendo los modelos de gestión establecidos en la red digital de servicios integrados de banda ancha [MIN1, SCH1]. El modelo establecido de RDSI-BA se basa en la conmutación distribuida a alta velocidad, sin utilizar un control de errores en la red. Se trata de una red de gran flexibilidad, tanto en los anchos de banda disponibles como en las calidades de servicio ofrecidas. Todo ello repercute en una mayor complejidad, tanto en el diseño, como en el software que se debe utilizar, como en la gestión de la red. A pesar de todo es una red de gran eficiencia con capacidad de direccionamiento de llamadas y/o conexiones a uno o varios destinos fijos o móviles. ATM (Asynchronous Transfer Mode) es la clave de la versatilidad de la red: se basa en el envío de un flujo continuo de celdas, tanto en la interfaz usuario-red (UNI) y en los enlaces, como en los nodos de conmutación y/o multiplexación. ATM permite además emplear una única interfaz para diferentes tipos de usuarios con diferentes necesidades de servicio. ATM es un método de comunicación orientado a conexión sin control de flujo ni recuperación de errores, que permite agrupar canales virtuales para configurar un camino virtual. A continuación se describen las capas que conforman la B-RDSI. La capa física (ITU-T I.432) es la encargada del correcto transporte de celdas ATM y de la adaptación al sistema de transmisión (ATM, SDH, G.703). Se descompone en dos subcapas con las siguientes funciones asignadas: una subcapa de convergencia de transmisión (TC), que permite la daptación de la tasa de celdas a la capacidad del sistema de transmisión, generación y verificación del HEC, delimitación de celdas ATM, adaptación a la trama de transmisión (ATM, SDH, G.703) y generación/recuperación de tramas de transmisión. Existe una segunda subcapa de medio físico (PM), que trata aspectos relativos a la correcta transmisión y recepción de los bits sobre el apropiado medio físico, y se ocupa de la conversión electro-óptica si el medio es fibra óptica. La capa ATM se encarga de la conmutación y multiplexación de celdas. Es una capa independiente del medio físico, común para todos los servicios y métodos de transmisión. Tiene las siguientes funciones: controla flujo en UNI (User Network Interface) si se usa el GFC, extrae/añade cabeceras para/desde AAL, también se encarga de cambiar los VCI y/o VPI en conmutadores y cross-connects y finalmente multiplexa/demultiplexa celdas de distintas conexiones (VCIs/VPIs). La capa de adaptación se ocupa de adaptar información de cada clase de servicio al flujo de celdas ATM. Se descompone en las dos subcapas siguientes: una subcapa de convergencia (CS), todavía
dependiente del servicio con las clases A, B, C y D, y una subcapa de segmentación (SAR), que segmenta PDUs en celdas ATM y ensambla celdas para formar PDUs. Finalmente, las capas altas se encargan de ofrecer las 4 clases de servicios definidas por la ITU-T (I211). En la figura 10.1 se especifican los campos de información que conforman la estructura de una celda ATM. Leyenda: GFC: asigna prioridades a teleservicios según la QOS. VPI/VCI: identifican conexión. Asociados a la función de encaminamiento. PTI: identificación de la carga útil. RES: no especificado. CLP: indicación de prioridad de pérdida de celdas (0/1 baja prioridad). HEC: detección y corrección de errores en cabecera. GFC/VPI VP
VPI VC VC
VC
PTI
RES
CLP
HEC (Chequeo errores cabecera) Tipos de celdas
Fig. 10.1 Estructura de celda ATM (5 + 48 bytes)
Plano de gestión Plano de control Protocolos y funciones de capas superiores
Plano de usuario Protocolos y funciones de capas superiores
Relación temporal entre fuente y destino Tasa de bits Modo de conexión
LAN
Fig. 10.3 Tipos de servicios en la red B-RDSI
Las clases de servicio definidas son las siguientes: vídeo de baja calidad con codificación CBR (comprimido a 2 Mbps); vídeo estándar CBR (34 Mbps) o VBR (2 a 10 Mbps); vídeo extendido VBR (10 a 34 Mbps); y, finalmente, vídeo de alta calidad: VBR (70 a 140 Mbps) y CBR (comprimido a 20 Mbps). En cuanto a las capas de adaptación, existen diferentes combinaciones de protocolos CS y SAR que dan lugar a infinidad de protocolos AAL. La ITU-T ha normalizado 4 protocolos: AAL 1 orientado al servicio A; AAL 2 orientado al servicio B; AAL ¾ orientado a servicios C, D y señalización; y, finalmente, AAL 5 con servicios C y D (más simple y eficiente que el a nterior). SB B-ET1
TB TR2
UB TR1
UNI ET2 ó B-ET2
R B-TA
TR2 SB
TR1 TB
UB
Fig. 10.4 Interfaces definidas en B-RDSI
La arquitectura definida en la B-RDSI contiene diversss interfaces siguiendo la misma filosofía que la RDSI de banda estrecha. Existe una interfaz en el punto de referencia R que permite tener conectados equipos sin disponer capacidades de red de banda ancha.
110
Gestión de red
Las interfaces en SB y TB deberan soportar todos los servicios RDSI. Las funciones en TR1 (capa física) son de terminación de línea, de aspectos de transmisión hasta dependencias de usuario y de OA&M. Respecto a las funciones asignadas al TR2 (capa física y superiores), existen las de multiplexación/concentración de tráfico, delimitación de celdas, almacenamiento de celdas ATM, CAC/UPC, manejo de protocolos de conmutación, conmutación de conexiones internas y, finalmente, funciones de O&AM. Respecto a las funciones de transporte de la capa ATM, se puede hablar de canal virtual (VC) y de camino virtual (VP). Es importante definir los siguientes conceptos de cara a su uso posterior: enlace de canal virtual (VCL)/enlace de camino virtual (VPL) son medios de transporte unidireccional entre un punto donde se asigna un VCI/VPI y un punto donde es conmutado (puntos de conmutación); un VCI identifica una conexión (canal virtual) incluida en un VP sobre el UNI o el NNI; un circuito virtual (VCC) es una concatenación de VCLs entre extremos de la conexión donde se genera y procesa la cabecera de las celdas de esa conexión; un trayecto virtual (VPC) es una concatenación de VPLs entre terminadores de VPLs (VPTs) donde se conmutan los VCLs (cambian los VCIs).
10.1 Introducción a la gestión de la red B-RDSI Los niveles de calidad de servicio exigidos en una red de banda ancha (B-RDSI) hacen necesaria la introducción de determinados mecanismos de gestión de red (NMC) que, de forma distribuida, interactúen con los distintos elementos de red tales como los conmutadores ATM. Los sistemas de gestión actuales convencionales, basados preferentemente en plataformas tipo SNMP, no proporcionan las capacidades necesarias para poder controlar una red basada en ATM. Por lo general, se requiere controlar tráfico muy sensible al retardo , jitter , o bien la infraestructura de conmutación extremo a extremo de forma muy rápida. Para este fin, el ATM Forum creó un modelo de gestión ATM de cinco capas y unas funciones OAM (Operations, Administration and Maintenance) que distribuyen la información de gestión por la red ATM. Este modelo de gestión extremo a extremo permite la interacción tanto de redes públicas como de redes privadas. El modelo también definirá las pasarelas entre los protocolos SNMP y CMIP (Common Management Information Protocol), así como entre otros sistemas propietarios. A pesar de todo, este modelo de gestión tardará años en poder completarse. De momento, el ATM Forum ha definido el ILMI (Interim Management Interface) que se incluye en la recomendación UNI (User-Network Interface). El ILMI utiliza una conexión virtual ATM preestablecida con UNI para comunicarse conmutador a conmutador y con una aplicación de gestión vía mensajes SNMP. Sin embargo, el ILMI se limita a gestionar interfaces entre redes y no distribuye inteligencia de gestión a través de la red. En la figura 10.5 se ha detallado un escenario de red de banda ancha. Se observa que los NMC se conectan a los elementos de la red ATM a través de la interfaz Q3 normalizada por la UIT y por el ETSI. Asimismo, se definen cinco interfaces de gestión (desde M1 a M5) que permiten monitorizar y controlar extremo a extremo los diferentes elementos de la red. En el caso de gestión más normal, de conmutadores ATM, interesarán, particularmente, las interfaces M1 y M2. Otro organismo, el IETF (Internet Engineering Task Force) define especificaciones para las interfaces M1 y M2, basadas en el protocolo SNMP. Éstas incluyen la definición de bases de datos (tipo MIBs)
en DS-1, DS-2 y otras conexiones para SDH. Actualmente está desarrollando de forma experimental una base de datos para redes ATM (AToM MIB, RFC 1695). En este caso, sin embargo, la gestión no es extremo a extremo. El ATM Forum tardará aún tiempo para la especificación del interfuncionamiento entre diversos tipos de protocolos como SNMP y CMIP y/o otros protocolos propietarios para el resto de interfaces. A pesar de ello, ya se está elaborando una base de datos MIB para la interfaz M4, que es independiente del tipo de protocolo utilizado en su acceso. En los próximos años se completarán los protocolos de gestión de la red ATM, pero no tanto desde el punto de vista de SNMP o CMIP sino de definición de las celdas OAM. Será necesaria una arquitectura distribuida inteligente que gestione la red, de forma que pueda reconfigurarse dinámicamente en caso de fallos en enlaces, o negociar el ancho de banda para determinados servicios, configurar según niveles de congestión, etc. El forum está ahora en proceso de especificar diversos tipos de celdas OAM de 53 bytes con funciones específicas, tales como gestión de fallos, gestión de prestaciones, de tráfico y funciones de activación/desactivación para los casos anteriores. Estas celdas permitirán realizar gestión de las conexiones extremo a extremo así como reducir el número de bases de datos (MIB) y las cargas de señalización en la red. A continuación, se muestran como ejemplo algunas de las funciones de gestión de red de banda ancha más representativas. Es el caso de crear un abonado CBDS (servicio de datos de banda ancha sin conexión) donde el NMC asocia el número de abonado E.164 y el identificador de acceso físico. Entonces, el NMC de banda ancha: - debe encontrar la ruta en la red a usar en la conexión, - asignar los recursos necesarios (p.e. ancho de banda) en cada enlace ATM, - crear las transconexiones ATM en cada elemento de red ATM, - crear el abonado en el servidor sin conexión.
Centro de gestión de red privada de BA M3 (SNMP, CMIP,...)
Agente
UNI ATM privado
Agente Conmutador ATM UME RDSI BA Usuario público
ILMI (SNMP/AAL)
M5 (SNMP, CMIP,...)
Agente
Agente
M4
M2 (Q3)
M1(Q3)
Centro de gestión de red público de BA
M4
Agente
UNI ATM público
Usuario RDSI BA UNI ATM público Agente
M4(Q3)
M4
Agente
Red ATM privada Red ATM pública Red ATM pública ILMI ILMI (SNMP/AAL) (SNMP/AAL) UME UME UME UNI ATM público
RDSI BE
Agente
Usuario público
Conmutador ATM
Usuario
ILMI (SNMP/AAL)
Red privada local
Usuario
Usuario
UME
Usuario
Fig. 10.5 Esquema de interfaces de gestión de red B-RDSI
Si existe algún problema como los relativos a caídas de enlace. El NMC debería: - detectar dicho enlace ATM, - encontrar todas las conexiones que estaba usando este enlace, - buscar una ruta alternativa en la red para cada conexión afectada, - asignar los recursos necesarios (p.e. ancho de banda) en cada enlace ATM, - crear las transconexiones ATM en cada elemento de red ATM.
10.2 Interfaces en la red de gestión de banda ancha. La UIT-T (o ITU-T) define una serie de interfaces X, F, Q3, QX para la gestión de la arquitectura física en la red de gestión de telecomunicaciones (TMN). De entre ellas, la más importante es la interfaz Q3. Todos los modelos de objetos específicos en Q3 se basan en información de gestión genérica definida en las series de recomendaciones X.700 y M.3100 de UIT-T. Las áreas funcionales cubiertas por esta interfaz (Q3) están relacionadas con la gestión de abonados, gestión de tráfico y gestión de recursos del sistema.
10.2.1 Interfaces definidas por el ATM Forum De manera simultánea, el ATM Forum define cinco interfaces de gestión denominadas de M1 a M5, que permiten monitorizar y controlar las conexiones extremo a extremo en redes ATM.
- Interfaz M1 (Q3) Define la interfaz entre el sistema de gestión de una red privada y la estación final ATM. - Interfaz M2 (Q3) Define la interfaz entre el sistema de gestión de una red privada y una red corporativa ATM. - Interfaz M3 (X) Define la interfaz entre la gestión de una red privada y el sistema de gestión de la red pública. - Interfaz M4 (Q3) Define la interfaz entre la plataforma del sistema de gestión de red y la red pública ATM. - Interfaz M5 (X) Define la interfaz entre plataformas de sistemas de gestión de redes públicas distintas.
10.3 ATM Forum El ATM Forum es una organización internacional sin ánimo de lucro que trata de acelerar la cooperación industrial en tecnología ATM. Sus recomendaciones y especificaciones son seguidas por los principales fabricantes de equipos ATM y constituyen un estándar de facto en esta tecnología. Las especificaciones propuestas por este ATM Forum se complementan en gran medida con las recomendaciones generadas por la UIT. Para la gestión de la interfaz de usuario con la red, el ATM Forum define un protocolo denominado Interim Local Management Interface (ILMI).
10.3.1 ILMI El Interim Local Management Interface (ILMI) utiliza una conexión virtual ATM en el User Network Interface (UNI) para comunicar con una aplicación de gestión usando mensajes SNMP. Cada conmutador ATM, o sistema final, y cada red ATM que desarrolle una red privada o pública UNI debe tener una entidad de gestión UNI (UME) que soporte la MIB ILMI. La UME reside entre el conmutador y la red o entre una red privada y una red pública. Es la responsable de mantener datos de gestión y responder a comandos SNMP recibidos sobre el UNI ATM a través del ILMI. De igual forma que en una aplicación basada en SNMP, estos mensajes se envían a la red vía un protocolo de paquetes datagrama de usuario TCP/IP. Estos paquetes se segmentan en unidades de datos de protocolo ATM, que se incorporan en celdas ATM usando capas de adaptación AAL 3/4 o AAL 5. Los tipos de información de gestión que están disponibles en la MIB ATM UNI son los siguientes: - Physical Layer - ATM Layer - ATM Layer Statistics - Virtual Path (VP) Connections - Virtual Channel (VC) Connections - Address Registration Information
10.3.2 Celdas OAM Los sistemas de gestión de redes ATM en un futuro van a utilizar celdas OAM para su gestión. El fórum está en proceso de definir una serie de celdas OAM (de 53 bytes) con funciones específicas tales como: gestión de fallos, gestión de prestaciones, de activación y desactivación (rec. UNI 3.1), y otras nuevas como, por ejemplo, para la gestión de tráfico: (Resource Management) RM (rec. UNI 4.0). Tipo de celda OAM (UNI)
Tipo de función OAM
Gestión de fallos
AIS FERF Bucle de celda OAM Comprobación de continuidad
Gestión de prestaciones
Monitorización directa Envío de informes en sentido contrario Monitorización/ Reporting
Activación/desactivación
Monitorización de prestaciones Comprobación de continuidad
Gestión de tráfico
Celdas de gestión de recursos (RM)
10.4 IETF en ATM El grupo IETF especifica una MIB para definir y desarrollar los objetos de gestión necesarios usando el protocolo SNMP estándar para gestionar dispositivos ATM.
10.4.1 AToM: RFC 1695 Este documento especifica un estándar para la comunidad Internet que permite su uso para gestión de redes ATM. Se define la MIB, y en particular sus objetos, para gestionar con interfaces basadas en ATM, dispositivos, redes y servicios. La MIB está limitada a un único extremo ATM del sistema o centro conmutador. Está basada en incorporaciones de la Sonet MIB, DS-1/E1 MIB, DS-3/E3 MIB y la ILMI MIB. Existen diferencias entre los objetos gestionados definidos por ATM Forum y IETF sobre información de gestión ATM. En general, la IETF MIB puede incluir la MIB II y la base de datos específica de ATM, ATM MIB.
10.5 Tendencias y análisis comparativo entre estándares de gestión ATM Actualmente las funciones de gestión que están disponibles en los equipos ATM que presentan los distintos fabricantes distan mucho de las que debieran utilizarse para un funcionamiento óptimo en
prestaciones. Los equipos más avanzados basan su gestión en estándares del ATM Forum mediante el ILMI a nivel de usuario y mediante el empleo de celdas OAM para la red de transporte. Dado que el ATM Forum no ha definido todavía completamente las funcionalidades de gestión, existen diversas opciones según cada fabricante: a) Uso de sistemas de gestión propietarios: pueden llegar a tener más funcionalidades que los estándares de facto abiertos definidos, como por ejemplo por ATM Forum; sin embargo, no son compatibles con otros equipos lo que condiciona la evolución futura del sistema. Raramente son mejores desde un punto de vista de prestaciones, rapidez de respuesta, etc. b) Uso de sistemas basados en ATM Forum: son abiertos y avanzados en prestaciones; sin embargo, pueden adolecer de escasas facilidades de gestión si no están debidamente actualizados. Pueden ofrecer funciones propietarias complementarias de gestión si es necesario y si se tiene un buen soporte técnico. c) Uso de otros sistemas abiertos, CMIP/CORBA: actualmente no hay solución disponible comercialmente en redes ATM si bien están empezando a consolidarse recomendaciones para su uso en redes TMN (ITU). Se trata de sistemas complejos, con gestión distribuida y que formarán parte de los sistemas de gestión en un futuro próximo. d) Uso de otros sistemas abiertos tales como SNMP, SNMPv2 (IETF): si bien presentan en general un buen grado de compatibilidad con otros sistemas abiertos, tienen el inconveniente de que no son adecuados para la gestión en redes ATM.
10.6 Control de tráfico en redes ATM La gestión de tráfico permite a la red ofrecer una calidad de servicio en cada conexión individual, activar nuevas conexiones de acuerdo con una optimización de los recursos existentes en la red y protegerse contra la congestión. La calidad de servicio se obtiene a partir de una serie de procedimientos: por una parte el contrato suscrito entre el usuario y la red durante el establecimiento de la conexión, el control de policía que garantiza el cumplimiento del contrato (UPC), también la disponibilidad de recursos para incorporar una nueva conexión (CAC) y finalmente un comportamiento justo y equitativo de la red.
10.6.1 Calidad de servicio La calidad de servicio se define como un conjunto de parámetros objetivos, y por tanto medibles, que caracterizan el grado de servicio que ofrece la red al usuario del servicio. Estos parámetros han de ser medibles. En la recomendación UNI 4.0 (Interficie usuario-red) del ATM Forum, la calidad de servicio se define por seis parámetros: cuatro de ellos hacen referencia a la transparencia semántica (la información que entra en la red es igual a la que sale) y los dos restantes se refieren a la transparencia temporal (retardo de las celdas).
- Parámetros relativos a la transparencia semántica a) Tasa de error de celda (Cell Error Rate, CER) CER = (Celdas erróneas)/(Celdas transmitidas) b) Tasa de celdas perdidas (Cell Loss Rate, CLR) CLR = (Celdas perdidas)/(Celdas transmitidas) c) Tasa de celdas mal insertadas ( Cell Misinsertion Rate, CMR) CMR = (Celdas mal insertadas)/(Intérvalo temporal) d) Tasa de bloques con errores severos ( Severely errored Cell Block Rate, SECBR) SECBR = (Bloques de celdas con errores severos)/(Número de bloques de celdas transmitidos).
- Parámetros relativos a la transparencia temporal a) Retardo máximo de transferencia de celda ( Maximun Cell Transfer Delay, maxCTD) Retardo máximo extremo a extremo en ausencia de tráfico. b) Variación “pico a pico” del retardo de celda (Peak to Peak CDV) El CDV es la varianza del retardo de celda. Otro de los aspectos importantes de la calidad de servicio que puede solicitarse o asignarse por una conexión es la prioridad de pérdida de celdas. Un usuario puede pedir dos niveles de prioridad de pérdida de celdas para una conexión ATM. La prioridad de una celda individual es indicada por el usuario mediante el bit CLP en la cabecera de la celda. Cuando se utilizan los dos niveles de prioridad, se han de especificar los parámetros de tráfico para los dos flujos de celdas. Normalmente, esto se hace especificando un conjunto de parámetros de tráfico por tráfico de alta prioridad (CLP = 0) y un conjunto de parámetros de tráfico para todo el tráfico (CLP = 0 o 1). Basándose en esta división, la red puede asignar los recursos más eficientemente.
10.6.2 Parámetros de tráfico Los parámetros de tráfico, junto a la calidad de servicio, se utilizan para definir una conexión ATM. Los parámetros de tráfico definen la forma que una fuente puede introducir tráfico en la red a través de una conexión virtual. Se definen a continuación: a) Tamaño máximo de ráfaga ( Maximum Burst Size , MBS) Especifica el tamaño de la ráfaga de celdas que puede introducirse en la red. Tiene dimensiones de celdas. b) Tasa de pico de celda (Peak Cell Rate, PCR) Especifica la tasa máxima de introducción de celdas en la red. PCR = 1/T donde T es la distancia mínima entre celdas. c) Tasa sostenida de celda (Sustainable Cell Rate, SCR) Especifica la tasa promedio de introducción de celdas en la red. Para ser útil a la red, SCR ha de ser menor que PCR. SCT = 1/Ts, donde Ts es la distancia media entre celdas. d) Tasa mínima de celda ( Minimum Cell Rate , MCR) Especifica la tasa mínima de introducción de celdas en la red.
10.6.3 Descriptores de tráfico Los descriptores de tráfico de una conexión describen las características de una conexión mediante: a) Un conjunto de parámetros de tráfico de la fuente. b) Una definición de conformidad. c) La tolerancia a la variación del retardo de la celda (Cell Delay Variation Tolerance, CDVT). A continuación se describe la relación entre las categorías de tráfico definidas en ATM respecto de los parámetros de calidad de servicio descritos.
PCR SCR MCR MBS MCTD CDVT CLR
CBR SI NO NO NO SI SI SI
VBR-RT SI SI NO SI SI SI SI
VBR-NRT SI SI NO SI SI NO SI
ABR SI NO SI NO SI NO SI
UBR NO NO NO NO NO NO NO
UBR+ NO NO SI NO NO NO NO
Tabla. 10.1 Parámetros de QoS aplicables a cada categoría de servicio ATM
10.6.4 Mecanismos de control de tráfico El control de tráfico son el conjunto de acciones que adopta la red para evitar las condiciones de congestión. La gestión de tráfico en ATM se describe en las recomendaciones I.371 y en el ATM Forum Traffic Management 4.0.
10.6.4.1 Control de admisión de conexiones, ( Connection Admission Control , CAC) El control de admisión de conexiones actúa cuando un usuario pide una nueva conexión y tiene que especificar (explícitamente o implícitamente) las características de la conexión en los dos sentidos. El usuario escoge las características del tráfico seleccionando una calidad de servicio entre las categorías de servicio que proporciona la red.
10.6.4.2 Control de parámetros de usuario/red ( Usage/Network Parameter Control , U/NPC) Una vez se ha aceptado una conexión por le CAC, la función de control de utilización de parámetros (UPC) de la red monitoriza la conexión para determinar si el tráfico cumple el contrato de tráfico. El propósito principal del UPC es proteger los recursos de la red de la sobrecarga por parte de una conexión que podría afectar negativamente la calidad de servicio en otras conexiones, detectando las violaciones de los parámetros asignados y adoptando las medidas apropiadas. La localización del UPC suele realizarse a nivel de camino virtual (VPC). Los algoritmos utilizados son variados, como el Generic Cell Rate Algorithm (GCRA) definido en la Rec. I.371 y UNI. Otros algoritmos son el Virtual Scheduling (VS) y continuous-state Leaky Bucket (LB) algorithm.
Otras funciones de control adicionales son el control de prioridad, ya comentado, el alisado de tráfico, los mecanismos de gestión de recursos de red, o bien los controles de realimentación.
10.7 Funciones de control de congestión Se denomina congestión a la circunstancia en la que el rendimiento de la red (o una parte de ella) se degrada debido a la presencia de demasiados paquetes. La congestión es un problema global, que se da en el nivel de red como consecuencia del tráfico agregado de varias fuentes sobre un enlace o router de baja capacidad. A diferencia de la congestión, el control de flujo es una circunstancia que sólo puede darse en conexiones punto a punto (es decir, a nivel de enlace o a nivel de transporte). Algunos de los parámetros que permiten detectar la presencia de congestión pueden ser los siguientes: - porcentaje de paquetes descartados - longitud media de las colas en las interfaces de los routers. - número de paquetes que dan timeout y se retransmiten (no debidos a errores) - retardo medio por paquete - desviación media del retardo por paquete. El tráfico a ráfagas es la principal causa de congestión; por eso el control de congestión suele utilizarse sólo en caso de tráfico tipo ABR. Entre los mecanismos de control de congestión existentes está el alisado de tráfico (traffic shaping) que permite establecer unos márgenes máximos al tráfico de ráfagas. El de vigilancia de tráfico o función policia (traffic policing) realiza una labor de monitorización o seguimiento del tráfico introducido por el usuario en la red para verificar que no excede el perfil pactado. El leacky bucket permite al host enviar ráfagas, que son almacenadas en un buffer o cola de la interfaz, para ser enviadas a la red posteriormente a un flujo constante. Para llamadas de datos ABR, la fuente crea una conexión con un call setup request . Durante la llamada, se define el valor para un conjunto de parámetros ABR. La tasa a la que la fuente ABR puede transmitir las celdas está reflejada en el ACR ( Allowed Cell Rate). El ACR está inicializado al ICR (Initial Cell Rate) y siempre está entre un mínimo MCR ( minimum Cell Rate) y un PCR (Peak Cell Rate). La transmisión de las celdas de datos está precedida por la transmsisión de celdas RM Rresource Management Cell). La fuente continuará enviando celdas RM después de un cierto número de celdas de usuario, y más frecuentemente cuando el ACR es bajo. La tasa de fuente viene controlada por el retorno de las celdas RM, que son devueltas por el destino o un destino virtual. La fuente sitúa la tasa permitida (ACR) en el campo CCR (Current Cell Rate) de la celda RM, y la tasa a la cual desearía transmitir las celdas (usualmente el PCR) en el campo ER ( Explicit Rate). La celda RM viaja a través de la red, dando a los conmutadores la información que contiene sobre las conexiones ABR. Los conmutadores también tienen que decidir a la vez cómo reducir el valor del campo ER, o si poner el bit CI (Congestion Indication) a 1. Los conmutadores que sólo soportan el mecanismo basado en el bit EFCI (Explicit Forward Congestion Notification) ignorarán el contenido de la celda RM. Los conmutadores pueden generar opcionalmente un número controlado de celdas RM en el camino hacia atrás además de los generados por la fuente. Las celdas RM generadas por los conmutadores deben tener el bit BN ( Backward Notification) a 1 y cada uno de los bits CI o NI ( No Increase) a 1.
Cuando la celda llega al destino éste debe cambiar el bit de dirección en la celda RM y devolverla a la fuente. Si el destino está congestionado y no puede soportar la tasa especificada en el campo ER, el destino debe reducir ER a la tasa que puede soportar. Si al devolver la celda RM al destino ha observado el bit EFCI activado desde que fue devuelta la última celda RM, entonces debe activar el bit CI de las celdas RM para indicar congestión. Mientras que las celdas RM viajan a través de la red, cada conmutador debe examinar la celda y determinar si puede soportar la tasa ER para su conexión. Si ER es demasiado elevado, el conmutador deberá reducir la tasa a la que pueda soportar. Los conmutadores no deben aumentar el ER ya que la información de los anteriores conmutadores donde ha pasado la celda RM se perdería. Los conmutadores deben intentar modificar el ER sólo en las conexiones cuello de botella ya que esto ofrece una justa asignación del ancho de banda. Los conmutadores también deben modificar el contenido de ER cuando van hacia delante o hacia atrás, pero no en ambos. Cuando la celda RM llega a la fuente, ésta debe reinicializar la tasa, ACR, basada en la información que llevaba la celda RM. Si el indicador de congestión no estaba activado (CI = 0), entonces la fuente debe incrementar su ACR en un incremento fijo determinado en el establecimiento de la llamada hacia el valor devuelto de ER, pero nunca excediendo el PCR. Si el indicador de congestión está activado (CI = 1) entonces la fuente debe disminuir su ACR en una proporción igual o más grande que una porción de su actual ACR. El tamaño también estará determinado en el establecimiento de la llamada. Si el ACR sigue siendo mayor que el valor devuelto de ER, la fuente debe disminuir su ACR al valor ER, aunque nunca por debajo del MCR. Un bit NI = 1 indica a la fuente que debe observar los campos CI y ER de la celda RM, pero no incrementar el ACR por encima de su valor actual. Otra vía para notificar la congestión los conmutadores ATM es poner a 1 el bit medio del campo PTI (Payload Type) de la cabecera en las celdas de datos que envían al causante de los problemas.
10.7.1 Control de flujo El ATM Forum ha adoptado el esquema basado en tasa como estándar para control de flujo. A partir de los requerimientos de espacio se pueden dividir los agoritmos de control de flujo en dos tipos: - algoritmo de control de flujo de espacio constante (número de variables utilizadas en el algoritmo constante e independiente del número de sesiones que cruzan el puerto). - algoritmo de espacio ilimitado (el espacio depende, normalmente de forma lineal, del número de conexiones). Los algoritmos de control de flujo de espacio constante son importantes en las redes actuales, ya que si alguien quiere tener tanto tráfico en ATM como tráfico TCP, la dependencia del número de sesiones no puede existir. ATM Forum propone tres algoritmos para el control de flujo de espacio constante ( Enhanced Proportional Rate Control Algorithm, EPRCA y Adaptive Proportional Rate Control with intelligent congestion indication APRC, Congestion Avoidance using Proportional Control, CAPC y Explicit Congestion Indication for Congestion Avoidance, ERICA/ERICA+). Los tres algoritmos calculan para
cada puerto de salida de cada conmutador un parámetro para delimitar la cantidad de sesiones del puerto.
10.8 Recuperación en redes ATM En este apartado se detallan los cambios realizados en el diseño de redes ATM para que adopten un alto grado de transparencia al usuario frente a roturas de cables.
Protección de redes Trata de los principios básicos de asignación de recursos dedicados para protección y la distinción entre protección 1+1 y 1:1. Concepto de agrupación de caminos virtuales que comparten la misma ruta física para reducir el el procesado de encabezamiento durante la protección de la conmutación. Redes reconfigurables Coordinación en la restauración de redes usando un control centralizado. Sólo existen soluciones propietarias. Redes autorecuperables Se describen tres técnicas que se basan en la asignación simultánea de rutas y capacidades. Otra opción consiste en permitir una plataforma tecnológica diferente situada usualmente en un nivel más bajo al de la jerarquía de transporte para asumir la responsabilidad de la continuidad de servicio en el caso de fallos. 10.8.1 Mecanismos de recuperación ATM alternativos Mecanismos que se basan en la recomendación ATM Network survivability architectures and mechanisms. Q.F/13. Nov. 1996. (*)
Protección Se ocupa de la asignación de una ruta alternativa con asignación de ancho de banda dedicado. En el caso de un evento inesperado, un protocolo de gestión distribuido permite real izar la conmutación. Restauración Podría realizarse bajo los auspicios de un control centralizado (red reconfigurable) o un protocolo de control distribuido con procedimientos de gestión de redes autorecuperables. En ambos casos, los recursos podrían ser semidedicados donde la ruta alternativa sea predeterminada, pero el ancho de banda asignado sea “por demanda” siguiendo la detección de fallos. También, en ambos casos, la ruta y el ancho de banda podrían asignarse en tiempo real (“por demanda”).
Dedicados Protección de redes Redes reconfigurables Redes autorecu perables
Semidedicados
Por demanda
Central
X
X
X
X
X
Control distribuido
Gestión distribuida X
X
X
X
Tabla 10.2 Arquitecturas de recuperación ATM
Un rasgo distintivo lo constituye el hecho de que se requiere menor capacidad sobrante en métodos de restauración que en los de protección. El control distribuido se aplica sobre procedimientos de establecimiento de conexiones con celdas de señalización del plano de control, mientras que la gestión distribuida hace uso de mensajes en el plano de gestión en forma de celdas OAM.
10.8.2 Redes de protección ATM Las redes de protección son las que disponen de los niveles de fiabilidad más elevados; sin embargo, suelen ser las más caras, dado que recursos como el ancho de banda y los caminos/canales virtuales (VPI/VCI) son dedicados más que compartidos. Por otra parte, la preasignación de rutas y recursos permite que los protocolos de gestión distribuida sean muy simples de usar en el caso de un fallo en la red. La protección de conexiones de red (NCP) puede aplicarse extremo a extremo o bien a un segmento (Sub-Network Connection Protection, SNCP). Para propósitos de control, los segmentos protegidos y los no protegidos se alinearian con flujos apropiados de operaciones y mantenimiento (OAM). El protocolo de conmutación de protección VP/VC se ha especificado para arquitecturas de protección “punto a punto” dentro de dominios NCP y SNCP (*). El protocolo podría ejecutarse de acuerdo con 1+1 o en 1:n. El uso de Virtual Path Groups (VPG) agrupa caminos virtuales formando segmentos o conexiones extremo a extremo, reduciendo la señalización en el caso de sistemas de múltiples conexiones.
10.8.3 Redes reconfigurables Las redes reconfigurables permiten la restauración de conexiones mediante sistemas de gestión de red centralizados (NMS). Podrían explotar rutas alternativas, preplanificadas, o mantenerlas dinámicamente de acuerdo con la información de estado de la red actual. Además resulta una tarea simple el priorizar el reencaminamiento de conexiones a fin de asegurar que aquellas con aplicaciones críticas
sean restauradas con mayor rapidez que los servicios que son tolerantes de pérdida de datos temporales. Sin embargo, existen tres causas de ralentización de la respuesta del sistema: - comunicaciones ascendentes entre los nodos de la red desde nodos adyacentes al del fallo y el NMS - procesado del NMS requerido para encaminamiento y asignación del ancho de banda - comunicación descendente entre el NMS y los nodos de la red, seguidos por la reconfiguración de los elementos de red apropiados. La restauración centralizada (generalmente propietaria) suele ser lenta e inapropiada en BISDN. Sin embargo, la gestión de fallos suele ser problemática entre equipos de diferentes fabricantes.
10.8.4 Redes ATM autorecuperables Este tipo de redes explota la gestión distribuida o la funcionalidad de señalización del plano de control, e incorpora asignación de recursos “por demanda“ o bien semidedicada. Se describen a continuación tres médodos de redes autorecuperables por demanda.
Autorecuperación con encaminamiento PNNI El ATM Forum ha definido el protocolo ( Private Network Node Interface, PNNI) para establecer circuitos virtuales conmutados (VCs) entre conmutadores ATM que utilizan un punto de acceso de servicio de red (NSAP) tipo direcciones ATM. Desde que el ATM Forum ha especificado una codificación NSAP para direcciones E.164, el protocolo de encaminamiento PNNI puede también emplearse en redes públicas. La especificación PNNI describe cómo los nodos de la red mantienen el conocimiento acerca de la alcanzabilidad y los recursos dentro de la red gracias a un protocolo de encaminamiento según los estados topológicos en un entorno de intercambio de información periódico entre nodos.
Autorecuperación con soft PVCs/PVPs En este caso, cuando ocurre un fallo, la conexión se corta hasta los extremos de los conmutadores ATM, seguidos de instigación automática de reencaminamiento, aunque no hay garantías de éxito. Es propio de General DataComm (APEX). Algoritmos de restauración distribuida (DRAs) Es una descripción genérica aplicada a protocolos que dinámicamente restauran la capacidad de transporte que ha caído, y originada en redes SONET/SDH. La idea de DRAs es encaminar tráfico rápidamente (< de 2 seg.) usando conmutadores digitales de alta granularidad, de manera que conexiones vocales o sesiones de transferencia de datos de usuario no se desconecten. Es decir, existe una clara distinción entre protocolos de transporte que operan en caminos, y señalización de control usada en circuitos individuales. 10.8.5 Autorecuperación con backup de VPs semidedicados Las rutas de backup que son disjuntas de las rutas de trabajo son preasignadas. Sin embargo, la capacidad sobrante podría compartirse para restauración desde el tipo más común de fallos, como single spans. La principal ventaja de esta aproximación es que la capacidad sobrante puede ser compartida entre otros VPs de backup, reduciendo los costes.
10.8.6 Restauración multicapa El principal problema de la restauración a bajo nivel es que aunque la capa SDH podría utilizarse para ser usada para reconfigurarse desde roturas de cable y fallos en equipos SDH, no sería efectiva para resolver fallos a nivel de ATM. Se plantea pues una restauración multicapa. Mecanismo de Aplicaciones recuperación Misión crítica en Protección datos. Telemedicina dedicada
Retardo
Coste
Viabilidad técnica
Objetivo es 60 ms
Alto (reserva de capacidad más VPI/VCIs) Medio (capacidad compartida más VPI/VCIs) Bajo (sólo capacidad)
La conmutación rápida se basa en VPG Se basa en VPG y asignación de capacidad Basada en señalización estándar. Viable, pero limitado a sistemas propietarios.
Semi dedicada
Misión casi crítica. Interruptible
< de 10 seg.
Autoredial
Residencial. Misión no crítica en datos
De 10 segs a minutos.
Centralizada (con NMS)
Residencial. Misión no crítica en datos
Varios minutos
Relacionado con sofisticación de NMS
Tabla 10.3 Tabla mecanismos de recuperación en B-RDSI
11 Gestión en redes de comunicaciones móviles La gestión de redes de comunicaciones móviles se beneficia de la alta sofisticación de los terminales móviles y de las altas prestaciones en general de todos los elementos de sus redes. Esto permite integrar una red de gestión de telecomunicaciones (TMN) e inteligencia de red en sus arquitecturas de comunicaciones de forma relativamente sencilla a pesar de la complejidad de todos los procesos subyacentes en los sistemas [VO1, GA1, RS2]. 11.1 Introducción a las comunicaciones personales
La progresiva integración de elementos computadores en las infraestructuras de redes de comunicaciones convencionales ha permitido dar un salto adelante a éstas, proporcionando al usuario un conjunto de nuevos servicios. Estas arquitecturas emergentes que proporcionan una capacidad de cálculo y ofrecen por consiguiente nuevos servicios reciben el nombre de redes inteligentes. En el caso de las comunicaciones móviles, estos nuevos servicios se ofrecen como facilidades y comúnmente se conocen como comunicaciones personales . En este capítulo se da una primera visión de estos nuevos servicios y de la infraestructura necesaria para su soporte. En las redes de comunicaciones fijas, el usuario está siempre asociado con su terminal propio, el punto de acceso a la red o el punto de conexión del terminal a la red (Fig. 11.1). En las redes de comunicaciones móviles, los terminales no disponen de punto fijo de conexión y se comunican dinámicamente a través de canales de radio. La infraestructura celular permite la movilidad de los terminales, que establecen y reciben llamadas siempre que se encuentren en una zona de cobertura adecuada. En este caso, la asociación entre el terminal y el usuario todavía se mantiene. En el entorno UPT (Universal Personal Telecommunication), la movilidad da un paso adelante: la asociación fija entre el usuario y el terminal, tanto en redes fijas como móviles, se rompe, el usuario únicamente se identifica con la red mediante un número personal conocido por el número UPT. Esto se conoce como movilidad personal. En este caso se permite al usuario aparecer en cualquier punto de acceso a la red y utilizar los servicios de telecomunicación a los que está abonado. La evolución de este tipo de sistemas empezó en 1989, cuando en el Reino Unido se permitió el desarrollo de una red de comunicaciones personales PCN ( Personal Communication Network ), basada en estándares de ETSI GSM (Fig. 11.2). Esta nueva recomendación DCS1800 aprobada en 1991 para Europa era un sistema celular digital a 1800 MHz que incorporaba una serie de servicios de telefonía personal. En América del Norte se introdujo un sistema equivalente, más orientado a la provisión de servicios personales, denominado PCS ( Personal Communication Services) que permitía el acceso por radioenlace, la movilidad del terminal y la movilidad personal.
En paralelo a la iniciativa británica, el ETSI decidió auspiciar el estándar UPT (Universal Personal Telecommunication) en Europa. La finalidad que se perseguía con este nuevo estándar era desarrollar inicialmente los conceptos de movilidad personal y número personal de abonado. Éstos rompieron la asociación fija que había entre terminal y usuario, al permitir un alto grado de movilidad en redes fijas y móviles. También existieron iniciativas dentro del programa RACE II (1992) con el proyecto Mobilise (R2003) que definía el concepto de PSCS ( Personal Services Communication Space) como una extensión de UPT. El PSCS estaba basado en el modelo conceptual de red inteligente (ITU-T, Q.1200) con extensiones obtenidas del Open Distributed Processing (ODP). Posteriormente, en Estados Unidos se aprobaron las bandas de 1900 MHz (PCS1900) para el soporte de redes móviles con servicios PCS ( Personal Communication Services). En la actualidad, en Europa el término PCN (Personal Communications Network ) ha sido desplazado por UPT y la contraposición entre el sistema europeo y el americano se plantea en términos de UPT/PCS (UPT está también siendo normalizado por el ITU). En el caso de PCS, además de la funcionalidad recogida en UPT, se añaden otras de carácter físico de la red. La evolución de estos sistemas PCS/UPT junto con su interconexión/integración con redes preexistentes es un paso intermedio hacia el concepto de sistemas de la tercera generación. La tercera generación (UMTS/FPLMTS) surge a partir de servicios soportados por sistemas celulares incorporando diferentes estándares como sistemas telefónicos inalámbricos (p.e. DECT), incluidas su interconexión con GSM y la ayuda de sistemas de satélites con cobertura mundial.
Identificación de línea
Identificación de terminal
Redes fijas
Relación fija
Redes móviles
Relación dinámica
Dinámica Redes fijas y móviles
Identificación de usuario Relación fija
SIN MOVILIDAD
Relación fija
MOVILIDAD DE TERMINAL
Dinámica
MOVILIDAD PERSONAL
Fija
Fig. 11.1 La movilidad personal permite a los usuarios el libre movimiento entre terminales, tanto en redes fijas como móviles, para establecer y/o recibir llamadas
Fig. 11.2 Esquema descriptivo de la evolución de los sistemas de comunicaciones móviles (europeo a la izquierda y americano a la derecha) desde sus orígenes hasta nuestros días 11.1.1 Comparación entre la gestión en sistemas cableados y sistemas de comunicación móviles
A partir de las características de los sistemas de comunicaciones fijas descritos en capítulos anteriores se pueden estudiar los aspectos de gestión que se plantean en los nuevos sistemas de comunicaciones móviles. Áreas funcionales como las de configuración o fallos resultan muy afectadas en estos nuevos sistemas. En la tabla 11.1 puede observarse una estimación de la evolución en la gestión que pueden seguir los sistemas de comunicaciones móviles frente a otras arquitecturas de comunicaciones fijas.
-Bucle dedicado/usuario - Canales escasos y por contienda - Estático - Calidad bucle estable - Dinámico - Calidad inestable Muy centralizado Muy distribuido
Distribución de equipos Interconexiones Pocas jurisdicciones Mas jurisdicciones Proveedor de servicios Fijo Depende de la posición local en el seguimiento Autentificación Ninguna Hecha para cada terminal llamada Tarificación - Uso independiente del -Distancia servicio local independiente del servicio local - Sin cargos para llamadas entrantes - Cargos para llamadas entrantes Diseño de red de Herramientas de Planif. bucle estático acceso ingeniería de RF Establecimiento del Ninguno Registro del terminal terminal inicial
Tabla 11.1 Tabla comparativa entre la gestión en redes fijas y redes de comunicaciones móviles 11.1.2 Arquitectura de la red GSM
La arquitectura del sistema GSM consta de tres grandes subsistemas interconectados que interactúan entre ellos mismos y con los usuarios, a través de ciertas interfaces de red. Los subsistemas son el Base Station Subsystem (BSS), el Network and Switching Subsystems (NSS) y el Operation Support Subsystem (OSS). La estación móvil ( Mobile Station, MS) se considera integrada en el subsistema BSS. La BSS, también conocida como subsistema radio proporciona y gestiona trayectos de transmisión de radio entre estaciones móviles y centros de conmutación móvil ( Mobile Switching Centers, MSC). La BSS también gestiona la interfaz de radio entre las estaciones móviles y los demás subsistemas de GSM. Cada BSS consiste de muchos controladores de estaciones base ( Base Station Controllers, BSCs) que conectan las MS a la NSS vía los MSCs. Los NSS gestionan las funciones de conmutación del sistema y permiten a las MSCs comunicar con otras redes tales como la PSTN y RDSI. El OSS soporta la operación y el mantenimiento de GSM y permite a los ingenieros de mantenimiento, monitorizar, diagnosticar y arreglar todas las alertas del sistema GSM. El OSS soporta unos o varios centros de mantenimiento de operaciones ( Operation Maintenance Centers, OMC). En el NSS hay tres diferentes bases de datos denominadas Home Location Register (HLR), Visitor Location Register (VLR) y Authentication Center (AUC). El AUC contiene el registro de identidades de equipos ( Equipmente Identity Register , EIR) que identifica terminales t erminales robados o que hacen un uso fraudulento del sistema.
Fig. 11.3 Arquitectura de la red GSM y sus protocolos de señalización
La gestión de red en GSM se basa en la constitución de una red de gestión del sistema (TMN) y sigue las pautas de diseño vistas en el correspondiente capítulo 6. NE-BSC NEF
MF: función de mediación NEF: funciones de elementos de red OS: sistema de operaciones OSF: funciones del sistema de operaciones Las recomendaciones de la ETSI que definen la arquitectura de gestión de red del sistema GSM son la serie 12 de GSM. Esta serie define más de 100 clases de objetos gestionados con casi 500 atributos [TO1]. 11.2 Arquitectura de las redes P CS 11.2.1 Características de los sistemas basados en PCS
Los sistemas PCS pueden distinguirse de otros sistemas basados en redes más convencionales por una serie de características relacionadas con la inteligencia del sistema. Por una parte, permiten a los usuarios operar en múltiples entornos y también preven la posibilidad de operar una conexión por persona adulta, lo que supone la infraestructura de un sistema de alta capacidad; por otra parte, PCS tiene que proporcionar acceso a determinados servicios personalizados, independientemente de la localización del usuario. Para poder alcanzar este objetivo, PCS debe integrar las redes actuales con las futuras, sean cableadas o con acceso mediante radioenlace y al mismo tiempo, soportar un seguimiento de las comunicaciones de forma global. Como consecuencia de la interconexión de multiples operadores en un entorno abierto, se requerirá la provisión de los adecuados servicios de seguridad al sistema. En los sistemas PCS está previsto el empleo de servicios multimedia de alta calidad; de esta forma, se pretenden proporcionar determinados servicios multimedia ofrecidos en redes cableadas como RDSI, en entornos de comunicaciones móviles, proporcionando la misma calidad. Esta provisión de nuevos servicios admitirá múltiples tipos de usuario y se ofrecerán de forma personalizada, es decir, con requerimientos y características distintas para cada uno de el los. El sistema admitirá un único número PTN (Personal Telecommunication Number ). ). Este número constituye la base de la movilidad personal. El usuario puede ser localizado en cualquier parte e independientemente de los dispositivos que esté utilizando a través de este número. De esta forma, con un único y pequeño terminal se puede tener acceso a todos los servicios disponibles del sistema. Las funciones que realiza una red PCS pueden clasificarse en los siguientes cuatro grupos: funciones de gestión de recursos radio, funciones de gestión de movilidad, funciones de gestión de llamada y funciones de gestión de datos (datos referidos a información interna de la red). Las funciones de gestión de recursos radio están relacionadas con la parte del radioenlace de una red PCS, y gestionan los recursos radio (frecuencia, slots temporales, código, etc.) asignación, monitorización de las características del canal e información sobre la transmisión de la señal. Las funciones de gestión de movilidad se realizan en las capas de transporte y de inteligencia de la red. Estas funciones son claves para proporcionar un seguimiento global y alta calidad de servicio. La gestión de movilidad consiste en el registro de localización, renovación de localización, búsqueda y traspaso del móvil. Las funciones de gestión de llamada incluyen el establecimiento de llamada, la terminación, la monitorización y el encaminamiento de llamadas, la autentificación, el cifrado, el descifrado y las
funciones de supervisión. Por último, la gestión de datos corresponde a la lista de funciones que se encargan de almacenar, obtener, renovar y mantener varias formas de información asociada con el uso de recursos de la red, perfiles de servicio, tarificación, etc. De estas cuatro funciones, la gestión de recursos y las funciones de gestión de movilidad son las exclusivas de sistemas basados en PCS y las que permiten un seguimiento global de los usuarios, proporcionándoles servicios de cali dad. Teniendo en cuenta estos cuatro grupos de funciones de red definidos, la red puede subdividirse en tres niveles lógicos: el nivel de acceso, que proporciona el método de acceso, el nivel de transporte, que se encarga de realizar las funciones de conmutación y de transmitir la información de usuario y de la señalización, y el nivel inteligente, que realiza gestión de red y control de servicio. Tomando como referencia esta arquitectura lógica formada por tres niveles, se han propuesto diversas arquitecturas de red. La arquitectura que actualmente se está desarrollando en Europa está basada en los estándares GSM/DCS1800, con el soporte de la interfaz UPT. El sistema celular digital DCS1800 es un estándar desarrollado por el ETSI que está basado en el GSM900 y que se diferencia de éste en tres elementos fundamentales: la frecuencia de operación (1710-1785, 1805-1880 MHz con 375 portadoras), las potencias de pico de 1000 mW y 250 mW, definiendo pequeños terminales portables, y, por último, la posibilidad de realizar un seguimiento a nivel nacional entre operadores que dispongan de solapes en sus coberturas. Uno de los problemas actuales más importantes que se plantea en Estados Unidos es la compatibilidad del estándar PCS1900, basado en GSM, y el estándar de señalización IS-41 para el desarrollo de sistemas PCS. Existen diferencias importantes entre ellos, como por ejemplo la introducción de algoritmos de privacidad y autentificaciones diferentes o la señalización necesaria para la interconexión entre sistemas al invocar procedimientos de movilidad (p.e. protocolo MAP en el handover ). ). El comité del T1P1 desarrolla el estándar PCS en Estados Unidos y lo define como un conjunto de capacidades que permiten una combinación de movilidad de terminal, movilidad personal y gestión de perfil de servicio. Sin embargo, en otras ocasiones, este término se usa para cubrir varias formas de accesos radio y servicios de movilidad personal. Se ha asignado para PCS un nuevo espectro con una franja de 140 MHz en los 1900 MHz (FCC 47 CFR Part 15). A partir de ahí, se han definido 51 bandas MTA (Major Trading Areas), que corresponderían geográficamente aproximadamente a estados, y 492 bandas BTA (Basic Trading Areas), que corresponderían a condados. Además de las licencias para sistemas terrestres se han asignado 20 MHz para aplicaciones sin licencia (10 MHz para tráfico asíncrono como redes de paquetes no cableadas y otros 10 MHz para tráfico síncrono, como puede ser la voz). Otros grupos de estandarización que desarrollan actualmente o que han trabajado en sistemas PCS son el TR-46 que está bajo la supervisión de la TIA y es responsable de servicios y protocolos PCS; el T1S1, que está supervisado por ATIS (Alliance for Telecommunications Industry Solutions) y se responsabiliza de protocolos de señalización; el T1M1, que está también supervisado por ATIS, y se ocupa de operaciones, administración, mantenimiento y provisión (OAM&P); y, por último, un comité técnico conjunto de T1P1 y TR-46 para proporcionar una interfaz común. La FCC (Federal Communications Commission) es el organismo encargado de asignar licencias para operar en el espectro PCS según normativas del JTC (Joint Technical Committee). El JTC distingue entre dos categorías de sistemas: celular digital e inalámbrico digital. Recientemente, el JTC ha pasado en su selección, de 16 posibles estándares a 7, cinco de los cuales son variaciones de los radioenlaces actuales: PACS, GSM, IS-54, IS-95 y DECT, mientras que los otros dos son aproximaciones híbridas TDMA/CDMA y de banda ancha en CDMA (W-CDMA), según se ve en la
tabla 11.2. El IS-136 es otro estándar muy reciente, en fase de estudio, y que supone una mejora respecto al IS-54 considerado en la tabla comparativa. Los estándares anteriores pueden clasificarse en cuatro importantes grupos: GSM (PCS1900), CDMA (IS-95), TDMA y PACS. El sistema PCS1900 está siendo utilizado ya por pequeños operadores para conseguir cuota de mercado rápidamente en los Estados Unidos. Se trata de una tecnología basada en el GSM y, por tanto, plenamente operativa. Respecto a otros sistemas como los basados en CDMA presenta mayores costes de mantenimiento ya que requiere más estaciones base y una más rigurosa gestión de las frecuencias. Los sistemas basados en CDMA (p.e. IS-95) preven una entrada en funcionamiento más a largo plazo. Se trata en principio de un sistema superior aunque en la práctica está teniendo muchas dificultades. Tiene la ventaja de que su plan de frecuencias es más simple y la cobertura es similar a los sistemas analógicos actuales, con 4 ó 5 veces la capacidad de éstos. Los operadores, deseosos de expandir el espectro de radio existente, optan por soluciones TDMA, como el TDMA IS-54B, que es una extensión digital del estándar analógico anterior, o el TDMA IS-136, que está siendo elegido por diversos operadores americanos importantes. Por último, el sistema PACS está previsto que funcione en bucles locales no cableados a bajo coste.
Método de acceso Método dúplex Bw Bit-rate (sin enc.) Gan. prc Guarda canales Canales voz/port. Refer. a AMPS Modulac.
Híbrido (nuevo)
Basado IS-95
CDMA/ TDMA/ FDMA TDD
PACS
Basado IS-54
CDMA
TDM/ TDMA
TDM/ TDMA
TDMA
TDMA
D-CDMA
FDD
FDD
FDD
FDD
TDD
FDD
5 MHz 32 Kbps
1.2MHz 8/13.3 Kbps
300 KHz 32 Kbps
30 KHz 7 Kbps
200 KHz 13 Kbps
1728Khz 32 Kbps
5 MHz 32 Kbps
21 dB 5 MHz
21 dB 1.25 MHz
300 KHz
30 KHz
200 KHz
1728 KHz
21 dB 5 MHz
20
8
3
8
12
128
16 X
10 X
0.8 X
3X
2-3 X
0.2 X
16 X
OQPSK/ QPSK FEC N=1 200 mW
Pi/ 4 d-QPSK Ninguno 16x1 12.5 mW
GMSK
GFSK
FEC 7x3 100 mW
FEC 7x1y 3x3 125 mW
OQPSK/QP SK Ninguno 9 20.8mW
FEC 1 500 mW
50 ms 50 ms No Tasa var. (8/4/2/1)
100 mW 312.5 ms 9 ms 9 ms No ADPCM 32Kbps
600 mW 6.7 ms 110 ms 110 ms Sí VSELP (8Kbps) LDCELP 16Kbps
1W 577 ms 90 ms 90 ms Sí RPE-LTP 13 Kbps
Fase cont salto QM Err.(voz) Ninguno Reuso fr. N=3 Pot. max media Pot. slot Lg.trama Lg. Tslot Ret. voz Ecualiz. Vocoder
1W 625 ms 80 ms 80 ms No CELP (8Kbps) ADPCM (16,24, 32,40)
en
en Basado en Basado DCS-1800 DECT
en
250 mW 417 ms 28 ms 28 ms No ADPCM 16-32 Kbps
Tabla 11.2 Esquema resumen de los sistemas de radioenlace candidatos para soportar PCS
El ámbito de actuación del comité JTC incluye el desarrollo de documentos técnicos para la definición de estándares sobre las funcionalidades de la interfaz aire, proporcionando acceso a redes de telecomunicaciones para servicios de comunicaciones móviles y PCS. Los trabajos incluyen el estudio de las consideraciones electromagnéticas en las interfaces, y pueden incluir aspectos relacionados con la capa física de transmisión, el acceso al medio, y los protocolos de señalización. Las actividades del JTC también tienen impacto sobre las actividades desarrolladas por el grupo ITU-R TG 8/1, que es una organización internacional que elabora recomendaciones para el futuro sistema FPLMTS. De forma simultánea, se está desarrollando todo un nuevo conjunto de interfaces de aplicación sobre los sistemas PCS; entre éstas se pueden considerar las comunicaciones inalámbricas residenciales y públicas, las PABX inalámbricas, las redes digitales celulares, las redes micro-celulares, las redes celulares analógicas, la radio móvil especializada, FPLMTS, UPT, el uso de satélites, etc. Todos estos sistemas requieren de su integración en una red inteligente. En el diseño de estos sistemas resulta fundamental la selección de una estructura idónea de la red que permita la movilidad de los usuarios según unos adecuados criterios de prestaciones. Actualmente, en Estados Unidos se consideran dos modelos de referencia para redes PCS, el TR-46 y el T1P1, que a su vez son convertibles entre sí. En el modelo T1P1 los datos de usuario y los datos del terminal están separados, es decir, los usuarios pueden comunicarse con la red vía terminales personales de radio diferentes. En el modelo de referencia TR-46, utilizado anteriormente por sistemas analógicos celulares, sólo se soporta movilidad de terminal [12]. En Europa, los estándares presentan diversas soluciones que se basan, por ejemplo, en el carácter más o menos distribuido de sus nodos (caso del futuro sistema UMTS frente al GSM). A continuación, se describen brevemente los modelos de referencia PCS a los que se ha hecho referencia r eferencia anteriormente. 1850 MHz
1910 MHz 1920 MHz
Licencias para banda ancha PCS
Asín Asíncr cron onoo
1930 MHz
Sínc Síncro rono no
1990 MHz
Licencias para banda ancha PCS
Banda PCS sin licencias
Fig. 11.5 Espectro de frecuencias asignado a PCS 11.2.1.1 Modelo de referencia TR-46
Los principales elementos de este modelo de referencia se muestran en la figura 11.6, y se describen a continuación: se define una estación personal ( Personal Station, PS) como un dispositivo que puede estar conectado o no a otros equipos (como ordenadores, fax,...) y que permite tener acceso a servicios de la red a través de un radioenlace. El sistema de radio ( Radio System, RS), a menudo llamado estación base, se compone de una BTS ( Base Transceiver System ) y de un controlador, BSC ( Base Base ). Station Controller ). Se define un PCSC ( Personal Communications Switching Center ) que sirve de interfaz entre el tráfico de usuarios procedente de las redes móviles con el de las redes cableadas. Se definen unas bases de
Home Location Register ) a semejanza de GSM, si bien datos VLR (Visited Location register ) y HLR ( Home ésta última puede ser distribuida.
Otros elementos que se contemplan en el modelo son un gestor de mensajes de datos ( Data Message Handler, DMH) usado para tarificación, un centro de autentificación ( Authentication Center , AC), un registro para equipos robados ( Equipment Identity Register , EIR), un sistema para operaciones (Operations System, OS) para la gestión de la red y una función de interconexión para posibilitar la comunicación entre otras redes ( Interworking Function, IWF). 11.2.1.2 Modelo de referencia T1P1
La arquitectura del modelo T1P1, según se muestra en la figura 11.7 es similar a la anterior; sin embargo, existen algunas diferencias que se describen a continuación: El terminal móvil o RPT ( Radio Radio Personal Terminal) es idéntico a la PS del modelo TR-46. El RP ( Radio Radio Port ) es idéntico a la BTS del modelo TR-46. El RPI ( Radio Radio Port Intermediary) proporciona una interfaz entre uno o más RPs y el controlador. El RPC ( Radio Port Controller ) es el controlador y es idéntico a la BSC del modelo TR-46. También se define un RASC ( Radio Access System Controller ) que realiza las funciones de control y conmutación en la parte específica de radio. En la parte de la red fija se define el centro de conmutación PSC ( PCS Switching Center ) que es similar al PCSC del modelo TR-46; el controlador de movilidad TMC ( Terminal Mobility Controller ), ), que proporciona el control lógico para el terminal; la base de datos TMD ( Terminal Mobility Data Store), que mantiene los datos asociados al terminal de forma similar a la VLR; el controlador de movilidad personal PMC ( Personal Mobility Controller), que proporciona el control lógico para el usuario. El PMD (Personal Mobility Data Store), que mantiene los datos de usuario asociados de forma similar al HLR del modelo TR-46. Se definen también un sistema OAM&P de manera idéntica al OS del TR-46 T R-46 y finalmente una función para interconexión, IWF ( Interworking Function). OS
Fig. 11.7 Modelo de referencia T1P1 11.2.2 Servicios PCS
Los servicios que se definen aquí están basados en el protocolo MAP, soportado por el estándar para señalización de interconexión IS-41. Aunque estos servicios están definidos para los sistemas norteamericanos presentan grandes similitudes con los proporcionados por el sistema GSM. En la fase dos del T1P1 se definen una serie de servicios básicos que pueden agruparse de la siguiente forma: Servicios básicos Funciones de registro y desregistro de la PS (Personal Station) al sistema PCS
- registro automático - autentificación de terminal y privacidad (usando clave privada) - autentificación de terminal y privacidad (usando clave pública) - autentificación de usuario y validación - registro personal automático - desconexión del registro personal automático - registro personal - desconexión del registro personal Funciones para la comunicación interna entre la red PCS visitante y la red PCS en la que el usuario está abonado. Funciones de seguimiento del terminal entre diversas redes P CS. Procedimientos de establecimiento, continuación y liberación de l lamada.
- origen de la llamada - distribución de la llamada - liberación de la llamada - llamadas de emergencia (E911) - handover
Los servicios suplementarios se definen en el estándar IS-104 (Personal Communications Service para 1800 MHz. El IS-41 C define también servicios, pero sólo están disponibles cuando hay un seguimiento del móvil. Otros servicios podrían ofrecerse únicamente por determinados sistemas PCS. Estos servicios son:
Descriptions)
Rellamada automática, llamadas a cobro revertido, mantenimiento y devolución de llamada, redirección de llamada (por defecto, ocupado, no respuesta, incondicional), transferencia de llamada, llamada en espera, presentación de la identificación del número que llama, restricción a la identificación del número que llama, multiconferencia, no molestar, alerta flexible, notificación de mensaje en espera, prioridad de acceso, prioridad multinivel, aceptación de password, preferencia de lenguaje, acceso prioritario por asignación de canal, llamadas remotas, aceptación de llamada selectiva, acceso e intercepción de PIN, llamadas con tres usuarios, mensaje de voz pregrabado, privacidad de voz y servicios de mensajes cortos. Estos servicios tienen que poder proporcionarse estando el terminal en movimiento, para lo cual es necesario una adecuada gestión de movilidad por parte de la red de acceso del sistema. A continuación se expone la solución más común adoptada actualmente. 11.2.3 Gestión de movilidad
Uno de los aspectos fundamentales en sistemas PCS es cómo se gestiona la movilidad. Esta gestión se mantiene actualmente a partir de una estructura formada por dos tipos de bases de datos con dos niveles jerárquicos (basados en GSM o bien en el sistema americano de señalización IS-41). La configuración más normal dispone de una única HLR ( Home Location Register ) que es un registro de localizaciones en el cual se almacena la identidad del usuario móvil para propósitos de información del usuario móvil (p.e. número en el directorio, información de perfil, localización actual o periodo de validación) junto con varios VLR asociados ( Visitor Location Register ). ). El VLR es otro registro de localizaciones temporales (de visitantes) usado para obtener información en el establecimiento de llamadas a/o desde un usuario móvil visitante. Los sistemas más avanzados como UMTS dispondrán de una arquitectura de bases de datos distribuida jerárquicamente que permitirá una gestión de la movilidad de los usuarios con una carga de señalización y retardos menores. En el último punto se explica con más detalle este tipo de sistemas. Esta gestión de movilidad se apoya, pues, en unos recursos que se estructuran de manera diferente según los requerimientos de los usuarios y las capacidades de la red. 11.2.4 Gestión de recursos
La gestión de recursos incluye en general la asignación de recursos y el acceso tanto en la red fija como en la red móvil. Aquí se describirá lo que ocurre en la parte de la red móvil. Una forma de asignar recursos es mediante esquemas de acceso múltiple. Estos tipos de esquemas se utilizan para compartir entre un grupo de usuarios un canal común de subida de forma que se mejora la capacidad del sistema y disminuye su coste. Existen tres características básicas para el diseño del acceso en un sistema PCS: flexibilidad, calidad y capacidad. La flexibilidad se refiere a la capacidad de manipular voz integrada, datos y tráfico de vídeo, tratando con la capacidad de seguimiento del
usuario. La calidad significa satisfacer requerimientos de servicio, tales como el retardo y/o la acotación de la pérdida de paquetes. La capacidad significa que el número de usuarios con servicio tendría que ser máximo para el ancho de banda dado. No siempre es fácil llegar a un buen compromiso entre estos factores. En las redes futuras de tercera generación se exigirán redes inteligentes integradas, tanto en el acceso móvil como en la red fija. Por ejemplo, si se considera un cluster de celdas en una determinada área geográfica, un gran operador de telefonía celular podría dar cobertura con celdas a muchas carreteras, otro a la red ferroviaria, otro operador a diversos edificios de oficinas limítrofes, etc. Para disponer de un entorno de gestión común eficaz, donde la optimización en la cobertura de las celdas, y la asignación de canales y de recursos en la red sea posible conjuntamente para las más diversas necesidades de tráfico cambiantes se necesitaría la integración de los múltiples sistemas coexistentes en una única red inteligente. Esta integración de subsistemas para gestionar recursos en la red requiere de la especificación de un método de acceso que permita obtener la adecuada sinergia al conjunto de la red. 11.2.5 Métodos de acceso en PCS
Los esquemas de acceso múltiple pueden clasificarse en tres tipos: de acceso aleatorio, de asignación fija y de asignación por demanda. El acceso aleatorio en PCS puede resolverse mediante mecanismos como ALOHA y CSMA/CD, ya conocidos, o bien mediante técnicas de acceso CDMA, en donde se comparte todo el ancho de banda. En los sistemas de asignación fija las transmisiones son coordinadas completamente por la estación base y ésta asigna la frecuencia con el canal correspondiente a cada terminal. Éste es el caso de los métodos de acceso basados en FDMA o TDMA. Cuando el acceso es por demanda de una asignación, existen distintos métodos que requieren explícitamente de control, como D-TDMA, PRMA, DRMA o DH-TDMA. Estos métodos de asignación se basan en el hecho que las conversaciones de voz consisten en franjas temporales de actividad (talkspurts) seguidas de saltos con silencios. Durante las fases de silencios no se genera información y los recursos de canal pueden utilizarse para otros usuarios de forma que puede obtenerse mediante multiplexación una gran eficiencia. Por último, pueden distinguirse una serie de métodos de asignación de canal que administran los recursos desde una perspectiva global por parte de la red para conseguir una eficiencia óptima del espectro. Este es el caso de estrategias como la macrodiversidad, el préstamo de canales, la asignación dinámica de canales (DCA), o bien funciones de coste que tengan en cuenta el estatus de la red, etc. Junto al método de acceso es necesario especificar la pila de protocolos de señalización utilizados en las distintas interfaces del modelo de referencia de la red para que ésta pueda proporcionar los servicios PCS adecuados al usuario. 11.2.6 Protocolo de señalización
El protocolo de señalización asociado a PCS está basado en el SS7 de la ITU y se recoge en las recomendaciones Q.1061 y Q.1062. SS7. Es un protocolo altamente fiable, que utiliza enlaces a 64 Kbps en Europa y de 56 Kbps en Estados Unidos. La introducción de la nueva carga de señalización
asociada a los servicios PCS será 3 o 4 veces superior a la asociada a sistemas móviles como GSM, que ya de por sí es importante. Los tres niveles más bajos del protocolo de señalización propuesto son el nivel físico, nivel de enlace y el nivel de gestión. El nivel físico se encarga de la transmisión de la información en cada uno de los canales, proporcionando los canales lógicos para las capas superiores. El nivel de enlace implementa las funciones de control de errores para el entorno de radioenlaces, así como para los entornos cableados convencionales. El tercer nivel comprende tres entidades funcionales definidas como: gestión de recursos radio (RR), gestión de movilidad (MM) y gestión de conexiones (CM). La introducción de la IN (Intelligent Network), proporciona independencia del servicio separando la secuencia de control de éste de la gestión de los recursos de red. Para gestionar la movilidad en PCS se introduce el MAP (Mobile Application Part) situado en el nivel de aplicación de SS7. La implementación de un MAP requerirá el uso del concepto del Application Service Element (ASE) de IN. Éste se define como un conjunto de funciones de aplicación que proporcionan capacidad para la interconexión de entidades de aplicaciones con un propósito específico, según se observa en la figura 11.8. El protocolo MAP es realmente un ASE basado en el TCAP (Transaction Capability Application Part). Éste está formado por dos subcapas, el subnivel de componentes y el subnivel de transacciones, correspondiente al nivel de aplicación. MAP también requiere el soporte de la parte de control de conexiones de señalización SCCP (Signalling Connection Part) y del MTP (Message Transfer Part) del SS7. En Estados Unidos se esta definiendo también el estándar T1M1 PCS OAM&P para el tratamiento de operaciones, la administración, el mantenimiento y la disposición de costes para redes basadas en PCS. En Europa, el GSM tiene su propia normativa a partir de las 12 series de especificaciones definidas por ETSI. 11.2.7 Red inteligente para servicios personales en redes de comunicaciones móviles avanzadas
Para las comunicaciones móviles personales se necesitan todas las funciones de la red inteligente usuales en las redes de cableado fijo, más otras relacionadas con la movilidad de servicio del abonado y en la gestión de la llamada. Éstas incluyen la obtención y renovación de información de localización, autentificación, encaminamiento de llamadas, traspaso, tarificación y mantenimiento. Estas funcionalidades de servicio adicionales causarán un dramático aumento en el tráfico de señalización, especialmente en los entornos de microceldas con altas densidades de terminales móviles con frecuentes renovaciones de localización. Los sistemas de telefonía móvil actuales incorporan las funciones mencionadas anteriormente mediante dos redes inteligentes interconectadas, una para el sistema móvil y otra para la red fija a la que está conectada (p.e. RDSI). En el caso de los procedimientos de movilidad, el estándar de red inteligente CS-2 (series Q.1200 de la ITU-T) tendrá que adaptarse a una arquitectura distribuida soportada por múltiples funciones de control de servicio (SCF's). Esto es un camino necesario para evitar señalización innecesaria en la red y minimizar los retardos incurridos. Por otra parte, dadas las características de red avanzada que puede soportar PCS, se está diseñando un terminal móvil tal que sea un terminal inteligente multimodo capaz de adaptar sus subsistemas de
radio dependiendo del servicio requerido, la carga de teletráfico y el estatus del radiocanal. Este terminal móvil dispondrá de lector de tarjetas inteligentes para la provisión de los parámetros de seguridad y los datos relativos al abonado. Esta aproximación proporciona flexibilidad a operadores de red y a proveedores de servicio, permitiendo evolucionar según progrese la t ecnología.
MAP ASE
Proceso de aplicación ASE
ASE
ASE Entidad de aplicación
TCAP
Subcapa de componentes Subcapa de transacciones
SCCP
MTP Fig. 11.8 Protocolo MAP en ITU/SS7
11.3 Funciones de gestión. Objetos gestionados
Dentro de las recomendaciones de red TMN existe un apartado para GSM. El grupo SMG6 del ETSI definió unas interfaces Q3 entre el sistema de operación y los elementos de red. Se especificaron aspectos de Q3 relacionados con las cinco áreas funcionales definidas por la ITU. En las áreas de gestión de configuración y de fallos, la cobertura se limitó a la BSS. Otros elementos de red como VLR y HLR se trataron más en relación a la gestión de tarificación. La MSC no se consideró estrictamente un elemento de red GSM y su definición se dejó para más adelante. En cuanto a gestión de seguridad, no se contemplaron especificaciones nuevas, considerando que ya se habían definido suficientes funcionalidades. En general el modelo GSM puede estructurarse en tres tipos de objetos. Uno representa puramente los recursos funcionales. El segundo tipo representa objetos que son recursos funcionales se relacionan generalmente con el equipo. El tercer tipo son aquellos objetos que representan recursos de equipo
directamente. En total, existen más de 100 clases de objetos gestionadas, definidas con casi 500 atributos. La definición de los managed objects (M.3100 de la CCITT) se encuentra en la serie 12 de GSMETSI. Estos managed objects soportan la interface Q3. Las clases de objetos que son top en el diagrama de contención son las siguientes: BssFunction, hlrFunction, vlrFunction, mscFunction, aucFunction, eirFunction, callRecordingFunction, sms_G_IWFunction. Otros objetos gestionados comunes son: simpleFileTransferControl, generalDataTransferControlFunction, gsmEquipment, etc. 11.4 Red inteligente y sistemas de comunicación móviles 11.4.1 Características de los servicios UPT
Dentro de los sistemas de comunicación personal que se espera tengan mayor implantación en Europa, la que está más desarrollada en especificaciones es la interfaz UPT. Además, actualmente UPT se nutre también de recomendaciones generadas por la ITU. Por eso en este apartado se describirán sus características principales. En entornos UPT se permite a los usuarios UPT realizar y recibir llamadas en cualquier terminal, fijo o móvil conectado a cualquier red. Esto es la base de la movilidad personal. En cambio, la movilidad personal en PCS se incorpora como una mejora en la movilidad de terminal de una red móvil (Fig. 11.9). Una de las características fundamentales de UPT es la portabilidad de servicio. En este caso, se permite a los usuarios invocar servicios a los que se está abonado desde cualquier terminal en la red. Sin embargo, el tipo de terminal y las capacidades de la red con las que se opera podrían limitar las características del servicio que se solicita. Para poder disponer de movilidad personal se requiere de un número personal (o número personal UPT) que permita identificar de manera única y directa a un usuario independientemente del terminal utilizado. El número personal UPT se utiliza, pues, para realizar y recibir llamadas, así como para su tarificación. Este número UPT será utilizable desde cualquier terminal fijo o móvil con las restricciones que impongan los operadores de red, la capacidad de la red en cualquier lugar teniendo que ser conectable y enrutable desde cualquier red bajo una perspectiva global. Por tanto, se puede decir que un usuario UPT es un usuario abonado a este servicio con un único número. En la recomendación E.168 de la ITU-T se muestran cuatro esquemas de numeración para UPT o aproximaciones basadas en la recomendación E.164 de la ITU-T. El número UPT sirve como puntero para indicar un registro o fichero donde se ubica información relativa al usuario y a los servicios a los que está abonado. Esta información tiene una parte que es fija (servicios abonados, tarificación, restricciones de movilidad, etc.) y otra parte variable (direcciones, posición, encaminamientos,...). Un usuario, según los acuerdos a que haya llegado con el proveedor de servicio y según las capacidades de la red, tendrá la posibilidad de leer o escribir en su perfil de servicio UPT. El uso de tarjetas inteligentes en redes móviles permite distinguir un tercer tipo de movilidad, distinta de las anteriores (de terminal y personal). Un ejemplo bien conocido de tarjeta inteligente es el Subscriber Identity Module (SIM) utilizado en GSM. Este tipo de movilidad de tarjeta SIM es análoga
a la movilidad de terminal, pero proporciona una especie de servicio de movilidad personal dentro de la red GSM. Las tarjetas inteligentes se utilizarán en las futuras redes de tercera generación como UMTS o IMT2000 permitiendo múltiples aplicaciones en entornos de red inteligente. Su uso puede servir como un posible método de acceso para acceso a UPT o autentificación en redes de comunicaciones móviles basadas en la movilidad personal. Las especificaciones UPT le permiten soportar un gran conjunto de servicios. Es previsible su implantación progresiva en sucesivas fases, conforme avance la tecnología y aumente la demanda del mercado. En una primera fase se desarrolla el conjunto de servicios UPT 1 para ser utilizados en la parte nacional, (recomendación ANSI T1.701), o bien a nivel internacional (recomendación F.851 de la ITU-T). Esta primera fase de UPT soporta el servicio telefónico sobre redes públicas analógicas convencionales, redes móviles y RDSI. Análogamente, el conjunto de servicios UPT 2 se sitúa en un escenario más avanzado, todavía en fase de especificación y desarrollo, tanto a nivel nacional como internacional [10]. El desarrollo de UPT requiere de una tarificación, un encaminamiento de llamadas, diversas facilidades en torno a las bases de datos, etc. que hacen necesaria la introducción de cambios en la red. Para facilitar este proceso se requerirá la potenciación conjunta de las redes inteligentes así como de una adecuada señalización, basada en el SS7. Características de los servicios UPT 1
A continuación, se describen brevemente las facilidades proporcionadas por el conjunto de servicios definidos en la fase 1 de las recomendaciones UPT. Autentificación de la identidad de usuario UPT: esta utilidad permite al proveedor de servicio UPT verificar la identidad de un usuario UPT. -
Registro de llamadas entrantes: esta utilidad permite al usuario UPT registrar todas las llamadas entrantes a una determinada dirección de terminal fijo o móvil. -
Llamadas UPT salientes: esta facilidad permite al usuario UPT realizar llamadas salientes desde cualquier terminal, fijo o móvil, previa autentificación de usuario. -
Seguimiento de llamadas salientes: esta facilidad permite al usuario UPT, antes de terminar una llamada saliente UPT a indicar la invocación de otro establecimiento de llamada sin necesidad de autentificación. -
Distribución de llamadas entrantes: es una facilidad de la red que permite presentar en pantalla de un terminal las llamadas UPT entrantes a un determinado usuario UPT que previamente se haya registrado. -
Características opcionales de los servicios UPT 1
Estas facilidades tratan de complementar los servicios establecidos en la fase 1 de UPT. Todos ellos son opcionales y su implementación dependerá de las características del terminal, de la red, así como de las condiciones impuestas por el proveedor de servicio.
- Registro de llamadas salientes: el registro de llamadas salientes permite a los usuarios UPT realizar llamadas salientes desde una determinada dirección de terminal; para ello, el terminal ha sido previamente personalizado, autentificado y las llamadas son cargadas al correspondiente número UPT. - Registro de todas las llamadas: esta utilidad permite al usuario UPT combinar el registro simultáneo de llamadas entrantes y salientes. - Registro de llamadas remotas entrantes, salientes y
totales: esta utilidad permite registrar todo tipo de llamadas a la dirección de un terminal remoto desde otro terminal. Seguimiento global: esta facilidad permite a un usuario UPT, previa autentificación y uso de servicios UPT, indicar una actividad de seguimiento antes de una desconexión total. -
Registro de llamadas entrantes por defecto variable: esta utilidad permite a un usuario UPT a tener una serie de registros por defecto para poder atender llamadas entrantes según diferentes horarios u opciones personales. -
- Interrogación de perfil de servicio UPT: esta facilidad permite a un usuario UPT el consultar los datos relativos a su propio perfil de usuario. Modificación de perfil de servicio UPT: esta facilidad permite a un usuario UPT el consultar y /o modificar los datos relativos a su propio perfil de usuario, como puede ser el password u otros paramétros de servicio. -
11.4.2 Seguridad en la red
Desde el punto de vista de seguridad, en UPT se tienen en cuenta dos situaciones importantes que pueden constituir amenazas para el sistema. En el primer caso, se trata de la fase en la que se proporcionan servicios de comunicación, en donde los datos relativos a un usuario UPT, tales como su identidad, número, posición, etc. son transmitidos desde unas bases de datos a otras con lo que debe asegurarse su privacidad y protección. En el segundo caso, se trata del proceso de verificar la identidad de un usuario UPT. Se realiza mediante la ayuda de una clave privada de autentificación (p. e. con un PIN) que es un número que permite autentificarse mutuamente el usuario UPT y el proveedor del servicio. 11.4.3 Servicios UPT de red inteligente sobre red GSM
En este apartado, como caso especial, se estudia la integración que supone una interfaz que proporciona comunicaciones personales como UPT en un sistema de comunicaciones móviles de gran implantación actual en Europa como es GSM. En este caso, la introducción de los servicios UPT en la red requiere de mayores capacidades en las bases de datos asociadas así, como una mayor funcionalidad de inteligencia desde la infraestructura de la red PSTN que la soporte. El modelo funcional UPT está basado en el estándar de arquitectura de red inteligente a causa de su gran flexibilidad en la creación de servicios. De esta forma, UPT puede integrarse en plataformas sobre GSM que dispongan de servicios de red inteligente. A continuación se analizarán los pasos que se deben efectuar para introducir los servicios UPT en la red GSM.
En primer lugar se describirán el conjunto de modificaciones que se deben realizar en la estructura funcional de una red inteligente, (Fig. 11.9) para soportar el conjunto de servicios UPT. Estas funciones del sistema pueden dividirse desde un punto de vista geográfico en elementos originantes, de abonado y elementos terminantes. Desde un punto de vista lógico se dividen en un control de llamada, control de servicio y funciones de gestión. En la figura 11.10 se muestra la arquitectura funcional en la interfaz UPT. Para una adecuada integración de las redes, se requieren una serie de cambios en las funcionalidades relativas al establecimiento de llamada. Concretamente, la función del agente de control de llamada UPT (CCAF) requiere de una combinación específica por parte del terminal usado, el dispositivo UPT y la funcionalidad de red para proporcionar acceso al servicio UPT. Desde el punto de vista de los terminales existentes, incluyendo GSM, sólo pueden hacerse cambios mínimos en CCAF. Desde un punto de vista ideal, UPT no impone requerimientos especiales en la función de control de llamada (CCF). Esto se debe a que la señalización a partir de pulsos decádicos puede convertirse en señales DTMF e información relacionada con el protocolo de señalización SS7, tal como de línea llamante o de identidad de línea llamada, debe ser soportada por todas las redes. Esto es posible en GSM. Siguiendo con los elementos descritos en la figura 11.10, dentro de las funcionalidades relacionadas con la operación de servicios, la función de conmutación de servicio (SSF) permite interrogar a la función SCF y así recibir una respuesta, que permite el intercambio de servicio de forma correcta. Algunos servicios UPT (p. e. registro para llamadas salientes), podrían requerir que la funcionalidad SSF sea soportada tanto a nivel de central local como a nivel de tránsito. En el Mobile Switching Centre (MSC) de GSM, actuando como central local, es posible registrar llamadas salientes para un cierto periodo de tiempo siempre que éste conozca el estatus de línea. Los mismos resultados se podrían obtener si se consiguiera integrar la SSF, función de conmutación de servicio en la MSC. La función de control de servicio (SCF) contiene el servicio lógico para UPT y es capaz de realizar todo tipo de consultas a la base de datos desde otras redes. La función de datos de servicio (SDF) contiene información relacionada con el servicio y el abonado UPT. Esta entidad necesita un estudio más profundo que permita diseñar una estructura estándar fácilmente utilizable en los procesos de autentificación, perfil de servicio, información de localización, etc. En esta reflexión parece muy recomendable estudiar las especificaciones diseñadas para GSM que pueden ser de utilidad en el proceso de integración y seguramente evitarán esfuerzos redundantes en el diseño. Existen otras funciones también necesarias como son la función de recursos especiales (SRF), que traduce las señales DTMF para el SCF, y las peticiones SCF en anuncios vocales para el usuario. Otra función de interés es la que permite la creación de servicios (SCEF): su principal misión es la definición, creación, y comprobación del servicio UPT. Los procedimientos UPT no relacionados con la llamada en la red inteligente pueden manipularse de dos formas diferentes: - El usuario interactúa con el mismo terminal que utiliza para realizar o recibir llamadas, y la información pasa a través de las funciones CCAF, CCF, SSF, SCF y SMF (función de gestión de servicios). - El usuario interactúa con un terminal dedicado a la gestión de servicio, y la información pasa a través de la función de acceso de gestión de servicio (SMAF), SMF, SCF, y SSF.
Desde un acceso PSTN, el primer método se usa para procedimientos simples, que se realizan frecuentemente desde distintas situaciones, tales como procedimientos de movilidad personal. El segundo método se usa en procedimientos más complejos (p.e. gestión de servicios), que se justifican en pocas situaciones. El objetivo a largo plazo es que el acceso a RDSI pueda utilizarse para todos los procedimientos de gestión. Al principio, en GSM se prevee, por su simplicidad, el primer método. Esto implica que la SMF sería flexible para permitir el uso de varios procedimientos de gestión de servicios como pueden ser la modificación de perfil de servicio, el chequeo de los límites de crédito, la tarificación, las estadísticas, etc. Es imprescindible definir la interfaz entre un usuario UPT y el sistema GSM, puesto que en general un abonado UPT requiere disponer de un acceso para operar en la red, es decir, registrar y realizar llamadas entrantes / salientes, o bien modificar el perfil de servicio, incluyendo el encaminamiento según hora del día, lista de preferencia de usuarios llamantes, opción de no molestar o de correo vocal si está ocupado. En la primera fase, está prevista la utilización de teléfonos con teclado DTMF, y realimentación vocal. Dado que no es deseable el tecleado de largas secuencias de números, para simplificar el procedimiento de acceso podría usarse la información de la dirección de la línea llamante. En sucesivas fases de desarrollo e implantación de estos servicios se usará una única tarjeta inteligente que permite proporcionar acceso a través de teléfonos públicos así como privados equipados con lectores de tarjetas. Entre estos se pueden incluir los sistemas de comunicaciones móviles tales como GSM, DECT, y avanzados o de tercera generación como UMTS/FPLMTS. El acceso de GSM al servicio UPT se puede efectuar mediante el tecleado de una secuencia de dígitos (incluyendo un código de acceso UPT, un número UPT y un número de identificación personal) y seleccionando el servicio usando un sistema de voz interactivo. Cuando un abonado UPT se registra en un terminal GSM usando un dispositivo DTMF, se enfrenta a un problema, ya que las señales DTMF no pueden soportarse actualmente de forma fiable por los codificadores de voz GSM. Sin embargo, el uso de un dispositivo DTMF permitiría a los abonados UPT y GSM tener sus servicios activos al mismo tiempo. En otras situaciones, es posible que un abonado UPT se registre en un terminal que contenga una tarjeta SIM de otra persona. Si el usuario extrae la tarjeta y realiza un nuevo registro de posición, los registros UPT le siguen a la nueva posición y terminal. Este problema podría evitarse con una desconexión del registro UPT automático. Se pueden realizar ciertas consideraciones de cierto interés y que surgen por la incorporación de funcionalidades UPT en terminales GSM. En las últimas fases de diseño de UPT, el dispositivo que proporciona servicios podría ser del tamaño de una tarjeta SIM. Sin embargo, en este caso sería imposible para el abonado GSM original tener sus servicios simultáneamente activos en el terminal cuando un abonado UPT se registre en éste. Si un abonado GSM y uno UPT se registraran en el mismo terminal, la red sería incapaz de encontrar si una llamada entrante va al abonado GSM o al UPT. Para solucionarlo se requerirían algunos pequeños cambios en las especificaciones de señalización existentes (p.e. un bit para indicar una llamada UPT). Otras cuestiones de relativo interés se refieren a la actuación que deben tener los propietarios de terminales para poder protegerse de los mismos usuarios UPT. Es necesario habilitar una serie de procedimientos que permitan la desconexión del registro de usuarios UPT de una dirección de terminal, así como la protección de la información de perfil de servicio, la tarificación etc. de las bases de datos. Por eso, sería necesaria la verificación de la autorización de entrada al servicio UPT en cada petición.
La provisión de autentificación prevista por medio de la utilización de un PIN parece no muy recomendable. En este caso, una tercera persona podría encontrar el código y usar el servicio a cuenta de los abonados. El problema podría reducirse notablemente si se dispusiera de una tarjeta inteligente UPT/GSM. Una vez se ha analizado la interfaz entre UPT y GSM para tener acceso a diversos servicios UPT se procede a la especificación de los procedimientos para poder soportarlos. Un usuario UPT puede controlar el servicio usando procedimientos UPT estandarizados. En una primera fase, estos procedimientos se efectúan manualmente, por ejemplo, usando el dispositivo de suscripción y mediante apuntes vocales. Todos los procedimientos que se pueden sugerir requieren el uso de ciertos elementos básicos, tales como acceso, autentificación, e identificación del abonado. Como se ha dicho anteriormente, los procedimientos UPT pueden clasificarse en cuatro grandes categorías: procedimientos de movilidad personal, procedimientos de establecimiento de llamada UPT, procedimientos de gestión de perfil de servicio UPT y determinados procedimientos especiales de gestión de red. En el establecimiento de la llamada, el terminal GSM indicaría que un determinado servicio UPT está activo informando al usuario (GSM o UPT). Por ejemplo, una llamada UPT entrante se distinguiría de una llamada GSM ordinaria por un tono de alerta, un apunte vocal con autentificación, o un display especial. En el caso de apuntes vocales, los terminales existentes no requieren modificaciones. Entre los procedimientos especiales de gestión de la red existe el de la facturación de cargos o tarificación del abonado. En el caso de la tarificación de un abonado UPT, ésta se basa en el número UPT. El abonado recibe una sóla factura a pesar de las redes o servicios usados. El operador es libre de ofrecer a sus abonados paquetes de servicios UPT adaptados al cliente. De acuerdo a las preferencias de los usuarios, la tarificación puede basarse en la localización del usuario llamado y llamante, hora del día, duración de la comunicación, etc. La información de contabilidad UPT se reúne en la red usada, que es transferida y manipulada de acuerdo a los principios de tarificación internacional. Si se usan recursos de red inteligente locales como plataformas UPT, se requieren acuerdos entre operadores UPT para asegurar que cada abonado UPT trata únicamente con un operador. Los cargos se pueden basar en los siguientes componentes: suscripción (pago inicial y tarifa mensual), gestión de la suscripción (p.e. servicios disponibles, cambios,..), uso de servicios (p.e. llamadas), cargos relacionados con la posición. Los cargos al abonado UPT se realizan de forma similar a GSM. Si un abonado UPT se registra y realiza llamadas desde un terminal GSM, las llamadas se cargan al abonado UPT hasta el punto de la red a la que está abonado el usuario llamado. Una situación especial se produce al tratar determinados conjuntos de servicios. En este caso, ETSI (European Telecomunications Standard Institute) ha especificado un conjunto de servicios suplementarios para UPT. Por otra parte, la red GSM se ha diseñado de acuerdo con los principios de RDSI, de forma que todos los servicios suplementarios GSM tienen sus contrapartidas en RDSI. Podrían producirse condiciones de colisión entre los servicios suplementarios al ocurrir solapamientos en las coberturas de ambos sistemas. Para evitar esto, se podría denegar el registro UPT si hubiera un servicio activo GSM que pudiera provocar una colisión. Sin embargo, la mejor solución pasa por distinguir entre llamadas GSM y UPT. La gestión en UPT requiere de un protocolo de aplicación especial. Debido a que se ha adoptado la arquitectura de red inteligente en una primera fase, UPT utilizará INAP (Intelligent Network
como su protocolo de aplicación. Además usará el modelo conceptual y de gestión de la red inteligente para propósitos de diseño y control.
Application Part)
La gestión UPT se divide en cinco areas funcionales de gestión (MFAs): gestión de perfil de servicio, gestión de abonado (administración de abonados y usuarios), gestión de tarificación, gestión de seguridad y gestión de interconexión de redes. Más adelante, la gestión UPT será adaptada a la red de gestión de telecomunicaciones (TMN) definida por la ITU. Si las redes GSM y la UPT se integran, los principios de gestión deben ser consistentes. Un abonado UPT debe ser capaz de modificar una porción de su perfil de servicio y desconectar el registro de llamadas entrantes y salientes usando un terminal GSM. En un principio, sólo podrán utilizarse modificaciones basadas en una señal DTMF o bien apuntes vocales. En el futuro, las facilidades del GSM relativas a la posibilidad de envío de mensajes cortos podrían utilizarse para el registro y la generación de un menú basado en una plataforma de selección interactiva que permita la modificación de servicios. Sin embargo, esto requerirá de una interconexión con un centro de servicios y con las bases de datos (SDF o HLR) que no se ha especificado todavía. La arquitectura de interconexión actual entre red inteligente y GSM no contiene señalización directa, de forma que si se requiere un intercambio de información entre ambas redes tiene que establecerse una llamada. Esta arquitectura debe adaptarse convenientemente para introducir los servicios UPT . Para posibilitar una conexión directa entre entidades, algunas funcionalidades como las provistas por el SSF y SRF tendrán que instalarse en la MSC. Cuando se usan servicios UPT desde GSM, una conexión de señalización es suficiente ya que la MSC tiene funcionalidades en la SSF para un acceso directo a la SCF, tal como puede verse en la figura 11.11 En la figura 11.12 pueden observarse los datos de abonado GSM y cómo deberían integrarse en la base de datos de la red inteligente a la que se está abonado. Eso facilitaría la obtención de información relacionada con GSM hacia la SCF. También las bases de datos con los perfiles de servicio del operador GSM o UPT a los que se está abonado podrían integrarse. Las autentificaciones podrían unificarse. En general, la integración flexible de bases de datos proporciona información relacionada con la movilidad a los servicios de red inteligente reduciendo la carga de señalización en la red. El operador de red inteligente y el de comunicaciones móviles podrían ser el mismo, posibilitando una conexión de bajo coste. País A
País B Grupo llamante
Obtención de localización
Grupo UPT Base de llamado
datos UPT
Llamada actual
Seguimiento
País C Grupo UPT llamado
Fig. 11.9. La red inteligente permite a una llamada actual ser enrutada directamente desde el país A al país C
Fig. 11.12 Integración de facilidades de red inteligente en las bases de datos VLR/HLR para el soporte de movilidad personal
Parte móvil
Parte de la red SMAF SMF SCEF
Inteligencia
Acceso y Transporte
MSF
SDF(M)o
MCF
SCF(M)o
MCCF
ACCF
MRRC MRTR
RRC
RBC
BC
RFTR
Relaciones de control de servicio Relaciones de control de conexiones portadoras Relaciones de control de conexiones de llamad Relaciones de gestión de servicios
La red inteligente en GSM se ha denominado CAMEL (Customized Applications for Mobile Network Enhaced Logic). Sus principales características son:
- Como una plataforma, CAMEL permite a los operadores móviles definir y desarrollar nuevos servicios de valor añadido sin necesidad de estandarizarlos. - Los operadores se pueden diferenciar de los otros operadores de red mediante la introducción de estos nuevos servicios de valor añadido. - Estos servicios pueden usarse cuando el roaming sea internacional. - CAMEL está diseñado para trabajar como un entorno multifabricante para la infraestructura, como las estaciones móviles. El potencial a largo plazo del desarrollo de CAMEL es tan grande que el concepto de Virtual Home Environment (VHE) planificado para el sistema UMTS está adoptando una gran importancia. La tercera fase de implantación de servicios de CAMEL está prevista para el año 1999. Se espera soporte una interconexión con la gestión de movilidad y con los servicios de GSM, posibilite la gestión de llamadas a más de dos terminales y el soporte de un nuevo VHE para facilitar el paso a UMTS. 11.5 Evolución de PCS hacia sistemas de tercera generación
Los recientes avances tecnológicos están permitiendo cada vez más un flujo interrelacionado de personas a escala mundial. En esta nueva era de globalización económica cada vez se hace más necesario el soporte de una red de comunicaciones móviles de cobertura mundial. El sistema UMTS/IMT2000 de la ITU surge como un intento de cubrir estas necesidades de comunicación. Para ello, se requiere de una nueva arquitectura de red inteligente (IN CS-3) que se integre en el sistema definido y que posibilite la gestión correcta de la información transmitida entre los nodos del sistema. Los sistemas de tercera generación como por ejemplo IMT2000/UMTS, permitirán dar soporte a los abonados para realizar cualquier tipo de comunicacion sin restricciones en el área de servicio, en la forma, ni en el instante de tiempo elegido. El sistema tendrá que ser capaz de poder transportar muchos tipos de información diferente y servir en muchos entornos de población diferentes. Entre ellos se pueden destacar el entorno urbano, con alta densidad de tráfico, entornos rurales dispersos, interiores de edificios y vehículos que pueden estar moviéndose a gran velocidad (p.e. coches, trenes,...). En principio, está previsto que el sistema IMT2000/UMTS tenga su propio servicio de movilidad personal disponible sólo en esa red, siendo la interfaz UPT necesaria para el caso de requerir movilidad a otras redes. Dado que IMT2000/UMTS dará acceso a servicios de información avanzados a una mayor población (millones de abonados) que los sistemas anteriores y a multitud de entornos, requerirá que la tecnología de los sistemas terminales, así como de la red, sean notablemente mejoradas. El sistema que se espera que se desarrollará, estará totalmente integrado por operadores de red de los diversos países proporcionando cobertura mundial y con tasas de velocidad de información de hasta 2
Mbps, proporcionado gran capacidad y calidad a los más variados servicios. Las bandas de frecuencia asignada para FPLMTS/UMTS por la WARC (World Administrative Radio Conference) son de 230 MHz de espectro no contiguo entre los 1885 y 2200 MHz. En este punto se introduce al lector en esos futuros sistemas de comunicaciones móviles. En primer lugar, se define la arquitectura de red en UMTS, tanto en la red de acceso como en la estructura de directorios de la red fija. Posteriormente, una vez se ha definido préviamente la arquitectura en la cual se va a operar, se desarrolla con más detalle la estructura de bases de datos distribuida del sistema. Este tipo de arquitectura es esencial para el buen funcionamiento de las futuras redes inteligentes, ya que actualmente son de tipo centralizado (p.e. CS1). 11.5.1 Arquitectura de la red UMTS
En este apartado se presenta una visión de la red UMTS según el proyecto MONET del RACE. Todavía no se ha desarrollado completamente un arquitectura definitiva para este estándar. Es en el entorno de la red UMTS donde van a integrarse los servicios para el usuario, a través de diferentes operadores de red y de servicio. Esta red está compuesta por una red de acceso y una red fija, cada una de las cuales contiene sus propias bases de datos. La red de acceso comprende diversas entidades que proporcionarán funcionalidades que soportarán la cobertura de los radioenlaces. Es decir, ejercerán funciones de soporte en las interfaces de radio, en la gestión de sus recursos y en el mantenimiento y operación del traspaso. La red fija UMTS comprenderá entidades que proporcionarán funcionalidades para soportar gestión de movilidad, operaciones con bases de datos, e interconexión con otras redes. Todas las interfaces con la parte fija de la red están previamente establecidas y no existe distinción entre entidades de la red fija UMTS y entidades de otras arquitecturas (p.e. B-ISDN, UPT). Éstas podrían ser (parcialmente) coincidentes o (totalmente) distintas, dependerá de su nivel de integración. En la figura 11.14 se representa la arquitectura de la red UMTS. A continuación, se describen brevemente los diferentes componentes que forman la red UMTS: La estación base ( Base Transceiver Station, BTS) proporciona la gestión del radioenlace, representando la funcionalidad necesaria para el establecimiento, el mantenimiento y la liberación del radioenlace. La CSS (centro de conmutación de celda o Cell Site Switch) representa la funcionalidad de conmutación básica en la red de acceso. En el caso de las BCPNs, la CSS podría representar una PBX fija o bien una NT2 dentro de un entorno ISDN. La central de interconexión local ( Local Exchange, LE) e interconexión de tránsito ( Transit Exchange, TX) representan la red fija existente, es decir, la infraestructura de conmutación sobre la cual se soportarán los servicios y procedimientos UMTS. El punto de control del servicio y movilidad ( Mobility and Service Control Point , MSCP) comprende la funcionalidad necesaria para el control de los procedimientos de movilidad y operación de servicios en una cierta área; puede acceder, modificar y borrar información en las bases de datos (Mobility and Service Data Point, MSDP). Las MSCPs estarían asociadas con la red fija (MSCP(LE/TX)) y con la red de acceso (MSCP(publica/privada)). En la red de acceso las entidades de control, MSCP(P/B), se separan de las CSS(P/B) ( Cell Site Switch) al tener los entornos públicos (P) diferente funcionalidad de los de negocios privados
(Business, B). Además, la MSCP está preparada para soportar servicios y control de servicios de la red inteligente. El punto de datos de servicio y movilidad ( Mobility and Service Data Point , MSDP) puede identificarse como una entidad que forma la base de datos distribuida UMTS. Esta entidad almacena información concerniente a datos del terminal, perfil de abonado y de servicio, datos de red, datos de localización, etc. Contiene también la funcionalidad de los datos que comprende el control y la comunicación en las bases de datos. El MT o terminal móvil ( Mobile Terminal, MT) comprende las funciones ubicadas en la parte del radioenlace correspondiente al terminal móvil. El MT será un "terminal multimodo inteligente" con subsistemas programables. Éstos permitirán seleccionar el tipo de control de frecuencias, el método de entrelazado usado por el canal, el codificador, el procedimiento de acceso múltiple, el tipo de modulación, el control de ráfaga, la secuencia de spreading, las frecuencias portadoras, etc. La generación de las claves de cifrado para confidencialidad e integridad es realizada por una tarjeta inteligente (Subscriber Identity Device, SID). Las redes privadas o CPN ( Customer Premises Network ) pueden verse externamente como subredes UMTS. Existen CPNs según los diversos entornos posibles en UMTS: doméstico, de oficinas o empresas, o bien móviles. A diferencia de GSM u otros sistemas anteriores, en UMTS está permitido realizar handovers entre redes distintas; eso comporta la adopción de servicios de seguridad tales como autentificaciones, controles de acceso, cambio de claves, etc., que dependerán en última instancia de la política de seguridad del sistema. Se pueden clasificar las CPNs según diversos criterios: uno de ellos, por ejemplo, según el tipo de interfaz entre la CPN y la red adyacente UMTS (pública). Esta interfaz determina las funciones que son soportadas por la CPN en sí misma y las funciones que realiza la red pública. Atendiendo a este criterio, se distinguen los siguientes: - CPN simple con acceso transparente - CPN compleja con acceso UNI usuario-red (User-Network Interface, UNI) - CPN con acceso UNI mejorado para MCPN (CPN móviles).
11.5.2 Estructura de directorios en la red fija. Bases de datos distribuidas
En la estructura de red fija se dispone de una serie de bases de datos distribuidas que forman una estructura jerárquica que permite almacenar tanto la información de perfiles de abonados como de la propia red. Las bases de datos distribuidas están compuestas de nodos de almacenamiento de información (Information Storage Nodes, ISN), de los cuales pueden identificarse varios tipos (Fig. 11.15). Los ISNs son nodos que contienen datos UMTS, información de directorios y funciones de control internas. Pueden dividirse en nodos de almacenamiento de datos residentes y nodos de almacenamiento de datos visitados. Ambos tipos no son mutuamente excluyentes y podrían coexistir en la misma ISNs. No configuran ninguna jerarquía.
Los ISNDn son nodos que contienen información de directorios y funciones de control, pero no datos UMTS. Están organizados jerárquicamente y pueden ser de los siguientes tipos: ISN DN, que son nodos que están en la parte superior de la jerarquía y son responsables de las relaciones entre redes, e ISNDn, que forman el resto de nodos de manera opcional. Por último, los nodos ISN I son los responsables de la interfaz con el resto de los sistemas UMTS. Estos nodos son los que permiten proporcionar servicios de comunicaciones personales entre redes pertenecientes a distintos operadores a través de una interfaz común UMTS. Estos nodos reciben peticiones de las entidades UMTS que están fuera de las bases de datos y las transforman en comandos internos y peticiones, que envían a las ISN s apropiadas. Estos nodos son también responsables de recoger los resultados y devolverlos a la entidad originante. 11.5.3 Distribución de información en las bases de datos
En este apartado, a modo de introducción, se describen brevemente los mecanismos sobre los cuales funciona el intercambio de los distintos tipos de información (p.e. de servicio o personal) entre las bases de datos de la red fija y el terminal móvil del usuario. Durante el funcionamiento normal de la red, el usuario con el terminal móvil va desplazándose sobre las distintas celdas en las que tiene cobertura el sistema. En la ejecución de los procedimientos de movilidad, ciertos datos son transferidos, o bien obtenidos, modificados o renovados entre las bases de datos del resto de la red. Cuando se considera el modelo funcional UMTS, puede entenderse el servicio de bases de datos como proporcionado por las entidades funcionales SDF (que representan la base de datos ISN) en respuesta a peticiones de servicio desde las entidades funcionales SCF (que representan los elementos de control de la red). Los datos son estructurados en dominios bajo áreas administrativas con la supervisión de un operador UMTS. Los proveedores de servicio son la autoridad que tiene la completa responsabilidad para la provisión de un servicio o un conjunto de servicios (p. e. de tipo personal) a los usuarios finales. Como se verá, eso puede afectar a las disciplinas de control de acceso a determinados servicios. Los proveedores de servicios, a su vez, pueden dividirse en dos categorías, los públicos y los privados, con políticas de seguridad no siempre coincidentes. El área de cobertura de un servicio personal es el área donde un proveedor de servicio dado es responsable de la provisión de uno o más de estos servicios. Para realizar esa tarea, un proveedor de servicios personales tiene acceso a una base de datos o a un conjunto de bases de datos interconectadas. Es importante también hacer una distinción entre las distintas clases de datos: los datos usables directamente, que pueden ser procesados para responder a una petición de base de datos, y los punteros, que dan indicaciones de la posición de los datos usables pedidos en los dominios de bases de datos y necesarios para soportar la provisión de un servicio. En el caso del establecimiento de una comunicación personal, los datos concernientes a los grupos llamante y llamado se intercambian entre los proveedores del servicio, formando parte de distintos dominios. Se define el dominio UMTS visitado como aquel dominio en el que el terminal móvil (usuario) se está moviendo. En contraposición se encuentra el dominio UMTS de abonado (home) en el cual el terminal móvil (usuario) tiene una suscripción válida. Durante la ejecución de los procedimientos de movilidad ciertos datos podrían ser transferidos (o modificados, obtenidos, etc.)
entre diferentes dominios UMTS. Se llama dominio UMTS originante a aquel dominio en el cual se genera una petición. Cabe notar que el dominio UMTS originante podría ser idéntico al dominio de abonado o visitado. 11.5.4 Conclusiones
A medida que se liberalizan los servicios de telecomunicaciones en todo el mundo y existen unas mayores necesidades de movilidad por parte de los usuarios, surgen una serie de problemas que tratan de resolver estos nuevos sistemas de comunicaciones personales. Para el soporte de esta movilidad personal se requiere de una red inteligente que se integre en un principio en las redes existentes convencionales para evolucionar, en un futuro, hacia sistemas más avanzados de tercera generación. El reto actual consiste en superar la problemática integración por la existencia de un considerable número de operadores de redes y proveedores de servicios, tanto públicos como privados, que ofrecen un soporte para los servicios de movilidad personal PCS/UPT. En este caso, el mayor orden reinante en Europa, en cuanto a operadores se refiere, permite ser optimistas en cuanto a su implantación final; sin embargo, se requerirán profundos cambios en las infraestructuras de comunicaciones así como en la misma sociedad, que de esta forma entraría de lleno en una nueva era de la información. En este capítulo se ha tratado de dar una visión lo más amplia posible del panorama actual de las comunicaciones personales; sin embargo, hay que decir que los estándares sobre el tema siguen estando abiertos y que existe una mejora continua en los sistemas.
DATOS MSDP(B)
MSCP(P/B)
MSDP(LE)
MSCP(LE)
RED DE ACCESO MT
BTS
CSS(P/B)
MSDP(TX)
RED DE SEÑALI ZACIÓN
CONTROL DE MSCP (TX) SERVICIO Y MOVILIDAD
LE
TX
INFRAESTRUCTUR DE CONMUTACIÓN BÁSICA
RED FIJA
MCPN (MT, BTS, CSS, MSCP,MSDP)
MT: Mobile Terminal BTS: Base Transceiver Station CSS Cell Site Switch LE: Local Exchange TX: Transit Exchange MSCP: Mobile and Service Control Point MSDP: Mobility and Service Data Point P/B: Public/Business
Fig. 11.14 Arquitectura de la red UMTS (según el proyecto MONET del programa RACE, UE)
12 Gestión en Internet En este capítulo se aborda la gestión con la familia de protocolos SNMP, actualmente la configuración de gestión más extendida y propia de las redes con pilas de protocolos TCP/IP. No se pretenden estudiar las problematicas de la gestión global de Internet como red de redes [STA1, ROS1,2..]. 12.1 Introducción
La red de redes Internet es actualmente una de las redes gestionadas de peor forma. Ello se debe principalmente a que no hay una calidad de servicio que se deba cumplir estrictamente entre los proveedores de servicio y los usuarios. Únicamente determinados operadores de red y proveedores de servicio cobran unas cuotas a sus abonados y éstos pueden exigir un determinado servicio; sin embargo, esa condición no se puede cumplir para todos los servicios y redes. Un problema añadido es que los protocolos actuales de Internet no permiten la flexibilidad de servicios ni la calidad de servicio que proporcionan redes más avanzadas como la RDSI de banda ancha, basada en tecnología ATM. Recientemente han aparecido especificaciones del IETF para el desarrollo de la Internet 2 que si, bien mejoran determinados aspectos de servicio, tampoco acaban de ofrecer una solución global satisfactoria a los abonados, sobre todo en cuanto se refiere a servicios interactivos en tiempo real. A pesar de todo lo anterior, los protocolo TCP/IP y la red Internet están ampliamente extendidos por la mayoría de países desarrollados y constituyen la red por antonomasia en la mayor parte de éstos. Por otra parte, las empresas están introduciendo recientemente este tipo de tecnología de forma masiva en sus redes, de forma que cada vez dependen más de su buen funcionamiento. De ahí se deduce que si se considera la gestión de red como esencial, entonces deba de implantarse en todos los recursos de una red. Esto trae consigo una serie de consecuencias y es que el impacto de añadir gestión de red en los nodos debe ser el mínimo posible, de forma que la complejidad algorítmica y de comunicaciones debe recaer en los procesos gestores (con el uso de plataformas de gestión de elevadas prestaciones). Esto último no siempre se cumple en realidad: baste decir que entornos de gestión como el basado en el protocolo CMIP que permitiría obtener mejores rendimientos en estos tipos de redes son suplantados generalmente por entornos más simples y baratos como el basado en SNMP (Simple Network Management Protocol) que generan a menudo un tráfico de señalización excesivo.
Las primeras aproximaciones a la gestión de red en Internet aparecieron en marzo de 1987 con una serie de protocolos como el SGMP ( Simple Gateway Monitoring Protocol), el HEMS ( High-Level Entity Management System) y el CMOT (versión de CMIP sobre TCP). Estos protocolos de gestión se ocupaban básicamente del buen funcionamiento de los nodos de encaminamiento centrales del conjunto de redes Internet. Posteriormente, en febrero de 1988, se produjeron una serie de revisiones para actualizar el protocolo SGMP, que dieron lugar a un incipiente SNMP. Más a largo plazo, existía la versión del CMOT como alternativa. No fue hasta el agosto de 1988 cuando aparecieron realmente las primeras recomendaciones del SNMP, así como de la SMI y MIB correspondientes. Desde el principio el protocolo SNMP tuvo mucho éxito, si bien no dejaba de ser un protocolo de monitorización esencialmente simple. Hubo en marzo de 1991 nuevas revisiones del entorno, que dieron lugar a una nueva especificación de base de datos denominada MIB II. Fue a partir de ahí que diversos fabricantes se dedicaron a la obtención de MIBs particulares que permitían la compatibilidad entre plataformas de gestión en entornos de red heterogéneos, dado que SNMP era esencialmente un protocolo abierto. Posteriormente, en mayo de 1993, el grupo IETF sacó una nueva versión más completa del protocolo, denominada SNMPv2, con diversas versiones y con relativamente escaso éxito. Finalmente, en el verano de 1998, se anunciaban los primeros documentos relacionados con una nueva versión SNMP3 más avanzada. Puede decirse que, actualmente, el marco de trabajo del protocolo SNMP se basa esencialmente en tres documentos: - Structure of Management Information (SMI): RFC1155. - Management Information Base (MIB): RFC 1156, RFC 1213. - Simple Network Management Protocol (SNMP): RFC 1157. Cabe destacar otros documentos adicionales como el Concise MIB definitions: RFC 1212. 12.3 Estructura de la información de gestión
El objetivo de especificar una estructura de la información de gestión consiste en poder referenciar un recurso en un sistema remoto. Pero para ello se requieren una serie de elementos, como un protocolo IP que nos permite llegar al sistema remoto, o el protocolo SNMP que permite llegar al proceso de gestión de red del sistema remoto. Sin embargo, existe un problema: ¿cómo llegar a los recursos del sistema remoto?, para ello se va a utilizar un método común para nombrar a los objetos. Este método usa los identificadores de objetos (Object Identifiers, OID). Los OID no son más que una secuencia de enteros no negativos separados por un punto que forman un árbol. Este árbol, denominado de registro, está estandarizado a nivel mundial. Por ejemplo, el OID: 1.3.6.1.1 identifica el objeto que se encontraría si, comenzando en el root , pasamos a la rama 3, después a la 6, a la 1 y finalmente a la rama 1. El árbol está formado por ramas y nodos. En cada nodo existe una etiqueta consistente en un número entero y quizás un texto breve. Cada nodo puede tener nodos hijos (subordinados o sub-identifiers),
conectados a éste mediante líneas (ramas). El árbol comienza con un nodo inicial denominado root que se puede extender hasta cualquier nivel de profundidad. Estos OIDs son los que permiten alcanzar (nombrar) objetos mediante SNMP. Pero, ¿cómo devolvemos los valores de los objetos (respuesta a un get )?. Para que ello sea posible es necesario conocer la estructura de los valores que nos pueden llegar desde los objetos, es decir la Macro OBJECT-TYPE, así como conocer el uso de una codificación por línea conocida de estos valores (sintaxis de referencia ASN1).
ccitt (2)
iso (1) org (3)
dod (6) internet (1) directory (1)
mgmt (2)
experimental (3)
mib (1)
private (4) enterprises (1)
Fig. 12.1 Árbol de registro
12.4 Sintaxis ASN.1
La sintaxis ASN.1, que se representa mediante el término Syntax en la macro de tipo de objetos, define el tipo de datos que modela el objeto. La sintaxis abstracta se utiliza para describir tanto las estructuras de datos que se intercambian las entidades del protocolo SNMP como la información de gestión que contienen estas estructuras de datos [STE1]. Junto con el concepto de sintaxis abstracta, existe el concepto de sintaxis de transferencia. Ésta última permite, a partir de la definición de las estructuras de datos, utilizar una forma determinada de transmitir los datos a través de la red. La sintaxis de transferencia que se utiliza junto con la ASN.1 son las reglas de codificación básicas ( Basic Encoding Rules, BER). Si bien se usa ASN.1 para la sintaxis abstracta, dado que esta notación es muy extensa, se restringe su uso para mantener la simplicidad en los agentes. Una colección de descripciones ASN.1 relacionadas con un mismo tema se conoce como módulo. Se definen tres tipos de objetos con ASN.1:
- Tipos (types), que definen nuevas estructuras de datos. - Valores (values), que son realizaciones (variables) de un tipo. - Macros, que se utilizan para cambiar la gramática ASN.1. Para saber en cada momento de qué tipo de objeto se trata, se utiliza la siguiente regla: los identificadores de tipo comienzan en mayúscula, los identificadores de valor se escriben en minúscula y los identificadores de macros se escriben completamente en mayúsculas. El tipo se representa con la siguiente sintaxis: NombreDeTipo ::= TIPO Un valor (una variable) lo hace de forma similar: NombreDeValor NombreDeTipo ::= VALOR Existen una serie de tipos permitidos para los objetos como los siguientes: Tipos simples (Integer, Octet String, Object Identifier) Tipos de aplicación Tipos estructurados (Sequence, Sequence Of) Subtipos (IpAddress, Counter, Gauge,...)
12.4.1 Tipos simples
Los tipos simples de ASN.1 que utiliza el protocolo de gestión son: - INTEGER: tipo de dato que toma como valor un número entero. Ejemplo: Estatus ::= INTEGER {up(1), down(2), testing(3)} que es lo mismo que decir que up = 1, down = 2 y testing = 3. - OCTET STRING: tipo de dato que toma como valor 0 o más octetos. Cada byte puede tomar valores entre 0 y 255. (código ASCII). - OBJECT IDENTIFIER: tipo de dato que permite la identificación de objetos de gestión. - NULL: tipo nulo. No se usa en el marco de gestión. 12.4.2 Tipos estructurados
Los tipos constructed (estructurados) que utiliza el protocolo de gestión son: - SEQUENCE: tipo de dato para hacer listas.
::= SEQUENCE { , ... } - SEQUENCE OF: tipo de dato para hacer tablas. (p.e. tablas de encaminamiento).
::= SEQUENCE OF 12.4.3 Tipos etiquetados ( tagged )
Estos tipos de datos se utilizan para definir nuevos tipos etiquetando uno ya existente. Existen los siguientes tipos de etiquetas: UNIVERSAL APPLICATION CONTEXT-SPECIFIC PRIVATE Los tipos etiquetados se construyen con la etiqueta y un número entero, por ejemplo: Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING Opaque es un tipo de dato que representa una codificación arbitraria.
12.4.4 Subtipos ASN.1
Los subtipos ASN1 refinan la semántica de un tipo ya existente, como: - IpAddress: tipo que sirve para representar direcciones IP. IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) - Network Address: representa direcciones de distintos protocolos. NetworkAddress ::= CHOICE { internet IpAddress} - Counter: entero no negativo, que se incrementa monotónicamente. Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0 .. 4.294.967.295) - Gauge: entero no negativo, que se puede incrementar o decrementar con valor máximo. Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0 .. 4.294.967.295)
- TimeTicks: entero no negativo, que permite contar tiempo en centésimas de segundo desde algún inicio. TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0 .. 4.294.967.295) Junto a estos tipos, es preciso definir también en las macro de los objetos gestionados un acceso y un estatus para así poder especificar las operaciones permitidas en éstos. El acceso (Access) define el nivel de acceso al objeto y puede especificarse uno de los siguientes: read-only, read-write, write-only y not-accesible. Como ejemplo, para tipos estructurados, no puede accederse a una tabla sino sólo a un campo concreto de la misma. El status permite definir los requisitos de implementación del objeto Mandatory (el único que se utiliza actualmente), Optional y Obsolete.
distinguiéndose los siguientes:
Por otra parte, el nombre de los objetos se define como un OBJECT IDENTIFIER que se usa para nombrar a los objetos gestionados. Este identificador puede estar en tres tipos de MIBs. Éstas son actualmente las siguientes: MIB estándar de Internet mib OBJECT IDENTIFIER ::= { internet mgmt(2) 1 } MIB experimental experimental OBJECT IDENTIFIER ::= { internet 3} MIB privadas enterprises OBJECT IDENTIFIER ::= { internet private (4) 1 } 12.5 Bases de información de gestión (MIB)
Las bases de información de gestión (MIB) son un conjunto de objetos gestionados de un recurso que se publican para ofrecer interoperabilidad de gestión. Estos objetos se organizan en grupos, según sea su temática. La red se estructura de forma que los nodos deben soportar grupos enteros. Actualmente existen los siguientes tipos de MIBs: las estándares, que son la MIB-I y MIB-II; las experimentales, con grupos en fase de desarrollo; y, finalmente, las privadas, que incorporan la información de los diversos fabricantes de equipos. A continuación, se presenta la plantilla de la macro de tipo de objeto utilizada en la MIB y la plantilla de la estructura de información de gestión (SMI). IMPORTS ObjectName FROM RFC1155-SMI DisplayString FROM RFC1158-MIB; OBJECT-TYPE MACRO ::=
BEGIN TYPE NOTATION ::= -- must conform to -- RFC1155's ObjectSyntax "SYNTAX" type(ObjectSyntax) "ACCESS" Access "ESTATUS" Estatus DescrPart ReferPart IndexPart DefValPart VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Estatus ::= "mandatory" | "optional" | "obsolete" | "deprecated" DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty ReferPart ::= "REFERENCE" value (reference DisplayString) | empty IndexPart ::= "INDEX" "{" IndexTypes "}"| empty IndexTypes ::= IndexType | IndexTypes "," IndexType IndexType ::= -- if indexobject, use the SYNTAX -- value of the correspondent -- OBJECT-TYPE invocation value (indexobject ObjectName) -- otherwise use named SMI type -- must conform to IndexSyntax below | type (indextype) DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}"
| empty
END IndexSyntax ::= CHOICE { number INTEGER (0..MAX), string OCTET STRING, object OBJECT IDENTIFIER, address NetworkAddress, ipAddress IpAddress } Fig. 12.2 Macro de Object-Type del RFC 1212
RFC1155-SMI DEFINITIONS ::= BEGIN EXPORTS -- EVERYTHING internet, directory, mgmt, experimental, private, enterprises, OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax, ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque; -- the path to the root internet
OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } -- definition of object types OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax) "ACCESS" Access "ESTATUS" Estatus VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Estatus ::= "mandatory" | "optional" | "obsolete" END -- names of objects in the MIB ObjectName ::= OBJECT IDENTIFIER -- syntax of objects in the MIB ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that simple SEQUENCEs are not directly -- mentioned here to keep things simple (i.e., -- prevent mis-use). However, application-wide -- types which are IMPLICITly encoded simple -- SEQUENCEs may appear in the following CHOICE application-wide ApplicationSyntax} SimpleSyntax ::= CHOICE { number INTEGER,
string OCTET STRING, object OBJECT IDENTIFIER, empty NULL } ApplicationSyntax ::= CHOICE { address NetworkAddress, counter Counter, gauge Gauge, ticks TimeTicks, arbitrary Opaque -- other application-wide types, as they are -- defined, will be added here } -- application-wide types NetworkAddress ::= CHOICE { internet
IpAddress }
IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value, IMPLICIT OCTET STRING -- "double-wrapped" END Fig. 12.3 Estructura de la información de gestión (SMI, RFC 1155)
Cada objeto se describe utilizando la macro OBJECT-TYPE. Cada objeto se descompone en una serie de campos. A continuación se describen brevemente los campos obligatorios: - Descriptor : nombre del objeto - Value: nombre del objeto en forma de OBJECT IDENTIFIER - Syntax : especifica el tipo de dato del que se trata - Access: indica el nivel máximo de acceso (lectura, escritura,.) - Status: muestra la vigencia de la definición del objeto - Description: se trata de un texto que describe el significado del objeto. Existen también estos campos opcionales: - Units: unidades asociadas con el tipo de dato (p.e. segundos)
- Reference: se nombra en caso de haber algún objeto asociado - Index/Augments: ofrecen medios para identificar variables - Defval: recomendación sobre la creación de variables. 12.5.1 MIB-I
La MIB-I constituye la primera MIB normalizada. Está formada con objetos de la torre de protocolos de TCP/IP. En la tabla se especifican los grupos que la forman, con el número de objetos que forma cada grupo y una breve descripción de éstos. Grupo
Número
Propósito
system interfaces at (adress translation) ip icmp tcp udp egp
3 22 3 33 26 17 4 6 114
El propio sistema Interfaces de red Correspondencia de dirección IP Protocolo internet P. de mensaje de control internet P. de control de transmisión P. de datagrama de usuario P. de pasarela exterior
Tabla 12.1 Esquema de grupos de la MIB-I
12.5.2 MIB-II
En la MIB-II se realizaron una serie de modificaciones sobre la primera versión. Entre éstas se halla la de la tabla address translation que se desestimó. También se define un nuevo grupo para cada tipo específico de interfaz, así como un nuevo grupo con objetos de SNMP. Grupo
Número
Comentarios
system interfaces at ip icmp tcp udp egp transmission snmp
7 23 3 38 26 19 7 18 0 30 171
eran 3 eran 22 serán 0 eran 33 sin cambio eran 17 nueva tabla expansión de tabla nuevo nuevo
Ejemplo de MIB IP: WINDOWS-NT-PERFORMANCE DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC-1213; microsoft OBJECT IDENTIFIER ::= { enterprises 311 } software OBJECT IDENTIFIER ::= { microsoft 1 } systems OBJECT IDENTIFIER ::= { software 1 } os OBJECT IDENTIFIER ::= { systems 3 } winnt OBJECT IDENTIFIER ::= { os 1 } performance OBJECT IDENTIFIER ::= { winnt 1 } -- iP MIB iP OBJECT IDENTIFIER ::= { performance 5 } ipDatagramsPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams/sec is the rate that IP datagrams are received from or sent to the interfaces, including those in error. Any forwarded datagrams are not included in this rate." ::= { iP 1 } ipDatagramsReceivedPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Received/sec is the rate that IP datagrams are received from the interfaces, including those in error." ::= { iP 2 } ipDatagramsReceivedHeaderErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Received Header Errors is the number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-tolive exceeded, errors discovered in processing their IP options, et c."
::= { iP 3 } ipDatagramsReceivedAddressErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Received Address Errors is the number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0. 0.0) and addresses of unsupported Classes (e.g., Class E). For entities that are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address." ::= { iP 4 } ipDatagramsForwardedPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Forwarded/sec is the rate of input datagrams for that this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities that do not act as IP Gateways, this rate will include only those packets that were Source-Routed via this entity, and the Source-Route option processing was successful." ::= { iP 5 } ipDatagramsReceivedUnknownProtocol OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Received Unknown Protocol is the number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol." ::= { iP 6 } ipDatagramsReceivedDiscarded OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Received Discarded is the number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). This counter does not include any datagrams discarded while awaiting re-assembly." ::= { iP 7 } ipDatagramsReceivedDeliveredPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION
"Datagrams Received Delivered/sec is the rate that input datagrams are successfully delivered to IP user-protocols (including ICMP)." ::= { iP 8 } ipDatagramsSentPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Sent/sec is the rate that IP datagrams are supplied to IP for transmission by local IP user-protocols (including ICMP). That this counter does not include any datagrams counted in Datagrams Forwarded." ::= { iP 9 } ipDatagramsOutboundDiscarded OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Outbound Discarded is the number of output IP datagrams for which no problems were encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space.) This counter would include datagrams counted in Datagrams Forwarded if any such packets met this (discretionary) discard criterion." ::= { iP 10 } ipDatagramsOutboundNoRoute OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Datagrams Outbound No Route is the number of IP datagrams discarded because no route could be found to transmit them to their destination. This counter includes any packets counted in Datagrams Forwarded that meet this `no route' criterion." ::= { iP 11 } ipFragmentsReceivedPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Fragments Received/sec is the rate that IP fragments that need to be re-assembled at this entity are received." ::= { iP 12 } ipFragmentsRe-assembledPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION
"Fragments Re-assembled/sec is the rate that IP fragments are successfully re-assembled." ::= { iP 13 } ipFragmentRe-assemblyFailures OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Fragment Re-assembly Failures is the number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.) This is not necessarily a count of discarded IP fragments since some algorithms (notably RFC 815) can lose track of the number of fragments by combining them as they are received." ::= { iP 14 } ipFragmentedDatagramsPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Fragmented Datagrams/sec is the rate that datagrams are successfully fragmented at this entity." ::= { iP 15 } ipFragmentationFailures OBJECT-TYPE SYNTAX INTEGER ACCESS read-only ESTATUS mandatory DESCRIPTION "Fragmentation Failures is the number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their `Don't Fragment' flag was set." ::= { iP 16 } ipFragmentsCreatedPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION "Fragments Created/sec is the rate that IP datagram fragments have been generated as a result of fragmentation at this entity." ::= { iP 17 } END 12.5.3 MIBs experimentales
Las MIB experimentales son las MIB consideradas en fase de desarrollo por los grupos de trabajo de Internet. Actualmente existen MIBs para:
IEEE 802.4 Token Bus (RFC 1230) IEEE 802.5 Token Ring (RFC 1231) IEEE 802.3 Repeater Devices (RFC 1368) Ethernet (RFC 1398) FDDI (RFC 1285) RMON (RFC 1271) Bridges (RFC 1286) ... Actualmente el RFC 1398 correspondiente a la MIB de Ethernet ya es estándar, con lo que pasará a depender de la MIB de transmisión. Posteriormente todas estas MIB se irán estandarizando, complementando a la MIB-II. 12.5.4 MIBs privadas
Las MIB privadas corresponden a las MIBs de productos específicos, generadas por los distintos fabricantes, y añaden funcionalidad a las MIB estándar. Generalmente, los fabricantes las hacen públicas, poniéndolas accesibles por Internet (deposito común en venera.isi.edu). Por ejemplo, se pueden encontrar MIBs para productos, de Cabletron, Synoptics, Proteon, ATT, Cisco, etc. 12.6 Simple Network Management Protocol (SNMP)
El protocolo SNMP (RFC 1157) surge a partir del protocolo SGMP para gestión de routers IP. El Simple Network Management Protocol (SNMP) es un protocolo de aplicación que ofrece servicios de gestión de red al conjunto de protocolos Internet. SNMP define una arquitectura basada en clienteservidor. El programa cliente (llamado el gestor de red) realiza conexiones virtuales a un programa servidor (llamado el agente SNMP) ejecutando en un dispositivo de red remoto. La base de datos controlada por el agente SNMP se denomina Management Information Base (MIB), y es un conjunto estándar de valores estadísticos y de control de status. SNMP permite también extensiones de esta MIB a agentes particulares para el uso de MIB privadas. Los mensajes enviados por el cliente (gestor de red) a los agentes SNMP están formados de identificadores de objetos MIB, junto con instrucciones a fin de cambiar u obtener un valor. Estación de gestión de red SNMP
Agente Conjunto de MIBs Ordenador
SNMP
SNMP
Agente Conjunto de MIBs Router
Agente Conjunto de MIBs Servidor de terminales
Conjunto de recursos
Fig. 12.4 Arquitectura de un sistema de gestión SNMP
La torre de comunicaciones SNMP se apoya en la estructura de protocolos TCP/IP de Internet y que se muestra en la figura siguiente.
SNMP RFC 1157
UDP RFC 768
IP RFC 791 ICMP RFC 782
Token Ring Ethernet, FDDI
Nivel 7
Nivel 4
Nivel 3
Nivel 1 y 2
Fig. 12.5 Torre de protocolos en Internet
A pesar de la fácil integración de SNMP en los protocolos UDP/IP, es posible montar SNMP sobre otras torres de comunicación (Ethernet, IPX, OSI, CLNS). Sin embargo, a la hora de elegir una infraestructura de comunicaciones, hay que tener en cuenta la interoperabilidad, el nivel de transporte y el uso de un servicio orientado o no a conexión. Entre las características principales del protocolo SNMP se puede destacar el hecho de que es un protocolo de gran flexibilidad y que permite una gran extensibilidad a todo tipo de redes. A pesar de definirse como un protocolo simple resulta ser un protocolo difícil de implementar para el diseño de aplicaciones, dada la complejidad intrínseca de las aplicaciones que debe diseñar. Por otra parte, en cuanto a rendimiento, la eficiencia del protocolo para la transmisión de información es baja, ya que se trata de una arquitectura basada en polling de acuerdo con una estructura de funcionamiento centralizada. El hecho de que se trate de una gestión conducida por polling determina que el gestor pregunte periódicamente a la información del agente sobre los recursos gestionados, de forma que es el gestor el responsable de monitorizar los recursos. Ello presenta la ventaja de que el gestor puede ser simple, pero presenta la desventaja de que la gestión de tráfico puede ser importante. SNMP, si bien es un protocolo abierto, también puede utilizar un agente proxy para gestionar sistemas propietarios. Cabe destacar también que en SNMP la comunicación con los agentes no está orientada a conexión y que al ser un protocolo basado en UDP/IP no garantiza la llegada de los mensajes TRAP a destino, con lo que tienen que integrarse mecanismos especiales en capas superiores para evitar estas deficiencias.
El protocolo SNMP es eminentemente un protocolo simple y de monitorización. A continuación, se definen los tipos de operaciones permisibles con sus objetos: - GetRequest: petición de valores específicos de la MIB. - GetNextRequest: proporciona un medio para moverse por la MIB. Petición del objeto siguiente a
uno
dado de la MIB (orden lexicográfico). - GetResponse: devuelve los valores solicitados por las operaciones anteriores. - SetRequest: permite asignar un valor a una variable. Debido a posibles problemas de seguridad esta función suele estar desactivada. - Traps: permite a los agentes informar de sucesos inusuales. (p.e. ColdStart, WarmStart, LinkDown, LinkUp, AuthenticationFailure, EGPNeighborLoss, EnterpriseSpecific). En la figura 12.6 se muestran las relaciones que existen entre los diversos tipos de primitivas y los nodos de comunicaciones, es decir, los papeles de gestor (lado de la izquierda) y agentes (lado derecho). Junto a los mensajes anteriores destacan las Traps como mensajes especiales que especifican alarmas o sucesos inusuales. Estas Traps suelen variar mucho en cada entorno, dependiendo de la implementación que realice el fabricante. El uso de MIBs privadas junto con mensajes tipo Trap permite la respuesta del sistema a alarmas específicas de los equipos de cada fabricante. Además, se posibilita la integración de agentes en multitud de dispositivos para su gestión, tales como puentes, encaminamientores, pasarelas, etc. Las definiciones de las variables MIB soportadas por un agente en particular se incorporan en ficheros descritos en una notación especial denominada Abstract Syntax Notation (ASN.1) a fin de que puedan ser utilizables por programas cliente de gestión de red de otros fabricantes. A continuación se describe la secuencia de eventos que se produce en la emisión y recepción de un mensaje SNMP por parte de una entidad de gestión: Secuencia de transmisión de un mensaje SNMP
1. Construcción de la PDU, usando estructuras ASN.1. 2. La PDU se procesa por el servicio de autenticación junto a las direcciones correspondientes. 3. La entidad de protocolo construye el mensaje, consistiendo de una vesión de campo, el nombre de la comunidad y el resultado del paso dos. 4. Este nuevo objeto ASN.1 es entonces codificado, usando las reglas de codificación básicas y pasado al servicio de transporte. En la práctica, las autentificaciones no se invocan. Secuencia de recepción de un mensaje SNMP
1. Chequeo básico de la sintaxis del mensaje, descartándolo si es erróneo. 2. Verificación del número de versión. Se descarta el mensaje si no es coherente. 3. La entidad de protocolo pasa al usuario la porción PDU del mensaje y las direcciones de transporte de emisor y receptor al servicio de autenticación. 3.1 Si la autenticación falla, el servicio de autenticación señaliza a la entidad de protocolos SNMP, para que genere una Trap y descarte el mensaje.
3.2 Si la autenticación tiene exito, el servicio de autenticación devuelve la PDU en la forma de objeto ASN.1 definido en RFC 1157. 4. La entidad de protocolo hace un chequeo básico de la sintaxis del mensaje, descartándolo si es erróneo. En cualquier caso, la comunidad nombrada con la adecuada política de acceso SNMP seleccionada finalmente procesa la PDU.
GetRequest PDU
GetNextRequest PDU
SetRequest PDU Trap PDU
GetResponse PDU
Obtener valores (Get values)
GetResponse PDU
GetResponse PDU
Obtener próximos valores
Asignar valores
Enviar Trap
(Set values)
(Send Trap)
(Get-next values)
Fig. 12.6 Secuencias de PDUs en el protocolo SNMP
Versión
SNMP PDU
Comunidad
Mensajes SNMP Tipo PDU Petición id
0
0
Campos variables
GetRequest PDU, GetNextRequest PDU, y SetRequest PDU Tipo PDU Petición id error-estatus error-índice
12.6.2 Codificación para la transferencia de la información de gestión: BER
Según se ha explicado en la sección 12.4, la información de gestión se define a partir de la ASN.1. Ésta establece que para la codificación se utilizarán las BER ( Basic Encoding Rules). Las BER permiten traducir una estructura de datos cualquiera en una secuencia de bytes y viceversa. Las BER no son más que un algoritmo recursivo que puede producir una secuencia de bytes a partir de cualquier valor ASN.1. El protocolo SNMP sólo utiliza un subconjunto de estas reglas. Las BER codifican los tipos utilizando los siguientes tres campos de longitud arbitraria: - Tag: indica el tipo de ASN.1 - Length: indica el tamaño de la codificación del valor que sigue - Value: indica propiamente la codificación del valor. 12.7 Configuración y rendimiento de una red gestionada por el protocolo SNMP
La gestión de redes se basa en la gestión de nodos, entendiendo como tales abstracciones de una entidad de red física como routers, hubs, ordenadores personales, impresoras, etc. Sin embargo, para analizar más en detalle la configuración y el rendimiento en la gestión, se tienen que determinar las dimensiones de los correspondientes parámetros: - número de estaciones - número de redes - número de segmentos - número de nodos - número de interfaces - número de gateways - número de nodos gestionados. De hecho, cada nodo tiene una o más interfaces que se registran en la base de datos. La carga de gestión puede determinarse a partir del número de nodos gestionados más el número de interfaces gestionadas para cada nodo. A partir de ahí, considerando el número de redes y de segmentos se determina finalmente el número de objetos que se deben gestionar. Para calcular el número de objetos que se deben gestionar, se tiene en cuenta que el número de interfaces por nodo suele ser único, y que experimentalmente puede considerarse un promedio de 2.4 objetos por nodo. Los requerimientos de recursos del sistema de gestión pasan por cubrir las funcionalidades de monitorización y de descubrimiento básicas ( Discover ); las funcionalidades de presentación (display); las funcionalidades de eventos de acción y de colección de datos; finalmente, funcionalidades relativas a gestión distribuida y de bases de datos específicas. Todas estas funciones requieren de espacio de memoria estándar, memoria swap, espacio de disco y potencia de cálculo. Se suele estimar a menudo que el espacio de memoria swap sea como dos veces el de la memoria estándar. El uso del protocolo SNMPv2 permite diversas configuraciones de gestión, y puede integrar estaciones de gestión con estaciones de sondeo de datos y con cónsolas de gestión (sesiones del programa de gestión). El proceso de sincronización de la información puede ser por ejemplo, de unos
3 min. para configuraciones de una estación de gestión, hasta unos 15 min. para configuraciones de 5 estaciones. El uso de filtros para los procesos de obtención de información, de descubrimiento de los nodos ( Discovery), la topología y los mapas, permite reducir mucho las necesidades de memoria y la carga del sistema de gestión, cosa que repercute en una mayor concentración de recursos para los objetos que realmente interesa gestionar. 12.7.1 Interrogación ( polling) de estatus de dispositivos.
Cada interrogación de estatus IP genera alrededor de 4 a 5 pequeños paquetes en una LAN local (debido a los ARPs) y 2 paquetes en las LAN remotas. El intervalo de interrogación de estatus suele estar por defecto en torno a los 5 min. (300 s). Este tiempo viene acotado por el tiempo que tarda un paquete en recorrer la red (ICMP echo request) a la interfaz más lejana. 12.7.2 Interrogación ( polling) de descubrimiento ( Discovery)
La interrogación de descubrimiento IP requiere de 10 a 100 paquetes por nodo, dependiendo del tipo de nodo. Los routers que soportan SNMP pueden requerir 100 paquetes, mientras que routers de grandes redes pueden requerir centenares de paquetes. Los dispositivos que no soportan SNMP requieren de unos 3 paquetes. Las frecuencias de chequeo de los nodos dependen a menudo de la información previa disponible. 12.7.3 Interrogación ( polling) de configuración de topología
El número de paquetes generados por esta interrogación depende en gran manera de cuántas interfaces en la red comunican a través de dispositivos que soportan la MIB Bridge (RFC 1493). En un entorno con gran cantidad de encaminamientos o conmutado se puede esperar la generación de 10 a 20 paquetes por interfaz en la red. Por defecto, la interrogación de la red se completa cada 4 horas. 12.7.4 Interrogación ( polling) de chequeo de configuración de dispositivo
Durante la interrogación de chequeo de configuración se generan entre 20 y 100 paquetes por nodo, dependiendo del tamaño de la información que se solicita. Este chequeo se completa por defecto una vez por nodo y se realiza para cada día. 12.7.5 Interrogación ( polling) de estatus de estación de sondeo
Requiere de aproximadamente 20 paquetes por estación de sondeo. La frecuencia de este tipo de interrogación se configura a partir de cada estación de sondeo, siendo la frecuencia por defecto de una cada 5 minutos. 12.7.6 Otras aplicaciones
Si se utilizan otras estaciones para la recolección de datos, monitorizar variables MIB, chequear niveles de disparo, crear gráficos, conectar a sistemas remotos, etc. consecuentemente se genera tráfico extra en la red.
Para una gestión con SNMP adecuada se define un nombre de comunidad ( community) que afecta tanto al agente como al conjunto de gestores que lo administran, y un perfil de comunidad que delimita las propiedades así como el modo de acceso al sistema. De esta forma, la comunidad puede ser pública ( public), es decir, de libre acceso. Esta información se almacena en cada MIB (Fig. 12.8). De esta forma, una comunidad es una relación entre un agente y gestores y el nombre de comunidad es una cadena de octetos transmitida en los mensajes SNMP. Para la determinación de políticas de autentificación y autorización se trabaja con autentificación simple, en la que el nombre de comunidad se transmite en claro; de ahí la necesidad de ampliar la seguridad del entorno de gestión mediante otros servicios de seguridad. En cuanto a la autorización, cada comunidad tiene asociado una vista (conjunto de objetos), de forma que para cada objeto se define un modo de acceso: read-only, read-write. Finalmente, el nombre de comunidad junto al perfil de comunidad marca la política de acceso al sistema.
Agente SNMP
Conjunto de gestores SNMP
MIB SNMP
Comunidad SNMP (nombre comunidad)
Modo de acceso SNMP
Perfil de comunidad SNMP Política de acceso SNMP Fig. 12.8 Conceptos administrativos
12.9 Configuraciones para el uso del protocolo SNMP en entornos heterogéneos
Las diversas configuraciones entre sistemas de gestión distintos y/o de diferentes fabricantes en una red limitan el acceso a la información de las bases de datos de gestión (MIBs). A continuación se describen algunas de las configuraciones de redes formadas con nodos heterogéneos más utilizadas. 12.9.1 Sistemas de gestión de red basados en SNMP emergentes
Las aplicaciones de gestión SNMP de distintos fabricantes pueden actuar sobre la información de gestión de tipo público (MIB2) común de todos los nodos de la red; sin embargo, cada una de ellas sólo puede entender la información de gestión de los nodos que pertenezcan a la misma marca. Esto se debe a que son MIBs propietarias. Por otra parte, la base de información definida por RMON suele también ser visible por las aplicaciones basadas en SNMP, complementando la gestión de la red.
Fig. 12.9 Esquemas de actuación en redes con sistemas de gestión homogéneos 12.9.2 Sistemas de gestión de LANs heterogéneas
En el caso de disponer de sistemas de gestión diferentes en la misma red, en principio tanto la información de gestión como los protocolos de gestión funcionan independientemente. Actualmente, las plataformas de gestión más evolucionadas permiten compatibilidad entre agentes de distintos estándares como SNMP y CMIP. Tal como se observa en la figura 12.10, el protocolo CMIP pasa a denominarse CMOT en entornos de redes TCP/IP, y CMOL en versión simplificada para la gestión de redes de área local.
Gestor SNMP
Gestor CMISE
Pila de protocolos OSI con CMIP o CMOL
SNMP CMOT
Agentes de objetos gestionados TCP/IP
SNMP/OSI
Agentes de objetos gestionados OSI
OSI: interconexión de sistemas abiertos SNMP: protocolo de gestión de red simple CMISE: elemento de servicio de información de gestión común CMIP: protocolo de información de gestión común CMOT: protocolo de información de gestión común sobre TCP/IP CMOL: protocolo de información de gestión común sobre LLC
Fig. 12.10 Esquemas de actuación en redes con sistemas de gestión heterogéneos
A pesar de ser las MIBs unas bases de datos para gestión de red muy utilizadas y de fácil uso, presentan diversos problemas respecto a otros entornos de gestión más evolucionados. Entre los aspectos negativos considerados figuran los siguientes: - Las comunicaciones datagrama son ineficientes para la obtención de grandes cantidades de información de las bases de datos. - No existen mecanismos para la obtención agregada de datos de las MIB. - No existen mecanismos de compresión de la información en la fuente. - No existen mecanismos de correlación de la información en la fuente (p.e. la unión de tablas SNMP). - No existe control de acceso a MIB. - La estructura estática de la información en las MIB limita la manipulación y la reconfiguración dinámica, aunque se puede hacer uso de MIBs con información aportada por fabricantes,... - Existe gran heterogeneidad en el modelo sintáctico/semántico. - No hay modelo explícito de control (p. e. en invocaciones remotas). - No hay mecanismos para representar y manipular relaciones. - El modelado de sistemas jerárquicos puede ser complicado. 12.10 Conclusiones sobre SNMP
Entre las ventajas del protocolo SNMP se pueden considerar las siguientes: - Es un estándar de mercado. - Es simple, fácil de usar. - Modelo útil para el acceso a datos de gestión de la red. - Acceso y organización eficientes de los datos gestionados. - Independencia del entorno de comunicaciones. - Capacidades generales de monitorización y control. Respecto a los inconvenientes más importantes se pueden enumerar los si guientes: - Limitaciones en el mecanismo de obtención de información: Falta de obtención selectiva de información. - No dispone de controles de gestión. - Limitaciones de las capacidades de modelado de datos: MIB estática Correlación de datos difícil Modelados de sistemas complejos.
12.11 Comparación entre los protocolos CMIP y SNMP
Finalmente, a título comparativo, se presenta una relación de temas donde se muestran similitudes y diferencias entre los protocolos CMIP y SNMP.
En cuanto a modelo de datos de instrumentación, el protocolo SNMP se representa a través de variables, tablas, Traps etc. mientras que CMIP utiliza un modelo de objetos extendido. Respecto a identificación de nombres de datos gestionados, SNMP hace uso de un árbol de directorios estático y CMIP hace uso de un árbol de directorios dinámico. En relación a la representación de datos uniforme, SNMP utiliza un número mínimo de tipos de datos ASN.1, mientras que CMIP hace uso de un rango extendido de tipos ASN.1. También, respecto al soporte de transporte de primitivas query/responses de gestión, SNMP utiliza datagrama, con la máxima independencia de la elección de transporte, mientras que CMIP utiliza conexiones con fuerte dependencia del estándar OSI. A nivel funcional, el protocolo CMIP obtiene un mayor rendimiento de los mensajes enviados ya que se reduce la señalización respecto al protocolo SNMP. CMIP también es más seguro que el SNMP. A nivel operacional, el protocolo CMIP se basa en una arquitectura jerárquicamente distribuida, lo que permite que el número de objetos supervisados sea mayor que en el protocolo SNMP que, al ser de tipo centralizado, viene limitado por la capacidad tecnológica de las plataformas de gestión. De todas formas, hay que decir a favor del protocolo SNMP que es más simple y que el personal requerido para su mantenimiento se reduce. A nivel de implementación, hay que decir que un agente CMIP ocupa unos 400 Kbytes o más mientras que un agente SNMP ocupa de 20 Kbytes a 60 Kbytes. También, el coste de procesado y de la misma aplicación es más elevado en una plataforma CMIP. En cuanto al soporte por parte de fabricantes, el protocolo SNMP es el utilizado por la gran mayoría de fabricantes y clientes, y existe una multitud de productos comerciales. Los gastos de mantenimiento también suelen ser menores en SNMP al ser más simple y tener una mayor base comercial. Finalmente, el protocolo CMIP permite más extensiones, es más escalable, permite la herencia de atributos y es más flexible que el protocolo SNMP. 12.12 SNMPv2
Este protocolo de gestión que se definió en 1993, es una versión más avanzada del SNMP. SNMPv2 aporta una serie de ventajas respecto a la primera versión, entre las cuales pueden destacarse: - Permite una mayor eficiencia en la transferencia de información. - Admite mecanismos de seguridad como la autentificación y el cifrado frente al SNMP (no implementados). - Permite la comunicación entre estaciones de gestión. - Parte de un modelo de comunicaciones extendido considerablemente. - Permite una señalización extendida de errores. - Permite el uso de varios servicios de transporte. El sistema basado en SNMPv2 soluciona muchos de los problemas de su anterior versión, SNMP; sin embargo, su mayor complejidad está coartando su desarrollo.
Los mensajes enviados por la plataforma de gestión de red a los agentes SNMP están formados por identificadores de objetos MIB junto con instrucciones, a fin de cambiar u obtener un valor. 12.12.1 Operaciones de SNMPv2
El protocolo SNMPv2, que incluye los mensajes de la primera versión SNMP, dispone de los siguientes tipos de mensajes: - GetRequest: petición de valores específicos de la MIB. - GetNextRequest: proporciona un medio para moverse por la MIB.
Petición del objeto siguiente a uno
dado de la MIB (orden lexicográfico). - GetBulkRequest: petición de múltiples valores. - Response: devuelve los valores solicitados por las operaciones anteriores gestor a gestor o agente a gestor). - SetRequest: permite asignar un valor a una variable. Debido a posibles problemas de seguridad esta función suele estar desactivada. - InformRequest: transmite información no solicitada (gestor a gestor). - SNMPv2-Traps: permite a los agentes informar de sucesos inusuales (p.e. ColdStart, WarmStart, LinkDown, LinkUp, AuthenticationFailure, EGPNeighborLoss, EnterpriseSpecific).
Tipo PDU Petición id
0
0
Campos variables
GetRequest PDU, GetNextRequest PDU, SetRequest PDU, SNMPv2 Trap PDU, InformRequest PDU Tipo PDU Petición id error-status error-indice
Campos variables
GetResponse PDU Tipo PDU Petición id No repet.
Max. repet.
Campos variables
Valor2
...
GetBulkRequest PDU Nombre 1
Valor1
Nombre2
Nombre n
Valor n
Campos variables Fig. 12.11 Formatos de PDU para SNMPv2
Sin embargo, el hecho de su incompatibilidad con la versión SNMP y la mayor complejidad añadida a las plataformas están desestimando su futura implementación. El desacuerdo en el consorcio sobre las recomendaciones acerca de seguridad propuestas en SNMPv2 ha propiciado finalmente su incorporación en una nueva versión SNMPv3.
El protocolo SNMPv3 es una evolución de la serie de modelos de gestión vistos anteriormente. SNMPv3 está aún en fase de especificación; sin embargo, se pueden describir algunas de las características en las que se está trabajando. Las áreas a las que SNMPv3 va enfocado son, primordialmente, mejorar la seguridad y la administración respecto a SNMPv2. Respecto a la estructura de la información de gestión, la SMI está dividida en tres partes: definiciones de módulos, definiciones de objetos y definiciones de notificaciones. Las definiciones de módulos (macros ASN.1: MODULE-IDENTITY) se utilizan para describir semánticamente los módulos de información. Para las definiciones sintácticas y semánticas de objetos se usan macros ASN.1: OBJECT-TYPE. Las definiciones de notificaciones usan macros NOTIFICATION-TYPE y describen transmisiones no solicitadas de información de gestión. Entre los tipos de datos que se incorporan a la SMI (RFC 1902) están: - IMPORTS para permitir la especificación de items que se usan en un módulo MIB, pero definidos en otro módulo MIB. - MODULE-IDENTITY especifica una descripción e información administrativa para un módulo MIB. - OBJECT-IDENTITY y los OID se asignan para especificar un valor OID. - OBJECT-TYPE especifica el tipo de dato, estatus y la semántica de los objetos gestionados. - SEQUENCE es un tipo que permite asignar los objetos de una lista en una tabla. - NOTIFICATION-TYPE se especifica para construir una notificación de eventos.
En SNMPv3 se prevé también aumentar el mapeo de mensajes tipo SNMP a otros tipos de protocolos de transporte. Desde el punto de vista de arquitectura de gestión se extiende el nombrado de: - Motores y aplicaciones. - Entidades (proveedores de servicio tales como motores e n agentes y gestores). - Identidades (usuarios de servicio). - Información de gestión, incluido soporte para múltiples contextos lógicos. Los cinco tipos de aplicaciones que se prevé asociar con un motor SNMP son: generadores de comandos, receptores de comandos (generadores de respuestas), originadores de notificaciones, receptores de notificaciones y envío de proxies. Respecto a las mejoras en seguridad, SNMPv3 utilizará MD5 y algoritmos de Hash para firma digital y proteger contra la modificación de la información proporcionando integridad de datos, autentificación de origen y de usuario. 12.14 Remote Network-Monitoring (RMON)
El Remote Network-Monitoring (RMON), especificado en 1994, define una MIB (que suplementa la MIB II) para permitir la monitorización remota, y proporciona al gestor de red información vital acerca de la interconexión con otras redes. Mientras que el protocolo SNMP se diseñó en función de una arquitectura de polling pasivo, el RMON permite al usuario el uso de agentes “inteligentes” que responden de acuerdo con acontecimientos excepcionales. Esto reduce el tráfico asociado con la red de gestión, mientras que permite al equipo remoto alertar a la plataforma de gestión SNMP cuando ocurre algún problema. Entre las características principales cabe destacar: - Operación off-line: pueden interrumpirse procesos de polling mientras el monitor sigue funcionando siempre. - Monitorización preventiva: en caso de sistemas bien dimensionados, se puede enviar periódicamente información de estatus de la red a fin de prevenir posibles problemas. - Detección de problemas y generación de informes: disposición de sondas activas. - Datos de valor añadido: el monitor de redes puede realizar análisis específicos de la información de su red que no son accesibles con métodos directos (sólo hasta nivel MAC). - Multiples gestores: RMON permite la estructura de plataformas gestoras dispuestas de forma distribuida y jerárquica. El estándar RMON es un sistema de monitorización remota que está creciendo muy deprisa como solución a problemas de gestión de red centralizada. Uno de sus principales alicientes es el de proporcionar una arquitectura distribuida, frente al carácter centralizado del protocolo SNMP. Las funciones MIB asociadas a RMON1 entran dentro los siguientes grupos: - Actividades a nivel de aplicación - Filter : mecanismo de selección de paquetes de acuerdo a un determinado criterio. - Packet capture: colección de paquetes y mecanismos de carga a través de criterios de filtrado.
- Events: mecanismo de control para acciones disparadas por una alarma. - Estadísticas de host - Host : descubrimiento y estadísticas de hosts por direcciones MAC. - Host Top N : estadísticas ordenadas por dirección MAC. - Matrix : seguimiento de la conversación entre dos hosts. - Otros grupos - Statistics: tráfico LAN acumulado y estadísticas de errores. - History: estadísticas de muestreo de intervalo para análisis de tendencias. - Alarms: niveles de disparo. - Token Ring: 4 parámetros de las redes token-ring. En las figuras siguientes se realiza una comparación de los entornos de una red, gestionada con y sin sonda RMON.
•
Red con sonda RMON (agente RMON): reduce el tráfico de gestión ya que analiza el tráfico, las alarmas, etc. y procesa toda la información de la red, mandando únicamente los datos significativos a la estación de gestión (p.e. estadísticas).
Sonda RMON Interconexión Interconexión Interconexión
Sonda RMON
Sonda RMON
Estación de gestión
Fig. 12.13 Esquema de redes con sonda RMON
•
Red sin sonda RMON: se caracteriza por realizarse un polling continuo de la estación de gestión al monitor. La estación de gestión ha de procesar toda la información lo que provoca un mayor tráfico de gestión.
Analizador de redes Interconexión Interconexión Interconexión
Estación de gestión
Fig. 12.14 Esquema de redes sin sonda RMON
12.15 RMON 2
RMON2 aparece como especificación RFC en 1996 como una extensión de RMON. RMON2 añade respecto a la versión uno, la decodificación de paquetes entre los niveles 3 y 7 del modelo OSI. Ello trae consigo las siguientes consecuencias: a) Una sonda RMON2 puede monitorizar tráfico de acuerdo con protocolos de nivel de red y direcciones, incluido el Internet Protocol (IP). Esto permite a la sonda observar más allá de los segmentos LAN, a los cuales está conectado, y ver el tráfico entrante/saliente a la LAN vía routers (nodos específicos). Aplicable a la gestión de interconexión de redes. b) A causa de que la sonda RMON2 puede decodificar y monitorizar tráfico a nivel de aplicación, tal como email, transferencia de ficheros, y protocolos WWW, la sonda puede grabar tráfico a y desde hosts para determinadas aplicaciones. RMON2 introduce, además, dos nuevas funcionalidades que mejoran el protocolo RMON: el uso de objetos indexados que no son parte de la tabla que éstos indexan, y el uso de indexado de filtro temporal. Los grupos MIB que incorpora RMON2, respecto a la versión anterior, son los siguientes: - Protocol Discovery - Protocol Distribution - Adress Mapping - Network Layer Host - Network Layer Matrix - Application Layer Host - Application Layer Matrix - User History - Probe Configuration - RMON Conformance
13 Gestión distribuida Las arquitecturas de red basadas en gestión distribuida son las que permiten la obtención de mejores rendimientos en grandes redes. La gestión de un gran número de nodos no puede solucionarse correctamente con los modelos cliente/servidor basados en el protocolo SNMP. 13.1 Distributed Computing Environment (DCE)
El Distributed Computing Environment (DCE) es una plataforma de procesamiento distribuido, esponsorizada por la Open Software Foundation (OSF). Soporta operaciones transparentes para distribuir recursos a través de redes heterogéneas. Está organizada en función de la relación clienteservidor [KNO1]. Existen tres grupos principales de funcionalidad DCE: 1. Remote Procedure Calls a servidores (DCE-RPC), utilizado también en DCOM. 2. Servicios de seguridad entre servidores y clientes 3. Localización de servidores y clientes dentro de una red. La unidad de organización principal de la DCE es la celda, que consta de recursos, sistemas y usuarios que tienen un propósito común y comparten actividades DCE comunes. Típicamente una celda contiene hosts y servidores conectados a una red de área local (LAN). 13.1.1 Componentes principales de DCE
El modelo de distribución está basado en su software RPC (Remote Procedure Call) y utiliza un modelo de distribución orientado a procedimiento. Permite a clientes/servidores comunicarse a través de diálogos de peticiones/respuestas (una petición iniciada por un cliente). El cliente no tiene constancia de la posición del servidor. Es el concepto clave de procesamiento distribuido. Existen una serie de componentes principales que conforman la arquitectura DCE: entre ellos se puede citar los threads (enlaces). Los enlaces comparten recursos más que copiarlos (excepto para pilas y registros que están separados para cada enlace). Se utilizan también los servicios de directorio, que
sirven para localizar recursos en una red de redes. Para ello usa el nombrado de la notación de X.500 y específicas de DCE. Así, se tienen: - Cell Directory Service (CDS): controla los servicios de directorio dentro de una celda. - Global Directory Service (GDS): controla los servicios de directorio fuera de una celda. Otros componentes de la arquitectura DCE son los siguientes: - Distributed Security Service (DSS): proporciona servicios de seguridad de una manera centralizada en lugar de realizar procedimientos de autentificación entre cada host. Proporciona autentificación, autorización, integridad de datos y privacidad de datos. - Distributed Time Service (DTS): proporciona un medio de sincronización de actividades entre hosts y red. - Distributed File Server (DFS): permite acceder ficheros en hosts entre una red o redes. Proporciona ficheros de back-up y servidores de back-up (si un servidor se pierde, otro puede realizar sus actividades). También organiza servidores en grupos lógicos, llamados dominios administrativos, facilitando el trabajo con grandes redes. Así como el uso de herramientas de administración. 13.1.2 Restricciones en el uso de DCE
Entre las restricciones a la hora de acometer una gestión con DCE hay que decir que la librería de ejecución de DCE debe ejecutarse en cada host (no importa si es servidor o cliente). La configuración mínima de una celda es de RPC, enlaces, CDS, DSS y DTS. Además, a los recursos puede accederse sólo después de una autentificación correcta. 13.1.3 Razones para escoger DCE
Entre las razones para la elección de DCE como arquitectura de gestión, se puede citar el hecho que permite el desarrollo de aplicaciones independientemente de la red, sin tener que desarrollar funciones genéricas como RPC, enlaces, etc. Se trata, además, de un entorno coherente, basado en estándares: es un entorno de computación abierto y que permite la compartición transparente de ficheros. El hecho de ser un entorno distribuido proporciona información independientemente de donde está almacenada, escondida la complejidad de la red, y se obtiene un conjunto integrado de servicios. Además, DCE previene el acceso no autorizado a recursos, y para su implantación no se necesitan las capacidades de un sistema orientado a objetos. Finalmente, DCE soporta comunicaciones síncronas entre servidores y clientes. 13.2 Distributed Management Environment (DME)
La Open Software Foundation (OSF) seleccionó un conjunto de tecnologías para integrar dentro de su Distributed Management Environment (DME). Esta tecnología, propugnada inicialmente por HP, es capaz de trabajar con cualquier sistema operativo y simplifica la gestión de sistemas distribuidos y stand-alone, reduciendo los costes para administración de sistemas.
Aplicaciones de gestión Opción de gestión de red (NMO)
Servicios de gestión Servicios Objeto Marco de actuación DCE con extensiones
Fig. 13.1 Estructura del marco de actuación DME
Aplicación cliente
CORBA IDL Stub
DCE RPC Runtime y servicios (directorio, seguridad, etc)
DCE IDL Stub DCE IDL Runtime
Fig. 13.2 Componentes cara cliente
DME comprende varios grandes componentes en dos grandes grupos: un marco de actuación y una serie de servicios distribuidos. Dentro del marco de actuación, presenta una infraestructura orientada a objetos para aplicaciones de gestión distribuida, la Object Management Framework (OMF) con una Distributed User Interface (DUI) que permite el soporte para el Simple Network Management Information Protocol (SNMP) y el CMIP, la Network Management Option (NMO). También dispone de Distributed Notificacion Services. En cuanto a los servicios distribuidos, permiten la instalación y distribución de software, licencia de software, integración de ordenadores personales o bien la gestión de hosts.
CORBA es una especificación para una arquitectura orientada a objetos estándar para aplicaciones (Object Management Architecture , OMA). CORBA se definió primero por el Object Management Group (OMG) en 1990 [CHA1, OR1]. En la actualidad, existe una necesidad de integrar una multitud de diferentes elementos de trabajo, así que la red pueda utilizar el hardware existente y el software, y así solucionar problemas de costes actuales y futuros de las empresas. CORBA proporciona la posibilidad de dar acceso a información distribuida y a recursos desde dentro de aplicaciones de sobremesa populares; proporcionar datos y sistemas disponibles como recursos de red; aumentar las herramientas, aplicaciones con funciones de cliente y capacidades para un entorno particular. Además, CORBA permite el cambio y evolución de los sistemas basados en red para reflejar nuevas topologías o nuevos recursos. CORBA permite la computación distribuida de objetos, es decir, dos o más partes de software comparten información con cada otra. Para ello, sin embargo, hay aspectos que se deben tener en cuenta, como la unión de computación distribuida con un modelo de objetos o el uso de un broker . Un modelo de objetos es un concepto de computación orientado a objetos. Se basa en los conceptos de abstracción, encapsulación, herencia y polimorfismo. Abstracción es la capacidad para agrupar objetos y enfocar las características comunes del grupo. La encapsulación esconde los detalles de implementación de un objeto en función de los servicios que puede proporcionar. La herencia permite pasar junto a las capacidades y comportamientos de un objeto a otro. Finalmente, el polimorfismo es la capacidad para sustituir objetos con la identificación de interfaces en el tiempo de ejecución. Existen diversas justificaciones para utilizar CORBA frente a otros mecanismos. Por ejemplo, el modelo de distribución CORBA está basado en el uso de objetos y utiliza un modelo de distribución orientado a objetos. De esta forma permite cubrir una necesidad de modificar o extender el sistema de
computación distribuido lo que permite obtener los beneficios que comporta el análisis y el diseño orientado a objetos. Esta flexibilidad resulta de gran utilidad en el diseño de los atributos de los objetos a gestionar, así como en el rendimiento de los protocolos de gestión. CORBA, además, soporta comunicaciones síncronas entre servidores y clientes y también cubre la necesidad de comunicaciones asíncronas sin usar una trayectoria predefinida. 13.3.1 Arquitectura CORBA
OMG a través de CORBA ( Common Object request Broker Architecture ) estandariza los mecanismos mediante los cuales los objetos envían mensajes y reciben respuestas, los servicios necesarios que incluye y ofrece interoperatividad entre aplicaciones. OMG proporciona un modelo, una arquitectura y un lenguaje (IDL, Interface Definition Language) para la definición de la interfaz de los objetos. CORBA propone una aproximación consistente en el desarrollo de una interfaz independiente de todo lenguaje, que permita invocar las operaciones sobre objetos, sin saber dónde éstas van a ser ejecutadas. Los objetos clientes se comunican con los objetos servidores mediante un conmutador de mensajes (ORB) que recibe una serie de peticiones y retorna con las respuestas correspondientes. Solicitudes
ORB (mecanismos) Respuestas Fig. 13.4 Esquema de flujos de información en un ORB
Objetos clientes
Herramientas comunes
Broker de petición de objetos (ORB) Descripción de los servicios ofrecidos a través de IDL Objetos servidores
Fig. 13.5 Esquema de servicios ofrecidos a través de IDL al ORB
La función principal del agente ORB es la de asegurar la independencia de localización e implementación de los objetos, y responder de la interoperatividad entre máquinas diferentes. Para ello, debe conseguir que el cliente sea capaz de ver la interfaz del objeto de manera independiente de su ubicación, del lenguaje de programación que lo implemente, y de cualquier aspecto que la interfaz no refleje expresamente. El funcionamiento de CORBA se sustenta en 5 componentes principales: el núcleo de ORB ( ORB core), el lenguaje de definición del interfaz (IDL), el interfaz de invocación dinámica (DII), el almacén de interfaces (IR) y los adaptadores de objeto (OA). El nucleo de CORBA es responsable de la recepción desde el cliente y entrega posterior de las peticiones a los servidores correspondientes. Los clientes no tienen por qué conocer dónde residen los objetos de red, cómo se comunican, cómo están implementados, cómo están almacenados, ni tampoco cómo se ejecutan o procesan. Para que un cliente pueda efectuar una petición sobre un objeto, debe conocer una referencia de objeto de él. CORBA especifica dos alternativas mediante las cuales los clientes pueden efectuar sus solicitudes sobre objetos: invocaciones estáticas vía una interfaz específica, o invocaciones dinámicas vía la interfaz de invocación dinámica (DII) del ORB. El lenguaje de definición del interfaz permite la especificación de las interfaces a objeto. Es un lenguaje declarativo, cuya sintaxis es similar a la de C++, que proporciona tipos de datos básicos (enteros, reales, etc.) estructurados (estructuras y uniones) y plantillas (templates). Se emplea en la declaración de operaciones para definir los tipos de argumentos y los valores de retorno. La interfaz de invocación dinámica permite que aquellas declaraciones de interfaces en IDL de las que los clientes no tenían conocimiento en tiempo de compilación, y que han sido compiladas en C++ o C, puedan ser invocadas por los clientes para operar sobre objetos conocidos. Por ejemplo, un constructor de una interfaz gráfica de usuario GUI puede, dada una lista de referencias a objeto, permitir a los usuarios hojear el almacén de interfaces, aprender sobre las operaciones soportadas por cada objeto y, entonces, invocar operaciones sobre ellos para ver cómo se presentan en pantalla. En suma, el DII es una matriz genérica del cliente capaz de avanzar cualquier petición sobre un objeto. El almacén de interfaces guarda de forma persistente la definición de las interfaces (InterfaceDef) de todos los objetos declarados IDL, y pueden ser consultados por medio de la operación get_interface(), la cual devuelve una referencia de objeto a un Interfacedef describiendo la interfaz del objeto solicitado. Los adaptadores de objeto proporcionan los medios por los cuales varios tipos de implementaciones utilizan los servicios de ORB, tales como la generación de referencias a objeto, la invocación de método de objeto, la seguridad o la activación y desactivación de objetos e implementaciones. El hecho de que CORBA admita varios tipos de implementaciones (por ejemplo, aplicaciones tradicionales o nuevos desarrollos O-O) le adjudica flexibilidad suficiente para permitir la integración de aplicaciones heredadas sin perjudicar a nuevos objetos definidos, restringiéndolos a un conjunto limitado de criterios de implementación. Los servicios que los OA deban proporcionar podrán ser proporcionados delegándolos al propio ORB o bien efectuándolos él mismo.
Núcleo del broker de petición de objetos (IIOP) Fig. 13.6 Estructura de un ORB CORBA 2
13.3.2 Pasarela CORBA/CMIP
Una de las implementaciones en CMIP que se puede encontrar en el mercado es la pasarela CORBA/CMIP UHC, que permite que en una aplicación basada en CORBA se pueda controlar o se puedan visualizar objetos basados en los agentes Q3 de CMIP, y permita recibir los eventos emitidos por los agentes de CMIP. La pasarela CORBA/CMIP UHC trabaja según los principios definidos en el Open Group/NMF Join Inter-Domain Management Force (JIDM).
Los objetivos básicos del diseño de la pasarela CORBA/CMIP UHC son: - Proporcionar una implementación escalable que permita el acceso a un número configurable de agentes OSI. - Incluir los principios de traducción definidos por el JIDM. - Permitir una configuración completamente dinámica en tiempo de ejecución de la información del diccionario. - Que las prestaciones de la pasarela sea independiente del número y tamaño de los agentes de la red. La pasarela incluye un compilador GDMO a IDL, que traduce de GDMO a IDL de CORBA y proporciona la información de mapeado que necesita el kernel de la pasarela. Una de las funcionalidades de la pasarela permite una actualización dinámica de la información del diccionario, incluir nuevas clases de objetos y agentes OSI en tiempo de ejecución. Esto se realiza implementando la información del diccionario como un MIB local accesible mediante un protocolo Q3, la interfaz de CORBA o la interfaz de gestión local de la pasarela. A partir de las funcionalidades básicas de traducción CORBA/CMIP, la pasarela añade las siguientes funcionalidades adicionales:
- Gestor de eventos genéricos: cumple las normativas X.734 y X.735, se encarga de la recepción, redirección y memorización de los eventos. - Q3IM: gestión interna de Q3ADE, que es un paquete de aplicaciones para el desarrollo TMN, y protocolo de gestión de MIB. - Pasarela de SNMP: accede a los agentes SNMP según las especificaciones NMF IIMC. - ADK: monitoriza la calidad de servicio y realiza estadísticas. La pasarela CMIP/CORBA UHC es una pasarela general con diversos campos de aplicación: - El producto se puede utilizar como una pasarela independiente entre dominios CORBA y CMIP. - El producto se puede utilizar para disponer de aplicaciones estandarizadas de gestión, que permite mapear a un número elevado de lenguajes de programación y mediante el cual se pueden gestionar los agentes CORBA, CMIP y SNMP. - El producto se puede utilizar para implementar agentes heterogéneos capaces de ser gestionados por aplicaciones de gestión CORBA y CMIP. O erador o abonado
Sistema gestor
Browser web Browser web Browser web Interfaz de usuario
HTTP
PROXY (Cliente CORBA)
Sistema gestionado C O R B A
Pasarela CORBA/ CMIP
CMIP
Pasarela SNMP CORBA/ SNMP
Agente OSI
Agente SNMP
Recursos gestionados
Recursos gestionados
Servidores CORBA
Fig. 13.7 Esquema de una arquitectura CORBA compatible con protocolos SNMP/CMIP 13.3.3 Conclusiones
Como conclusiones, se puede resaltar que CORBA tiene ya un gran respaldo desde la industria. Existe una amplia gama de productos basados en CORBA. Además, su interoperabilidad se garantiza mediante la versión 2 del ORB, que incluye una notación IDL normalizada por la ITU. Esa misma interoperabilidad de ORBs permite utilizar CORBA como soporte de la interfaz X o Q en TMN. De todas formas hay que decir que la notación GDMO/ASN1 sigue siendo mejor alternativa como especificación de modelos de información. 13.4 Distributed Component Object Model (DCOM)
DCOM (Distributed Component Object Model) es un protocolo que permite a los componentes software comunicarse directamente a través de una red de manera fiable, segura y eficiente. Al
principio adoptaba el nombre de Network OLE. Actualmente DCOM está diseñada para utilizarse a través de múltiples protocolos de transporte de red, incluyendo los de Internet como HTTP. DCOM se basa en la especificación DCE-RPC de la Open Software Foundation y funciona tanto con applets java como con componentes ActiveX a través del uso del Component Object Model (COM) [CHA1]. DCOM fue desarrollado por Microsoft Corporation como respuesta a CORBA como arquitectura abierta. DCOM está disponible actualmente en la mayoría de sistemas operativos, si bien CORBA es más utilizado. DCOM especifica cómo se hacen las peticiones a un objeto y cómo se representan, comunican y mantienen las referencias a objetos. Tiene su aplicación en el diseño de las comunicaciones en entornos de red distribuidos. 13.4.1 OLE y el modelo de objeto COM
OLE es el acrónimo de Object Linking and Embedding que se refiere a enlazar e integrar objetos. La tabla de funciones de OLE está constituida por un agregado de servicios que dependen unos de otros, como el Component Object Model o COM. Otros son servicios dedicados a los servidores de objetos y a la programación de aplicaciones clientes, similares a las del ORB de CORBA. Estos servicios constituyen el OLE Automation. Por otra parte están los OLE Controls, redenominados ActiveX por Microsoft en 1996, para avanzar su posición en el contexto del World Wide Web y de Internet. La distribución de objetos en el sistema OLE es lo que ha dado lugar a la definición de DCOM. 13.5 Gestión basada en agentes inteligentes móviles
Actualmente se está planteando el uso de agentes inteligentes en todo tipo de redes avanzadas. Se pueden entender éstas como redes donde la información está disponible en cualquier momento, cualquier hora y desde cualquier terminal. Para que ello sea posible hay que plantearse los avances que en los últimos tiempos se han mantenido en entornos de comunicaciones móviles y personales. 13.5.1 Introducción a los agentes inteligentes
Un agente inteligente (AI) es un término que define desde interfaces de usuario adaptativos hasta comunidades de procesos inteligentes que cooperan unos con otros para conseguir realizar una tarea común. Como agentes moviles representan objetos activos o transportables que se mueven desde un sistema a otro para acceder a recursos remotos o incluso encontrar otros agentes y cooperar con ellos. Una última categoría de AI son los de programación remota y se consideran una alternativa a la programación remota, considerada alternativa a la basada en la estructura Remote Procedure Call (RPC). También pueden definirse los agentes inteligentes como entidades de software autónomas que se comportan de acuerdo a una inteligencia autocontenida. Entre los atributos de un agente se pueden considerar:
- Inteligencia: indica el método que se utiliza para desarrollar la lógica del agente o “inteligencia”. - Operaciones asíncronas: un agente podría ejecutar su(s) tarea(s) totalmente desacoplada de su usuario u otros agentes. - Comunicación de agentes: durante sus operaciones, los agentes podrían comunicar con varios recursos de sistemas y usuarios. - Cooperación de agentes: este atributo indica que el sistema de agentes permite la cooperación entre entidades de agentes. Esta cooperación abarca desde la clásica interacción cliente/servidor a negociaciones basadas en métodos de inteligencia artificial. - Movilidad de agentes: con el objetivo de realizar tareas específicas, los agentes podrían transportarse a través de la red hasta entornos remotos donde admitan su soporte. Existen diversos niveles de movilidad: ejecución remota y migración. 13.5.2 Clases de agentes inteligentes
Dentro del contexto de sistemas con un único agente se puede hablar de agentes locales en relación a agentes de red. En el contexto de sistemas multiagente, los agentes pueden estar basados en inteligencia artificial distribuida o bien ser agentes móviles. Agentes locales
Los agentes locales tienen como objetivo principal las interacciones típicas entre el usuario y el agente. También se denominan interfaces inteligentes. Por ejemplo: obtención y filtrado de información local, gestión de correo local, ordenación de reuniones, etc.
Agentes de red
Los agentes de red, en contraste con los agentes locales, pueden acceder no sólo localmente sino también a recursos remotos. Esto exige tener un conocimiento más o menos detallado de la infraestructura de la red y de los servicios que hay disponibles. Los agentes de red no cooperan entre ellos. Por ejemplo: asistentes personales: correos inteligentes (filtros basados en preferencias), motores de búsqueda (WWW).
Agentes basados en inteligencia artificial distribuida
El principal objetivo de estos sistemas multiagente es la coordinación de comportamiento inteligente entre una colección de agentes inteligentes autónomos. Cómo coordinan ellos sus conocimientos, objetivos y utilidades para planear y desarrollar conjuntamente acciones o solucionar problemas. Por ejemplo: monitorización de vehículos distribuida, CIM, gestión de telecomunicaciones. Estos agentes se desarrollan mediante técnicas de inteligencia artificial y podrían comunicarse y cooperar entre ellos. Son usualmente estáticos.
Agentes móviles
Los agentes móviles se sitúan principalmente en grandes ordenadores, ofreciendo un conjunto de servicios sofisticados. Por ejemplo: filtrado de Internet avanzado, agentes de búsqueda, mensajes inteligentes, comunicación inteligente y gestión. En cuanto a lenguajes, los más utilizados actualmente son el Safe-TCL y Java, que permiten ejecución remota de agentes. Los agentes basados en Telescript permiten la migración mientras están activos.
Inteligencia de X agente Operación X asíncrona Comunicación entre agentes Cooperación entre agentes Movilidad entre agentes
Agente de red
Agente DAI
Agente móvil
X
X
X
X
X
X
X
X
X
X
X X
Tabla 13.1 Clases de agentes inteligentes y sus características 13.5.3 Agentes móviles
La movilidad es quizás la característica más apreciada de los agentes a la hora de influir en la forma tradicional en que se realizan servicios y comunicaciones. Como contrapartida, la ejecución de programas (agentes) debe realizarse en entornos considerados seguros. Se pueden considerar las siguientes situaciones: - Procesado de tareas asíncrona y cooperativamente. - Personalización y configuración de servicios. - Uso de servicio instantáneo (NCs) y comercio activo. Se pueden distinguir los siguientes tipos: Clase de agente simple: ejecución remota o migración. Clase de agente cliente/servidor (p.e. CORBA). Clase de agente multimedia (p.e. MHEG). - Descentralización de gestión. - Comunicaciones inteligentes. - Obtención de información y soporte de tipos ti pos de información dinámica. 13.5.4 Arquitecturas de comunicaciones basadas en agentes
Los entornos de telecomunicaciones actuales están basados en dos tipos de redes: las redes inteligentes con el protocolo INAP, o bien la red de gestión de las telecomunicaciones (TMN), con el protocolo CMIP. Estos entornos representan los fundamentos para una creación eficiente y uniforme, y la provisión y gestión de servicios de telecomunicación avanzados. Ambos tipos de redes presentan arquitecturas altamente centralizadas en sus SCP, lo que las limita en su escalabilidad y flexibilidad para su crecimiento. Esto no ocurriría con el uso de agentes inteligentes. Se pueden hacer las siguientes aproximaciones a arquitecturas de servicio basadas en agentes: - Red inteligente: los agentes son entidades estacionarias en la red, que proporcionan la inteligencia necesaria y son capaces de realizar tareas predefinidas específicas autónomamente (en nombre de un
usuario o aplicación). Este tipo de agentes estáticos, tales como agentes de usuario o de gestión, podrían considerarse más como entornos de ejecución de agentes especializados, que ejecutan scripts (p.e. agentes de tipo de ejecución remota). - Mensaje inteligente: los agentes son entidades móviles, que viajan entre diferentes ordenadores/sistemas y realizan tareas específicas en posiciones remotas (tanto ejecuciones remotas de agentes como migraciones). Actualmente existe ya una arquitectura de comunicaciones basada en agentes. Se trata del entorno denominado Mobile IP. Ésta es una estructura basada en agentes estáticos ( Home Agent, Foreign Agent ). ). En este caso, el home agent de un nodo móvil es un router que al menos tiene una interfaz con el home link del nodo móvil. A un nodo móvil se le asigna una nueva dirección IP cuando visita un foreign li nk . Un foreign agent de un nodo móvil es un router que al menos tiene una interfaz con el foreign link del nodo móvil. En el caso anterior de la aproximación de sistema inteligente, ésta se basará en el despliegue de agentes estáticos en la red o sistema. En este caso, la red inteligente está previsto que evolucione hacia TINA. Adoptando la aproximación de mensajes inteligentes basada en agentes móviles, se podría utilizar en dos tipos de dominios, los llamados de intercambio de información asíncrona, tales como servicios de correo, y para el preestablecimiento de información en tiempo real, tales como servicios de comunicación multimedia.
Entorno de red Usuario A
Agente usuario
Negociación
Agente terminal Sistema final
Agente usuario
Usuario B
Agente terminal Gestión de conexión
Establecimiento de conexión Recursos de red
Fig. 13.8 Telecomunicaciones basadas en agentes estáticos
Fig. 13.9 Señalización basada en agentes móviles 13.5.5 Gestión basada en agentes
La distribución de tareas de gestión en la gestión de red se conoce como gestión por delegación, y adopta un paradigma de gestión descentralizada que tiene la ventaja del incremento de potencia computacional en nodos de la red y decrecimiento de la presión en sistemas de gestión de redes centralizados y en anchos de banda de red. La gestión por delegación habilita tanto la distribución temporal (p.e. distribución sobre tiempo) como la distribución espacial (p.e. distribución sobre nodos de red diferentes). El objetivo básico consiste en traer la inteligencia de gestión (p.e. los servicios de gestión), tan cerca como sea posible a los recursos gestionados, y a su representación lógica en forma de objetos gestionados. Esto es, mediante la delegación. Gestor
Descarga de scripts de gestión
Agente gestionado
Agente gestionado
Agente gestionado
Fig. 13.10 Delegación de inteligencia de gestión
El agente de gestión (nodo gestionado) tiene que verse como un entorno de agente de ejecución específico, que soporta la ejecución remota de scripts de gestión. Estos scripts podrían activarse según el tiempo, las actividades de gestión o la aparición de eventos específicos en el agente gestionado.
Las aplicaciones de gestión móviles representan una extensión del escenario anterior, donde las aplicaciones de gestión serán realizadas por medio de agentes móviles que también soportan migración. Gestor
1
4
2
Agente gestionado
3
Agente gestionado
Agente gestionado
Fig. 13.11 Servicios de gestión basados en agentes moviles
Sea T r Tiempo de respuesta completo. representa el tiempo de cálculo local del proceso del gestor en el gestor. t a describe el tiempo pasado por los agentes (SNMP o agente móvil). t d representa el retardo de la red. t m
T r = t m A1 , A2 ,..., An
t
t
+ a + d
representan los agentes distribuidos.
representa el retardo temporal desde el gestor al agente A1 . t 1m representa el retardo temporal entre el agente A1 y el gestor. t m1
Para el caso cliente/servidor tradicional, el gestor necesitará construir un mensaje de petición tantas veces como n, donde n es el número de nodos agentes. Además, un agente móvil sólo necesita procesar una vez. El tiempo de cálculo local del proceso gestor en cada caso será: t mSNMP
El retardo de la red total t d es 2nt para SNMP y (n+1)t para el caso móvil. Se asume que los retardos temporales entre todos los nodos distribuidos son los mismos. Si se asume también que t m , t a son constantes, el tiempo T r será: T r SNMP = 2nt + nα + β T r MOVIL = ( n + 1)t + α + β
13.5.6 Procesos elásticos Un proceso elástico es un proceso con múltiples enlaces que soporta la invocación remota de un conjunto de transformaciones elásticas. Estas transformaciones permiten procesos remotos para: - Extender la funcionalidad de un proceso elástico mediante la delegación de agentes a éste. - Controlar la ejecución de agentes. - Comunicarse con los agentes Un proceso P = < C, S > consiste en un programa código C y un estado S. C se define por una colección de fragmentos de código de programa que P puede ejecutar, C = {c1, c2, …,cn}. S es el estado de todos sus enlaces, S = {s1, s2, …,sn}. ci incluye todo el código en el programa principal ejecutable, y todo las rutinas de librería importadas que fueron explícita o implícitamente cargadas en su espacio de direcciones. si = < ci, xi > donde xi indica el estado de ejecución del enlace. Clientes
Agente delegado
Servidor elástico
Proceso Proceso elástico
Proceso
RPC
Runtime elástico
Fig. 13.14 Agentes móviles delegando a un servidor elástico
- Transformaciones de extensibilidad de código: permiten a un proceso remoto extender o contraer el código de programa C de un proceso elástico. - Una transformación suma incorpora un nuevo fragmento de código, c en un proceso en ejecución, P = < C, S >. Suma: {< C, S >, c} -> < {C U c}, S > - Una transformación borrado, borra un fragmento de código c, de un proceso P, y podría implícitamente borrar cualquier enlace cuyo estado esté asociado con el fragmento de código borrado. Borrado: {< C, S >, c} -> <{ C - c }, {S - {si: si = < c, xi > }} >
- Transformaciones de control de estado: permiten a un proceso remoto modificar el estado de un proceso elástico. - Una instanciación incorpora un nuevo enlace al estado de un proceso existente. Instanciación: {< C, S >, c} -> }} >
13. Gestión distribuida
201
- Una terminación borra un enlace de un proceso existente. Terminación: {< C, S >, sj} -> . - Una suspensión cambia el estado de un enlace que se está ejecutando a suspendido. Suspensión: { sj = < c, - >} -> { sj = < c, Sus >} - Un reenganche cambia el estado de un enlace suspendido a ejecución. Reenganche: { sj = < c, Sus >} -> { sj = < c, Run >} Un proceso elástico Pe, soporta la invocación remota de las seis transformaciones elásticas definidas anteriormente. Esto es, el código y el estado de un Pe pueden modificarse remotamente durante su ejecución, como el resultado de una interacción externa explícita. Un proceso elástico es una generalización de un entorno de múltiples enlaces dinámicos a uno de distribuido. Un server elástico es un proceso elástico cuyas interfaces de servicio pueden modificarse remotamente. Esto es, la interfaz del servidor es una colección de procedimientos de servicio { p1, p2,…,pn } que cambia dinámicamente y que puede invocarse remotamente por sus clientes.
14 Gestión basada en Webs La aplicación de las nuevas tecnologías de Internet a la gestión de redes intranet, sistemas y aplicaciones es lo que se denomina comunmente como gestión basada en web . La gestión basada en web puede acomodar los sistemas actuales de gestión, basados en SNMP, CMIP, DMI u otros sistemas propietarios. Existen recientemente sin embargo nuevas iniciativas como Web-based Enterprise Management (WBEM) y Java Management API (JMAPI) [WAT1, WHI1]. 14.1 Java Management API (JMAPI)
JMAPI es un conjunto de clases Java para el desarrollo de sistemas integrados, redes y soluciones de gestión de servicios para redes heterogéneas. Este núcleo de APIs puede usarse en un array diverso de entornos de computación que incluye numerosos sistemas operativos, arquitecturas y protocolos de red, lo que permite el desarrollo del bajo mantenimiento y un software heterogéneo desde una fuente única. JMAPI está orientado a resolver problemas de gestión de sistemas distribuidos. El componente que permite a una máquina ser gestionada es pequeño (p.e. applets/java beans), y los objetos agente para operaciones de gestión se descargan y ejecutan de forma segura. Esto minimiza la distribución y el problemas de las versiones para las operaciones de gestión, y fácilmente permite la modificación y extensión de las operaciones de gestión. Por otro lado, la máquina virtual java ha de residir en las plataformas que deben ser gestionadas. En el nivel superior, la arquitectura consiste de un browser user interface, admin runtime module, y appliances.
- El browser user interface es el mecanismo por el cual una administrador envía operaciones de gestión. Estas operaciones podrían invocarse interactivamente a través de un navegador de web o bien una aplicación independiente. - El admin runtime module es el mecanismo que proporciona objetos de gestión instanciados activos a aplicaciones. - Las appliances son los dispositivos de red que deben ser gestionados. El JMAPI está provisto de guías para interfaz de usuario, clases java y especificaciones para el desarrollo de aplicaciones para la gestión integrada de redes de siste mas y servicios. Esto incluye:
- Java Management API User Interface Style Guide - Admin View Module (AVM) - Base Object Interfaces - Managed Container Interfaces - Managed Notification Interfaces - Managed Data Interfaces - Managed Protocol Interfaces - SNMP Interfaces - Applet Integration Interfaces
Para la creación de los agentes que se sitúan en los dispositivos que se deben gestionar ( appliances), SUN proporciona el Java Dynamic Management Kit (JDMK), que se trata de un toolkit para dotar de funcionalidad a los agentes.
Applet JMAPI
HTTP
AVM base AVM Help AVM Integration Managed object interfaces
RMI
Admin runtime module
Fábrica de objetos gestionados Instancias de objetos gestionados Interfaces de agentes SNMP
Navegador de web para java
Agente objeto
SNMP Agente SNMP
Servidor HTTP
Interfaces de datos gestionados
JDBC
RMI
Appliance Fábrica de objetos agente Instancia de objetos agente Código JAVA
Métodos nativos
Base de datos
Fig. 14.1 Esquema de gestión con JMAPI
14.2 Web-based Enterprise Management (WBEM)
El WBEM trata de ser un estándar de facto para integrar aplicaciones de gestión de red en webs. Está definido por más de 50 fabricantes (julio 1996) entre los que destacan: Microsoft, Intel, Compaq, BMC y Cisco.
WBEM proporciona una arquitectura que permite soluciones de gestión para ser construidas cubriendo las áreas tradicionales de gestión de configuración, gestión de fallos, gestión de tarificación, prestaciones, seguridad, gestión de operaciones y planificación. Está construido para las necesidades de los estándares de Internet, tanto actuales como futuros, en las áreas de transporte, seguridad y protocolos de configuración. WBEM proporciona un modelo de datos que permite un modelado uniforme, así como la gestión del sistema, la red, y los elementos de aplicación. También direcciona las necesidades de un conjunto grande y distribuido de elementos de gestión, proporcionando una solución escalable. Componentes definidos por el modelo WBEM: - HyperMedia Managemen t Schema (HMMS) :
descripción de datos extensiva para representar el entorno gestionado que será definido por el Desktop Management Task Force (DMTF). Implementación independiente de los datos comunes, permitiendo datos de una variedad de fuentes para ser descritos, instanciados y accedidos a pesar de la fuente original de los datos. El HMMS está estructurado en distintos niveles. El primer nivel es el core schema (esquema del núcleo) que consiste de las clases a nivel superior, sus propiedades y asociaciones. El segundo nivel es una serie de esquemas específicos de dominio, que incluye el Windows NT, UNIX, red y esquemas de aplicaciones. El core schema establece una clasificación básica de los elementos del entorno gestionado, en elementos de sistema gestionado, componentes de aplicación, componentes de recursos y componentes de red. Las clases de componentes son agrupaciones de las clases de elementos de sistema gestionados. - HyperMedia Object Manager (HMOM):
un modelo de datos que consolida los datos de gestión provenientes de diferentes fuentes. Definición genérica para gestión de aplicaciones que agrega gestión de datos y usa uno o más protocolos para presentar una representación uniforme del browser (navegador) usando, HTML. Implementación de referencia C++. Un servidor HMMP que implementa un gran subconjunto del protocolo y del rol de los conmutadores para actuar como proxy en nombre de las peticiones de un cliente HMMP se denomina gestor de objetos hipermedia (HMOM). Los servidores HMMP que implementan un subconjunto pequeño de los protocolos y no tienen roles de conmutación se denominan típicamente proveedores (providers). - HyperMedia Management Protocol (HMMP):
un protocolo de comunicación sobre el cual la gestión de datos puede ser accedida y visualizada, y permite soluciones de gestión que son independientes de la plataforma y físicamente distribuidas entre los elementos de la empresa. Permite integrar HMMS, corriendo sobre HTTP y con interfaces planeadas a SNMP y DMI. El HMMP se utiliza para intercambiar mensajes que lleven información de gestión entre entidades HMMP. Las operaciones básicas en HMMP son OPEN, CLOSE, GET, PUT, DELETE; CANCEL, METHOD_EXEC, y METHOD_RETURN
Acceso basado en HTTP (incluyendo HMMP) SNMP, DMI, otros Dispositivos o aplicaciones
Dispositivos o aplicaciones
Dispositivos o aplicaciones
Fig. 14.2 Esquema de la arquitectura WBEM
Dispositivos o aplicaciones
15. Desktop Managment Interface (DMI)
207
15 Desktop Management Interface (DMI) El DMI (Desktop Management Interface) ha sido definido por el DMTF (Desktop Management Task Force) que es un consorcio internacional, fundado en 1992. Se han definido las siguientes especificaciones DMI1.0 (Abril 1994) y DMI2.0 (Marzo 1996). El DMI consta de tres capas. La capa del núcleo es la capa de servicios (Service Layer,SL), que es la aplicación local que gestiona las peticiones para información de gestión y las almacena en una base de datos. La capa de servicio soporta dos interfaces de programación de aplicaciones: la interfaz de componentes (Component Interface, CI) y la interfaz de gestión ( Management Interface , MI). El CI se implementa en los componentes de hardware o de software, tales como procesadores, impresoras, sistemas operativos, etc. Esta interfaz permite el acceso a información específica de componentes que se requiere para gestionar esos mismos componentes. El MI es la interfaz vista por las aplicaciones de gestión, que puede ser local o remoto. Los sistemas de gestión construidos en el esquema gestoragente pueden acceder a componentes desktop vía agentes proxy (SNMP, CMIP). La información de gestión se describe mediante un lenguaje especial llamado Management Information Format (MIF) que se utiliza en los ficheros MIF que se almacenan en bases de datos MIF. Las especificaciones DMI se refieren a los interfaces MI y CI, funciones soportadas por esas interfaces, y llamadas y procedimientos usados para acceder a esas funciones. Estas llamadas son gestionadas por la capa de servicio DMI. El conjunto de operaciones disponibles por las aplicaciones de gestión son las siguientes: - GET (valores de atributos de componentes gestionados). - SET (atributos y valores de atributos). - LIST (atributos actuales como almacenados en la base de datos MIF). - INDICATION (enviados por la SL a la aplicación como un suceso asíncrono). La lista de operaciones implementadas en la SL y disponibles a nivel de CI son: - INSTALL (usado en la instalación de los componentes gestionados). - REGISTER (registro dinámico de un punto de servicio en SL para ser gestionado). - INDICATE (evento asíncrono enviado a una aplicación registrada). La CI permite la creación de un punto de servicio que se usa para cargar los ficheros MIF asociados con nuevos componentes registrados.
Actualmente sólo existen especificaciones para la traducción de DMTF MIF a SNMP MIB y no en sentido contrario.
15.1 Common Information Model (CIM)
Actualmente se está especificando la versión 2 de CIM por el IETF, lo que significa que la información de gestión de redes y sistemas podrá recogerse y almacenarse de un mismo modo. Si a CIM se añade Extensible Markup Language (XML), la gestión de datos podría representarse sobre una interfaz web de forma estándar o a través de WBEM.
16 Plataformas de gestión de red Las plataformas de gestión son el elemento más visible de la gestión de una red y la clave del correcto funcionamiento de los sistemas de comunicaciones. Su ubicación física, el personal, el mantenimiento, la configuración de elementos, etc., son básicos para que no haya mayores problemas. 16.1 Plataformas de gestión
Las plataformas de gestión son la última etapa en la evolución de los sistemas de gestión, desde sistemas de monitorización pasivos a sistemas de gestión standalone, y finalmente a plataformas de gestión. Las plataformas de gestión se distinguen por los siguientes atributos únicos [GHE1]: - Separación de aplicaciones de gestión de los servicios de la plataforma por medio de APIs. - Entornos de desarrollo de aplicaciones de gestión independientes del software de fabricante. - Separación/modularidad de los servicios/componentes de la plataforma de gestión. - Soporte para la integración de aplicaciones de gestión. - Fundamento para la integración de tecnologías multifabricante, heterogéneas, distribuidas y abiertas. - Interfaz de usuario gráfica común. - Servicios de aplicaciones comunes (tiempo, directorio, seguridad). - Repositorio de datos de gestión comunes. - Sistemas de distribución de software y servicios de licencia software. - Reusabilidad de software y entornos de desarrollo de software de bajo coste. Dependiendo del nivel de sofisticación, las plataformas de gestión pueden proporcionar también: - Un entorno para paradigmas orientados a objetos (definiciones de i nterfaces, modelos, librerías,...). - Un entorno para invocar métodos de objetos e instrumentación. - Un entorno para soportar selectivamente sistemas propietarios. A continuación se describen brevemente algunas de las plataformas de gestión más importantes: HP OpenView. Sun Solstice. IBM System View. SPECTRUM de Cabletron. TME10 (Tivoli Management Environment)
El OpenView de HP ofrece una solución de gestión de red para gestión local y redes multifabricante de área extendida. Incorpora herramientas para el desarrollo de aplicaciones de gestión OSI. Utiliza una amplia variedad de protocolos (SNMP, CMIP, CMOT...). En el caso de gestión distribuida, hay que decir que HP fue el principal promotor del estándar DME (OSF). Otras características de OpenView: - Incorpora la aplicación Network Node Manager para redes TCP/IP. - Usa la base de datos INGRES (relacional). - Servidor del gestor de red OpenView. - Soporta los interfaces XOM/XMP. - Compilador GDMO/ASN1. - API SQL y permite exportar datos a RDBMS externas. X.11 OSF/MOTIF HP Open View Windows
HP Open View Windows Gestor objetos
Servicios de gestión Co- de datos municaciones Servicios de gestión de eventos
Gestor objetos Aplicación
Gestor objetos
Gestor objetos
Infraestructura
SNMP UDP IP
IP
CMIP TCP
Sistema de gestión de bases de datos
Base de datos
CMIP OSI Protocolos de comunicaciones
Fig. 16.1 Esquema funcional de la plataforma OpenView
16.3 SunNet Manager (SUN)
es una plataforma que está basada en arquitecturas y protocolos de cálculo distribuido. Los agentes que actúan con SunNet Manager son del tipo: SunNet Manager (Solstice)
- Niveles de protocolo de comunicaciones e interfaces tales como Internet MIB (RFC1066) a través de SNMP, RPC, Ethernet, FDDI y X.25. - Dispositivos de red tales como routers IP. - Estadísticas de recursos y sistema: a) Mecanismos del sistema tales como el uso de CPU y buffers de memoria libres. b) Disco y sistema de ficheros. c) Aplicación, bases de datos y estadísticas de servicios de red tales como NFS o RPC.
Discover
Resultados Gráfico Resultados navegador
Run-time MDB ASCII MDB
Eventos Log Datos Log
Cónsola
(open windows)
Servicios de comunicaciones (RPC) servicios agentes Agente
servicios agentes Agente proxy
servicios agentes Agente
Agente Objetos gestionados Fig. 16.2 Esquema funcional de la plataforma SunNet Manager
16.4 IBM System View para AIX
El origen de la plataforma de gestión IBM System View es la plataforma IBM Netview/6000 que a su vez partió de una licencia de HP Openview v.3 con algunas mejoras. El diseño de IBM Netview/6000 para AIX añadió una nueva componente al entorno tradicional de gestión IBM, que consiste de las siguientes entidades Focal Point (host basado en Netview), Entry Point (para dispositivos SNA), y Service Point (para dispositivos no SNA). Esta nueva componente se denomina Collection Point. El Collection Point actúa como un sistema de gestión de elementos independiente que recibe datos usando otros protocolos nativos aparte de SNA.
Otro aspecto destacable de la plataforma de gestión IBM System View es que no soporta el protocolo CMIP ni soporta actualmente ORB ( Object Request Broker ). 16.5 SPECTRUM de Cabletron
La primera versión de Spectrum de Cabletron data de 1992. Los componentes que forman el núcleo de la plataforma son el módulo SpectroSERVER y los clientes SpectroGRAPH. El SpectroSERVER consta de tres componentes el Virtual Network Machine (VNM), una bases de datos y un gestor de dispositivos de comunicaciones. El cliente SpectroGRAPH proporciona las capacidades de la interfaz gráfica de usuario. Las primeras versiones potentes de Spectrum no salieron hasta 1994. Actualmente no soporta el protocolo CMIP ni implementa el entorno de operación ORB. 16.6 TME10 (Tivoli Management Environment)
La arquitectura TME está formada por unos servicios desktop y el marco de la plataforma de gestión, que en principio pueden distribuirse separadamente. El modelo de información de objetos soporta herencia y relaciones de contención; sin embargo, no está basado en el modelo y las plantillas OSI MIM/GDMO. La comunicación entre gestor y agentes se realiza con mecanismos RPC de la pila de protocolos TCP/IP. Una plataforma que funciona como pasarela realiza una conversión de llamadas RPC y comandos SNMP a métodos IDL para ordenar acciones en objetos. El ORB disponible no soporta la versión CORBA 2.0 dado que ésta no soporta seguridad en el protocolo IIOP (OMG). TME10 incorpora su propia seguridad de forma integrada. Tivoli Systems se fundó en 1989 y fue adquirida en 1996 por IBM.
Conclusiones Actualmente todavía no existe una solución en el marco de la gestión de red que pueda proporcionar resultados satisfactorios a todo tipo de redes de comunicaciones. La TMN, o red de gestión de telecomunicaciones, es el camino más válido para enfocar la gestión en grandes redes. El protocolo CMIP y/o la arquitectura CORBA permiten utilizar las funcionalidades requeridas normalmente para gestionar redes con gran número de nodos. Sin embargo, desde un punto de vista comercial, existen pocas herramientas y aplicaciones. En el caso de redes de área local, de a lo sumo de centenares de nodos, se recomienda el uso de protocolos como SNMP y RMON/RMON2, sobre todo si se trata de redes que utilizan como protocolo de transporte el TCP/IP. Sin embargo, hay que considerar que la gestión quedará reducida a la simple monitorización de las funciones esenciales del sistema. Si la red que se quiere gestionar está constituida básicamente de nodos tipo PCs que soporten el estándar de gestión DMI, ésta será la solución más cómoda y completa. Para la gestión remota por Internet, están definiéndose una serie de soluciones como JMAPI, WBEM, CIM que, si bien son realmente potentes, actualmente están aún en una fase temprana de desarrollo.
[CAR1] Carleton, Russell. LNT Powered - SNMP Network Management , Interlink Network Group, 1996. [FEI1] Feit, Sidnie. SNMP: A Guide to Network Management , McGraw-Hill, 1994, ISBN 0070203598. [HAR1] Harnedy, Sean J. Total SNMP: Exploring the Simple Network Management Protocol, segunda edición, CBM Books, 1997, ISBN 0136469949. [HEI1] Hein, Mathis, Griffiths, David. SNMP Version 1 & 2: Simple Network Management Protocol: Theory and Practice, International Thomson Computer Press, 1995, ISBN 1850321396. [LEI1] Leinwand, Allan, Fang-Conroy, Karen. Network Management: A Practical Perspective, segunda edición, Addison-Wesley, 1995, ISBN 0-201-60999-1. [MIL1] Miller, Mark A. Managing Internetworks With Snmp (Network Troubleshooting Library), segunda edición, M&T Books, 1993, ISBN 1558515615. [PER1] Perkins, David, McGinnis, Evan. Understanding SNMP MIBs , Prentice Hall, 1997, ISBN 0134377087. [ROS1] Rose, Marshall T. The Simple Book: An Introduction to Network Management, segunda edición revisada, Prentice Hall Series in Innovative Technology, 1996, ISBN 0134516591. [ROS2] Rose, Marshall T., McCloghrie Keith, How to Manage Your Network Using SNMP: The Prentice Hall, 1995, ISBN 0131415174.
Network Management Practicum,
[STA1] Stallings, William. SNMP, SNMPv2, and RMON: Practical Network Management, segunda edición, 1996, ISBN 0201634791. TCP/IP
[BLA3] Black, Uyless D. TCP/IP and Related Protocols, segunda edición, McGraw-Hill Series on Computer Communications, 1992, ISBN 0070055602.
[BON1] Bonner, Patrick. Networking Programming With Windows Sockets, Prentice Hall Computer Books, 1995, ISBN 0132301520. [COM1] Comer, Douglas E. Internetworking with TCP/IP - Volume I: Principles, Protocols, and Architecture, tercera edición, Prentice-Hall, 1995, ISBN 0132169878. [COM2] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume II: Design, Implementation, and Internals, segunda edición, Prentice-Hall, 1994, ISBN 0131255274. [COM3] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume III: ClientServer Programming and Applications , Versión Windows Sockets. Prentice-Hall, 1997. ISBN 0138487146. [FEI2] Feit, Sidnie. TCP/IP: Architecture, Protocols, and Implementation with Ipv6 and IP Security , segunda edición, McGraw-Hill, 1996, ISBN 0070213895. [HUN1] Hunt, Craig. Networking Personal Computers with TCP/IP, O'Reilly & Associates, 1995. ISBN 1565921232. [HUN2] Hunt, Craig. TCP/IP Network Administration, O'Reilly & Associates, 1992, ISBN 093717582X. [QUI1] Quinn, Bob, Shute Dave. Windows Sockets Network Programming , Addison Wesley, 1996, ISBN 0201633728. ASN.1 y BER
[STE1] Steedman, Douglas. Abstract Syntax Notation One (ASN.1): The Tutorial and Reference , Technology Appraisals, Isleworth, Middlesex United Kingdom, 1993, ISBN 1871802067. Programación con Win32. Windows NT
[APP1] Appleman, Daniel. Visual Basic Programmer's Guide to the Win32 API, Ziff-Davis Press, 1996, ISBN 1562762877. [BEV1] Beveridge, Jim, Wiener Robert. Multithreading Applications in Win32. The Complete Guide to Threads , Addison-Wesley, 1996, ISBN 0201442345. [BRA1] Brain, Marshall, Win32 System Services: The Heart of Windows 95 and Windows NT , segunda edición, Prentice Hall, 1996, ISBN 0133247325. [HAM1] Hamilton, Dave, Williams Mickey. Programming Windows NT 4 Unleashed, Sams Publishing, Indianapolis, IN, 1996, ISBN 067230905 [LEW1] Lewis, Bil, Berg, Daniel J. Threads Primer, Prentice Hall, 1995, ISBN 0134436989 [MUR1] Murray, James D. Windows NT SNMP, O’Reilly, 1998.
[PEA1] Pearce, Eric, Windows NT in a Nutshell, O’Reilly & Associates, 1997, ISBN 1565922514. [PET1] Petrusha, Ron, Inside the Windows 95 Registry, O'Reilly & Associates, 1996, ISBN 1565921704. [PHA1] Phan, Thuan Q., Garg Pankaj K. Multithreaded Programming with Windows NT , Prentice Hall, 1996. ISBN 0131206438 [SHA1] Shah, Devang, Kleiman Steve, Smaalders Bart, Programming with Threads , Prentice Hall, 1996, ISBN 0131723898 [SIM1] Simon, Richard J., Gouker Michael, Barnes Brian, Windows 95 WIN32 Programming API 1571690093.
Bible, The Waite Group, 1996, ISBN
Sistema de señalización nº 7 y redes inteligentes
[ATS1] Nakamura Atsushi et al. SCP Architecture with Performance Flexibility, p. 1680-1684, Globecom 91. [BLA1] Black Uyless. The Intelligent Network. Customizing Telecommunication Networks and Services, Prentice Hall, 1998. [BLA2] Black Uyless. ISDN and SS7. Architectures for Digital Signalling Networks, Prentice Hall, 1997. [FAY1] Faynberg Igor et al. The Intelligent Network Standards, Mc Graw Hill, 1997. [INO1] Inoue Yuji et al. The TINA book, Prentice Hall 1999. [RUS1] Russell Travis. Signaling System #7, Segunda edición, Mc Graw Hill, 1998. Gestión según OSI [BLA4] Black, Uyless. Network Management Standards: Snmp, Cmip, Tmn, Mibs, and Object Libraries, second edition, McGraw-Hill Computer Communications, 1995, ISBN 007005570X. [GHE1] Ghetie Iosif G. Networks and Systems and Management . Platforms Analysis and Evaluation, Kluwer Academic Publishers, 1997. [SLO1] Sloman, Morris. Network and Distributed Systems Management , Addison Wesley, 1994. [STA2] Stallings, William. SNMP, SNMPv2 and CMIP. The Practical Guide to Network-Management Standards, Addison Wesley, 1993. Gestión de la red B-RDSI
[NAT1] Giroux Natalie, Ganti Sudhakar. Quality of Service in ATM networks, Prentice Hall, 1999. [SCH1] Schwartz Mischa. Broadband Integrated Networks, Prentice Hall, 1996. [VEN1] Venieris Iakovos, Hussmann Heinrich. Intelligent Broadband Networks, John Wiley, 1998. Gestión en redes de comunicaciones móviles
[AB1] Barba A., Cruselles E., Melús J. L. The CPNs in UMTS. Security aspects. Fourth WINLAB Workshop on Third Generation Wireless Information Networks. p 317-328, New Jersey, 1993. [AB2] Barba A., Pulido J. M., Melús J. L. Diseño de protocolos de gestión de movilidad entre redes IX Symposium nacional de la URSI. p 1184-1189, Las Palmas de Gran Canaria, septiembre 1994.
privadas y UMTS.
[DG1] Goodman David J. Cellular Packet Communications. p 1272-1280, IEEE Transactions on communications, agosto 1990. [DG2] Goodman David J. Trends in Cellular and Cordless Communications, IEEE Communications Magazine, vol. 29, N 6, p 31-40, junio 1991. [GA1] Garg Vijay K., Wilkes Joseph E. Wireless and Personal Communications Systems , Ed. Prentice Hall, 1996. [FRI1] Frisch Ivan T. et al. Network Management and Control. Vol 2. Plenum Press 1994. [HB1] Hans de Boer et al. Network aspects for the third generation mobiles, GLOBECOM '91, p 1517-1522. 1991. [HM1] Maab Henning, Schreyer Oliver, Stahl Martin. Directory Services for Mobility Management in Private Telecommunication Networks , p 1252-1256, ICC 1993. [JB1] Bursztejn J. Interoperability and/or convergence of mobile systems. p 9-12. RACE Mobile Telecommunications workshop, Amsterdam, 1994. [JI1] Yu James I. IS-41 for mobility management, p 158-162. ICUPC'92 Dallas, 1992. [JI2] Yu James I. Overview of EIA/TIA IS-41, p 220-224, PIRMC '92 Boston, 1992. [KJ1] Jakobs Kai, Reichert Frank. New Applications in Mobile Communication. The Directory. 41st VTC Conference, p 485-490, San Louis, 1991. [LH1] Hanzo L., Steele R. The Pan-European mobile radio system, Part I y II, BT, marzo-abril 1994. [MC1] Callendar Michael H.. Future Public Land Mobile Telecommunication Systems, IEEE Personal Communications, p 18-22. 4 trimestre 1994.
[MH1] Hakan Mitts. Universal wireless accesss to ATM, p 329-333, RACE Mobile Telecommunications Workshop, Portugal, 1995 [ML1] Laitinen Mikko, Rantala Jari. Integration of intelligent network services into future GSM networks. IEEE Communications Magazine, p 76-86, junio 1995. [MM1] Mouly Michel, Pautet Marie-Bernadette. Current evolution of the GSM systems, IEEE Personal Communications, p 9-19, octubre 1995. [MM2] M. B. Pautet and M. Mouly. GSM protocol architecture: Radio sub-system signalling , 41st IEEE Vehicular Technology, p 326 – 332, 1991. [RS2] Steele Raymond. The evolution of personal communications, IEEE Personal Communications. p 6- 11. 2º trimestre 1994. [VO1] Li Victor O. K., Qiu Xiaoxin. Personal Communication Systems (PCS), Proceedings of the IEEE, p 1210-1243, septiembre 1995. [TO1] Towle Thomas T. TMN as Applied to the GSM Network , IEEE Communications Magazine, p 68-73, marzo 1995. Gestión distribuida
[BA1] Bapat Subodh. Object-Oriented Networks, models for architecture, operations, and management, Prentice Hall 1994. [CHA1] Chauvet Jean Marie . Corba, Active X y Java Beans, Ed. Gestión 2000. [KNO1] Knouse Charles. Practical DCE Programming, Prentice Hall, 1996. [LE1] Lewis Geoffrey, Barber Steven, Siegel Ellen. Programming with Java IDL, John Wiley, OMG, 1998. [OR1] Orfali Robert, Harkey Dan. Client/Server Programming with Java and Corba , John Wiley, 1997. [WAT1] Watson Mark. Intelligent Java Applications for the internet and intranets, Morgan Kaufmann, 1997. [WHI1] White Barbara et al. Using Java Beans , QUE, 1997. Revistas Journal of network and systems management . Plenum Press. International journal of network management. John Wiley.
Anexos Anexo I: recomendaciones y normas Recomendaciones para TMN (ITU-T)
M.3000. Introducción a la recomendación TMN. M.3010. Principios para una red de gestión de telecomunicaciones. M.3020. Metodología para la especificación de la interfaz T MN. M.3100. Modelo de información de elementos de red genéricos. M.mocs (=M.3101). Requerimientos para conformar objetos gestionados en TMN M.3100. M.3180. Catálogo de información de gestión TMN. M.3200. Introducción a los servicios de gestión TMN. M.3300. Capacidades de gestión TMN presentadas en la interfaz F. M.3400. Funciones de gestión TMN. M.xfunc. Servicios de gestión TMN y funciones para la interfaz X. M.xinfo. Identificación de la información que debe ser intercambiada vía la interfaz X para diferentes casos de acceso. X.282. ISO/IEC 10742. Elementos de información de gestión relacionados con el nivel de enlace de datos OSI. X.283. ISO/IEC 10733. Elementos de información de gestión relacionados con el nivel de red OSI. X.284. Elementos de información de gestión relacionados con el nivel de transporte OSI. Serie X.700
X.700. Marco de gestión para OSI. X.701. Visión de la gestión de sistemas. X.702. ISO/IEC 11587. Contexto de aplicación para sistemas de gestión con procesado de transacciones OSI. X.710. Definición de CMIS. X.711. Especificación de CMIP. X.712. Definición de CMIP. Proforma del protocolo PICS. X.720. Estructura de la información de gestión: modelo de información de gestión. X.721. ISO/IEC 101652. Estructura de la información de gestión: definición de la información de gestión. X.722. Estructura de la información de gestión: GDMO. X.723. ISO/IEC 101645. Gestión de sistemas: información de gestión genérica.
X.725. ISO/IEC 10156-7. Modelo de relación general. X.730. ISO/IEC 101641. Modelo de información de red genérica. X.731. ISO/IEC 101642. Gestión de sistemas: función de gestión de estado. X.732. ISO/IEC 101643. Gestión de sistemas: atributos para representación de relaciones. X.733. ISO/IEC 101644. Gestión de sistemas: función de recopilación de alarmas. X.734. ISO/IEC 101645. Gestión de sistemas: función de gestión de recopilación de eventos. X.735. ISO/IEC 101646. Gestión de sistemas: función de control de registro. X.736. ISO/IEC 101647. Gestión de sistemas: función de recopilación de alarmas de seguridad. X.737. ISO/IEC 10164-14. Gestión de sistemas: clases de test de diagnóstico y confianza. X.738. ISO/IEC 1016413. Gestión de sistemas. Función de sumario. X.739. ISO/IEC 1016411. Gestión de sistemas. Métrica de objetos y atributos. X.740. ISO/IEC 101648. Gestión de sistemas. Función de pruebas de auditabilidad y seguridad. X.741. ISO/IEC 10164-9. Gestión de sistemas. Objetos y atributos para control de acceso. X.742. ISO/IEC 10164-10. Gestión de sistemas. Función de métrica de contabilidad. X.744. ISO/IEC 1016418. Gestión de sistemas. Función de gestión del software. X.745. ISO/IEC 10164-12. Gestión de sistemas. Función de gestión de test. X.746. ISO/IEC 10164-15. Gestión de sistemas. Función de inventario. X.750. ISO/IEC 10164. Conocimiento de gestión, función de gestión. Otras normas de ITU-T relacionadas con gestión según TMN. Q.811. Protocolos de capa baja para la interfaz Q3. Q.812. Perfiles de protocolo de capa alta para la interfaz Q3. Q.821. Etapas 2 y 3 de descripción de la interfaz Q3. Vigilancia de alarmas. Q.822. Descripción de las etapas 1, 2 y 3 para la interfaz Q3. Gestión de prestaciones. Q.823. Gestión de tráfico y encaminamiento. Q.824.0 - Q.824.6. Etapas 2 y 3 de descripción de la interfaz Q3. Administración de clientes. G.774. Modelo de información de gestión de SDH para los elemetos de red. G.774.01 Monitorización de prestaciones SDH para el ele mento de red. G.774.02 Configuración SDH de la estructura de carga para el elemento de red. G.774.03 Gestión SDH de la protección de la sección multiplex para el elemento de red. G.774.04 Gestión SDH de la protección de la conexión de subred desde el elemento de red. G.784. Gestión SDH. G.atmn. Gestión ATM. G.mtn1 Gestión de redes de transmisión. Recomendaciones para control y gestión de B-RDSI (ITU-T)
I.371. Control de tráfico y control de congestión. I.35B. Prestaciones en la red B-ISDN. I.610. Principios OAM. RFCs de IETF RFC
Título
Autor(es)
1089
SNMP over Ethernet. M.L. Schoffstall, C. Davin, M. Fedor, J.D. Case. Feb 1989. none
Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin. Apr 1989. OBSOLETES: RFC1067, OBSOLETED-BY: RFC1157 Structure and Identification of Management Information for TCP/IP-based Internets. M. T. Rose, K. Z. McCloghrie. May 1990. OBSOLETES: RFC1065 Management Information Base for Network Management of TCP/IP-based Internets. K. Z. McCloghrie, M. T. Rose. May 1990. OBSOLETES: RFC1066 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin. May 1990. OBSOLETES: RFC1098 Management Information Base for Network Management of TCP/IP- based Internets: MIBII M. T. Rose. May 1990. OBSOLETED-BY: RFC1213 SNMP over OSI. M.T. Rose. Jun 1990. OBSOLETED-BY: RFC1418 Bulk table retrieval with the SNMP. M.T. Rose, K. McCloghrie, J.R. Davin. Oct 1990. none Management Information Base for Network Management of TCP/IP- based Internets: MIBIIK. Z. McCloghrie, M. T. Rose. Mar 1991. OBSOLETES: RFC1158 Convention for defining traps for use with the SNMP. M.T. Rose. Mar 1991. none SNMP MUX protocol and MIB. M.T. Rose. May 1991. none SNMP communications services. F. Kastenholz. Oct 1991. None SNMP over OSI. M. Rose. Dec 1991. OBSOLETED-BY: RFC1418 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Cook. Dec 1991. none FDDI Management Information Base. J. Case. Jan 1992. none Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. Dec 1991. none DECnet Phase IV MIB Extensions. J. Saperia. Dec 1991. none SNMP over IPX. R. Wormley, S. Bostock. Feb 1992. OBSOLETED-BY: RFC1420 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. Feb 1992. SEE-ALSO: RFC1155, RFC1212, RFC1213, RFC1157 SNMP Administrative Model. J. Davin,J. Galvin,K. McCloghrie. Jul 1992. none SNMP Security Protocols J. Galvin,K. McCloghrie,J. Davin. Jul 1992. none SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. Nov 1992. none SNMP MIB Extension for the X.25 Packet Layer. D. Throop. Nov 1992. none Definitions of Managed Objects for the DS3/E3 Interface Type. Tracy A. Cox, Kaj Tesink. Jan 1993. OBSOLETES: RFC1233 Identification MIB. M. StJohns & M. Rose. Jan 1993. none SNMP over OSI. M. Rose. Feb 1993. OBSOLETES: RFC1161, RFC1283 SNMP over AppleTalk. G. Minshall & M. Ritter. Feb 1993. none SNMP over IPX. S. Bostock. Feb 1993. OBSOLETES: RFC1298 Introduction to version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin & K. McCloghrie. Apr 1993. none Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin & K. McCloghrie. Apr 1993. none
Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K. McCloghrie & J. Galvin. Apr 1993. none Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none Transport Map pings for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none
Publicaciones relacionadas con programación y gestión en Windows. http://www.entmag.com/ Maintech: el periódico independiente para Windows NT. http://www.ntsystems.com Windows NT System Magazine http://www.winntmag.com Windows NT Magazine http://www.backoffice.com BackOffice Magazine Página web de Open System Resources: http://www.osr.com/ Recursos de Internet
Desarrollos en Windows http://www.microsoft.com/support/ ftp://ftp.microsoft.com/ Grupos de News
http://www.tis.com/docs/research/network/ps/snmp/ SNMP bajo desarrollo
http://www.int.snmp.com/v2estatus.html http://www.int.snmp.com/v2star.html http://www.ietf.org/html.charters/snmpv3-charter.html ASN.1 y BER
http://www.itu.int/itudoc/itu-t/rec/x/x200-499/x208_22887.html http://www.itu.int/itudoc/itu-t/rec/x/x200-499/x209_24177.html http://www.inria.fr/rodeo/personnel/hoschka/asn1.html http://www.csc.vill.edu/~cassel/netbook/asn1only/node4.html Estándares de organizaciones
http://www.cis.ohio-state.edu/htbin/rfc/rfc1871.html http://www.cis.ohio-state.edu/htbin/rfc/rfc2200.html ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/std-faq comp.std.misc http://www.ietf.cnri.reston.va.us/ Internet Engineering Task Force (IETF) http://www.iab.org/iab/ Internet Architecture Board (IAB) http://info.isoc.org/index.html Internet Society (SOC) http://www.iana.org/iana/
Internet Assigned Numbers Authority (IANA) http://www.irtf.org/irtf/ Internet Research Task Force (IRTF) http://www.iso.ch/ International Standards Organization (ISO) http://standards.ieee.org/ Institute of Electrical and Electronics Engineers (IEEE) Asignación de números a e mpresas
Assigned Numbers Authority (IANA): http://www.isi.edu/div7/iana/forms.html Lista actual de asignación de numeración: ftp://ftp.isi.edu/in-notes/iana/assignments/ ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers Gestión de red
http://netman.cit.buffalo.edu/ Gestión de red, University of New York, Buffalo http://snmp.cs.utwente.nl/ The SimpleWeb http://www.cforc.com/cwk/net-manage.cgi Base de datos de recursos de gestión de red. http://www.cit.ac.nz/smac/nm210/ Redes y gestión de redes. http://www.ldv.e-technik.tu-muenchen.de/forsch/netmanage/netmanage_e.html Redes y gestión de sistemas, Technical University of Munich, Germany http://www.microsoft.com/products/backoffice/management/ Página deMicrosoft System y gestión de red http://www.mindspring.com/~jlindsay/webbased.html Página de gestión basada en web http://www.microsoft.com/management/ Productos de gestión Microsoft http://wwwsnmp.cs.utwente.nl/~schoenw/ietf-nm/ RFCs de gestión de red. IETF
http://www.elec.uow.edu.au/anmf/index.html Forum de gestión de red australiano http://www.javasoft.com/products/JavaManagement/document.html Documentos de gestión de Java http://www.aetc.af.mil/AETC-NetMgmt/nms-menu.html Evaluación de sistemas de gestión de red. http://www.phoaks.com/phoaks/comp/dcom/net-management/resources3.html Página de gestión de PHOAKS: comp.dcom.net-management WinSNMP
http://www.winsnmp.com/ Tutoriales WinSNMP, freeware, e información. http://www.acec.com/snmp.htm Ace*Comm WinSNMP http://www.mg-soft.si/ MG-WinSNMP SDK, MG-WinMIB SDK, WinSNMP. Ejemplos de código fuente. http://www.ftp.com/pr/wsnmp.htm WinSNMP Software Development Kit ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsnmp/ http://www.fastin.com/cdrom2/winsnmp/ Sunsite.UNC.EDU WinSNMP archivo WinSock
http://www.winsock.com/ Stardust WinSock Labs http://www.sockets.com/ Página de desarrollo de WinSock de Bob Quinn's http://www.goodnet.com/~esnible/winsock.html Windows Sockets Programming http://www.intel.com/IAL/winsock2/index.htm Intel WinSock 2 http://www.data.com/Tutorials/Winsock_2.html Tutorial WinSock 2 http://webcom.com/~llarrow/winsock.html Archivos WinSock, FAQs, y URLs relacionados.
http://www.dart.com/ Power TCP Internet Toolkit http://www.distinct.com/home.htm Distinct TCP/IP http://www.kaon.co.nz/netmanage/cham.html Chameleon y Chameleon NFS http://www.netinst.com/html/wscomp.html WinSock Companion TCP/IP Suite http://www.dolphinsys.com/ WinSock OCXs y VBXs para Internet y desarrollo software TCP/IP http://www.lantimes.com/lantimes/buyers/index/c123.html Guía del comprador TCP/IP http://www.phoaks.com/phoaks/comp/protocols/tcp-ip/resources0.html Página PHOAKS comp.protocols.tcp-ip http://www.microsoft.com/win32dev/netwrk/tcpiphom.htm Redes: Microsoft TCP/IP y Windows 95 http://pclt.cis.yale.edu/pclt/comm/tcpip.htm Introduction to TCP/IP Telecomunications Management Network (TMN)
http://www.delta.dk/se/icm/ni.htm http://www.broadcom.ie/p812/reference/probe http://www.ics.forth.gr. http://www.isrglobal.com/snmpwp.htm. http://www.itu.int/itunews/199602/standard.htm. http://www.webproforum.com/vertel. Gestión en comunicaciones móviles
