Gestión de Red - Antoni Barba Martí - UPC

ndice
Prlogo
Este libro pretende ser una gua introductoria al mundo de la gestin de red. A lo largo de las pginas siguientes se ha tratado de dar ms una visin general de las arquitecturas y entornos de gestin de red que de definir las funcionalidades especficas de un determinado protocolo de gestin de red. El contenido del presente texto constituye el temario bsico para la asignatura de gestin de red que se imparte en la ETSE de Telecomunicaciones de Barcelona (Universitat Politcnica de Catalunya). ltimamente, aspectos como el control, la gestin de red o la gestin de servicios estn teniendo cada vez ms 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 liberacin 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 tcnico, 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 descripcin pormenorizada de cada entorno de gestin; el temario que se ha planteado se divide en tres grandes reas, empezando por la gestin de servicios, introduciendo el sistema de sealizacin n 7, las redes inteligentes y TINA. A continuacin, en la segunda parte, basada en los grandes estndares de gestin, se dedican varios captulos a los protocolos, recomendaciones y estndares ms utilizados. En la tercera parte, se abordan los aspectos ms prcticos o de aplicacin y se describe cmo se realiza la gestin en redes avanzadas como son BRDSI o UMTS. Finalmente, se da un repaso a las plataformas y herramientas de gestin de red ms importantes disponibles en el mercado.
Los autores, 1998; Edicions UPC, 1998.
ndice
ndice
ndice
1 Introduccin 1.1 Monitorizacin, control, gestin .............................................................................................16
2 Gestin de servicios 2.1 Introduccin al sistema de sealizacin 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 2.2.2 Introduccin a las redes inteligentes ............................................................................22 2.2.3 Evolucin de la red inteligente ....................................................................................23 2.2.4 Componentes de la red 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 bsico de la red inteligente...........................................................29 2.3 TINA (Telecommunications Information Networking Architecture). ....................................29 2.3.1 Arquitectura de computacin TINA ............................................................................30 2.3.2 Arquitectura de servicio TINA ....................................................................................31 2.3.3 Arquitectura de red TINA............................................................................................32 2.3.4 Arquitectura de gestin TINA .....................................................................................32 2.3.5 Evolucin de la red inteligente hacia TINA ................................................................34 2.4 Creacin de servicios ..............................................................................................................34 2.4.1 Entorno de creacin de servicios .................................................................................36
3 Soluciones para la gestin de redes 3.1 Evolucin de las redes de telecomunicaciones .......................................................................37 3.2 Modelos para la monitorizacin y el control de red................................................................42
10
Gestin de red
3.2.1 Arquitecturas propietarias............................................................................................42 3.2.2 Plataformas de gestin.................................................................................................44 3.2.3 Clases de productos de gestin ....................................................................................44 3.2.4 Productos de gestin de LANs standalone...................................................................44 3.2.5 Gestin de LANs de PCs .............................................................................................46 3.2.6 Sistemas de gestin de elementos de red de rea local (LAN) ....................................47 3.2.7 Integradores para gestin de LANs..............................................................................48 3.3 Mecanismos para la deteccin de configuraciones de red ......................................................52 3.3.1 RPE (Regulated Poll Emission) ...................................................................................53 3.3.2 Modelado de la duracin de un ciclo de consultas de eestatus ....................................53 3.3.3 Duracin media del tiempo de ciclo de K intentos ......................................................54 3.3.4 Nmero esperado de intentos de polling en un ciclo ...................................................55 3.3.5 Flujos del ciclo de polling............................................................................................56 3.3.6 Anlisis del retardo ......................................................................................................57
4 Entornos de gestin de telecomunicacin orientados a objetos 4.1 Introduccin a la orientacin a objetos ...................................................................................59 4.2 Objetos gestionados y el entorno gestor/agente ......................................................................59
5 Gestin segn OSI 5.1 Modelo funcional ....................................................................................................................63 5.2 Modelo de organizacin..........................................................................................................64 5.3 Modelo de comunicaciones: CMIP.........................................................................................64 5.3.1 Caractersticas 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 informacin...........................................................................................................72 5.4.1 MIB (Management Information Base) .................................................................................76 5.4.2 GDMO (Guidelines for Definition of Managed Objects) ....................................................77
6 Red de gestin de las telecomunicaciones (TMN) 6.1 6.2 6.3 6.4 6.5 Arquitectura fsica...................................................................................................................83 Modelo organizativo ...............................................................................................................84 Modelo funcional ....................................................................................................................85 Modelo de informacin...........................................................................................................86 Implementacin fsica de las funciones de la TMN................................................................87
ndice
11
7 reas funcionales de gestin 7.1 Gestin de fallos .....................................................................................................................91 7.1.1 Identificacin de fallos en redes de comunicaciones ...................................................92 7.2 Gestin de configuracin ........................................................................................................94 7.3 Gestin de prestaciones...........................................................................................................94 7.4 Gestin de tarificacin ............................................................................................................95 7.5 Gestin de seguridad...............................................................................................................95
8 Funciones de gestin de la red de sealizacin 8.1 Controles de flujo MTP en la red de sealizacin...................................................................97 8.1.1 Gestin del enlace de sealizacin ..............................................................................98 8.1.2 Gestin del trfico de sealizacin ..............................................................................98 8.2 Control de flujo de trfico de sealizacin..............................................................................99 8.2.1 Gestin de rutas de sealizacin..................................................................................99 8.3 Control nodal MTP ...............................................................................................................101 8.3.1 Controles SCCP .........................................................................................................103 8.3.2 Controles de congestin automticos.........................................................................103 8.4 Gestin de fallos ...................................................................................................................103 8.5 Arquitectura de gestin de red de sealizacin .....................................................................104 9 Gestin de redes virtuales 9.1 Introduccin ..........................................................................................................................105 9.2 Estndares de VLAN ............................................................................................................105 9.3 Gestin de red en VLAN ......................................................................................................105 9.3.1 Seguridad en VLAN ..................................................................................................106
10 Gestin de la red B-RDSI 10.1 Introduccin a la gestin de la red B-RDSI ..........................................................................110 10.2 Interfaces en la red de gestin 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 anlisis comparativo entre estndares de gestin ATM ..................................114 10.6 Control de trfico en redes ATM ..........................................................................................115 10.6.1 Calidad de servicio ....................................................................................................115 10.6.2 Parmetros de trfico .................................................................................................116 10.6.3 Descriptores de trfico...............................................................................................117 10.6.4 Mecanismos de control de trfico ..............................................................................117 10.7 Funciones de control de congestin ......................................................................................118 10.7.1 Control de flujo..........................................................................................................119
12
Gestin de red
10.8 Recuperacin en redes ATM.................................................................................................120 10.8.1 Mecanismos de recuperacin ATM alternativos .......................................................120 10.8.2 Redes de proteccin ATM .........................................................................................121 10.8.3 Redes reconfigurables................................................................................................121 10.8.4 Redes ATM autorecuperables....................................................................................122 10.8.5 Autorecuperacin con backup de VPs semidedicados...............................................122 10.8.6 Restauracin multicapa..............................................................................................123
11 Gestin en redes de comunicaciones mviles 11.1 Introduccin a las comunicaciones personales......................................................................125 11.1.1 Comparacin entre la gestin en sistemas cableados y sistemas de comunicacin mviles ..........................................................................................127 11.1.2 Arquitectura de la red GSM.......................................................................................128 11.2 Arquitectura de las redes PCS...............................................................................................130 11.2.1 Caractersticas de los sistemas basados en PCS.........................................................130 11.2.2 Servicios PCS ............................................................................................................135 11.2.3 Gestin de movilidad.................................................................................................136 11.2.4 Gestin de recursos....................................................................................................136 11.2.5 Mtodos de acceso en PCS ........................................................................................137 11.2.6 Protocolo de sealizacin ..........................................................................................137 11.2.7 Red inteligente para servicios personales en redes de comunicaciones mviles avanzadas .....................................................................................................138 11.3 Funciones de gestin. Objetos gestionados...........................................................................139 11.4 Red inteligente y sistemas de comunicacin mviles ...........................................................140 11.4.1 Caractersticas 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 Evolucin de PCS hacia sistemas de tercera generacin.......................................................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 Distribucin de informacin en las bases de datos ....................................................152 11.5.4 Conclusiones..............................................................................................................153
12 Gestin en Internet Introduccin ..........................................................................................................................155 Evolucin ..............................................................................................................................156 Estructura de la informacin de gestin................................................................................156 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 informacin de gestin (MIB)................................................................................160 12.5.1 MIB-I.........................................................................................................................164 12.1 12.2 12.3 12.4
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 Codificacin para la transferencia de la informacin de gestin: BER .....................173 12.7 Configuracin y rendimiento de una red gestionada por el protocolo SNMP.......................173 12.7.1 Interrogacin (polling) de estatus de dispositivos......................................................174 12.7.2 Interrogacin (polling) de descubrimiento (Discovery).............................................174 12.7.3 Interrogacin (polling) de configuracin de topologa ..............................................174 12.7.4 Interrogacin (polling) de chequeo de configuracin de dispositivo .........................174 12.7.5 Interrogacin (polling) de estatus de estacin 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 heterogneos.......................175 12.9.1 Sistemas de gestin de red basados en SNMP emergentes........................................175 12.9.2 Sistemas de gestin de LANs heterogneas...............................................................176 12.9.3 Valoracin crtica de las MIB en SNMP ...................................................................177 12.10 Conclusiones sobre SNMP ..................................................................................................177 12.11 Comparacin 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 Gestin 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. Gestin segn 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 Gestin basada en agentes inteligentes mviles....................................................................193 13.5.1 Introduccin a los agentes inteligentes ......................................................................193 13.5.2 Clases de agentes inteligentes....................................................................................194 13.5.3 Agentes mviles ........................................................................................................195 13.5.4 Arquitecturas de comunicaciones basadas en agentes ...............................................195 13.5.5 Gestin basada en agentes .........................................................................................197 13.5.6 Procesos elsticos ......................................................................................................200
14
Gestin de red
14 Gestin basada en Webs 14.1 Java Management API (JMAPI) ...........................................................................................203 14.2 Web-based Enterprise Management (WBEM) .....................................................................204
15 Desktop Management Interface (DMI) 15.1 Common Information Model (CIM) .....................................................................................208
16 Plataformas de gestin de red 16.1 16.2 16.3 16.4 16.5 16.6 Plataformas de gestin ..........................................................................................................209 Plataforma de gestin de red OpenView ...............................................................................210 SunNet Manager (SUN)........................................................................................................210 IBM System View para AIX ..................................................................................................211 SPECTRUM de Cabletron ....................................................................................................212 TME10 (Tivoli Management Environment) .........................................................................212
Conclusiones ......................................................................................................................................213 Bibliografa ......................................................................................................................................215 Anexos ......................................................................................................................................221
Anexo I: recomendaciones y normas ..................................................................................................221 Anexo II: direcciones en Internet ........................................................................................................225
1. Introduccin
15
1 Introduccin
La gestin de red trata sobre la planificacin, la organizacin, la supervisin 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 gestin 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 ms una parte importante y estrtegica de las empresas, industrias u otros tipos de instituciones y como resultado de las cada vez mayores dimensiones que estn adoptando, resulta pues ms importante su control y gestin con el fin de obtener la mejor calidad de servicio posible. Tradicionalmente, en la gestin de las redes se ha partido de soluciones propietarias y cerradas con un mbito de actuacin limitado a la propia empresa o dominio de la institucin. Con el tiempo, la evolucin tecnolgica ha permitido la entrada de mltiples fabricantes de equipos, de la misma forma que otros fabricantes de reputado nombre han desaparecido y, en consecuencia, tambin el apoyo que prestaban a sus soluciones de red. Por tanto, bien sea porque ha ocurrido la absorcin de empresas o bien por diversificacin de las fuentes de los equipos, las redes actuales son cada vez ms heterogneas en equipos. Uno de los problemas ms 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 gestin que utilicen estndares abiertos con el fin de compatibilizar protocolos e informacin. De esta forma, durante la dcada de los noventa, se han ido desarrollando diversas iniciativas con el objetivo de ofrecer recomendaciones y estndares abiertos para tratar de dar solucin a estas nuevas problemticas, como por ejemplo mediante el protocolo de gestin SNMP o el CMIP. Para proporcionar una calidad de servicio adecuada mediante la gestin de redes, se parte de unos recursos humanos que mediante una serie de herramientas aplican unas determinadas metodologas a la red. Este texto versa sobre herramientas y mtodos que se pueden emplear en la gestin de red. Las recomendaciones sobre esta temtica provienen de diversos grupos de estandarizacin. La ms importante, la ITUT, ha definido la red de gestin de las telecomunicaciones (TMN). Estas recomendaciones definen cinco reas funcionales para la gestin de red, las de supervisin y fallos, configuracin, tarificacin, prestaciones y seguridad. La organizacin de la gestin puede estructurarse tambin segn un criterio temporal. De esta forma, se puede hablar de un control operacional que opera a muy corto plazo y a bajo nivel, una administracin que opera a corto plazo y a bajo-medio nivel, un anlisis de la gestin que opera a medio plazo y a medio-alto nivel y finalmente una planificacin a largo plazo y a ms alto nivel.
16
Gestin de red
En el control operacional, las operaciones realizadas a este nivel deben quedar registradas, para su posterior anlisis por el administrador de red. Es el caso de operaciones tales como la recogida de datos sobre prestaciones y utilizacin de la red, la evaluacin de alarmas, la diagnosis de problemas, el arranque y la parada de los componentes de la red, la ejecucin programada de pruebas preventivas, la modificacin de configuraciones o la carga de nuevas versiones de software. Las funciones principales de la administracin consisten en seguir las tareas de control operacional y en elaborar informes peridicos para su posterior anlisis. Por ello se ocupa de tareas como la evaluacin de la calidad de servicio, la evaluacin de trfico, el mantenimiento de registro histrico de problemas, el mantenimiento de inventario, el mantenimiento de configuraciones, la contabilidad de red y de control de acceso. El objetivo del anlisis es garantizar la calidad de servicio y, finalmente, la planificacin se encarga de las decisiones dependientes del negocio al que se dedica la empresa.
1.1 Monitorizacin, control, gestin

Llegados a este punto, sera conveniente distinguir entre monitorizacin, control y gestin de una red. Se utiliza el trmino monitorizacin para designar el tipo de acciones consistentes en obtener informacin de la red con el fin de detectar anomalas. Estas acciones son pasivas y su nico objetivo es conocer el comportamiento respecto al trfico del sistema. Una vez se conoce el sistema se puede proceder al control: para ello se establece una sealizacin o plano de control en toda red que se ocupa de regular activamente las comunicaciones y, en general, el trfico de la red. Un ejemplo de red de control es el sistema de sealizacin n 7. Finalmente, la gestin se define a partir del plano de gestin que integran las redes ms avanzadas como RDSI, GSM, etc. Como ejemplo de red de gestin se puede citar la TMN (Telecommunications Management Network) definida por la ITU-T. Segn las reas funcionales de gestin definidas por la ITU-T, la monitorizacin de red se utiliza para proporcionar informacin en la gestin de las funciones de prestaciones, fallos, contabilidad y en determinados aspectos de configuracin, mientras que el control de red se aplica a las funciones de configuracin y seguridad. En el proceso de monitorizacin de la red se consideran una serie de aspectos como son: en primer lugar, una definicin de la informacin de gestin que se monitoriza, una forma de acceso a la informacin de monitorizacin, un diseo de los mecanismos de monitorizacin y, finalmente, un procesado de la informacin de monitorizacin obtenida. Por otra parte, la informacin de monitorizacin puede clasificarse segn su naturaleza temporal en: informacin esttica que se almacena en los elementos monitorizados (p.e. inventario); informacin dinmica que se almacena en los propios elementos o en equipos especializados (p.e. cambios de estado o fallos) e informacin estadstica que se genera a partir de la informacin dinmica y que puede residir en cualquier lugar que tenga acceso a la informacin dinmica (p.e. rendimientos). Los mecanismos de monitorizacin se basan fundamentalmente en un sondeo o polling por parte de la estacin gestora, esto es, en un acceso peridico a la informacin de gestin almacenada en los nodos gestionados. Este mtodo tiene la ventaja de que los objetos que se gestionan nicamente deben estar preparados para responder, con lo que es ms 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 envan mensajes bajo ciertas condiciones; de esta forma tienen como ventaja el hecho que se minimiza el trfico de gestin por la red. Otros mtodos son mixtos, se basan en proxies, sondas, etc, y combinan los dos mecanismos anteriores.
2. Gestin de servicios
17
2 Gestin de servicios
Una parte cada vez mayor de los ingresos que obtienen los operadores de red parte de los servicios de valor aadido que aportan los proveedores de servicios. Para soportar estos servicios se hace necesario una infraestructura basada en las redes inteligentes y cada vez ms en lo que se ha denominado ltimamente inteligencia de red basada en estndares, como por ejemplo TINA.
2.1 Introduccin al sistema de sealizacin n 7 (SS7)

La red de sealizacin n 7 (tambin denominada Channel Common Signalling, CCS) es la red que se ocupa de la sealizacin y constituye el soporte bsico de las redes inteligentes. Esta red se define de forma separada de la red de transporte de informacin. En su forma bsica consta de nodos llamados puntos de sealizacin (SPs) interconectados por enlaces de transmisin. La red se constituye con los siguientes tipos de nodos: Service Switching Point (SSP). Punto de conmutacin de servicio Signal Transfer Point (STP). Punto de transferencia de seal Service Control Point (SCP). Punto de control de servicio Intelligent Peripheral (IP). Perifrico inteligente y de diversas configuraciones de interconexiones entre los nodos, formadas por Signaling Links (SLs) o enlaces de sealizacin [BLA2, RUS1].
SCE SCP: Punto de control de servicios SSP: Punto de conmutacin de Servicios STP: Punto de transferencia de sealizacin SMS: Sistema de gestin de servicios IP: Perifrico inteligente SDP: Punto de datos de servicios Terminal del usuario A SMS SCP SDP Red de sealizacin SS7 IP STP AD/SN Local Local RTC SSP Terminal del usuario B
Fig. 2.1 Esquema de bloques de la red SS7 en un entorno de red inteligente
18
Gestin de red
La red SS7 constituye la base de la red inteligente y de lo que se ha venido a llamar ms recientemente inteligencia de red. En los prximos captulos se describirn ms pormenorizadamente sus funciones y componentes. 2.1.1 Arquitectura de la red SS7/CCS La arquitectura de la red SS7/CCS (sealizacin por canal comn) est formada por nodos y diversos tipos de enlaces que estn configurados de forma que aporten la mxima fiabilidad al sistema. A continuacin se describen las caractersticas principales de estos tipos de nodos. Punto de conmutacin de servicio (SSP) Los puntos de conmutacin de servicio (SSP) son centros de conmutacin equipados para manipular sealizacin troncal as como sealizacin de servicios o servicios de transacciones con las bases de datos dentro y fuera de la red. Tambin transfieren mensajes SS7 a otros puntos de sealizacin dentro de la red. Los puntos de sealizacin se despliegan en pares, por cuestiones de redundancia y diversidad; de esta forma en caso de fallo siempre puede desviarse el trfico por rutas alternativas. El objetivo consiste en mantener el mximo del tiempo posible la red operativa. Punto de transferencia de seal (STP) Los STP o conmutadores de alta fiabilidad que enrutan mensajes SS7 entre los nodos de la red y se basan en la informacin del propio mensaje o bien en informacin 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 sealizacin en una red SS7. Pueden realizar funciones de gateway para transferir mensajes de sealizacin a otras redes de sealizacin SS7 (uso de MTP). Tambin el encaminamiento especializado es funcin del SCCP (acceso a bases de datos). Cada nmero concreto accede a un servicio diferente. Existe una tabla en cada STP que indica para cada nmero el SCP y el enlace que se debe utilizar para enviar el mensaje. El nmero 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 trfico, dentro todava 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 tndems de acceso y SCP's a STPs se denominan enlaces de acceso o enlaces A. Cada nodo se conecta como mnimo con un par de nodos jerrquicos (superiores e inferiores) para mayor fiabilidad. Cada SCP suele tener un mnimo de tres enlaces y un mximo de cinco enlaces a cada par de STPs a los que est conectado. Se trata de una limitacin por hardware (existente en centrales de AT&T), segn el nmero de tarjetas front-end (a 2 enlaces por tarjeta) que puede soportar el SCP.
19
SCP
SCP
Enlaces A STP Enlaces A STP
SP
SP
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 jerrquico (p.e. regiones distintas). En este caso se aconseja una diversidad de tres caminos para cada conjunto de enlaces, con un mximo de ocho enlaces.
STP Enlaces B Enlaces SS7 Enlaces B STP
STP
STP
Fig. 2.3 Esquema de red SS7 con los enlaces tipo B
Los enlaces que conectan pares de STP juntos se denominan enlaces C o cross links, con al menos dos enlaces para cada conjunto de enlaces. La principal funcin de los enlaces C es llevar mensajes de gestin de red. Se implantan al menos dos STP por regin.
20
Gestin de red
STP
STP
Enlaces SS7
Enlaces C Enlaces C STP STP
Fig. 2.4 Esquema de red SS7 con los enlaces tipo C
Los enlaces en diagonal o enlaces D conectan STPs de diferentes niveles jerrquicos (p.e. STP local y STP regional). Generalmente se disponen con al menos tres rutas alternativas. Cada conjunto de enlaces tiene un mximo de ocho enlaces. Los enlaces que conectan SPs a STPs diferentes del par asociado originariamente se denominan extended links o enlaces E. Un mnimo de uno y un mximo de 16 enlaces E se utilizan desde cada SP/SSP para conectar a sus compaeros 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 mximo se utilizan16 enlaces y no hay conexin a nodos inteligentes de la red. Los nombres de estos enlaces slo determinan las funciones que realizan puesto que fsicamente son idnticos. En una configuracin en un nico nivel, un par de STPs proporciona todos los encaminamientos de mensajes de sealizacin dentro de su rea de servicio. Esto incluye mensajes database query type y call setup type. En la configuracin 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 lgica de servicio para responder a peticiones procedentes de SSPs. Por ejemplo, convertir nmeros 800 (900) en encaminamientos para nmeros de la red bsica, validar nmeros, 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 segn los nodos a los que conecta. Son enlaces sncronos bidireccionales a 64Kbps (56 Kbps en U.S.). El protocolo SS7 es el modelo en capas que cubre la comunicacin entre nodos inteligentes en la red CCS.
21
OMAP
TCAP
ISDN-UP
Database Query Mode
SCCP
Trunk Signaling Mode
Red MTP Enlace Fsico

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, seleccin del enlace de sealizacin, deteccin y correccin de errores, conexin fsica a los enlaces. Tambin proporciona gestin de red para el control de flujo en caso de congestin de la red. A nivel de red el protocolo proporciona encaminamiento dentro de la sealizacin de red, control de fallos y congestin de la red y distribucin de la carga. Sus tareas se dividen en tres funciones: Sealizacin de gestin de trfico. Sealizacin de gestin de enlaces. Sealizacin de gestin de rutas. Signaling Connection Control Part (SCCP) SCCP ( Signaling Connection Control Part): contiene funciones de transporte de alto nivel necesarias para soportar partes de aplicacin de alto nivel. Proporciona funciones de encaminamiento, servicios orientados a conexin y no orientados a conexin. Tambin se ocupa de la gestin 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 sealizacin entre centrales.
22
Gestin de red
Transaction Capabilities Application Part (TCAP) TCAP (Transaction Capabilities Application Part): soporta la transferencia de informacin que no est asociada con el circuito de control, por ejemplo la peticin/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, monitorizacin, encaminamiento y verificaciones.
2.2 Redes inteligentes

En este apartado se describen las ideas fundamentales de lo que constituye la integracin de los servicios de valor aadido 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 aplicacin de las funcionalidades del sistema de sealizacin n 7. Esta infraestructura de sealizacin comn es la que permitir ms adelante el rpido desarrollo, desde un punto de vista tcnico, 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 tambin en el contexto de la red de gestin de las telecomunicaciones (Telecommunications Management Network, TMN) y al mismo tiempo con los avances que se estn produciendo hacia la especificacin de lo que es TINA. Los objetivos de este apartado consisten en especificar e introducir los conceptos bsicos de las redes inteligentes mostrando la evolucin que han seguido los servicios a partir de la integracin de ordenadores en los elementos de red del sistema. Se trata tambin de establecer una relacin entre los conceptos de sealizacin, gestin de red y red inteligente.
2.2.2 Introduccin a las redes inteligentes La red inteligente es inteligente porque es programable, es decir, la introduccin de ordenadores y, por tanto, de software en los nodos de la red permite configurar mediante programacin el comportamiento, los servicios y, por tanto, la inteligencia del sistema. El motivo bsico del desarrollo de esta red es el de obtener mayores beneficios para el operador dado que aumenta el trfico telefnico y tambin 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.
23
Por otra parte, la red inteligente est diseada para permitir una creacin y/o modificacin de los servicios de forma sencilla y rpida con el fin de adaptarse fcilmente 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 evolucin tecnolgica de los sistemas de comunicaciones. Los tipos de servicios diseados para la red de comunicaciones pueden ser servicios de red que comportan un flujo de sealizacin para mejorar la transferencia de la informacin, o bien servicios de valor aadido que comportan un flujo de datos para mejorar el proceso de informacin. Son nicamente estos ltimos, los servicios de valor aadido, los que se consideran especficos de las redes inteligentes. La ITU-T ha especificado una serie de servicios inteligentes conocidos como CS1 (Capability Services 1), ms recientemente ha aparecido un nuevo conjunto denominado CS2 y se est trabajando en la especificacin de un CS3. Dentro de los tipos de servicios CS1, en los que se basan la gran mayora de infraestructuras de operadores de servicio actuales, pueden citarse los siguientes: servicios de tarificacin en llamadas (nmeros 900,...), servicios de encaminamiento, numeracin, captura/entrega de informacin u otros servicios de valor aadido. Finalmente, entre los servicios especificados en CS2 destacan los servicios de interconexin con otras redes, multiconferencia, movilidad personal, movilidad de terminal y servicios multimedia, as como la creacin y gestin de estos servicios (CS2/CS3).
2.2.3 Evolucin 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 incorporacin en las primeras centrales de un control basado en una unidad de proceso (ordenador). Posteriormente se introdujeron en las centrales mecanismos de conmutacin digital y los sistemas de transmisin digital. Llegados a este punto, todo estaba preparado para la implementacin de una red de sealizacin por canal comn. Esta red de sealizacin, basada en el protocolo n 7, permiti que las centrales de comunicaciones pudieran transferir la informacin de control de forma ms adecuada y, por tanto, se entendieran mejor entre ellas para poder pasar a introducir una inteligencia en la red. La introduccin de los servicios segn 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 sealizacin (SPs) interconectados por enlaces de sealizacin. La arquitectura AIN incluye nuevos sistemas de red fsicos y sistemas operativos, as como nuevo software para los sistemas de red y sistemas de operacin existentes. La AIN integrada en la red bsica permite operar a ordenadores inteligentes, llamados nodos, localizados en la red CCS. La red inteligente incluye en su forma bsica los siguientes nodos: Service Switching Point (SSP). Punto de conmutacin de servicio Signal Transfer Point (STP). Punto de transferencia de seal
24
Gestin de red
Service Control Point (SCP). Punto de control de servicio Service Management System (SMS). Sistema de gestin de servicios Signaling Links (SLs). Enlaces de sealizacin Adems, la red inteligente suele dotarse tambin de los siguientes elementos: Intelligent peripheral (IP). Perifrico inteligente Service Data Point (SDP). Punto de datos del servicio Service Creation Environment (SCE). Entorno de creacin 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 continuacin, se describen con mayor detalle los nodos que constituyen la red. SMS: realiza funciones de mantenimiento, administrativas y de provisin para los SCPs. Tambin realiza la funcin de creacin de servicios. SCP: simbolizados por triangulos, para mostrar sus capacidades para realizar decisiones. Los AIN SCPs contienen programas lgicos de servicios que reflejan los servicios de clientes y que interactan 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): aaden funciones de comprensin a la red tales como reconocimiento de voz, sntesis y anuncios de voz especficos. Adjuntos: nodos AIN que se conectan a los SSPs y que realizan las mismas funciones 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 travs 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 funcin de procesado de la llamada. Enva un mensaje de consulta a travs 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 abstraccin que facilita la definicin de interfaces abiertos y normalizados para posibilitar la creacin de servicios avanzados y abiertos en un entorno multifabricante.
25
El modelo conceptual define las estructuras lgicas y funcionales, as como las caractersticas de los servicios bsicos. Se puede estructurar en los cuatro planos siguientes: plano de servicio (perspectiva del usuario), plano funcional global (perspectiva del diseador del servicio), plano funcional distribuido (relacionado con la arquitectura de la red) y plano fsico (relacionado con la arquitectura de la red). El plano de servicio presenta una descripcin del servicio desde el punto de vista del usuario. Se trata de una visin orientada al servicio en la que no hay informacin sobre la realizacin de los servicios en la red. En el plano funcional global se da una visin 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 distribucin de las funciones de una red inteligente mediante entes funcionales (FEs) y acciones de entes funcionales (FEAs). Finalmente, en el plano fsico se indica la forma de implementar la red inteligente. Se identifican los distintos tipos de entes fsicos (PEs), las FEs que realizan y los protocolos que emplean para comunicarse. A continuacin se presentan las entidades funcionales definidas en la primera fase de especificacin de servicios (CS1): CCF: funcin de control de llamadas (tareas clsicas: sealizacin, reserva de circuitos,...). CCAF: funcin de agente de control de llamadas (intermediario entre usuarios y procesos de llamadas analgicas, RDSI,...). SSF: funcin de conmutacin del servicio (intercepta llamadas de IN). SCF: funcin de control de servicio (lgica de control de los servicios de IN). SRF: funciones de recursos especializados (interacciones con usuario: DTMF/voz, anuncios,...). SDF: funcin de datos del servicio (acceso a datos de servicio y red). SMF: funcin de gestin del servicio. SCEF: funcin de entorno de creacin de servicios. SMAF: funcin agente de gestin de servicios.
SMAF SMF SCEF
SDF
SCF
SSF
CCF
Fig. 2.6 Estructura de entidades funcionales correspondiente a la red inteligente
26
Gestin de red
Se puede establecer una correspondencia entre entidades funcionales y entidades a nivel fsico (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 diseo para dimensionar un nodo SCP. El nodo se descompone en una serie de entidades funcionales [ATS1]. A continuacin se describe la notacin bsica 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
SMS
CHF
SCP
SSP
Fig. 2.7 Esquema de funcionalidades del nodo SCP
Sea la DMF la funcin de procesado de la llamada, la CHF la funcin que realiza de interfaz de comunicaciones con el mdulo SSP y la SHF el programa del servicio lgico que ejecuta el SLP. Sean: M SH : nmero de SHs. M CH : nmero de CHs M DM : nmero de DMs 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).
27
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/llamada). C: cantidad de procesado en CH para una nica llamada (bits/llamada). Q: cantidad de procesado en DM para una nica llamada (pasos/llamada). V: condicin de trfico: nmero mximo de llamadas procesadas simultneamente. 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 = K SH 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 CV + 1 + K CH ct CH QV + 1 + K DM qt DM (*) + 1
Para simplificar, se adoptan los parmetros M como enteros, de la forma:
PV K * = K SH pt SH si PV K * = K SH pt SH
CV + K CH ct CH
QV + K DM qt DM
t SH + t CH + t DM = T CV + K CH ct CH QV + K DM q (T t t ) CH SH
Para obtener una solucin de coste mnimo se igualan las derivadas parciales de cada variable a cero:
K * K * = =0 t SH t CH Se obtiene:
28
Gestin de red
T t SH = K SH P + p
K SH P p K CH C + c K CH C c K CH C + c K DM Q q K CH C + c K DM Q q K DM Q q K DM Q q
T tCH = K SH P + p
T t DM = K SH P + p obtenemos
M SH , M CH y M DM y sustituimos en (*), con

K* K
Ejemplo Sean las siguientes relaciones: P C Q : : = 1 :1 :1 p c q
Fracciones de tiempo procesando en cada mdulo: (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 = 1 : 2 : 4 K * donde
(t SH
+ t CH + t DM ) = 0.3
Una llamada se procesa por un nico mdulo para cada tipo de funcin. La proporcin de tiempo invertido para procesar en cada mdulo viene dada por: P C Q : : p c q Por otra parte, se desprecia el retardo en las conexiones entre mdulos.
29
2.2.7 Modelo de llamada bsico 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 lgicos de servicio residentes en el SCP. Estos programas lgicos de servicio interactan con informacin enviada desde el SSP para proporcionar direcciones de control de llamada. Cmo el SSP determina qu tipo de informacin del cliente se enva al SCP? Se dirige funcionalmente por el modelo de llamada bsico de la red inteligente. Este modelo de llamada bsico define puntos en llamada (PIC) como posiciones que proporcionan cinco reas de disparo lgico, denominadas puntos de deteccin de disparo (TDPs), donde la informacin almacenada se transfiere al SCP.
Un trigger es la traslacin de un software que puede emplazarse en contra de las lneas de un cliente o un cdigo de dial seleccionado dentro del plan de dialing de oficina. Cada punto de deteccin de disparo puede proporcionar multiples disparos. La informacin recogida en un punto de deteccin de disparo es lo que define un tipo de servicio AIN. Un ejemplo de tipo de servicio es el nmero de llamante recogido en el punto de deteccin de disparo del intento originante y que podra 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 deteccin de disparo, y por eso no pueden disparar la transmisin de informacin 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 lgicos de servicio del SCP. Los programas lgicos de servicio proporcionan la lgica que determina los servicios disponibles al cliente. El mensaje desde el SSP contiene informacin que permite al SCP el registro del grupo cliente que contiene el programa lgico 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 estndar OMG CORBA, y una arquitectura de aplicacin de telecomunicaciones. Proporciona una arquitectura de red de informacin 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 gestin como aplicaciones basadas en software que operan en una plataforma de computacin distribuida CORBA. Para ello, se intenta obtener un entorno de desarrollo de aplicaciones de red, gestin y operaciones que sean de fcil utilizacin 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/.
30
Gestin de red
TINA surgi como solucin a los nuevos servicios de telecomunicaciones que requieren un acceso y una gestin ms flexibles de lo que las redes actuales pueden proporcionar. La arquitectura se basa en computacin distribuida, orientada a objetos, y en otros conceptos y estndares de las industrias de telecomunicaciones y ordenadores, como ODP, IN, TMN, ATM, CORBA. La arquitectura TINA se estructura en cuatro grandes reas: arquitectura de computacin, arquitectura de servicio, arquitectura de red y arquitectura de gestin. - Arquitectura de computacin: esta arquitectura define un conjunto de conceptos y principios para el diseo y construccin 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 diseo, especificacin, implementacin y gestin de servicios de telecomunicaciones. Pueden identificarse tres conceptos fundamentales: conceptos de sesin, 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 gestin, relacionados con temas de gestin de servicios. - Arquitectura de red: define un conjunto de principios y principios para el diseo, especificacin, implementacin y gestin de redes de transporte. Aspectos bsicos de esta arquitectura es el modelo de informacin de recursos de red genricos, la definicin de los grafos de conexiones que proporcionan una visin de conectividad orientada al servicio, y la gestin de conexiones. - Arquitectura de gestin: define un conjunto de conceptos y principios para el diseo, especificacin e implementacin de sistemas de software que se usan para gestionar servicios, recursos, software, as como otras tecnologas subyacentes.
2.3.1 Arquitectura de computacin TINA La arquitectura de computacin define los conceptos de modelado que deberan de usarse para especificar el software orientado a objetos en sistemas TINA. Adems 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 programacin y encapsulacin. Los objetos interactan entre ellos mediante el envo y la recepcin de informacin 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 operacin puede tener argumentos de entrada y devolver resultados. - Una interfaz de flujo no tiene operaciones, es decir, no hay parmetros 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 vdeo o voz. Estos flujos se establecen mediante la interaccin con componentes de red y servicio.
31
Las interfaces se especifican independientemente de cualquier lenguaje de programacin mediante una notacin especfica. Esta notacin se denomina TINA Object Definition Language (TINA ODL), y es una extensin del Object Management Groups Interface Definition Language (OMG IDL). El lenguaje consiste en un conjunto de plantillas que permiten la especificacin de las entidades de computacin TINA bsicas: bloques de construccin, objetos e interfaces. Los conceptos de modelado de la informacin permiten ver el estado, las relaciones y el comportamiento de las entidades de informacin en el dominio del problema bajo estudio (notacin casi GDMO-GDR). Los conceptos de modelado de ingeniera definen la mquina 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 gestin o de usuario final). Desde el punto de vista de computacin describe cmo debera estar estructurado un servicio distribuido para proporcionar sus funciones al usuario. Para ello, identifica componentes software en tiempo de ejecucin (run-time) tales como: agentes de usuario, agentes terminal, sesin de servicio, gestor de suscripciones o gestor de sesin de comunicaciones. La capa de servicio TINA pasa sus requerimientos de gestin en forma de Management Contexts (MgmtCtxt), que se transportan por una construccin denominada transaccin 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 sesin por lo que se obtiene un nuevo conjuntos de funciones de gestin representadas por MgmtCtxts en cada sesin de servicio. Las fases de transaccin de un servicio son tres: Fase de set-up: se interpretan los MgmtCtxts y se reservan los recursos necesarios. Fase de ejecucin: una vez se ha autorizado el acceso, se ejecuta la sesin de servicio TINA. Fase de wrap-up: se informa de la gestin (QoS) si es necesario.
Sesin de
usuario
Sesin de servicio
Sesin de usuario
Sesin de acceso
Sesin de comunicacin
Sesin de acceso
Fig. 2.8 Concepto de sesin en TINA
32
Gestin de red
Con TINA se reemplaza el concepto de llamada por el de sesin, entendiendo este ltimo como el propsito de un servicio de realizar un conjunto de actividades durante un periodo especfico de tiempo. Se definen cuatro tipos especficos de sesiones desde el punto de vista de la informacin que tratan: sesin de servicio, sesin de comunicacin, sesin de usuario y sesin de comunicacin. En la figura 2.8 se relacionan grficamente estos tipos de sesin. 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 propsito de estos conceptos de sesin es separar los diferentes mbitos y promocionar la distribucin de funcionalidad.
2.3.3 Arquitectura de red TINA La arquitectura de red intenta proporcionar un conjunto de conceptos genricos que describen redes de transporte de una forma independiente a la tecnologa (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 gestin de un conjunto de recursos de la red (subredes, elementos de red, pistas, conexiones, etc). Se pueden considerar los siguientes niveles de gestin: Nivel de elementos de red: aspectos referidos a la informacin requerida para gestionar recursos de equipos especficos proporcionada por las funciones de la capa de elementos de red. Nivel de gestin de recursos: informacin para la representacin de la red, tanto lgica como fsicamente. Nivel de gestin de servicios: gestin de software de los servicios, configuracin de los servicios, y utilizacin de recursos para proporcionar el servicio. El concepto de grafo de conexin se utiliza para proporcionar una visin de conectividad orientada al servicio. Un grafo de conexiones presenta vrtices y puertos, con puertos conectados por lneas para representar conectividad. Hay dos tipos de grafos de conexiones: grafos de conexin lgica donde los vrtices representan objetos, los puertos representan interfaces de flujos y las lneas flujos. En cambio, en el grafo de conexiones fsicas, los vrtices representan nodos fsicos, los puertos, puntos de acceso a red y las lneas, conexiones.
2.3.4 Arquitectura de gestin TINA La arquitectura de gestin define un conjunto de principios de gestin de entidades en un sistema TINA. Est basada principalmente en la gestin OSI y en estndares TMN. Las reas funcionales de gestin son las ya clsicas cinco definidas por la TMN en la ITU: fallos, rendimiento, seguridad, configuracin y tarificacin. En TINA adems, se subdivide la gestin de configuracin en gestin de conexiones y en gestin de (configuracin de) recursos. A menudo se utiliza otro tipo de clasificacin y tambin se pueden definir los siguientes planos: Gestin de computacin: relacionada con la gestin 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 gestin especfica. Su principal inters es el empleo, la instalacin, y la carga de software. Gestin de las telecomunicaciones: se refiere a los servicios de telecomunicaciones, el software de control y la gestin de redes de transmisin y conmutacin.
33
Estos dos tipos de gestin se dividen en subtipos de gestin. La gestin de telecomunicaciones se divide, al igual que en TMN, en gestin de servicio, red y elemento. Por su parte, la gestin computacional se puede dividir en distintas reas de inters. Notacin de interfaz operacional
COa Cliente Interfaz CO
Servidor
Notacin de interfaz de flujo

COc Fuente Productor Sumidero Consumidor COd
Fig. 2.9 Tipos de interfaz de objeto computacional
Los principales objetos computacionales de la arquitectura de servicio relacionada con una sesin 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 mnimo conjunto de capacidades como un extremo final de una sesin de acceso por medio de la interaccin con el agente de usuario para realizar el control de la sesin 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 ejecucin de sesin. El Ucxt (User Context) mantiene el conjunto de recursos disponibles al usuario para la ejecucin 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 sesin de servicio manteniendo el seguimiento y control de los recursos. El USM (User (Service) Session Manager) comprende el control de servicio y de sesin de las sesiones de usuario (servicio). El SubAgt (Subscription Agent) es un punto de contacto para acceder a la informacin de suscripcin para agentes de usuario. Finalmente, el SF (Service Factory) controla el ciclo de vida de los objetos de la sesin de servicio de acuerdo a las peticiones realizadas desde agentes de usuario.
UAP
Sesin de acceso
USM
GSEP
SSM
SF
UA UCxt TE-A
PPrf
SubAgt
Fig. 2.10 Objetos computacionales relacionados con una sesin de acceso
34
Gestin de red
2.3.5 Evolucin de la red inteligente hacia TINA Existen dos posibles vas para implementar TINA en las redes inteligentes. En un primer caso (Open Switch Path), la solucin se basa en una amplia distribucin de funciones inteligentes sobre una red de servidores y terminales, y un gestor-agente dedicado a controlar las funciones de conmutacin. La red inteligente avanza desde SCPs muy poco centralizados a una web de servidores de red que soportan perfectamente la interaccin CPE-CPN (Customer Premises Network) y los equipos de provisin de servicios. Los servidores de red estn diseados para soportar funciones o servicios especficos. La interaccin entre componentes software est soportada por plataformas basadas en CORBA gracias al IDL (Interface Definition Language). El uso de interfaces pblicas permite definir una sealizacin abierta de servicios especficos. La capacidad de cargar cdigo desde los servidores de la red a las CPEs aumenta la flexibilidad de este enfoque. La segunda opcin (Bridge to Legacy Path) sigue la lnea de la actual implementacin 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 diseados para proveer funciones especficas. Las interacciones con los CPEs no se soportan directamente, estn mediadas por equipos de red (SSPs en el plano de control y IP/SN en el plano del usuario). La interaccin entre los elementos de software dentro de la capa inteligente se soporta por plataformas CORBA, las funciones de gestin estn integradas con las de control gracias al uso de estas plataformas. Es necesario dar un nuevo paso con el fin de superar la segunda generacin de RI e influenciar en los servicios ofrecidos en la era de la multimedia. La inteligencia se soporta por una infraestructura de computacin, pues las aplicaciones, de acuerdo con la arquitectura TINA, funcionan sobre los nodos de computacin. Cada nodo de computacin est agrupado en un entorno de procesado distribuido (DPE). La comunicacin entre los nodos de conmutacin est soportada por conexiones ATM. Los servidores son especializados en funcin 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 gestin y el control de la informacin proporcionada), funciones de recursos (usadas para ejercer el control y la gestin en el nivel de red), y funciones de elementos (que proveen un control especfico 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 fcilmente en la infraestructura si vienen provistos de APIs de control y gestin con interfaces pblicas, los equipos van desde servidores de informacin, hasta routers o conmutadores abiertos. Un entorno de construccin de aplicacin potente como (Application Construction Environment, ACE), inspirado en el concepto de creacin de servicio total, completa la infraestructura. Todos los componentes del servicio estn ya diseados, coordinados y creados. Los diseos de servicio especifican todas las relaciones y limitaciones entre el servicio lgico y el resto de funciones.
2.4 Creacin 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 mtodos y procedimientos para crear y proveer servicios.
35
La red inteligente proporciona un buen nmero de potenciales beneficios. Permite la introduccin de nuevos servicios menos larga temporalmente que los mtodos clsicos, reduce el coste de los nuevos servicios y permite a las compaas telefnicas ser menos dependientes del proveedor de los conmutadores. Con la nueva red inteligente, los nuevos servicios se pueden disear a partir de las ideas de clientes. El proceso de creacin de servicios se ha diseado e implementado para realizar esos beneficios. La creacin de servicios incluye todas las actividades y herramientas necesarias para desarrollar un servicio nuevo o modificado. La creacin 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 creacin de servicios: Proceso: las actividades para generar una nueva idea de servicio, evaluando el nuevo concepto de servicio, documentando, diseando, probando y desarrollando una nueva lgica de servicio. Entorno: los aspectos fsicos de la creacin del servicio, incluida la estructura organizacional y los ordenadores. Se pueden distinguir las siguientes fases en la creacin del servicio: a) Idea del servicio b) Anlisis de necesidades y descripcin del servicio c) Especificacin del servicio d) Desarrollo del servicio e) Verificacin del servicio f) Despliegue del servicio g) Configuracin h) Testeo y mantenimiento a) La creacin de servicio empieza con una idea. Una idea de servicio puede originarse de muy diferentes fuentes. Las compaas telefnicas desarrollarn nuevos servicios en sus esfuerzos para mejorar los servicios existentes (NO-AIN). Otras fuentes de ideas de creacin de servicios son: clientes, gentes de marketing quienes proporcionan nuevos conceptos de servicio a clientes, otros personales de compaas telefnicas 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 anlisis de necesidades. Un comit de anlisis de necesidades estudiara todos los departamentos, incluyendo: operaciones, red, marketing, facturacin, tarifas y departamento de temas de negocios corporativos. El comite evala un nuevo servicio basado en analisis econmicos, anlisis de mercado, anlisis 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 descripcin escrita en donde se describe cmo el cliente quiere el servicio. La descripcin del servicio es el paso para una especificacin detallada del servicio.
36
Gestin de red
d) En el paso de desarrollo de servicio es donde se crean los servicios realmente. Aqu, un creador de servicios usa la especificacin de servicios junto con el conocimiento de la red para producir un programa lgico de servicio, que contiene las instrucciones reales para ejecutar el servicio. e) El programa lgico de servicio debe pasar un proceso de verificacin, que consta de un sistema de test de la lgica de servicio. f) Despus que el programa lgico de servicio se ha verificado, se descarga el programa en el host de lgica de servicio (SCP o adjunto). g) El programa lgico de servicio debe aprovisionarse con datos especficos del cliente (p.e. informacin de encaminamiento segn la hora del da). El programa lgico de servicio es configurado segn las especificaciones del abonado, bien sea mediante representantes del servicio de la compaia telefnica o posiblemente por el propio abonado. h) Muy importante: debe realizarse la comprobacin de extremo a extremo del software, del nuevo servicio para garantizar un servicio de mantenimiento al cliente. Despus de la configuracin, los simuladores deben usarse para probar llamadas al nuevo servicio: si son aceptables, se activa el servicio. La activacin 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 creacin de un nuevo o rediseado servicio.
2.4.1 Entorno de creacin de servicios El entorno de creacin de servicios se refiere a los recursos usados para el soporte del proceso de creacin de servicios, incluyendo estructura de la organizacion, computacin y capacidades de comunicacin. El entorno de creacin de servicios consiste de cinco reas: anlisis, desarrollo, produccin, red y integracin/prueba. El entorno de anlisis es el conjunto de herramientas y facilidades que soportan la generacin, formalizacin y verificacin de las especificaciones de datos y servicio del usuario, funcionales y niveles fsicos. El entorno de desarrollo es el conjunto de herramientas y facilidades que soportan el diseo, la codificacin y prueba de aplicaciones de servicio. El entorno de produccin es el conjunto de herramientas y facilidades que soportan la conversin del software fuente en imgenes ejecutables especficas de la plataforma, y la configuracin de componentes de software para redes especficas y plataformas de operacin. El entorno de red es el conjunto de herramientas y facilidades que soportan: instalacin de imgenes ejecutables en la cima de plataformas en lugares especficos; prueba en la instalacin de imgenes ejecutables; aislamiento de problemas de software; introduccin de correccin de programas temporales para emergencias fijas. El entorno de integracin y revisin es el conjunto de herramientas y facilidades que soportan: introduccin fsica de imgenes ejecutables en la cima de cada paltaforma; prueba y integracin de imgenes ejecutables en cada plataforma; verificacin de fiabilidad de la red en presencia de nuevos componentes de software.
3. Soluciones para la gestin de redes
37
3 Soluciones para la gestin de redes

A lo largo de los aos se han requerido diversas soluciones, generalmente de tipo propietario, para la gestin de las redes de comunicaciones. Actualmente, con el mayor nmero 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 Evolucin de las redes de telecomunicaciones

Las redes de telecomunicaciones dentro del mbito informtico han evolucionado a partir de la necesidad de compartir informacin 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 tenan un uso local y eran manejados por una nica persona o interfaz. Posteriormente, los sistemas operativos pemitieron el acceso de mltiples usuarios que interactuaban en principio tambin en un modo local. La gestin de los equipos, cuando exista, era pues necesariamente local, y los mecanismos especficos 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 gestin local
Ms adelante, el uso de redes de telecomunicaciones permiti el acceso remoto de equipos terminales a los grandes ordenadores. Las redes de tecnologa conmutada y el uso de mdems eran ms baratos
38
Gestin de red
de utilizar que el coste que comportaba la disposicin de mltiples ordenadores. El nico ordenador era de tipo multiacceso y se acceda a ste de modo local, o remotamente mediante el uso de mdems y equipos terminales (inicialmente teletipos). La gestin de red segua siendo bsicamente de tipo centralizado y basada en mtodos del fabricante del mismo ordenador. Si bien esa gestin ya no cubra todos los elementos que entraban en la red de comunicaciones. Terminales locales Terminales remotos
RTC
Mdem
Mdem
Fig. 3.2 Esquema de un sistema formado por un nico ordenador multiacceso y con conexin a terminales de acceso remoto mediante el uso de mdems
A medida que creci el uso del ordenador y aument el nmero de conexiones de equipos terminales a ste, fue necesario reducir la cantidad de mdems utilizados debido a sus elevados costes. La solucin fue la introduccin del multiplexor que permita integrar mltiples conexiones de equipos terminales en una sola lnea de comunicacin con lo que aumentaba el rendimiento. De esta forma, no eran necesarios tantos mdems y se reduca el coste de las telecomunicaciones. Ordenador multiacceso
MUX Mdem Mdem
MUX
Terminal remoto
RTC
Terminales locales
Fig. 3.3 Esquema de un sistema formado por un nico ordenador con conexin de terminales de acceso remoto a travs de multiplexores
39
A medida que el progreso tecnolgico abarataba los costes de la introduccin de ordenadores en la empresa, las redes pasaron de tener configuraciones centralizadas a configuraciones de tipo distribuido con mltiples ordenadores. De esta forma, si bien en un principio se seguan utilizando redes RTC con mdems, eran los ordenadores multiacceso quienes se interconectaban de forma interna. La gestin de red empez a pasar de modelos centralizados a plantearse de modo distribuido o jerrquicamente distribuido en funcin del rango de los ordenadores en la red.
MUX MUX Mdem Mdem
MUX
Terminales remotos
Terminales locales
RTC
Terminales locales
Mdem
Fig. 3.4 Esquema de un sistema formado por un conjunto de ordenadores actuando de forma distribuida conectados a travs de una RTC
Conforme la interaccin mutua del sistema distribuido de ordenadores iba aumentando fue hacindose ms necesario el uso de lneas dedicadas que permitieran reducir el coste debido al trfico de informacin por las redes. Las empresas alquilaban lneas a los operadores de redes y eso permita ofrecer costes menores en comunicaciones. La gestin de red se plantea de forma distribuida. A raz del crecimiento del trfico telefnico en las redes de ordenadores se hace cada vez ms necesario el empleo de lneas telefnicas privadas en las grandes corporaciones. A medida que la tecnologa avance, se introduciran, adems, lneas digitales que se adecuen mejor al trfico generado por las comunicaciones entre ordenadores.
40
Gestin de red
MUX MUX Mdem Mdem
MUX Lneas dedicadas
Terminales remotos
Terminales locales
RTC
Mdem Terminales locales
Fig. 3.5 Esquema de un sistema formado por un conjunto de ordenadores que actan de forma distribuida, conectados va lneas dedicadas
Ordenador Ordenador
Red de paquetes
Fig. 3.6 Esquema de un sistema formado por un conjunto de ordenadores que actan de forma distribuida, conectados segn una red digital o de paquetes
La entrada de las comunicaciones de tipo digital permiti optimizar la transferencia de informacin entre ordenadores. Nacieron redes como RDSI de conmutacin de circuitos para terminales multimedia y otras redes basadas en conmutacin de paquetes como la que utiliza la norma X.25.
41
Ms adelante, con el empleo masivo de terminales tipo PC en las grandes corporaciones, se desarrollaron redes locales en conexin con redes de rea extendida para poder cubrir las distancias correspondientes a campus o ciudades. Otros estndares como Frame Relay o ATM se han desarrollado para permitir esa interconexin de redes locales que pueden estar situadas de forma remota. En estos casos la proliferacin de mltiples fabricantes distintos en el desarrollo de los terminales y dispositivos de interconexin de red hace complicada la gestin de este tipo de redes heterogneas. Es por ello que a partir de esos momentos, resulta evidente la necesidad de disear mecanismos de estandarizacin 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 estandarizacin que trataron de solucionar el problema de la gestin en redes heterogneas, 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 gestin segn las configuraciones de los escenarios, es decir, una gestin autnoma donde las redes tienen gestin local en cada nodo; una gestin homognea con redes homogneas con un nico nodo de gestin centralizado; finalmente, una gestin heterognea, con la ampliacin de las redes con la interconexin de productos heterogneos. Este sera el caso del siguiente ejemplo: una organizacin que interconecta sus sistemas de informacin con diferentes redes de comunicaciones. El caso de utilizar sistemas de gestin 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 aplicacin (de gestin) con distintos programas de aplicacin con funcionalidad similar; y, finalmente, un plano de informacin (de gestin): con una duplicidad y posible inconsistencia de la informacin almacenada en las bases de datos. Todo ello, dificulta el cumplimiento de que la gestin de red sea efectiva desde el punto de vista del coste.
42
Gestin de red
Como solucin se plantea una gestin integrada, en la que se normalizan las comunicaciones con la especificacin de un protocolo entre elemento de red y centro de gestin, y la normalizacin de la informacin donde el centro de gestin debe poder conocer a los elementos de red mediante su nombre y sus propiedades visibles. Por tanto, debe haber tambin una definicin sintcticamente uniforme de los elementos de red. Existen una serie de modelos de gestin normalizados, en los cuales es posible el acceso uniforme a los recursos gestionados. Se normaliza el protocolo de comunicaciones, el modelo de informacin de gestin y las definiciones de informacin de gestin. Los modelos de gestin de red tradicionales ms importantes son la arquitectura TMN (ITU-T), el modelo de gestin OSI (ISO) con el protocolo CMIP y el modelo de gestin Internet (IETF), basado en el protocolo SNMP. Ms recientemente, han adquirido importancia el modelo DMI (DMTF), la gestin por agentes inteligentes y la gestin por webs.
3.2 Modelos para la monitorizacin y el control de red

La gestin de red ha evolucionado desde la gestin basada en arquitecturas de red de tipo propietario hasta el uso, hoy ya masivo, de plataformas de gestin basadas principalmente en sistemas operativos UNIX o NT. Estas plataformas de gestin se implementan segn una integracin de aplicaciones compatibles y que permiten una gran flexibilidad de uso en la gestin de redes heterogneas [GHE1]. Existen tambin los productos especficos para la gestin de redes de rea local, tanto para segmentos independientes como especficos, para redes de PCs o para determinados elementos de red. Finalmente, existen tambin los integradores de sistemas de gestin.
3.2.1 Arquitecturas propietarias Desde siempre los fabricantes lderes en sistemas de gestin han tratado de imponer estndares de facto. 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 lderes 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 gestin por parte de unos pocos fabricantes. Entre las arquitecturas de red ms importantes se encuentran: IBM, Xerox, Novell, Ungerman-Bass, 3 COM, Banyan, Proteon y AT&T. A continuacin se describen algunas de ellas. IBM network management architecture: Open network management (ONA) es el marco de trabajo para los sistemas de gestin IBM. Se definen tres grandes tipos de elementos que realizan funciones de gestin: - 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 gestin SNA.
43
Esquema:
Netview
Punto focal NMVTs Punto de servicio Netview/PC
Punto de entrada Dispositivo SNA

Fig. 3.8 Esquema de la arquitectura de gestin de red IBM
Sistema no SNA
Las plataformas de gestin que utilizan la arquitectura de red IBM pueden ser: Netview para la gestin de redes SNA, LAN Network Manager para la gestin de redes Token Ring y Netview/6000 para la gestin SNMP (Karat). Novell: Novell utiliza un sistema operativo de red, basado en una evolucin del Netware. Recientemente Novell ha introducido CMISE y CMIP en sus sistemas de gestin de red. Actualmente Novell est migrando su torre de protocolos IPX al estndar IP. Arquitectura de gestin de red AT&T: La arquitectura del sistema de gestin mltiple 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 ms bajo est formado por los elementos de la red, es decir, componentes fsicos y lgicos 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 gestin integrados que unen conjuntamente los EMSs de los tres niveles.
NE
NE
Gestin de elementos
NE
Gestin de elementos
NE
NE
Gestin de elementos
NE
Sistema de gestin integrado Interfaz de usuario unificado

Fig. 3.9 Esquema de arquitectura de red de AT&T
44
Gestin de red
3.2.2 Plataformas de gestin Las plataformas de gestin utilizan una integracin de aplicaciones para poder adaptarse al entorno cambiante y complejo de los elementos de red que se quieran gestionar. Entre las aplicaciones ms 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 topologas de la red; la programacin de sondeos de variables de la MIB; la programacin de acciones ante alarmas; y, finalmente, los visualizadores grficos de valores de variables de MIB. Dentro de la categora 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 gestin posibilitan mayor grado de integracin multifabricante que el esquema gestor de gestores. Las interacciones con otros sistemas de gestin de diferentes fabricantes se realizan a travs de un interfaz de programacin de aplicaciones estndares (API) y un conjunto estndar de definiciones de datos de gestin. 3.2.3 Clases de productos de gestin Se pueden distinguir las siguientes clases de productos de gestin para LANs: Productos standalone, dirigidos especialmente a monitorizacin, anlisis de test, seguridad y necesidades de tarificacin. Plataformas de gestin de red que proporcionan un entorno en el cual las aplicaciones pueden ser desarrolladas, mejoradas e intercambiadas. Herramientas de gestin de LANs de PCs, que incluyen soluciones de propsito especial como una combinacin de funciones de sistemas operativos en LANs y aadidos especiales. Sistemas de gestin de elementos LAN basados en estndares abiertos o de facto que ofrecen una aceptable funcionalidad a elementos LAN, tales como segmentos LAN, hubs cableados, dispositivos de interconexin LAN, FDDI, PBXs y conexin a integradores de gestores de red. Integradores que probablemente soportan elementos de gestin de sistemas LAN, MAN, y WAN en la misma plataforma.
3.2.4 Productos de gestin de LANs standalone Los productos standalone sirven reas funcionales especiales sin intencin de aplicabilidad a la integracin de gestin de LANs. Esto es, instrumentos de test de LANs, analizadores de LAN, sistemas de monitorizacin de LAN, u otros instrumentos especiales.
45
Los productos standalone suelen evaluarse de acuerdo a los siguientes criterios: - interfaz de usuario - protocolos que son soportados - nivel de decodificacin - el tipo de LANs/WANs soportadas - buffers de captura - filtros - soporte para monitorizacin distribuida - niveles de disparo - bsquedas - etiquetas temporales - generadores de trfico - chequeo de cables - convencin en el nombrado - diagnstico por s mismo - impresin por hard-copy - proteccin de passwords Entre los instrumentos ms 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 gestin de prestaciones y de fallos. En general ofrecen indicaciones sobre: - Servicio: retardos, tiempo de transferencias, tiempo de dilogo. - Uso: uso global del ancho de banda, uso especfico 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 monitorizacin de precisin y disponer de herramienta de diagnstico para gestores de red. Analizan tanto redes Ethernet como Token Ring (entre otros protocolos). Verifican trfico 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 simulacin de cargas. Los sistemas de monitorizacin de LANs forman una familia de herramientas que soportan monitorizacin continua, ofreciendo una unidad de coleccin de datos en cada segmento LAN. Las funciones que suele realizar el software son del tipo: nmero de canales de entrada, filtros, etiquetas temporales, estaciones de monitorizacin, buffers (colas), niveles de disparo, presentacin, lista de alarmas, protocolos medidos, encabezamientos, estadsticas y informes de errores, interfaz a bases de datos u otros y soporte SNMP. Entre los productos ms representativos, se suele citar el Sniffer (llamado Watchdog) de Network General. Existen equipos ms recientes como el Network Advisor de HP o el Trakker de Concord Communications. Existen tambin instrumentos especiales de LANs. Estos instrumentos especiales soportan reas de gestin de LANs especficas. Por ejemplo, la tarificacin utiliza en particular dos tipos de productos: medidores de software y herramientas de gestin de pruebas de auditabilidad, as como herramientas de documentacin.
46
Gestin de red
3.2.5 Gestin de LANs de PCs Los sistemas de gestin de LANs de PCs estn orientados a supervisin de eestatus, determinacin de fallos y muy bsicas capacidades de administracin. Actualmente las ltimas versiones de Windows NT (Microsoft) est aportando interesantes novedades para la administracin y monitorizacin de las redes locales de PCs. Adems, y aparte de IBM, han dominado el mercado otras compaas 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 presin de los usuarios hacia aplicaciones multiprotocolo, interoperabilidad, etc. las compaas lderes han reaccionado hacia: - Abrir gateways a TCP/IP. - Acuerdos de cooperacin (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. - Adquisicin de productos de monitorizacin para proporcionar a los usuarios con monitorizacin mejorada y gestin. Actualmente son las plataformas abiertas de gestin de red las que constituyen la base comn para que a travs de APIs (interfaces de programacin de aplicaciones) las aplicaciones de gestin 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 aplicacin pueda invocar una funcin de otra. DMI (Desktop Management Interface) fue el primer API de gestin de PCs independiente de protocolos y sistemas operativos (abril 1994). Es uno de los principales componentes de la solucin de gestin 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 estndar en categorias tales como sistemas PC, servidores, impresoras, adaptadores LAN, mdems y aplicaciones software. La arquitectura DMI incluye el nivel de servicio, un programa local que recoge informacin de los productos, gestiona esa informacin en bases de datos MIF, y la pasa a las aplicaciones de gestin cuando es solicitada. Controla, adems, su comunicacin con las aplicaciones de gestin de MI (Management Interface) y con los productos gestionables a traves de CI (Component Interface).
SMS (Systems Management Server) de Microsoft es otra plataforma diseada para soportar tareas de gestin de sistemas, tales como inventarios hardware y software LAN y distribucin electrnica 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 gestin LAN de Microsoft se centra fundamentalmente en el control de los sistemas conectados a la LAN, dejando la gestin 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 solucin abierta para la gestin 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 gestin de NMS corre bajo PCs Windows y sus funciones clave son la exploracin y mapeo de dispositivos de interconectividad, gestin de
47
direcciones de red, rastreo de condiciones de alarmas y su almacenamiento en una base de datos. Dispone de una herramienta de anlisis experto para la solucin de problemas y dispone de la capacidad de gestionar cualquier dispositivo SNMP.
3.2.6 Sistemas de gestin de elementos de red de rea local (LAN) Los sistemas de gestin de elementos de redes derea local gestionan LANs de propsito general. Los sistemas de gestin de elementos en esta seccin estn agrupados en: - ethernet - token Ring - concentradores cableados, hubs - dispositivos de interconexin - backbones de LANs, como por ejemplo FDDI - plataformas de gestin LAN Los segmentos de redes de rea local basados en Ethernet son todava lderes en el mercado. Por ello, es extremadamente importante proporcionar capacidades de monitorizacin y gestin para esos segmentos. Las empresas lderes en este campo son DEC a travs de Ethernim y HP, con LANProbe, Probeview y Openview. IBM est liderando este mercado con herramientas de gestin token ring y con la gama de productos LAN Network Manager. Hay dos opciones de gestin bsicas: gestin standalone de componentes conectados, o centralizados y gestin integrada via Netview. Los productos de gestin de redes LAN de IBM gestionan LANs al nivel de estacin 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 gestin de redes Token-Ring: - IBM LAN Network Management versin 1.0. - IBM LAN Network Management versin 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 gestin de elementos token ring como las ms importantes: - monitorizacin activa - monitorizacin de errores en el anillo - servidor de parmetros al anillo - servidor de configuracin del anillo - servidor de puente LAN - trazas y prestaciones - gestor de estaciones - unidad de acceso controlado - gestor de LANs - Netview (punto de control SNA)
48
Gestin de red
Por otra parte, los concentradores cableados y hubs estn llegando a ser el objetivo de la gestin de redes en LAN. Muchos analistas predicen que la gestin de red basada en bridges y routers va encaminada a gestin basada en hubs. Uno de los sistemas de gestin ms 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 estndares de gestin en algunos tipos de redes todava no estn completamente definidos. Los sistemas de gestin de elementos para LANs interconectados emplazan tanto gestin de LANs como gestin de WANs en el mismo lugar, el control del centro de gestin 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 topologa MAN y/o WAN. Como productos destacados se puede citar el CiscoWorks de Cisco. Finalmente, la mayor parte de sistemas de gestin de elementos multisegmento tienen la capacidad de ofrecer gestin multisegmento desde plataformas estndares o propietarias. stas combinan fast packet, conmutacin, tecnologas de encaminamiento con FDDI, ethernet y hubs token ring que se gestionan desde una plataforma comn y ofrecen mejores prestaciones por el menor coste.
3.2.7 Integradores para gestin de LANs Para la gestin de redes heterogneas se han adoptado diversas estrategias a lo largo del tiempo. Al principio era usual utilizar una integracin de gestin de LANs jerrquica, mediante un esquema de gestor de gestores. Este esquema era vlido pero no permita suficiente flexibilidad en los cambios de configuracin de la red, ya que exiga la modificacin de los programas continuamente. El procesado de la informacin y la fiabilidad de un nico nodo jerrquico superior (gestor de gestores) era tambin una limitacin en redes de muchos nodos. Gestor de gestores
Aplicaciones de integrador
SGE de elementos LAN
SGE PBX
SGE de hubs cableados
SGE de puentes/routers
SGE de PC-LANs
Equipos de test de LANs
Analizadores LAN
Monitores LAN
Objetos gestionados SGE: Sistema de gestin de elementos
Fig. 3.10 Configuracin como gestor de gestores de redes
49
A medida que los fabricantes se fueron enfrentando con el problema de la gestin de gestores fueron adoptando otras soluciones como el uso de integracin de gestin de LANs con plataformas. Actualmente el uso de plataformas de gestin que utilizan APIs (Applications Programming Interfaces) est muy extendido. Finalmente, con el uso masivo de Internet, la gestin de red mediante webs y navegadores se est haciendo cada vez ms normal, si bien los estndares estn an poco desarrollados.
A1
A2
AN
Plataforma para soluciones de fabricantes utilizando el Applications Programming Interface (API)

SGE de elementos LAN SGE PBX SGE de hubs cableados SGE de puentes/routers SGE de PC-LANs
Equipos de test de LANs
Analizadores LAN
Monitores LAN
Objetos gestionados SGE: Sistema de gestin de elementos
Fig. 3.11 Configuracin como gestor que integra APIs para gestin de redes heterogneas
Las aplicaciones sobre plataformas de gestin ms frecuentes son las siguientes: - gestin de equipos especficos - gestin de incidencias a travs de un Trouble Ticket System - gestin de inventario - gestin de cableado - interaccin con otros sistemas de gestin - gestin de fallos mediante sistemas expertos - gestin de sistemas,... Por otra parte, las plataformas de gestin requieren de una integracin entre esas aplicaciones. Existen tres tipos de integracin entre aplicaciones: integracin de comunicaciones, integracin de interfaces de usuario e integracin de informacin. Slo las dos primeras estn solucionadas con el uso de una plataformas de gestin: 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.
50
Gestin de red
LAN Interfaz de usuario (motif, GUI, windows,...) Elementos de servicio - Comunicacin interna i - Interfaz a agentes - Aplicacin entre funciones Elementos de servicio con aplicacin: l i d - Configuracin - Fallos - Prestaciones - Seguridad - Tarificacin
Gateways a agentes propietarios, de facto o abiertos Agente de facto Agente abierto
Agente propietario
Eventos Mensajes Alarmas
Reacciones Comandos
Fig. 3.12 Arquitectura genrica de un producto de gestin de LANs actual
Respecto a la integracin de informacin, se implementa una base de datos local de gestin dado que las aplicaciones de gestin requieren almacenar datos localmente, como datos de topologa, 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 aplicacin tiene necesidades de almacenamiento diferentes, pero con frecuencia existen datos comunes entre ellas. Como consecuencia, cada aplicacin tiene su propia base de datos. Dado que las plataformas actuales no permiten una integracin de la informacin entre las aplicaciones (slo admiten una emulacin de consolas), se definen dos enfoques diferentes para su solucin: un esquema universal de almacenamiento de datos, o bien el desarrollo de aplicaciones a la medida. La integracin puede realizarse de dos formas: mediante el uso de una plataforma o bien mediante el uso de un integrador. Con los productos de integracin, se pueden identificar dos grandes grupos: productos de emulacin de consolas e integradores avanzados. Las soluciones ms importantes basadas en productos de emulacin de consolas son: - Netview (IBM) - Accumaster Integration (AT&T) - DECmcc (DEC) A continuacin, en las siguientes figuras se presentan esquemticamente las funcionalidades de estos integradores.
51
Netview Ayudas a instalacin Comandos de facilidades CLISTs Ayudas a escritorio Hardware monitor (NPDA) Monitor de prestaciones (NPM) Estatus Monitor Soporte 4700 (TARA) Gestor de distribucin Ayudas Navegador (Browser) Monitor de sesion (NLDM) Acceso/SAMON
Fig. 3.13 Estructura Netview (IBM)
Gestin de seguridad Planificacin de redes Recursos sobrantes
Gestin de configuracin y nombres Gestin de fallos Gestin de prestaciones Gestin de tarificacin
NMP
Sistemas de gestin de elementos Sistemas de gestin de elementos Sistemas de gestin de elementos
Elementos de red en una arquitectura distribuida
Fig. 3.14 Accumaster Integrator Architecture
52
Gestin de red
Mdulos de presentacin: Interfaz de lnea de comandos Creacin MAP DEC Windows Mdulos funcionales:
Interfaz
Mdulos de acceso DECnet phase IV DECnet OSI SNMP TCP/IP Ethernet Bridge/router
Ejecucin Registro Dominios Alarmas Analizador de prestaciones Historia Diagnosis DECnet
Reposicin de la informacin de gestin
Fig. 3.15 DECmcc Director
3.3 Mecanismos para la deteccin de configuraciones de red

En el momento de proceder a la obtencin de la configuracin topolgica de una red se pueden aplicar diferentes mecanismos de bsqueda y deteccin de los nodos que configuran la red. Normalmente eso se realiza con la aplicacin Discover desde una plataforma de gestin de tipo convencional. En el proceso de deteccin se envan de modo secuencial mensajes ICMP (Internet Control Message Protocol) a cada uno de los nodos, que la aplicacin presenta en pantalla en el caso de que los nodos estn 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 inundacin de mensajes ICMP no reconocidos que afecten al trfico normal. La solucin a este tipo de problemas pasa por restringir el nmero 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 explcito en la tasa de consultas. Sin embargo, la tasa de consultas podra ser ms 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 generacin de rfagas de mensajes en el momento de descubrir series de nodos. Una poltica de gestin 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 disposicin, 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 solucin pasa por aumentar N; sin embargo, en este caso, las rfagas podran ser mayores. Una posible solucin pasa por prevenir inundaciones, se disea un algoritmo RPE (Regulated Poll Emission) en el que los mensajes de prueba se emiten a una tasa que no supera un determinado nivel,
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 interrogacin de eestatus puedan generarse en rfagas dependiendo de la estrategia escogida de ordenacin. Para ello, la solucin pasa por utilizar un mecanismo de leaky bucket, en la que un nmero especfico de pings puede transmitirse dentro de un tramo especfico de tiempo. Los mensajes se enviaran en intervalos de tiempo no menores que . Si el tiempo de emisin de los mensajes de polling de longitud constante es C, con C < , entonces la tasa de transmisin de polling mxima 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 direccin IP de destino. Para acelerar la gestin de los timeouts 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 tendra un puntero en el registro de la otra para asegurar su borrado automtico y efectivo cuando suceda un timeout. El RPE tiene una serie de ventajas, ya que el mtodo permite un nmero arbitrario de peticiones de eestatus simultneas, permite un rpido cambio en los mapas de eestatus de los nodos de red y previene la liberacin de rfagas de mensajes de peticin de estatus en la red. En cuanto a las limitaciones, cabe decir que no hay un control sobre la tasa de recepcin de reconocimientos (ack. ICMP), con el consiguiente peligro de rfagas de respuestas en caso de recuperacin o desbloqueo de la red.
3.3.2 Modelado de la duracin de un ciclo de consultas de eestatus La duracin de la consulta viene determinada por el nmero de reintentos en la obtencin del estatus de un nodo. En el caso del mtodo COP-N el tiempo de espera es hasta la prxima consulta, mientras que en el RPE es el tiempo en que la peticin de polling est almacenada. Sea un ciclo de polling con K intentos. La duracin del intento k (1 <= k <= K) consta de: C: tiempo de emisin de la peticin de polling. TK : 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. T1 = 10, T2 = 20, T3 = 40, T4 = 80 segundos, por tanto,
= 150segundos .
54
Gestin de red
Transmisin Inicio
Transmisin C
Transmisin C
Transmisin
C 1 p1
p1 T 1
Timeout
p2 T 2
Timeout
p3
p4
T4
Fin
1 p2
1 p3
Timeout
1 p4 A4
Timeout
A1
Ack
A2
Ack
A3
Ack
2
Ack
S S1
S3
Fig. 3.16 Esquema de la duracin 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) Prdida del mensaje de reconocimiento, por ejemplo debido a congestin en la red, con probabilidad 3 . d) El ack. no se devuelve antes que expire el timeout con probabilidad Pr (AK TK ) .
Luego, PK = 1 (1 1 )(1 2 )(1 3 )Pr (AK TK ) ya que los cuatro sucesos pueden ocurrir independientemente. El tiempo de acknowledgment AK se ve afectado por los
i . AK depende de la topologa as como de
los niveles de congestin, lo que complica el anlisis. La solucin pasa por adoptar una AK distribuida exponencialmente con media equivalente al tiempo de viaje de la red gestionada, con lo que E [AK ] podra ser de menos de 10 mseg. o de varios segundos. De hecho, el valor de las probabilidades
i podra 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 Duracin 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 interrogacin al comienzo del k-simo intento S1 : tiempo en tomar la decisin de si el nodo interrogado es alcanzable o no.
55
Para otros intentos aparte del k-simo, se requiere un intento subsiguiente con probabilidad
pK y
resulta innecesario con probabilidad 1 - p K . Si un (k + 1) intento no es necesario, la duracin del k-simo intento ser el comienzo de la emisin al retorno del reconocimiento. Si se necesita, el resto del ciclo de polling incluye el k-simo timeout y la duracin del (k + 1) intento, S K +1 : S k = C + (1 p k )Ak + p k (Tk + 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 duracin 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 duracin 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 [Tk ]+ E [S k +1 ]) con k = K-1, K-2, ..., 2, 1.
3.3.4 Nmero esperado de intentos de polling en un ciclo El nmero 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. Se requeriran K intentos con probabilidad
p
i 1
K 1
Si N p denota el nmero de intentos de polling requeridos dentro de un ciclo, bajo la suposicin de independencia: E N p = K (1 p k ) p j + K p k
k =1 j =1 k =1
[ ]
K 1
K 1
K 1
al primer intento tenemos, (1 p1 ) , con dos intentos slo p1 (1 p 2 ) . Si S p denota el tamao de un mensaje de polling, X denota el mximo flujo bajo el cual se realiza cualquier mecanismo de envo de polling. La mxima demanda de ancho de banda de polling viene acotada por S p XE N p .
[ ]
56
Gestin de red
3.3.5 Flujos del ciclo de polling a) Mtodo COP-N La tasa mxima resulta ser: XN = El perodo de congelamiento resulta ser: N E [S 1 ]
T
i =1
, expresado como la suma de los intervalos de timeout
si N nodos inalcanzables son interrogados en rpida sucesin. 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 prdida de paquetes. C es el tiempo transcurrido al emitir un polling ICMP. Si a es pequeo, las rfagas de consultas podran degradar el comportamiento de la aplicacin.
b) Mtodo RPE 1 la tasa mxima para el envo de peticiones ICMP. Luego, > C a causa de las limitaciones del hardware y del software de E [S1 ] si se quiere tener ms tasa que en el mtodo los equipos. Por tanto, debe cumplirse que < N COP-N. Sea el tiempo mnimo entre emisiones de consultas ICMP. Sea, pues, Sea M el mximo nmero de nodos permitido para que peticiones de polling no sean reconocidas, es decir, M como el nmero de entradas de la lista de registros. De forma que, en general se cumpla que M>>N. Luego, el nmero medio de peticiones de polling residentes en memoria resultar ser de XE [S1 ]. De forma que XE [S1 ] 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 saturacin del sistema operativo y/o la red con mensajes de polling, con lo que crece. Conforme crecen los retardos de propagacin, transmisin, congestin, timeouts, o la alta incidencia de fallos en los nodos, entonces E [S1 ] resulta ser un valor alto. M nunca ser un lmite si es mayor que N. En el mtodo COP-N, con N<<M interrogaciones no reconocidas, el proceso de polling se congelara tan pronto como N fallara, o se sondearan en sucesin nodos no alcanzables. Si la red funciona correctamente, el mtodo COP-N puede atascar la red de forma intermitente, mientras que con el mtodo RPE, se puede escoger un apropiado para evitar bloqueos.
57
3.3.6 Anlisis del retardo Sean n > N nodos ordenados para ser interrogados en el tiempo t y, de stos, los primeros N sean nodos inalcanzables o cados, mientras que el estado del resto n-N nodos es desconocido. Sea M el mximo nmero permisible de ciclos de polling no resueltos bajo el mtodo RPE que, en E [S1 ] general, es mucho mayor que . Luego, en estas condiciones se puede calcular el retardo como: a) Mtodo COP-N Los ciclos de polling para los N nodos fallidos tardan
T
k =1
segundos. Durante este periodo los otros
nodos no pueden interrogarse. Puede suponerse tambin que la interrogacin de estatus del ltimo nodo de la cola se iniciar en el tiempo: t + (n N 1) E [S 1 ]+ Tk
k =1 K
segs. para n >= N + 1.
b) Mtodo RPE Si M es muy grande, y se cumple que n (<M) nodos se han clasificado para polling en el tiempo t y el tiempo mnimo entre pollings es , el -nsimo ciclo de polling se inicia en el tiempo t + (n 1) tanto si los primeros N nodos han sido alcanzados como si no. Adems el n-simo ciclo de polling ser mejor con el mecanismo de control de tasa si (n 1) (n N 1) E [S 1 ]+ Tk
k =1 K
Para n = N + 1 , el n-simo ciclo de polling se iniciar antes que el mecanismo de tasa constante:
T
k =1
ya que es mucho menor, en general, que el otro trmino. El mtodo 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 gestin de telecomunicacin orientados a objetos
59
4 Entornos de gestin de telecomunicacin orientados a objetos

A medida de que las redes de comunicaciones tienden cada vez ms a ser sistemas complejos, es necesario tener metodologas de modelado formales para entender, describir, construir operar y gestionarlas [BA1].
4.1 Introduccin a la orientacin a objetos

El modelado orientado a objetos puede definirse como una formalizacin de la habilidad humana de categorizar cosas. Se puede distinguir entre el modelado orientado a objetos, ms abstracto, menos detallado y ms comprensivo de la visin del sistema, que se aplica mejor en las fases iniciales del proceso de diseo de una red, y la programacin orientada a objeto, que concierne a los detalles de diseo del sistema a bajo nivel y a la eficiencia en la implementacin. En este caso, el uso de lenguajes de programacin orientados a objetos se podra utilizar para implementar un modelo orientado a objetos.
4.2 Objetos gestionados y el entorno gestor/agente

El tema de comunicacin entre objetos en una programacin 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 gestin ms bsica, esto es, el sistema gestor/agente. Un lenguaje de programacin orientado a objeto podra 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 propsito. Cada clase en el modelo tiene un referente en el sistema real. Las clases de objetos deben especificarse para todo un conjunto de funciones: fsicas, lgicas, humanas, etc. en el modelo de red. El ncleo de las propiedades especificadas en una clase de objetos son los atributos, funciones y cpsulas. Las clases se organizan en una jerarqua de herencia con una generalizacin que se incrementa hacia arriba y una especializacin que se incrementa hacia abajo. En teora de la especializacin, generalizacin y especializacin se describen formalmente en trminos 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 especializacin. La base de especializacin acta como un factor que permite distinguir entre subclases.
60
Gestin de red
La especializacin 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 numrico de la superclase, la especializacin ocurre restringiendo el dominio de valores que se le permite poseer al atributo en la subclase. En algunas ocasiones es necesario usar ms de una propiedad como base para la misma especializacin: esto se conoce como especializacin compuesta.
Multiplexor Velocidad del puerto
Velocidad del puerto < 45 Mbps

Multiplexor banda estrecha
Velocidad del puerto >= 45 Mbps
Multiplexor ancha
banda
Fig. 4.1 Base cuantitativa de la especializacin
Servicios de llamada al cliente Tipo de servicio Nmero de versin software Fecha de inicio servicio Tipo de servicio = Llamada en espera Tipo de servicio = Multiconferencia Servicio multiconferencia Tipo de servicio = Trazas llamada Servicio trazas llamada
Servicio llamada en espera
Fig. 4.2 Base cualitativa de la especializacin
Las clases se especializan desde sus superclases usando una base formal de especializacin. Si se usa un atributo como la propiedad de base de una especializacin, las subclases creadas tienen valores restringidos por el dominio del atributo. El atributo, escogido como propiedad de base, podra tener un valor continuo o un valor discreto. La particin del dominio de la base atributo en las subclases se considera en funcin de criterios de completitud y solapamiento. Podran considerarse simultneamente mltiples propiedades para su uso como base compuesta de especializacin.
4. Entornos de gestin de telecomunicacin orientados a objetos
61
Disjuntos Ms deseable
Solapados
Completos
No deseable
Incompletos
Deseable
Lo menos deseable
Fig. 4.3 Modos de subclases para bases seleccionadas de especializacin
Para el desarrollo de productos o redes usando metodologas de modelado orientado a objetos, la arquitectura de la red debe organizarse usando jerarquas de herencia y agregacin. La jerarqua 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 jerarqua de agregacin que se manifiesta en la arquitectura de la red inteligente.
SCE
SCP: Punto de control de servicios SSP: Punto de conmutacin de servicios STP: Punto de transferencia de sealizacin SMS: Sistema de gestin de servicios IP: Perifrico inteligente SDP: Punto de datos de servicios SCE: Entorno de creacin de servicios AD: Adjunto SN: Nodo de servicios
SMS
SCP
SDP Red de sealizacin SS7
IP
STP AD/SN Local Local SSP
Terminal de usuario B
Terminal de usuario A
RTC
Fig. 4.4 Esquema de arquitectura de la red inteligente
62
Gestin de red
Red inteligente [1, - ] Punto de Conmutacin de servicio [1] Funcin de conmutacin de servicio [0, - ] Punto de Transferencia de seal [0, - ] Punto de control de servicio [1] Funcin de control de servicio [1] Funcin de conmutacin de servicios [0, - ] Sistema de soporte de operaciones [1] Funcin de datos de servicio [0, - ] Procesador adjunto [0, - ] Nodod de servicio [0, - ] Perifrico inteligente
[1] Funcin de control de llamada
[1] Funcin de control de servicio
[1] Funcin de datos de servicio
[1] Funcin de recursos especializados
[1] Funcin de control de llamada
[1] Funcin de control de servicio
[1] Funcin de datos de servicio
[1] Funcin de recursos especializados
Fig. 4.5 Jerarqua de agregacin parcial para la red inteligente
6. Red De gestin de las telecomunicaciones (TMN)
63
5 Gestin segn OSI

El fundamento del sistema de gestin OSI es la base de datos que contiene informacin relativa a los recursos y elementos que deben ser gestionados (MIB). La estructura de gestin de informacin (SMI) identifica los tipos de datos que pueden ser usados en la MIB y cmo se representan y nombran los recursos dentro de la MIB [STA2]. Cada recurso que se monitoriza y controla por el sistema de gestin 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 gestin, la complejidad de la gestin se traslada al agente (que reside en un ordenador). Los protocolos de gestin permiten realizar funciones ms complejas dado que el modelo de informacin tambin es complejo. La evolucin de este tipo de gestin permitir realizar una gestin integrada en entornos heterogneos (p.e. TMN). Las recomendaciones de la serie X.700 permiten hablar de una serie de modelos de gestin de sistemas. Son los siguientes: - Modelo de comunicaciones: se detalla el protocolo de gestin y el servicio que proporciona. - Modelo de informacin: se definen los recursos de red usando una sintaxis abstracta. - Modelo funcional: se definen las funciones de gestin que proporcionan una interfaz a la aplicacin de gestin. - Modelo de organizacin: se exponen las posibles subdivisiones de la red en dominios de gestin.
5.1 Modelo funcional
El modelo funcional describe las cinco reas en las que tradicionalmente se ha dividido la gestin de red: gestin de fallos, gestin de configuracin, gestin de prestaciones, gestin de contabilidad y gestin de seguridad. El sistema de gestin basado en OSI define una serie de niveles con interfaces de gestin que interactan con la base de datos MIB. El nivel de aplicacin interacta, a su vez, con otros procesos de gestin mediante el protocolo CMIP (Fig. 5.1).
64
Gestin de red
OSI ha definido cinco grandes reas de gestin (SMFAs) denominadas de fallos, contabilidad, prestaciones, seguridad y configuracin (Fig. 5.2). Estas reas estn a su vez constituidas por diversas funciones especficas (SMF) que realizan procesos de gestin, interactuando con los servicios CMISE.
Proceso de aplicacin de gestin de sistemas Interfaz de gestin de sistemas LME de gestin de sistemas Entidad de presentacin LME Entidad de sesin Entidad de LME transporte LME LME Entidad de red LME Entidad de nivel de enlace LME Entidad fsica Interfaz de gestin de capas LME: layer-management entity
Entidad de aplicacin
CMIP
Proceso agente
Base de datos de informacin de gestin
MIB
Fig. 5.1 Marco de gestin OSI
5.2 Modelo de organizacin

El modelo de organizacin parte de una estructura de red dividida en dominios de gestin. La divisin del entorno se realiza a partir de dos aspectos principales: polticas funcionales (p. e. dominios con una misma poltica de seguridad, contabilidad,...), o bien otras polticas, como dominios geogrficos, tecnolgicos, 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 dinmicamente el papel de gestores y agentes.
5.3 Modelo de comunicaciones: CMIP

El Common Management Information Protocol (CMIP) se define en el estndar 9596 de OSI. Este protocolo ofrece un mecanismo de transporte en la forma de servicio pregunta-respuesta para capas OSI. La especificacin del protocolo describe precisamente cmo se ejecutan los servicios CMIS
65
individuales. En la figura 5.3 se pueden observar los estndares relacionados con la gestin definida por OSI.
reas funcionales de gestin especficas (SMFA)
Gestin de fallos
Gestin de contabilidad
Gestin de configuracin
Gestin de prestaciones
Gestin de seguridad
Gestin de objetos
Gestin de informacin de eventos
Gestin de estados Control de registros
Gestin de relaciones Pruebas de seguridad-audit.
Informacin de alarmas Control de acceso Sumarizacin
Informacin de seguridad y alarmas
Registro de contabilidad
Monitorizacin de carga de trabajo
Gestin de test
Funciones de gestin del sistema (SMF)
Servicios CMISE Event report Create Get Delete Set Cancel-Get Action
Fig. 5.2 Funciones de gestin de sistemas
Una parte de la especificacin del protocolo CMIP es la definicin de la Abstract Syntax Notation (ASN.1) para codificacin y decodificacin de unidades de datos del protocolo CMIP (PDUs). Estos aspectos se estudiarn en el capitulo 12, relativo a Internet. A lo largo de la evolucin del protocolo CMIP han surgido variantes del protocolo para diferentes entornos. Por ejemplo, existe una versin de CMIP sobre protocolos TCP/IP denominada CMOT, o bien el caso de una versin de CMIP sobre protocolos IEEE de LANs denominada CMOL. En la figura 5.4 se detallan los subniveles que forman el nivel de aplicacin en un entorno de gestin segn el estndar OSI (Entidad de Aplicacin de Gestin de Sistemas, SMAE).
66
Gestin de red
5.3.1 Caractersticas principales del protocolo CMIP Entre las caractersticas ms 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 comunicacin con los agentes est orientada a conexin. - La estructura de funcionamiento es distribuida. - Permite una jerarqua de sistemas de operacin. - El protocolo asegura que los mensajes llegan a su destino. El hecho de que se trate de una gestin conducida por eventos se traduce en que: - El agente notifica al gestor de sucesos la informacin concerniente a los recursos gestionados. - El agente es responsable de monitorizar los recursos. - Presenta la ventaja de que existe menor gestin de trfico. - Presenta la desventaja de tener agentes ms complejos.
Gestin del marco de trabajo 7498-4 X.700 Introduccin a la gestin de sistemas 10040 X.701
Tutorial de gestin del sistema
Modelo de informacin de gestin 10165-1 X.720 Funciones de gestin de sistemas 10164-n X.7nn Guias para la definicin de objetos gestionados 10165-4 X722 Definicin de informacin de gestin 10165-2 X.721 Definicines de objetos gestionados
Servicio de informacin de gestin comn 9565 X.710
Protocolo de informacin de gestin comn 9596-1 X.711
Fig. 5.3 Relaciones entre estndares OSI
67
Proceso de aplicacin
Proceso de aplicacin
SMAE
SMASE
MAPDUs
SMASE
CMIPDUs
SMAE
CMISE
CMISE
otros ASEs ACSE
ROSE
otros ASEs ACSE
ROSE
Nivel de presentacin
MAPDUs: unidad de datos de protocolo de aplicacin de gestin. CMIPDUs: unidad de datos de protocolo de informacin de gestin comn.
Nivel de presentacin
Fig. 5.4 Gestin en el nivel de aplicacin
5.3.2 Servicios usados por CMIP CMIP hace uso de ACSE ya que establece y finaliza asociaciones para el intercambio de informacin de gestin. El tipo de asociacin se especifica en el campo Application Context de la primitiva de asociacin de ACSE (manager, agent, o manager-agent). Es usado directamente por el usuario de gestin. El protocolo CMIP tambin hace uso de ROSE, ya que es usado por CMISE para la solicitud de ejecucin de operaciones remotas. El gestor solicita una operacin 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 travs de CMISE (Common Management Information Service Element), CMIP proporciona tres tipos de servicio: - Manejo de datos: usado por el gestor para solicitar y alterar informacin de los recursos del agente. - Informe de sucesos: usado por el agente para informar al gestor sobre diversos sucesos de inters. - Control directo: usado por el gestor para solicitar la ejecucin de diversas acciones en el agente. Tambin hace uso del servicio de operaciones remotas proporcionado por ROSE.
68
Gestin de red
5.3.4 Primitivas CMIP Existen las siguientes primitivas CMIP para peticin 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 obtencin de informacin de gestin desde una capa de usuario de servicio CMISE. - M-SET (conf/no-conf) -> manejo de datos Pide la modificacin de informacin de gestin 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 accin. - 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 peticin previa de invocacin de un servicio M-GET.
La estructura de los mensajes de operaciones CMIP tiene los siguientes campos de informacin: - Object Class - Object Instance - Scope (subarbol, niveles,...) - Filter (todos los objetos con determinadas condiciones lgicas) - Access Control - Synchronization - Attribute Identifier List Se definen las siguientes primitivas CMIP para transmisin 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 mltiples objetos, incluyendo un parmetro de enlace para proporcionar mltiples
69
rplicas a una nica peticin. Aunque la primitiva M-SET tambin permite la especificacin de mltiples objetos, no soporta respuestas enlazadas. Para las cuatro primitivas se proporcionan herramientas para la seleccin de objetos, basadas en el filtrado, la sincronizacin y la contencin (scope).
5.3.5 Arquitectura de comunicaciones A continuacin se presenta en la figura la torre de protocolos OSI que soporta el estndar de gestin CMIP:
Aplicacin de gestin ASE especfica de gestin FTAM CMISE CCR ACSE ROSE ACSE Nivel 6 Nivel 5 Nivel 4 Subred 2 802.3 Nivel 1-3
Nivel 7
Nivel OSI de presentacin Nivel OSI de sesin Nivel OSI de transporte Subred 1 X25
Fig. 5.5 Arquitectura de niveles definida para el protocolo CMIP
Actualmente las plataformas de gestin con protocolo CMIP de diferentes fabricantes presentan informacin que es propietaria, de forma que existe una cierta incompatibilidad si se quieren utilizar conjuntamente en la gestin de una red. En la figura adjunta se describe esta situacin. Finalmente, y ms recientemente, se ha presentado el interfaz XOM/XOP, definido por la asociacin X/Open para la coexistencia de protocolos SNMP con CMIP. A partir de unos proxies se permite la complementariedad de gestin 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.
70
Gestin de red
Fabricante A Aplicaciones de plataforma y gestin
Fabricante B
Sistemas de gestin de red

CMIP CMIP
Aplicaciones de plataforma y gestin
CMIP CMIP
CMIP
CMIP
MIB propietario
Standard MIB
Agentes de objetos gestionados Fabricante A
Sistemas gestionados
Standard MIB
MIB propietario
Agentes de objetos gestionados Fabricante B
Fig. 5.6 Sistemas de gestin de red basados en CMIP emergentes
5.3.6 X/Open Abstract Data Manipulation Application Program Interface XOM OSI Abstract Data Manipulation API (XOM) define un interfaz de programacin de propsito general a gestin de objetos OSI (gestin de objetos como la creacin, el examen, la modificacin y el borrado de objetos potenciales de informacin compleja). La arquitectura de informacin 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, cmo el cliente comunica con el servicio, cmo el servicio comunica con el cliente en respuesta, y cmo componentes del servicio comunican unos con otros. La arquitectura no dicta la estructura fsica de la informacin ni cmo 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 cdigos de retorno de las funciones de interfaz de servicio (p.e. codificacin invalida, errores permanentes,...). El XOM Workspace Interface define tipos que especifican la parte inicial de la representacin de objetos y algunas estructuras de datos asociadas. Tambin proporciona una definicin de macros para cada funcin interfaz de servicio, que usa la estructura de datos definida para llamar la
71
implementacin de las funciones apropiadas para los argumentos particulares. La especificacin XOM incluye tambin Object Management Package donde se define la jerarqua 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 informacin de gestin. La interfaz se dise para ofrecer servicios que estn relacionados con los estndares CMIS/CMIP y SNMP. El XMP opera entre una aplicacin de usuario y el software comn definido por la X/Open y asla la parte del programador de todas las operaciones del software X/Open. Permite la manipulacin de diferentes estructuras de informacin de gestin descritas en ISO 10165 y RFC 1155.
Programa de gestin API XOM API XMP
Gestin de paquetes de servicio
Paquete XOM
Paquete comun
Paquete DMI
Paquete CMIS
Paquete SNMP
Espacio de trabajo de los objetos gestionados

Fig. 5.7 Relacin entre XOM y XMP
La especificacin XMP describe un nmero de funciones con muchas clases y objetos OM, que se utilizan como argumentos y resultados de las funciones. La interfaz modela interacciones de gestin como peticiones de servicio. Estas peticiones de gestin se realizan a travs de un nmero de funciones interfaz, que usan un nmero de argumentos de entrada. Cada peticin vlida causa una operacin realizada por agente o notificacin direccionada al gestor. Despus de algunas operaciones, un estatus o los resultados de las operaciones pueden devolverse. Todas las interacciones gestoragente se realizan durante una sesin, 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.
72
Gestin de red
5.3.8 CMIS/P++ CMIS++ es una nueva versin de CMIS que proporciona mucha ms potencia expresiva, mientras que CMIP++ soporta evaluacin remota y minimiza el trfico de gestin requerido para la obtencin de informacin de gestin. Esta extensin de la arquitectura se justifica por los requerimientos que presenta la gestin de redes como SDH.
5.4 Modelo de informacin

El modelo de informacin proporciona una representacin de los recursos gestionados. En el esquema de la figura 5.8 se muestra el proceso de obtencin de la informacin de gestin del entorno de red.
Operaciones gestin Gestor Agente

Operaciones gestin Notificaciones
Notificaciones
Entorno local
Fig. 5.8 Esquema del proceso de gestin en un entorno de red
El objetivo consiste en modelar los aspectos de gestin de los recursos reales, as como definir una estructura para la informacin de gestin que se transmita entre sistemas. Este modelado se estructura en funcin de unos objeto gestionados (MO: Managed Object) que se pueden definir como abstracciones de un recurso que representa sus propiedades para el propsito de su gestin (p.e. entidad de capa, conexin, item de un equipo de comunicaciones fsico). Para el caso que nos ocupa, slo es necesario definir los aspectos del recurso tiles para su gestin. De la misma forma no se define la relacin entre el recurso y su abstraccin 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 gestin de sistemas permitidas sobre el objeto, el comportamiento del objeto en respuesta a las operaciones de gestin, las notificaciones que puede enviar, los paquetes condicionales que pueden ser encapsulados en el objeto (caractersticas opcionales del objeto), la posicin del objeto en la jerarqua de herencia o bien la especificacin de las clases de objetos alomrficas con su clase. Por otra parte, el modelo de informacin hace uso de los principios de diseo orientado a objetos. Para ello, se requiere adaptar un enfoque que permita estandarizar especificaciones de una manera modular. El enfoque elegido debe proporcionar una fcil capacidad de extensin del protocolo y de los procedimientos. Tambin se debe permitir la reutilizacin de especificaciones anteriores. Finalmente, hay que tener en cuenta que el mbito de diseo es aplicado a la especificacin de informacin transmitida en los protocolos de gestin, no a la implantacin.
73
Antes de seguir adelante es necesario repasar una serie de conceptos relacionados con el diseo orientado a objetos que se utilizan en la gestin 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 gestin 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 concrecin de la informacin 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 relacin de inclusin 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 envo de mensajes al objeto. Por otra parte, no es visible la operacin interna del objeto, salvo cuando se hayan definido atributos, operaciones o notificaciones para mostrar esta informacin. En cuanto a las clases y ejemplares, se diferencia entre los aspectos relativos a la definicin de los objetos y los aspectos de implementacin de estos objetos. Es decir, la definicin 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 implementacin 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 especializacin genera una nueva clase (subclase) por extensin de otra ya existente (superclase), aadiendo nuevas propiedades. Por tanto, introduce una relacin de herencia. Las propiedades de una clase se pueden extender a partir de la ampliacin con nuevos atributos, la extensin/restriccin de los rangos de atributos, la ampliacin con nuevas acciones o notificaciones o bien la ampliacin de los argumentos de acciones y notificaciones. Existe una TOP o superclase superior de la jerarqua de la herencia que contiene las propiedades comunes a todos los objetos gestionados. Por otra parte, se permite slo la herencia estricta de las propiedades, es decir, que una subclase se especialice mediante la adicin de nuevas propiedades (no se pueden quitar propiedades). Tambin se permite herencia mltiple, lo que conlleva una serie de beneficios: una mayor reutilizacin de las definiciones de clases y una mejora de la capacidad de un sistema gestor para reconocer clases no conocidas. Ejemplo de jerarqua de herencia:
74
Gestin de red
cima red sistema equipo
Red X.25
bridge
router
Fig. 5.9 Esquema un rbol de jerarqua 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). Tambin se permiten atributos multivaluados y atributos de grupo. El comportamiento (behaviour) define a los miembros de la misma clase si exhiben el mismo comportamiento (interactan) ante la misma operacin de gestin. El comportamiento de un objeto se define por la semntica de atributos, las operaciones y notificaciones, la respuesta a operaciones de gestin 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 estn o todos presentes o ausentes a la vez en un objeto gestionado (p. e. correo electrnico con paquete condicional de seguridad). La condicin 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 extensin de una clase de tal manera que contine la interoperabilidad cuando el gestor o el objeto gestionado no incluyan esta extensin. Por otra parte, se necesita para posibilitar la migracin de versiones de gestin. Existen una serie de constricciones para las subclases alomrficas: esto es, deben incluir un atributo que identifique las superclases alomrficas 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 tambin las superclases no restringidas, que son superclases sin restricciones en sus valores. Se especializan subclases alomrficas con distintas restricciones que no seran permitidas en un alomorfismo directo entre ellas. La determinacin del comportamiento alomrfico se representa mediante un argumento en la peticin de la operacin. Tambin 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 alomrfica permitida y que aparezca primera en la lista.
75
Existen una serie de operaciones posibles sobre objetos. Una operacin en un objeto gestionado sirve para afectar la gestin 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 accin distinta ante cambios en las propiedades. Son tiles para modelar la ejecucin remota de comandos. La notificacin es un informe emitido por el objeto cuando se cumplen determinadas condiciones. Las condiciones de las notificaciones se especifican en la definicin. 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 definicin de clases se parte de la posicin en la jerarqua de herencia, los atributos de la clase, los comportamientos, las acciones, las notificaciones, y las clases alomrficas. Las propiedades anteriores se pueden agrupar en paquetes (obligatorios o condicionales).
raz sistema sistema
PC
Estacin de trabajo Placa red
PC
Unidad disco
Unidad disco
Fig. 5.10 Esquema de rbol de agregacin
Una jerarqua de agregacin refleja la relacin de contencin entre instancias de objetos. Cuando se establece una jerarqua de agregacin, una instancia subordinada est contenida en una nica instancia superior. Tiene como utilidad la estructuracin de instancias de objetos en los agentes (usado por los parmetros de filtrado y mbito del CMIP. Tambin permite realizar operaciones con una gran potencia). Define tambin el nombrado de los ejemplares desde el gestor. En la figura 5.10 se muestra un ejemplo de rbol de agregacin. 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
76
Gestin de red
Distinguished Name (RDN). El nombre de una instancia es la concatenacin de RDN de sus antecesores en la jerarqua de agregacin. Un ejemplo de nombre completo de instancia es el siguiente: SistemaId=DEPART3@PCId=PCMarketing@UnidadID=DiscoA
raz sistema SisID=ST5 sistema SisID=ST8
PC PCid=PC7
Estacin de trabajo WSId=Sun5 Placa red PlacaId=Eth1
PC PCId=PC2
Unidad disco Unid=B
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 jerarqua de agregacin. Por ello, se definen junto a la definicin 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 notacin 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 extraccin de rbol de herencia y extraccin de los posibles rboles de agregacin (a partir de las ligaduras de nombrado), as como para ver la capacidad de gestin que ofrece: atributos que se pueden leer (o leer y controlar).
77
5.4.2 GDMO (Guidelines for Definition of Managed Objects) La notacin GDMO proporciona las pautas para la definicin de MIBs. Por ello, se hace uso de unas macros que se definen mediante macros ASN.1. La norma proporciona adems normas tiles para disear MIBs, como son el agrupamiento de datos, el uso de herencia y la definicin de relaciones. Existen una serie de macros GDMO para la definicin de: - MANAGED OBJECT - PACKAGES - PARAMETER - NAME BINDING - ATTRIBUTE - ATTRIBUTE GROUP - BEHAVIOUR - ACTION - NOTIFICATION A continuacin se especifican las plantillas correspondientes a las macros anteriores, para ello se utiliza la siguiente notacin:
Notacin: MAYUSCULAS: palabras clave [MAYUSCULAS]: palabras clave opcionales <texto>: 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 informacin sobre algn elemento definido en las plantillas.
Plantilla de object class (clase de objeto): <clase> MANAGED OBJECT CLASS DERIVED from <clase>; CHARACTERIZED BY <package> | <PACKAGE> [, <package> | <PACKAGE>]*; CONDITIONAL PACKAGES <package> PRESENT IF <condition> [, <package> PRESENT IF <condition>]*; REGISTERED AS {n de registro}
78
Gestin de red
Plantilla de Package (lote): <packagelabel> PACKAGE [BEHAVIOUR <behaviour-definitions-label> [, <behaviour-definitions-label>*;] [ATTRIBUTES <attributes-label> propertylist [<parameter-label>]* {,<attribute-label> propertylist [<parameter-label>]* }*;] [ATTRIBUTES GROUPS <group-label> <attribute-label>]* [, <group-label> <attribute-label>]*]*;] [ACTIONS <action-label> <parameter-label>]* [,<action-label> <parameter-label>]*]*;] [NOTIFICATIONS <notification-label> <parameter-label>]* [,<notification-label> <parameter-label>]*]*;] [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 <behaviour-definition-label get-replace -> GET |REPLACE | GET-REPLACE add-remove -> ADD | REMOVE | ADD-REMOVE
Plantilla de attribute (atributo) <atributo> ATTRIBUTE DERIVED from <atributo>; o WITH ATTRIBUTE SYNTAX <tipo ASN.1>; [MATCHES FOR [EQUALITY | ORDERING | SUBSTRINGS |SET-COMPARISON | SET-INTERSECTION],*;] [BEHAVIOUR <behaviour> [, <behaviour>*];] [PARAMETERS <parameter> [, <parameter>*];] [REGISTERED AS {n de registro}];
79
Plantilla de behaviour (comportamiento) <etiqueta-comportamiento> BEHAVIOUR DEFINED AS <descripcin>;
Plantilla de notification (notificacin) <notificacin> NOTIFICATION [BEHAVIOUR <behaviour> [, <behaviour>*];] [PARAMETERS <parameter> [, <parameter>*];] [WITH INFORMATION SYNTAX <tipo ASN.1> [AND ATTRIBUTE IDS <fich> <atributo> ] [<fich> <atributo>]*];] [WITH REPLY SYNTAX <tipo ASN.1>; ] REGISTERED AS {n de registro};
Plantilla de action (accin) <action> ACTION [BEHAVIOUR <behaviour> [, <behaviour>*];] [MODE CONFIRMED;] [PARAMETERS <parameter> [, <parameter>*];] [WITH INFORMATION SYNTAX <tipo ASN.1> [WITH REPLY SYNTAX <tipo ASN.1>; ] REGISTERED AS {n de registro};
Plantilla de name binding (ligazn de nombres) <nombre-relacin> NAME BINDING SUBORDINATE OBJECT CLASS <clase> [AND SUBCLASSES]; NAMED BY SUPERIOR OBJECT CLASS <clase> [AND SUBCLASSES];
80
Gestin de red
WITH ATTRIBUTE <attribute>; [BEHAVIOUR <behaviour> [, <behaviour>*];] [CREATE [WITH-REFERENCE-OBJECT | WITH-AUTOMATIC-INSTANCE-NAMING] [<PARAMETRO>*];] [DELETE [ONLY-IF-NO-CONTAINED-OBJECT | DELETES-CONTAINED-OBJECTS] [<PARAMETERS>*];] REGISTERED AS {n de registro};
81
6 Red de gestin de las telecomunicaciones (TMN)

La TMN (Telecommunications Management Network) proporciona funciones de gestin y comunicaciones para la operacin, la administracin y el mantenimiento de una red de telecomunicaciones y sus servicios en un entorno de multiples fabricantes [SLO1]. Existieron dos motivaciones bsicas para el desarrollo de la arquitectura TMN: una es la creciente heterogeneidad en la tecnologa para la construccin de redes de telecomunicacin, y la coexistencia de redes analgico-digitales; otra se deriva de las mayores demandas sobre: posibilidad de introducir nuevos servicios, alta calidad de servicios, posibilidad de reorganizar las redes. mtodos eficientes de trabajo para operar las redes y competencia entre empresas operadoras privadas. La TMN define la relacin entre los bloques funcionales bsicos constituyentes de la red (sistemas de operacin (OS), red de comunicaciones de datos, elementos de red (NE)) a travs de interfaces estndares. Introduce el concepto de control de subred (conjunto de elementos de red agrupados segn un determinado criterio (p.e. funcin, provedor,) y es tratada como una sola entidad por la aplicacin de gestin. El dispositivo que implementa la funcionalidad OAM&P de subred, el elemento gestor (EM), simplifica la comunicacin entre OSs y NEs. Desde el punto de vista de la arquitectura, el EM es un punto de gestin flexible que une la realizacin del fabricante con los sistemas de gestin de la red, utilizando las interfaces y modelos de informacin 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 fsica: estructura y entidades de la red. - Modelo organizativo: niveles de gestin. - Modelo funcional: servicios, componentes y funciones de gestin. - Modelo de informacin: definicin de recursos gestionados. Las recomendaciones para la red TMN son las siguientes: M.3000. Introduccin a la recomendacin TMN. M.3010. Principios para una red de gestin de telecomunicaciones. M.3020. Metodologa para la especificacin de la interfaz TMN. M.3100. Modelo de informacin de elementos de red genricos. M.3101. Requerimientos para conformar objetos gestionados en TMN M.3100. M.3180. Catlogo de informacin de gestin TMN.
82
Gestin de red
M.3200. Introduccin a los servicios de gestin TMN. M.3300. Capacidades de gestin TMN presentadas en la interfaz F. M.3400. Funciones de gestin TMN. M.xfunc. Servicios de gestin TMN y funciones para la interfaz X. M.xinfo. Identificacin de la informacin que se intercambia va la interfaz X para diferentes casos de acceso.
Red TMN
F
Estaciones de trabajo
Red de comunicacin de datos
Q3
Q3
Dispositivos de mediacin
Qx Q3 Q3 Q3 Qx Qx
Adaptadores a interfaz Q
Qx
Red de comunicacin de datos
Adaptadores a interfaz Q
Qx
Elementos de red Sistema Satlite
Fig. 6.1 Esquema de arquitectura fsica TMN
83
6.1 Arquitectura fsica

La arquitectura fsica de TMN proporciona la manera de transportar la informacin de los procesos relacionados con la gestin de las redes de telecomunicaciones. Los componentes que forman esta arquitectura fsica 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
X
OS
X/F/Q3 F WS Q3/F G
DCN
MD QX X DCN Q3 QA X/F/Q3 NE QX QA F WS X/F/QX NE G
Fig. 6.2 Arquitectura fsica 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 pequeos elementos de red que requieran unas pocas funciones OAM utilizadas con gran frecuencia. Utilizada normalmente por los NEs y MDs ms 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 informacin: semntica de datos (MIBs GDMO).
84
Gestin de red
Interfaz X: soporta el conjunto de funciones para la interconexin de diferentes OSs, ya sea entre entornos de TMNs o no. Requiere de las 7 capas de OSI, segn est definido en la normativa T1.217 de ANSI. Los mensajes y protocolos definidos para la interfaz X podran usarse igualmente en la interfaz Q3. Interfaz F: soporta el conjunto de funciones para la interconexin de estaciones de trabajo con componentes fsicos 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 gestin: - gestin comercial - gestin de servicios - gestin de red - gestin de elementos de red - elementos de red. Este modelo va ms all del que se define para una organizacin de la red desde un punto de vista tcnico, puesto que cubre variados aspectos de administracin en el sector del marketing y los servicios, requeridos por las empresas proveedoras de servicios. A continuacin se describen las funciones relacionadas con la organizacin de la TMN. sta se estructura mediante un modelo de capas:
Capa de gestin comercial: soportada por un sistema de operacin comercial (OS) con las siguientes funciones asociadas: - gestin completa y responsabilidad de empresa total - tareas de asignacin de objetivos - accin ejecutiva
Capa de gestin de servicios: soportada por un sistema de operacin de servicios (OS) con las siguientes funciones asociadas: - interfaz con clientes y otras administraciones - interaccin con proveedores de servicios - mantenimiento de los acuerdos de nivel de servicio - mantenimiento de datos estadsticos - interaccin entre servicios
Capa de gestin de red: soportada por un sistema de operacin de red (OS) con las siguientes funciones asociadas: - provisin, cese o modificacin de las capacidades de la red para el soporte de servicios a clientes. - control y coordinacin de todos los elementos de la red con su mbito y dominio.
85
Capa de gestin de elementos de red: soportada por un sistema de operacin de elementos de red (OS, MD) con las siguientes funciones asociadas: - mantenimiento estadstico, control y coordinacin 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 gestin. La idea consiste en descomponer las funcionalidades de mayor a menor nivel en bloques reaprovechables (segn las necesidades desde el punto de vista de los operadores).
Servicios de gestin TMN Los servicios de gestin que se definen son del siguiente tipo: - Administracin de abonados. Administracin de encaminamiento y anlisis de digitos. Administracin de medidas y anlisis de trfico. Administracin de la tarificacin. - Gestin de la seguridad de la TMN. Gestin de trfico. Gestin del acceso de abonado. Gestin de circuitos entre centrales y equipo asociado. Gestin de la red de conmutacin. Gestin de equipos en la instalacin del usuario. Gestin del servicio controlado por el abonado. Gestin del sistema de sealizacin por canal comn. Gestin de redes inteligentes. Gestin de la TMN. - Administracin de instalacin del sistema. Administracin de calidad de servicio y funcionamiento de la red - Restablecimiento y recuperacin. - Gestin de materiales. - Programa de trabajo del personal.
Componentes y funciones de gestin De los muchos componentes que define TMN, un ejemplo de componente del servicio de gestin podra ser: - vigilancia de alarmas.
Funciones de gestin Para el caso del componente de vigilancia de alarmas del citado ejemplo se podran utilizar las siguientes funciones: - funciones de informes de alarmas - funciones de informes resumidos de alarmas - funciones de criterios de sucesos de alarmas - funciones de gestin de indicacin de alarmas - funciones de control de registro de alarmas.
86
Gestin de red
6.4 Modelo de informacin

El modelo de informacin utilizado en TMN es el definido por el interfaz Q3 en la semntica de datos (MIBs GDMO). A continuacin se muestra en la figura 6.3 adjunta un esquema con los niveles de estructura de protocolo del punto de referencia Q3.
Aplicacin de gestin ASE especfica de gestin FTAM CMISE CCR ACSE ROSE ACSE Nivel 6 Nivel 5 Nivel 4 Subred 2 802.3 Nivel 1-3
Nivel 7
Nivel OSI de presentacin Nivel OSI de sesin Nivel OSI de transporte Subred 1 X25
CMISE: servicio asociado al protocolo CMI FTAM: gestin y acceso para la transferencia de ficheros ROSE: elemento de servicio de operaciones remotas ACSE: elemento de servicio de control de asociaciones CCR: recuperacin, concurrencia y entrega..
Fig. 6.3 Esquema de capas del interfaz Q3
Los niveles 1 a 3 del interfaz Q3 vienen definidos por el estndar Q.811 que especifica diversas configuraciones de acceso: - CONS1: Para redes X.25 sobre redes pblicas 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.
87
Para los niveles altos, se utiliza la recomendacin Q.812 que define dos tipos de perfiles de protocolo: perfiles para servicios de tipo transaccin y perfiles para servicios de tipo transferencia de ficheros. El nivel de aplicacin suele cubrirse mediante el protocolo CMIP.
6.5 Implementacin fsica de las funciones de la TMN

La implantacin fsica de sistemas de gestin ha seguido una progresin 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 operacin con inteligencia distribuida, ms SNCs centros de gestin de la subred, ms elementos de red inteligentes).
Aplicaciones de gestin de servicio
Aplicaciones de gestin de servicio
MIB
OS de servicio CPN
M A M
OS de servicio PN
MIB A M
DUA M
M
A
MIB M A A
DUA
OS de servicio PN
MIB
OS de servicio CPN
M M
DUA
M DUA
OS de red CPN
DSA
OS de red CPN
DSA
DSA
DSA
OS A de red PN Aplicaciones
Directorio
OS de red PN
A
Aplicaciones de gestin de red
A
Aplicaciones de gestin de red
de gestin de red
OS A de red PN Aplicaciones
MIB
MIB
MIB
de gestin de red
MIB
Fig. 6.4 Esquema de sistemas de gestin de red y servicios
La estrategia de diseo de una TMN depende en gran medida de la topologa y las posibilidades de las redes de telecomunicaciones (TNs), que la TMN deber gestionar. La aproximacin tradicional para proporcionar comunicaciones entre NEs y que los soporten los OSs es disear 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 aproximacin no es la ms econmica. En la figura 6.4 se representan unos sistemas de gestin de proveedores de servicio privados y pblicos (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 operacin y con las bases de datos de gestin (MIBs) de los equipos. Tambin se observa un sistema
88
Gestin de red
de directorios X.500 para el almacenamiento de informaciones de perfiles de servicios y de abonados a la red.
TMN desde M.3100

Red Equipos Punto de terminacion Fragmento TP
top
Elemento gestionado
software
conectividad
Fragmento
de crossconexion
alarmSeverity Assignment profile log
conexion
pruebas
OSI desde las series X.720

logRecord Discriminator eventForwarding
eventLog
Record
alarm Record
Discriminator
stateChange Record
ChangeRecord Record
attributeValue
objectCreation
objectDeletion
Record
Fig. 6.5 Jerarqua de herencia simplificada del modelo GNIM de la TMN
7. reas funcionales de gestin
89
7 reas funcionales de gestin

Se puede definir la gestin de red como la planificacin, la organizacin, la supervisin 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 gestin de red: Supervisin y fallos: conjunto de facilidades que permiten la deteccin, aislamiento y correccin de una operacin anormal. Configuracin: facilidades que permiten controlar, identificar, recoger y proporcionar datos a objetos gestionados, con el propsito de asistir a operar servicios de interconexin. 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 gestin de red y que permiten proteger los objetos gestionados.
Sistema de red Polticas de gestin Control Gestores Interpretan Monitor Recursos
Fig. 7.1 Flujo de informacin de gestin
El esquema de funcionamiento que sigue un sistema de gestin (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 travs de sus agentes, proporcionan la informacin a los gestores de la red. Los gestores, a partir de los parmetros definidos en sus polticas de gestin, actan sobre la red mediante mensajes de control sobre los agentes de los nodos, optimizando el funcionamiento a travs de cambios de configuracin, etc. Este control realizado sobre la red modifica las condiciones del trfico y el ciclo se repite realizando nuevas mediciones sobre los recursos.
90
Gestin de red
Monitoriza estatus y recibe informes de sucesos
Interpreta polticas y toma decisiones
Realiza control de operaciones
Fig. 7.2 Bucle de actividades de gestin
El esquema de funcionamiento general de una plataforma de gestin puede verse en la figura 7.3. En este esquema, el usuario a travs de una interfaz unificada tiene acceso a la informacin procedente de diversas aplicaciones de gestin (gestores). Esto se requiere as puesto que la diversidad de elementos de red procedentes de diferentes fabricantes junto con la enormidad de funciones de gestin definidas por los estndares aconseja el procesado en paralelo.
Interfaz a usuario unificado Presentacin de informacin de gestin de red a los usuarios
Aplicacin de gestin de red
Aplicacin de gestin de red Elemento Elemento de aplicacin de aplicacin
Elemento de aplicacin
Servicio de transporte de datos de gestin
Mdulo de acceso MIB
Pila de protocolos de comunicaciones
MIB
Redes gestionadas
Fig. 7.3 Modelo de referencia de un sistema de gestin de red
91
Los elementos de aplicacin corresponden a funciones diferentes que son aprovechables por las diferentes aplicaciones. El servicio de transporte y las pilas de protocolos implementadas suelen ser tambin de tipo variado dada la complejidad de interconexin de redes que forman los sistemas de comunicaciones actuales.
7.1 Gestin de fallos

La gestin de fallos se ocupa del conjunto de facilidades que permiten la deteccin, aislamiento y correccin de una operacin anormal. El determinar el mximo de informacin sobre los fallos es el elemento fundamental para su buena gestin. La informacin de fallos debe permitir detectarlos y aislarlos. Los fallos: se detectan normalmente ante cambios de estado en los dispositivos.
Estatus y supervisin de red
Usuario
Monitorizacin
Alarmas de dispositivos
Etiquetado de problemas
Seguimiento de problemas dinmico Back-up y reconfiguracin
no
conocido?
Unir a problemas conocidos
Back-up, reconfiguracin Determinacin problema s conocido? no Implementar solucin
Diagnosis y reparacin
Diagnosis y reparacin Monitorizar y verificar correcin no conocido? s Restauracin Actualizar bases de datos Distribuir informes Fin
Recuperacin por la red
Fig. 7.4 Secuencia de operaciones realizadas en un sistema para corregir fallos
Existen una serie de problemas relacionados con la deteccin de fallos. Por ejemplo, fallos no observables que slo permiten detectar efectos laterales, o bien el caso de fallos inciertos, en los que la informacin sobre el fallo puede no ser fiable en cuanto a su fuente.
92
Gestin de red
Por otra parte, tambin existen una serie de problemas en la fase correspondiente al aislamiento de fallos. Puede darse el caso de una deteccin de mltiples fallos por una sola causa e incluso el caso de deteccin de fallos por mltiples causas. En la figura 7.4 se puede observar el proceso seguido por una aplicacin de gestin de alarmas en su recorrido hasta determinar correctamente la causa concreta del fallo y el porqu de las alarmas generadas. Como ejemplos de tecnologas que permiten tratar los fallos de conectividad en redes TCP/IP existen programas como PING o TRACEROUTE. Para la deteccin de fallos se puede utilizar el programa PING, que realiza un sondeo peridico del recurso mediante el protocolo ICMP (echo request). Permite tambin 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 parmetro Time To Live de IP.
7.1.1 Identificacin de fallos en redes de comunicaciones En este apartado se presenta un anlisis introductorio a la identificacin de fallos en redes de comunicaciones. El proceso de gestin de fallos se caracteriza por los siguientes tres pasos: 1) Correlacin de alarmas. 2) Identificacin de fallos. 3) Pruebas de localizacin. En los procesos 1 y 2 se correlacionan los fallos observados, o las alarmas enviadas, y se proponen varias hiptesis de fallo a fin de identificar el fallo. Posteriormente, cada una de las hiptesis propuestas se examina para localizar el fallo de una forma ms precisa. Existen muchos mtodos para llegar a la obtencin del fallo en una red. En este caso se presenta una posible metodologa basada en el anlisis 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 vrtice 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 podra haber causado la alarma. Se define tambin un cluster de alarmas, como el conjunto de alarmas cuyos dominios interseccionan unos con otros.
93
Supongamos que ei emite una alarma ai. Asociaremos esta alarma con todos los objetos ej en el grfico de dependencias con pesos de dependencia pij > W, donde W es un parmetro. 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 variacin del problema de fuente nica. En este caso, se encuentra el camino de coste mnimo desde el vrtice de una fuente en un grfico a todos los otros vrtices en el grfico. 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 consistira en encontrar el camino de coste mximo, que fuera tambin 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 mnimo. 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 grfico de dependencias, tal como se muestra en la figura 7.6.
p1 e1=A p16 p6 e6=L3 p51 p56 e5=C p5 p54 p35 p31 e2=L1
p2
p32
e3=B p34 e4=L2 p4
p3
Fig. 7.6 Grfico de dependencias de la red
94
Gestin de red
7.2 Gestin de configuracin

La gestin de configuracin es un conjunto de facilidades que permiten controlar, identificar, recoger y proporcionar datos a objetos gestionados con el propsito de asistir a operar servicios de interconexin. Entre las tareas relacionadas se puede destacar la definicin de informacin de configuracin en los recursos, la modificacin de las propiedades de los recursos, la definicin y modificacin de relaciones entre los recursos, la inicializacin y terminacin de servicios de red o bien la distribucin de software.
7.3 Gestin 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 estn orientados al servicio, como la disponibilidad, el tiempo de respuesta, y la fiabilidad. En cambio, otros indicadores estn orientados a la eficiencia, como el throughput (caudal, flujo) o la utilizacin. En la figura 7.7 puede observarse el proceso seguido por una aplicacin de gestin de prestaciones o rendimientos hasta encontrar unos parmetros de funcionamiento ptimos en la red.
Violaciones de los niveles de servicio
Peticiones de servicio con parmetros especficos Monitorizacion de red y seguimiento histrico
Evaluaciones de prestaciones
Ficheros con datos histricos
Nivel de servicio adecuado? s Problema conocido? no Diagnosis y formularcin de solucin no s s
no
Resolver con el originante o llamante
Solucin realizable?
Implementar solucin Actualizar directorios y distribuir informes
Fig. 7.7 Proceso de gestin de prestaciones
95
7.4 Gestin de tarificacin

La gestin de tarificacin 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 tarificacin. Entre ellos se pueden destacar: localizacin geogrfica, distancia desde nodo central, zonas temporales (da/semana), descuentos por volumen, precio por paquete, cdigos de rea, rango de extensin por voz, email, etc, identificacin de equipos orientados a datos, etc.
7.5 Gestin de seguridad

La gestin de seguridad est relacionada con la generacin, distribucin y almacenamiento de claves de cifrado, informacin de passwords (contraseas) o bien informacin de control de acceso y autorizacin que debe mantenerse y distribuirse. Es decir, proporciona facilidades para incorporar mecanismos de seguridad contra los ataques a las comunicaciones, como proteccin contra interrupcin del servicio, captura no autorizada de informacin, modificacin de informacin o suplantacin de entidad.
8 Funciones de gestin de la red de sealizacin
97

Las funciones de gestin utilizadas en el SS7 se refieren a procedimientos de control de disponibilidad que permiten reconfigurar la red para desviar el trfico y as poder subsanar mejor los inconvenientes de fallos en nodos y/o enlaces. Adems existen los controles de congestin especficos que permiten evitar en lo posible los bloqueos de la red y las posibles prdidas de informacin correspondientes. Dado que los enlaces de sealizacin se disean para que el trfico que soporten sea menor que la capacidad del enlace (40%), las situaciones de congestin se producen generalmente debido a cadas de enlaces o nodos [RUS1].
8.1 Controles de flujo MTP en la red de sealizacin

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 manipulacin de mensajes de sealizacin y funciones de gestin de red de sealizacin, descritas en la recomendacin Q.701. Las funciones de manipulacin de mensajes de sealizacin conciernen al encaminamiento, la discriminacin y la distribucin de mensajes de acuerdo con el estatus actual de los nodos y enlaces de la red, estn disponibles, no disponibles o congestionados. En los siguientes apartados se har enfasis en las funciones de gestin de red de sealizacin, que se usan para reencaminar trfico a otros enlaces cuando los nodos son inalcanzables, y que pueden dividirse en gestin de enlaces de sealizacin, gestin de trfico de sealizacin y gestin de rutas de sealizacin (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 congestin de mensajes no se asignan dentro del MTP y cualquier decisin para descartar mensajes se toma nicamente a nivel de UP (el descarte podra ser en el nivel MTP slo en caso de falta de memoria fsica). En la opcin nacional con mltiples niveles de congestin y prioridades de congestin, el MTP reconoce mltiples prioridades de congestin y basa sus decisiones de descarte en esas prioridades, de forma separada, adems de cualquier descarte que pudiera haber en el nivel UP. En la opcin nacional con mltiples niveles de congestin, pero sin prioridades de congestin, el descarte slo ocurre en el nivel UP, como en el caso de control internacional.
98
Gestin de red
8.1.1 Gestin del enlace de sealizacin Las funciones de gestin de los enlaces de sealizacin son controlar localmente los enlaces de sealizacin, es decir, activando y desactivando enlaces, y proporcionar la informacin de estatus sobre la disponibilidad de enlaces locales a la funcin de gestin de trfico segn la recomendacin Q.704. Tiene funciones de soporte de informacin y no interviene directamente en el control de congestin. Los procedimientos de gestin 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 sealizacin adyacente. Se definen tres funciones para la gestin de enlaces: - activacin de enlace - restauracin de enlace - desactivacin 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 tambin enva 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 enva 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 restauracin del enlace. La desactivacin se realiza cuando se encuentra al enlace en error y requiere ser emplazado para un alineamiento. Para ello, previamente se desva el trfico a otros enlaces y posteriormente se desconecta.
8.1.2 Gestin del trfico de sealizacin La gestin de trfico de sealizacin realiza el desvo y el control de flujo de trfico en respuesta a fallos de nodo/enlace y a congestin (Q.704). En el caso de no disponibilidad de enlace/ruta o restriccin de ruta, las decisiones de encaminamiento se basan en la informacin de estatus recibida desde las funciones de gestin de rutas/enlaces de sealizacin. El objetivo es mantener la conectividad a todos los destinos requeridos. Los mensajes de gestin de trfico no se propagan a travs de la red de sealizacin SS7, sino que lo hacen punto a punto por la red troncal. La gestin de trfico proporciona los mecanismos para gestionar el desvo del trfico debidos a: - no disponibilidad del enlace de sealizacin - disponibilidad del enlace de sealizacin - no disponibilidad de la ruta de sealizacin - disponibilidad de la ruta de sealizacin - restriccin de la ruta de sealizacin - disponibilidad del punto de sealizacin. Tipos de mensajes involucrados: - Changeover: desva el trfico fuera del enlace cado.
99
- Changeback: se utiliza cuando un enlace cado es restaurado. - Emergency changeover: cuando se inicia un procedimiento de changeover pero el buffer de transmisin no puede leerse. - Forced rerouting: se inicia cuando una ruta a un destino especfico no est disponible. - Controlled rerouting: procedimiento para restaurar el trfico hacia la ruta ms favorable, caso de que haya sido previamente restringida. - MTP restart: restablecimiento de un punto de sealizacin despus de un aislamiento previo del resto de la red. - Management inhibiting: usado por la gestin del enlace para bloquear un enlace de sealizacin 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 funcin de gestin del trfico de sealizacin consistente en el desvo de trfico, en el caso de cada de enlace o de nodo, a uno o varios enlaces. Se describe en la recomendacin Q.704. Existe el procedimiento anlogo para recuperar la situacin inicial de la red (Changeback), descrito en la misma recomendacin.
8.2 Control de flujo de trfico de sealizacin

Se trata de un control de flujo integrado en el nivel MTP para regular el exceso de trfico de control MTP. Cuando se detecta congestin, se advierte a los usuarios para que regulen la carga de sealizacin en los puntos de origen del trfico. La razn de este control es que los enlaces de sealizacin de 64 Kbps podran ver excedida su capacidad por un exceso de trfico. El objetivo consiste en proteger las colas del nivel 2 y por tanto los enlaces de sealizacin. Los controles MTP operan principalmente a nivel 3 MTP. Los procedimientos describen como los puntos de conmutacin (SP) responden a la indicacin de congestin 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 indicacin de congestin MTP-ESTATUS enviadas desde el nivel 3 MTP de la funcin de gestin de trfico de sealizacin a todos los UP conectados. Los UP toman la decisin de reducir el trfico de sealizacin 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 - opcin nacional con prioridades de congestin - opcin nacional sin prioridades de congestin.
8.2.1 Gestin de rutas de sealizacin El objetivo de la gestin de rutas de sealizacin es asegurar que los SP estn informados en cada momento de la disponibilidad de rutas en la red. La gestin de rutas no pertenece a un enlace en concreto (como la gestin de trfico) sino que afecta por entero a un punto de sealizacin. La disponibilidad o no de las rutas, las restricciones de trfico, etc, se comunican a la fuente SP de la ruta
100
Gestin de red
de sealizacin por medio de procedimientos y mensajes explcitos como: TFP, TFA, o TFR. En caso de congestin, se usa el mensaje TFC. Procedimiento TFC En el enlace congestionado, la funcin de gestin de rutas de sealizacin usa el procedimiento TFC para informar a los nodos fuente acerca del estatus de congestin de las rutas de sealizacin y los enlaces afectados, a fin que stos puedan reducir el trfico hacia los enlaces de acuerdo con los mecanismos de control de flujo de trfico. El mensaje TFC informa del estatus de congestin de la ruta a los nodos fuente. Los procedimientos para la determinacin de congestin, o estado de descarte en los enlaces de la red, y cmo estos estados son usados por la funcin de gestin 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 - opcin nacional con prioridades de congestin - opcin nacional sin prioridades de congestin. En la red internacional, las prioridades de congestin de mensajes no se asignan dentro del MTP y cualquier decisin para descartar mensajes se toma nicamente a nivel de UP (el descarte podra ser en el nivel MTP slo en caso de falta de memoria fsica). En la opcin nacional, con mltiples niveles o estados de congestin (S<=3) y prioridades de congestin (N<=3), el MTP reconoce mltiples prioridades de congestin y basa sus decisiones de descarte en esas prioridades, de forma separada, adems de cualquier descarte que pudiera haber en el nivel UP. En la opcin nacional con mltiples niveles de congestin, pero sin prioridades de congestin, el descarte slo 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 gestin de rutas. La ventaja de la gestin de rutas de cluster es que un slo mensaje puede enviarse para direccionar a un grupo entero de puntos de sealizacin, ms que a puntos de sealizacin individuales. Para la gestin 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 gestin 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)
101
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 estn los de transferencia prohibida y transferencia restringida. Transferencia prohibida (Transfer Prohibited, TFP) El procedimiento de transferencia prohibida se utiliza hacia nodos adyacentes para desvo de trfico desde nodos funcionalmente no disponibles. Para dar a conocer la informacin de prohibicin, se envan mensajes TFP a los nodos adyacentes. El procedimiento acta tanto para nodos como para rutas no disponibles. Una vez desviado el trfico hacia otras rutas, si se recupera el enlace o la ruta, puede restaurarse la red hacia la situacin original si se reenruta el trfico a su ruta original mediante un procedimiento de transferencia disponible (TransFer Available, TFA). El procedimiento se describe en la recomendacin Q.704. Transferencia restringida (TransFer Restricted, TFR) El procedimiento de transferencia restringida se utiliza hacia uno o ms nodos adyacentes para el desvo de trfico hacia rutas alternativas (si es posible) en respuesta a una situacin de congestin de trfico. La funcin de gestin de rutas locales utiliza el mensaje TFR para llevar la indicacin a los nodos adyacentes. A la llegada del mensaje, los nodos responden con con un reencaminamiento controlado del trfico hacia una ruta no congestionada. Una vez se ha descongestionado la ruta original, se emplea un procedimiento TFA con el envo de los mensajes correspondientes a los nodos adyacentes para recuperar la ruta original. El procedimiento se describe en la recomendacin Q.704.
8.3 Control nodal MTP

Este control sirve para proteger a la red de congestin nodal (en SPs o STPs), posiblemente a raz 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 trfico. El control nodal puede realizarse a varios niveles del protocolo de sealizacin. Control nodal de nivel 2 MTP El control nodal a nivel 2 de MTP se basa en la recomendacin Q.703. Los controles de flujo a nivel 2 se basan en un control on/off realizado en respuesta a congestin nodal en SPs o STPs. Control de flujo El mecanismo de control de flujo a nivel 2 se activa cuando se detecta congestin en el extremo final del enlace de sealizacin. La notificacin sobre la deteccin de congestin se obtiene mediante el envo peridico de LSSUs (Link Estatus Signal Units) con la indicacin (B) de ocupado al extremo del enlace. En el extremo, se prueba la duracin de la congestin; si persiste, se deja el enlace fuera de servicio y se notifica al nivel 3 de gestin de red de lo sucedido. Bloqueo de procesador La recomendacin Q.703 cubre adems 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 enva un flujo continuo de LSSUs con la indicacin 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
102
Gestin de red
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 comunicacin. Control nodal de nivel 3 MTP La congestin nodal implica que es el propio nodo quien provoca un cuello de botella en la transmisin. El caso de congestin nodal SP o STP se trata en las recomendaciones Q.700 y Q.704, siendo la deteccin dependiente de la implementacin. Se aplican los mismos mecanismos que para la congestin de rutas de sealizacin. UP no disponible En el caso de que un UP remoto sea designado como no disponible (inalcanzable), se para el trfico hacia este UP desde la fuente UP (Q.704). El UP inalcanzable (estado UPU) se sealiza a la fuente SP mediante un mensaje UPU retornado desde donde se ha detectado este estado. El MTP en la fuente SP pasa la informacin UPU al UP afectado va la primitiva MTP-ESTATUS, identificando el destino afectado (Q.701) y UP. Se espera que la fuente UP pare o reduzca la generacin de mensajes hacia el UP de forma apropiada. La recuperacin del UP remoto podra tratarse tambin desde el punto de vista de gestin de fallos y alarmas. Por el momento (recs. 1992), se deja a criterio del UP examinar la disponibilidad. UP en congestin En las recomendaciones Q.704 de 1992 se afirma que el MTP no mantiene informacin de estatus acerca de la disponibilidad de UPs 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 deteccin de congestin en el protocolo MTP, regulando el trfico 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 indicacin de congestin, pasa esa informacin al UP va la primitiva de MTP-ESTATUS (Q.701), que identifica el destino afectado y el estatus de la congestin si se utilizan mltiples niveles de congestin (p.e. opcin nacional). Entonces, el UP reduce el trfico al destino afectado de forma progresiva. Las bases para el descartado por parte de los controles UP es un tema de implementacin sujeto a mltiples variantes de diseo. Los controles UP podran actuar independientemente de cualquier control en MTP, si bien en determinados casos (p.e. una opcion nacional) podra haber redundancias o malfuncionamiento. Bloqueo UP El bloqueo en TUP se describe en la recomendacin Q.724. Los UPs en nodos adyacentes son informados por el control de flujo del usuario y responden parando o reduciendo el tamao del circuito hacia el nodo afectado.
103
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, slo la clase 3 proporciona control de flujo, va un mecanismo de ventana usando crditos. Cuando el SCCP recibe una indicacin de congestin desde el MTP va una primitiva MTP-ESTATUS, hace un broadcast de esa informacin 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 implementacin por parte del fabricante.
8.3.2 Controles de congestin automticos Los controles de congestin automticos (Automatic Congestion Control, ACC) se usan cuando una aplicacin de procesamiento de conmutacin de llamadas es sobrecargada (Q.724 en TUP, Q.764 en ISUP y Q.542). Definen el uso que hace la red de sealizacin en respuesta a la congestin detectada en la aplicacin de procesado de la llamada. En el caso de TUP se pueden utilizar un par de niveles de congestin para advertir a los nodos adyacentes y as reducir la tasa de llamadas dirigida al nodo congestionado. Si se utiliza el protocolo ISUP, se aade un parmetro a los mensajes generados por el nodo de conmutacin. Este parmetro indica el nivel de congestin (1 2) y a su recepcin los nodos adyacentes reducen el trfico hacia el nodo afectado. ISUP tambin define un mensaje de sobrecarga especfico en la rec. Q.763 como una opcin nacional. En Q.764, el protocolo ISUP define una opcin nacional para reducir el trfico en caso de un bloqueo de troncales temporal (TTB) en lo que parece ser una funcin de proteccin de servicio.
8.4 Gestin 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 sealizacin, es la siguiente: Deteccin desde el punto de sealizacin de la cada de uno de sus enlaces. Inicio del Link Status Signal Unit LSSU por el nivel 3 de la capa de gestin. La gestin 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 sealizacin. Cuando se recibe el mensaje, mantiene todas las MSUs (Message Signal Units) para prevenir la transmisin sobre el enlace cado. La gestin del enlace a nivel 3 pasa ahora al proceso de recuperacin del enlace. Pone el enlace fuera de servicio, que inicia cambiando el cdigo del enlace y comenzando el procedimiento de Changeover. Se desva el trfico. El procedimiento de Changeover es invocado por la gestin de trfico del nivel 3. Todos los mensajes no reconocidos en el buffer de transmisin del enlace al punto de sealizacin se transfieren a un nuevo enlace. Cuando se ha completado este procedimiento, se enva el mensaje de Changeover al punto de sealizacin proporcionando el cdigo de sealizacin (SLC). Cuando se recibe por el punto de sealizacin el mensaje, ste transfiere las MSUs que estn todava en el buffer de transmisin del enlace fallido al nuevo enlace. Entonces, se retransmiten las MSUs sobre el nuevo enlace en ambas direcciones.
104
Gestin de red
Para reconocer la finalizacin de la transferencia del buffer y la recepcin del mensaje de Changeover, el punto de sealizacin enva el mensaje de Acknowledgement Changeover al otro punto de sealizacin. Esto significa que ahora puede desviarse el trfico. Una vez que los mensajes han sido retransmitidos y los buffers han sido retransmitidos, el procedimiento de recuperacin de gestin 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 desvo del trfico, el problema del corte del procesador se ha trasladado al nuevo enlace, de forma que ambos enlaces son inaccesibles al punto de sealizacin. La gestin del trfico debe ahora desviar el trfico fuera de los enlaces cados y buscar enlaces alternativos.
8.5 Arquitectura de gestin de red de sealizacin

Las recomendaciones descritas se basan en la congestin de la red de sealizacin y en sus controles, dejando aparte los controles de la parte de aplicacin de procesamiento de la llamada. Es decir, la parte UP se describe como red de sealizacin. Est an poco desarrollada la relacin entre la UP y la parte de aplicacin de procesamiento de la llamada (AP). Slo se han empezado a utilizar tcnicas como el tema UPU. Cada fabricante resuelve de forma libre la relacin o interfaz entre UP y conmutacin de llamada (AP) en caso de congestin o fallo. El conjunto de los mecanismos de gestin 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 restauracin del sistema puede ser compleja o incluso llegar a ser imposible. Los mecanismos de gestin propuestos tampoco permiten la descongestin en el caso de producirse bucles sin fin en la red. Por esto es recomendable el uso de una red de gestin (TMN) especfica, que podra basarse en el protocolo CMIP o bien en tcnicas de desarrollo ms reciente como es CORBA.
9. Gestin de redes virtuales
105
9 Gestin de redes virtuales

El uso cada vez ms frecuente de elementos de red que actan a niveles superiores est permitiendo un auge de la gestin basada en la configuracin de redes virtuales para obtener mejores rendimientos sobre el trfico circulante entre los nodos.
9.1 Introduccin
Una VLAN puede entenderse como un grupo de terminales de usuario, quizs en mltiples segmentos de LAN fsicos, que no estn restringidos por su localizacin fsica y que pueden comunicarse como si estuvieran en una LAN en comn. 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 Estndares de VLAN

Aparte de las mltiples soluciones propietarias implementadas, existen dos estndares propuestos por el IEEE para redes VLAN. Estos son el IEEE 902.10 y el IEEE 802.1Q. Otros estndares 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 estndar para el control de puentes, conmutadores y el estndar IEEE 802.1p que aade importantes funcionalidades de filtrado en VLAN.
9.3 Gestin de red en VLAN

El despliegue de redes conmutadas/VLANs requiere de nuevas perspectivas para la introduccin de una gestin de red adecuada. Existen un par de estndares de gestin 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 jerrquicamente distribuidas que utilizan los entornos SNMP/RMON. En entornos basados en LANs, RMON ayuda a los gestores de red a determinar cmo segmentar mejor sus redes y hacer un seguimiento de quin est comunicando con cualquier otro. A partir de la
106
Gestin de red
emisin de eventos especiales, un gestor de red puede identificar los usuarios que utilizan ms 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 estndares de comunicacin abiertos y de tener que proporcionar seguridad distribuida. Los estndares de seguridad se basan en los protocolos ISAKMP y Oakley que son competidores para establecer una gestin de claves en Internet y que son considerados por el grupo de trabajo Ipsec (IP Security) del IETF. Otra solucin 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 computacin remota. La seguridad distribuida separa la autentificacin de usuario y la autorizacin del proceso de comunicaciones y crea una nica posicin central para datos de autentificacin de usuario.
10. Gestin de la red B-RDSI
107
10 Gestin de la red B-RDSI

En este captulo se procede a dar una visin general de este tipo de redes describiendo los modelos de gestin establecidos en la red digital de servicios integrados de banda ancha [MIN1, SCH1]. El modelo establecido de RDSI-BA se basa en la conmutacin 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 diseo, como en el software que se debe utilizar, como en la gestin 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 mviles. ATM (Asynchronous Transfer Mode) es la clave de la versatilidad de la red: se basa en el envo de un flujo continuo de celdas, tanto en la interfaz usuario-red (UNI) y en los enlaces, como en los nodos de conmutacin y/o multiplexacin. ATM permite adems emplear una nica interfaz para diferentes tipos de usuarios con diferentes necesidades de servicio. ATM es un mtodo de comunicacin orientado a conexin sin control de flujo ni recuperacin de errores, que permite agrupar canales virtuales para configurar un camino virtual. A continuacin se describen las capas que conforman la B-RDSI. La capa fsica (ITU-T I.432) es la encargada del correcto transporte de celdas ATM y de la adaptacin al sistema de transmisin (ATM, SDH, G.703). Se descompone en dos subcapas con las siguientes funciones asignadas: una subcapa de convergencia de transmisin (TC), que permite la daptacin de la tasa de celdas a la capacidad del sistema de transmisin, generacin y verificacin del HEC, delimitacin de celdas ATM, adaptacin a la trama de transmisin (ATM, SDH, G.703) y generacin/recuperacin de tramas de transmisin. Existe una segunda subcapa de medio fsico (PM), que trata aspectos relativos a la correcta transmisin y recepcin de los bits sobre el apropiado medio fsico, y se ocupa de la conversin electro-ptica si el medio es fibra ptica. La capa ATM se encarga de la conmutacin y multiplexacin de celdas. Es una capa independiente del medio fsico, comn para todos los servicios y mtodos de transmisin. Tiene las siguientes funciones: controla flujo en UNI (User Network Interface) si se usa el GFC, extrae/aade cabeceras para/desde AAL, tambin 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 adaptacin se ocupa de adaptar informacin de cada clase de servicio al flujo de celdas ATM. Se descompone en las dos subcapas siguientes: una subcapa de convergencia (CS), todava
108
Gestin de red
dependiente del servicio con las clases A, B, C y D, y una subcapa de segmentacin (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 informacin que conforman la estructura de una celda ATM. Leyenda: GFC: asigna prioridades a teleservicios segn la QOS. VPI/VCI: identifican conexin. Asociados a la funcin de encaminamiento. PTI: identificacin de la carga til. RES: no especificado. CLP: indicacin de prioridad de prdida de celdas (0/1 baja prioridad). HEC: deteccin y correccin de errores en cabecera. GFC/VPI VP VC VC
PTI RES CLP
VPI VC
HEC (Chequeo errores cabecera) Tipos de celdas
Fig. 10.1 Estructura de celda ATM (5 + 48 bytes)
Plano de gestin Plano de control

Protocolos y funciones de capas superiores
Plano de usuario
Protocolos y funciones de capas superiores
HL CS SAR
Gestin de capas Gestin de plano
Capas de adaptacin ATM

Capa ATM Capa fsica
TC PM
Fig. 10.2 Estructura de niveles en la red B-RDSI
109
A Requerida (Circuitos) Constante (CBR)
C No requerida (paquetes)
Variable (VBR) Sin conexin Datos X.25 y sealizacin LAN
C R I T E R I O
Relacin temporal entre fuente y destino Tasa de bits Modo de conexin
Orientada a la conexin Voz 64 Kbps Video CBR Audio video VBR y
Fig. 10.3 Tipos de servicios en la red B-RDSI
Las clases de servicio definidas son las siguientes: vdeo de baja calidad con codificacin CBR (comprimido a 2 Mbps); vdeo estndar CBR (34 Mbps) o VBR (2 a 10 Mbps); vdeo extendido VBR (10 a 34 Mbps); y, finalmente, vdeo de alta calidad: VBR (70 a 140 Mbps) y CBR (comprimido a 20 Mbps). En cuanto a las capas de adaptacin, 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 sealizacin; y, finalmente, AAL 5 con servicios C y D (ms simple y eficiente que el anterior). SB B-ET1 TR2 TB TR1 UB
UNI
ET2 B-ET2 R B-TA SB TR2 TB TR1 UB
Fig. 10.4 Interfaces definidas en B-RDSI
La arquitectura definida en la B-RDSI contiene diversss interfaces siguiendo la misma filosofa 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
Gestin de red
Las interfaces en SB y TB deberan soportar todos los servicios RDSI. Las funciones en TR1 (capa fsica) son de terminacin de lnea, de aspectos de transmisin hasta dependencias de usuario y de OA&M. Respecto a las funciones asignadas al TR2 (capa fsica y superiores), existen las de multiplexacin/concentracin de trfico, delimitacin de celdas, almacenamiento de celdas ATM, CAC/UPC, manejo de protocolos de conmutacin, conmutacin 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 conmutacin); un VCI identifica una conexin (canal virtual) incluida en un VP sobre el UNI o el NNI; un circuito virtual (VCC) es una concatenacin de VCLs entre extremos de la conexin donde se genera y procesa la cabecera de las celdas de esa conexin; un trayecto virtual (VPC) es una concatenacin de VPLs entre terminadores de VPLs (VPTs) donde se conmutan los VCLs (cambian los VCIs).
10.1 Introduccin a la gestin de la red B-RDSI

Los niveles de calidad de servicio exigidos en una red de banda ancha (B-RDSI) hacen necesaria la introduccin de determinados mecanismos de gestin de red (NMC) que, de forma distribuida, interacten con los distintos elementos de red tales como los conmutadores ATM. Los sistemas de gestin 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 trfico muy sensible al retardo, jitter, o bien la infraestructura de conmutacin extremo a extremo de forma muy rpida. Para este fin, el ATM Forum cre un modelo de gestin ATM de cinco capas y unas funciones OAM (Operations, Administration and Maintenance) que distribuyen la informacin de gestin por la red ATM. Este modelo de gestin extremo a extremo permite la interaccin tanto de redes pblicas como de redes privadas. El modelo tambin 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 gestin tardar aos en poder completarse. De momento, el ATM Forum ha definido el ILMI (Interim Management Interface) que se incluye en la recomendacin UNI (User-Network Interface). El ILMI utiliza una conexin virtual ATM preestablecida con UNI para comunicarse conmutador a conmutador y con una aplicacin de gestin va mensajes SNMP. Sin embargo, el ILMI se limita a gestionar interfaces entre redes y no distribuye inteligencia de gestin a travs 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 travs de la interfaz Q3 normalizada por la UIT y por el ETSI. Asimismo, se definen cinco interfaces de gestin (desde M1 a M5) que permiten monitorizar y controlar extremo a extremo los diferentes elementos de la red. En el caso de gestin ms normal, de conmutadores ATM, interesarn, 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 definicin de bases de datos (tipo MIBs)
111
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 gestin no es extremo a extremo. El ATM Forum tardar an tiempo para la especificacin 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 prximos aos se completarn los protocolos de gestin de la red ATM, pero no tanto desde el punto de vista de SNMP o CMIP sino de definicin de las celdas OAM. Ser necesaria una arquitectura distribuida inteligente que gestione la red, de forma que pueda reconfigurarse dinmicamente en caso de fallos en enlaces, o negociar el ancho de banda para determinados servicios, configurar segn niveles de congestin, etc. El forum est ahora en proceso de especificar diversos tipos de celdas OAM de 53 bytes con funciones especficas, tales como gestin de fallos, gestin de prestaciones, de trfico y funciones de activacin/desactivacin para los casos anteriores. Estas celdas permitirn realizar gestin de las conexiones extremo a extremo as como reducir el nmero de bases de datos (MIB) y las cargas de sealizacin en la red. A continuacin, se muestran como ejemplo algunas de las funciones de gestin de red de banda ancha ms representativas. Es el caso de crear un abonado CBDS (servicio de datos de banda ancha sin conexin) donde el NMC asocia el nmero de abonado E.164 y el identificador de acceso fsico. Entonces, el NMC de banda ancha: - debe encontrar la ruta en la red a usar en la conexin, - 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 conexin.
112
Gestin de red
Centro de gestin de red privada de BA

M3 (SNMP, CMIP,...)
Sistema de gestin de la red portadora pblica Agente

M5 (SNMP, CMIP,...)
Centro de gestin de red pblico de BA Agente
Agente
M1(Q3)
M2 (Q3)
M4 M4
Usuario
UNI ATM privado ILMI (SNMP/AAL) UNI ATM pblico RDSI BA UNI ATM pblico Agente M4(Q3) M4
Agente Conmutador ATM UME

RDSI BA Usuario pblico
Agente
Agente
Red ATM privada Red ATM pblica Red ATM pblica ILMI ILMI (SNMP/AAL) (SNMP/AAL) UME UME
UME
UNI ATM pblico
RDSI BE Usuario pblico Red privada local
Agente Usuario Conmutador ATM

ILMI (SNMP/AAL)
UME
Usuario Usuario
Usuario
Fig. 10.5 Esquema de interfaces de gestin de red B-RDSI
Si existe algn problema como los relativos a cadas de enlace. El NMC debera: - detectar dicho enlace ATM, - encontrar todas las conexiones que estaba usando este enlace, - buscar una ruta alternativa en la red para cada conexin 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 gestin de banda ancha.

La UIT-T (o ITU-T) define una serie de interfaces X, F, Q3, QX para la gestin de la arquitectura fsica en la red de gestin de telecomunicaciones (TMN). De entre ellas, la ms importante es la interfaz Q3. Todos los modelos de objetos especficos en Q3 se basan en informacin de gestin genrica definida en las series de recomendaciones X.700 y M.3100 de UIT-T. Las reas funcionales cubiertas por esta interfaz (Q3) estn relacionadas con la gestin de abonados, gestin de trfico y gestin de recursos del sistema.
10.2.1 Interfaces definidas por el ATM Forum De manera simultnea, el ATM Forum define cinco interfaces de gestin denominadas de M1 a M5, que permiten monitorizar y controlar las conexiones extremo a extremo en redes ATM.
113
- Interfaz M1 (Q3) Define la interfaz entre el sistema de gestin de una red privada y la estacin final ATM. - Interfaz M2 (Q3) Define la interfaz entre el sistema de gestin de una red privada y una red corporativa ATM. - Interfaz M3 (X) Define la interfaz entre la gestin de una red privada y el sistema de gestin de la red pblica. - Interfaz M4 (Q3) Define la interfaz entre la plataforma del sistema de gestin de red y la red pblica ATM. - Interfaz M5 (X) Define la interfaz entre plataformas de sistemas de gestin de redes pblicas distintas.
10.3 ATM Forum

El ATM Forum es una organizacin internacional sin nimo de lucro que trata de acelerar la cooperacin industrial en tecnologa ATM. Sus recomendaciones y especificaciones son seguidas por los principales fabricantes de equipos ATM y constituyen un estndar de facto en esta tecnologa. Las especificaciones propuestas por este ATM Forum se complementan en gran medida con las recomendaciones generadas por la UIT. Para la gestin 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 conexin virtual ATM en el User Network Interface (UNI) para comunicar con una aplicacin de gestin usando mensajes SNMP. Cada conmutador ATM, o sistema final, y cada red ATM que desarrolle una red privada o pblica UNI debe tener una entidad de gestin UNI (UME) que soporte la MIB ILMI. La UME reside entre el conmutador y la red o entre una red privada y una red pblica. Es la responsable de mantener datos de gestin y responder a comandos SNMP recibidos sobre el UNI ATM a travs del ILMI. De igual forma que en una aplicacin basada en SNMP, estos mensajes se envan a la red va 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 adaptacin AAL 3/4 o AAL 5. Los tipos de informacin de gestin que estn 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
114
Gestin de red
10.3.2 Celdas OAM Los sistemas de gestin de redes ATM en un futuro van a utilizar celdas OAM para su gestin. El frum est en proceso de definir una serie de celdas OAM (de 53 bytes) con funciones especficas tales como: gestin de fallos, gestin de prestaciones, de activacin y desactivacin (rec. UNI 3.1), y otras nuevas como, por ejemplo, para la gestin de trfico: (Resource Management) RM (rec. UNI 4.0). Tipo de celda OAM (UNI) Gestin de fallos Tipo de funcin OAM AIS FERF Bucle de celda OAM Comprobacin de continuidad Monitorizacin directa Envo de informes en sentido contrario Monitorizacin/Reporting Monitorizacin de prestaciones Comprobacin de continuidad Celdas de gestin de recursos (RM)
Gestin de prestaciones
Activacin/desactivacin
Gestin de trfico
10.4 IETF en ATM

El grupo IETF especifica una MIB para definir y desarrollar los objetos de gestin necesarios usando el protocolo SNMP estndar para gestionar dispositivos ATM. 10.4.1 AToM: RFC 1695 Este documento especifica un estndar para la comunidad Internet que permite su uso para gestin 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 informacin de gestin ATM. En general, la IETF MIB puede incluir la MIB II y la base de datos especfica de ATM, ATM MIB.
10.5 Tendencias y anlisis comparativo entre estndares de gestin ATM

Actualmente las funciones de gestin que estn disponibles en los equipos ATM que presentan los distintos fabricantes distan mucho de las que debieran utilizarse para un funcionamiento ptimo en
115
prestaciones. Los equipos ms avanzados basan su gestin en estndares 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 todava completamente las funcionalidades de gestin, existen diversas opciones segn cada fabricante: a) Uso de sistemas de gestin propietarios: pueden llegar a tener ms funcionalidades que los estndares de facto abiertos definidos, como por ejemplo por ATM Forum; sin embargo, no son compatibles con otros equipos lo que condiciona la evolucin 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 gestin si no estn debidamente actualizados. Pueden ofrecer funciones propietarias complementarias de gestin si es necesario y si se tiene un buen soporte tcnico. c) Uso de otros sistemas abiertos, CMIP/CORBA: actualmente no hay solucin disponible comercialmente en redes ATM si bien estn empezando a consolidarse recomendaciones para su uso en redes TMN (ITU). Se trata de sistemas complejos, con gestin distribuida y que formarn parte de los sistemas de gestin en un futuro prximo. 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 gestin en redes ATM.
10.6 Control de trfico en redes ATM

La gestin de trfico permite a la red ofrecer una calidad de servicio en cada conexin individual, activar nuevas conexiones de acuerdo con una optimizacin de los recursos existentes en la red y protegerse contra la congestin. 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 conexin, el control de polica que garantiza el cumplimiento del contrato (UPC), tambin la disponibilidad de recursos para incorporar una nueva conexin (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 parmetros objetivos, y por tanto medibles, que caracterizan el grado de servicio que ofrece la red al usuario del servicio. Estos parmetros han de ser medibles. En la recomendacin UNI 4.0 (Interficie usuario-red) del ATM Forum, la calidad de servicio se define por seis parmetros: cuatro de ellos hacen referencia a la transparencia semntica (la informacin 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).
116
Gestin de red
- Parmetros relativos a la transparencia semntica a) Tasa de error de celda (Cell Error Rate, CER) CER = (Celdas errneas)/(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)/(Intrvalo temporal) d) Tasa de bloques con errores severos (Severely errored Cell Block Rate, SECBR) SECBR = (Bloques de celdas con errores severos)/(Nmero de bloques de celdas transmitidos). - Parmetros relativos a la transparencia temporal a) Retardo mximo de transferencia de celda (Maximun Cell Transfer Delay, maxCTD) Retardo mximo extremo a extremo en ausencia de trfico. b) Variacin 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 conexin es la prioridad de prdida de celdas. Un usuario puede pedir dos niveles de prioridad de prdida de celdas para una conexin 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 parmetros de trfico para los dos flujos de celdas. Normalmente, esto se hace especificando un conjunto de parmetros de trfico por trfico de alta prioridad (CLP = 0) y un conjunto de parmetros de trfico para todo el trfico (CLP = 0 o 1). Basndose en esta divisin, la red puede asignar los recursos ms eficientemente.
10.6.2 Parmetros de trfico Los parmetros de trfico, junto a la calidad de servicio, se utilizan para definir una conexin ATM. Los parmetros de trfico definen la forma que una fuente puede introducir trfico en la red a travs de una conexin virtual. Se definen a continuacin: a) Tamao mximo de rfaga (Maximum Burst Size, MBS) Especifica el tamao de la rfaga 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 mxima de introduccin de celdas en la red. PCR = 1/T donde T es la distancia mnima entre celdas. c) Tasa sostenida de celda (Sustainable Cell Rate, SCR) Especifica la tasa promedio de introduccin 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 mnima de celda (Minimum Cell Rate, MCR) Especifica la tasa mnima de introduccin de celdas en la red.
117
10.6.3 Descriptores de trfico Los descriptores de trfico de una conexin describen las caractersticas de una conexin mediante: a) Un conjunto de parmetros de trfico de la fuente. b) Una definicin de conformidad. c) La tolerancia a la variacin del retardo de la celda (Cell Delay Variation Tolerance, CDVT). A continuacin se describe la relacin entre las categoras de trfico definidas en ATM respecto de los parmetros 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 Parmetros de QoS aplicables a cada categora de servicio ATM
10.6.4 Mecanismos de control de trfico El control de trfico son el conjunto de acciones que adopta la red para evitar las condiciones de congestin. La gestin de trfico en ATM se describe en las recomendaciones I.371 y en el ATM Forum Traffic Management 4.0.
10.6.4.1 Control de admisin de conexiones, (Connection Admission Control, CAC) El control de admisin de conexiones acta cuando un usuario pide una nueva conexin y tiene que especificar (explcitamente o implcitamente) las caractersticas de la conexin en los dos sentidos. El usuario escoge las caractersticas del trfico seleccionando una calidad de servicio entre las categoras de servicio que proporciona la red. 10.6.4.2 Control de parmetros de usuario/red (Usage/Network Parameter Control, U/NPC) Una vez se ha aceptado una conexin por le CAC, la funcin de control de utilizacin de parmetros (UPC) de la red monitoriza la conexin para determinar si el trfico cumple el contrato de trfico. El propsito principal del UPC es proteger los recursos de la red de la sobrecarga por parte de una conexin que podra afectar negativamente la calidad de servicio en otras conexiones, detectando las violaciones de los parmetros asignados y adoptando las medidas apropiadas. La localizacin 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.
118
Gestin de red
Otras funciones de control adicionales son el control de prioridad, ya comentado, el alisado de trfico, los mecanismos de gestin de recursos de red, o bien los controles de realimentacin.
10.7 Funciones de control de congestin

Se denomina congestin 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 congestin es un problema global, que se da en el nivel de red como consecuencia del trfico agregado de varias fuentes sobre un enlace o router de baja capacidad. A diferencia de la congestin, el control de flujo es una circunstancia que slo puede darse en conexiones punto a punto (es decir, a nivel de enlace o a nivel de transporte). Algunos de los parmetros que permiten detectar la presencia de congestin pueden ser los siguientes: - porcentaje de paquetes descartados - longitud media de las colas en las interfaces de los routers. - nmero de paquetes que dan timeout y se retransmiten (no debidos a errores) - retardo medio por paquete - desviacin media del retardo por paquete. El trfico a rfagas es la principal causa de congestin; por eso el control de congestin suele utilizarse slo en caso de trfico tipo ABR. Entre los mecanismos de control de congestin existentes est el alisado de trfico (traffic shaping) que permite establecer unos mrgenes mximos al trfico de rfagas. El de vigilancia de trfico o funcin policia (traffic policing) realiza una labor de monitorizacin o seguimiento del trfico introducido por el usuario en la red para verificar que no excede el perfil pactado. El leacky bucket permite al host enviar rfagas, 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 conexin con un call setup request. Durante la llamada, se define el valor para un conjunto de parmetros 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 mnimo MCR (minimum Cell Rate) y un PCR (Peak Cell Rate). La transmisin de las celdas de datos est precedida por la transmsisin de celdas RM Rresource Management Cell). La fuente continuar enviando celdas RM despus de un cierto nmero de celdas de usuario, y ms 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 sita la tasa permitida (ACR) en el campo CCR (Current Cell Rate) de la celda RM, y la tasa a la cual deseara transmitir las celdas (usualmente el PCR) en el campo ER (Explicit Rate). La celda RM viaja a travs de la red, dando a los conmutadores la informacin que contiene sobre las conexiones ABR. Los conmutadores tambin tienen que decidir a la vez cmo reducir el valor del campo ER, o si poner el bit CI (Congestion Indication) a 1. Los conmutadores que slo soportan el mecanismo basado en el bit EFCI (Explicit Forward Congestion Notification) ignorarn el contenido de la celda RM. Los conmutadores pueden generar opcionalmente un nmero controlado de celdas RM en el camino hacia atrs adems 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.
119
Cuando la celda llega al destino ste debe cambiar el bit de direccin 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 congestin. Mientras que las celdas RM viajan a travs de la red, cada conmutador debe examinar la celda y determinar si puede soportar la tasa ER para su conexin. 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 informacin de los anteriores conmutadores donde ha pasado la celda RM se perdera. Los conmutadores deben intentar modificar el ER slo en las conexiones cuello de botella ya que esto ofrece una justa asignacin del ancho de banda. Los conmutadores tambin deben modificar el contenido de ER cuando van hacia delante o hacia atrs, pero no en ambos. Cuando la celda RM llega a la fuente, sta debe reinicializar la tasa, ACR, basada en la informacin que llevaba la celda RM. Si el indicador de congestin 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 congestin est activado (CI = 1) entonces la fuente debe disminuir su ACR en una proporcin igual o ms grande que una porcin de su actual ACR. El tamao tambin 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 va para notificar la congestin los conmutadores ATM es poner a 1 el bit medio del campo PTI (Payload Type) de la cabecera en las celdas de datos que envan al causante de los problemas.
10.7.1 Control de flujo El ATM Forum ha adoptado el esquema basado en tasa como estndar 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 (nmero de variables utilizadas en el algoritmo constante e independiente del nmero de sesiones que cruzan el puerto). - algoritmo de espacio ilimitado (el espacio depende, normalmente de forma lineal, del nmero de conexiones). Los algoritmos de control de flujo de espacio constante son importantes en las redes actuales, ya que si alguien quiere tener tanto trfico en ATM como trfico TCP, la dependencia del nmero 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
120
Gestin de red
cada puerto de salida de cada conmutador un parmetro para delimitar la cantidad de sesiones del puerto.
10.8 Recuperacin en redes ATM

En este apartado se detallan los cambios realizados en el diseo de redes ATM para que adopten un alto grado de transparencia al usuario frente a roturas de cables.
Proteccin de redes Trata de los principios bsicos de asignacin de recursos dedicados para proteccin y la distincin entre proteccin 1+1 y 1:1. Concepto de agrupacin de caminos virtuales que comparten la misma ruta fsica para reducir el el procesado de encabezamiento durante la proteccin de la conmutacin.
Redes reconfigurables Coordinacin en la restauracin de redes usando un control centralizado. Slo existen soluciones propietarias.
Redes autorecuperables Se describen tres tcnicas que se basan en la asignacin simultnea de rutas y capacidades. Otra opcin consiste en permitir una plataforma tecnolgica diferente situada usualmente en un nivel ms bajo al de la jerarqua de transporte para asumir la responsabilidad de la continuidad de servicio en el caso de fallos.
10.8.1 Mecanismos de recuperacin ATM alternativos Mecanismos que se basan en la recomendacin ATM Network survivability architectures and mechanisms. Q.F/13. Nov. 1996. (*)
Proteccin Se ocupa de la asignacin de una ruta alternativa con asignacin de ancho de banda dedicado. En el caso de un evento inesperado, un protocolo de gestin distribuido permite realizar la conmutacin.
Restauracin Podra realizarse bajo los auspicios de un control centralizado (red reconfigurable) o un protocolo de control distribuido con procedimientos de gestin de redes autorecuperables. En ambos casos, los recursos podran ser semidedicados donde la ruta alternativa sea predeterminada, pero el ancho de banda asignado sea por demanda siguiendo la deteccin de fallos. Tambin, en ambos casos, la ruta y el ancho de banda podran asignarse en tiempo real (por demanda).
121
Recursos Dedicados Proteccin de redes Redes reconfigurables Redes autorecuperables X
Semidedicados
Por demanda
Control Central
Control distribuido
Gestin distribuida X
Tabla 10.2 Arquitecturas de recuperacin ATM
Un rasgo distintivo lo constituye el hecho de que se requiere menor capacidad sobrante en mtodos de restauracin que en los de proteccin. El control distribuido se aplica sobre procedimientos de establecimiento de conexiones con celdas de sealizacin del plano de control, mientras que la gestin distribuida hace uso de mensajes en el plano de gestin en forma de celdas OAM.
10.8.2 Redes de proteccin ATM Las redes de proteccin son las que disponen de los niveles de fiabilidad ms elevados; sin embargo, suelen ser las ms caras, dado que recursos como el ancho de banda y los caminos/canales virtuales (VPI/VCI) son dedicados ms que compartidos. Por otra parte, la preasignacin de rutas y recursos permite que los protocolos de gestin distribuida sean muy simples de usar en el caso de un fallo en la red. La proteccin de conexiones de red (NCP) puede aplicarse extremo a extremo o bien a un segmento (Sub-Network Connection Protection, SNCP). Para propsitos de control, los segmentos protegidos y los no protegidos se alinearian con flujos apropiados de operaciones y mantenimiento (OAM). El protocolo de conmutacin de proteccin VP/VC se ha especificado para arquitecturas de proteccin punto a punto dentro de dominios NCP y SNCP (*). El protocolo podra 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 sealizacin en el caso de sistemas de mltiples conexiones.
10.8.3 Redes reconfigurables Las redes reconfigurables permiten la restauracin de conexiones mediante sistemas de gestin de red centralizados (NMS). Podran explotar rutas alternativas, preplanificadas, o mantenerlas dinmicamente de acuerdo con la informacin de estado de la red actual. Adems resulta una tarea simple el priorizar el reencaminamiento de conexiones a fin de asegurar que aquellas con aplicaciones crticas
122
Gestin de red
sean restauradas con mayor rapidez que los servicios que son tolerantes de prdida de datos temporales. Sin embargo, existen tres causas de ralentizacin 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 asignacin del ancho de banda - comunicacin descendente entre el NMS y los nodos de la red, seguidos por la reconfiguracin de los elementos de red apropiados. La restauracin centralizada (generalmente propietaria) suele ser lenta e inapropiada en BISDN. Sin embargo, la gestin de fallos suele ser problemtica entre equipos de diferentes fabricantes.
10.8.4 Redes ATM autorecuperables Este tipo de redes explota la gestin distribuida o la funcionalidad de sealizacin del plano de control, e incorpora asignacin de recursos por demanda o bien semidedicada. Se describen a continuacin tres mdodos de redes autorecuperables por demanda. Autorecuperacin 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 codificacin NSAP para direcciones E.164, el protocolo de encaminamiento PNNI puede tambin emplearse en redes pblicas. La especificacin PNNI describe cmo 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 segn los estados topolgicos en un entorno de intercambio de informacin peridico entre nodos. Autorecuperacin con soft PVCs/PVPs En este caso, cuando ocurre un fallo, la conexin se corta hasta los extremos de los conmutadores ATM, seguidos de instigacin automtica de reencaminamiento, aunque no hay garantas de xito. Es propio de General DataComm (APEX). Algoritmos de restauracin distribuida (DRAs) Es una descripcin genrica aplicada a protocolos que dinmicamente restauran la capacidad de transporte que ha cado, y originada en redes SONET/SDH. La idea de DRAs es encaminar trfico rpidamente (< 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 distincin entre protocolos de transporte que operan en caminos, y sealizacin de control usada en circuitos individuales.
10.8.5 Autorecuperacin con backup de VPs semidedicados Las rutas de backup que son disjuntas de las rutas de trabajo son preasignadas. Sin embargo, la capacidad sobrante podra compartirse para restauracin desde el tipo ms comn de fallos, como single spans. La principal ventaja de esta aproximacin es que la capacidad sobrante puede ser compartida entre otros VPs de backup, reduciendo los costes.
123
10.8.6 Restauracin multicapa El principal problema de la restauracin a bajo nivel es que aunque la capa SDH podra utilizarse para ser usada para reconfigurarse desde roturas de cable y fallos en equipos SDH, no sera efectiva para resolver fallos a nivel de ATM. Se plantea pues una restauracin multicapa.
Mecanismo de recuperacin Proteccin dedicada Semi dedicada
Aplicaciones Misin crtica en datos. Telemedicina Misin casi crtica. Interruptible Residencial. Misin no crtica en datos Residencial. Misin no crtica en datos
Retardo Objetivo es 60 ms < de 10 seg.
Coste Alto (reserva de capacidad ms VPI/VCIs) Medio (capacidad compartida ms VPI/VCIs) Bajo (slo capacidad) Relacionado con sofisticacin de NMS
Viabilidad tcnica La conmutacin rpida se basa en VPG Se basa en VPG y asignacin de capacidad Basada en sealizacin estndar. Viable, pero limitado a sistemas propietarios.
Autoredial
De 10 segs a minutos. Varios minutos
Centralizada (con NMS)
Tabla 10.3 Tabla mecanismos de recuperacin en B-RDSI
11. Gestin de redes de comunicaciones mviles
125
11 Gestin en redes de comunicaciones mviles

La gestin de redes de comunicaciones mviles se beneficia de la alta sofisticacin de los terminales mviles y de las altas prestaciones en general de todos los elementos de sus redes. Esto permite integrar una red de gestin 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 Introduccin a las comunicaciones personales

La progresiva integracin 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 clculo y ofrecen por consiguiente nuevos servicios reciben el nombre de redes inteligentes. En el caso de las comunicaciones mviles, estos nuevos servicios se ofrecen como facilidades y comnmente se conocen como comunicaciones personales. En este captulo se da una primera visin 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 conexin del terminal a la red (Fig. 11.1). En las redes de comunicaciones mviles, los terminales no disponen de punto fijo de conexin y se comunican dinmicamente a travs 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 asociacin entre el terminal y el usuario todava se mantiene. En el entorno UPT (Universal Personal Telecommunication), la movilidad da un paso adelante: la asociacin fija entre el usuario y el terminal, tanto en redes fijas como mviles, se rompe, el usuario nicamente se identifica con la red mediante un nmero personal conocido por el nmero 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 telecomunicacin a los que est abonado. La evolucin 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 estndares de ETSI GSM (Fig. 11.2). Esta nueva recomendacin DCS1800 aprobada en 1991 para Europa era un sistema celular digital a 1800 MHz que incorporaba una serie de servicios de telefona personal. En Amrica del Norte se introdujo un sistema equivalente, ms orientado a la provisin de servicios personales, denominado PCS (Personal Communication Services) que permita el acceso por radioenlace, la movilidad del terminal y la movilidad personal.
126
Gestin de red
En paralelo a la iniciativa britnica, el ETSI decidi auspiciar el estndar UPT (Universal Personal Telecommunication) en Europa. La finalidad que se persegua con este nuevo estndar era desarrollar inicialmente los conceptos de movilidad personal y nmero personal de abonado. stos rompieron la asociacin fija que haba entre terminal y usuario, al permitir un alto grado de movilidad en redes fijas y mviles. Tambin existieron iniciativas dentro del programa RACE II (1992) con el proyecto Mobilise (R2003) que defina el concepto de PSCS (Personal Services Communication Space) como una extensin 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 mviles con servicios PCS (Personal Communication Services). En la actualidad, en Europa el trmino PCN (Personal Communications Network) ha sido desplazado por UPT y la contraposicin entre el sistema europeo y el americano se plantea en trminos de UPT/PCS (UPT est tambin siendo normalizado por el ITU). En el caso de PCS, adems de la funcionalidad recogida en UPT, se aaden otras de carcter fsico de la red. La evolucin de estos sistemas PCS/UPT junto con su interconexin/integracin con redes preexistentes es un paso intermedio hacia el concepto de sistemas de la tercera generacin. La tercera generacin (UMTS/FPLMTS) surge a partir de servicios soportados por sistemas celulares incorporando diferentes estndares como sistemas telefnicos inalmbricos (p.e. DECT), incluidas su interconexin con GSM y la ayuda de sistemas de satlites con cobertura mundial.
Identificacin de lnea
Identificacin de terminal Relacin fija
Identificacin de usuario Relacin fija
Redes fijas
SIN MOVILIDAD
Redes mviles
Relacin dinmica
Relacin fija
MOVILIDAD DE TERMINAL
Dinmica Redes fijas y mviles Fija
Dinmica
MOVILIDAD PERSONAL
Fig. 11.1 La movilidad personal permite a los usuarios el libre movimiento entre terminales, tanto en redes fijas como mviles, para establecer y/o recibir llamadas
127
Tecnologa analgica
Tecnologa FM
CT -1
IMTS
CT-1+
Tecnologa analgica
TCAS, NMT, C450
AMPS
Tecnologa digital
N-AMPS
CT-2
Tecnologa digital
CT-3/DCT-900 GSM DCS1800
TDMA E-TDMA
CDMA
Fig. 11.2 Esquema descriptivo de la evolucin de los sistemas de comunicaciones mviles (europeo a la izquierda y americano a la derecha) desde sus orgenes hasta nuestros das
11.1.1 Comparacin entre la gestin en sistemas cableados y sistemas de comunicacin mviles A partir de las caractersticas de los sistemas de comunicaciones fijas descritos en captulos anteriores se pueden estudiar los aspectos de gestin que se plantean en los nuevos sistemas de comunicaciones mviles. reas funcionales como las de configuracin o fallos resultan muy afectadas en estos nuevos sistemas. En la tabla 11.1 puede observarse una estimacin de la evolucin en la gestin que pueden seguir los sistemas de comunicaciones mviles frente a otras arquitecturas de comunicaciones fijas.
128
Gestin de red
Tema Red de acceso
Cableado
Mvil
Area Funcional Fallos Prestaciones
Distribucin de equipos Interconexiones Proveedor de servicios local Autentificacin terminal Tarificacin
-Bucle dedicado/usuario - Canales escasos y por contienda - Esttico - Calidad bucle estable - Dinmico - Calidad inestable Muy centralizado Muy distribuido Pocas jurisdicciones Fijo Ninguna - Uso independiente del servicio local - Sin cargos para llamadas entrantes Planif. bucle esttico Ninguno Mas jurisdicciones Depende de la posicin en el seguimiento Hecha para cada llamada -Distancia independiente del servicio local - Cargos para llamadas entrantes Herramientas de ingeniera de RF Registro del terminal
Configuracin, fallos Contabilidad, fallos Contabilidad Configuracin Configuracin Contabilidad
Diseo de red de acceso Establecimiento del terminal inicial
Planificacin Planificacin Configuracin
Tabla 11.1 Tabla comparativa entre la gestin en redes fijas y redes de comunicaciones mviles
11.1.2 Arquitectura de la red GSM La arquitectura del sistema GSM consta de tres grandes subsistemas interconectados que interactan entre ellos mismos y con los usuarios, a travs 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 estacin mvil (Mobile Station, MS) se considera integrada en el subsistema BSS. La BSS, tambin conocida como subsistema radio proporciona y gestiona trayectos de transmisin de radio entre estaciones mviles y centros de conmutacin mvil (Mobile Switching Centers, MSC). La BSS tambin gestiona la interfaz de radio entre las estaciones mviles y los dems subsistemas de GSM. Cada BSS consiste de muchos controladores de estaciones base (Base Station Controllers, BSCs) que conectan las MS a la NSS va los MSCs. Los NSS gestionan las funciones de conmutacin del sistema y permiten a las MSCs comunicar con otras redes tales como la PSTN y RDSI. El OSS soporta la operacin 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 robados o que hacen un uso fraudulento del sistema.
129
MS
CC MM RR LAPDm L1
Subsistema de radio BSS BTS BSC

LAPDm L1 BTSM LAPD RR BTSM LAPD BSSMAP SCCP MTP
BSSMAP CC, MM SCCP MTP
MSC VLR MAP

MAP TCAP SCCP MTP
Radio enlace
Red SS7 Subsistema de red NSS MAP VLR

MAP TCAP SCCP MTP
NMC
TMN
X.25 Network
HLR
ADC
OMC
AUC
Subsistema de gestin de red
EIR
Fig. 11.3 Arquitectura de la red GSM y sus protocolos de sealizacin
La gestin de red en GSM se basa en la constitucin de una red de gestin del sistema (TMN) y sigue las pautas de diseo vistas en el correspondiente captulo 6.
NE-BSC
NEF
NE-BTS Qx
NEF
OS
OSF
Q3
MF
bssfunction
Q3
NE-MSC/VLR
NEF mscfunction vlrfunction
Fig. 11.4 Ejemplo de TMN en la arquitectura GSM
130
Gestin de red
MF: funcin de mediacin 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 gestin de red del sistema GSM son la serie 12 de GSM. Esta serie define ms de 100 clases de objetos gestionados con casi 500 atributos [TO1].
11.2 Arquitectura de las redes PCS

11.2.1 Caractersticas de los sistemas basados en PCS Los sistemas PCS pueden distinguirse de otros sistemas basados en redes ms convencionales por una serie de caractersticas relacionadas con la inteligencia del sistema. Por una parte, permiten a los usuarios operar en mltiples entornos y tambin preven la posibilidad de operar una conexin 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 localizacin 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 interconexin de multiples operadores en un entorno abierto, se requerir la provisin 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 mviles, proporcionando la misma calidad. Esta provisin de nuevos servicios admitir mltiples tipos de usuario y se ofrecern de forma personalizada, es decir, con requerimientos y caractersticas distintas para cada uno de ellos. El sistema admitir un nico nmero PTN (Personal Telecommunication Number). Este nmero constituye la base de la movilidad personal. El usuario puede ser localizado en cualquier parte e independientemente de los dispositivos que est utilizando a travs de este nmero. De esta forma, con un nico y pequeo 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 gestin de recursos radio, funciones de gestin de movilidad, funciones de gestin de llamada y funciones de gestin de datos (datos referidos a informacin interna de la red). Las funciones de gestin de recursos radio estn relacionadas con la parte del radioenlace de una red PCS, y gestionan los recursos radio (frecuencia, slots temporales, cdigo, etc.) asignacin, monitorizacin de las caractersticas del canal e informacin sobre la transmisin de la seal. Las funciones de gestin 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 gestin de movilidad consiste en el registro de localizacin, renovacin de localizacin, bsqueda y traspaso del mvil. Las funciones de gestin de llamada incluyen el establecimiento de llamada, la terminacin, la monitorizacin y el encaminamiento de llamadas, la autentificacin, el cifrado, el descifrado y las
131
funciones de supervisin. Por ltimo, la gestin de datos corresponde a la lista de funciones que se encargan de almacenar, obtener, renovar y mantener varias formas de informacin asociada con el uso de recursos de la red, perfiles de servicio, tarificacin, etc. De estas cuatro funciones, la gestin de recursos y las funciones de gestin de movilidad son las exclusivas de sistemas basados en PCS y las que permiten un seguimiento global de los usuarios, proporcionndoles servicios de calidad. Teniendo en cuenta estos cuatro grupos de funciones de red definidos, la red puede subdividirse en tres niveles lgicos: el nivel de acceso, que proporciona el mtodo de acceso, el nivel de transporte, que se encarga de realizar las funciones de conmutacin y de transmitir la informacin de usuario y de la sealizacin, y el nivel inteligente, que realiza gestin de red y control de servicio. Tomando como referencia esta arquitectura lgica formada por tres niveles, se han propuesto diversas arquitecturas de red. La arquitectura que actualmente se est desarrollando en Europa est basada en los estndares GSM/DCS1800, con el soporte de la interfaz UPT. El sistema celular digital DCS1800 es un estndar desarrollado por el ETSI que est basado en el GSM900 y que se diferencia de ste en tres elementos fundamentales: la frecuencia de operacin (1710-1785, 1805-1880 MHz con 375 portadoras), las potencias de pico de 1000 mW y 250 mW, definiendo pequeos 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 ms importantes que se plantea en Estados Unidos es la compatibilidad del estndar PCS1900, basado en GSM, y el estndar de sealizacin IS-41 para el desarrollo de sistemas PCS. Existen diferencias importantes entre ellos, como por ejemplo la introduccin de algoritmos de privacidad y autentificaciones diferentes o la sealizacin necesaria para la interconexin entre sistemas al invocar procedimientos de movilidad (p.e. protocolo MAP en el handover). El comit del T1P1 desarrolla el estndar PCS en Estados Unidos y lo define como un conjunto de capacidades que permiten una combinacin de movilidad de terminal, movilidad personal y gestin de perfil de servicio. Sin embargo, en otras ocasiones, este trmino 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 corresponderan geogrficamente aproximadamente a estados, y 492 bandas BTA (Basic Trading Areas), que corresponderan a condados. Adems de las licencias para sistemas terrestres se han asignado 20 MHz para aplicaciones sin licencia (10 MHz para trfico asncrono como redes de paquetes no cableadas y otros 10 MHz para trfico sncrono, como puede ser la voz). Otros grupos de estandarizacin que desarrollan actualmente o que han trabajado en sistemas PCS son el TR-46 que est bajo la supervisin 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 sealizacin; el T1M1, que est tambin supervisado por ATIS, y se ocupa de operaciones, administracin, mantenimiento y provisin (OAM&P); y, por ltimo, un comit tcnico conjunto de T1P1 y TR-46 para proporcionar una interfaz comn. La FCC (Federal Communications Commission) es el organismo encargado de asignar licencias para operar en el espectro PCS segn normativas del JTC (Joint Technical Committee). El JTC distingue entre dos categoras de sistemas: celular digital e inalmbrico digital. Recientemente, el JTC ha pasado en su seleccin, de 16 posibles estndares 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 hbridas TDMA/CDMA y de banda ancha en CDMA (W-CDMA), segn se ve en la
132
Gestin de red
tabla 11.2. El IS-136 es otro estndar muy reciente, en fase de estudio, y que supone una mejora respecto al IS-54 considerado en la tabla comparativa. Los estndares anteriores pueden clasificarse en cuatro importantes grupos: GSM (PCS1900), CDMA (IS-95), TDMA y PACS. El sistema PCS1900 est siendo utilizado ya por pequeos operadores para conseguir cuota de mercado rpidamente en los Estados Unidos. Se trata de una tecnologa 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 ms estaciones base y una ms rigurosa gestin de las frecuencias. Los sistemas basados en CDMA (p.e. IS-95) preven una entrada en funcionamiento ms a largo plazo. Se trata en principio de un sistema superior aunque en la prctica est teniendo muchas dificultades. Tiene la ventaja de que su plan de frecuencias es ms simple y la cobertura es similar a los sistemas analgicos 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 extensin digital del estndar analgico 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.
Hbrido (nuevo) Mtodo de CDMA/ acceso TDMA/ FDMA TDD Mtodo dplex 5 MHz Bw 32 Kbps Bit-rate (sin enc.) 21 dB Gan. prc 5 MHz Guarda canales 20 Canales voz/port. 16 X Refer. a AMPS Fase cont Modulac. salto QM Ninguno Err.(voz) N=3 Reuso fr. Pot. max media 1W Pot. slot 625 ms Lg.trama 80 ms Lg. Tslot 80 ms Ret. voz No Ecualiz. CELP Vocoder (8Kbps) ADPCM (16,24, 32,40) Basado IS-95 CDMA en PACS TDM/ TDMA FDD 300 KHz 32 Kbps 300 KHz 3 0.8 X Pi/ 4 d-QPSK Ninguno 16x1 12.5 mW 100 mW 312.5 ms 9 ms 9 ms No ADPCM 32Kbps Basado IS-54 TDM/ TDMA FDD 30 KHz 7 Kbps 30 KHz 8 3X GMSK FEC 7x3 100 mW 600 mW 6.7 ms 110 ms 110 ms S VSELP (8Kbps) LDCELP 16Kbps en Basado en Basado DCS-1800 DECT TDMA TDMA en WCDMA D-CDMA
FDD 1.2MHz 8/13.3 Kbps 21 dB 1.25 MHz 8 10 X OQPSK/ QPSK FEC N=1 200 mW 50 ms 50 ms No Tasa var. (8/4/2/1)
FDD 200 KHz 13 Kbps 200 KHz 12 2-3 X GFSK FEC 7x1y 3x3 125 mW 1W 577 ms 90 ms 90 ms S RPE-LTP 13 Kbps
TDD 1728Khz 32 Kbps 1728 KHz 128 0.2 X OQPSK/QP SK Ninguno 9 20.8mW 250 mW 417 ms 28 ms 28 ms No ADPCM 16-32 Kbps
FDD 5 MHz 32 Kbps 21 dB 5 MHz
16 X
FEC 1 500 mW 13.25 ms 13.25 ms No ADPCM 32 Kbps
Tabla 11.2 Esquema resumen de los sistemas de radioenlace candidatos para soportar PCS
133
El mbito de actuacin del comit JTC incluye el desarrollo de documentos tcnicos para la definicin de estndares sobre las funcionalidades de la interfaz aire, proporcionando acceso a redes de telecomunicaciones para servicios de comunicaciones mviles y PCS. Los trabajos incluyen el estudio de las consideraciones electromagnticas en las interfaces, y pueden incluir aspectos relacionados con la capa fsica de transmisin, el acceso al medio, y los protocolos de sealizacin. Las actividades del JTC tambin tienen impacto sobre las actividades desarrolladas por el grupo ITU-R TG 8/1, que es una organizacin internacional que elabora recomendaciones para el futuro sistema FPLMTS. De forma simultnea, se est desarrollando todo un nuevo conjunto de interfaces de aplicacin sobre los sistemas PCS; entre stas se pueden considerar las comunicaciones inalmbricas residenciales y pblicas, las PABX inalmbricas, las redes digitales celulares, las redes micro-celulares, las redes celulares analgicas, la radio mvil especializada, FPLMTS, UPT, el uso de satlites, etc. Todos estos sistemas requieren de su integracin en una red inteligente. En el diseo de estos sistemas resulta fundamental la seleccin de una estructura idnea de la red que permita la movilidad de los usuarios segn 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 estn separados, es decir, los usuarios pueden comunicarse con la red va terminales personales de radio diferentes. En el modelo de referencia TR-46, utilizado anteriormente por sistemas analgicos celulares, slo se soporta movilidad de terminal [12]. En Europa, los estndares presentan diversas soluciones que se basan, por ejemplo, en el carcter ms o menos distribuido de sus nodos (caso del futuro sistema UMTS frente al GSM). A continuacin, se describen brevemente los modelos de referencia PCS a los que se ha hecho referencia anteriormente.
1850 MHz
1910 MHz
1920 MHz
1930 MHz
1990 MHz
Licencias para banda ancha PCS
Asncrono
Sncrono
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 continuacin: se define una estacin 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 travs de un radioenlace. El sistema de radio (Radio System, RS), a menudo llamado estacin base, se compone de una BTS (Base Transceiver System) y de un controlador, BSC (Base Station Controller). Se define un PCSC (Personal Communications Switching Center) que sirve de interfaz entre el trfico de usuarios procedente de las redes mviles con el de las redes cableadas. Se definen unas bases de
134
Gestin de red
datos VLR (Visited Location register) y HLR (Home Location Register) a semejanza de GSM, si bien 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 tarificacin, un centro de autentificacin (Authentication Center, AC), un registro para equipos robados (Equipment Identity Register, EIR), un sistema para operaciones (Operations System, OS) para la gestin de la red y una funcin de interconexin para posibilitar la comunicacin entre otras redes (Interworking Function, IWF).
11.2.1.2 Modelo de referencia T1P1 La arquitectura del modelo T1P1, segn se muestra en la figura 11.7 es similar a la anterior; sin embargo, existen algunas diferencias que se describen a continuacin: El terminal mvil o RPT (Radio Personal Terminal) es idntico a la PS del modelo TR-46. El RP (Radio Port) es idntico a la BTS del modelo TR-46. El RPI (Radio Port Intermediary) proporciona una interfaz entre uno o ms RPs y el controlador. El RPC (Radio Port Controller) es el controlador y es idntico a la BSC del modelo TR-46. Tambin se define un RASC (Radio Access System Controller) que realiza las funciones de control y conmutacin en la parte especfica de radio. En la parte de la red fija se define el centro de conmutacin 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 lgico 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 lgico 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 tambin un sistema OAM&P de manera idntica al OS del TR-46 y finalmente una funcin para interconexin, IWF (Interworking Function).
OS AUX IWF
Sistema de radio PS BTS BSC PCSC Redes externas
Otras VLR EIR PCSC AC HLR VLR
DMH
Gestores de movilidad
Fig. 11.6 Modelo de referencia TR-46
135
TMD
TMC
Redes externas
Sistema de radio RPT RP RPI RPC
RASC PSC
RPT PMD PMC
IWF
OAM&P
Fig. 11.7 Modelo de referencia T1P1
11.2.2 Servicios PCS Los servicios que se definen aqu estn basados en el protocolo MAP, soportado por el estndar para sealizacin de interconexin IS-41. Aunque estos servicios estn 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 bsicos que pueden agruparse de la siguiente forma: Servicios bsicos Funciones de registro y desregistro de la PS (Personal Station) al sistema PCS - registro automtico - autentificacin de terminal y privacidad (usando clave privada) - autentificacin de terminal y privacidad (usando clave pblica) - autentificacin de usuario y validacin - registro personal automtico - desconexin del registro personal automtico - registro personal - desconexin del registro personal Funciones para la comunicacin 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 PCS. Procedimientos de establecimiento, continuacin y liberacin de llamada. - origen de la llamada - distribucin de la llamada - liberacin de la llamada - llamadas de emergencia (E911) - handover
136
Gestin de red
Servicios suplementarios Los servicios suplementarios se definen en el estndar IS-104 (Personal Communications Service Descriptions) para 1800 MHz. El IS-41 C define tambin servicios, pero slo estn disponibles cuando hay un seguimiento del mvil. Otros servicios podran ofrecerse nicamente por determinados sistemas PCS. Estos servicios son: Rellamada automtica, llamadas a cobro revertido, mantenimiento y devolucin de llamada, redireccin de llamada (por defecto, ocupado, no respuesta, incondicional), transferencia de llamada, llamada en espera, presentacin de la identificacin del nmero que llama, restriccin a la identificacin del nmero que llama, multiconferencia, no molestar, alerta flexible, notificacin de mensaje en espera, prioridad de acceso, prioridad multinivel, aceptacin de password, preferencia de lenguaje, acceso prioritario por asignacin de canal, llamadas remotas, aceptacin de llamada selectiva, acceso e intercepcin 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 gestin de movilidad por parte de la red de acceso del sistema. A continuacin se expone la solucin ms comn adoptada actualmente.
11.2.3 Gestin de movilidad Uno de los aspectos fundamentales en sistemas PCS es cmo se gestiona la movilidad. Esta gestin se mantiene actualmente a partir de una estructura formada por dos tipos de bases de datos con dos niveles jerrquicos (basados en GSM o bien en el sistema americano de sealizacin IS-41). La configuracin ms normal dispone de una nica HLR (Home Location Register) que es un registro de localizaciones en el cual se almacena la identidad del usuario mvil para propsitos de informacin del usuario mvil (p.e. nmero en el directorio, informacin de perfil, localizacin actual o periodo de validacin) junto con varios VLR asociados (Visitor Location Register). El VLR es otro registro de localizaciones temporales (de visitantes) usado para obtener informacin en el establecimiento de llamadas a/o desde un usuario mvil visitante. Los sistemas ms avanzados como UMTS dispondrn de una arquitectura de bases de datos distribuida jerrquicamente que permitir una gestin de la movilidad de los usuarios con una carga de sealizacin y retardos menores. En el ltimo punto se explica con ms detalle este tipo de sistemas. Esta gestin de movilidad se apoya, pues, en unos recursos que se estructuran de manera diferente segn los requerimientos de los usuarios y las capacidades de la red.
11.2.4 Gestin de recursos La gestin de recursos incluye en general la asignacin de recursos y el acceso tanto en la red fija como en la red mvil. Aqu se describir lo que ocurre en la parte de la red mvil. Una forma de asignar recursos es mediante esquemas de acceso mltiple. Estos tipos de esquemas se utilizan para compartir entre un grupo de usuarios un canal comn de subida de forma que se mejora la capacidad del sistema y disminuye su coste. Existen tres caractersticas bsicas para el diseo del acceso en un sistema PCS: flexibilidad, calidad y capacidad. La flexibilidad se refiere a la capacidad de manipular voz integrada, datos y trfico de vdeo, tratando con la capacidad de seguimiento del
137
usuario. La calidad significa satisfacer requerimientos de servicio, tales como el retardo y/o la acotacin de la prdida de paquetes. La capacidad significa que el nmero de usuarios con servicio tendra que ser mximo para el ancho de banda dado. No siempre es fcil llegar a un buen compromiso entre estos factores. En las redes futuras de tercera generacin se exigirn redes inteligentes integradas, tanto en el acceso mvil como en la red fija. Por ejemplo, si se considera un cluster de celdas en una determinada rea geogrfica, un gran operador de telefona celular podra dar cobertura con celdas a muchas carreteras, otro a la red ferroviaria, otro operador a diversos edificios de oficinas limtrofes, etc. Para disponer de un entorno de gestin comn eficaz, donde la optimizacin en la cobertura de las celdas, y la asignacin de canales y de recursos en la red sea posible conjuntamente para las ms diversas necesidades de trfico cambiantes se necesitara la integracin de los mltiples sistemas coexistentes en una nica red inteligente. Esta integracin de subsistemas para gestionar recursos en la red requiere de la especificacin de un mtodo de acceso que permita obtener la adecuada sinergia al conjunto de la red.
11.2.5 Mtodos de acceso en PCS Los esquemas de acceso mltiple pueden clasificarse en tres tipos: de acceso aleatorio, de asignacin fija y de asignacin por demanda. El acceso aleatorio en PCS puede resolverse mediante mecanismos como ALOHA y CSMA/CD, ya conocidos, o bien mediante tcnicas de acceso CDMA, en donde se comparte todo el ancho de banda. En los sistemas de asignacin fija las transmisiones son coordinadas completamente por la estacin base y sta asigna la frecuencia con el canal correspondiente a cada terminal. ste es el caso de los mtodos de acceso basados en FDMA o TDMA. Cuando el acceso es por demanda de una asignacin, existen distintos mtodos que requieren explcitamente de control, como D-TDMA, PRMA, DRMA o DH-TDMA. Estos mtodos de asignacin 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 informacin y los recursos de canal pueden utilizarse para otros usuarios de forma que puede obtenerse mediante multiplexacin una gran eficiencia. Por ltimo, pueden distinguirse una serie de mtodos de asignacin 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 prstamo de canales, la asignacin dinmica de canales (DCA), o bien funciones de coste que tengan en cuenta el estatus de la red, etc. Junto al mtodo de acceso es necesario especificar la pila de protocolos de sealizacin 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 sealizacin El protocolo de sealizacin 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 introduccin de la nueva carga de sealizacin
138
Gestin de red
asociada a los servicios PCS ser 3 o 4 veces superior a la asociada a sistemas mviles como GSM, que ya de por s es importante. Los tres niveles ms bajos del protocolo de sealizacin propuesto son el nivel fsico, nivel de enlace y el nivel de gestin. El nivel fsico se encarga de la transmisin de la informacin en cada uno de los canales, proporcionando los canales lgicos 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: gestin de recursos radio (RR), gestin de movilidad (MM) y gestin de conexiones (CM). La introduccin de la IN (Intelligent Network), proporciona independencia del servicio separando la secuencia de control de ste de la gestin de los recursos de red. Para gestionar la movilidad en PCS se introduce el MAP (Mobile Application Part) situado en el nivel de aplicacin de SS7. La implementacin de un MAP requerir el uso del concepto del Application Service Element (ASE) de IN. ste se define como un conjunto de funciones de aplicacin que proporcionan capacidad para la interconexin de entidades de aplicaciones con un propsito especfico, segn 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 aplicacin. MAP tambin requiere el soporte de la parte de control de conexiones de sealizacin SCCP (Signalling Connection Part) y del MTP (Message Transfer Part) del SS7. En Estados Unidos se esta definiendo tambin el estndar T1M1 PCS OAM&P para el tratamiento de operaciones, la administracin, el mantenimiento y la disposicin 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 mviles avanzadas Para las comunicaciones mviles personales se necesitan todas las funciones de la red inteligente usuales en las redes de cableado fijo, ms otras relacionadas con la movilidad de servicio del abonado y en la gestin de la llamada. stas incluyen la obtencin y renovacin de informacin de localizacin, autentificacin, encaminamiento de llamadas, traspaso, tarificacin y mantenimiento. Estas funcionalidades de servicio adicionales causarn un dramtico aumento en el trfico de sealizacin, especialmente en los entornos de microceldas con altas densidades de terminales mviles con frecuentes renovaciones de localizacin. Los sistemas de telefona mvil actuales incorporan las funciones mencionadas anteriormente mediante dos redes inteligentes interconectadas, una para el sistema mvil y otra para la red fija a la que est conectada (p.e. RDSI). En el caso de los procedimientos de movilidad, el estndar de red inteligente CS-2 (series Q.1200 de la ITU-T) tendr que adaptarse a una arquitectura distribuida soportada por mltiples funciones de control de servicio (SCF's). Esto es un camino necesario para evitar sealizacin innecesaria en la red y minimizar los retardos incurridos. Por otra parte, dadas las caractersticas de red avanzada que puede soportar PCS, se est diseando un terminal mvil tal que sea un terminal inteligente multimodo capaz de adaptar sus subsistemas de
139
radio dependiendo del servicio requerido, la carga de teletrfico y el estatus del radiocanal. Este terminal mvil dispondr de lector de tarjetas inteligentes para la provisin de los parmetros de seguridad y los datos relativos al abonado. Esta aproximacin proporciona flexibilidad a operadores de red y a proveedores de servicio, permitiendo evolucionar segn progrese la tecnologa.
MAP
Proceso de aplicacin ASE ASE ASE Entidad de aplicacin
ASE
TCAP
Subcapa de componentes
Subcapa de transacciones
SCCP
MTP
Fig. 11.8 Protocolo MAP en ITU/SS7
11.3 Funciones de gestin. 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 operacin y los elementos de red. Se especificaron aspectos de Q3 relacionados con las cinco reas funcionales definidas por la ITU. En las reas de gestin de configuracin y de fallos, la cobertura se limit a la BSS. Otros elementos de red como VLR y HLR se trataron ms en relacin a la gestin de tarificacin. La MSC no se consider estrictamente un elemento de red GSM y su definicin se dej para ms adelante. En cuanto a gestin de seguridad, no se contemplaron especificaciones nuevas, considerando que ya se haban 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
140
Gestin de red
directamente. En total, existen ms de 100 clases de objetos gestionadas, definidas con casi 500 atributos. La definicin 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 contencin 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 comunicacin mviles

11.4.1 Caractersticas de los servicios UPT Dentro de los sistemas de comunicacin personal que se espera tengan mayor implantacin en Europa, la que est ms desarrollada en especificaciones es la interfaz UPT. Adems, actualmente UPT se nutre tambin de recomendaciones generadas por la ITU. Por eso en este apartado se describirn sus caractersticas principales. En entornos UPT se permite a los usuarios UPT realizar y recibir llamadas en cualquier terminal, fijo o mvil 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 mvil (Fig. 11.9). Una de las caractersticas 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 podran limitar las caractersticas del servicio que se solicita. Para poder disponer de movilidad personal se requiere de un nmero personal (o nmero personal UPT) que permita identificar de manera nica y directa a un usuario independientemente del terminal utilizado. El nmero personal UPT se utiliza, pues, para realizar y recibir llamadas, as como para su tarificacin. Este nmero UPT ser utilizable desde cualquier terminal fijo o mvil 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 nmero. En la recomendacin E.168 de la ITU-T se muestran cuatro esquemas de numeracin para UPT o aproximaciones basadas en la recomendacin E.164 de la ITU-T. El nmero UPT sirve como puntero para indicar un registro o fichero donde se ubica informacin relativa al usuario y a los servicios a los que est abonado. Esta informacin tiene una parte que es fija (servicios abonados, tarificacin, restricciones de movilidad, etc.) y otra parte variable (direcciones, posicin, encaminamientos,...). Un usuario, segn los acuerdos a que haya llegado con el proveedor de servicio y segn 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 mviles 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 anloga
141
a la movilidad de terminal, pero proporciona una especie de servicio de movilidad personal dentro de la red GSM. Las tarjetas inteligentes se utilizarn en las futuras redes de tercera generacin como UMTS o IMT2000 permitiendo mltiples aplicaciones en entornos de red inteligente. Su uso puede servir como un posible mtodo de acceso para acceso a UPT o autentificacin en redes de comunicaciones mviles basadas en la movilidad personal. Las especificaciones UPT le permiten soportar un gran conjunto de servicios. Es previsible su implantacin progresiva en sucesivas fases, conforme avance la tecnologa 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, (recomendacin ANSI T1.701), o bien a nivel internacional (recomendacin F.851 de la ITU-T). Esta primera fase de UPT soporta el servicio telefnico sobre redes pblicas analgicas convencionales, redes mviles y RDSI. Anlogamente, el conjunto de servicios UPT 2 se sita en un escenario ms avanzado, todava en fase de especificacin y desarrollo, tanto a nivel nacional como internacional [10]. El desarrollo de UPT requiere de una tarificacin, un encaminamiento de llamadas, diversas facilidades en torno a las bases de datos, etc. que hacen necesaria la introduccin de cambios en la red. Para facilitar este proceso se requerir la potenciacin conjunta de las redes inteligentes as como de una adecuada sealizacin, basada en el SS7.
Caractersticas de los servicios UPT 1 A continuacin, se describen brevemente las facilidades proporcionadas por el conjunto de servicios definidos en la fase 1 de las recomendaciones UPT. - Autentificacin 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 direccin de terminal fijo o mvil. - Llamadas UPT salientes: esta facilidad permite al usuario UPT realizar llamadas salientes desde cualquier terminal, fijo o mvil, previa autentificacin de usuario. - Seguimiento de llamadas salientes: esta facilidad permite al usuario UPT, antes de terminar una llamada saliente UPT a indicar la invocacin de otro establecimiento de llamada sin necesidad de autentificacin. - Distribucin 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.
Caractersticas 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 implementacin depender de las caractersticas del terminal, de la red, as como de las condiciones impuestas por el proveedor de servicio.
142
Gestin de red
- Registro de llamadas salientes: el registro de llamadas salientes permite a los usuarios UPT realizar llamadas salientes desde una determinada direccin de terminal; para ello, el terminal ha sido previamente personalizado, autentificado y las llamadas son cargadas al correspondiente nmero UPT. - Registro de todas las llamadas: esta utilidad permite al usuario UPT combinar el registro simultneo de llamadas entrantes y salientes. - Registro de llamadas remotas entrantes, salientes y totales: esta utilidad permite registrar todo tipo de llamadas a la direccin de un terminal remoto desde otro terminal. - Seguimiento global: esta facilidad permite a un usuario UPT, previa autentificacin y uso de servicios UPT, indicar una actividad de seguimiento antes de una desconexin 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 segn diferentes horarios u opciones personales. - Interrogacin de perfil de servicio UPT: esta facilidad permite a un usuario UPT el consultar los datos relativos a su propio perfil de usuario. - Modificacin 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 paramtros 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 comunicacin, en donde los datos relativos a un usuario UPT, tales como su identidad, nmero, posicin, etc. son transmitidos desde unas bases de datos a otras con lo que debe asegurarse su privacidad y proteccin. 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 autentificacin (p. e. con un PIN) que es un nmero 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 integracin que supone una interfaz que proporciona comunicaciones personales como UPT en un sistema de comunicaciones mviles de gran implantacin actual en Europa como es GSM. En este caso, la introduccin 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 estndar de arquitectura de red inteligente a causa de su gran flexibilidad en la creacin de servicios. De esta forma, UPT puede integrarse en plataformas sobre GSM que dispongan de servicios de red inteligente. A continuacin se analizarn los pasos que se deben efectuar para introducir los servicios UPT en la red GSM.
143
En primer lugar se describirn 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 geogrfico en elementos originantes, de abonado y elementos terminantes. Desde un punto de vista lgico se dividen en un control de llamada, control de servicio y funciones de gestin. En la figura 11.10 se muestra la arquitectura funcional en la interfaz UPT. Para una adecuada integracin de las redes, se requieren una serie de cambios en las funcionalidades relativas al establecimiento de llamada. Concretamente, la funcin del agente de control de llamada UPT (CCAF) requiere de una combinacin especfica 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, slo pueden hacerse cambios mnimos en CCAF. Desde un punto de vista ideal, UPT no impone requerimientos especiales en la funcin de control de llamada (CCF). Esto se debe a que la sealizacin a partir de pulsos decdicos puede convertirse en seales DTMF e informacin relacionada con el protocolo de sealizacin SS7, tal como de lnea llamante o de identidad de lnea 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 operacin de servicios, la funcin de conmutacin de servicio (SSF) permite interrogar a la funcin SCF y as recibir una respuesta, que permite el intercambio de servicio de forma correcta. Algunos servicios UPT (p. e. registro para llamadas salientes), podran requerir que la funcionalidad SSF sea soportada tanto a nivel de central local como a nivel de trnsito. 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 lnea. Los mismos resultados se podran obtener si se consiguiera integrar la SSF, funcin de conmutacin de servicio en la MSC. La funcin de control de servicio (SCF) contiene el servicio lgico para UPT y es capaz de realizar todo tipo de consultas a la base de datos desde otras redes. La funcin de datos de servicio (SDF) contiene informacin relacionada con el servicio y el abonado UPT. Esta entidad necesita un estudio ms profundo que permita disear una estructura estndar fcilmente utilizable en los procesos de autentificacin, perfil de servicio, informacin de localizacin, etc. En esta reflexin parece muy recomendable estudiar las especificaciones diseadas para GSM que pueden ser de utilidad en el proceso de integracin y seguramente evitarn esfuerzos redundantes en el diseo. Existen otras funciones tambin necesarias como son la funcin de recursos especiales (SRF), que traduce las seales DTMF para el SCF, y las peticiones SCF en anuncios vocales para el usuario. Otra funcin de inters es la que permite la creacin de servicios (SCEF): su principal misin es la definicin, creacin, y comprobacin del servicio UPT. Los procedimientos UPT no relacionados con la llamada en la red inteligente pueden manipularse de dos formas diferentes: - El usuario interacta con el mismo terminal que utiliza para realizar o recibir llamadas, y la informacin pasa a travs de las funciones CCAF, CCF, SSF, SCF y SMF (funcin de gestin de servicios). - El usuario interacta con un terminal dedicado a la gestin de servicio, y la informacin pasa a travs de la funcin de acceso de gestin de servicio (SMAF), SMF, SCF, y SSF.
144
Gestin de red
Desde un acceso PSTN, el primer mtodo se usa para procedimientos simples, que se realizan frecuentemente desde distintas situaciones, tales como procedimientos de movilidad personal. El segundo mtodo se usa en procedimientos ms complejos (p.e. gestin 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 gestin. Al principio, en GSM se prevee, por su simplicidad, el primer mtodo. Esto implica que la SMF sera flexible para permitir el uso de varios procedimientos de gestin de servicios como pueden ser la modificacin de perfil de servicio, el chequeo de los lmites de crdito, la tarificacin, las estadsticas, 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 segn hora del da, lista de preferencia de usuarios llamantes, opcin de no molestar o de correo vocal si est ocupado. En la primera fase, est prevista la utilizacin de telfonos con teclado DTMF, y realimentacin vocal. Dado que no es deseable el tecleado de largas secuencias de nmeros, para simplificar el procedimiento de acceso podra usarse la informacin de la direccin de la lnea llamante. En sucesivas fases de desarrollo e implantacin de estos servicios se usar una nica tarjeta inteligente que permite proporcionar acceso a travs de telfonos pblicos as como privados equipados con lectores de tarjetas. Entre estos se pueden incluir los sistemas de comunicaciones mviles tales como GSM, DECT, y avanzados o de tercera generacin como UMTS/FPLMTS. El acceso de GSM al servicio UPT se puede efectuar mediante el tecleado de una secuencia de dgitos (incluyendo un cdigo de acceso UPT, un nmero UPT y un nmero de identificacin 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 seales DTMF no pueden soportarse actualmente de forma fiable por los codificadores de voz GSM. Sin embargo, el uso de un dispositivo DTMF permitira 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 posicin, los registros UPT le siguen a la nueva posicin y terminal. Este problema podra evitarse con una desconexin del registro UPT automtico. Se pueden realizar ciertas consideraciones de cierto inters y que surgen por la incorporacin de funcionalidades UPT en terminales GSM. En las ltimas fases de diseo de UPT, el dispositivo que proporciona servicios podra ser del tamao de una tarjeta SIM. Sin embargo, en este caso sera imposible para el abonado GSM original tener sus servicios simultneamente 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 sera incapaz de encontrar si una llamada entrante va al abonado GSM o al UPT. Para solucionarlo se requeriran algunos pequeos cambios en las especificaciones de sealizacin existentes (p.e. un bit para indicar una llamada UPT). Otras cuestiones de relativo inters se refieren a la actuacin 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 desconexin del registro de usuarios UPT de una direccin de terminal, as como la proteccin de la informacin de perfil de servicio, la tarificacin etc. de las bases de datos. Por eso, sera necesaria la verificacin de la autorizacin de entrada al servicio UPT en cada peticin.
145
La provisin de autentificacin prevista por medio de la utilizacin de un PIN parece no muy recomendable. En este caso, una tercera persona podra encontrar el cdigo y usar el servicio a cuenta de los abonados. El problema podra 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 especificacin de los procedimientos para poder soportarlos. Un usuario UPT puede controlar el servicio usando procedimientos UPT estandarizados. En una primera fase, estos procedimientos se efectan manualmente, por ejemplo, usando el dispositivo de suscripcin y mediante apuntes vocales. Todos los procedimientos que se pueden sugerir requieren el uso de ciertos elementos bsicos, tales como acceso, autentificacin, e identificacin del abonado. Como se ha dicho anteriormente, los procedimientos UPT pueden clasificarse en cuatro grandes categoras: procedimientos de movilidad personal, procedimientos de establecimiento de llamada UPT, procedimientos de gestin de perfil de servicio UPT y determinados procedimientos especiales de gestin de red. En el establecimiento de la llamada, el terminal GSM indicara que un determinado servicio UPT est activo informando al usuario (GSM o UPT). Por ejemplo, una llamada UPT entrante se distinguira de una llamada GSM ordinaria por un tono de alerta, un apunte vocal con autentificacin, o un display especial. En el caso de apuntes vocales, los terminales existentes no requieren modificaciones. Entre los procedimientos especiales de gestin de la red existe el de la facturacin de cargos o tarificacin del abonado. En el caso de la tarificacin de un abonado UPT, sta se basa en el nmero UPT. El abonado recibe una sla 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 tarificacin puede basarse en la localizacin del usuario llamado y llamante, hora del da, duracin de la comunicacin, etc. La informacin de contabilidad UPT se rene en la red usada, que es transferida y manipulada de acuerdo a los principios de tarificacin 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: suscripcin (pago inicial y tarifa mensual), gestin de la suscripcin (p.e. servicios disponibles, cambios,..), uso de servicios (p.e. llamadas), cargos relacionados con la posicin. 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 situacin 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 diseado de acuerdo con los principios de RDSI, de forma que todos los servicios suplementarios GSM tienen sus contrapartidas en RDSI. Podran producirse condiciones de colisin entre los servicios suplementarios al ocurrir solapamientos en las coberturas de ambos sistemas. Para evitar esto, se podra denegar el registro UPT si hubiera un servicio activo GSM que pudiera provocar una colisin. Sin embargo, la mejor solucin pasa por distinguir entre llamadas GSM y UPT. La gestin en UPT requiere de un protocolo de aplicacin especial. Debido a que se ha adoptado la arquitectura de red inteligente en una primera fase, UPT utilizar INAP (Intelligent Network
146
Gestin de red
Application Part) como su protocolo de aplicacin. Adems usar el modelo conceptual y de gestin de la red inteligente para propsitos de diseo y control. La gestin UPT se divide en cinco areas funcionales de gestin (MFAs): gestin de perfil de servicio, gestin de abonado (administracin de abonados y usuarios), gestin de tarificacin, gestin de seguridad y gestin de interconexin de redes. Ms adelante, la gestin UPT ser adaptada a la red de gestin de telecomunicaciones (TMN) definida por la ITU. Si las redes GSM y la UPT se integran, los principios de gestin deben ser consistentes. Un abonado UPT debe ser capaz de modificar una porcin de su perfil de servicio y desconectar el registro de llamadas entrantes y salientes usando un terminal GSM. En un principio, slo podrn utilizarse modificaciones basadas en una seal DTMF o bien apuntes vocales. En el futuro, las facilidades del GSM relativas a la posibilidad de envo de mensajes cortos podran utilizarse para el registro y la generacin de un men basado en una plataforma de seleccin interactiva que permita la modificacin de servicios. Sin embargo, esto requerir de una interconexin con un centro de servicios y con las bases de datos (SDF o HLR) que no se ha especificado todava. La arquitectura de interconexin actual entre red inteligente y GSM no contiene sealizacin directa, de forma que si se requiere un intercambio de informacin entre ambas redes tiene que establecerse una llamada. Esta arquitectura debe adaptarse convenientemente para introducir los servicios UPT. Para posibilitar una conexin directa entre entidades, algunas funcionalidades como las provistas por el SSF y SRF tendrn que instalarse en la MSC. Cuando se usan servicios UPT desde GSM, una conexin de sealizacin 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 cmo deberan integrarse en la base de datos de la red inteligente a la que se est abonado. Eso facilitara la obtencin de informacin relacionada con GSM hacia la SCF. Tambin las bases de datos con los perfiles de servicio del operador GSM o UPT a los que se est abonado podran integrarse. Las autentificaciones podran unificarse. En general, la integracin flexible de bases de datos proporciona informacin relacionada con la movilidad a los servicios de red inteligente reduciendo la carga de sealizacin en la red. El operador de red inteligente y el de comunicaciones mviles podran ser el mismo, posibilitando una conexin de bajo coste.
Pas A Grupo llamante Obtencin de localizacin
Pas B Grupo UPT Base de llamado
datos UPT
Llamada actual
Seguimiento
Pas C Grupo UPT llamado
Fig. 11.9. La red inteligente permite a una llamada actual ser enrutada directamente desde el pas A al pas C
147
SMAF SMF SCEF SMF
SMAF SMF SCEF
SMAF
Red de abonado
SCEF
Red originante
SDF SRF
SDF
Red terminal
SDF
SCF SRF
SCF
SCF
SSF CCAF
SSF CCF CCF CCF CCAF
Fig. 11.10 Arquitectura funcional en UPT
SDF SCF HLR INAP SSP CCF SSF TUP/ISUP SSF SSF MSC VLR INAP MAP
Fig. 11.11 Integracin de facilidades de red inteligente en la MSC para el soporte de movilidad personal
148
Gestin de red
SDF HLR SCF MAP
INAP SSP CCF SSF
INAP
SSF TUP/ISUP
SSF MSC
VLR
Fig. 11.12 Integracin de facilidades de red inteligente en las bases de datos VLR/HLR para el soporte de movilidad personal
Parte mvil
Parte de la red SMAF SMF SCEF
Inteligencia MSF SDF(M)o
MCF Acceso y Transporte
SCF(M)o
MCCF
ACCF
MRRC
RRC
RBC
BC
MRTR
RFTR
Relaciones de control de servicio Relaciones de control de conexiones portadoras Relaciones de control de conexiones de llamada Relaciones de gestin de servicios
Fig. 11.13 Modelo funcional en UMTS - FPLMTS
149
11.4.4 Red inteligente en GSM: CAMEL La red inteligente en GSM se ha denominado CAMEL (Customized Applications for Mobile Network Enhaced Logic). Sus principales caractersticas son: - Como una plataforma, CAMEL permite a los operadores mviles definir y desarrollar nuevos servicios de valor aadido sin necesidad de estandarizarlos. - Los operadores se pueden diferenciar de los otros operadores de red mediante la introduccin de estos nuevos servicios de valor aadido. - Estos servicios pueden usarse cuando el roaming sea internacional. - CAMEL est diseado para trabajar como un entorno multifabricante para la infraestructura, como las estaciones mviles. 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 implantacin de servicios de CAMEL est prevista para el ao 1999. Se espera soporte una interconexin con la gestin de movilidad y con los servicios de GSM, posibilite la gestin de llamadas a ms de dos terminales y el soporte de un nuevo VHE para facilitar el paso a UMTS.
11.5 Evolucin de PCS hacia sistemas de tercera generacin

Los recientes avances tecnolgicos estn permitiendo cada vez ms un flujo interrelacionado de personas a escala mundial. En esta nueva era de globalizacin econmica cada vez se hace ms necesario el soporte de una red de comunicaciones mviles de cobertura mundial. El sistema UMTS/IMT2000 de la ITU surge como un intento de cubrir estas necesidades de comunicacin. 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 gestin correcta de la informacin transmitida entre los nodos del sistema. Los sistemas de tercera generacin como por ejemplo IMT2000/UMTS, permitirn 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 informacin diferente y servir en muchos entornos de poblacin diferentes. Entre ellos se pueden destacar el entorno urbano, con alta densidad de trfico, entornos rurales dispersos, interiores de edificios y vehculos que pueden estar movindose a gran velocidad (p.e. coches, trenes,...). En principio, est previsto que el sistema IMT2000/UMTS tenga su propio servicio de movilidad personal disponible slo 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 informacin avanzados a una mayor poblacin (millones de abonados) que los sistemas anteriores y a multitud de entornos, requerir que la tecnologa 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 pases proporcionando cobertura mundial y con tasas de velocidad de informacin de hasta 2
150
Gestin de red
Mbps, proporcionado gran capacidad y calidad a los ms 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 mviles. 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 prviamente la arquitectura en la cual se va a operar, se desarrolla con ms 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 visin de la red UMTS segn el proyecto MONET del RACE. Todava no se ha desarrollado completamente un arquitectura definitiva para este estndar. Es en el entorno de la red UMTS donde van a integrarse los servicios para el usuario, a travs 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 proporcionarn funcionalidades que soportarn la cobertura de los radioenlaces. Es decir, ejercern funciones de soporte en las interfaces de radio, en la gestin de sus recursos y en el mantenimiento y operacin del traspaso. La red fija UMTS comprender entidades que proporcionarn funcionalidades para soportar gestin de movilidad, operaciones con bases de datos, e interconexin con otras redes. Todas las interfaces con la parte fija de la red estn previamente establecidas y no existe distincin entre entidades de la red fija UMTS y entidades de otras arquitecturas (p.e. B-ISDN, UPT). stas podran ser (parcialmente) coincidentes o (totalmente) distintas, depender de su nivel de integracin. En la figura 11.14 se representa la arquitectura de la red UMTS. A continuacin, se describen brevemente los diferentes componentes que forman la red UMTS: La estacin base (Base Transceiver Station, BTS) proporciona la gestin del radioenlace, representando la funcionalidad necesaria para el establecimiento, el mantenimiento y la liberacin del radioenlace. La CSS (centro de conmutacin de celda o Cell Site Switch) representa la funcionalidad de conmutacin bsica en la red de acceso. En el caso de las BCPNs, la CSS podra representar una PBX fija o bien una NT2 dentro de un entorno ISDN. La central de interconexin local (Local Exchange, LE) e interconexin de trnsito (Transit Exchange, TX) representan la red fija existente, es decir, la infraestructura de conmutacin sobre la cual se soportarn 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 operacin de servicios en una cierta rea; puede acceder, modificar y borrar informacin en las bases de datos (Mobility and Service Data Point, MSDP). Las MSCPs estaran 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 pblicos (P) diferente funcionalidad de los de negocios privados
151
(Business, B). Adems, 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 informacin concerniente a datos del terminal, perfil de abonado y de servicio, datos de red, datos de localizacin, etc. Contiene tambin la funcionalidad de los datos que comprende el control y la comunicacin en las bases de datos. El MT o terminal mvil (Mobile Terminal, MT) comprende las funciones ubicadas en la parte del radioenlace correspondiente al terminal mvil. El MT ser un "terminal multimodo inteligente" con subsistemas programables. stos permitirn seleccionar el tipo de control de frecuencias, el mtodo de entrelazado usado por el canal, el codificador, el procedimiento de acceso mltiple, el tipo de modulacin, el control de rfaga, la secuencia de spreading, las frecuencias portadoras, etc. La generacin 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 segn los diversos entornos posibles en UMTS: domstico, de oficinas o empresas, o bien mviles. A diferencia de GSM u otros sistemas anteriores, en UMTS est permitido realizar handovers entre redes distintas; eso comporta la adopcin de servicios de seguridad tales como autentificaciones, controles de acceso, cambio de claves, etc., que dependern en ltima instancia de la poltica de seguridad del sistema. Se pueden clasificar las CPNs segn diversos criterios: uno de ellos, por ejemplo, segn el tipo de interfaz entre la CPN y la red adyacente UMTS (pblica). Esta interfaz determina las funciones que son soportadas por la CPN en s misma y las funciones que realiza la red pblica. 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 mviles).
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 jerrquica que permite almacenar tanto la informacin de perfiles de abonados como de la propia red. Las bases de datos distribuidas estn compuestas de nodos de almacenamiento de informacin (Information Storage Nodes, ISN), de los cuales pueden identificarse varios tipos (Fig. 11.15). Los ISNs son nodos que contienen datos UMTS, informacin 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 podran coexistir en la misma ISNs. No configuran ninguna jerarqua.
152
Gestin de red
Los ISNDn son nodos que contienen informacin de directorios y funciones de control, pero no datos UMTS. Estn organizados jerrquicamente y pueden ser de los siguientes tipos: ISNDN, que son nodos que estn en la parte superior de la jerarqua y son responsables de las relaciones entre redes, e ISNDn, que forman el resto de nodos de manera opcional. Por ltimo, los nodos ISNI 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 travs de una interfaz comn UMTS. Estos nodos reciben peticiones de las entidades UMTS que estn fuera de las bases de datos y las transforman en comandos internos y peticiones, que envan a las ISNs apropiadas. Estos nodos son tambin responsables de recoger los resultados y devolverlos a la entidad originante.
11.5.3 Distribucin de informacin en las bases de datos En este apartado, a modo de introduccin, se describen brevemente los mecanismos sobre los cuales funciona el intercambio de los distintos tipos de informacin (p.e. de servicio o personal) entre las bases de datos de la red fija y el terminal mvil del usuario. Durante el funcionamiento normal de la red, el usuario con el terminal mvil va desplazndose sobre las distintas celdas en las que tiene cobertura el sistema. En la ejecucin 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 supervisin de un operador UMTS. Los proveedores de servicio son la autoridad que tiene la completa responsabilidad para la provisin 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 categoras, los pblicos y los privados, con polticas 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 provisin de uno o ms 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 tambin hacer una distincin entre las distintas clases de datos: los datos usables directamente, que pueden ser procesados para responder a una peticin de base de datos, y los punteros, que dan indicaciones de la posicin de los datos usables pedidos en los dominios de bases de datos y necesarios para soportar la provisin de un servicio. En el caso del establecimiento de una comunicacin 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 mvil (usuario) se est moviendo. En contraposicin se encuentra el dominio UMTS de abonado (home) en el cual el terminal mvil (usuario) tiene una suscripcin vlida. Durante la ejecucin de los procedimientos de movilidad ciertos datos podran ser transferidos (o modificados, obtenidos, etc.)
153
entre diferentes dominios UMTS. Se llama dominio UMTS originante a aquel dominio en el cual se genera una peticin. Cabe notar que el dominio UMTS originante podra ser idntico 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 ms avanzados de tercera generacin. El reto actual consiste en superar la problemtica integracin por la existencia de un considerable nmero de operadores de redes y proveedores de servicios, tanto pblicos 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 implantacin final; sin embargo, se requerirn profundos cambios en las infraestructuras de comunicaciones as como en la misma sociedad, que de esta forma entrara de lleno en una nueva era de la informacin. En este captulo se ha tratado de dar una visin lo ms amplia posible del panorama actual de las comunicaciones personales; sin embargo, hay que decir que los estndares sobre el tema siguen estando abiertos y que existe una mejora continua en los sistemas.
DATOS MSDP(B) MSDP(LE) MSDP(TX)
MSCP(P/B) RED DE ACCESO MT BTS CSS(P/B)
MSCP(LE)
RED DE SEALI ZACIN
CONTROL DE MSCP (TX) SERVICIO Y MOVILIDAD
LE
TX
INFRAESTRUCTURA DE CONMUTACIN BSICA
RED FIJA 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
MCPN (MT, BTS, CSS, MSCP,MSDP)
Fig. 11.14 Arquitectura de la red UMTS (segn el proyecto MONET del programa RACE, UE)
154
Gestin de red
ISNDN
ISNI
ISNDn
ISNDn
ISNDn
ISNDn
ISNDn
ISNDn
ISNs
ISNs
ISNs
ISNs
ISNs
ISNs
ISNs
ISNs
ISNs
Fig. 11.15 Estructura jerrquica y distribuida de bases de datos (MSDP) en la red fija UMTS (segn el proyecto MONET del RACE)
12. Gestin en Internet
155
12 Gestin en Internet
En este captulo se aborda la gestin con la familia de protocolos SNMP, actualmente la configuracin de gestin ms extendida y propia de las redes con pilas de protocolos TCP/IP. No se pretenden estudiar las problematicas de la gestin global de Internet como red de redes [STA1, ROS1,2..].
12.1 Introduccin
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 condicin no se puede cumplir para todos los servicios y redes. Un problema aadido es que los protocolos actuales de Internet no permiten la flexibilidad de servicios ni la calidad de servicio que proporcionan redes ms avanzadas como la RDSI de banda ancha, basada en tecnologa 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 solucin 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 estn ampliamente extendidos por la mayora de pases desarrollados y constituyen la red por antonomasia en la mayor parte de stos. Por otra parte, las empresas estn introduciendo recientemente este tipo de tecnologa de forma masiva en sus redes, de forma que cada vez dependen ms de su buen funcionamiento. De ah se deduce que si se considera la gestin 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 aadir gestin de red en los nodos debe ser el mnimo posible, de forma que la complejidad algortmica y de comunicaciones debe recaer en los procesos gestores (con el uso de plataformas de gestin de elevadas prestaciones). Esto ltimo no siempre se cumple en realidad: baste decir que entornos de gestin como el basado en el protocolo CMIP que permitira obtener mejores rendimientos en estos tipos de redes son suplantados generalmente por entornos ms simples y baratos como el basado en SNMP (Simple Network Management Protocol) que generan a menudo un trfico de sealizacin excesivo.
156
Gestin de red
12.2 Evolucin
Las primeras aproximaciones a la gestin 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 (versin de CMIP sobre TCP). Estos protocolos de gestin se ocupaban bsicamente 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. Ms a largo plazo, exista la versin 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 monitorizacin esencialmente simple. Hubo en marzo de 1991 nuevas revisiones del entorno, que dieron lugar a una nueva especificacin de base de datos denominada MIB II. Fue a partir de ah que diversos fabricantes se dedicaron a la obtencin de MIBs particulares que permitan la compatibilidad entre plataformas de gestin en entornos de red heterogneos, dado que SNMP era esencialmente un protocolo abierto. Posteriormente, en mayo de 1993, el grupo IETF sac una nueva versin ms 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 versin SNMP3 ms 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 informacin de gestin

El objetivo de especificar una estructura de la informacin de gestin 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 gestin de red del sistema remoto. Sin embargo, existe un problema: cmo llegar a los recursos del sistema remoto?, para ello se va a utilizar un mtodo comn para nombrar a los objetos. Este mtodo usa los identificadores de objetos (Object Identifiers, OID). Los OID no son ms 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 encontrara si, comenzando en el root, pasamos a la rama 3, despus 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 nmero entero y quizs un texto breve. Cada nodo puede tener nodos hijos (subordinados o sub-identifiers),
157
conectados a ste mediante lneas (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, cmo 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 codificacin por lnea conocida de estos valores (sintaxis de referencia ASN1).
iso (1) org (3)
ccitt (2)
dod (6) internet (1) directory (1) mgmt (2) private (4)
experimental (3)
mib (1)
Fig. 12.1 rbol de registro
enterprises (1)
12.4 Sintaxis ASN.1

La sintaxis ASN.1, que se representa mediante el trmino 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 informacin de gestin 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 definicin de las estructuras de datos, utilizar una forma determinada de transmitir los datos a travs de la red. La sintaxis de transferencia que se utiliza junto con la ASN.1 son las reglas de codificacin bsicas (Basic Encoding Rules, BER). Si bien se usa ASN.1 para la sintaxis abstracta, dado que esta notacin es muy extensa, se restringe su uso para mantener la simplicidad en los agentes. Una coleccin de descripciones ASN.1 relacionadas con un mismo tema se conoce como mdulo. Se definen tres tipos de objetos con ASN.1:
158
Gestin de red
- Tipos (types), que definen nuevas estructuras de datos. - Valores (values), que son realizaciones (variables) de un tipo. - Macros, que se utilizan para cambiar la gramtica 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 mayscula, los identificadores de valor se escriben en minscula y los identificadores de macros se escriben completamente en maysculas. 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 aplicacin 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 gestin son: - INTEGER: tipo de dato que toma como valor un nmero 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 ms octetos. Cada byte puede tomar valores entre 0 y 255. (cdigo ASCII). - OBJECT IDENTIFIER: tipo de dato que permite la identificacin de objetos de gestin. - NULL: tipo nulo. No se usa en el marco de gestin.
12.4.2 Tipos estructurados Los tipos constructed (estructurados) que utiliza el protocolo de gestin son: - SEQUENCE: tipo de dato para hacer listas.
159
<list> ::= SEQUENCE { <type1>, ... <typeN> } - SEQUENCE OF: tipo de dato para hacer tablas. (p.e. tablas de encaminamiento). <table> ::= SEQUENCE OF <list>
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 nmero entero, por ejemplo: Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING Opaque es un tipo de dato que representa una codificacin arbitraria.
12.4.4 Subtipos ASN.1 Los subtipos ASN1 refinan la semntica 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 monotnicamente. Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0 .. 4.294.967.295) - Gauge: entero no negativo, que se puede incrementar o decrementar con valor mximo. Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0 .. 4.294.967.295)
160
Gestin de red
- TimeTicks: entero no negativo, que permite contar tiempo en centsimas de segundo desde algn inicio. TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0 .. 4.294.967.295) Junto a estos tipos, es preciso definir tambin 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 slo a un campo concreto de la misma. El status permite definir los requisitos de implementacin del objeto distinguindose los siguientes: Mandatory (el nico que se utiliza actualmente), Optional y Obsolete. 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 estndar 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 informacin de gestin (MIB)

Las bases de informacin de gestin (MIB) son un conjunto de objetos gestionados de un recurso que se publican para ofrecer interoperabilidad de gestin. Estos objetos se organizan en grupos, segn sea su temtica. La red se estructura de forma que los nodos deben soportar grupos enteros. Actualmente existen los siguientes tipos de MIBs: las estndares, que son la MIB-I y MIB-II; las experimentales, con grupos en fase de desarrollo; y, finalmente, las privadas, que incorporan la informacin de los diversos fabricantes de equipos. A continuacin, se presenta la plantilla de la macro de tipo de objeto utilizada en la MIB y la plantilla de la estructura de informacin de gestin (SMI). IMPORTS ObjectName FROM RFC1155-SMI DisplayString FROM RFC1158-MIB; OBJECT-TYPE MACRO ::=
161
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) "}" 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
| empty
162
Gestin de red
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,
163
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 informacin de gestin (SMI, RFC 1155)
Cada objeto se describe utilizando la macro OBJECT-TYPE. Cada objeto se descompone en una serie de campos. A continuacin 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 mximo de acceso (lectura, escritura,.) - Status: muestra la vigencia de la definicin del objeto - Description: se trata de un texto que describe el significado del objeto. Existen tambin estos campos opcionales: - Units: unidades asociadas con el tipo de dato (p.e. segundos)
164
Gestin de red
- Reference: se nombra en caso de haber algn objeto asociado - Index/Augments: ofrecen medios para identificar variables - Defval: recomendacin sobre la creacin 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 nmero de objetos que forma cada grupo y una breve descripcin de stos.
Grupo system interfaces at (adress translation) ip icmp tcp udp egp
Nmero 3 22 3 33 26 17 4 6 114
Propsito El propio sistema Interfaces de red Correspondencia de direccin IP Protocolo internet P. de mensaje de control internet P. de control de transmisin 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 versin. Entre stas se halla la de la tabla address translation que se desestim. Tambin se define un nuevo grupo para cada tipo especfico de interfaz, as como un nuevo grupo con objetos de SNMP. Grupo system interfaces at ip icmp tcp udp egp transmission snmp Nmero 7 23 3 38 26 19 7 18 0 30 171 Comentarios eran 3 eran 22 sern 0 eran 33 sin cambio eran 17 nueva tabla expansin de tabla nuevo nuevo
Tabla 12.2 Esquema de grupos de la MIB-II
165
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, etc."
166
Gestin de red
::= { 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
167
"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
168
Gestin de red
"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:
169
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 estndar, con lo que pasar a depender de la MIB de transmisin. Posteriormente todas estas MIB se irn estandarizando, complementando a la MIB-II. 12.5.4 MIBs privadas Las MIB privadas corresponden a las MIBs de productos especficos, generadas por los distintos fabricantes, y aaden funcionalidad a las MIB estndar. Generalmente, los fabricantes las hacen pblicas, ponindolas accesibles por Internet (deposito comn 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 gestin de routers IP. El Simple Network Management Protocol (SNMP) es un protocolo de aplicacin que ofrece servicios de gestin 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 estndar de valores estadsticos y de control de status. SNMP permite tambin 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 estn formados de identificadores de objetos MIB, junto con instrucciones a fin de cambiar u obtener un valor.
Estacin de gestin de red
SNMP
SNMP SNMP
Agente Conjunto de MIBs Ordenador
Agente Conjunto de MIBs Router
Agente Conjunto de MIBs Servidor de terminales
Conjunto de recursos
Fig. 12.4 Arquitectura de un sistema de gestin SNMP
170
Gestin de red
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
Nivel 7
UDP RFC 768
Nivel 4
IP RFC 791 ICMP RFC 782
Nivel 3
Token Ring Ethernet, FDDI
Nivel 1 y 2
Fig. 12.5 Torre de protocolos en Internet
A pesar de la fcil integracin de SNMP en los protocolos UDP/IP, es posible montar SNMP sobre otras torres de comunicacin (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 conexin. Entre las caractersticas 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 difcil de implementar para el diseo de aplicaciones, dada la complejidad intrnseca de las aplicaciones que debe disear. Por otra parte, en cuanto a rendimiento, la eficiencia del protocolo para la transmisin de informacin 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 gestin conducida por polling determina que el gestor pregunte peridicamente a la informacin 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 gestin de trfico puede ser importante. SNMP, si bien es un protocolo abierto, tambin puede utilizar un agente proxy para gestionar sistemas propietarios. Cabe destacar tambin que en SNMP la comunicacin con los agentes no est orientada a conexin 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.
171
12.6.1 Operaciones de SNMP El protocolo SNMP es eminentemente un protocolo simple y de monitorizacin. A continuacin, se definen los tipos de operaciones permisibles con sus objetos: - GetRequest: peticin de valores especficos de la MIB. - GetNextRequest: proporciona un medio para moverse por la MIB. Peticin del objeto siguiente a uno dado de la MIB (orden lexicogrfico). - GetResponse: devuelve los valores solicitados por las operaciones anteriores. - SetRequest: permite asignar un valor a una variable. Debido a posibles problemas de seguridad esta funcin 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 implementacin que realice el fabricante. El uso de MIBs privadas junto con mensajes tipo Trap permite la respuesta del sistema a alarmas especficas de los equipos de cada fabricante. Adems, se posibilita la integracin de agentes en multitud de dispositivos para su gestin, 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 notacin especial denominada Abstract Syntax Notation (ASN.1) a fin de que puedan ser utilizables por programas cliente de gestin de red de otros fabricantes. A continuacin se describe la secuencia de eventos que se produce en la emisin y recepcin de un mensaje SNMP por parte de una entidad de gestin: Secuencia de transmisin de un mensaje SNMP 1. Construccin de la PDU, usando estructuras ASN.1. 2. La PDU se procesa por el servicio de autenticacin junto a las direcciones correspondientes. 3. La entidad de protocolo construye el mensaje, consistiendo de una vesin 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 codificacin bsicas y pasado al servicio de transporte. En la prctica, las autentificaciones no se invocan. Secuencia de recepcin de un mensaje SNMP 1. Chequeo bsico de la sintaxis del mensaje, descartndolo si es errneo. 2. Verificacin del nmero de versin. Se descarta el mensaje si no es coherente. 3. La entidad de protocolo pasa al usuario la porcin PDU del mensaje y las direcciones de transporte de emisor y receptor al servicio de autenticacin. 3.1 Si la autenticacin falla, el servicio de autenticacin sealiza a la entidad de protocolos SNMP, para que genere una Trap y descarte el mensaje.
172
Gestin de red
3.2 Si la autenticacin tiene exito, el servicio de autenticacin devuelve la PDU en la forma de objeto ASN.1 definido en RFC 1157. 4. La entidad de protocolo hace un chequeo bsico de la sintaxis del mensaje, descartndolo si es errneo. En cualquier caso, la comunidad nombrada con la adecuada poltica de acceso SNMP seleccionada finalmente procesa la PDU.
GetRequest PDU
GetNextRequest PDU
SetRequest PDU Trap PDU
GetResponse PDU
GetResponse PDU
GetResponse PDU
Obtener valores (Get values)
Obtener prximos valores (Get-next values)
Asignar valores (Set values)
Enviar Trap (Send Trap)
Fig. 12.6 Secuencias de PDUs en el protocolo SNMP
Versin
Comunidad
SNMP PDU
Mensajes SNMP Tipo PDU Peticin id 0 0 Campos variables
GetRequest PDU, GetNextRequest PDU, y SetRequest PDU Tipo PDU Peticin id error-estatus error-ndice GetResponse PDU Tipo PDU empresa direccin agente Trap genrico Trap Time-stamp especfico Campos variables Campos variables
Trap PDU Nombre 1 Valor1 Nombre2 Valor2 .. . Nombre n Valor n
Campos variables
Fig. 12.7 Formatos SNMP
173
12.6.2 Codificacin para la transferencia de la informacin de gestin: BER Segn se ha explicado en la seccin 12.4, la informacin de gestin se define a partir de la ASN.1. sta establece que para la codificacin se utilizarn 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 ms que un algoritmo recursivo que puede producir una secuencia de bytes a partir de cualquier valor ASN.1. El protocolo SNMP slo 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 tamao de la codificacin del valor que sigue - Value: indica propiamente la codificacin del valor.
12.7 Configuracin y rendimiento de una red gestionada por el protocolo SNMP

La gestin de redes se basa en la gestin de nodos, entendiendo como tales abstracciones de una entidad de red fsica como routers, hubs, ordenadores personales, impresoras, etc. Sin embargo, para analizar ms en detalle la configuracin y el rendimiento en la gestin, se tienen que determinar las dimensiones de los correspondientes parmetros: - nmero de estaciones - nmero de redes - nmero de segmentos - nmero de nodos - nmero de interfaces - nmero de gateways - nmero de nodos gestionados. De hecho, cada nodo tiene una o ms interfaces que se registran en la base de datos. La carga de gestin puede determinarse a partir del nmero de nodos gestionados ms el nmero de interfaces gestionadas para cada nodo. A partir de ah, considerando el nmero de redes y de segmentos se determina finalmente el nmero de objetos que se deben gestionar. Para calcular el nmero de objetos que se deben gestionar, se tiene en cuenta que el nmero 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 gestin pasan por cubrir las funcionalidades de monitorizacin y de descubrimiento bsicas (Discover); las funcionalidades de presentacin (display); las funcionalidades de eventos de accin y de coleccin de datos; finalmente, funcionalidades relativas a gestin distribuida y de bases de datos especficas. Todas estas funciones requieren de espacio de memoria estndar, memoria swap, espacio de disco y potencia de clculo. Se suele estimar a menudo que el espacio de memoria swap sea como dos veces el de la memoria estndar. El uso del protocolo SNMPv2 permite diversas configuraciones de gestin, y puede integrar estaciones de gestin con estaciones de sondeo de datos y con cnsolas de gestin (sesiones del programa de gestin). El proceso de sincronizacin de la informacin puede ser por ejemplo, de unos
174
Gestin de red
3 min. para configuraciones de una estacin de gestin, hasta unos 15 min. para configuraciones de 5 estaciones. El uso de filtros para los procesos de obtencin de informacin, de descubrimiento de los nodos (Discovery), la topologa y los mapas, permite reducir mucho las necesidades de memoria y la carga del sistema de gestin, cosa que repercute en una mayor concentracin de recursos para los objetos que realmente interesa gestionar. 12.7.1 Interrogacin (polling) de estatus de dispositivos. Cada interrogacin de estatus IP genera alrededor de 4 a 5 pequeos paquetes en una LAN local (debido a los ARPs) y 2 paquetes en las LAN remotas. El intervalo de interrogacin 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 ms lejana. 12.7.2 Interrogacin (polling) de descubrimiento (Discovery) La interrogacin 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 informacin previa disponible. 12.7.3 Interrogacin (polling) de configuracin de topologa El nmero de paquetes generados por esta interrogacin depende en gran manera de cuntas interfaces en la red comunican a travs de dispositivos que soportan la MIB Bridge (RFC 1493). En un entorno con gran cantidad de encaminamientos o conmutado se puede esperar la generacin de 10 a 20 paquetes por interfaz en la red. Por defecto, la interrogacin de la red se completa cada 4 horas. 12.7.4 Interrogacin (polling) de chequeo de configuracin de dispositivo Durante la interrogacin de chequeo de configuracin se generan entre 20 y 100 paquetes por nodo, dependiendo del tamao de la informacin que se solicita. Este chequeo se completa por defecto una vez por nodo y se realiza para cada da. 12.7.5 Interrogacin (polling) de estatus de estacin de sondeo Requiere de aproximadamente 20 paquetes por estacin de sondeo. La frecuencia de este tipo de interrogacin se configura a partir de cada estacin de sondeo, siendo la frecuencia por defecto de una cada 5 minutos. 12.7.6 Otras aplicaciones Si se utilizan otras estaciones para la recoleccin de datos, monitorizar variables MIB, chequear niveles de disparo, crear grficos, conectar a sistemas remotos, etc. consecuentemente se genera trfico extra en la red.
175
12.8 Marco administrativo

Para una gestin 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 pblica (public), es decir, de libre acceso. Esta informacin se almacena en cada MIB (Fig. 12.8). De esta forma, una comunidad es una relacin entre un agente y gestores y el nombre de comunidad es una cadena de octetos transmitida en los mensajes SNMP. Para la determinacin de polticas de autentificacin y autorizacin se trabaja con autentificacin simple, en la que el nombre de comunidad se transmite en claro; de ah la necesidad de ampliar la seguridad del entorno de gestin mediante otros servicios de seguridad. En cuanto a la autorizacin, 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 poltica de acceso al sistema.
Agente SNMP
Conjunto de gestores SNMP
MIB SNMP
Modo de acceso SNMP
Comunidad SNMP (nombre comunidad) Poltica de acceso SNMP
Perfil de comunidad SNMP
Fig. 12.8 Conceptos administrativos
12.9 Configuraciones para el uso del protocolo SNMP en entornos heterogneos

Las diversas configuraciones entre sistemas de gestin distintos y/o de diferentes fabricantes en una red limitan el acceso a la informacin de las bases de datos de gestin (MIBs). A continuacin se describen algunas de las configuraciones de redes formadas con nodos heterogneos ms utilizadas.
12.9.1 Sistemas de gestin de red basados en SNMP emergentes Las aplicaciones de gestin SNMP de distintos fabricantes pueden actuar sobre la informacin de gestin de tipo pblico (MIB2) comn de todos los nodos de la red; sin embargo, cada una de ellas slo puede entender la informacin de gestin de los nodos que pertenezcan a la misma marca. Esto se debe a que son MIBs propietarias. Por otra parte, la base de informacin definida por RMON suele tambin ser visible por las aplicaciones basadas en SNMP, complementando la gestin de la red.
176
Gestin de red
Fabricante A Aplicaciones de plataforma y gestin
Fabricante B
Sistemas de gestin de red

SNMP SNMP
Aplicaciones de plataforma y gestin
SNMP
SNMP
SNMP
SNMP
MIB propietario
Standard MIB
Sistemas gestionados
Estndar MIB
MIB propietario
RMON Fabricante A Fabricante B
RMON
Fig. 12.9 Esquemas de actuacin en redes con sistemas de gestin homogneos
12.9.2 Sistemas de gestin de LANs heterogneas En el caso de disponer de sistemas de gestin diferentes en la misma red, en principio tanto la informacin de gestin como los protocolos de gestin funcionan independientemente. Actualmente, las plataformas de gestin ms evolucionadas permiten compatibilidad entre agentes de distintos estndares 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 versin simplificada para la gestin de redes de rea local.
Gestor SNMP
Gestor CMISE
Pila de protocolos OSI con CMIP o CMOL SNMP CMOT SNMP/OSI
Agentes de objetos gestionados TCP/IP
Agentes de objetos gestionados OSI
OSI: interconexin de sistemas abiertos SNMP: protocolo de gestin de red simple CMISE: elemento de servicio de informacin de gestin comn CMIP: protocolo de informacin de gestin comn CMOT: protocolo de informacin de gestin comn sobre TCP/IP CMOL: protocolo de informacin de gestin comn sobre LLC
Fig. 12.10 Esquemas de actuacin en redes con sistemas de gestin heterogneos
177
12.9.3 Valoracin crtica de las MIB en SNMP A pesar de ser las MIBs unas bases de datos para gestin de red muy utilizadas y de fcil uso, presentan diversos problemas respecto a otros entornos de gestin ms evolucionados. Entre los aspectos negativos considerados figuran los siguientes: - Las comunicaciones datagrama son ineficientes para la obtencin de grandes cantidades de informacin de las bases de datos. - No existen mecanismos para la obtencin agregada de datos de las MIB. - No existen mecanismos de compresin de la informacin en la fuente. - No existen mecanismos de correlacin de la informacin en la fuente (p.e. la unin de tablas SNMP). - No existe control de acceso a MIB. - La estructura esttica de la informacin en las MIB limita la manipulacin y la reconfiguracin dinmica, aunque se puede hacer uso de MIBs con informacin aportada por fabricantes,... - Existe gran heterogeneidad en el modelo sintctico/semntico. - No hay modelo explcito de control (p. e. en invocaciones remotas). - No hay mecanismos para representar y manipular relaciones. - El modelado de sistemas jerrquicos puede ser complicado.
12.10 Conclusiones sobre SNMP

Entre las ventajas del protocolo SNMP se pueden considerar las siguientes: - Es un estndar de mercado. - Es simple, fcil de usar. - Modelo til para el acceso a datos de gestin de la red. - Acceso y organizacin eficientes de los datos gestionados. - Independencia del entorno de comunicaciones. - Capacidades generales de monitorizacin y control. Respecto a los inconvenientes ms importantes se pueden enumerar los siguientes: - Limitaciones en el mecanismo de obtencin de informacin: Falta de obtencin selectiva de informacin. - No dispone de controles de gestin. - Limitaciones de las capacidades de modelado de datos: MIB esttica Correlacin de datos difcil Modelados de sistemas complejos.
12.11 Comparacin entre los protocolos CMIP y SNMP

Finalmente, a ttulo comparativo, se presenta una relacin de temas donde se muestran similitudes y diferencias entre los protocolos CMIP y SNMP.
178
Gestin de red
En cuanto a modelo de datos de instrumentacin, el protocolo SNMP se representa a travs de variables, tablas, Traps etc. mientras que CMIP utiliza un modelo de objetos extendido. Respecto a identificacin de nombres de datos gestionados, SNMP hace uso de un rbol de directorios esttico y CMIP hace uso de un rbol de directorios dinmico. En relacin a la representacin de datos uniforme, SNMP utiliza un nmero mnimo de tipos de datos ASN.1, mientras que CMIP hace uso de un rango extendido de tipos ASN.1. Tambin, respecto al soporte de transporte de primitivas query/responses de gestin, SNMP utiliza datagrama, con la mxima independencia de la eleccin de transporte, mientras que CMIP utiliza conexiones con fuerte dependencia del estndar OSI. A nivel funcional, el protocolo CMIP obtiene un mayor rendimiento de los mensajes enviados ya que se reduce la sealizacin respecto al protocolo SNMP. CMIP tambin es ms seguro que el SNMP. A nivel operacional, el protocolo CMIP se basa en una arquitectura jerrquicamente distribuida, lo que permite que el nmero de objetos supervisados sea mayor que en el protocolo SNMP que, al ser de tipo centralizado, viene limitado por la capacidad tecnolgica de las plataformas de gestin. De todas formas, hay que decir a favor del protocolo SNMP que es ms simple y que el personal requerido para su mantenimiento se reduce. A nivel de implementacin, hay que decir que un agente CMIP ocupa unos 400 Kbytes o ms mientras que un agente SNMP ocupa de 20 Kbytes a 60 Kbytes. Tambin, el coste de procesado y de la misma aplicacin es ms elevado en una plataforma CMIP. En cuanto al soporte por parte de fabricantes, el protocolo SNMP es el utilizado por la gran mayora de fabricantes y clientes, y existe una multitud de productos comerciales. Los gastos de mantenimiento tambin suelen ser menores en SNMP al ser ms simple y tener una mayor base comercial. Finalmente, el protocolo CMIP permite ms extensiones, es ms escalable, permite la herencia de atributos y es ms flexible que el protocolo SNMP.
12.12 SNMPv2
Este protocolo de gestin que se defini en 1993, es una versin ms avanzada del SNMP. SNMPv2 aporta una serie de ventajas respecto a la primera versin, entre las cuales pueden destacarse: - Permite una mayor eficiencia en la transferencia de informacin. - Admite mecanismos de seguridad como la autentificacin y el cifrado frente al SNMP (no implementados). - Permite la comunicacin entre estaciones de gestin. - Parte de un modelo de comunicaciones extendido considerablemente. - Permite una sealizacin extendida de errores. - Permite el uso de varios servicios de transporte. El sistema basado en SNMPv2 soluciona muchos de los problemas de su anterior versin, SNMP; sin embargo, su mayor complejidad est coartando su desarrollo.
179
Los mensajes enviados por la plataforma de gestin de red a los agentes SNMP estn 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 versin SNMP, dispone de los siguientes tipos de mensajes: - GetRequest: peticin de valores especficos de la MIB. - GetNextRequest: proporciona un medio para moverse por la MIB. Peticin del objeto siguiente a uno dado de la MIB (orden lexicogrfico). - GetBulkRequest: peticin de mltiples 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 funcin suele estar desactivada. - InformRequest: transmite informacin 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 Peticin id
Campos variables
GetRequest PDU, GetNextRequest PDU, SetRequest PDU, SNMPv2 Trap PDU, InformRequest PDU Tipo PDU Peticin id error-status error-indice GetResponse PDU Tipo PDU Peticin id No repet. Max. repet. Campos variables Campos variables
GetBulkRequest PDU Nombre 1 Valor1 Nombre2 Valor2 ... Nombre n Valor n
Campos variables
Fig. 12.11 Formatos de PDU para SNMPv2
Sin embargo, el hecho de su incompatibilidad con la versin SNMP y la mayor complejidad aadida a las plataformas estn desestimando su futura implementacin. El desacuerdo en el consorcio sobre las recomendaciones acerca de seguridad propuestas en SNMPv2 ha propiciado finalmente su incorporacin en una nueva versin SNMPv3.
180
Gestin de red
PrivDst
AutInfo
GrupoDst GrupoSrc Contexto SNMP PDU
Mensajes SNMP generales PrivDst Longitud 0 OCTET STRING GrupoDst GrupoSrc Contexto SNMP PDU
Mensajes no seguros PrivDst Firma

dstTime-stamp srcTime-stamp GrupoDst GrupoSrc
Contexto SNMP PDU
Autenticados pero no privados PrivDst Longitud 0 OCTET STRING GrupoDst GrupoSrc Contexto SNMP PDU Encriptado
srcTime-stamp
Privados pero no autenticados PrivDst Firma

dstTime-stamp
.. GrupoDst GrupoSrc .
Contexto SNMP PDU
Privados y autenticados
Encriptado
Fig. 12.12 Formatos de mensajes de SNMPv2
12.13 SNMPv3
El protocolo SNMPv3 es una evolucin de la serie de modelos de gestin vistos anteriormente. SNMPv3 est an en fase de especificacin; sin embargo, se pueden describir algunas de las caractersticas en las que se est trabajando. Las reas a las que SNMPv3 va enfocado son, primordialmente, mejorar la seguridad y la administracin respecto a SNMPv2. Respecto a la estructura de la informacin de gestin, la SMI est dividida en tres partes: definiciones de mdulos, definiciones de objetos y definiciones de notificaciones. Las definiciones de mdulos (macros ASN.1: MODULE-IDENTITY) se utilizan para describir semnticamente los mdulos de informacin. Para las definiciones sintcticas y semnticas de objetos se usan macros ASN.1: OBJECT-TYPE. Las definiciones de notificaciones usan macros NOTIFICATION-TYPE y describen transmisiones no solicitadas de informacin de gestin. Entre los tipos de datos que se incorporan a la SMI (RFC 1902) estn: - IMPORTS para permitir la especificacin de items que se usan en un mdulo MIB, pero definidos en otro mdulo MIB. - MODULE-IDENTITY especifica una descripcin e informacin administrativa para un mdulo MIB. - OBJECT-IDENTITY y los OID se asignan para especificar un valor OID. - OBJECT-TYPE especifica el tipo de dato, estatus y la semntica 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 notificacin de eventos.
181
En SNMPv3 se prev tambin aumentar el mapeo de mensajes tipo SNMP a otros tipos de protocolos de transporte. Desde el punto de vista de arquitectura de gestin se extiende el nombrado de: - Motores y aplicaciones. - Entidades (proveedores de servicio tales como motores en agentes y gestores). - Identidades (usuarios de servicio). - Informacin de gestin, incluido soporte para mltiples contextos lgicos. 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 envo de proxies. Respecto a las mejoras en seguridad, SNMPv3 utilizar MD5 y algoritmos de Hash para firma digital y proteger contra la modificacin de la informacin proporcionando integridad de datos, autentificacin 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 monitorizacin remota, y proporciona al gestor de red informacin vital acerca de la interconexin con otras redes. Mientras que el protocolo SNMP se dise en funcin 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 trfico asociado con la red de gestin, mientras que permite al equipo remoto alertar a la plataforma de gestin SNMP cuando ocurre algn problema. Entre las caractersticas principales cabe destacar: - Operacin off-line: pueden interrumpirse procesos de polling mientras el monitor sigue funcionando siempre. - Monitorizacin preventiva: en caso de sistemas bien dimensionados, se puede enviar peridicamente informacin de estatus de la red a fin de prevenir posibles problemas. - Deteccin de problemas y generacin de informes: disposicin de sondas activas. - Datos de valor aadido: el monitor de redes puede realizar anlisis especficos de la informacin de su red que no son accesibles con mtodos directos (slo hasta nivel MAC). - Multiples gestores: RMON permite la estructura de plataformas gestoras dispuestas de forma distribuida y jerrquica. El estndar RMON es un sistema de monitorizacin remota que est creciendo muy deprisa como solucin a problemas de gestin de red centralizada. Uno de sus principales alicientes es el de proporcionar una arquitectura distribuida, frente al carcter centralizado del protocolo SNMP. Las funciones MIB asociadas a RMON1 entran dentro los siguientes grupos: - Actividades a nivel de aplicacin - Filter: mecanismo de seleccin de paquetes de acuerdo a un determinado criterio. - Packet capture: coleccin de paquetes y mecanismos de carga a travs de criterios de filtrado.
182
Gestin de red
- Events: mecanismo de control para acciones disparadas por una alarma. - Estadsticas de host - Host: descubrimiento y estadsticas de hosts por direcciones MAC. - Host Top N: estadsticas ordenadas por direccin MAC. - Matrix: seguimiento de la conversacin entre dos hosts. - Otros grupos - Statistics: trfico LAN acumulado y estadsticas de errores. - History: estadsticas de muestreo de intervalo para anlisis de tendencias. - Alarms: niveles de disparo. - Token Ring: 4 parmetros de las redes token-ring. En las figuras siguientes se realiza una comparacin de los entornos de una red, gestionada con y sin sonda RMON.
Red con sonda RMON (agente RMON): reduce el trfico de gestin ya que analiza el trfico, las alarmas, etc. y procesa toda la informacin de la red, mandando nicamente los datos significativos a la estacin de gestin (p.e. estadsticas).
Sonda RMON Interconexin Interconexin Interconexin Sonda RMON
Sonda RMON
Estacin de gestin
Fig. 12.13 Esquema de redes con sonda RMON
Red sin sonda RMON: se caracteriza por realizarse un polling continuo de la estacin de gestin al monitor. La estacin de gestin ha de procesar toda la informacin lo que provoca un mayor trfico de gestin.
183
Analizador de redes Interconexin Interconexin Interconexin
Estacin de gestin
Fig. 12.14 Esquema de redes sin sonda RMON
12.15 RMON 2
RMON2 aparece como especificacin RFC en 1996 como una extensin de RMON. RMON2 aade respecto a la versin uno, la decodificacin de paquetes entre los niveles 3 y 7 del modelo OSI. Ello trae consigo las siguientes consecuencias: a) Una sonda RMON2 puede monitorizar trfico de acuerdo con protocolos de nivel de red y direcciones, incluido el Internet Protocol (IP). Esto permite a la sonda observar ms all de los segmentos LAN, a los cuales est conectado, y ver el trfico entrante/saliente a la LAN va routers (nodos especficos). Aplicable a la gestin de interconexin de redes. b) A causa de que la sonda RMON2 puede decodificar y monitorizar trfico a nivel de aplicacin, tal como email, transferencia de ficheros, y protocolos WWW, la sonda puede grabar trfico a y desde hosts para determinadas aplicaciones. RMON2 introduce, adems, 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 versin 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
184
Gestin de red
12.16 RMON 3
RMON 3 prev extender el entorno RMON a las redes de rea extendida (WAN). Todava est en fase de especificacin.
13. Gestin distribuida
185
13 Gestin distribuida
Las arquitecturas de red basadas en gestin distribuida son las que permiten la obtencin de mejores rendimientos en grandes redes. La gestin de un gran nmero 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 travs de redes heterogneas. Est organizada en funcin de la relacin clienteservidor [KNO1]. Existen tres grupos principales de funcionalidad DCE: 1. Remote Procedure Calls a servidores (DCE-RPC), utilizado tambin en DCOM. 2. Servicios de seguridad entre servidores y clientes 3. Localizacin de servidores y clientes dentro de una red. La unidad de organizacin principal de la DCE es la celda, que consta de recursos, sistemas y usuarios que tienen un propsito comn y comparten actividades DCE comunes. Tpicamente una celda contiene hosts y servidores conectados a una red de rea local (LAN).
13.1.1 Componentes principales de DCE El modelo de distribucin est basado en su software RPC (Remote Procedure Call) y utiliza un modelo de distribucin orientado a procedimiento. Permite a clientes/servidores comunicarse a travs de dilogos de peticiones/respuestas (una peticin iniciada por un cliente). El cliente no tiene constancia de la posicin 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 ms que copiarlos (excepto para pilas y registros que estn separados para cada enlace). Se utilizan tambin los servicios de directorio, que
186
Gestin de red
sirven para localizar recursos en una red de redes. Para ello usa el nombrado de la notacin de X.500 y especficas 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 autentificacin entre cada host. Proporciona autentificacin, autorizacin, integridad de datos y privacidad de datos. - Distributed Time Service (DTS): proporciona un medio de sincronizacin 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). Tambin organiza servidores en grupos lgicos, llamados dominios administrativos, facilitando el trabajo con grandes redes. As como el uso de herramientas de administracin.
13.1.2 Restricciones en el uso de DCE Entre las restricciones a la hora de acometer una gestin con DCE hay que decir que la librera de ejecucin de DCE debe ejecutarse en cada host (no importa si es servidor o cliente). La configuracin mnima de una celda es de RPC, enlaces, CDS, DSS y DTS. Adems, a los recursos puede accederse slo despus de una autentificacin correcta.
13.1.3 Razones para escoger DCE Entre las razones para la eleccin de DCE como arquitectura de gestin, se puede citar el hecho que permite el desarrollo de aplicaciones independientemente de la red, sin tener que desarrollar funciones genricas como RPC, enlaces, etc. Se trata, adems, de un entorno coherente, basado en estndares: es un entorno de computacin abierto y que permite la comparticin transparente de ficheros. El hecho de ser un entorno distribuido proporciona informacin independientemente de donde est almacenada, escondida la complejidad de la red, y se obtiene un conjunto integrado de servicios. Adems, DCE previene el acceso no autorizado a recursos, y para su implantacin no se necesitan las capacidades de un sistema orientado a objetos. Finalmente, DCE soporta comunicaciones sncronas entre servidores y clientes.
13.2 Distributed Management Environment (DME)

La Open Software Foundation (OSF) seleccion un conjunto de tecnologas para integrar dentro de su Distributed Management Environment (DME). Esta tecnologa, propugnada inicialmente por HP, es capaz de trabajar con cualquier sistema operativo y simplifica la gestin de sistemas distribuidos y stand-alone, reduciendo los costes para administracin de sistemas.
187
Herramientas de desarrollo
Aplicaciones de gestin Servicios de gestin Servicios Objeto Marco de actuacin DCE con extensiones Opcin de gestin de red (NMO)
Fig. 13.1 Estructura del marco de actuacin DME
Aplicacin cliente
CORBA IDL Stub DCE IDL Stub DCE IDL Runtime
DCE RPC Runtime y servicios (directorio, seguridad, etc)
Fig. 13.2 Componentes cara cliente
DME comprende varios grandes componentes en dos grandes grupos: un marco de actuacin y una serie de servicios distribuidos. Dentro del marco de actuacin, presenta una infraestructura orientada a objetos para aplicaciones de gestin 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). Tambin dispone de Distributed Notificacion Services. En cuanto a los servicios distribuidos, permiten la instalacin y distribucin de software, licencia de software, integracin de ordenadores personales o bien la gestin de hosts.
188
Gestin de red
Servicio Cliente IDL Stub

Interfaz de invocacin dinmica
Esqueleto IDL DCE Runtime activar/registrar Repositorio de interfaces DCE daemon
(DII) DCE Runtime
RPC
Fig. 13.3 Componentes en el marco de trabajo DME
13.3 CORBA. Gestin segn OMG

CORBA es una especificacin para una arquitectura orientada a objetos estndar 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 informacin 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. Adems, CORBA permite el cambio y evolucin de los sistemas basados en red para reflejar nuevas topologas o nuevos recursos.
CORBA permite la computacin distribuida de objetos, es decir, dos o ms partes de software comparten informacin con cada otra. Para ello, sin embargo, hay aspectos que se deben tener en cuenta, como la unin de computacin distribuida con un modelo de objetos o el uso de un broker. Un modelo de objetos es un concepto de computacin orientado a objetos. Se basa en los conceptos de abstraccin, encapsulacin, herencia y polimorfismo. Abstraccin es la capacidad para agrupar objetos y enfocar las caractersticas comunes del grupo. La encapsulacin esconde los detalles de implementacin de un objeto en funcin 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 identificacin de interfaces en el tiempo de ejecucin. Existen diversas justificaciones para utilizar CORBA frente a otros mecanismos. Por ejemplo, el modelo de distribucin CORBA est basado en el uso de objetos y utiliza un modelo de distribucin orientado a objetos. De esta forma permite cubrir una necesidad de modificar o extender el sistema de
189
computacin distribuido lo que permite obtener los beneficios que comporta el anlisis y el diseo orientado a objetos. Esta flexibilidad resulta de gran utilidad en el diseo de los atributos de los objetos a gestionar, as como en el rendimiento de los protocolos de gestin. CORBA, adems, soporta comunicaciones sncronas entre servidores y clientes y tambin cubre la necesidad de comunicaciones asncronas sin usar una trayectoria predefinida.
13.3.1 Arquitectura CORBA OMG a travs de CORBA (Common Object request Broker Architecture) estandariza los mecanismos mediante los cuales los objetos envan 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 definicin de la interfaz de los objetos. CORBA propone una aproximacin consistente en el desarrollo de una interfaz independiente de todo lenguaje, que permita invocar las operaciones sobre objetos, sin saber dnde 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 informacin en un ORB
Objetos clientes
Herramientas comunes
Broker de peticin de objetos (ORB)

Descripcin de los servicios ofrecidos a travs de IDL Objetos servidores
Fig. 13.5 Esquema de servicios ofrecidos a travs de IDL al ORB
190
Gestin de red
La funcin principal del agente ORB es la de asegurar la independencia de localizacin e implementacin de los objetos, y responder de la interoperatividad entre mquinas diferentes. Para ello, debe conseguir que el cliente sea capaz de ver la interfaz del objeto de manera independiente de su ubicacin, del lenguaje de programacin que lo implemente, y de cualquier aspecto que la interfaz no refleje expresamente. El funcionamiento de CORBA se sustenta en 5 componentes principales: el ncleo de ORB (ORB core), el lenguaje de definicin del interfaz (IDL), el interfaz de invocacin dinmica (DII), el almacn de interfaces (IR) y los adaptadores de objeto (OA). El nucleo de CORBA es responsable de la recepcin desde el cliente y entrega posterior de las peticiones a los servidores correspondientes. Los clientes no tienen por qu conocer dnde residen los objetos de red, cmo se comunican, cmo estn implementados, cmo estn almacenados, ni tampoco cmo se ejecutan o procesan. Para que un cliente pueda efectuar una peticin 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 estticas va una interfaz especfica, o invocaciones dinmicas va la interfaz de invocacin dinmica (DII) del ORB. El lenguaje de definicin del interfaz permite la especificacin de las interfaces a objeto. Es un lenguaje declarativo, cuya sintaxis es similar a la de C++, que proporciona tipos de datos bsicos (enteros, reales, etc.) estructurados (estructuras y uniones) y plantillas (templates). Se emplea en la declaracin de operaciones para definir los tipos de argumentos y los valores de retorno. La interfaz de invocacin dinmica permite que aquellas declaraciones de interfaces en IDL de las que los clientes no tenan conocimiento en tiempo de compilacin, 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 grfica de usuario GUI puede, dada una lista de referencias a objeto, permitir a los usuarios hojear el almacn de interfaces, aprender sobre las operaciones soportadas por cada objeto y, entonces, invocar operaciones sobre ellos para ver cmo se presentan en pantalla. En suma, el DII es una matriz genrica del cliente capaz de avanzar cualquier peticin sobre un objeto. El almacn de interfaces guarda de forma persistente la definicin de las interfaces (InterfaceDef) de todos los objetos declarados IDL, y pueden ser consultados por medio de la operacin 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 generacin de referencias a objeto, la invocacin de mtodo de objeto, la seguridad o la activacin y desactivacin 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 integracin de aplicaciones heredadas sin perjudicar a nuevos objetos definidos, restringindolos a un conjunto limitado de criterios de implementacin. Los servicios que los OA deban proporcionar podrn ser proporcionados delegndolos al propio ORB o bien efectundolos l mismo.
191
Cliente
Repositorio interfaces
Implementacin de objetos
Implementacin
Repositorio
Invocacin dinmica
Stubs IDL Cliente
Interfaces ORB
Esqueletos estticos
Invocacin de esqueletos dinmica
Adaptador de objetos
Ncleo del broker de peticin 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 aplicacin 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 segn los principios definidos en el Open Group/NMF Join Inter-Domain Management Force (JIDM). Los objetivos bsicos del diseo de la pasarela CORBA/CMIP UHC son: - Proporcionar una implementacin escalable que permita el acceso a un nmero configurable de agentes OSI. - Incluir los principios de traduccin definidos por el JIDM. - Permitir una configuracin completamente dinmica en tiempo de ejecucin de la informacin del diccionario. - Que las prestaciones de la pasarela sea independiente del nmero y tamao 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 informacin de mapeado que necesita el kernel de la pasarela. Una de las funcionalidades de la pasarela permite una actualizacin dinmica de la informacin del diccionario, incluir nuevas clases de objetos y agentes OSI en tiempo de ejecucin. Esto se realiza implementando la informacin del diccionario como un MIB local accesible mediante un protocolo Q3, la interfaz de CORBA o la interfaz de gestin local de la pasarela. A partir de las funcionalidades bsicas de traduccin CORBA/CMIP, la pasarela aade las siguientes funcionalidades adicionales:
192
Gestin de red
- Gestor de eventos genricos: cumple las normativas X.734 y X.735, se encarga de la recepcin, redireccin y memorizacin de los eventos. - Q3IM: gestin interna de Q3ADE, que es un paquete de aplicaciones para el desarrollo TMN, y protocolo de gestin de MIB. - Pasarela de SNMP: accede a los agentes SNMP segn las especificaciones NMF IIMC. - ADK: monitoriza la calidad de servicio y realiza estadsticas. La pasarela CMIP/CORBA UHC es una pasarela general con diversos campos de aplicacin: - 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 gestin, que permite mapear a un nmero elevado de lenguajes de programacin y mediante el cual se pueden gestionar los agentes CORBA, CMIP y SNMP. - El producto se puede utilizar para implementar agentes heterogneos capaces de ser gestionados por aplicaciones de gestin CORBA y CMIP.
Operador o abonado Browser web Browser web Browser web Interfaz de usuario
Sistema gestor Pasarela CORBA/ CMIP CMIP
Sistema gestionado C O R B A Agente OSI
HTTP
PROXY (Cliente CORBA)
Recursos gestionados
Pasarela CORBA/ SNMP
SNMP
Agente SNMP
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. Adems, su interoperabilidad se garantiza mediante la versin 2 del ORB, que incluye una notacin 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 notacin GDMO/ASN1 sigue siendo mejor alternativa como especificacin de modelos de informacin.
13.4 Distributed Component Object Model (DCOM)

DCOM (Distributed Component Object Model) es un protocolo que permite a los componentes software comunicarse directamente a travs de una red de manera fiable, segura y eficiente. Al
193
principio adoptaba el nombre de Network OLE. Actualmente DCOM est diseada para utilizarse a travs de mltiples protocolos de transporte de red, incluyendo los de Internet como HTTP. DCOM se basa en la especificacin DCE-RPC de la Open Software Foundation y funciona tanto con applets java como con componentes ActiveX a travs 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 mayora de sistemas operativos, si bien CORBA es ms utilizado. DCOM especifica cmo se hacen las peticiones a un objeto y cmo se representan, comunican y mantienen las referencias a objetos. Tiene su aplicacin en el diseo de las comunicaciones en entornos de red distribuidos.
13.4.1 OLE y el modelo de objeto COM OLE es el acrnimo 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 programacin de aplicaciones clientes, similares a las del ORB de CORBA. Estos servicios constituyen el OLE Automation. Por otra parte estn los OLE Controls, redenominados ActiveX por Microsoft en 1996, para avanzar su posicin en el contexto del World Wide Web y de Internet. La distribucin de objetos en el sistema OLE es lo que ha dado lugar a la definicin de DCOM.
13.5 Gestin basada en agentes inteligentes mviles

Actualmente se est planteando el uso de agentes inteligentes en todo tipo de redes avanzadas. Se pueden entender stas como redes donde la informacin 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 mviles y personales.
13.5.1 Introduccin a los agentes inteligentes Un agente inteligente (AI) es un trmino que define desde interfaces de usuario adaptativos hasta comunidades de procesos inteligentes que cooperan unos con otros para conseguir realizar una tarea comn. 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 categora de AI son los de programacin remota y se consideran una alternativa a la programacin remota, considerada alternativa a la basada en la estructura Remote Procedure Call (RPC). Tambin pueden definirse los agentes inteligentes como entidades de software autnomas que se comportan de acuerdo a una inteligencia autocontenida. Entre los atributos de un agente se pueden considerar:
194
Gestin de red
- Inteligencia: indica el mtodo que se utiliza para desarrollar la lgica del agente o inteligencia. - Operaciones asncronas: un agente podra ejecutar su(s) tarea(s) totalmente desacoplada de su usuario u otros agentes. - Comunicacin de agentes: durante sus operaciones, los agentes podran comunicar con varios recursos de sistemas y usuarios. - Cooperacin de agentes: este atributo indica que el sistema de agentes permite la cooperacin entre entidades de agentes. Esta cooperacin abarca desde la clsica interaccin cliente/servidor a negociaciones basadas en mtodos de inteligencia artificial. - Movilidad de agentes: con el objetivo de realizar tareas especficas, los agentes podran transportarse a travs de la red hasta entornos remotos donde admitan su soporte. Existen diversos niveles de movilidad: ejecucin remota y migracin.
13.5.2 Clases de agentes inteligentes Dentro del contexto de sistemas con un nico agente se puede hablar de agentes locales en relacin a agentes de red. En el contexto de sistemas multiagente, los agentes pueden estar basados en inteligencia artificial distribuida o bien ser agentes mviles. Agentes locales Los agentes locales tienen como objetivo principal las interacciones tpicas entre el usuario y el agente. Tambin se denominan interfaces inteligentes. Por ejemplo: obtencin y filtrado de informacin local, gestin de correo local, ordenacin de reuniones, etc. Agentes de red Los agentes de red, en contraste con los agentes locales, pueden acceder no slo localmente sino tambin a recursos remotos. Esto exige tener un conocimiento ms 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 bsqueda (WWW). Agentes basados en inteligencia artificial distribuida El principal objetivo de estos sistemas multiagente es la coordinacin de comportamiento inteligente entre una coleccin de agentes inteligentes autnomos. Cmo coordinan ellos sus conocimientos, objetivos y utilidades para planear y desarrollar conjuntamente acciones o solucionar problemas. Por ejemplo: monitorizacin de vehculos distribuida, CIM, gestin de telecomunicaciones. Estos agentes se desarrollan mediante tcnicas de inteligencia artificial y podran comunicarse y cooperar entre ellos. Son usualmente estticos. Agentes mviles Los agentes mviles se sitan principalmente en grandes ordenadores, ofreciendo un conjunto de servicios sofisticados. Por ejemplo: filtrado de Internet avanzado, agentes de bsqueda, mensajes inteligentes, comunicacin inteligente y gestin. En cuanto a lenguajes, los ms utilizados actualmente son el Safe-TCL y Java, que permiten ejecucin remota de agentes. Los agentes basados en Telescript permiten la migracin mientras estn activos.
195
Atributos/ Clase Inteligencia de agente Operacin asncrona Comunicacin entre agentes Cooperacin entre agentes Movilidad entre agentes
Agente local X X
Agente de red X X X
Agente DAI X X X X
Agente mvil X X X X X
Tabla 13.1 Clases de agentes inteligentes y sus caractersticas
13.5.3 Agentes mviles La movilidad es quizs la caracterstica ms apreciada de los agentes a la hora de influir en la forma tradicional en que se realizan servicios y comunicaciones. Como contrapartida, la ejecucin de programas (agentes) debe realizarse en entornos considerados seguros. Se pueden considerar las siguientes situaciones: - Procesado de tareas asncrona y cooperativamente. - Personalizacin y configuracin de servicios. - Uso de servicio instantneo (NCs) y comercio activo. Se pueden distinguir los siguientes tipos: Clase de agente simple: ejecucin remota o migracin. Clase de agente cliente/servidor (p.e. CORBA). Clase de agente multimedia (p.e. MHEG). - Descentralizacin de gestin. - Comunicaciones inteligentes. - Obtencin de informacin y soporte de tipos de informacin dinmica.
13.5.4 Arquitecturas de comunicaciones basadas en agentes Los entornos de telecomunicaciones actuales estn basados en dos tipos de redes: las redes inteligentes con el protocolo INAP, o bien la red de gestin de las telecomunicaciones (TMN), con el protocolo CMIP. Estos entornos representan los fundamentos para una creacin eficiente y uniforme, y la provisin y gestin de servicios de telecomunicacin 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 ocurrira 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 especficas autnomamente (en nombre de un
196
Gestin de red
usuario o aplicacin). Este tipo de agentes estticos, tales como agentes de usuario o de gestin, podran considerarse ms como entornos de ejecucin de agentes especializados, que ejecutan scripts (p.e. agentes de tipo de ejecucin remota). - Mensaje inteligente: los agentes son entidades mviles, que viajan entre diferentes ordenadores/sistemas y realizan tareas especficas 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 estticos (Home Agent, Foreign Agent). En este caso, el home agent de un nodo mvil es un router que al menos tiene una interfaz con el home link del nodo mvil. A un nodo mvil se le asigna una nueva direccin IP cuando visita un foreign link. Un foreign agent de un nodo mvil es un router que al menos tiene una interfaz con el foreign link del nodo mvil. En el caso anterior de la aproximacin de sistema inteligente, sta se basar en el despliegue de agentes estticos en la red o sistema. En este caso, la red inteligente est previsto que evolucione hacia TINA. Adoptando la aproximacin de mensajes inteligentes basada en agentes mviles, se podra utilizar en dos tipos de dominios, los llamados de intercambio de informacin asncrona, tales como servicios de correo, y para el preestablecimiento de informacin en tiempo real, tales como servicios de comunicacin multimedia.
Entorno de red
Usuario A
Agente usuario
Negociacin
Agente usuario
Usuario B
Agente terminal Sistema final
Agente terminal Sistema final
Gestin de conexin Establecimiento de conexin Recursos de red
Fig. 13.8 Telecomunicaciones basadas en agentes estticos
197
1 Usuario A 2 Sistema Final
1 2 Sistema Final Usuario B
Entorno de red
Fig. 13.9 Sealizacin basada en agentes mviles
13.5.5 Gestin basada en agentes La distribucin de tareas de gestin en la gestin de red se conoce como gestin por delegacin, y adopta un paradigma de gestin descentralizada que tiene la ventaja del incremento de potencia computacional en nodos de la red y decrecimiento de la presin en sistemas de gestin de redes centralizados y en anchos de banda de red. La gestin por delegacin habilita tanto la distribucin temporal (p.e. distribucin sobre tiempo) como la distribucin espacial (p.e. distribucin sobre nodos de red diferentes). El objetivo bsico consiste en traer la inteligencia de gestin (p.e. los servicios de gestin), tan cerca como sea posible a los recursos gestionados, y a su representacin lgica en forma de objetos gestionados. Esto es, mediante la delegacin.
Gestor
Descarga de scripts de gestin
Agente gestionado
Agente gestionado
Agente gestionado
Fig. 13.10 Delegacin de inteligencia de gestin
El agente de gestin (nodo gestionado) tiene que verse como un entorno de agente de ejecucin especfico, que soporta la ejecucin remota de scripts de gestin. Estos scripts podran activarse segn el tiempo, las actividades de gestin o la aparicin de eventos especficos en el agente gestionado.
198
Gestin de red
Las aplicaciones de gestin mviles representan una extensin del escenario anterior, donde las aplicaciones de gestin sern realizadas por medio de agentes mviles que tambin soportan migracin.
Gestor
Agente gestionado
Agente gestionado
Agente gestionado
Fig. 13.11 Servicios de gestin basados en agentes moviles
Sea Tr Tiempo de respuesta completo. t m representa el tiempo de clculo local del proceso del gestor en el gestor. t a describe el tiempo pasado por los agentes (SNMP o agente mvil). t d representa el retardo de la red.
T r = tm + t a + td
A1 , A2 ,..., An representan los agentes distribuidos. t m1 representa el retardo temporal desde el gestor al agente A1 . t1m representa el retardo temporal entre el agente A1 y el gestor. Para el caso cliente/servidor tradicional, el gestor necesitar construir un mensaje de peticin tantas veces como n, donde n es el nmero de nodos agentes. Adems, un agente mvil slo necesita procesar una vez. El tiempo de clculo local del proceso gestor en cada caso ser:
t mSNMP = nt m t m MOVIL = tm
199
Gestor
t1m tm1 tnm
tmn
A1
A2
A3
An Agente gestionado
Agente gestionado Agente gestionado
Fig. 13.12 Tiempo de respuesta de agentes SNMP
Gestor
tm1 t12 A1 A2 t23 A3
tnm
An Agente gestionado
Agente gestionado Agente gestionado
Fig. 13.13 Tiempo de respuesta de un agente mvil
El retardo de la red total t d es 2nt para SNMP y (n+1)t para el caso mvil. Se asume que los retardos temporales entre todos los nodos distribuidos son los mismos. Si se asume tambin que t m , t a son constantes, el tiempo Tr ser:
T r SNMP = 2nt + n + T r MOVIL = (n + 1)t + +

con
= tm = ta
200
Gestin de red
13.5.6 Procesos elsticos Un proceso elstico es un proceso con mltiples enlaces que soporta la invocacin remota de un conjunto de transformaciones elsticas. Estas transformaciones permiten procesos remotos para: - Extender la funcionalidad de un proceso elstico mediante la delegacin de agentes a ste. - Controlar la ejecucin de agentes. - Comunicarse con los agentes Un proceso P = < C, S > consiste en un programa cdigo C y un estado S. C se define por una coleccin de fragmentos de cdigo 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 cdigo en el programa principal ejecutable, y todo las rutinas de librera importadas que fueron explcita o implcitamente cargadas en su espacio de direcciones. si = < ci, xi > donde xi indica el estado de ejecucin del enlace. Clientes
Proceso Proceso elstico
Agente delegado
Servidor elstico
Proceso
RPC
Runtime elstico
Fig. 13.14 Agentes mviles delegando a un servidor elstico
- Transformaciones de extensibilidad de cdigo: permiten a un proceso remoto extender o contraer el cdigo de programa C de un proceso elstico. - Una transformacin suma incorpora un nuevo fragmento de cdigo, c en un proceso en ejecucin, P = < C, S >. Suma: {< C, S >, c} -> < {C U c}, S > - Una transformacin borrado, borra un fragmento de cdigo c, de un proceso P, y podra implcitamente borrar cualquier enlace cuyo estado est asociado con el fragmento de cdigo 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 elstico. - Una instanciacin incorpora un nuevo enlace al estado de un proceso existente. Instanciacin: {< C, S >, c} -> <C, {{s1,..,sk} U {sk+1 = <c, Run >}} >
201
- Una terminacin borra un enlace de un proceso existente. Terminacin: {< C, S >, sj} -> <C, S - sj >. - Una suspensin cambia el estado de un enlace que se est ejecutando a suspendido. Suspensin: { sj = < c, - >} -> { sj = < c, Sus >} - Un reenganche cambia el estado de un enlace suspendido a ejecucin. Reenganche: { sj = < c, Sus >} -> { sj = < c, Run >} Un proceso elstico Pe, soporta la invocacin remota de las seis transformaciones elsticas definidas anteriormente. Esto es, el cdigo y el estado de un Pe pueden modificarse remotamente durante su ejecucin, como el resultado de una interaccin externa explcita. Un proceso elstico es una generalizacin de un entorno de mltiples enlaces dinmicos a uno de distribuido. Un server elstico es un proceso elstico cuyas interfaces de servicio pueden modificarse remotamente. Esto es, la interfaz del servidor es una coleccin de procedimientos de servicio { p1, p2,,pn } que cambia dinmicamente y que puede invocarse remotamente por sus clientes.
14. Gestin basada en Webs
203
14 Gestin basada en Webs

La aplicacin de las nuevas tecnologas de Internet a la gestin de redes intranet, sistemas y aplicaciones es lo que se denomina comunmente como gestin basada en web. La gestin basada en web puede acomodar los sistemas actuales de gestin, 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 gestin de servicios para redes heterogneas. Este ncleo de APIs puede usarse en un array diverso de entornos de computacin que incluye numerosos sistemas operativos, arquitecturas y protocolos de red, lo que permite el desarrollo del bajo mantenimiento y un software heterogneo desde una fuente nica. JMAPI est orientado a resolver problemas de gestin de sistemas distribuidos. El componente que permite a una mquina ser gestionada es pequeo (p.e. applets/java beans), y los objetos agente para operaciones de gestin se descargan y ejecutan de forma segura. Esto minimiza la distribucin y el problemas de las versiones para las operaciones de gestin, y fcilmente permite la modificacin y extensin de las operaciones de gestin. Por otro lado, la mquina 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 enva operaciones de gestin. Estas operaciones podran invocarse interactivamente a travs de un navegador de web o bien una aplicacin independiente. - El admin runtime module es el mecanismo que proporciona objetos de gestin instanciados activos a aplicaciones. - Las appliances son los dispositivos de red que deben ser gestionados.
El JMAPI est provisto de guas para interfaz de usuario, clases java y especificaciones para el desarrollo de aplicaciones para la gestin integrada de redes de sistemas y servicios. Esto incluye:
204
Gestin de red
- 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 creacin de los agentes que se sitan 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
AVM base AVM Help AVM Integration Managed object interfaces
HTTP
Servidor HTTP
Admin runtime module
Fbrica de objetos gestionados
RMI
Instancias de objetos gestionados

Interfaces de SNMP agentes Interfaces de gestionados datos
Navegador de web para java SNMP

Agente SNMP
Appliance Fbrica de objetos agente Instancia de objetos agente
Cdigo JAVA Mtodos nativos
Agente objeto RMI
JDBC
Base de datos
Fig. 14.1 Esquema de gestin con JMAPI
14.2 Web-based Enterprise Management (WBEM)

El WBEM trata de ser un estndar de facto para integrar aplicaciones de gestin de red en webs. Est definido por ms de 50 fabricantes (julio 1996) entre los que destacan: Microsoft, Intel, Compaq, BMC y Cisco.
14. Gestin basada en Webs
205
WBEM proporciona una arquitectura que permite soluciones de gestin para ser construidas cubriendo las reas tradicionales de gestin de configuracin, gestin de fallos, gestin de tarificacin, prestaciones, seguridad, gestin de operaciones y planificacin. Est construido para las necesidades de los estndares de Internet, tanto actuales como futuros, en las reas de transporte, seguridad y protocolos de configuracin. WBEM proporciona un modelo de datos que permite un modelado uniforme, as como la gestin del sistema, la red, y los elementos de aplicacin. Tambin direcciona las necesidades de un conjunto grande y distribuido de elementos de gestin, proporcionando una solucin escalable. Componentes definidos por el modelo WBEM:
- HyperMedia Management Schema (HMMS): descripcin de datos extensiva para representar el entorno gestionado que ser definido por el Desktop Management Task Force (DMTF). Implementacin 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 ncleo) que consiste de las clases a nivel superior, sus propiedades y asociaciones. El segundo nivel es una serie de esquemas especficos de dominio, que incluye el Windows NT, UNIX, red y esquemas de aplicaciones. El core schema establece una clasificacin bsica de los elementos del entorno gestionado, en elementos de sistema gestionado, componentes de aplicacin, 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 gestin provenientes de diferentes fuentes. Definicin genrica para gestin de aplicaciones que agrega gestin de datos y usa uno o ms protocolos para presentar una representacin uniforme del browser (navegador) usando, HTML. Implementacin 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 pequeo de los protocolos y no tienen roles de conmutacin se denominan tpicamente proveedores (providers).
- HyperMedia Management Protocol (HMMP): un protocolo de comunicacin sobre el cual la gestin de datos puede ser accedida y visualizada, y permite soluciones de gestin que son independientes de la plataforma y fsicamente 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 informacin de gestin entre entidades HMMP. Las operaciones bsicas en HMMP son OPEN, CLOSE, GET, PUT, DELETE; CANCEL, METHOD_EXEC, y METHOD_RETURN
206
Gestin de red
Navegador Internet Applet Protocolo de gestin hipermedia Gestin de servicios (HMOM) Otros
Programas y aplicaciones Dir. servicios Acceso a datos Esquema de gestin hipermedia Acceso basado en HTTP (incluyendo HMMP)
SNMP, DMI, otros Dispositivos o aplicaciones Dispositivos o aplicaciones Dispositivos o aplicaciones Dispositivos o aplicaciones
Fig. 14.2 Esquema de la arquitectura WBEM
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 ncleo es la capa de servicios (Service Layer,SL), que es la aplicacin local que gestiona las peticiones para informacin de gestin y las almacena en una base de datos. La capa de servicio soporta dos interfaces de programacin de aplicaciones: la interfaz de componentes (Component Interface, CI) y la interfaz de gestin (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 informacin especfica de componentes que se requiere para gestionar esos mismos componentes. El MI es la interfaz vista por las aplicaciones de gestin, que puede ser local o remoto. Los sistemas de gestin construidos en el esquema gestoragente pueden acceder a componentes desktop va agentes proxy (SNMP, CMIP). La informacin de gestin 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 gestin 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 aplicacin como un suceso asncrono). La lista de operaciones implementadas en la SL y disponibles a nivel de CI son: - INSTALL (usado en la instalacin de los componentes gestionados). - REGISTER (registro dinmico de un punto de servicio en SL para ser gestionado). - INDICATE (evento asncrono enviado a una aplicacin registrada). La CI permite la creacin de un punto de servicio que se usa para cargar los ficheros MIF asociados con nuevos componentes registrados.
208
Gestin de red
Actualmente slo existen especificaciones para la traduccin de DMTF MIF a SNMP MIB y no en sentido contrario.
15.1 Common Information Model (CIM)

Actualmente se est especificando la versin 2 de CIM por el IETF, lo que significa que la informacin de gestin de redes y sistemas podr recogerse y almacenarse de un mismo modo. Si a CIM se aade Extensible Markup Language (XML), la gestin de datos podra representarse sobre una interfaz web de forma estndar o a travs de WBEM.
16. Plataformas de gestin de red
209
16 Plataformas de gestin de red

Las plataformas de gestin son el elemento ms visible de la gestin de una red y la clave del correcto funcionamiento de los sistemas de comunicaciones. Su ubicacin fsica, el personal, el mantenimiento, la configuracin de elementos, etc., son bsicos para que no haya mayores problemas.
16.1 Plataformas de gestin

Las plataformas de gestin son la ltima etapa en la evolucin de los sistemas de gestin, desde sistemas de monitorizacin pasivos a sistemas de gestin standalone, y finalmente a plataformas de gestin. Las plataformas de gestin se distinguen por los siguientes atributos nicos [GHE1]: - Separacin de aplicaciones de gestin de los servicios de la plataforma por medio de APIs. - Entornos de desarrollo de aplicaciones de gestin independientes del software de fabricante. - Separacin/modularidad de los servicios/componentes de la plataforma de gestin. - Soporte para la integracin de aplicaciones de gestin. - Fundamento para la integracin de tecnologas multifabricante, heterogneas, distribuidas y abiertas. - Interfaz de usuario grfica comn. - Servicios de aplicaciones comunes (tiempo, directorio, seguridad). - Repositorio de datos de gestin comunes. - Sistemas de distribucin de software y servicios de licencia software. - Reusabilidad de software y entornos de desarrollo de software de bajo coste. Dependiendo del nivel de sofisticacin, las plataformas de gestin pueden proporcionar tambin: - Un entorno para paradigmas orientados a objetos (definiciones de interfaces, modelos, libreras,...). - Un entorno para invocar mtodos de objetos e instrumentacin. - Un entorno para soportar selectivamente sistemas propietarios. A continuacin se describen brevemente algunas de las plataformas de gestin ms importantes: HP OpenView. Sun Solstice. IBM System View. SPECTRUM de Cabletron. TME10 (Tivoli Management Environment)
210
Gestin de red
16.2 Plataforma de gestin de red OpenView

El OpenView de HP ofrece una solucin de gestin de red para gestin local y redes multifabricante de rea extendida. Incorpora herramientas para el desarrollo de aplicaciones de gestin OSI. Utiliza una amplia variedad de protocolos (SNMP, CMIP, CMOT...). En el caso de gestin distribuida, hay que decir que HP fue el principal promotor del estndar DME (OSF). Otras caractersticas de OpenView: - Incorpora la aplicacin 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 Aplicacin Gestor objetos Gestor objetos Gestor objetos
Servicios de gestin Co- de datos municaciones Servicios de gestin de eventos
Infraestructura
Sistema de gestin de bases de datos
Base de datos
SNMP UDP IP
CMIP TCP IP
CMIP OSI Protocolos de comunicaciones
Fig. 16.1 Esquema funcional de la plataforma OpenView
16.3 SunNet Manager (SUN)

SunNet Manager (Solstice) es una plataforma que est basada en arquitecturas y protocolos de clculo distribuido. Los agentes que actan con SunNet Manager son del tipo:
16. Plataformas de gestin de red
211
- Niveles de protocolo de comunicaciones e interfaces tales como Internet MIB (RFC1066) a travs de SNMP, RPC, Ethernet, FDDI y X.25. - Dispositivos de red tales como routers IP. - Estadsticas 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) Aplicacin, bases de datos y estadsticas de servicios de red tales como NFS o RPC.
Discover Resultados navegador
Resultados Grfico
Eventos Log Datos Log
Run-time MDB
ASCII MDB
Cnsola
(open windows)
Servicios de comunicaciones (RPC)
servicios agentes Agente proxy Agente
servicios agentes Agente
servicios agentes 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 gestin 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 diseo de IBM Netview/6000 para AIX aadi una nueva componente al entorno tradicional de gestin 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 acta como un sistema de gestin de elementos independiente que recibe datos usando otros protocolos nativos aparte de SNA.
212
Gestin de red
Otro aspecto destacable de la plataforma de gestin IBM System View es que no soporta el protocolo CMIP ni soporta actualmente ORB (Object Request Broker).
16.5 SPECTRUM de Cabletron

La primera versin de Spectrum de Cabletron data de 1992. Los componentes que forman el ncleo de la plataforma son el mdulo 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 grfica de usuario. Las primeras versiones potentes de Spectrum no salieron hasta 1994. Actualmente no soporta el protocolo CMIP ni implementa el entorno de operacin ORB.
16.6 TME10 (Tivoli Management Environment)

La arquitectura TME est formada por unos servicios desktop y el marco de la plataforma de gestin, que en principio pueden distribuirse separadamente. El modelo de informacin de objetos soporta herencia y relaciones de contencin; sin embargo, no est basado en el modelo y las plantillas OSI MIM/GDMO. La comunicacin entre gestor y agentes se realiza con mecanismos RPC de la pila de protocolos TCP/IP. Una plataforma que funciona como pasarela realiza una conversin de llamadas RPC y comandos SNMP a mtodos IDL para ordenar acciones en objetos. El ORB disponible no soporta la versin 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
213
Conclusiones
Actualmente todava no existe una solucin en el marco de la gestin de red que pueda proporcionar resultados satisfactorios a todo tipo de redes de comunicaciones. La TMN, o red de gestin de telecomunicaciones, es el camino ms vlido para enfocar la gestin en grandes redes. El protocolo CMIP y/o la arquitectura CORBA permiten utilizar las funcionalidades requeridas normalmente para gestionar redes con gran nmero 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 gestin quedar reducida a la simple monitorizacin de las funciones esenciales del sistema. Si la red que se quiere gestionar est constituida bsicamente de nodos tipo PCs que soporten el estndar de gestin DMI, sta ser la solucin ms cmoda y completa. Para la gestin remota por Internet, estn definindose una serie de soluciones como JMAPI, WBEM, CIM que, si bien son realmente potentes, actualmente estn an en una fase temprana de desarrollo.
Bibliografa
215
Bibliografa
SNMP y gestin en red internet [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 edicin, 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 edicin, Addison-Wesley, 1995, ISBN 0-201-60999-1. [MIL1] Miller, Mark A. Managing Internetworks With Snmp (Network Troubleshooting Library), segunda edicin, 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 edicin revisada, Prentice Hall Series in Innovative Technology, 1996, ISBN 0134516591. [ROS2] Rose, Marshall T., McCloghrie Keith, How to Manage Your Network Using SNMP: The Network Management Practicum, Prentice Hall, 1995, ISBN 0131415174. [STA1] Stallings, William. SNMP, SNMPv2, and RMON: Practical Network Management, segunda edicin, 1996, ISBN 0201634791.
TCP/IP [BLA3] Black, Uyless D. TCP/IP and Related Protocols, segunda edicin, McGraw-Hill Series on Computer Communications, 1992, ISBN 0070055602.
216
Gestin de red
[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 edicin, Prentice-Hall, 1995, ISBN 0132169878. [COM2] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume II: Design, Implementation, and Internals, segunda edicin, Prentice-Hall, 1994, ISBN 0131255274. [COM3] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume III: ClientServer Programming and Applications, Versin Windows Sockets. Prentice-Hall, 1997. ISBN 0138487146. [FEI2] Feit, Sidnie. TCP/IP: Architecture, Protocols, and Implementation with Ipv6 and IP Security, segunda edicin, 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.
Programacin 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 edicin, 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, OReilly, 1998.
Bibliografa
217
[PEA1] Pearce, Eric, Windows NT in a Nutshell, OReilly & 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 Bible, The Waite Group, 1996, ISBN 1571690093.
Sistema de sealizacin 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 edicin, Mc Graw Hill, 1998. Gestin segn 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.
Gestin de la red B-RDSI [MIN1] Daniel Minoli, Golway Thomas. Planning & Managing ATM Networks, Prentice Hall, 1997.
218
Gestin de red
[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.
Gestin en redes de comunicaciones mviles [AB1] Barba A., Cruselles E., Mels 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., Mels J. L. Diseo de protocolos de gestin de movilidad entre redes privadas y UMTS. IX Symposium nacional de la URSI. p 1184-1189, Las Palmas de Gran Canaria, septiembre 1994. [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.
Bibliografa
219
[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.
Gestin 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. Gestin 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
221
Anexos
Anexo I: recomendaciones y normas
Recomendaciones para TMN (ITU-T) M.3000. Introduccin a la recomendacin TMN. M.3010. Principios para una red de gestin de telecomunicaciones. M.3020. Metodologa para la especificacin de la interfaz TMN. M.3100. Modelo de informacin de elementos de red genricos. M.mocs (=M.3101). Requerimientos para conformar objetos gestionados en TMN M.3100. M.3180. Catlogo de informacin de gestin TMN. M.3200. Introduccin a los servicios de gestin TMN. M.3300. Capacidades de gestin TMN presentadas en la interfaz F. M.3400. Funciones de gestin TMN. M.xfunc. Servicios de gestin TMN y funciones para la interfaz X. M.xinfo. Identificacin de la informacin que debe ser intercambiada va la interfaz X para diferentes casos de acceso.
X.282. ISO/IEC 10742. Elementos de informacin de gestin relacionados con el nivel de enlace de datos OSI. X.283. ISO/IEC 10733. Elementos de informacin de gestin relacionados con el nivel de red OSI. X.284. Elementos de informacin de gestin relacionados con el nivel de transporte OSI. Serie X.700 X.700. Marco de gestin para OSI. X.701. Visin de la gestin de sistemas. X.702. ISO/IEC 11587. Contexto de aplicacin para sistemas de gestin con procesado de transacciones OSI. X.710. Definicin de CMIS. X.711. Especificacin de CMIP. X.712. Definicin de CMIP. Proforma del protocolo PICS. X.720. Estructura de la informacin de gestin: modelo de informacin de gestin. X.721. ISO/IEC 101652. Estructura de la informacin de gestin: definicin de la informacin de gestin. X.722. Estructura de la informacin de gestin: GDMO. X.723. ISO/IEC 101645. Gestin de sistemas: informacin de gestin genrica.
222
Gestin de red
X.725. ISO/IEC 10156-7. Modelo de relacin general. X.730. ISO/IEC 101641. Modelo de informacin de red genrica. X.731. ISO/IEC 101642. Gestin de sistemas: funcin de gestin de estado. X.732. ISO/IEC 101643. Gestin de sistemas: atributos para representacin de relaciones. X.733. ISO/IEC 101644. Gestin de sistemas: funcin de recopilacin de alarmas. X.734. ISO/IEC 101645. Gestin de sistemas: funcin de gestin de recopilacin de eventos. X.735. ISO/IEC 101646. Gestin de sistemas: funcin de control de registro. X.736. ISO/IEC 101647. Gestin de sistemas: funcin de recopilacin de alarmas de seguridad. X.737. ISO/IEC 10164-14. Gestin de sistemas: clases de test de diagnstico y confianza. X.738. ISO/IEC 1016413. Gestin de sistemas. Funcin de sumario. X.739. ISO/IEC 1016411. Gestin de sistemas. Mtrica de objetos y atributos. X.740. ISO/IEC 101648. Gestin de sistemas. Funcin de pruebas de auditabilidad y seguridad. X.741. ISO/IEC 10164-9. Gestin de sistemas. Objetos y atributos para control de acceso. X.742. ISO/IEC 10164-10. Gestin de sistemas. Funcin de mtrica de contabilidad. X.744. ISO/IEC 1016418. Gestin de sistemas. Funcin de gestin del software. X.745. ISO/IEC 10164-12. Gestin de sistemas. Funcin de gestin de test. X.746. ISO/IEC 10164-15. Gestin de sistemas. Funcin de inventario. X.750. ISO/IEC 10164. Conocimiento de gestin, funcin de gestin. Otras normas de ITU-T relacionadas con gestin segn 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 descripcin de la interfaz Q3. Vigilancia de alarmas. Q.822. Descripcin de las etapas 1, 2 y 3 para la interfaz Q3. Gestin de prestaciones. Q.823. Gestin de trfico y encaminamiento. Q.824.0 - Q.824.6. Etapas 2 y 3 de descripcin de la interfaz Q3. Administracin de clientes. G.774. Modelo de informacin de gestin de SDH para los elemetos de red. G.774.01 Monitorizacin de prestaciones SDH para el elemento de red. G.774.02 Configuracin SDH de la estructura de carga para el elemento de red. G.774.03 Gestin SDH de la proteccin de la seccin multiplex para el elemento de red. G.774.04 Gestin SDH de la proteccin de la conexin de subred desde el elemento de red. G.784. Gestin SDH. G.atmn. Gestin ATM. G.mtn1 Gestin de redes de transmisin. Recomendaciones para control y gestin de B-RDSI (ITU-T) I.371. Control de trfico y control de congestin. I.35B. Prestaciones en la red B-ISDN. I.610. Principios OAM.
RFCs de IETF RFC 1089 Ttulo Autor(es) Fecha Comentarios
SNMP over Ethernet. M.L. Schoffstall, C. Davin, M. Fedor, J.D. Case. Feb 1989. none
Anexos
223
1098 1155 1156 1157 1158 1161 1187 1213 1215 1227 1270 1283 1284 1285 1286 1289 1298 1303 1351 1352 1381 1382 1407 1414 1418 1419 1420 1441 1442 1443 1444 1445 1446
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
224
Gestin de red
1447 1448 1449 1450 1451 1452
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 Mappings 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
Anexos
225
Anexo II: direcciones en Internet
Revistas Publicaciones relacionadas con programacin y gestin en Windows. http://www.entmag.com/ Maintech: el peridico 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 Pgina 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 comp.protocols.snmp info.snmp tnn.protocols.snmp comp.dcom.net-management vmsnet.networks.management.misc comp.protocols.tcp-ip microsoft.public.management. comp.protocols.tcp-ip.ibmpc comp.os.ms-windows.networking.tcp-ip microsoft.public.windowsnt.protocol.misc microsoft.public.windowsnt.protocol.tcpip comp.dcom.lans.ethernet comp.os.ms-windows.programmer.win32
226
Gestin de red
Pginas Web SNMP http://www.concentric.net/~tkvallil/snmp.html http://www.cisco.com/univercd/data/doc/cintrnet/ito/55029.htm http://www.snmpinfo.com/ http://snmp.net.cmu.edu/bin/snmpv2/ http://www.ibr.cs.tu-bs.de/cgi-bin/sbrowser.cgi http://www.phoaks.com/phoaks/comp/protocols/snmp/resources0.html CMIP y SNMP http://cio.cisco.com/warp/public/535/3.html SNMPv2 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 Estndares 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/
Anexos
227
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) Asignacin de nmeros a empresas Assigned Numbers Authority (IANA): http://www.isi.edu/div7/iana/forms.html Lista actual de asignacin de numeracin: ftp://ftp.isi.edu/in-notes/iana/assignments/ ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers Gestin de red http://netman.cit.buffalo.edu/ Gestin 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 gestin de red. http://www.cit.ac.nz/smac/nm210/ Redes y gestin de redes. http://www.ldv.e-technik.tu-muenchen.de/forsch/netmanage/netmanage_e.html Redes y gestin de sistemas, Technical University of Munich, Germany http://www.microsoft.com/products/backoffice/management/ Pgina deMicrosoft System y gestin de red http://www.mindspring.com/~jlindsay/webbased.html Pgina de gestin basada en web http://www.microsoft.com/management/ Productos de gestin Microsoft http://wwwsnmp.cs.utwente.nl/~schoenw/ietf-nm/ RFCs de gestin de red. IETF
228
Gestin de red
http://www.elec.uow.edu.au/anmf/index.html Forum de gestin de red australiano http://www.javasoft.com/products/JavaManagement/document.html Documentos de gestin de Java http://www.aetc.af.mil/AETC-NetMgmt/nms-menu.html Evaluacin de sistemas de gestin de red. http://www.phoaks.com/phoaks/comp/dcom/net-management/resources3.html Pgina de gestin de PHOAKS: comp.dcom.net-management WinSNMP http://www.winsnmp.com/ Tutoriales WinSNMP, freeware, e informacin. http://www.acec.com/snmp.htm Ace*Comm WinSNMP http://www.mg-soft.si/ MG-WinSNMP SDK, MG-WinMIB SDK, WinSNMP. Ejemplos de cdigo 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/ Pgina 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.
Anexos
229
ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/ Archivo Sun's WinSock ftp://ftp.microsoft.com/bussys/winsock/ Archivo Microsoft's WinSock, http://www.simtel.net/simtel.net/win95/winsock-pre-bydate.html Coleccin Simtel.Net Windows 95 http://ftp.sunet.se/ftp/pub/pc/windows/winsock-indstate/Windows95/Develop/ Archivo Swedish University Network, http://ftp.urz.uni-heidelberg.de/ftp/pub/net/winsock/winsock-l/Windows95/Develop/ Archivo University of Heidelberg, http://www.cyfronet.krakow.pl/ftp/simw95/simtel_winsock.html Archivo Krakow, http://www.phoaks.com/phoaks/alt/winsock/ Pginas PHOAKS alt.winsock. Ethernet http://wwwhost.ots.utexas.edu/ethernet/ Pgina Ethernet de Charles Spurgeon. http://www.lantronix.com/htmfiles/mrktg/catalog/et.htm Tutorial Ethernet
http://netlab1.usu.edu/novell.faq/nvfaq-l.htm Ethernet http://pclt.cis.yale.edu/pclt/comm/ether.htm Redes Ethernet http://www.cavebear.com/CaveBear/Ethernet/ Cdigos Ethernet http://www.phoaks.com/phoaks/comp/dcom/lans/ethernet/resources0.html Ethernet PHOAKS comp.dcom.lans. http://www.yahoo.com/Computers_and_Internet/Communications_and_Networking/LANs/Ethernet/ Pgina Ethernet Yahoo!'s TCP/IP http://www.ftp.com/ FTP Software
230
Gestin de red
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 Gua del comprador TCP/IP http://www.phoaks.com/phoaks/comp/protocols/tcp-ip/resources0.html Pgina 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. Gestin en comunicaciones mviles http://www.ee.surrey.ac.uk http://www.cdg.org http://www.gsmdata.com http://www.itu.ch http://www.etsi.fr http://www.gsmworld.com http://www.pcsdata.com
Anexos
231
Archivos de mdulos y repositorios MIB ftp://venera.isi.edu/mib/ http://smurfland.cit.buffalo.edu/ftp/pub/mibs/ ftp://ftp.3com.com/pub/mibs/ 3Com ftp://ftp.banyan.com/pub/mibs/ Banyan ftp://ftp.wellfleet.com/netman/mibs/ Bay Networks http://www.cabletron.com/support/mibs/ ftp://ctron.com/pub/snmp/mibs/ Cabletron ftp://ftp.cisco.com/pub/mibs/ http://cio.cisco.com/public/mibs/ http://www.ij.com/public/mibs/ Cisco Systems ftp://gatekeeper.dec.com/pub/DEC/mib/ Digital Equipment Corporation ftp://ftp.fore.com/pub/snmp/mibs/ FORE Systems http://http-mib.onramp.net/ HTTP MIB
Obtencin de RFCs para gestin con SNMP Para obtener RFCs desde la red, probar primero con el siguiente URL: http://www.isi.edu/rfc-editor/ En caso de tener problemas, puede probar va FTP con cualquiera de los siguientes repositorios: DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.NCREN.NET, FTP.SESQUI.NET, NIS.GARR.IT, o FTP.IMAG.FR.

Gestión de Red - Antoni Barba Martí - UPC

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestión de Red - Antoni Barba Martí - UPC

Enviado por

Direitos autorais:

Formatos disponíveis

ndice

Los autores, 1998; Edicions UPC, 1998.

1 Introduccin 1.1 Monitorizacin, control, gestin .............................................................................................16

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Anexo I: recomendaciones y normas ..................................................................................................221 Anexo II: direcciones en Internet ........................................................................................................225

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

1.1 Monitorizacin, control, gestin

Los autores, 1998; Edicions UPC, 1998.

2.1 Introduccin al sistema de sealizacin n 7 (SS7)

Fig. 2.1 Esquema de bloques de la red SS7 en un entorno de red inteligente

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Enlaces A STP Enlaces A STP

Fig. 2.2 Esquema de red SS7 con los enlaces tipo A

STP Enlaces B Enlaces SS7 Enlaces B STP

Fig. 2.3 Esquema de red SS7 con los enlaces tipo B

Los autores, 1998; Edicions UPC, 1998.

Enlaces C Enlaces C STP STP

Fig. 2.4 Esquema de red SS7 con los enlaces tipo C

Los autores, 1998; Edicions UPC, 1998.

Database Query Mode

Trunk Signaling Mode

Red MTP Enlace Fsico

Los autores, 1998; Edicions UPC, 1998.

2.2 Redes inteligentes

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Fig. 2.6 Estructura de entidades funcionales correspondiente a la red inteligente

Los autores, 1998; Edicions UPC, 1998.

Fig. 2.7 Esquema de funcionalidades del nodo SCP

Los autores, 1998; Edicions UPC, 1998.

Para simplificar, se adoptan los parmetros M como enteros, de la forma:

Los autores, 1998; Edicions UPC, 1998.

M SH , M CH y M DM y sustituimos en (*), con

Ejemplo Sean las siguientes relaciones: P C Q : : = 1 :1 :1 p c q

Los autores, 1998; Edicions UPC, 1998.

2.3 TINA (Telecommunications Information Networking Architecture).

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Fig. 2.8 Concepto de sesin en TINA

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Notacin de interfaz de flujo

Fig. 2.9 Tipos de interfaz de objeto computacional

Fig. 2.10 Objetos computacionales relacionados con una sesin de acceso

Los autores, 1998; Edicions UPC, 1998.

2.4 Creacin de servicios

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

Los autores, 1998; Edicions UPC, 1998.

3. Soluciones para la gestin de redes

3 Soluciones para la gestin de redes

3.1 Evolucin de las redes de telecomunicaciones

Impresoras Bancos de memoria

Los autores, 1998; Edicions UPC, 1998.

MUX Mdem Mdem

Los autores, 1998; Edicions UPC, 1998.