Gestión_De_Red_-_Antoni_Barba_Martí_-_UPC

Índice 7

Prólogo

Este libro pretende ser una guía introductoria al mundo de la gestión de red. A lo largo de las páginassiguientes se ha tratado de dar más una visión general de las arquitecturas y entornos de gestión de redque de definir las funcionalidades específicas de un determinado protocolo de gestión de red. Elcontenido del presente texto constituye el temario básico para la asignatura de gestión de red que seimparte en la ETSE de Telecomunicaciones de Barcelona (Universitat Politècnica de Catalunya).

Últimamente, aspectos como el control, la gestión de red o la gestión de servicios están teniendo cadavez más una mayor importancia para los operadores de red. Una de las razones fundamentales está enque los clientes cada vez exigen mayor calidad de servicio a un menor precio. El factor externo loconstituye el hecho de que actualmente, con la liberación del mercado de las telecomunicaciones, losusuarios pueden elegir libremente su operador de red. De esta forma, se ha desatado la competenciaentre operadores para mantener la mayor cuota de mercado posible. Hay que tener en cuenta que,desde un punto de vista técnico, la fidelidad del cliente se puede obtener o mantener mejor si lacalidad del servicio que proporciona el operador de red es la óptima.

En el texto se realiza una descripción pormenorizada de cada entorno de gestión; el temario que se haplanteado se divide en tres grandes áreas, empezando por la gestión de servicios, introduciendo elsistema de señalización nº 7, las redes inteligentes y TINA. A continuación, en la segunda parte,basada en los grandes estándares de gestión, se dedican varios capítulos a los protocolos,recomendaciones y estándares más utilizados. En la tercera parte, se abordan los aspectos másprácticos o de aplicación y se describe cómo se realiza la gestión en redes avanzadas como son B-RDSI o UMTS. Finalmente, se da un repaso a las plataformas y herramientas de gestión de red másimportantes disponibles en el mercado.

Índice 9

Índice

Índice

1 Introducción

1.1 Monitorización, control, gestión .............................................................................................16

2 Gestión de servicios

2.1 Introducción al sistema de señalización nº 7 (SS7).................................................................172.1.1 Arquitectura de la red SS7/CCS ..................................................................................182.1.2 Tipos de protocolos .....................................................................................................20

2.2 Redes inteligentes......................................................................................................................222.2.1 Contexto y objetivos ....................................................................................................222.2.2 Introducción a las redes inteligentes ............................................................................222.2.3 Evolución de la red inteligente ....................................................................................232.2.4 Componentes de la red inteligente avanzada (Advanced Intelligent Network, AIN)....232.2.5 Arquitectura funcional de la red inteligente.................................................................242.2.6 Dimensionado de un SCP ............................................................................................262.2.7 Modelo de llamada básico de la red inteligente...........................................................29

2.3 TINA (Telecommunications Information Networking Architecture). ....................................292.3.1 Arquitectura de computación TINA ............................................................................302.3.2 Arquitectura de servicio TINA ....................................................................................312.3.3 Arquitectura de red TINA............................................................................................322.3.4 Arquitectura de gestión TINA .....................................................................................322.3.5 Evolución de la red inteligente hacia TINA ................................................................34

2.4 Creación de servicios ..............................................................................................................342.4.1 Entorno de creación de servicios .................................................................................36

3 Soluciones para la gestión de redes

3.1 Evolución de las redes de telecomunicaciones .......................................................................373.2 Modelos para la monitorización y el control de red................................................................42

Gestión de red10

3.2.1 Arquitecturas propietarias............................................................................................423.2.2 Plataformas de gestión.................................................................................................443.2.3 Clases de productos de gestión ....................................................................................443.2.4 Productos de gestión de LANs standalone...................................................................443.2.5 Gestión de LANs de PCs .............................................................................................463.2.6 Sistemas de gestión de elementos de red de área local (LAN) ....................................473.2.7 Integradores para gestión de LANs..............................................................................48

3.3 Mecanismos para la detección de configuraciones de red ......................................................523.3.1 RPE (Regulated Poll Emission) ...................................................................................533.3.2 Modelado de la duración de un ciclo de consultas de eestatus ....................................533.3.3 Duración media del tiempo de ciclo de K intentos ......................................................543.3.4 Número esperado de intentos de polling en un ciclo ...................................................553.3.5 Flujos del ciclo de polling............................................................................................563.3.6 Análisis del retardo......................................................................................................57

4 Entornos de gestión de telecomunicación orientados a objetos

4.1 Introducción a la orientación a objetos ...................................................................................594.2 Objetos gestionados y el entorno gestor/agente ......................................................................59

5 Gestión según OSI

5.1 Modelo funcional ....................................................................................................................635.2 Modelo de organización..........................................................................................................645.3 Modelo de comunicaciones: CMIP.........................................................................................64

5.3.1 Características principales del protocolo CMIP ..........................................................665.3.2 Servicios usados por CMIP .........................................................................................675.3.3 Servicios ofrecidos por CMIP .....................................................................................675.3.4 Primitivas CMIP ..........................................................................................................685.3.5 Arquitectura de comunicaciones..................................................................................695.3.6 X/Open Abstract Data Manipulation Application Program Interface XOM ...............705.3.7 X/Open Management Protocols Application Program Interface (XMP) .....................715.3.8 CMIS/P++....................................................................................................................72

5.4 Modelo de información...........................................................................................................725.4.1 MIB (Management Information Base) .................................................................................765.4.2 GDMO (Guidelines for Definition of Managed Objects) ....................................................77

6 Red de gestión de las telecomunicaciones (TMN)

6.1 Arquitectura física...................................................................................................................836.2 Modelo organizativo ...............................................................................................................846.3 Modelo funcional ....................................................................................................................856.4 Modelo de información...........................................................................................................866.5 Implementación física de las funciones de la TMN................................................................87

Índice 11

7 Áreas funcionales de gestión

7.1 Gestión de fallos .....................................................................................................................917.1.1 Identificación de fallos en redes de comunicaciones ...................................................92

7.2 Gestión de configuración ........................................................................................................947.3 Gestión de prestaciones...........................................................................................................947.4 Gestión de tarificación ............................................................................................................957.5 Gestión de seguridad...............................................................................................................95

8 Funciones de gestión de la red de señalización

8.1 Controles de flujo MTP en la red de señalización...................................................................978.1.1 Gestión del enlace de señalización ..............................................................................988.1.2 Gestión del tráfico de señalización ..............................................................................98

8.2 Control de flujo de tráfico de señalización..............................................................................998.2.1 Gestión de rutas de señalización..................................................................................99

8.3 Control nodal MTP ...............................................................................................................1018.3.1 Controles SCCP.........................................................................................................1038.3.2 Controles de congestión automáticos.........................................................................103

8.4 Gestión de fallos ...................................................................................................................1038.5 Arquitectura de gestión de red de señalización.....................................................................104

9 Gestión de redes virtuales

9.1 Introducción ..........................................................................................................................1059.2 Estándares de VLAN ............................................................................................................1059.3 Gestión de red en VLAN ......................................................................................................105

9.3.1 Seguridad en VLAN ..................................................................................................106

10 Gestión de la red B-RDSI

10.1 Introducción a la gestión de la red B-RDSI ..........................................................................11010.2 Interfaces en la red de gestión de banda ancha. ....................................................................112

10.2.1 Interfaces definidas por el ATM Forum ....................................................................11210.3 ATM Forum..........................................................................................................................113

10.3.1 ILMI ..........................................................................................................................11310.3.2 Celdas OAM..............................................................................................................114 ......

10.4 IETF en ATM .......................................................................................................................11410.4.1 AToM: RFC 1695......................................................................................................114

10.5 Tendencias y análisis comparativo entre estándares de gestión ATM ..................................11410.6 Control de tráfico en redes ATM ..........................................................................................115

10.6.1 Calidad de servicio ....................................................................................................11510.6.2 Parámetros de tráfico .................................................................................................11610.6.3 Descriptores de tráfico...............................................................................................11710.6.4 Mecanismos de control de tráfico..............................................................................117

10.7 Funciones de control de congestión ......................................................................................11810.7.1 Control de flujo..........................................................................................................119

Gestión de red12

10.8 Recuperación en redes ATM.................................................................................................12010.8.1 Mecanismos de recuperación ATM alternativos .......................................................12010.8.2 Redes de protección ATM.........................................................................................12110.8.3 Redes reconfigurables................................................................................................12110.8.4 Redes ATM autorecuperables....................................................................................12210.8.5 Autorecuperación con backup de VPs semidedicados...............................................12210.8.6 Restauración multicapa..............................................................................................123

11 Gestión en redes de comunicaciones móviles

11.1 Introducción a las comunicaciones personales......................................................................12511.1.1 Comparación entre la gestión en sistemas cableados y sistemas

de comunicación móviles ..........................................................................................12711.1.2 Arquitectura de la red GSM.......................................................................................128

11.2 Arquitectura de las redes PCS...............................................................................................13011.2.1 Características de los sistemas basados en PCS.........................................................13011.2.2 Servicios PCS ............................................................................................................13511.2.3 Gestión de movilidad.................................................................................................13611.2.4 Gestión de recursos....................................................................................................13611.2.5 Métodos de acceso en PCS........................................................................................13711.2.6 Protocolo de señalización ..........................................................................................13711.2.7 Red inteligente para servicios personales en redes de comunicaciones

móviles avanzadas .....................................................................................................13811.3 Funciones de gestión. Objetos gestionados...........................................................................13911.4 Red inteligente y sistemas de comunicación móviles ...........................................................140

11.4.1 Características de los servicios UPT..........................................................................14011.4.2 Seguridad en la red ....................................................................................................14211.4.3 Servicios UPT de red inteligente sobre red GSM......................................................14211.4.4 Red inteligente en GSM: CAMEL.............................................................................149

11.5 Evolución de PCS hacia sistemas de tercera generación.......................................................14911.5.1 Arquitectura de la red UMTS ....................................................................................15011.5.2 Estructura de directorios en la red fija. Bases de datos distribuidas ..........................15111.5.3 Distribución de información en las bases de datos ....................................................15211.5.4 Conclusiones..............................................................................................................153

12 Gestión en Internet

12.1 Introducción ..........................................................................................................................15512.2 Evolución ..............................................................................................................................15612.3 Estructura de la información de gestión................................................................................15612.4 Sintaxis ASN.1......................................................................................................................157

12.4.1 Tipos simples.............................................................................................................15812.4.2 Tipos estructurados....................................................................................................15812.4.3 Tipos etiquetados (tagged) ........................................................................................15912.4.4 Subtipos ASN.1 .........................................................................................................159

12.5 Bases de información de gestión (MIB)................................................................................16012.5.1 MIB-I.........................................................................................................................164

Índice 13

12.5.2 MIB-II........................................................................................................................16412.5.3 MIBs experimentales .................................................................................................16812.5.4 MIBs privadas............................................................................................................169

12.6 Simple Network Management Protocol (SNMP)..................................................................16912.6.1 Operaciones de SNMP...............................................................................................17112.6.2 Codificación para la transferencia de la información de gestión: BER .....................173

12.7 Configuración y rendimiento de una red gestionada por el protocolo SNMP.......................17312.7.1 Interrogación (polling) de estatus de dispositivos......................................................17412.7.2 Interrogación (polling) de descubrimiento (Discovery) .............................................17412.7.3 Interrogación (polling) de configuración de topología ..............................................17412.7.4 Interrogación (polling) de chequeo de configuración de dispositivo.........................17412.7.5 Interrogación (polling) de estatus de estación de sondeo...........................................17412.7.6 Otras aplicaciones......................................................................................................174

12.8 Marco administrativo ............................................................................................................17512.9 Configuraciones para el uso del protocolo SNMP en entornos heterogéneos.......................175

12.9.1 Sistemas de gestión de red basados en SNMP emergentes........................................17512.9.2 Sistemas de gestión de LANs heterogéneas...............................................................17612.9.3 Valoración crítica de las MIB en SNMP ...................................................................177

12.10 Conclusiones sobre SNMP ..................................................................................................17712.11 Comparación entre los protocolos CMIP y SNMP..............................................................17712.12 SNMPv2 ..............................................................................................................................178

12.12.1 Operaciones de SNMPv2 .........................................................................................17912.13 SNMPv3 ..............................................................................................................................18012.14 Remote Network-Monitoring (RMON)...............................................................................18112.15 RMON 2..............................................................................................................................18312.16 RMON 3..............................................................................................................................184

13 Gestión distribuida

13.1 Distributed Computing Environment (DCE).........................................................................18513.1.1 Componentes principales de DCE .............................................................................18513.1.2 Restricciones en el uso de DCE.................................................................................18613.1.3 Razones para escoger DCE........................................................................................186

13.2 Distributed Management Environment (DME).....................................................................18613.3 CORBA. Gestión según OMG..............................................................................................188

13.3.1 Arquitectura CORBA ................................................................................................18913.3.2 Pasarela CORBA/CMIP ............................................................................................19113.3.3 Conclusiones..............................................................................................................192

13.4 Distributed Component Object Model (DCOM) ..................................................................19213.4.1 OLE y el modelo de objeto COM..............................................................................193

13.5 Gestión basada en agentes inteligentes móviles....................................................................19313.5.1 Introducción a los agentes inteligentes ......................................................................19313.5.2 Clases de agentes inteligentes....................................................................................19413.5.3 Agentes móviles ........................................................................................................19513.5.4 Arquitecturas de comunicaciones basadas en agentes ...............................................19513.5.5 Gestión basada en agentes .........................................................................................19713.5.6 Procesos elásticos ......................................................................................................200

Gestión de red14

14 Gestión basada en Webs

14.1 Java Management API (JMAPI) ...........................................................................................20314.2 Web-based Enterprise Management (WBEM) .....................................................................204

15 Desktop Management Interface (DMI)

15.1 Common Information Model (CIM) .....................................................................................208

16 Plataformas de gestión de red

16.1 Plataformas de gestión ..........................................................................................................20916.2 Plataforma de gestión de red OpenView ...............................................................................21016.3 SunNet Manager (SUN)........................................................................................................21016.4 IBM System View para AIX ..................................................................................................21116.5 SPECTRUM de Cabletron....................................................................................................21216.6 TME10 (Tivoli Management Environment) .........................................................................212

Conclusiones ......................................................................................................................................213

Bibliografía ......................................................................................................................................215

Anexos ......................................................................................................................................221

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

1. Introducción 15

1 Introducción

La gestión de red trata sobre la planificación, la organización, la supervisión y el control de elementosde comunicaciones para garantizar un adecuado nivel de servicio, y de acuerdo con un determinadocoste. Los objetivos principales de la gestión de red consisten en mejorar la disponibilidad y elrendimiento de los elementos del sistema, así como incrementar su efectividad.

Desde el momento en que las redes se consideran cada vez más una parte importante y estrátegica delas empresas, industrias u otros tipos de instituciones y como resultado de las cada vez mayoresdimensiones que están adoptando, resulta pues más importante su control y gestión con el fin deobtener la mejor calidad de servicio posible.

Tradicionalmente, en la gestión de las redes se ha partido de soluciones propietarias y cerradas con unámbito de actuación limitado a la propia empresa o dominio de la institución. Con el tiempo, laevolución tecnológica ha permitido la entrada de múltiples fabricantes de equipos, de la misma formaque otros fabricantes de reputado nombre han desaparecido y, en consecuencia, también el apoyo queprestaban a sus soluciones de red. Por tanto, bien sea porque ha ocurrido la absorción de empresas obien por diversificación de las fuentes de los equipos, las redes actuales son cada vez másheterogéneas en equipos.

Uno de los problemas más graves que tienen estas redes es que los equipos que las constituyen son defabricantes distintos, con lo cual la única forma de gestionarlas es a partir de sistemas de gestión queutilicen estándares abiertos con el fin de compatibilizar protocolos e información. De esta forma,durante la década de los noventa, se han ido desarrollando diversas iniciativas con el objetivo deofrecer recomendaciones y estándares abiertos para tratar de dar solución a estas nuevasproblemáticas, como por ejemplo mediante el protocolo de gestión SNMP o el CMIP.

Para proporcionar una calidad de servicio adecuada mediante la gestión de redes, se parte de unosrecursos humanos que mediante una serie de herramientas aplican unas determinadas metodologías ala red. Este texto versa sobre herramientas y métodos que se pueden emplear en la gestión de red. Lasrecomendaciones sobre esta temática provienen de diversos grupos de estandarización. La másimportante, la ITU–T, ha definido la red de gestión de las telecomunicaciones (TMN). Estasrecomendaciones definen cinco áreas funcionales para la gestión de red, las de supervisión y fallos,configuración, tarificación, prestaciones y seguridad.

La organización de la gestión puede estructurarse también según un criterio temporal. De esta forma,se puede hablar de un control operacional que opera a muy corto plazo y a bajo nivel, unaadministración que opera a corto plazo y a bajo-medio nivel, un análisis de la gestión que opera amedio plazo y a medio-alto nivel y finalmente una planificación a largo plazo y a más alto nivel.

© Los autores, 1998; © Edicions UPC, 1998.

Gestión de red16

En el control operacional, las operaciones realizadas a este nivel deben quedar registradas, para suposterior análisis por el administrador de red. Es el caso de operaciones tales como la recogida dedatos sobre prestaciones y utilización de la red, la evaluación de alarmas, la diagnosis de problemas, elarranque y la parada de los componentes de la red, la ejecución programada de pruebas preventivas, lamodificación de configuraciones o la carga de nuevas versiones de software.

Las funciones principales de la administración consisten en seguir las tareas de control operacional yen elaborar informes periódicos para su posterior análisis. Por ello se ocupa de tareas como laevaluación de la calidad de servicio, la evaluación de tráfico, el mantenimiento de registro histórico deproblemas, el mantenimiento de inventario, el mantenimiento de configuraciones, la contabilidad dered y de control de acceso. El objetivo del análisis es garantizar la calidad de servicio y, finalmente, laplanificación se encarga de las decisiones dependientes del negocio al que se dedica la empresa.

1.1 Monitorización, control, gestión

Llegados a este punto, sería conveniente distinguir entre monitorización, control y gestión de una red.Se utiliza el término monitorización para designar el tipo de acciones consistentes en obtenerinformación de la red con el fin de detectar anomalías. Estas acciones son pasivas y su único objetivoes conocer el comportamiento respecto al tráfico del sistema. Una vez se conoce el sistema se puedeproceder al control: para ello se establece una señalización o plano de control en toda red que se ocupade regular activamente las comunicaciones y, en general, el tráfico de la red. Un ejemplo de red decontrol es el sistema de señalización nº 7. Finalmente, la gestión se define a partir del plano de gestiónque integran las redes más avanzadas como RDSI, GSM, etc. Como ejemplo de red de gestión sepuede citar la TMN (Telecommunications Management Network) definida por la ITU-T.

Según las áreas funcionales de gestión definidas por la ITU-T, la monitorización de red se utiliza paraproporcionar información en la gestión de las funciones de prestaciones, fallos, contabilidad y endeterminados aspectos de configuración, mientras que el control de red se aplica a las funciones deconfiguración y seguridad.

En el proceso de monitorización de la red se consideran una serie de aspectos como son: en primerlugar, una definición de la información de gestión que se monitoriza, una forma de acceso a lainformación de monitorización, un diseño de los mecanismos de monitorización y, finalmente, unprocesado de la información de monitorización obtenida. Por otra parte, la información demonitorización puede clasificarse según su naturaleza temporal en: información estática que sealmacena en los elementos monitorizados (p.e. inventario); información dinámica que se almacena enlos propios elementos o en equipos especializados (p.e. cambios de estado o fallos) e informaciónestadística que se genera a partir de la información dinámica y que puede residir en cualquier lugarque tenga acceso a la información dinámica (p.e. rendimientos). Los mecanismos de monitorización sebasan fundamentalmente en un sondeo o polling por parte de la estación gestora, esto es, en un accesoperiódico a la información de gestión almacenada en los nodos gestionados. Este método tiene laventaja de que los objetos que se gestionan únicamente deben estar preparados para responder, con loque es más simple. Otros mecanismos que se emplean, desde el punto de vista del agente gestionado,se denominan event reporting o notificaciones, donde son los propios recursos quienes envíanmensajes bajo ciertas condiciones; de esta forma tienen como ventaja el hecho que se minimiza eltráfico de gestión por la red. Otros métodos son mixtos, se basan en proxies, sondas, etc, y combinanlos dos mecanismos anteriores.


2. Gestión de servicios 17

2 Gestión de servicios

Una parte cada vez mayor de los ingresos que obtienen los operadores de red parte de los servicios devalor añadido que aportan los proveedores de servicios. Para soportar estos servicios se hace necesariouna infraestructura basada en las redes inteligentes y cada vez más en lo que se ha denominadoúltimamente inteligencia de red basada en estándares, como por ejemplo TINA.

2.1 Introducción al sistema de señalización nº 7 (SS7)

La red de señalización nº 7 (también denominada Channel Common Signalling, CCS) es la red que seocupa de la señalización y constituye el soporte básico de las redes inteligentes. Esta red se define deforma separada de la red de transporte de información. En su forma básica consta de nodos llamadospuntos de señalización (SPs) interconectados por enlaces de transmisión. La red se constituye con lossiguientes tipos de nodos:

Service Switching Point (SSP). Punto de conmutación de servicioSignal Transfer Point (STP). Punto de transferencia de señalService Control Point (SCP). Punto de control de servicioIntelligent Peripheral (IP). Periférico inteligente

y de diversas configuraciones de interconexiones entre los nodos, formadas por Signaling Links (SLs)o enlaces de señalización [BLA2, RUS1].

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

SSP

AD/SN

STPIP

SCE SMS SCP SDP

Local

LocalTerminal del

usuario A

Terminal delusuario B

Red de señalización SS7

RTC

SCP: Punto de control de serviciosSSP: Punto de conmutación de ServiciosSTP: Punto de transferencia de señalizaciónSMS: Sistema de gestión de servicios

IP: Periférico inteligenteSDP: Punto de datos de servicios


Gestión de red18

La red SS7 constituye la base de la red inteligente y de lo que se ha venido a llamar más recientementeinteligencia de red. En los próximos capítulos se describirán más pormenorizadamente sus funcionesy componentes.

2.1.1 Arquitectura de la red SS7/CCS

La arquitectura de la red SS7/CCS (señalización por canal común) está formada por nodos y diversostipos de enlaces que están configurados de forma que aporten la máxima fiabilidad al sistema. Acontinuación se describen las características principales de estos tipos de nodos.

Punto de conmutación de servicio (SSP)

Los puntos de conmutación de servicio (SSP) son centros de conmutación equipados para manipularseñalización troncal así como señalización de servicios o servicios de transacciones con las bases dedatos dentro y fuera de la red. También transfieren mensajes SS7 a otros puntos de señalización dentrode la red.

Los puntos de señalización se despliegan en pares, por cuestiones de redundancia y diversidad; de estaforma en caso de fallo siempre puede desviarse el tráfico por rutas alternativas. El objetivo consiste enmantener el máximo del tiempo posible la red operativa.

Punto de transferencia de señal (STP)

Los STP o conmutadores de alta fiabilidad que enrutan mensajes SS7 entre los nodos de la red y sebasan en la información del propio mensaje o bien en información almacenada en tablas deencaminamiento. Se despliegan de forma separada para permitir mayor fiabilidad al sistema yasegurando la duplicidad del software.

Los STP proporcionan una transferencia de mensajes eficiente entre todos los nodos de señalizaciónen una red SS7. Pueden realizar funciones de gateway para transferir mensajes de señalización a otrasredes de señalización SS7 (uso de MTP). También el encaminamiento especializado es función delSCCP (acceso a bases de datos). Cada número concreto accede a un servicio diferente. Existe unatabla en cada STP que indica para cada número el SCP y el enlace que se debe utilizar para enviar elmensaje.

El número de enlaces en cada ruta suele ser de 1 a 16. Los STP utilizan enlaces para susinterconexiones que suelen calcularse para un 40 % de su capacidad. La idea es que si uno de ellos(enlace o STP) falla, el otro soporte hasta un 80 % de tráfico, dentro todavía del margen decapacidades. Cada enlace de su grupo de enlaces se identifica con un Signaling Link Code (SLC).

Los enlaces que conectan centrales entre sí y/o tándems de acceso y SCP's a STPs se denominanenlaces de acceso o enlaces A. Cada nodo se conecta como mínimo con un par de nodos jerárquicos(superiores e inferiores) para mayor fiabilidad.

Cada SCP suele tener un mínimo de tres enlaces y un máximo de cinco enlaces a cada par de STPs alos que está conectado. Se trata de una limitación por hardware (existente en centrales de AT&T),según el número de tarjetas front-end (a 2 enlaces por tarjeta) que puede soportar el SCP.



SCP SCP

STP

SP

Enlaces A

STP

SP

Enlaces A

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

Los enlaces B (o enlaces puente) se establecen entre pares de STP en el mismo nivel jerárquico (p.e.regiones distintas). En este caso se aconseja una diversidad de tres caminos para cada conjunto deenlaces, con un máximo de ocho enlaces.

STP

Enlaces B

STP

Enlaces B

STP STP

Enlaces SS7

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 dosenlaces para cada conjunto de enlaces. La principal función de los enlaces C es llevar mensajes degestión de red. Se implantan al menos dos STP por región.


Gestión de red20

STP

Enlaces C

STP

Enlaces C

STP STP

Enlaces SS7

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

Los enlaces en diagonal o enlaces D conectan STPs de diferentes niveles jerárquicos (p.e. STP local ySTP regional). Generalmente se disponen con al menos tres rutas alternativas. Cada conjunto deenlaces tiene un máximo de ocho enlaces.

Los enlaces que conectan SPs a STPs diferentes del par asociado originariamente se denominanextended links o enlaces E. Un mínimo de uno y un máximo de 16 enlaces E se utilizan desde cadaSP/SSP para conectar a sus compañeros STPs en una nueva área de servicio. Los enlaces F o fullyassociated links se conectan directamente entre SPs/SSPs siempre que no hayan STPs. Como máximose utilizan16 enlaces y no hay conexión a nodos inteligentes de la red. Los nombres de estos enlacessólo determinan las funciones que realizan puesto que físicamente son idénticos.

En una configuración en un único nivel, un par de STPs proporciona todos los encaminamientos demensajes de señalización dentro de su área de servicio. Esto incluye mensajes database query type ycall setup type. En la configuración a dos niveles, existen pares de STPs a nivel local (LSTP) y paresde 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 clientesy lógica de servicio para responder a peticiones procedentes de SSPs. Por ejemplo, convertir números800 (900) en encaminamientos para números de la red básica, validar números, etc. Se despliegan deforma 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 dedatos 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 formadiferente según los nodos a los que conecta. Son enlaces síncronos bidireccionales a 64Kbps (56 Kbpsen U.S.).

El protocolo SS7 es el modelo en capas que cubre la comunicación entre nodos inteligentes en la redCCS.



MTP

Físico

Enlace

Red

SCCP

TCAP ISDN-UP

DatabaseQueryMode

TrunkSignalingMode

OMAP

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 atodas las aplicaciones de los niveles superiores, selección del enlace de señalización, detección ycorrección de errores, conexión física a los enlaces. También proporciona gestión de red para elcontrol de flujo en caso de congestión de la red.

A nivel de red el protocolo proporciona encaminamiento dentro de la señalización de red, control defallos y congestión de la red y distribución de la carga. Sus tareas se dividen en tres funciones:

Señalización de gestión de tráfico.Señalización de gestión de enlaces.Señalización de gestión de rutas.

Signaling Connection Control Part (SCCP)

SCCP ( Signaling Connection Control Part): contiene funciones de transporte de alto nivel necesariaspara soportar partes de aplicación de alto nivel. Proporciona funciones de encaminamiento, serviciosorientados a conexión y no orientados a conexión. También se ocupa de la gestión de bases de datosduplicadas.

Integrated Services Digital Network - User Part (ISDN-UP)

ISDN-UP: proporciona control de llamada para ISDN (RDSI) y mensajes de señalización entrecentrales.


Gestión de red22

Transaction Capabilities Application Part (TCAP)

TCAP (Transaction Capabilities Application Part): soporta la transferencia de información que noestá asociada con el circuito de control, por ejemplo la petición/respuesta de la base de datos tipo 800.

Operations Maintenance Administration Part (OMAP)

El protocolo OMAP (Operations Maintenance Administration Part) se ocupa de las siguientesfuncionalidades de red: prestaciones, monitorización, encaminamiento y verificaciones.

2.2 Redes inteligentes

En este apartado se describen las ideas fundamentales de lo que constituye la integración de losservicios de valor añadido en las redes de telecomunicaciones. El tipo de sistema resultante sedenomina red inteligente [FAY1, BLA1].

2.2.1 Contexto y objetivos

Las redes inteligentes surgen como una aplicación de las funcionalidades del sistema de señalizaciónnº 7. Esta infraestructura de señalización común es la que permitirá más adelante el rápido desarrollo,desde un punto de vista técnico, de los servicios de la red inteligente.

Esta red inteligente que va evolucionando hacia una red inteligente avanzada (Advanced IntelligentNetwork, AIN) tiene que verse también en el contexto de la red de gestión de las telecomunicaciones(Telecommunications Management Network, TMN) y al mismo tiempo con los avances que se estánproduciendo hacia la especificación de lo que es TINA.

Los objetivos de este apartado consisten en especificar e introducir los conceptos básicos de las redesinteligentes mostrando la evolución que han seguido los servicios a partir de la integración deordenadores en los elementos de red del sistema. Se trata también de establecer una relación entre losconceptos de señalización, gestión de red y red inteligente.

2.2.2 Introducción a las redes inteligentes

La red inteligente es inteligente porque es programable, es decir, la introducción de ordenadores y, portanto, de software en los nodos de la red permite configurar mediante programación elcomportamiento, los servicios y, por tanto, la inteligencia del sistema.

El motivo básico del desarrollo de esta red es el de obtener mayores beneficios para el operador dadoque aumenta el tráfico telefónico y también los ingresos debido a las suscripciones de los usuarios alos nuevos servicios. Otro nuevo factor de beneficio se deriva del hecho que una red con ordenadoresintegrados permite obtener una inteligencia de red y gestionar mejor los recursos del sistema con elfin de optimizar el rendimiento y reducir costes en el servicio.



Por otra parte, la red inteligente está diseñada para permitir una creación y/o modificación de losservicios de forma sencilla y rápida con el fin de adaptarse fácilmente a las continuas y cambiantesdemandas de los clientes.

Por último, el surgimiento de nuevos servicios e infraestructuras de tipo inteligente obedece, engeneral, a la continua evolución tecnológica de los sistemas de comunicaciones.

Los tipos de servicios diseñados para la red de comunicaciones pueden ser servicios de red quecomportan un flujo de señalización para mejorar la transferencia de la información, o bien servicios devalor añadido que comportan un flujo de datos para mejorar el proceso de información. Sonúnicamente estos últimos, los servicios de valor añadido, los que se consideran específicos de lasredes inteligentes.

La ITU-T ha especificado una serie de servicios inteligentes conocidos como CS1 (CapabilityServices 1), más recientemente ha aparecido un nuevo conjunto denominado CS2 y se está trabajandoen la especificación de un CS3. Dentro de los tipos de servicios CS1, en los que se basan la granmayoría de infraestructuras de operadores de servicio actuales, pueden citarse los siguientes: serviciosde tarificación en llamadas (números 900,...), servicios de encaminamiento, numeración,captura/entrega de información u otros servicios de valor añadido. Finalmente, entre los serviciosespecificados en CS2 destacan los servicios de interconexión con otras redes, multiconferencia,movilidad personal, movilidad de terminal y servicios multimedia, así como la creación y gestión deestos servicios (CS2/CS3).

2.2.3 Evolución de la red inteligente

Desde un principio, la red inteligente partió de los sistemas de comunicaciones basados en un controlpor programa almacenado (Stored Program Control, SPC). Es decir, el primer paso se constituyó conla incorporación en las primeras centrales de un control basado en una unidad de proceso (ordenador).Posteriormente se introdujeron en las centrales mecanismos de conmutación digital y los sistemas detransmisión digital. Llegados a este punto, todo estaba preparado para la implementación de una redde señalización por canal común. Esta red de señalización, basada en el protocolo nº 7, permitió quelas centrales de comunicaciones pudieran transferir la información de control de forma más adecuaday, por tanto, se entendieran mejor entre ellas para poder pasar a introducir una inteligencia en la red.La introducción de los servicios según la demanda de los clientes dió lugar finalmente a la redinteligente actual.

2.2.4 Componentes de la red inteligente avanzada (Advanced Intelligent Network, AIN)

La red CCS (Common Channel Signaling) consta de nodos llamados puntos de señalización (SPs)interconectados por enlaces de señalización. La arquitectura AIN incluye nuevos sistemas de redfísicos y sistemas operativos, así como nuevo software para los sistemas de red y sistemas deoperación existentes. La AIN integrada en la red básica permite operar a ordenadores inteligentes,llamados nodos, localizados en la red CCS. La red inteligente incluye en su forma básica lossiguientes nodos:

Service Switching Point (SSP). Punto de conmutación de servicioSignal Transfer Point (STP). Punto de transferencia de señal


Gestión de red24

Service Control Point (SCP). Punto de control de servicioService Management System (SMS). Sistema de gestión de serviciosSignaling Links (SLs). Enlaces de señalización

Además, la red inteligente suele dotarse también de los siguientes elementos:

Intelligent peripheral (IP). Periférico inteligenteService Data Point (SDP). Punto de datos del servicioService Creation Environment (SCE). Entorno de creación de serviciosAdjunct (AD). AdjuntoServices 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 yse denomina INAP (Intelligent Network Application Protocol, INAP). A continuación, se describencon mayor detalle los nodos que constituyen la red.

SMS: realiza funciones de mantenimiento, administrativas y de provisión para los SCPs. Tambiénrealiza la función de creación de servicios.

SCP: simbolizados por triangulos, para mostrar sus capacidades para realizar decisiones. Los AINSCPs contienen programas lógicos de servicios que reflejan los servicios de clientes y que interactúancon SSP para gestionar decisiones en el procesado de llamadas.

STP: como STP, proporcionan servicio de encaminamiento en la red de forma ininterrumpida.

SSP: dispone de software especial para proporcionar servicios AIN.

IP (Intelligent Peripherals): añaden funciones de comprensión a la red tales como reconocimiento devoz, síntesis y anuncios de voz específicos.

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 servicioslimitada a determinados clientes. Los NAP no acceden a las AIN SCPs pero proporcionan serviciosAIN a través de conexiones a AIN SSPs.

El SSP tiene un software especial que permite proporcionar servicios AIN. El SSP cuando es alertadopor mecanismos de disparo de peticiones de servicio AIN, suspende la función de procesado de lallamada. Envía un mensaje de consulta a través de la red CCS al SCP para pedir instrucciones por elprocesado 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 unaabstracción que facilita la definición de interfaces abiertos y normalizados para posibilitar la creaciónde servicios avanzados y abiertos en un entorno multifabricante.



El modelo conceptual define las estructuras lógicas y funcionales, así como las características de losservicios básicos. Se puede estructurar en los cuatro planos siguientes: plano de servicio (perspectivadel usuario), plano funcional global (perspectiva del diseñador del servicio), plano funcionaldistribuido (relacionado con la arquitectura de la red) y plano físico (relacionado con la arquitecturade la red).

El plano de servicio presenta una descripción del servicio desde el punto de vista del usuario. Se tratade una visión orientada al servicio en la que no hay información sobre la realización de los serviciosen la red. En el plano funcional global se da una visión de las distintas funcionalidades de una redinteligente, que se considera una entidad única que contiene el modelo de proceso de llamadas y losbloques constructivos independientes del servicio (SIBs). En el plano funcional distribuido seespecifica la distribución de las funciones de una red inteligente mediante entes funcionales (FEs) yacciones de entes funcionales (FEAs). Finalmente, en el plano físico se indica la forma deimplementar la red inteligente. Se identifican los distintos tipos de entes físicos (PEs), las FEs querealizan y los protocolos que emplean para comunicarse.

A continuación se presentan las entidades funcionales definidas en la primera fase de especificaciónde servicios (CS1):

CCF: función de control de llamadas (tareas clásicas: señalización, reserva de circuitos,...).CCAF: función de agente de control de llamadas (intermediario entre usuarios y procesos de llamadasanalógicas, RDSI,...).SSF: función de conmutación del servicio (intercepta llamadas de IN).SCF: función de control de servicio (lógica de control de los servicios de IN).SRF: funciones de recursos especializados (interacciones con usuario: DTMF/voz, anuncios,...).SDF: función de datos del servicio (acceso a datos de servicio y red).SMF: función de gestión del servicio.SCEF: función de entorno de creación de servicios.SMAF: función agente de gestión de servicios.

SSF

SCF

SDF

SMF

SMAF

SCEF

CCF

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


Gestión de red26

Se puede establecer una correspondencia entre entidades funcionales y entidades a nivel físico (FEs-PEs) para cada nodo de la arquitectura. De esta forma, un SSP dispone de las funciones SSF/CCF yopcionalmente puede incluir SCF, SRF o SDF. Un SCP dispone de SCF y opcionalmente puedeincluir SDF. Un nodo IP dispone de SRF. Un Adjunto dispone de SCF y SDF. Finalmente, un nodo deservicio dispone de SSF/CCF, SCF y SDF y opcionalmente puede incluir una SRF.

2.2.6 Dimensionado de un SCP

En este apartado se presenta un posible diseño para dimensionar un nodo SCP. El nodo sedescompone en una serie de entidades funcionales [ATS1]. A continuación se describe la notaciónbásica que se ha empleado:

DMF: Data Managing FunctionCHF: Communication Handling FunctionSHF: Service Handling FunctionSSP: Service Switching PointSH: Service HandlerCH: Communications HandlerDM: Data Manager

Fig. 2.7 Esquema de funcionalidades del nodo SCP

Sea la DMF la función de procesado de la llamada, la CHF la función que realiza de interfaz decomunicaciones con el módulo SSP y la SHF el programa del servicio lógico que ejecuta el SLP.

Sean:

SHM : número de SH’s.

CHM : número de CH’s

DMM : número de DM’s

SHt : tiempo de procesado en SH permitido para una única llamada (s).

CHt : tiempo de procesado en CH permitido para una única llamada (s).

DMt : tiempo de procesado en DM permitido para una única llamada (s).

SSP

SMSDMFSHF

CHF SCP



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: condición de tráfico: número máximo de llamadas procesadas simultáneamente.

El coste K para un único servicio y para un único SCP es:

=++= DMDMCHCHSHSH MKMKMKK (*)

+

+

+

+

+

= 111

DMDM

CHCH

SHSH qt

QVK

ct

CVK

pt

PVK

Con:

SHK : coste para un único SH.

CHK : coste para un único CH.

DMK : coste para un único DM.

0,0,0 ≥≥≥ DMCHSH ttt Tttt DMCHSH ≤++

Para simplificar, se adoptan los parámetros M como enteros, de la forma:

+

+

=

DMDM

CHCH

SHSH qt

QVK

ct

CVK

pt

PVKK *

si Tttt DMCHSH =++

( )

−−

+

+

=

SHCHDM

CHCH

SHSH ttTq

QVK

ct

CVK

pt

PVKK *

Para obtener una solución de coste mínimo se igualan las derivadas parciales de cada variable a cero:

0**

=∂∂=

∂∂

CHSH t

K

t

K

Se obtiene:


Gestión de red28

q

QK

c

CK

p

PK

p

PKT

t

DMCHSH

SH

SH

++

=

q

QK

c

CK

p

PK

c

CKT

t

DMCHSH

CH

CH

++

=

q

QK

c

CK

p

PK

q

QKT

t

DMCHSH

DM

DM

++

=

obtenemos SHM , CHM y DMM y sustituimos en (*), con

KK ≈*

Ejemplo

Sean las siguientes relaciones: 1:1:1:: =q

Q

c

C

p

P

Fracciones de tiempo procesando en cada módulo: ( ) ( )136.0,096.0,068.0,, =DMCHSH ttt

3.7:4.10:7.14:: =DMCHSH MMM

4:2:1:: =DMCHSH KKK

*K donde ( ) 3.0=++ DMCHSH ttt

Una llamada se procesa por un único módulo para cada tipo de función. La proporción de tiempoinvertido para procesar en cada módulo viene dada por:

q

Q

c

C

p

P::

Por otra parte, se desprecia el retardo en las conexiones entre módulos.



2.2.7 Modelo de llamada básico de la red inteligente

Para proporcionar los servicios de red inteligente, algunas funciones de procesado de la llamada sedesplazan desde el conmutador y se convierten en programas lógicos de servicio residentes en el SCP.Estos programas lógicos de servicio interactúan con información enviada desde el SSP paraproporcionar direcciones de control de llamada. ¿Cómo el SSP determina qué tipo de información delcliente se envía al SCP? Se dirige funcionalmente por el modelo de llamada básico de la redinteligente.

Este modelo de llamada básico define puntos en llamada (PIC) como posiciones que proporcionancinco áreas de disparo lógico, denominadas puntos de detección de disparo (TDPs), donde lainformación almacenada se transfiere al SCP.

Un trigger es la traslación de un software que puede emplazarse en contra de las líneas de un cliente oun código de dial seleccionado dentro del plan de dialing de oficina. Cada punto de detección dedisparo puede proporcionar multiples disparos. La información recogida en un punto de detección dedisparo es lo que define un tipo de servicio AIN. Un ejemplo de tipo de servicio es el número dellamante recogido en el punto de detección de disparo del intento originante y que podría usarse paraproporcionar un servicio de dialing activado por voz.

Tal como se ve en el modelo, no todos los puntos en la llamada tienen puntos de detección de disparo,y por eso no pueden disparar la transmisión de información recogida en el punto de control de servicio(SCP). Los puntos en llamada representan una secuencia de acciones de procesamiento de llamadabasadas en el conmutador.

Para proporcionar servicios AIN, los disparos en el SSP deben interactuar con los programas lógicosde servicio del SCP. Los programas lógicos de servicio proporcionan la lógica que determina losservicios disponibles al cliente. El mensaje desde el SSP contiene información que permite al SCP elregistro del grupo cliente que contiene el programa lógico de servicio.

2.3 TINA (Telecommunications Information Networking Architecture).

El consorcio TINA (TINA-C) comprende la mayor parte de los grandes operadores de red yfabricantes de ordenadores, y fue fundado en 1992 [INO1]. El principal logro de la arquitectura TINAes proporcionar una arquitectura de servicios de redes de servicios de telecomunicaciones. Especificauna plataforma distribuida orientada a objetos, basada en el estándar OMG CORBA, y unaarquitectura de aplicación de telecomunicaciones. Proporciona una arquitectura de red de informaciónde 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 lossistemas de gestión como aplicaciones basadas en software que operan en una plataforma decomputación distribuida CORBA. Para ello, se intenta obtener un entorno de desarrollo deaplicaciones de red, gestión y operaciones que sean de fácil utilización y mantenimiento. El trabajo deTINA-C ha sido fuertemente influenciado por las especificaciones de INA definidas por Bellcore. Sibien las especificaciones de TINA fueron confidenciales hasta 1995, actualmente se pueden consultaren el web: http://www.tinac.com/.


Gestión de red30

TINA surgió como solución a los nuevos servicios de telecomunicaciones que requieren un acceso yuna gestión más flexibles de lo que las redes actuales pueden proporcionar. La arquitectura se basa encomputación distribuida, orientada a objetos, y en otros conceptos y estándares de las industrias detelecomunicaciones y ordenadores, como ODP, IN, TMN, ATM, CORBA. La arquitectura TINA seestructura en cuatro grandes áreas: arquitectura de computación, arquitectura de servicio, arquitecturade red y arquitectura de gestión.

- Arquitectura de computación: esta arquitectura define un conjunto de conceptos y principios para eldiseño y construcción de software distribuido y el entorno de soporte de software, basado enprincipios orientados a objetos. Esta arquitectura está basada en el modelo de referencia paraprocesado distribuido abierto (RM-ODP).

- Arquitectura de servicio: define un conjunto de conceptos y principios para el diseño, especificación,implementación y gestión de servicios de telecomunicaciones. Pueden identificarse tres conceptosfundamentales: conceptos de sesión, relacionados con actividades de servicios y relacionestemporales, conceptos de acceso, relacionados con asociaciones de terminal y usuario con redes yservicios, y conceptos de gestión, relacionados con temas de gestión de servicios.

- Arquitectura de red: define un conjunto de principios y principios para el diseño, especificación,implementación y gestión de redes de transporte. Aspectos básicos de esta arquitectura es el modelode información de recursos de red genéricos, la definición de los grafos de conexiones queproporcionan una visión de conectividad orientada al servicio, y la gestión de conexiones.

- Arquitectura de gestión: define un conjunto de conceptos y principios para el diseño, especificacióne implementación de sistemas de software que se usan para gestionar servicios, recursos, software, asícomo otras tecnologías subyacentes.

2.3.1 Arquitectura de computación TINA

La arquitectura de computación define los conceptos de modelado que deberían de usarse paraespecificar el software orientado a objetos en sistemas TINA. Además define un entorno de procesodistribuido (DPE) que proporciona un sistema de soporte que permite a los objetos localizar einteractuar entre ellos. Estos conceptos se basan en el Reference Model for Open DistributedProcessing (RM-ODP).

El modelado computacional utiliza los objetos computacionales como las unidades de programación yencapsulación. Los objetos interactúan entre ellos mediante el envío y la recepción de informacióna/desde interfaces. Un objeto puede proporcionar muchas interfaces, del mismo o diferente tipo.Existen dos tipos de interfaces: operational interface y stream interface (fig. 2.9).

- Una interfaz operacional define operaciones que permiten que funciones de un objeto que ofrece(servidor) sean invocadas por otros objetos (clientes). Una operación puede tener argumentos deentrada y devolver resultados.

- Una interfaz de flujo no tiene operaciones, es decir, no hay parámetros de entrada/salida, peticiones,resultados o notificaciones. El establecimiento de un flujo entre este tipo de interfaces permite el pasode otras informaciones estructuradas, tales como flujos de bits de vídeo o voz. Estos flujos seestablecen mediante la interacción con componentes de red y servicio.



Las interfaces se especifican independientemente de cualquier lenguaje de programación medianteuna notación específica. Esta notación se denomina TINA Object Definition Language (TINA ODL),y es una extensión del Object Management Group´s Interface Definition Language (OMG IDL). Ellenguaje consiste en un conjunto de plantillas que permiten la especificación de las entidades decomputación TINA básicas: bloques de construcción, objetos e interfaces.

Los conceptos de modelado de la información permiten ver el estado, las relaciones y elcomportamiento de las entidades de información en el dominio del problema bajo estudio (notacióncasi GDMO-GDR).

Los conceptos de modelado de ingeniería definen la máquina TINA-C abstracta que se basa en unentorno 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 detelecomunicaciones, de gestión o de usuario final). Desde el punto de vista de computación describecómo debería estar estructurado un servicio distribuido para proporcionar sus funciones al usuario.Para ello, identifica componentes software en tiempo de ejecución (run-time) tales como: agentes deusuario, agentes terminal, sesión de servicio, gestor de suscripciones o gestor de sesión decomunicaciones.

La capa de servicio TINA pasa sus requerimientos de gestión en forma de Management Contexts(MgmtCtxt), que se transportan por una construcción denominada transacción de servicio. Si bien lacapa de recursos TINA se construye siguiendo una estructura DPE, es plenamente interoperable conTMN. Por otra parte, TINA se orienta a sesión por lo que se obtiene un nuevo conjuntos de funcionesde gestión representadas por MgmtCtxts en cada sesión de servicio. Las fases de transacción de unservicio son tres:

Fase de set-up: se interpretan los MgmtCtxts y se reservan los recursos necesarios.Fase de ejecución: una vez se ha autorizado el acceso, se ejecuta la sesión de servicio TINA.Fase de wrap-up: se informa de la gestión (QoS) si es necesario.

Fig. 2.8 Concepto de sesión en TINA

Sesión deusuario

Sesión deusuario

Sesión deacceso

Sesión deacceso

Sesión decomunicación

Sesión de servicio

Gestión de red32

Con TINA se reemplaza el concepto de llamada por el de sesión, entendiendo este último como elpropósito de un servicio de realizar un conjunto de actividades durante un periodo específico detiempo. Se definen cuatro tipos específicos de sesiones desde el punto de vista de la información quetratan: sesión de servicio, sesión de comunicación, sesión de usuario y sesión de comunicación. En lafigura 2.8 se relacionan gráficamente estos tipos de sesión. Las sesiones de comunicaciones y sesionesde acceso son independientes del servicio, mientras que las sesiones de servicio y sesiones de usuarioson dependientes del servicio. El propósito de estos conceptos de sesión es separar los diferentesámbitos y promocionar la distribución de funcionalidad.

2.3.3 Arquitectura de red TINA

La arquitectura de red intenta proporcionar un conjunto de conceptos genéricos que describen redes detransporte de una forma independiente a la tecnología (Network Resource Information Model, NRIM).El NRIM define un modelo de recursos de red que proporciona las abstracciones necesarias alsoftware de servicio. El software de servicio usa NRIM cuando se necesitan establecer las conexionesde red y cuando el servicio es responsable de la gestión de un conjunto de recursos de la red (subredes,elementos de red, pistas, conexiones, etc). Se pueden considerar los siguientes niveles de gestión:

Nivel de elementos de red: aspectos referidos a la información requerida para gestionar recursos deequipos específicos proporcionada por las funciones de la capa de elementos de red.Nivel de gestión de recursos: información para la representación de la red, tanto lógica comofísicamente.Nivel de gestión de servicios: gestión de software de los servicios, configuración de los servicios, yutilización de recursos para proporcionar el servicio.

El concepto de grafo de conexión se utiliza para proporcionar una visión de conectividad orientada alservicio. Un grafo de conexiones presenta vértices y puertos, con puertos conectados por líneas pararepresentar conectividad. Hay dos tipos de grafos de conexiones: grafos de conexión lógica donde losvértices representan objetos, los puertos representan interfaces de flujos y las líneas flujos. En cambio,en el grafo de conexiones físicas, los vértices representan nodos físicos, los puertos, puntos de accesoa red y las líneas, conexiones.

2.3.4 Arquitectura de gestión TINA

La arquitectura de gestión define un conjunto de principios de gestión de entidades en un sistemaTINA. Está basada principalmente en la gestión OSI y en estándares TMN. Las áreas funcionales degestión son las ya clásicas cinco definidas por la TMN en la ITU: fallos, rendimiento, seguridad,configuración y tarificación. En TINA además, se subdivide la gestión de configuración en gestión deconexiones y en gestión de (configuración de) recursos. A menudo se utiliza otro tipo de clasificacióny también se pueden definir los siguientes planos:

Gestión de computación: relacionada con la gestión de los ordenadores, las plataformas, y el softwareque se ejecuta en esa plataforma. No concierne a lo que las aplicaciones hacen ni a su gestiónespecífica. Su principal interés es el empleo, la instalación, y la carga de software.Gestión de las telecomunicaciones: se refiere a los servicios de telecomunicaciones, el software decontrol y la gestión de redes de transmisión y conmutación.



Estos dos tipos de gestión se dividen en subtipos de gestión. La gestión de telecomunicaciones sedivide, al igual que en TMN, en gestión de servicio, red y elemento. Por su parte, la gestióncomputacional se puede dividir en distintas áreas de interés.

Fig. 2.9 Tipos de interfaz de objeto computacional

Los principales objetos computacionales de la arquitectura de servicio relacionada con una sesión deacceso son los siguientes (Fig. 2.10). El UAP (User Application) representa una variedad deaplicaciones de servicio en un sistema de usuario. GSEP (Generic Session End Point) es un objetocomputacional independiente del servicio que modela el mínimo conjunto de capacidades como unextremo final de una sesión de acceso por medio de la interacción con el agente de usuario pararealizar el control de la sesión de servicio. El UA (User Agent) representa a un usuario en el dominiodel proveedor de servicios. El PPrf (Personal Profile) mantiene las restricciones y preferenciasrelacionadas con el usuario en acceso al servicio y ejecución de sesión. El Ucxt (User Context)mantiene el conjunto de recursos disponibles al usuario para la ejecución de servicios. TE-A es elequipo terminal A. El SSM (Service Session Manager) soporta las capacidades de servicio que secomparten entre los usuarios en una sesión de servicio manteniendo el seguimiento y control de losrecursos. El USM (User (Service) Session Manager) comprende el control de servicio y de sesión delas sesiones de usuario (servicio). El SubAgt (Subscription Agent) es un punto de contacto paraacceder a la información de suscripción para agentes de usuario. Finalmente, el SF (Service Factory)controla el ciclo de vida de los objetos de la sesión de servicio de acuerdo a las peticiones realizadasdesde agentes de usuario.

Fig. 2.10 Objetos computacionales relacionados con una sesión de acceso

Sesión deacceso

UAP

GSEP

UA

USM SSM

SF

SubAgtUCxt PPrf

TE-A

COa

COc

CO

COd

Cliente Servidor

Productor Consumidor

Notación de interfaz operacional

Notación de interfaz de flujo

Fuente Sumidero

Interfaz


Gestión de red34

2.3.5 Evolución de la red inteligente hacia TINA

Existen dos posibles vías para implementar TINA en las redes inteligentes. En un primer caso (OpenSwitch Path), la solución se basa en una amplia distribución de funciones inteligentes sobre una red deservidores y terminales, y un gestor-agente dedicado a controlar las funciones de conmutación. La redinteligente avanza desde SCPs muy poco centralizados a una web de servidores de red que soportanperfectamente la interacción CPE-CPN (Customer Premises Network) y los equipos de provisión deservicios. Los servidores de red están diseñados para soportar funciones o servicios específicos. Lainteracción entre componentes software está soportada por plataformas basadas en CORBA gracias alIDL (Interface Definition Language). El uso de interfaces públicas permite definir una señalizaciónabierta de servicios específicos. La capacidad de cargar código desde los servidores de la red a lasCPEs aumenta la flexibilidad de este enfoque.

La segunda opción (Bridge to Legacy Path) sigue la línea de la actual implementación de la redinteligente, y tiene influencia en los sistemas SCP y SMS. La mayor parte de la inteligencia sedespliega en una red de servidores que proporcionan funciones avanzadas. El control sobre lasfunciones avanzadas se ejerce por el protocolo actual INAP o sus futuras versiones. La inteligencia dered avanza desde SCPs centralizados a una web de servidores de red diseñados para proveer funcionesespecíficas. Las interacciones con los CPEs no se soportan directamente, están mediadas por equiposde red (SSPs en el plano de control y IP/SN en el plano del usuario). La interacción entre loselementos de software dentro de la capa inteligente se soporta por plataformas CORBA, las funcionesde gestión están integradas con las de control gracias al uso de estas plataformas.

Es necesario dar un nuevo paso con el fin de superar la segunda generación de RI e influenciar en losservicios ofrecidos en la era de la multimedia. La inteligencia se soporta por una infraestructura decomputación, pues las aplicaciones, de acuerdo con la arquitectura TINA, funcionan sobre los nodosde computación. Cada nodo de computación está agrupado en un entorno de procesado distribuido(DPE). La comunicación entre los nodos de conmutación está soportada por conexiones ATM. Losservidores son especializados en función de las funciones que proveen a la infraestructura o bien a losusuarios finales. Las aplicaciones de red proveen funciones de servicio (por ejemplo la gestión y elcontrol de la información proporcionada), funciones de recursos (usadas para ejercer el control y lagestión en el nivel de red), y funciones de elementos (que proveen un control específico sobre loselementos individuales de la red). Las aplicaciones de tipo gateway soportan la interoperabilidad conlos sistemas antiguos, por ejemplo pasarela CORBA a SS7. Los equipos de red pueden serintroducidos fácilmente en la infraestructura si vienen provistos de APIs de control y gestión coninterfaces públicas, los equipos van desde servidores de información, hasta routers o conmutadoresabiertos.

Un entorno de construcción de aplicación potente como (Application Construction Environment,ACE), inspirado en el concepto de creación de servicio total, completa la infraestructura. Todos loscomponentes del servicio están ya diseñados, coordinados y creados. Los diseños de servicioespecifican todas las relaciones y limitaciones entre el servicio lógico y el resto de funciones.

2.4 Creación de servicios

En el pasado, los servicios al cliente eran controlados por la central local. Con la red inteligente, lainteligencia reside en otros elementos de la red, lo que significa que se necesitan nuevos métodos yprocedimientos para crear y proveer servicios.



La red inteligente proporciona un buen número de potenciales beneficios. Permite la introducción denuevos servicios menos larga temporalmente que los métodos clásicos, reduce el coste de los nuevosservicios y permite a las compañías telefónicas ser menos dependientes del proveedor de losconmutadores. Con la nueva red inteligente, los nuevos servicios se pueden diseñar a partir de lasideas de clientes.

El proceso de creación de servicios se ha diseñado e implementado para realizar esos beneficios. Lacreación de servicios incluye todas las actividades y herramientas necesarias para desarrollar unservicio nuevo o modificado.

La creación de servicios se define como el conjunto de actividades que deben realizarse para crear unnuevo servicio y las capacidades de las operaciones asociadas para soportarlo.

Hay dos partes importantes en la creación de servicios:

Proceso: las actividades para generar una nueva idea de servicio, evaluando el nuevo concepto deservicio, documentando, diseñando, probando y desarrollando una nueva lógica de servicio.Entorno: los aspectos físicos de la creación del servicio, incluida la estructura organizacional y losordenadores.

Se pueden distinguir las siguientes fases en la creación del servicio:a) Idea del serviciob) Análisis de necesidades y descripción del servicioc) Especificación del serviciod) Desarrollo del servicioe) Verificación del serviciof) Despliegue del serviciog) Configuraciónh) Testeo y mantenimiento

a) La creación de servicio empieza con una idea. Una idea de servicio puede originarse de muydiferentes fuentes. Las compañías telefónicas desarrollarán nuevos servicios en sus esfuerzos paramejorar los servicios existentes (NO-AIN).

Otras fuentes de ideas de creación de servicios son: clientes, gentes de marketing quienesproporcionan nuevos conceptos de servicio a clientes, otros personales de compañías telefónicasquienes tienen acceso a nuevos conceptos de servicio, reguladores gubernamentales, proveedores deservicio mejorados, sesiones de brainstorming en casa.

b) Siempre que se origina una nueva idea de servicio, se precisa un análisis de necesidades. Un comitéde análisis de necesidades estudiaría todos los departamentos, incluyendo: operaciones, red,marketing, facturación, tarifas y departamento de temas de negocios corporativos.

El comite evalúa un nuevo servicio basado en analisis económicos, análisis de mercado, análisis dered y las evaluaciones de las alternativas de servicio.

c) Si la idea de servicio pasa el test de criterios de servicio, se convierte en una descripción escrita endonde se describe cómo el cliente quiere el servicio. La descripción del servicio es el paso para unaespecificación detallada del servicio.


Gestión de red36

d) En el paso de desarrollo de servicio es donde se crean los servicios realmente. Aquí, un creador deservicios usa la especificación de servicios junto con el conocimiento de la red para producir unprograma lógico de servicio, que contiene las instrucciones reales para ejecutar el servicio.

e) El programa lógico de servicio debe pasar un proceso de verificación, que consta de un sistema detest de la lógica de servicio.

f) Después que el programa lógico de servicio se ha verificado, se descarga el programa en el host delógica de servicio (SCP o adjunto).

g) El programa lógico de servicio debe aprovisionarse con datos específicos del cliente (p.e.información de encaminamiento según la hora del día). El programa lógico de servicio es configuradosegún las especificaciones del abonado, bien sea mediante representantes del servicio de la compañiatelefónica o posiblemente por el propio abonado.

h) Muy importante: debe realizarse la comprobación de extremo a extremo del software, del nuevoservicio para garantizar un servicio de mantenimiento al cliente. Después de la configuración, lossimuladores deben usarse para probar llamadas al nuevo servicio: si son aceptables, se activa elservicio. La activación del servicio debe coordinarse entre los administradores del SCP, el STP y elSSP. El mantenimiento se refiere a todas las actividades asociadas con el soporte corriente de unservicio desplegado.

Cada paso individual del proceso produce su propia salida que contribuye a la creación de un nuevo orediseñado servicio.

2.4.1 Entorno de creación de servicios

El entorno de creación de servicios se refiere a los recursos usados para el soporte del proceso decreación de servicios, incluyendo estructura de la organizacion, computación y capacidades decomunicación. El entorno de creación de servicios consiste de cinco áreas: análisis, desarrollo,producción, red y integración/prueba.

El entorno de análisis es el conjunto de herramientas y facilidades que soportan la generación,formalización y verificación de las especificaciones de datos y servicio del usuario, funcionales yniveles físicos. El entorno de desarrollo es el conjunto de herramientas y facilidades que soportan eldiseño, la codificación y prueba de aplicaciones de servicio. El entorno de producción es el conjuntode herramientas y facilidades que soportan la conversión del software fuente en imágenes ejecutablesespecíficas de la plataforma, y la configuración de componentes de software para redes específicas yplataformas de operación. El entorno de red es el conjunto de herramientas y facilidades que soportan:instalación de imágenes ejecutables en la cima de plataformas en lugares específicos; prueba en lainstalación de imágenes ejecutables; aislamiento de problemas de software; introducción decorrección de programas temporales para emergencias fijas.

El entorno de integración y revisión es el conjunto de herramientas y facilidades que soportan:introducción física de imágenes ejecutables en la cima de cada paltaforma; prueba y integración deimágenes ejecutables en cada plataforma; verificación de fiabilidad de la red en presencia de nuevoscomponentes de software.


3. Soluciones para la gestión de redes 37

3 Soluciones para la gestión de redes

A lo largo de los años se han requerido diversas soluciones, generalmente de tipo propietario, para lagestión de las redes de comunicaciones. Actualmente, con el mayor número y heterogeneidad deelementos junto a la mayor importancia que han adquirido las redes de comunicaciones para laempresa, se exigen nuevos enfoques.

3.1 Evolución de las redes de telecomunicaciones

Las redes de telecomunicaciones dentro del ámbito informático han evolucionado a partir de lanecesidad de compartir información y procesos con usuarios remotos. En una primera fase sedesarrollaron los grandes ordenadores: éstos eran extremadamente engorrosos de utilizar y caros.Estos primeros ordenadores tenían un uso local y eran manejados por una única persona o interfaz.Posteriormente, los sistemas operativos pemitieron el acceso de múltiples usuarios que interactuabanen principio también en un modo local. La gestión de los equipos, cuando existía, era puesnecesariamente local, y los mecanismos específicos de cada fabricante de ordenador.

Ordenadormultiacceso

ImpresorasBancos de memoria

Terminaleslocales

Operador

Fig. 3.1 Esquema de un sistema formado por un único ordenador multiacceso y con gestión local

Más adelante, el uso de redes de telecomunicaciones permitió el acceso remoto de equipos terminalesa los grandes ordenadores. Las redes de tecnología conmutada y el uso de módems eran más baratos


Gestión de red38

de utilizar que el coste que comportaba la disposición de múltiples ordenadores. El único ordenadorera de tipo multiacceso y se accedía a éste de modo local, o remotamente mediante el uso de módemsy equipos terminales (inicialmente teletipos). La gestión de red seguía siendo básicamente de tipocentralizado y basada en métodos del fabricante del mismo ordenador. Si bien esa gestión ya no cubríatodos los elementos que entraban en la red de comunicaciones.

RTCOrdenadormultiacceso

Módem Módem

Terminalesremotos

Terminaleslocales

Fig. 3.2 Esquema de un sistema formado por un único ordenador multiacceso y con conexión a terminales deacceso remoto mediante el uso de módems

A medida que creció el uso del ordenador y aumentó el número de conexiones de equipos terminales aéste, fue necesario reducir la cantidad de módems utilizados debido a sus elevados costes. La soluciónfue la introducción del multiplexor que permitía integrar múltiples conexiones de equipos terminalesen una sola línea de comunicación con lo que aumentaba el rendimiento. De esta forma, no erannecesarios tantos módems y se reducía el coste de las telecomunicaciones.

Fig. 3.3 Esquema de un sistema formado por un único ordenador con conexión de terminales de acceso remoto através de multiplexores


RTC

Módem

Terminalremoto

Terminaleslocales

MUXMUX

Módem



A medida que el progreso tecnológico abarataba los costes de la introducción de ordenadores en laempresa, las redes pasaron de tener configuraciones centralizadas a configuraciones de tipodistribuido con múltiples ordenadores. De esta forma, si bien en un principio se seguían utilizandoredes RTC con módems, eran los ordenadores multiacceso quienes se interconectaban de formainterna. La gestión de red empezó a pasar de modelos centralizados a plantearse de modo distribuido ojerárquicamente distribuido en función del rango de los ordenadores en la red.

Fig. 3.4 Esquema de un sistema formado por un conjunto de ordenadores actuando de forma distribuidaconectados a través de una RTC

Conforme la interacción mutua del sistema distribuido de ordenadores iba aumentando fue haciéndosemás necesario el uso de líneas dedicadas que permitieran reducir el coste debido al tráfico deinformación por las redes. Las empresas alquilaban líneas a los operadores de redes y eso permitíaofrecer costes menores en comunicaciones. La gestión de red se plantea de forma distribuida.

A raíz del crecimiento del tráfico telefónico en las redes de ordenadores se hace cada vez másnecesario el empleo de líneas telefónicas privadas en las grandes corporaciones. A medida que latecnología avance, se introduciran, además, líneas digitales que se adecuen mejor al tráfico generadopor las comunicaciones entre ordenadores.

RTC

Terminalesremotos

Terminaleslocales


MUX

Módem

Terminaleslocales


MUX

Módem

Módem

MUX


Gestión de red40

Fig. 3.5 Esquema de un sistema formado por un conjunto de ordenadores que actúan de forma distribuida,conectados vía líneas dedicadas

Fig. 3.6 Esquema de un sistema formado por un conjunto de ordenadores que actúan de forma distribuida,conectados según una red digital o de paquetes

La entrada de las comunicaciones de tipo digital permitió optimizar la transferencia de informaciónentre ordenadores. Nacieron redes como RDSI de conmutación de circuitos para terminalesmultimedia y otras redes basadas en conmutación de paquetes como la que utiliza la norma X.25.

RTC

Terminalesremotos

Terminaleslocales


MUX

Módem

Terminaleslocales


MUX

Módem

Módem

MUX

Líneasdedicadas

Red de paquetes

Ordenador

Ordenador



Más adelante, con el empleo masivo de terminales tipo PC en las grandes corporaciones, sedesarrollaron redes locales en conexión con redes de área extendida para poder cubrir las distanciascorrespondientes a campus o ciudades. Otros estándares como Frame Relay o ATM se handesarrollado para permitir esa interconexión de redes locales que pueden estar situadas de formaremota. En estos casos la proliferación de múltiples fabricantes distintos en el desarrollo de losterminales y dispositivos de interconexión de red hace complicada la gestión de este tipo de redesheterogéneas. Es por ello que a partir de esos momentos, resulta evidente la necesidad de diseñarmecanismos de estandarización para poder gestionar la creciente complejidad de los sistemas de redes.

Fig. 3.7 Esquema de un sistema formado por un conjunto de redes locales interconectadas por una red depaquetes, una red de área extendida (WAN) o una red de tipo B-RDSI

De esta forma, surgieron diversos organismos de estandarización que trataron de solucionar elproblema de la gestión en redes heterogéneas, como IETF que definió el protocolo SNMP o comoISO, que hizo lo propio con el protocolo CMIP.

Se puede, pues, hablar de distintos tipos de gestión según las configuraciones de los escenarios, esdecir, una gestión autónoma donde las redes tienen gestión local en cada nodo; una gestiónhomogénea con redes homogéneas con un único nodo de gestión centralizado; finalmente, una gestiónheterogénea, con la ampliación de las redes con la interconexión de productos heterogéneos. Este seríael caso del siguiente ejemplo: una organización que interconecta sus sistemas de información condiferentes redes de comunicaciones.

El caso de utilizar sistemas de gestión de red propietarios trae consigo las siguientes consecuencias:un plano de usuario (operador de red) con una multiplicidad de interfaces de usuario; un plano deaplicación (de gestión) con distintos programas de aplicación con funcionalidad similar; y, finalmente,un plano de información (de gestión): con una duplicidad y posible inconsistencia de la informaciónalmacenada en las bases de datos. Todo ello, dificulta el cumplimiento de que la gestión de red seaefectiva desde el punto de vista del coste.

WAN, B-RDSI

Ordenador Ordenador

LAN

LANLANPasarela

Pasarela

Pasarela


Gestión de red42

Como solución se plantea una gestión integrada, en la que se normalizan las comunicaciones con laespecificación de un protocolo entre elemento de red y centro de gestión, y la normalización de lainformación donde el centro de gestión debe poder conocer a los elementos de red mediante sunombre y sus propiedades visibles. Por tanto, debe haber también una definición sintácticamenteuniforme de los elementos de red.

Existen una serie de modelos de gestión normalizados, en los cuales es posible el acceso uniforme alos recursos gestionados. Se normaliza el protocolo de comunicaciones, el modelo de información degestión y las definiciones de información de gestión. Los modelos de gestión de red tradicionales másimportantes son la arquitectura TMN (ITU-T), el modelo de gestión OSI (ISO) con el protocolo CMIPy el modelo de gestión Internet (IETF), basado en el protocolo SNMP. Más recientemente, hanadquirido importancia el modelo DMI (DMTF), la gestión por agentes inteligentes y la gestión porwebs.

3.2 Modelos para la monitorización y el control de red

La gestión de red ha evolucionado desde la gestión basada en arquitecturas de red de tipo propietariohasta el uso, hoy ya masivo, de plataformas de gestión basadas principalmente en sistemas operativosUNIX o NT. Estas plataformas de gestión se implementan según una integración de aplicacionescompatibles y que permiten una gran flexibilidad de uso en la gestión de redes heterogéneas [GHE1].

Existen también los productos específicos para la gestión de redes de área local, tanto para segmentosindependientes como específicos, para redes de PCs o para determinados elementos de red.Finalmente, existen también los integradores de sistemas de gestión.

3.2.1 Arquitecturas propietarias

Desde siempre los fabricantes líderes en sistemas de gestión han tratado de imponer estándares defacto. Actualmente se trata de una tendencia que está cayendo en desuso. Las razones principales sebasan en la cada vez menor cuota de mercado de estos fabricantes líderes y de la cada vez mayorcomplejidad de los entornos de red, formados por extensas interconexiones de redes y servicios quedificultan su control y gestión por parte de unos pocos fabricantes.

Entre las arquitecturas de red más importantes se encuentran: IBM, Xerox, Novell, Ungerman-Bass, 3COM, Banyan, Proteon y AT&T. A continuación se describen algunas de ellas.

IBM network management architecture:

Open network management (ONA) es el marco de trabajo para los sistemas de gestión IBM. Sedefinen tres grandes tipos de elementos que realizan funciones de gestión:

- Puntos focales, que proporcionan control centralizado, p. e. Netview.- Puntos de entrada, que pueden ser dispositivos SNA en general.- Puntos de servicio, que proporcionan servicios de gestión SNA.



Esquema:

Sistema no SNA

Punto focal

Punto de servicio

Punto de entrada

Dispositivo SNA

Netview

Netview/PC

NMVTs

Fig. 3.8 Esquema de la arquitectura de gestión de red IBM

Las plataformas de gestión que utilizan la arquitectura de red IBM pueden ser: Netview para la gestiónde redes SNA, LAN Network Manager para la gestión de redes Token Ring y Netview/6000 para lagestión SNMP (Karat).

Novell:Novell utiliza un sistema operativo de red, basado en una evolución del Netware. RecientementeNovell ha introducido CMISE y CMIP en sus sistemas de gestión de red. Actualmente Novell estámigrando su torre de protocolos IPX al estándar IP.

Arquitectura de gestión de red AT&T:La arquitectura del sistema de gestión múltiple de red, UNMA (Unified Network ManagementArchitecture) de AT&T está basada en OSI. UNMA consiste de una arquitectura en tres capas ligadas.El nivel más bajo está formado por los elementos de la red, es decir, componentes físicos y lógicosque comprende la red que se quiere gestionar. El segundo nivel lo forman Element ManagementSystems (EMS), que administran y gestionan elementos de red. El tercer nivel consiste de sistemas degestión integrados que unen conjuntamente los EMSs de los tres niveles.

NE NE NE NE NE NE

Sistema de gestiónintegrado

Interfaz de usuariounificado

Gestión deelementos



Fig. 3.9 Esquema de arquitectura de red de AT&T


Gestión de red44

3.2.2 Plataformas de gestión

Las plataformas de gestión utilizan una integración de aplicaciones para poder adaptarse al entornocambiante y complejo de los elementos de red que se quieran gestionar. Entre las aplicaciones másusuales que se incorporan, destacan los MIB browser (navegadores u hojeadores de MIB) comointerfaces de usuario del protocolo SNMP; el discover, que permite autodescubrir equipos ytopologías de la red; la programación de sondeos de variables de la MIB; la programación de accionesante alarmas; y, finalmente, los visualizadores gráficos de valores de variables de MIB.

Dentro de la categoría de sistemas basados en UNIX podemos encontrar los siguientes:- Enterprise Management Architecture de Digital (PolyCenter)- OpenView Network Management server de HP- SunNet Manager de Sun Microsystems (Solstice)- Spectrum de Cabletron- DualManager de Netlabs (OverLord)- NMC 3000 de Network Managers- NetExpert de Objective Systems Integrators- NMS/Core de Teknekron Communications Systems- Network Knowledge Systems de Applied Computing Devices- IBM Netview/6000 para AIX- TME 10 de Tivoli.

Las plataformas de gestión posibilitan mayor grado de integración multifabricante que el esquemagestor de gestores. Las interacciones con otros sistemas de gestión de diferentes fabricantes se realizana través de un interfaz de programación de aplicaciones estándares (API) y un conjunto estándar dedefiniciones de datos de gestión.

3.2.3 Clases de productos de gestión

Se pueden distinguir las siguientes clases de productos de gestión para LANs:

- Productos standalone, dirigidos especialmente a monitorización, análisis de test, seguridad ynecesidades de tarificación.

- Plataformas de gestión de red que proporcionan un entorno en el cual las aplicaciones pueden serdesarrolladas, mejoradas e intercambiadas.

- Herramientas de gestión de LANs de PCs, que incluyen soluciones de propósito especial como unacombinación de funciones de sistemas operativos en LANs y añadidos especiales.

- Sistemas de gestión de elementos LAN basados en estándares abiertos o de facto que ofrecen unaaceptable funcionalidad a elementos LAN, tales como segmentos LAN, hubs cableados,dispositivos de interconexión LAN, FDDI, PBXs y conexión a integradores de gestores de red.

- Integradores que probablemente soportan elementos de gestión de sistemas LAN, MAN, y WANen la misma plataforma.

3.2.4 Productos de gestión de LANs standalone

Los productos standalone sirven áreas funcionales especiales sin intención de aplicabilidad a laintegración de gestión de LANs. Esto es, instrumentos de test de LANs, analizadores de LAN,sistemas de monitorización de LAN, u otros instrumentos especiales.



Los productos standalone suelen evaluarse de acuerdo a los siguientes criterios:

- interfaz de usuario- protocolos que son soportados- nivel de decodificación- el tipo de LANs/WANs soportadas- buffers de captura- filtros- soporte para monitorización distribuida- niveles de disparo- búsquedas- etiquetas temporales- generadores de tráfico- chequeo de cables- convención en el nombrado- diagnóstico por sí mismo- impresión por hard-copy- protección de passwords

Entre los instrumentos más importantes para tests de LANs se incluyen: óhmetros, testers, conectorescoaxiales, conectores en T, terminadores, osciloscopios y reflectores en el dominio temporal.

Los analizadores de LANs tienen como fin el soporte de gestión de prestaciones y de fallos. Engeneral ofrecen indicaciones sobre:

- Servicio: retardos, tiempo de transferencias, tiempo de diálogo.- Uso: uso global del ancho de banda, uso específico por aplicaciones y/o usuarios.- Perfiles de usuario: qué aplicaciones y qué actividades.- Perfiles de servidores: uso interno, colas,...

Los sistemas analizadores de LANs, suelen permitir la monitorización de precisión y disponer deherramienta de diagnóstico para gestores de red. Analizan tanto redes Ethernet como Token Ring(entre otros protocolos). Verifican tráfico en tiempo real, conectividad y problemas asociados,actividades de ficheros en tiempo real, conectividad con bridges y retardos asociados, test dehardware para servidores y simulación de cargas.

Los sistemas de monitorización de LANs forman una familia de herramientas que soportanmonitorización continua, ofreciendo una unidad de colección de datos en cada segmento LAN. Lasfunciones que suele realizar el software son del tipo: número de canales de entrada, filtros, etiquetastemporales, estaciones de monitorización, buffers (colas), niveles de disparo, presentación, lista dealarmas, protocolos medidos, encabezamientos, estadísticas y informes de errores, interfaz a bases dedatos u otros y soporte SNMP. Entre los productos más representativos, se suele citar el Sniffer(llamado Watchdog) de Network General. Existen equipos más recientes como el Network Advisor deHP o el Trakker de Concord Communications.

Existen también instrumentos especiales de LANs. Estos instrumentos especiales soportan áreas degestión de LANs específicas. Por ejemplo, la tarificación utiliza en particular dos tipos de productos:medidores de software y herramientas de gestión de pruebas de auditabilidad, así como herramientasde documentación.


Gestión de red46

3.2.5 Gestión de LANs de PCs

Los sistemas de gestión de LANs de PCs están orientados a supervisión de eestatus, determinación defallos y muy básicas capacidades de administración. Actualmente las últimas versiones de WindowsNT (Microsoft) está aportando interesantes novedades para la administración y monitorización de lasredes locales de PCs. Además, y aparte de IBM, han dominado el mercado otras compañías comoNovell, 3Com y Banyan. Otros productos interesantes en el área de LANs de PC son StarLAN deAT&T y LocalTalk de Apple. Como resultado de la tremenda presión de los usuarios haciaaplicaciones multiprotocolo, interoperabilidad, etc. las compañías líderes han reaccionado hacia:

- Abrir gateways a TCP/IP.- Acuerdos de cooperación (p.e. IBM y Novell, IBM y 3Com, Banyan y Novell).- Soporte de SNMP sobre un redes locales.- Soporte de CMOT sobre redes con muchos nodos.- Adquisición de productos de monitorización para proporcionar a los usuarios con monitorizaciónmejorada y gestión.

Actualmente son las plataformas abiertas de gestión de red las que constituyen la base común para quea través de APIs (interfaces de programación de aplicaciones) las aplicaciones de gestión puedanrealizar la recogida de datos de los elementos de red. Estas aplicaciones son accesibles normalmentepor medio de lenguaje C y permiten que una aplicación pueda invocar una función de otra.

DMI (Desktop Management Interface) fue el primer API de gestión de PCs independiente deprotocolos y sistemas operativos (abril 1994). Es uno de los principales componentes de la solución degestión de DMTF (Desktop Management Task Force), consorcio industrial que persigue proveer unaplataforma PC susceptible de ser gestionada en modo flexible. Los ficheros MIF (ManagementInformation Format) provistos con cada producto gestionable definen, por su parte, los atributosgestionables del estándar en categorias tales como sistemas PC, servidores, impresoras, adaptadoresLAN, módems y aplicaciones software. La arquitectura DMI incluye el nivel de servicio, un programalocal que recoge información de los productos, gestiona esa información en bases de datos MIF, y lapasa a las aplicaciones de gestión cuando es solicitada. Controla, además, su comunicación con lasaplicaciones de gestión de MI (Management Interface) y con los productos gestionables a traves de CI(Component Interface).

SMS (Systems Management Server) de Microsoft es otra plataforma diseñada para soportar tareas degestión de sistemas, tales como inventarios hardware y software LAN y distribución electrónica desoftware, en entornos LAN Manager y Windows NT Advanced Server (NTAS) de Microsoft, Netwarede Novell, Pathworks de Digital y LAN Server de IBM. Sobre plataformas Window NTAS, SMSutiliza DMI. La estrategia de gestión LAN de Microsoft se centra fundamentalmente en el control delos sistemas conectados a la LAN, dejando la gestión de dispositivos de red, como routers y hubs, asoluciones de mayor nivel que incluyan estaciones basadas en SNMP.

NMS (Netware Management System) de Novell es una familia de productos software que constituyeuna solución abierta para la gestión de LANs NetWare y dispositivos de internetworking como routersy hubs. NMS comprende tres productos software que corren sobre una consola central y agentes queresiden en los dispositivos de la red. El software de gestión de NMS corre bajo PCs Windows y susfunciones clave son la exploración y mapeo de dispositivos de interconectividad, gestión de



direcciones de red, rastreo de condiciones de alarmas y su almacenamiento en una base de datos.Dispone de una herramienta de análisis experto para la solución de problemas y dispone de lacapacidad de gestionar cualquier dispositivo SNMP.

3.2.6 Sistemas de gestión de elementos de red de área local (LAN)

Los sistemas de gestión de elementos de redes deárea local gestionan LANs de propósito general. Lossistemas de gestión de elementos en esta sección están agrupados en:

- ethernet- token Ring- concentradores cableados, hubs- dispositivos de interconexión- backbones de LANs, como por ejemplo FDDI- plataformas de gestión LAN

Los segmentos de redes de área local basados en Ethernet son todavía líderes en el mercado. Por ello,es extremadamente importante proporcionar capacidades de monitorización y gestión para esossegmentos. Las empresas líderes en este campo son DEC a través de Ethernim y HP, con LANProbe,Probeview y Openview.

IBM está liderando este mercado con herramientas de gestión token ring y con la gama de productosLAN Network Manager. Hay dos opciones de gestión básicas: gestión standalone de componentesconectados, o centralizados y gestión integrada via Netview.

Los productos de gestión de redes LAN de IBM gestionan LANs al nivel de estación de trabajo, y conNetview como computador Host. Ellos hacen seguimiento y control de acceso a dispositivos en cadaLAN. IBM tiene cinco grandes productos de gestión de redes Token-Ring:

- IBM LAN Network Management versión 1.0.- IBM LAN Network Management versión 1.1.- IBM LAN Network Management Entry.- IBM LAN Station Manager.- IBM 8230 Controlled Access Unit (CAU).

Se pueden distinguir las siguientes funciones en la gestión de elementos token ring como las másimportantes:

- monitorización activa- monitorización de errores en el anillo- servidor de parámetros al anillo- servidor de configuración del anillo- servidor de puente LAN- trazas y prestaciones- gestor de estaciones- unidad de acceso controlado- gestor de LANs- Netview (punto de control SNA)


Gestión de red48

Por otra parte, los concentradores cableados y hubs están llegando a ser el objetivo de la gestión deredes en LAN. Muchos analistas predicen que la gestión de red basada en bridges y routers vaencaminada a gestión basada en hubs. Uno de los sistemas de gestión más representativos es el queCabletron presenta con el Spectrum Network Management.

Respecto a las redes de alta velocidad, se identifican casi exclusivamente como redes FDDI yFast/Gigabit Ethernet. Los estándares de gestión en algunos tipos de redes todavía no estáncompletamente definidos.

Los sistemas de gestión de elementos para LANs interconectados emplazan tanto gestión de LANscomo gestión de WANs en el mismo lugar, el control del centro de gestión de red. Cada objetogestionado individual, tales como repetidor, puente, brouter, router, y gateway es parte del segmentode LAN local. Pero al mismo tiempo, los mismos componentes son parte de la topología MAN y/oWAN. Como productos destacados se puede citar el CiscoWorks de Cisco.

Finalmente, la mayor parte de sistemas de gestión de elementos multisegmento tienen la capacidad deofrecer gestión multisegmento desde plataformas estándares o propietarias. Éstas combinan fastpacket, conmutación, tecnologías de encaminamiento con FDDI, ethernet y hubs token ring que segestionan desde una plataforma común y ofrecen mejores prestaciones por el menor coste.

3.2.7 Integradores para gestión de LANs

Para la gestión de redes heterogéneas se han adoptado diversas estrategias a lo largo del tiempo. Alprincipio era usual utilizar una integración de gestión de LANs jerárquica, mediante un esquema degestor de gestores. Este esquema era válido pero no permitía suficiente flexibilidad en los cambios deconfiguración de la red, ya que exigía la modificación de los programas continuamente. El procesadode la información y la fiabilidad de un único nodo jerárquico superior (gestor de gestores) era tambiénuna limitación en redes de muchos nodos.

Gestor de gestores

SGE deelementos LAN

SGEPBX

SGE dehubs cableados

SGE depuentes/routers

SGE dePC-LANs

MonitoresLAN

AnalizadoresLAN

Equipos detest de LANs

Aplicaciones de integrador

Objetos gestionados

SGE: Sistema de gestión de elementos

Fig. 3.10 Configuración como gestor de gestores de redes



A medida que los fabricantes se fueron enfrentando con el problema de la gestión de gestores fueronadoptando otras soluciones como el uso de integración de gestión de LANs con plataformas.Actualmente el uso de plataformas de gestión que utilizan APIs (Applications ProgrammingInterfaces) está muy extendido. Finalmente, con el uso masivo de Internet, la gestión de red mediantewebs y navegadores se está haciendo cada vez más normal, si bien los estándares están aún pocodesarrollados.

SGE deelementosLAN

SGEPBX

SGE dehubscableados

SGE depuentes/routers

SGE dePC-LANs

MonitoresLAN

AnalizadoresLAN

Equipos detest de LANs

Objetos gestionados

SGE: Sistema de gestión de elementos

A1 A2 AN

Plataforma para soluciones de fabricantes utilizando elApplications Programming Interface (API)

Fig. 3.11 Configuración como gestor que integra APIs para gestión de redes heterogéneas

Las aplicaciones sobre plataformas de gestión más frecuentes son las siguientes:

- gestión de equipos específicos- gestión de incidencias a través de un Trouble Ticket System- gestión de inventario- gestión de cableado- interacción con otros sistemas de gestión- gestión de fallos mediante sistemas expertos- gestión de sistemas,...

Por otra parte, las plataformas de gestión requieren de una integración entre esas aplicaciones. Existentres tipos de integración entre aplicaciones: integración de comunicaciones, integración de interfacesde usuario e integración de información. Sólo las dos primeras están solucionadas con el uso de unaplataformas de gestión: las comunicaciones, dado que todas las aplicaciones usan los servicios decomunicaciones (API) de la plataforma y el interfaz de usuario, puesto que las aplicaciones compartenel interfaz de usuario de la plataforma.


Gestión de red50

LAN

Interfaz de usuario (motif, GUI, windows,...)

Elementos de servicioé i- Comunicación interna

- Interfaz a agentes- Aplicación entre funciones

Elementos de serviciol i dcon aplicación:

- Configuración- Fallos- Prestaciones- Seguridad- Tarificación

Gateways a agentes propietarios, de facto o abiertos

Agentepropietario

Agente defacto

Agenteabierto

EventosMensajesAlarmas

ReaccionesComandos

Fig. 3.12 Arquitectura genérica de un producto de gestión de LANs actual

Respecto a la integración de información, se implementa una base de datos local de gestión dado quelas aplicaciones de gestión requieren almacenar datos localmente, como datos de topología, datosadministrativos, etc. Estos datos pueden formar parte de las MIB, pero no es frecuente. Lasplataformas y algunas aplicaciones incorporan el uso de bases de datos relacionales para elalmacenamiento local. Cada aplicación tiene necesidades de almacenamiento diferentes, pero confrecuencia existen datos comunes entre ellas. Como consecuencia, cada aplicación tiene su propiabase de datos.

Dado que las plataformas actuales no permiten una integración de la información entre lasaplicaciones (sólo admiten una emulación de consolas), se definen dos enfoques diferentes para susolución: un esquema universal de almacenamiento de datos, o bien el desarrollo de aplicaciones a lamedida.

La integración puede realizarse de dos formas: mediante el uso de una plataforma o bien mediante eluso de un integrador. Con los productos de integración, se pueden identificar dos grandes grupos:productos de emulación de consolas e integradores avanzados. Las soluciones más importantesbasadas en productos de emulación de consolas son:

- Netview (IBM)- Accumaster Integration (AT&T)- DECmcc (DEC)

A continuación, en las siguientes figuras se presentan esquemáticamente las funcionalidades de estosintegradores.


Netview

Ayudas a instalación

Comandos de facilidades

CLISTs

Ayudas a escritorio

AyudasNavegador (Browser)

EstatusMonitor

Hardware monitor(NPDA)

Soporte 4700(TARA)

Monitor desesion (NLDM)

Monitor deprestaciones (NPM)

Gestor dedistribución Acceso/SAMON

Fig. 3.13 Estructura Netview (IBM)

Gestión deseguridad

Planificación deredes

Recursossobrantes Gestión de tarificación

Gestión de configuracióny nombres

Gestión de fallosGestión de prestaciones

Elementos de red en una arquitectura distribuida

Sistemas degestión deelementos



NMP

Fig. 3.14 Accumaster Integrator Architecture


Gestión de red52

Módulos de presentación:Interfaz de línea de comandosCreación MAPDEC Windows

Interfaz

Ejecución

Reposición de lainformación degestión

Módulos de acceso

DECnet phase IVDECnet OSISNMPTCP/IPEthernetBridge/router

Módulosfuncionales:

RegistroDominiosAlarmasAnalizador de prestacionesHistoriaDiagnosis DECnet

Fig. 3.15 DECmcc Director

3.3 Mecanismos para la detección de configuraciones de red

En el momento de proceder a la obtención de la configuración topológica de una red se puedenaplicar diferentes mecanismos de búsqueda y detección de los nodos que configuran la red.Normalmente eso se realiza con la aplicación Discover desde una plataforma de gestión de tipoconvencional. En el proceso de detección se envían de modo secuencial mensajes ICMP (InternetControl Message Protocol) a cada uno de los nodos, que la aplicación presenta en pantalla en elcaso de que los nodos estén activos. En el caso de que no contesten al cabo de un determinadotiempo, los nodos se dan por inactivos; sin embargo, existen una serie de problemas en el caso deque se produzca una inundación de mensajes ICMP no reconocidos que afecten al tráfico normal.La solución a este tipo de problemas pasa por restringir el número de mensajes que pueden estar noreconocidos (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 pararesolverlas, ya que no hay control explícito en la tasa de consultas. Sin embargo, la tasa de consultaspodría ser más alta de lo deseable si el tiempo de reconocimiento es corto y todos los nodosinterrogados responden al mismo tiempo. El problema puede ser la generación de ráfagas de mensajesen el momento de descubrir series de nodos. Una política de gestión usual es utilizar un sistema conN=3 y un tiempo de timeout de 10 segundos. Este tiempo de timeout se suele duplicar en los tressubsiguientes intentos. A partir de esta disposición, surgen nuevos problemas, como es el retardo quese produce en el sistema si los nodos son ilocalizables que llega a ser de 2,5 minutos. (10 + 20 + 40 +80 = 150 seg.). Si existe alguna parte de la red cortada, ello produce bloqueos sucesivos del sistema.Una posible solución pasa por aumentar N; sin embargo, en este caso, las ráfagas podrían ser mayores.

Una posible solución pasa por prevenir inundaciones, se diseña un algoritmo RPE (Regulated PollEmission) en el que los mensajes de prueba se emiten a una tasa que no supera un determinado nivel,


soportable por la red (p.e. usando el sistema operativo Unix). Los nodos pueden ser consultadosconcurrentemente sin recibir reconocimientos.

3.3.1 RPE (Regulated Poll Emission)

Este algoritmo permite que las peticiones de interrogación de eestatus puedan generarse en ráfagasdependiendo de la estrategia escogida de ordenación. Para ello, la solución pasa por utilizar unmecanismo de leaky bucket, en la que un número específico de pings puede transmitirse dentro de untramo específico de tiempo. Los mensajes se enviarían en intervalos de tiempo no menores que τ. Si eltiempo de emisión de los mensajes de polling de longitud constante es C, con C < τ, entonces la tasade transmisión de polling máxima es 1/τ a pesar del estado de los nodos interrogados o la secuenciacon la que éstos son interrogados.

Para acelerar el proceso de los reconocimientos (acknowledgments) se implementan registros de pingsno reconocidos en una estructura indexada de datos ordenados por la dirección IP de destino. Paraacelerar la gestión de los timeouts se registran los pings no reconocidos de forma que son indexadospor el tiempo en que se ordena un timeout. Cada registro en una tabla tendría un puntero en el registrode la otra para asegurar su borrado automático y efectivo cuando suceda un timeout.

El RPE tiene una serie de ventajas, ya que el método permite un número arbitrario de peticiones deeestatus simultáneas, permite un rápido cambio en los mapas de eestatus de los nodos de red ypreviene la liberación de ráfagas de mensajes de petición de estatus en la red. En cuanto a laslimitaciones, cabe decir que no hay un control sobre la tasa de recepción de reconocimientos (ack.ICMP), con el consiguiente peligro de ráfagas de respuestas en caso de recuperación o desbloqueo dela red.

3.3.2 Modelado de la duración de un ciclo de consultas de eestatus

La duración de la consulta viene determinada por el número de reintentos en la obtención del estatusde un nodo. En el caso del método COP-N el tiempo de espera es hasta la próxima consulta, mientrasque en el RPE es el tiempo en que la petición de polling está almacenada.

Sea un ciclo de polling con K intentos. La duración del intento k (1 <= k <= K) consta de:

C: tiempo de emisión de la petición de polling.

KT : intervalo de timeout.

KA : tiempo en recibir un reconocimiento (ack)

Kp : probabilidad de que el k-ésimo intento no sea reconocido.

1 - Kp : probabilidad de que el k-ésimo intento sea recibido antes del timeout.

Ejemplo: K = 4. 1T = 10, 2T = 20, 3T = 40, 4T = 80 segundos, por tanto, ∑ = segundosTi 150 .


Gestión de red54

C CCCT1

T2 T

3T

4

A1

A2

A3

A4

S4

S3S

2S

1

InicioFin

Transmisión

Timeout

Ack

Transmisión Transmisión Transmisión

Timeout Timeout Timeout

Ack AckAck

p1

1 − p1

1 − p21 − p

3 1 − p4

p2

p3

p4

Fig. 3.16 Esquema de la duración de los ciclos de consulta

Un intento de polling no está reconocido si ocurre uno cualquiera de los siguientes eventos:

a) El mensaje de polling ICMP se pierde en su viaje con probabilidad 1γ .

b) El nodo no es alcanzable porque el camino está cortado con probabilidad 2γ .

c) Pérdida del mensaje de reconocimiento, por ejemplo debido a congestión en la red, con

probabilidad 3γ .

d) El ack. no se devuelve antes que expire el timeout con probabilidad ( )KKr TAP ≥ .

Luego, ( )( )( ) ( )KKrK TAPP ≤−−−−= 321 1111 γγγ

ya que los cuatro sucesos pueden ocurrir independientemente.

El tiempo de acknowledgment KA se ve afectado por los iγ . KA depende de la topología así como de

los niveles de congestión, lo que complica el análisis. La solución pasa por adoptar una KA

distribuida exponencialmente con media equivalente al tiempo de viaje de la red gestionada, con loque [ ]KAE podría ser de menos de 10 mseg. o de varios segundos. De hecho, el valor de las

probabilidades iγ podría variar con la secuencia de nodos que deben ser interrogados, o por

aquellas consultas que se han iniciado y no se han contestado.

3.3.3 Duración media del tiempo de ciclo de K intentos

Sean las siguientes definiciones:C: tiempo en emitir un mensaje de polling ICMP

KS : tiempo restante de resolver la interrogación al comienzo del k-ésimo intento

1S : tiempo en tomar la decisión de si el nodo interrogado es alcanzable o no.



Para otros intentos aparte del k-ésimo, se requiere un intento subsiguiente con probabilidad Kp y

resulta innecesario con probabilidad 1 - Kp .

Si un (k + 1) intento no es necesario, la duración del k-ésimo intento será el comienzo de la emisión alretorno del reconocimiento. Si se necesita, el resto del ciclo de polling incluye el k-ésimo timeout y laduración del (k + 1) intento, 1+KS :

( ) ( )11 +++−+= kkkkkk STpApCS con k = 1, 2, 3,... K-1.

En el k-ésimo intento, el resto del ciclo de polling finaliza KA si el:

( ) ( )KKKKK TpApCS +−+= 1

La duración media de la etapa final del ciclo de polling es pues:

[ ] [ ] ( ) [ ] [ ]KKKKK TEpAEpCESE +−+= 1

La duración media del tiempo restante del ciclo de polling al comienzo del k-ésimo intento es:

[ ] [ ] ( ) [ ] [ ] [ ]( )11 +++−+= kkkkkk SETEpAEpCESE

con k = K-1, K-2, ..., 2, 1.

3.3.4 Número esperado de intentos de polling en un ciclo

El número esperado de intentos de polling en un ciclo determina el ancho de banda necesario. Engeneral se asume que los eventos en intentos de polling sucesivos dentro de un ciclo sonindependientes. Aunque no resulta cierto, ya que si un nodo no es alcanzable en el primer intento, casiseguro no lo será en los intentos subsiguientes.

Se requeriran K intentos con probabilidad ∏−

−

1

1

K

iip .

Si pN denota el número de intentos de polling requeridos dentro de un ciclo, bajo la suposición de

independencia:

[ ] ( ) ∏∑ ∏−

=

−

=

−

=+−=

1

1

1

1

1

1

1K

kk

K

k

K

jjkp pKppKNE

al primer intento tenemos, ( )11 p− , con dos intentos sólo ( )21 1 pp − .

Si pS denota el tamaño de un mensaje de polling, X denota el máximo flujo bajo el cual se realiza

cualquier mecanismo de envío de polling. La máxima demanda de ancho de banda de polling vieneacotada por [ ]pp NXES .


Gestión de red56

3.3.5 Flujos del ciclo de polling

a) Método COP-N

La tasa máxima resulta ser:

[ ]1SE

NX N =

El período de congelamiento resulta ser: ∑=

K

iiT

1

, expresado como la suma de los intervalos de timeout

si N nodos inalcanzables son interrogados en rápida sucesión. Si la red funciona perfectamente, la tasa

resulta ser: Ca

NX N +

=* con a como el tiempo de reconocimiento medio en ausencia de fallos o

pérdida de paquetes. C es el tiempo transcurrido al emitir un polling ICMP. Si a es pequeño, lasráfagas de consultas podrían degradar el comportamiento de la aplicación.

b) Método RPE

Sea τ el tiempo mínimo entre emisiones de consultas ICMP. Sea, pues, τ1

la tasa máxima para el

envío de peticiones ICMP. Luego, τ > C a causa de las limitaciones del hardware y del software de

los equipos. Por tanto, debe cumplirse que [ ]N

SE 1<τ si se quiere tener más tasa que en el método

COP-N.

Sea M el máximo número de nodos permitido para que peticiones de polling no sean reconocidas, esdecir, M como el número de entradas de la lista de registros. De forma que, en general se cumpla queM>>N. Luego, el número medio de peticiones de polling residentes en memoria resultará ser de

[ ]1SXE . De forma que [ ]1SXE ha de ser menor que M para que el sistema funcione correctamente.

Así:

[ ]

<

1

,1

SE

MminX

τ

donde τ es controlable y M dependiente de la memoria disponible.

Los factores que limitan la tasa de polling son la saturación del sistema operativo y/o la red conmensajes de polling, con lo que τ crece. Conforme crecen los retardos de propagación, transmisión,congestión, timeouts, o la alta incidencia de fallos en los nodos, entonces [ ]1SE resulta ser un valor

alto.

M nunca será un límite si es mayor que N. En el método COP-N, con N<<M interrogaciones noreconocidas, el proceso de polling se congelaría tan pronto como N fallara, o se sondearan en sucesiónnodos no alcanzables. Si la red funciona correctamente, el método COP-N puede atascar la red deforma intermitente, mientras que con el método RPE, se puede escoger un τ apropiado para evitarbloqueos.


3.3.6 Análisis del retardo

Sean n > N nodos ordenados para ser interrogados en el tiempo t y, de éstos, los primeros N seannodos inalcanzables o caídos, mientras que el estado del resto n-N nodos es desconocido.

Sea M el máximo número permisible de ciclos de polling no resueltos bajo el método RPE que, en

general, es mucho mayor que [ ]τ

1SE. Luego, en estas condiciones se puede calcular el retardo como:

a) Método COP-N

Los ciclos de polling para los N nodos fallidos tardan ∑=

K

kkT

1

segundos. Durante este periodo los otros

nodos no pueden interrogarse. Puede suponerse también que la interrogación de estatus del últimonodo de la cola se iniciará en el tiempo:

[ ] ∑=

+−−+K

kkTSENnt

11)1( segs. para n >= N + 1.

b) Método RPE

Si M es muy grande, y se cumple que n (<M) nodos se han clasificado para polling en el tiempo t y eltiempo mínimo entre pollings es τ, el é-nésimo ciclo de polling se inicia en el tiempo ( )τ1−+ nt tanto

si los primeros N nodos han sido alcanzados como si no. Además el n-ésimo ciclo de polling será

mejor con el mecanismo de control de tasa τ si [ ] ∑=

+−−≤−K

kkTSENnn

11)1()1( τ

Para n = N + 1 , el n-ésimo ciclo de polling se iniciará antes que el mecanismo de tasa constante:

N

TK

kk∑

=≤ 1τ

ya que τ es mucho menor, en general, que el otro término.

El método RPE puede sincronizarse para limitar el ancho de banda de las interrogaciones o sostener laactividad de las interrogaciones de acuerdo con las necesidades.

4. Entornos de gestión de telecomunicación orientados a objetos 59

4 Entornos de gestión de telecomunicación orientados a objetos

A medida de que las redes de comunicaciones tienden cada vez más a ser sistemas complejos, esnecesario tener metodologías de modelado formales para entender, describir, construir operar ygestionarlas [BA1].

4.1 Introducción a la orientación a objetos

El modelado orientado a objetos puede definirse como una formalización de la habilidad humana decategorizar cosas. Se puede distinguir entre el modelado orientado a objetos, más abstracto, menosdetallado y más comprensivo de la visión del sistema, que se aplica mejor en las fases iniciales delproceso de diseño de una red, y la programación orientada a objeto, que concierne a los detalles dediseño del sistema a bajo nivel y a la eficiencia en la implementación. En este caso, el uso delenguajes de programación orientados a objetos se podría utilizar para implementar un modeloorientado a objetos.

4.2 Objetos gestionados y el entorno gestor/agente

El tema de comunicación entre objetos en una programación orientada a objetos es aplicable de formadirecta: un objeto recibe un mensaje y responde a éste. Se trata en un principio de la arquitectura degestión más básica, esto es, el sistema gestor/agente.

Un lenguaje de programación orientado a objeto podría usarse como para implementar un modelo dered orientado a objetos. En un modelo de red orientado a objetos, cada clase que se especifica tiene unpropósito. Cada clase en el modelo tiene un referente en el sistema real.

Las clases de objetos deben especificarse para todo un conjunto de funciones: físicas, lógicas,humanas, etc. en el modelo de red. El núcleo de las propiedades especificadas en una clase de objetosson los atributos, funciones y cápsulas. Las clases se organizan en una jerarquía de herencia con unageneralización que se incrementa hacia arriba y una especialización que se incrementa hacia abajo.

En teoría de la especialización, generalización y especialización se describen formalmente en términosde una propiedad tomada como base. Esto implica que cuando se decide especializar una nueva clasede objetos de una clase de objetos existente, se debe seleccionar una base de especialización. La basede especialización actúa como un factor que permite distinguir entre subclases.


Gestión de red60

La especialización cualititativa ocurre cuando la propiedad tomada como base es un atributosuperclase que puede poseer uno de un conjunto enumerado de valores. Si la propiedad tomada comobase es un atributo numérico de la superclase, la especialización ocurre restringiendo el dominio devalores que se le permite poseer al atributo en la subclase. En algunas ocasiones es necesario usar másde una propiedad como base para la misma especialización: esto se conoce como especializacióncompuesta.

Fig. 4.1 Base cuantitativa de la especialización

Fig. 4.2 Base cualitativa de la especialización

Las clases se especializan desde sus superclases usando una base formal de especialización. Si se usaun atributo como la propiedad de base de una especialización, las subclases creadas tienen valoresrestringidos por el dominio del atributo. El atributo, escogido como propiedad de base, podría tener unvalor continuo o un valor discreto. La partición del dominio de la base atributo en las subclases seconsidera en función de criterios de completitud y solapamiento. Podrían considerarsesimultáneamente múltiples propiedades para su uso como base compuesta de especialización.

Multiplexor

Multiplexor bandaestrecha

Multiplexor bandaancha

Velocidad del puerto < 45 Mbps Velocidad del puerto >= 45 Mbps

Velocidad del puerto

Servicios de llamada al cliente

Servicio llamada en espera Servicio trazas llamada

Tipo de servicioNúmero de versión softwareFecha de inicio servicio

Servicio multiconferencia

Tipo de servicio =Llamada en espera

Tipo de servicio =Multiconferencia

Tipo de servicio =Trazas llamada


4. Entornos de gestión de telecomunicación orientados a objetos 61

Fig. 4.3 Modos de subclases para bases seleccionadas de especialización

Para el desarrollo de productos o redes usando metodologías de modelado orientado a objetos, laarquitectura de la red debe organizarse usando jerarquías de herencia y agregación. La jerarquía deherencia debe enumerar todas las versiones y diferentes configuraciones que la red o el productopueda manifestar. En la figura aparece como ejemplo la jerarquía de agregación que se manifiesta enla arquitectura de la red inteligente.

Fig. 4.4 Esquema de arquitectura de la red inteligente

SSP

AD/SN

STPIP

SCE SMS SCP SDP

Local

LocalTerminal deusuario A

Terminal deusuario B

Red de señalización SS7

RTC

SCP: Punto de control de serviciosSSP: Punto de conmutación de serviciosSTP: Punto de transferencia de señalizaciónSMS: Sistema de gestión de servicios

IP: Periférico inteligenteSDP: Punto de datos de serviciosSCE: Entorno de creación de serviciosAD: AdjuntoSN: Nodo de servicios

Disjuntos Solapados

Completos

Incompletos

Másdeseable No deseable

Deseable Lo menosdeseable


Gestión de red62

Fig. 4.5 Jerarquía de agregación parcial para la red inteligente

[1] [1] [1] [1] [1]

[1] [1] [1] [1] [1] [1] [1]

[1, - ] [0, - ] [0, - ] [0, - ] [0, - ] [0, - ] [0, - ]Punto deConmutaciónde servicio

Punto deTransferenciade señal

Punto decontrol deservicio

Sistema desoporte deoperaciones

Procesadoradjunto

Nodod deservicio

Periféricointeligente

Redinteligente

Función deconmutaciónde servicio

Función decontrol dellamada

Función decontrol deservicio

Funciónde datosde servicio


Función dedatos deservicio

Función derecursosespecializados

Función deconmutaciónde servicios

Función decontrol dellamada


Función dedatos deservicio

Función derecursosespecializados


6. Red De gestión de las telecomunicaciones (TMN) 63

5 Gestión según OSI

El fundamento del sistema de gestión OSI es la base de datos que contiene información relativa a losrecursos y elementos que deben ser gestionados (MIB). La estructura de gestión de información (SMI)identifica los tipos de datos que pueden ser usados en la MIB y cómo se representan y nombran losrecursos dentro de la MIB [STA2].

Cada recurso que se monitoriza y controla por el sistema de gestión OSI se representa por un objetogestionado, como por ejemplo: conmutadores, estaciones de trabajo, PBX, programas en cola,algoritmos de encaminamiento, etc.

En este caso de gestión, la complejidad de la gestión se traslada al agente (que reside en unordenador). Los protocolos de gestión permiten realizar funciones más complejas dado que el modelode información también es complejo. La evolución de este tipo de gestión permitirá realizar unagestión integrada en entornos heterogéneos (p.e. TMN).

Las recomendaciones de la serie X.700 permiten hablar de una serie de modelos de gestión desistemas. Son los siguientes:

- Modelo de comunicaciones: se detalla el protocolo de gestión y el servicio que proporciona.- Modelo de información: se definen los recursos de red usando una sintaxis abstracta.- Modelo funcional: se definen las funciones de gestión que proporcionan una interfaz a la aplicaciónde gestión.- Modelo de organización: se exponen las posibles subdivisiones de la red en dominios de gestión.

5.1 Modelo funcional

El modelo funcional describe las cinco áreas en las que tradicionalmente se ha dividido la gestión dered: gestión de fallos, gestión de configuración, gestión de prestaciones, gestión de contabilidad ygestión de seguridad.

El sistema de gestión basado en OSI define una serie de niveles con interfaces de gestión queinteractúan con la base de datos MIB. El nivel de aplicación interactúa, a su vez, con otros procesos degestión mediante el protocolo CMIP (Fig. 5.1).


Gestión de red64

OSI ha definido cinco grandes áreas de gestión (SMFAs) denominadas de fallos, contabilidad,prestaciones, seguridad y configuración (Fig. 5.2). Estas áreas están a su vez constituidas por diversasfunciones específicas (SMF) que realizan procesos de gestión, interactuando con los servicios CMISE.

LME

LME

LME

LME

LME

LME

LME

Entidad de aplicaciónde gestión de sistemas

Entidad depresentaciónEntidad desesión

Entidad detransporte

Entidad de red

Entidad denivel de enlace

Entidad física

Base de datosde informaciónde gestión

LME: layer-management entity

Proceso de aplicación de gestión de sistemas

Interfaz de gestiónde capas

Interfaz de gestión desistemas

CMIPProcesoagente

MIB

Fig. 5.1 Marco de gestión OSI

5.2 Modelo de organización

El modelo de organización parte de una estructura de red dividida en dominios de gestión. La divisióndel entorno se realiza a partir de dos aspectos principales: políticas funcionales (p. e. dominios conuna misma política de seguridad, contabilidad,...), o bien otras políticas, como dominios geográficos,tecnológicos, etc.

La red se estructura en dominios administrativos, con la necesidad de establecer y mantener lasresponsabilidades de cada dominio. Por otra parte, el sistema permite que dentro de un dominio, sepueda reasignar dinámicamente el papel de gestores y agentes.

5.3 Modelo de comunicaciones: CMIP

El Common Management Information Protocol (CMIP) se define en el estándar 9596 de OSI. Esteprotocolo ofrece un mecanismo de transporte en la forma de servicio pregunta-respuesta para capasOSI. La especificación del protocolo describe precisamente cómo se ejecutan los servicios CMIS



individuales. En la figura 5.3 se pueden observar los estándares relacionados con la gestión definidapor OSI.

Gestión defallos

Gestión decontabilidad

Gestión deconfiguración

Gestión deprestaciones

Gestión deseguridad

Gestión deobjetos

Gestión deestados

Gestión derelaciones

Informaciónde alarmas

Gestión deinformación deeventos

Control deregistros

Información deseguridad y alarmas

Pruebas deseguridad-audit.

Control deacceso

Registro decontabilidad

Monitorizaciónde carga de trabajo

Gestión detest

Sumarización

Áreas funcionales de gestión específicas (SMFA)

Funciones de gestión del sistema (SMF)

Event report Get Set Action

Create Delete Cancel-Get

Servicios CMISE

Fig. 5.2 Funciones de gestión de sistemas

Una parte de la especificación del protocolo CMIP es la definición de la Abstract Syntax Notation(ASN.1) para codificación y decodificación de unidades de datos del protocolo CMIP (PDUs). Estosaspectos se estudiarán en el capitulo 12, relativo a Internet.

A lo largo de la evolución del protocolo CMIP han surgido variantes del protocolo para diferentesentornos. Por ejemplo, existe una versión de CMIP sobre protocolos TCP/IP denominada CMOT, obien el caso de una versión de CMIP sobre protocolos IEEE de LANs denominada CMOL.

En la figura 5.4 se detallan los subniveles que forman el nivel de aplicación en un entorno de gestiónsegún el estándar OSI (Entidad de Aplicación de Gestión de Sistemas, SMAE).


Gestión de red66

5.3.1 Características principales del protocolo CMIP

Entre las características más importantes del protocolo CMIP se pueden destacar las siguientes:

- CMIS/CMIP requiere de gran cantidad de memoria y capacidad de CPU.- Se generan largas cabeceras en los mensajes de los protocolos.- Las especificaciones son dificiles de realizar y tediosas de implementar en aplicaciones.- La comunicación con los agentes está orientada a conexión.- La estructura de funcionamiento es distribuida.- Permite una jerarquía de sistemas de operación.- El protocolo asegura que los mensajes llegan a su destino.

El hecho de que se trate de una gestión conducida por eventos se traduce en que:- El agente notifica al gestor de sucesos la información concerniente a los recursos

gestionados.- El agente es responsable de monitorizar los recursos.- Presenta la ventaja de que existe menor gestión de tráfico.- Presenta la desventaja de tener agentes más complejos.

Gestión delmarco de trabajo7498-4 X.700

Introducción a la gestiónde sistemas

10040 X.701

Funciones de gestiónde sistemas10164-n X.7nn

Servicio de informaciónde gestión común9565 X.710

Protocolo de informaciónde gestión común9596-1 X.711

Definición deinformación de gestión10165-2 X.721

Tutorial de gestión delsistema

Modelo de información degestión10165-1 X.720

Guias para la definición deobjetos gestionados10165-4 X722

Definiciónes deobjetos gestionados

Fig. 5.3 Relaciones entre estándares OSI



Proceso de aplicación

SMAE SMASE

CMISE

ROSEotros ASEs

ACSE

Nivel de presentación

Proceso de aplicación

SMAESMASE

CMISE

ROSEotros ASEs

ACSE

Nivel de presentación

MAPDUs

CMIPDUs

MAPDUs: unidad de datos de protocolo de aplicación de gestión.

CMIPDUs: unidad de datos de protocolo de información de gestión común.

Fig. 5.4 Gestión en el nivel de aplicación

5.3.2 Servicios usados por CMIP

CMIP hace uso de ACSE ya que establece y finaliza asociaciones para el intercambio de informaciónde gestión. El tipo de asociación se especifica en el campo Application Context de la primitiva deasociación de ACSE (manager, agent, o manager-agent). Es usado directamente por el usuario degestión.

El protocolo CMIP también hace uso de ROSE, ya que es usado por CMISE para la solicitud deejecución de operaciones remotas. El gestor solicita una operación remota, el agente lo intenta ejecutary devuelve el resultado del intento. ROSE se utiliza por aplicaciones tipo cliente-servidor.

5.3.3 Servicios ofrecidos por CMIP

A través de CMISE (Common Management Information Service Element), CMIP proporciona trestipos de servicio:

- Manejo de datos: usado por el gestor para solicitar y alterar información de los recursos del agente.- Informe de sucesos: usado por el agente para informar al gestor sobre diversos sucesos de interés.- Control directo: usado por el gestor para solicitar la ejecución de diversas acciones en el agente.También hace uso del servicio de operaciones remotas proporcionado por ROSE.


Gestión de red68

5.3.4 Primitivas CMIP

Existen las siguientes primitivas CMIP para petición de operaciones:

- M-EVENT-REPORT (conf/no-conf) -> notificacionesInforma de un evento acerca de un objeto gestionado desde una capa de usuario de servicio CMISE.

- M-GET (conf) -> manejo de datosPide la obtención de información de gestión desde una capa de usuario de servicio CMISE.

- M-SET (conf/no-conf) -> manejo de datosPide la modificación de información de gestión desde una capa de usuario de servicio CMISE.

- M-ACTION (conf/no-conf) -> control directoPide que una capa de usuario de servicio CMISE realice una acción.

- M-CREATE (conf/no-conf) -> control directoPide que una capa de usuario de servicio CMISE cree una instancia de un objeto gestionado.

- M-DELETE (conf/no-conf) -> control directoPide que una capa de usuario de servicio CMISE borre una instancia de un objeto gestionado.

- M-CANCEL-GET (conf) -> control directoPide que una capa de usuario de servicio CMISE cancele una petición previa de invocación de unservicio M-GET.

La estructura de los mensajes de operaciones CMIP tiene los siguientes campos de información:

- Object Class- Object Instance- Scope (subarbol, niveles,...)- Filter (todos los objetos con determinadas condiciones lógicas)- Access Control- Synchronization- Attribute Identifier List

Se definen las siguientes primitivas CMIP para transmisión de resultados:

- M-EVENT-REPORT-RES- M-GET-RES- M-SET-RES- M-ACTION-RES- M-CREATE-RES- M-DELETE-RES- M-LINKED-REPLY

Las primitivas de servicio M-GET, M-ACTION y M-DELETE son primitivas que pueden especificaroperaciones en múltiples objetos, incluyendo un parámetro de enlace para proporcionar múltiples



réplicas a una única petición. Aunque la primitiva M-SET también permite la especificación demúltiples objetos, no soporta respuestas enlazadas. Para las cuatro primitivas se proporcionanherramientas para la selección de objetos, basadas en el filtrado, la sincronización y la contención(scope).

5.3.5 Arquitectura de comunicaciones

A continuación se presenta en la figura la torre de protocolos OSI que soporta el estándar de gestiónCMIP:

Nivel OSI de transporte

Nivel OSI de sesión

Nivel OSI de presentación

Subred 1 X25

Subred 2 802.3

ACSE ROSE ACSE

CCRCMISE

FTAM

ASE específica de gestión

Aplicación de gestión

Nivel 7

Nivel 6

Nivel 5

Nivel 4

Nivel 1-3

Fig. 5.5 Arquitectura de niveles definida para el protocolo CMIP

Actualmente las plataformas de gestión con protocolo CMIP de diferentes fabricantes presentaninformación que es propietaria, de forma que existe una cierta incompatibilidad si se quieren utilizarconjuntamente en la gestión de una red. En la figura adjunta se describe esta situación.

Finalmente, y más recientemente, se ha presentado el interfaz XOM/XOP, definido por la asociaciónX/Open para la coexistencia de protocolos SNMP con CMIP. A partir de unos proxies se permite lacomplementariedad de gestión de ambos protocolos en redes grandes. En entornos locales se utilizaSNMP y, a nivel de red de área extensa, se suele hacer uso del protocolo CMIP.


Gestión de red70

MIB propietario

Standard MIB

MIB propietario

Standard MIBSistemas

gestionados

Fabricante A Fabricante B


Aplicaciones de plataforma y gestión

Aplicaciones de plataforma y gestión

Sistemas de gestión de red

CMIP CMIP CMIPCMIP

CMIPCMIP

Agentes de objetos gestionados

Agentes de objetos gestionados

Fig. 5.6 Sistemas de gestión de red basados en CMIP emergentes

5.3.6 X/Open Abstract Data Manipulation Application Program Interface XOM

OSI Abstract Data Manipulation API (XOM) define un interfaz de programación de propósito generala gestión de objetos OSI (gestión de objetos como la creación, el examen, la modificación y el borradode objetos potenciales de información compleja).

La arquitectura de información XOM (XOM Information Architecture) especifica el intercambio entrecliente y servicio, y que el servicio mantiene y hace accesible al cliente. La arquitectura proporcionauna base para especificar interfaces de servicio, como por ejemplo, cómo el cliente comunica con elservicio, cómo el servicio comunica con el cliente en respuesta, y cómo componentes del serviciocomunican unos con otros. La arquitectura no dicta la estructura física de la información ni cómo elservicio la mantiene internamente.

La XOM Information Syntaxes define la sintaxis permitida de valores atributo. Las sintaxis sonsimilares a los tipos y constructores de tipos de ASN.1.

La XOM Service Interface especifica:

- Los tipos de datos del interfaz de servicio (p.e. booleano, objeto, string,..)- Las funciones que el servicio hace dsponibles al cliente (p.e. copy, create, get, put, remove,..).- Los códigos de retorno de las funciones de interfaz de servicio (p.e. codificación invalida, errorespermanentes,...).

El XOM Workspace Interface define tipos que especifican la parte inicial de la representación deobjetos y algunas estructuras de datos asociadas. También proporciona una definición de macros paracada función interfaz de servicio, que usa la estructura de datos definida para llamar la



implementación de las funciones apropiadas para los argumentos particulares. La especificación XOMincluye también Object Management Package donde se define la jerarquía de clases y algunas clasesde objetos.

5.3.7 X/Open Management Protocols Application Program Interface (XMP)

La X/Open Management Protocols Application Program Interface (XMP) define un ApplicationProgram Interface (API) para servicios de información de gestión. La interfaz se diseñó para ofrecerservicios que están relacionados con los estándares CMIS/CMIP y SNMP. El XMP opera entre unaaplicación de usuario y el software común definido por la X/Open y aísla la parte del programador detodas las operaciones del software X/Open. Permite la manipulación de diferentes estructuras deinformación de gestión descritas en ISO 10165 y RFC 1155.

Gestión depaquetes de servicio

PaqueteDMIPaquete comun

PaqueteCMIS

PaqueteSNMP

Espacio de trabajo de losobjetos gestionados

PaqueteXOM

Programa de gestión

API XOM API XMP

Fig. 5.7 Relación entre XOM y XMP

La especificación XMP describe un número de funciones con muchas clases y objetos OM, que seutilizan como argumentos y resultados de las funciones. La interfaz modela interacciones de gestióncomo peticiones de servicio. Estas peticiones de gestión se realizan a través de un número defunciones interfaz, que usan un número de argumentos de entrada. Cada petición válida causa unaoperación realizada por agente o notificación direccionada al gestor. Después de algunas operaciones,un estatus o los resultados de las operaciones pueden devolverse. Todas las interacciones gestor-agente se realizan durante una sesión, que se representa por un objeto usado en la mayor parte de lasfunciones interfaz.

La tarea del programador es crear funciones de llamada que invoquen operaciones CMISE o SNMP.


Gestión de red72

5.3.8 CMIS/P++

CMIS++ es una nueva versión de CMIS que proporciona mucha más potencia expresiva, mientras queCMIP++ soporta evaluación remota y minimiza el tráfico de gestión requerido para la obtención deinformación de gestión. Esta extensión de la arquitectura se justifica por los requerimientos quepresenta la gestión de redes como SDH.

5.4 Modelo de información

El modelo de información proporciona una representación de los recursos gestionados. En el esquemade la figura 5.8 se muestra el proceso de obtención de la información de gestión del entorno de red.

Operaciones gestión

Notificaciones

Gestor Agente

Notificaciones

Operaciones gestión

Entorno local

Fig. 5.8 Esquema del proceso de gestión en un entorno de red

El objetivo consiste en modelar los aspectos de gestión de los recursos reales, así como definir unaestructura para la información de gestión que se transmita entre sistemas.

Este modelado se estructura en función de unos objeto gestionados (MO: Managed Object) que sepueden definir como abstracciones de un recurso que representa sus propiedades para el propósito desu gestión (p.e. entidad de capa, conexión, item de un equipo de comunicaciones físico). Para el casoque nos ocupa, sólo es necesario definir los aspectos del recurso útiles para su gestión. De la mismaforma no se define la relación entre el recurso y su abstracción como objeto gestionado, que suele serdefinido por el fabricante.

Entre los componentes de un objeto gestionado, pueden distinguirse una serie de atributos visibles, lasoperaciones de gestión de sistemas permitidas sobre el objeto, el comportamiento del objeto enrespuesta a las operaciones de gestión, las notificaciones que puede enviar, los paquetes condicionalesque pueden ser encapsulados en el objeto (características opcionales del objeto), la posición del objetoen la jerarquía de herencia o bien la especificación de las clases de objetos alomórficas con su clase.

Por otra parte, el modelo de información hace uso de los principios de diseño orientado a objetos. Paraello, se requiere adaptar un enfoque que permita estandarizar especificaciones de una manera modular.El enfoque elegido debe proporcionar una fácil capacidad de extensión del protocolo y de losprocedimientos. También se debe permitir la reutilización de especificaciones anteriores. Finalmente,hay que tener en cuenta que el ámbito de diseño es aplicado a la especificación de informacióntransmitida en los protocolos de gestión, no a la implantación.



Antes de seguir adelante es necesario repasar una serie de conceptos relacionados con el diseñoorientado a objetos que se utilizan en la gestión OSI.

El árbol de registro sirve para que todos los elementos definidos en una MIB puedan tener asignadosun Object Identifier (OID). Los OIDs de gestión de sistemas se registran por debajo de:

{joint-iso-ccitt ms (9)}

que es el identificador principal (top). Por debajo de éste, se asignan otros identificadores quedependiendo de la concreción de la información y forma donde se definan, van creando las hojas delárbol de registro. Las ramas sucesivas del árbol son las siguientes:

smo (0)cmip (1)function (2)smi (3)

El encapsulamiento es una relación de inclusión entre un objeto gestionado y sus atributos,notificaciones, operaciones y comportamiento. Asegura la integridad de los objetos gestionados. Lasoperaciones sobre un objeto se realizan mediante el envío de mensajes al objeto. Por otra parte, no esvisible la operación interna del objeto, salvo cuando se hayan definido atributos, operaciones onotificaciones para mostrar esta información.

En cuanto a las clases y ejemplares, se diferencia entre los aspectos relativos a la definición de losobjetos y los aspectos de implementación de estos objetos. Es decir, la definición de objetos nos llevaa 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 lasmismas condiciones para la presencia de estos packages (lotes). Dan como resultado un texto condefiniciones de clases. Por otra parte, la implementación de objetos como ejemplares (o instancias) delas clases dan lugar como resultado a instancias existentes en un agente en un momento dado.

Una clase de objeto es un conjunto de ejemplares de objetos gestionados con las mismas propiedades.Una especialización genera una nueva clase (subclase) por extensión de otra ya existente (superclase),añadiendo nuevas propiedades. Por tanto, introduce una relación de herencia.

Las propiedades de una clase se pueden extender a partir de la ampliación con nuevos atributos, laextensión/restricción de los rangos de atributos, la ampliación con nuevas acciones o notificaciones obien la ampliación de los argumentos de acciones y notificaciones. Existe una TOP o superclasesuperior de la jerarquía de la herencia que contiene las propiedades comunes a todos los objetosgestionados. Por otra parte, se permite sólo la herencia estricta de las propiedades, es decir, que unasubclase se especialice mediante la adición de nuevas propiedades (no se pueden quitar propiedades).También se permite herencia múltiple, lo que conlleva una serie de beneficios: una mayorreutilización de las definiciones de clases y una mejora de la capacidad de un sistema gestor parareconocer clases no conocidas.

Ejemplo de jerarquía de herencia:


Gestión de red74

cima

sistemared

equipo

bridgerouter

Red X.25

Fig. 5.9 Esquema un árbol de jerarquía de herencia

Los atributos de objetos gestionados representan las propiedades de un objeto gestionado. Losatributos tienen un valor asociado que puede ser un conjunto o una secuencia de elementos. Puedehaber constricciones en el valor de un atributo o entre valores de distintos atributos. Por otra parte, losatributos pueden ser obligatorios o contenidos en paquetes condicionales (opcionales). También sepermiten atributos multivaluados y atributos de grupo.

El comportamiento (behaviour) define a los miembros de la misma clase si exhiben el mismocomportamiento (interactúan) ante la misma operación de gestión. El comportamiento de un objeto sedefine por la semántica de atributos, las operaciones y notificaciones, la respuesta a operaciones degestión sobre el objeto, las circunstancias bajo las que se emiten las notificaciones, las dependenciasentre valores de atributos particulares y los efectos de las relaciones entre los objetos.

Los paquetes condicionales (packages) definen los atributos opcionales, las notificaciones, lasoperaciones y los comportamientos que están o todos presentes o ausentes a la vez en un objetogestionado (p. e. correo electrónico con paquete condicional de seguridad). La condición de presenciada idea de las capacidades del recurso, mientras que el atributo packages informa de los paquetescondicionales que soporta el objeto.

El alomorfismo es la capacidad de un ejemplar de una subclase de simular el comportamiento de susuperclase. Permite la extensión de una clase de tal manera que continúe la interoperabilidad cuandoel gestor o el objeto gestionado no incluyan esta extensión. Por otra parte, se necesita para posibilitarla migración de versiones de gestión. Existen una serie de constricciones para las subclasesalomórficas: esto es, deben incluir un atributo que identifique las superclases alomórficas de esasubclase, y el rango de valores de un atributo heredado debe ser el mismo o un subconjunto del rangode la superclase. Existen también las superclases no restringidas, que son superclases sin restriccionesen sus valores. Se especializan subclases alomórficas con distintas restricciones que no seríanpermitidas en un alomorfismo directo entre ellas.

La determinación del comportamiento alomórfico se representa mediante un argumento en la peticiónde la operación. También puede representarse si se proporciona una lista ordenada de clases conocidaspor el sistema gestor. Por otra parte, la clase que se aplique será aquella que sea superclase alomórficapermitida y que aparezca primera en la lista.



Existen una serie de operaciones posibles sobre objetos. Una operación en un objeto gestionado sirvepara afectar la gestión del sistema. Se pueden definir dos clases de operaciones: las operacionesaplicables 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 oindirectos.

Las acciones representan la capacidad del objeto de realizar una acción distinta ante cambios en laspropiedades. Son útiles para modelar la ejecución remota de comandos.

La notificación es un informe emitido por el objeto cuando se cumplen determinadas condiciones. Lascondiciones de las notificaciones se especifican en la definición. Por otra parte, se define un EFD(Event Forwarding Discriminator) que permite filtrar las notificaciones que llegan a los gestores.

Como resumen se puede decir que para la definición de clases se parte de la posición en la jerarquíade herencia, los atributos de la clase, los comportamientos, las acciones, las notificaciones, y las clasesalomórficas. Las propiedades anteriores se pueden agrupar en paquetes (obligatorios o condicionales).

raíz

sistema

Estación detrabajo

PC

Unidaddisco

Placa red Unidaddisco

PC

sistema

Fig. 5.10 Esquema de árbol de agregación

Una jerarquía de agregación refleja la relación de contención entre instancias de objetos. Cuando seestablece una jerarquía de agregación, una instancia subordinada está contenida en una única instanciasuperior. Tiene como utilidad la estructuración de instancias de objetos en los agentes (usado por losparámetros de filtrado y ámbito del CMIP. También permite realizar operaciones con una granpotencia). Define también el nombrado de los ejemplares desde el gestor. En la figura 5.10 se muestraun ejemplo de árbol de agregación.

Para el nombrado de instancias, cada clase de objetos gestionados debe tener al menos un atributo queproporcione un nombre distintivo a los ejemplares de esa clase. Este atributo es el Relative


Gestión de red76

Distinguished Name (RDN). El nombre de una instancia es la concatenación de RDN de susantecesores en la jerarquía de agregación.

Un ejemplo de nombre completo de instancia es el siguiente:SistemaId=DEPART3@PCId=PCMarketing@UnidadID=DiscoA

raíz

sistemaSisID=ST5

Estación detrabajo

WSId=Sun5

PCPCid=PC7

Unidad discoUnid=B

Placa redPlacaId=Eth1

Unidad discoUnID=C

PCPCId=PC2

sistemaSisID=ST8

SisId=ST5@PCId=PC2@UnID=C

Fig. 5.11 Esquema de nombrado completo de instancia

El name binding proporciona restricciones para organizar la jerarquía de agregación. Por ello, sedefinen junto a la definición de clases. La estructura de un name binding se compone de una clasesubordinada, una clase superior permitida y un atributo identificador para el nombrado de la clasesubordinada. Hay que decir que pueden existir (y es deseable) varios name bindings para una mismaclase subordinada.

5.4.1 MIB (Management Information Base)

Una MIB es un conjunto de definiciones de uno o varios recursos formado por clases de objetosgestionados, acciones, notificaciones, atributos, sintaxis, etc, y los name bindings. Actualmente hayuna gran variedad de MIBs definidas y normalizadas.

Una MIB no tiene por qué ser autocontenida, ya que permite referencias a otras MIBs. La sintaxis deMIBs se basa en la notación GDMO (Guidelines for Definition of Managed Objects). Existen unaserie de criterios para implementar una MIB, como son el uso de herencias de definiciones yaexistentes y el establecer ligaduras de nombrado siempre que sea posible.

Una MIB puede interpretarse como la extracción de árbol de herencia y extracción de los posiblesárboles de agregación (a partir de las ligaduras de nombrado), así como para ver la capacidad degestión que ofrece: atributos que se pueden leer (o leer y controlar).



5.4.2 GDMO (Guidelines for Definition of Managed Objects)

La notación GDMO proporciona las pautas para la definición de MIBs. Por ello, se hace uso de unasmacros que se definen mediante macros ASN.1. La norma proporciona además normas útiles paradiseñar MIBs, como son el agrupamiento de datos, el uso de herencia y la definición de relaciones.

Existen una serie de macros GDMO para la definición de:- MANAGED OBJECT- PACKAGES- PARAMETER- NAME BINDING- ATTRIBUTE- ATTRIBUTE GROUP- BEHAVIOUR- ACTION- NOTIFICATION

A continuación se especifican las plantillas correspondientes a las macros anteriores, para ello seutiliza la siguiente notación:

Notación:

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 constructorsupporting productions: amplia información sobre algún elemento definido en las plantillas.

Plantilla de object class (clase de objeto):

<clase> MANAGED OBJECT CLASSDERIVED from <clase>;

CHARACTERIZED BY<package> | <PACKAGE>[, <package> | <PACKAGE>]*;

CONDITIONAL PACKAGES<package> PRESENT IF <condition>[, <package> PRESENT IF<condition>]*;

REGISTERED AS {nº de registro}


Gestión de red78

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 productionspropertylist -> [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-labelget-replace -> GET |REPLACE | GET-REPLACEadd-remove -> ADD | REMOVE | ADD-REMOVE

Plantilla de attribute (atributo)

<atributo> ATTRIBUTE

DERIVED from <atributo>;oWITH 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}];



Plantilla de behaviour (comportamiento)

<etiqueta-comportamiento> BEHAVIOUR

DEFINED AS “<descripción>“;

Plantilla de notification (notificación)

<notificación> NOTIFICATION



[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 (acción)

<action> ACTION


[MODE CONFIRMED;]


[WITH INFORMATION SYNTAX <tipo ASN.1>

[WITH REPLY SYNTAX <tipo ASN.1>; ]


Plantilla de name binding (ligazón de nombres)

<nombre-relación> NAME BINDING

SUBORDINATE OBJECT CLASS <clase> [AND SUBCLASSES];

NAMED BY SUPERIOR OBJECT CLASS <clase> [AND SUBCLASSES];


Gestión de red80

WITH ATTRIBUTE <attribute>;


[CREATE [WITH-REFERENCE-OBJECT | WITH-AUTOMATIC-INSTANCE-NAMING][<PARAMETRO>*];]

[DELETE [ONLY-IF-NO-CONTAINED-OBJECT | DELETES-CONTAINED-OBJECTS][<PARAMETERS>*];]




6 Red de gestión de las telecomunicaciones (TMN)

La TMN (Telecommunications Management Network) proporciona funciones de gestión ycomunicaciones para la operación, la administración y el mantenimiento de una red detelecomunicaciones y sus servicios en un entorno de multiples fabricantes [SLO1].

Existieron dos motivaciones básicas para el desarrollo de la arquitectura TMN: una es la crecienteheterogeneidad en la tecnología para la construcción de redes de telecomunicación, y la coexistenciade redes analógico-digitales; otra se deriva de las mayores demandas sobre: posibilidad de introducirnuevos servicios, alta calidad de servicios, posibilidad de reorganizar las redes. métodos eficientes detrabajo para operar las redes y competencia entre empresas operadoras privadas.

La TMN define la relación entre los bloques funcionales básicos constituyentes de la red (sistemas deoperación (OS), red de comunicaciones de datos, elementos de red (NE)) a través de interfacesestándares. Introduce el concepto de control de subred (conjunto de elementos de red agrupados segúnun determinado criterio (p.e. función, provedor,…) y es tratada como una sola entidad por laaplicación de gestión. El dispositivo que implementa la funcionalidad OAM&P de subred, el elementogestor (EM), simplifica la comunicación entre OSs y NEs. Desde el punto de vista de la arquitectura,el EM es un punto de gestión flexible que une la realización del fabricante con los sistemas de gestiónde la red, utilizando las interfaces y modelos de información definidos en la TMN.

Las recomendaciones que regulan la TMN son las de la serie M.3XXX de la ITU-T. En estasrecomendaciones se definen los siguientes modelos y arquitecturas:

- Arquitectura física: estructura y entidades de la red.- Modelo organizativo: niveles de gestión.- Modelo funcional: servicios, componentes y funciones de gestión.- Modelo de información: definición de recursos gestionados.

Las recomendaciones para la red TMN son las siguientes:

M.3000. Introducción a la recomendación TMN.M.3010. Principios para una red de gestión de telecomunicaciones.M.3020. Metodología para la especificación de la interfaz TMN.M.3100. Modelo de información de elementos de red genéricos.M.3101. Requerimientos para conformar objetos gestionados en TMN M.3100.M.3180. Catálogo de información de gestión TMN.


Gestión de red82

M.3200. Introducción a los servicios de gestión TMN.M.3300. Capacidades de gestión TMN presentadas en la interfaz F.M.3400. Funciones de gestión TMN.M.xfunc. Servicios de gestión TMN y funciones para la interfaz X.M.xinfo. Identificación de la información que se intercambia vía la interfaz X para diferentes casos deacceso.

Red de comunicación de datos

Red de comunicación de datos

��

��

��

Red TMN

X

Sistema Satélite

Elementos de red

Adaptadores a interfaz Q

Dispositivos de mediación

Estaciones de trabajo

F

F

Q3

QxQ3

Q3Q3 Qx

QxQx

Qx

Q3

Adaptadores a interfaz Q

Fig. 6.1 Esquema de arquitectura física TMN



6.1 Arquitectura física

La arquitectura física de TMN proporciona la manera de transportar la información de los procesosrelacionados con la gestión de las redes de telecomunicaciones.

Los componentes que forman esta arquitectura física son los siguientes:- sistemas de operaciones (OS)- redes de comunicaciones de datos (DCN)- dispositivos mediadores (MD)- estaciones de trabajo (WS)- elementos de red (NE)- adaptadores Q (QA).

Fig. 6.2 Arquitectura física de la TMN

Las interfaces TMN se basan en conceptos del modelo de referencia OSI (ITU-T X.200):

Interfaz Qx: es una interfaz apropiada para pequeños elementos de red que requieran unas pocasfunciones OAM utilizadas con gran frecuencia. Utilizada normalmente por los NEs y MDs máscomplejos.

Interfaz Q3: soporta un complejo conjunto de funciones y requiere el servicio de bastantes protocolospara poderlas ofrecer. Para las OSs y los NEs se encuentra especificada en los documentos T1.204-1989 y T1.208-1989 de ANSI. Está compuesta por:

Modelo de comunicaciones: protocolo CMIPModelo de información: semántica de datos (MIB’s GDMO).

OS

DCN

MD

WS

WSDCN

QA NE QA NE

X

X

Q3 X/F/Q3

QX

Q3/F

X/F/Q3

F G

F G

QX X/F/QX

TMN


Gestión de red84

Interfaz X: soporta el conjunto de funciones para la interconexión de diferentes OSs, ya sea entreentornos de TMNs o no. Requiere de las 7 capas de OSI, según está definido en la normativa T1.217de ANSI. Los mensajes y protocolos definidos para la interfaz X podrían usarse igualmente en lainterfaz Q3.

Interfaz F: soporta el conjunto de funciones para la interconexión de estaciones de trabajo concomponentes físicos de la red de comunicaciones que contengan las OSF o las MF.

6.2 Modelo organizativo

El modelo organizativo (de capas de TMN) definido por la ITU-T establece las siguientes capas degestión:

- gestión comercial- gestión de servicios- gestión de red- gestión de elementos de red- elementos de red.

Este modelo va más allá del que se define para una organización de la red desde un punto de vistatécnico, puesto que cubre variados aspectos de administración en el sector del marketing y losservicios, requeridos por las empresas proveedoras de servicios. A continuación se describen lasfunciones relacionadas con la organización de la TMN. Ésta se estructura mediante un modelo decapas:

Capa de gestión comercial: soportada por un sistema de operación comercial (OS) con las siguientesfunciones asociadas:- gestión completa y responsabilidad de empresa total- tareas de asignación de objetivos- acción ejecutiva

Capa de gestión de servicios: soportada por un sistema de operación de servicios (OS) con lassiguientes funciones asociadas:- interfaz con clientes y otras administraciones- interacción con proveedores de servicios- mantenimiento de los acuerdos de nivel de servicio- mantenimiento de datos estadísticos- interacción entre servicios

Capa de gestión de red: soportada por un sistema de operación de red (OS) con las siguientesfunciones asociadas:

- provisión, cese o modificación de las capacidades de la red para el soporte de servicios a clientes.- control y coordinación de todos los elementos de la red con su ámbito y dominio.



Capa de gestión de elementos de red: soportada por un sistema de operación de elementos de red(OS, MD) con las siguientes funciones asociadas:- mantenimiento estadístico, control y coordinación de elementos de la red.

Capa de elementos de red: que forma los elementos de la red (NE).

6.3 Modelo funcional

El modelo funcional se compone de Bloques de Servicios, Componentes y Funciones de gestión. Laidea consiste en descomponer las funcionalidades de mayor a menor nivel en bloques reaprovechables(según las necesidades desde el punto de vista de los operadores).

Servicios de gestión TMN

Los servicios de gestión que se definen son del siguiente tipo:- Administración de abonados. Administración de encaminamiento y análisis de digitos.Administración de medidas y análisis de tráfico. Administración de la tarificación.- Gestión de la seguridad de la TMN. Gestión de tráfico. Gestión del acceso de abonado. Gestión decircuitos entre centrales y equipo asociado. Gestión de la red de conmutación. Gestión de equipos enla instalación del usuario. Gestión del servicio controlado por el abonado. Gestión del sistema deseñalización por canal común. Gestión de redes inteligentes. Gestión de la TMN.- Administración de instalación del sistema. Administración de calidad de servicio y funcionamientode la red- Restablecimiento y recuperación.- Gestión de materiales.- Programa de trabajo del personal.

Componentes y funciones de gestión

De los muchos componentes que define TMN, un ejemplo de componente del servicio de gestiónpodría ser:- vigilancia de alarmas.

Funciones de gestión

Para el caso del componente de vigilancia de alarmas del citado ejemplo se podrían utilizar lassiguientes funciones:

- funciones de informes de alarmas- funciones de informes resumidos de alarmas- funciones de criterios de sucesos de alarmas- funciones de gestión de indicación de alarmas- funciones de control de registro de alarmas.


Gestión de red86

6.4 Modelo de información

El modelo de información utilizado en TMN es el definido por el interfaz Q3 en la semántica de datos(MIBs GDMO). A continuación se muestra en la figura 6.3 adjunta un esquema con los niveles deestructura de protocolo del punto de referencia Q3.

Nivel OSI de transporte

Nivel OSI de sesión

Nivel OSI de presentación

Subred 1 X25

Subred 2 802.3

ACSE ROSE ACSE

CCRCMISE

FTAM

ASE específica de gestión

Aplicación de gestión

Nivel 7

Nivel 6

Nivel 5

Nivel 4

Nivel 1-3

CMISE: servicio asociado al protocolo CMIFTAM: gestión y acceso para la transferencia de ficherosROSE: elemento de servicio de operaciones remotasACSE: elemento de servicio de control de asociacionesCCR: recuperación, concurrencia y entrega..

Fig. 6.3 Esquema de capas del interfaz Q3

Los niveles 1 a 3 del interfaz Q3 vienen definidos por el estándar Q.811 que especifica diversasconfiguraciones de acceso:

- CONS1: Para redes X.25 sobre redes públicas de datos.- CONS2: RDSI canal D.- CONS3: RDSI canal B.- CONS5: Protocolo MTP del SS7.- CONS6: X.25 sobre LANs.- CLNS1: Red Ethernet.- CLNS2: X.25 con protocolo ISO/IP.



Para los niveles altos, se utiliza la recomendación Q.812 que define dos tipos de perfiles de protocolo:perfiles para servicios de tipo transacción y perfiles para servicios de tipo transferencia de ficheros. Elnivel de aplicación suele cubrirse mediante el protocolo CMIP.

6.5 Implementación física de las funciones de la TMN

La implantación física de sistemas de gestión ha seguido una progresión con el tiempo desde sistemascentralizados (sistemas de operaciones con toda la inteligencia y elementos de red sin inteligencia) asistemas distribuidos (red de sistemas de operación con inteligencia distribuida, más SNCs centros degestión de la subred, más elementos de red inteligentes).

Fig. 6.4 Esquema de sistemas de gestión de red y servicios

La estrategia de diseño de una TMN depende en gran medida de la topología y las posibilidades de lasredes de telecomunicaciones (TNs), que la TMN deberá gestionar. La aproximación tradicional paraproporcionar comunicaciones entre NEs y que los soporten los OSs es diseñar una TMN dedicada. Sinembargo, con los modernos NEs inteligentes, y la diversidad de caminos necesaria para proporcionarrobustez a la red frente a fallos, esta aproximación no es la más económica.

En la figura 6.4 se representan unos sistemas de gestión de proveedores de servicio privados ypúblicos (en la parte superior) que gestionan sistemas de operaciones de operadores de red (parteinferior). Se observan las correspondientes interacciones entre gestores y agentes de cada sistema deoperación y con las bases de datos de gestión (MIBs) de los equipos. También se observa un sistema

DUA DUA DUA DUA

A A A A

M

A

M

AAM

M

M

M

MMA

A

A

M

M

DSA DSADSADSA

Aplicacionesde gestiónde red




OSde redCPN

OSde redCPN

OSde redPN

Aplicaciones de gestión de servicio Aplicaciones de gestión de servicio

OSdeservicioCPN

OSdeservicioCPN

OS deservicioPN

Directorio

MIB MIB MIB MIB

MIB MIBMIBMIB

OSde redPN

OSde redPN

OS deservicioPN


Gestión de red88

de directorios X.500 para el almacenamiento de informaciones de perfiles de servicios y de abonadosa la red.

Fig. 6.5 Jerarquía de herencia simplificada del modelo GNIM de la TMN

FragmentoTPFragmento

de crossconexion

Red EquiposPunto determinacion

Elementogestionado software

conectividad

conexion pruebas

TMN desde M.3100

OSI desde las series X.720

alarmSeverityAssignmentprofile

loglogRecord Discriminator

alarmRecord

attributeValueChangeRecord

objectCreationRecord

objectDeletionRecord

stateChangeRecord

eventLogRecord

eventForwardingDiscriminator

top


7. Áreas funcionales de gestión 89

7 Áreas funcionales de gestión

Se puede definir la gestión de red como la planificación, la organización, la supervisión y el control deelementos de comunicaciones para garantizar un adecuado nivel de servicio, y de acuerdo con undeterminado coste.

Las recomendaciones de la OSI, posteriormente recogidas por la ITU, definen las siguientes áreasfuncionales para la gestión de red:

Supervisión y fallos: conjunto de facilidades que permiten la detección, aislamiento y corrección deuna operación anormal.Configuración: facilidades que permiten controlar, identificar, recoger y proporcionar datos a objetosgestionados, con el propósito de asistir a operar servicios de interconexión.Contabilidad: facilidades que permiten establecer cargos por el uso de determinados objetos eidentificar costes por el uso de éstos.Prestaciones: facilidades dedicadas a evaluar el comportamiento de objetos gestionados y laefectividad de determinadas actividades.Seguridad: aspectos que son esenciales en la gestión de red y que permiten proteger los objetosgestionados.

��

��

��

��

��

Políticas de gestión Gestores

Interpretan Monitor

Control

Recursos

Sistema de red

Fig. 7.1 Flujo de información de gestión

El esquema de funcionamiento que sigue un sistema de gestión (Figs. 7.1 y 7.2) parte de lasmediciones que se realizan de los recursos de la red a partir de los agentes que los mismos nodoscontienen. Estos nodos, a través de sus agentes, proporcionan la información a los gestores de la red.Los gestores, a partir de los parámetros definidos en sus políticas de gestión, actúan sobre la redmediante mensajes de control sobre los agentes de los nodos, optimizando el funcionamiento a travésde cambios de configuración, etc. Este control realizado sobre la red modifica las condiciones deltráfico y el ciclo se repite realizando nuevas mediciones sobre los recursos.


Gestión de red90

Realiza control deoperaciones

Monitoriza estatus yrecibe informes desucesos

Interpreta políticasy toma decisiones

Fig. 7.2 Bucle de actividades de gestión

El esquema de funcionamiento general de una plataforma de gestión puede verse en la figura 7.3. Eneste esquema, el usuario a través de una interfaz unificada tiene acceso a la información procedente dediversas aplicaciones de gestión (gestores). Esto se requiere así puesto que la diversidad de elementosde red procedentes de diferentes fabricantes junto con la enormidad de funciones de gestión definidaspor los estándares aconseja el procesado en paralelo.

MIB Redesgestionadas

Módulo deacceso MIB

Pila de protocolosde comunicaciones

Servicio de transporte de datos de gestión

Elementode aplicación

Aplicación degestión de red

Presentación de información de gestiónde red a los usuarios

Interfaz ausuariounificado



Aplicación degestión de red

Fig. 7.3 Modelo de referencia de un sistema de gestión de red



Los elementos de aplicación corresponden a funciones diferentes que son aprovechables por lasdiferentes aplicaciones. El servicio de transporte y las pilas de protocolos implementadas suelen sertambién de tipo variado dada la complejidad de interconexión de redes que forman los sistemas decomunicaciones actuales.

7.1 Gestión de fallos

La gestión de fallos se ocupa del conjunto de facilidades que permiten la detección, aislamiento ycorrección de una operación anormal.

El determinar el máximo de información sobre los fallos es el elemento fundamental para su buenagestión. La información de fallos debe permitir detectarlos y aislarlos. Los fallos: se detectannormalmente ante cambios de estado en los dispositivos.

Usuario Monitorización Alarmas de dispositivos

Etiquetado de problemas

conocido?Unir a problemas conocidos

sí

sí

no

no

no

sí

Back-up, reconfiguración

Determinación problema

conocido? Implementar solución

Diagnosis y reparación

Monitorizar y verificar correción

conocido?

Restauración

Actualizar bases de datos

Distribuir informes

Fin

Recuperación porla red

Diagnosis y reparación

Back-up y reconfiguración

Seguimiento de problemasdinámico

Estatus ysupervisiónde red

Fig. 7.4 Secuencia de operaciones realizadas en un sistema para corregir fallos

Existen una serie de problemas relacionados con la detección de fallos. Por ejemplo, fallos noobservables que sólo permiten detectar efectos laterales, o bien el caso de fallos inciertos, en los que lainformación sobre el fallo puede no ser fiable en cuanto a su fuente.


Gestión de red92

Por otra parte, también existen una serie de problemas en la fase correspondiente al aislamiento defallos. Puede darse el caso de una detección de múltiples fallos por una sola causa e incluso el caso dedetección de fallos por múltiples causas.

En la figura 7.4 se puede observar el proceso seguido por una aplicación de gestión de alarmas en surecorrido hasta determinar correctamente la causa concreta del fallo y el porqué de las alarmasgeneradas.

Como ejemplos de tecnologías que permiten tratar los fallos de conectividad en redes TCP/IP existenprogramas como PING o TRACEROUTE. Para la detección de fallos se puede utilizar el programaPING, que realiza un sondeo periódico del recurso mediante el protocolo ICMP (echo request).Permite también comprobar el tiempo de respuesta. Para el aislamiento de fallos se puede utilizar elprograma TRACEROUTE que permite ver la ruta que siguen los paquetes hacia un nodo y que estábasado en el parámetro Time To Live de IP.

7.1.1 Identificación de fallos en redes de comunicaciones

En este apartado se presenta un análisis introductorio a la identificación de fallos en redes decomunicaciones. El proceso de gestión de fallos se caracteriza por los siguientes tres pasos:

1) Correlación de alarmas.2) Identificación de fallos.3) Pruebas de localización.

En los procesos 1 y 2 se correlacionan los fallos observados, o las alarmas enviadas, y se proponenvarias hipótesis de fallo a fin de identificar el fallo. Posteriormente, cada una de las hipótesispropuestas se examina para localizar el fallo de una forma más precisa.

Existen muchos métodos para llegar a la obtención del fallo en una red. En este caso se presenta unaposible metodología basada en el análisis de probabilidades.

Se define un objeto como parte de la red que tiene una existencia distinta y separada. A partir de ahí,un grafo dirigido G = (E,D) es un modelo del sistema donde E equivale a los objetos terminalesactivos 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 dependientede ei. A cada vértice ei se le asigna un peso pi que es la probabilidad de que el objeto falleindependientemente del estado (falle o no falle) de cualquier otro objeto de terminal activodependiente de éste. Así, a cada par dirigido (ej, ei) se le asigna un peso pji, especificando ladependencia 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 elconjunto de objetos que podría haber causado la alarma. Se define también un cluster de alarmas,como el conjunto de alarmas cuyos dominios interseccionan unos con otros.



Supongamos que ei emite una alarma ai. Asociaremos esta alarma con todos los objetos ej en elgráfico de dependencias con pesos de dependencia pij > W, donde W es un parámetro. Escogiendodiferentes valores de W se pueden crear diferentes asociaciones de entidades con una alarma dada.

El problema de encontrar el D(ai) es una variación del problema de fuente única. En este caso, seencuentra el camino de coste mínimo desde el vértice de una fuente en un gráfico a todos los otrosvértices en el gráfico. Por ejemplo, mediante el algoritmo de Dijkstra. En este algoritmo se asocia elcoste de un camino al producto de pesos pij, donde el problema consistiría en encontrar el camino decoste máximo, que fuera también mayor que W. Ahora bien, si en lugar de adoptar pij escogemos -log(pij) como coste del camino y este coste es menor que -log(W), se puede utilizar directamente elalgoritmo de Dijkstra de coste de camino mínimo.

Como ejemplo, sea la siguiente red de la figura 7.5.

AB

C

L1

L3L4

L2

Fig. 7.5 Esquema de conexiones de una red

A partir de la red anterior, se puede construir un gráfico de dependencias, tal como se muestra en lafigura 7.6.

p1

p6

p16

p2

p32

p3

p34

p4p54p5

p56

p51p35

p31

e1=A

e5=C

e3=B

e4=L2

e2=L1

e6=L3

Fig. 7.6 Gráfico de dependencias de la red


Gestión de red94

7.2 Gestión de configuración

La gestión de configuración es un conjunto de facilidades que permiten controlar, identificar, recogery proporcionar datos a objetos gestionados con el propósito de asistir a operar servicios deinterconexión. Entre las tareas relacionadas se puede destacar la definición de información deconfiguración en los recursos, la modificación de las propiedades de los recursos, la definición ymodificación de relaciones entre los recursos, la inicialización y terminación de servicios de red o bienla distribución de software.

7.3 Gestión de prestaciones

Representan un conjunto de facilidades dedicadas a evaluar el comportamiento de objetos gestionadosy la efectividad de determinadas actividades. Entre los indicadores de prestaciones se pueden definirlos que están orientados al servicio, como la disponibilidad, el tiempo de respuesta, y la fiabilidad. Encambio, otros indicadores están orientados a la eficiencia, como el throughput (caudal, flujo) o lautilización.

En la figura 7.7 puede observarse el proceso seguido por una aplicación de gestión de prestaciones orendimientos hasta encontrar unos parámetros de funcionamiento óptimos en la red.

no

sí

sí

no

no

sí

Violaciones de losniveles de servicio

Peticiones de servicio conparámetros específicos

Evaluaciones deprestaciones

Monitorizacion de red yseguimiento histórico

Nivel de servicioadecuado?

Problema conocido?

Resolver con el originanteo llamante

Ficheros condatoshistóricos

Diagnosis y formularción desolución

Soluciónrealizable?

Implementar solución

Actualizar directorios y distribuir informes

Fig. 7.7 Proceso de gestión de prestaciones



7.4 Gestión de tarificación

La gestión de tarificación son un conjunto de facilidades que permiten establecer cargos por el uso dedeterminados objetos e identificar costes por el uso de éstos. Se puede hablar de criterios sobretarificación. Entre ellos se pueden destacar: localización geográfica, distancia desde nodo central,zonas temporales (día/semana), descuentos por volumen, precio por paquete, códigos de área, rangode extensión por voz, email, etc, identificación de equipos orientados a datos, etc.

7.5 Gestión de seguridad

La gestión de seguridad está relacionada con la generación, distribución y almacenamiento de clavesde cifrado, información de passwords (contraseñas) o bien información de control de acceso yautorización que debe mantenerse y distribuirse. Es decir, proporciona facilidades para incorporarmecanismos de seguridad contra los ataques a las comunicaciones, como protección contrainterrupción del servicio, captura no autorizada de información, modificación de información osuplantación de entidad.


8 Funciones de gestión de la red de señalización 97

8 Funciones de gestión de la red de señalización

Las funciones de gestión utilizadas en el SS7 se refieren a procedimientos de control de disponibilidadque permiten reconfigurar la red para desviar el tráfico y así poder subsanar mejor los inconvenientesde fallos en nodos y/o enlaces. Además existen los controles de congestión específicos que permitenevitar en lo posible los bloqueos de la red y las posibles pérdidas de información correspondientes.Dado que los enlaces de señalización se diseñan para que el tráfico que soporten sea menor que lacapacidad del enlace (40%), las situaciones de congestión se producen generalmente debido a caídasde enlaces o nodos [RUS1].

8.1 Controles de flujo MTP en la red de señalización

Las funciones de control de flujo MTP pertenecen al nivel 3. Las funciones atribuidas al nivel 3pueden dividirse en dos grandes grupos: funciones de manipulación de mensajes de señalización yfunciones de gestión de red de señalización, descritas en la recomendación Q.701.

Las funciones de manipulación de mensajes de señalización conciernen al encaminamiento, ladiscriminación y la distribución de mensajes de acuerdo con el estatus actual de los nodos y enlaces dela red, estén disponibles, no disponibles o congestionados. En los siguientes apartados se hará enfasisen las funciones de gestión de red de señalización, que se usan para reencaminar tráfico a otrosenlaces cuando los nodos son inalcanzables, y que pueden dividirse en gestión de enlaces deseñalización, gestión de tráfico de señalización y gestión de rutas de señalización (recs. Q.701,Q.704).

Los controles de flujo MTP se diferencian en que pueden seguir las recomendacionesinternacionales o bien dos opciones dentro de las recomendaciones de ámbito nacional. En la redinternacional, las prioridades de congestión de mensajes no se asignan dentro del MTP y cualquierdecisión para descartar mensajes se toma únicamente a nivel de UP (el descarte podría ser en elnivel MTP sólo en caso de falta de memoria física). En la opción nacional con múltiples niveles decongestión y prioridades de congestión, el MTP reconoce múltiples prioridades de congestión ybasa sus decisiones de descarte en esas prioridades, de forma separada, además de cualquierdescarte que pudiera haber en el nivel UP. En la opción nacional con múltiples niveles decongestión, pero sin prioridades de congestión, el descarte sólo ocurre en el nivel UP, como en elcaso de control internacional.


Gestión de red98

8.1.1 Gestión del enlace de señalización

Las funciones de gestión de los enlaces de señalización son controlar localmente los enlaces deseñalización, es decir, activando y desactivando enlaces, y proporcionar la información de estatussobre la disponibilidad de enlaces locales a la función de gestión de tráfico según la recomendaciónQ.704. Tiene funciones de soporte de información y no interviene directamente en el control decongestión.

Los procedimientos de gestión de enlaces requieren del uso de funciones del nivel 2 Message TransferPart (MTP) o SAAL para informar de fallos y del estatus de los enlaces a un punto de señalizaciónadyacente. Se definen tres funciones para la gestión de enlaces:

- activación de enlace- restauración de enlace- desactivación de enlace

Cuando se activa un enlace por primera vez, el nivel 3 direcciona al nivel 2 para empezar elprocedimiento de alineamiento y emplazar el enlace en servicio. Antes que puedan enviarse realmentelos mensajes, el gestor del enlace también envía mensajes de test sobre el enlace para asegurar laintegridad de éste. Una vez se ha activado el enlace y es considerado en servicio, se envía un mensajeSLTM (Signaling Link Test Message) que es contestado con un SLTA (Signaling Link TestAcknowledgment). En caso de fallo del enlace, que se determina e informa por parte del nivel 2, seprocede a la restauración del enlace. La desactivación se realiza cuando se encuentra al enlace en errory requiere ser emplazado para un alineamiento. Para ello, previamente se desvía el tráfico a otrosenlaces y posteriormente se desconecta.

8.1.2 Gestión del tráfico de señalización

La gestión de tráfico de señalización realiza el desvío y el control de flujo de tráfico en respuesta afallos de nodo/enlace y a congestión (Q.704). En el caso de no disponibilidad de enlace/ruta orestricción de ruta, las decisiones de encaminamiento se basan en la información de estatus recibidadesde las funciones de gestión de rutas/enlaces de señalización. El objetivo es mantener laconectividad a todos los destinos requeridos.

Los mensajes de gestión de tráfico no se propagan a través de la red de señalización SS7, sino que lohacen punto a punto por la red troncal. La gestión de tráfico proporciona los mecanismos paragestionar el desvío del tráfico debidos a:

- no disponibilidad del enlace de señalización- disponibilidad del enlace de señalización- no disponibilidad de la ruta de señalización- disponibilidad de la ruta de señalización- restricción de la ruta de señalización- disponibilidad del punto de señalización.

Tipos de mensajes involucrados:

- Changeover: desvía el tráfico fuera del enlace caído.



- Changeback: se utiliza cuando un enlace caído es restaurado.- Emergency changeover: cuando se inicia un procedimiento de changeover pero el buffer detransmisión no puede leerse.- Forced rerouting: se inicia cuando una ruta a un destino específico no está disponible.- Controlled rerouting: procedimiento para restaurar el tráfico hacia la ruta más favorable, caso de quehaya sido previamente restringida.- MTP restart: restablecimiento de un punto de señalización después de un aislamiento previo del restode la red.- Management inhibiting: usado por la gestión del enlace para bloquear un enlace de señalizacióndesde el nivel 4.- Flow Control: en el nivel 3, se utiliza para controlar el flujo de los mensajes UP desde la fuente.

Por ejemplo, el cambio de enlace (Link Changeover) es una función de gestión del tráfico deseñalización consistente en el desvío de tráfico, en el caso de caída de enlace o de nodo, a uno o variosenlaces. Se describe en la recomendación Q.704. Existe el procedimiento análogo para recuperar lasituación inicial de la red (Changeback), descrito en la misma recomendación.

8.2 Control de flujo de tráfico de señalización

Se trata de un control de flujo integrado en el nivel MTP para regular el exceso de tráfico de controlMTP. Cuando se detecta congestión, se advierte a los usuarios para que regulen la carga deseñalización en los puntos de origen del tráfico. La razón de este control es que los enlaces deseñalización de 64 Kbps podrían ver excedida su capacidad por un exceso de tráfico. El objetivoconsiste en proteger las colas del nivel 2 y por tanto los enlaces de señalización. Los controles MTPoperan principalmente a nivel 3 MTP.

Los procedimientos describen como los puntos de conmutación (SP) responden a la indicación decongestión de un conjunto de rutas (Transfer Controlled Message, TFC). Los UP en las fuentes SPson informados de los destinos afectados por medio de las primitivas de indicación de congestiónMTP-ESTATUS enviadas desde el nivel 3 MTP de la función de gestión de tráfico de señalización atodos los UP conectados. Los UP toman la decisión de reducir el tráfico de señalización hacia eldestino 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 puedenseguir las recomendaciones internacionales o bien dos opciones dentro de las recomendaciones deámbito nacional (recs. Q.704); esto es:- controles internacionales- opción nacional con prioridades de congestión- opción nacional sin prioridades de congestión.

8.2.1 Gestión de rutas de señalización

El objetivo de la gestión de rutas de señalización es asegurar que los SP estén informados en cadamomento de la disponibilidad de rutas en la red. La gestión de rutas no pertenece a un enlace enconcreto (como la gestión de tráfico) sino que afecta por entero a un punto de señalización. Ladisponibilidad o no de las rutas, las restricciones de tráfico, etc, se comunican a la fuente SP de la ruta


Gestión de red100

de señalización por medio de procedimientos y mensajes explícitos como: TFP, TFA, o TFR. En casode congestión, se usa el mensaje TFC.

Procedimiento TFC

En el enlace congestionado, la función de gestión de rutas de señalización usa el procedimiento TFCpara informar a los nodos fuente acerca del estatus de congestión de las rutas de señalización y losenlaces afectados, a fin que éstos puedan reducir el tráfico hacia los enlaces de acuerdo con losmecanismos de control de flujo de tráfico. El mensaje TFC informa del estatus de congestión de laruta a los nodos fuente.

Los procedimientos para la determinación de congestión, o estado de descarte en los enlaces de la red,y cómo estos estados son usados por la función de gestión de rutas, son descritos en Q. 704.Igualmente puede diferenciarse, tal como se ha descrito anteriormente, en que pueden seguir lasrecomendaciones internacionales o bien dos opciones dentro de las recomendaciones de ámbitonacional, esto es:

- controles internacionales- opción nacional con prioridades de congestión- opción nacional sin prioridades de congestión.

En la red internacional, las prioridades de congestión de mensajes no se asignan dentro del MTP ycualquier decisión para descartar mensajes se toma únicamente a nivel de UP (el descarte podría seren el nivel MTP sólo en caso de falta de memoria física). En la opción nacional, con múltiples niveleso estados de congestión (S<=3) y prioridades de congestión (N<=3), el MTP reconoce múltiplesprioridades de congestión y basa sus decisiones de descarte en esas prioridades, de forma separada,además de cualquier descarte que pudiera haber en el nivel UP. En la opción nacional con múltiplesniveles de congestión, pero sin prioridades de congestión, el descarte sólo ocurre en el nivel UP, comoen el caso de control internacional.

El uso de direcciones de cluster en la red permite utilizar mensajes de cluster de gestión de rutas. Laventaja de la gestión de rutas de cluster es que un sólo mensaje puede enviarse para direccionar a ungrupo entero de puntos de señalización, más que a puntos de señalización individuales.

Para la gestión de rutas normal pueden utilizarse los siguientes mensajes:- Transfer-prohibited (TFP)- Transfer-allowed (TFA)- Transfer-restricted (TFR)- Transfer-controlled (TFC)- Signaling-route-set-test (RST)- Signaling-route-set-congestion-test (RCT)

Para la gestión de rutas de cluster existen los siguientes mensajes:- Transfer-cluster-prohibited (TCP)- Transfer-cluster-allowed (TCA)- Transfer-cluster-restricted (TCR)- Cluster-route-set-test (CRST)



Dentro de los controles de disponibilidad de red, las recomendaciones de la serie X.700 definendiversos procedimientos para reconfigurar la red en caso de fallo: entre ellos están los de transferenciaprohibida y transferencia restringida.

Transferencia prohibida (Transfer Prohibited, TFP)El procedimiento de transferencia prohibida se utiliza hacia nodos adyacentes para desvío de tráficodesde nodos funcionalmente no disponibles. Para dar a conocer la información de prohibición, seenvían mensajes TFP a los nodos adyacentes. El procedimiento actúa tanto para nodos como pararutas no disponibles. Una vez desviado el tráfico hacia otras rutas, si se recupera el enlace o la ruta,puede restaurarse la red hacia la situación original si se reenruta el tráfico a su ruta original medianteun procedimiento de transferencia disponible (TransFer Available, TFA). El procedimiento sedescribe en la recomendación Q.704.

Transferencia restringida (TransFer Restricted, TFR)El procedimiento de transferencia restringida se utiliza hacia uno o más nodos adyacentes para eldesvío de tráfico hacia rutas alternativas (si es posible) en respuesta a una situación de congestión detráfico. La función de gestión de rutas locales utiliza el mensaje TFR para llevar la indicación a losnodos adyacentes. A la llegada del mensaje, los nodos responden con con un reencaminamientocontrolado del tráfico hacia una ruta no congestionada. Una vez se ha descongestionado la rutaoriginal, se emplea un procedimiento TFA con el envío de los mensajes correspondientes a los nodosadyacentes para recuperar la ruta original. El procedimiento se describe en la recomendación Q.704.

8.3 Control nodal MTP

Este control sirve para proteger a la red de congestión nodal (en SPs o STPs), posiblemente a raíz deprocesados internos en el nodo o de comunicaciones entre procesadores. Las causas pueden ser porlimitaciones de capacidad en los enlaces o por fallos en nodos de la red que pueden dar a lugar acuellos de botella y congestiones en el tráfico. El control nodal puede realizarse a varios niveles delprotocolo de señalización.

Control nodal de nivel 2 MTP

El control nodal a nivel 2 de MTP se basa en la recomendación Q.703. Los controles de flujo a nivel 2se basan en un control on/off realizado en respuesta a congestión nodal en SPs o STPs.

Control de flujoEl mecanismo de control de flujo a nivel 2 se activa cuando se detecta congestión en el extremo finaldel enlace de señalización. La notificación sobre la detección de congestión se obtiene mediante elenvío periódico de LSSUs (Link Estatus Signal Units) con la indicación (“B”) de ocupado al extremodel enlace. En el extremo, se prueba la duración de la congestión; si persiste, se deja el enlace fuera deservicio y se notifica al nivel 3 de gestión de red de lo sucedido.

Bloqueo de procesadorLa recomendación Q.703 cubre además de los mecanismos de control de flujo los bloqueos deprocesador. Éstos se producen cuando las funciones del nivel 2 no pueden transferirse al nivel 3, o elnivel 3 no puede acceder al nivel 4, etc. En este caso se envía un flujo continuo de LSSUs con laindicación de estatus PO (Processor Outage) desde el extremo cercano, donde ocurre el bloqueo, alextremo lejano. Por otra parte, las MSUs recibidas por el extremo cercano se desechan. El extremo


Gestión de red102

lejano pasa de enviar MSUs a enviar FISUs. En el momento en que se restablece el procesador, elextremo cercano pasa a enviar MSUs y el extremo lejano pasa a reestablecer la comunicación.

Control nodal de nivel 3 MTP

La congestión nodal implica que es el propio nodo quien provoca un cuello de botella en latransmisión. El caso de congestión nodal SP o STP se trata en las recomendaciones Q.700 y Q.704,siendo la detección dependiente de la implementación. Se aplican los mismos mecanismos que para lacongestión de rutas de señalización.

UP no disponibleEn el caso de que un UP remoto sea designado como no disponible (inalcanzable), se para el tráficohacia este UP desde la fuente UP (Q.704). El UP inalcanzable (estado UPU) se señaliza a la fuente SPmediante un mensaje UPU retornado desde donde se ha detectado este estado. El MTP en la fuente SPpasa la información UPU al UP afectado vía la primitiva MTP-ESTATUS, identificando el destinoafectado (Q.701) y UP. Se espera que la fuente UP pare o reduzca la generación de mensajes hacia elUP de forma apropiada. La recuperación del UP remoto podría tratarse también desde el punto devista de gestión de fallos y alarmas. Por el momento (recs. 1992), se deja a criterio del UP examinar ladisponibilidad.

UP en congestiónEn las recomendaciones Q.704 de 1992 se afirma que el MTP no mantiene información de estatusacerca de la disponibilidad de UP’s remotos.

Controles UP de nivel 4

Pueden considerarse los controles de flujo y los bloqueos en UP.

Controles de flujo UPLos controles de flujo UP han de responder a la detección de congestión en el protocolo MTP,regulando el tráfico enviado a los destinos congestionados. Tanto el TUP (Q.724) como el ISUP(Q.764) tienen recomendaciones similares para el tratamiento del control de flujo en UP, por lo que seconsideran de forma conjunta.

Cuando el MTP en la fuente SP recibe una indicación de congestión, pasa esa información al UP víala primitiva de MTP-ESTATUS (Q.701), que identifica el destino afectado y el estatus de lacongestión si se utilizan múltiples niveles de congestión (p.e. opción nacional). Entonces, el UPreduce el tráfico al destino afectado de forma progresiva.

Las bases para el descartado por parte de los controles UP es un tema de implementación sujeto amúltiples variantes de diseño. Los controles UP podrían actuar independientemente de cualquiercontrol en MTP, si bien en determinados casos (p.e. una opcion nacional) podría haber redundancias omalfuncionamiento.

Bloqueo UPEl bloqueo en TUP se describe en la recomendación Q.724. Los UPs en nodos adyacentes soninformados por el control de flujo del usuario y responden parando o reduciendo el tamaño delcircuito hacia el nodo afectado.



8.3.1 Controles SCCP

El protocolo SCCP se describe en las recomendaciones Q.711 hasta la Q.716. El SCCP, junto al MTP,proporcionan las funcionalidades del nivel 3 de la red. De las cuatro clases de servicio definidas 0 a 3,sólo la clase 3 proporciona control de flujo, vía un mecanismo de ventana usando créditos. Cuando elSCCP recibe una indicación de congestión desde el MTP vía una primitiva MTP-ESTATUS, hace unbroadcast de esa información localmente a los subsistemas SCCP concernientes (Q.714). Lasrecomendaciones no especifican qué es lo que realizan los subsistemas como respuesta, por lo que sedeja este mecanismo para libre implementación por parte del fabricante.

8.3.2 Controles de congestión automáticos

Los controles de congestión automáticos (Automatic Congestion Control, ACC) se usan cuando unaaplicación de procesamiento de conmutación de llamadas es sobrecargada (Q.724 en TUP, Q.764 enISUP y Q.542). Definen el uso que hace la red de señalización en respuesta a la congestión detectadaen la aplicación de procesado de la llamada.

En el caso de TUP se pueden utilizar un par de niveles de congestión para advertir a los nodosadyacentes y así reducir la tasa de llamadas dirigida al nodo congestionado. Si se utiliza el protocoloISUP, se añade un parámetro a los mensajes generados por el nodo de conmutación. Este parámetroindica el nivel de congestión (1 ó 2) y a su recepción los nodos adyacentes reducen el tráfico hacia elnodo afectado. ISUP también define un mensaje de sobrecarga específico en la rec. Q.763 como unaopción nacional. En Q.764, el protocolo ISUP define una opción nacional para reducir el tráfico encaso de un bloqueo de troncales temporal (TTB) en lo que parece ser una función de protección deservicio.

8.4 Gestión de fallos

La secuencia de procedimientos que ocurren desde que se detecta un fallo en un enlace, de unconjunto de dos enlaces conectados a un punto de señalización, es la siguiente:

Detección desde el punto de señalización de la caída de uno de sus enlaces. Inicio del Link StatusSignal Unit LSSU por el nivel 3 de la capa de gestión. La gestión de la capa de nivel 3 instruye a la denivel 2 enviando un LSSU con el estatus de procesador bloqueado (Processor Outage) al enlace deseñalización. Cuando se recibe el mensaje, mantiene todas las MSUs (Message Signal Units) paraprevenir la transmisión sobre el enlace caído.

La gestión del enlace a nivel 3 pasa ahora al proceso de recuperación del enlace. Pone el enlace fuerade servicio, que inicia cambiando el código del enlace y comenzando el procedimiento deChangeover. Se desvía el tráfico. El procedimiento de Changeover es invocado por la gestión detráfico del nivel 3. Todos los mensajes no reconocidos en el buffer de transmisión del enlace al puntode señalización se transfieren a un nuevo enlace. Cuando se ha completado este procedimiento, seenvía el mensaje de Changeover al punto de señalización proporcionando el código de señalización(SLC). Cuando se recibe por el punto de señalización el mensaje, éste transfiere las MSUs que estántodavía en el buffer de transmisión del enlace fallido al nuevo enlace. Entonces, se retransmiten lasMSUs sobre el nuevo enlace en ambas direcciones.


Gestión de red104

Para reconocer la finalización de la transferencia del buffer y la recepción del mensaje de Changeover,el punto de señalización envía el mensaje de Acknowledgement Changeover al otro punto deseñalización. Esto significa que ahora puede desviarse el tráfico. Una vez que los mensajes han sidoretransmitidos y los buffers han sido retransmitidos, el procedimiento de recuperación de gestión delenlace puede empezar. Se empieza enviando el mensaje de LSSU de alineamiento normal sobre elenlace fallido y empezando el procedimiento de alineamiento. Todos los timers y contadores sonpuestos a cero.

Durante el desvío del tráfico, el problema del corte del procesador se ha trasladado al nuevo enlace, deforma que ambos enlaces son inaccesibles al punto de señalización. La gestión del tráfico debe ahoradesviar el tráfico fuera de los enlaces caídos y buscar enlaces alternativos.

8.5 Arquitectura de gestión de red de señalización

Las recomendaciones descritas se basan en la congestión de la red de señalización y en sus controles,dejando aparte los controles de la parte de aplicación de procesamiento de la llamada. Es decir, laparte UP se describe como red de señalización. Está aún poco desarrollada la relación entre la UP y laparte de aplicación de procesamiento de la llamada (AP). Sólo se han empezado a utilizar técnicascomo el tema UPU. Cada fabricante resuelve de forma libre la relación o interfaz entre UP yconmutación de llamada (AP) en caso de congestión o fallo.

El conjunto de los mecanismos de gestión propuestos permite garantizar únicamente un buencomportamiento de la red en entornos locales. En el caso de que se produzcan fallos en diversas parteso nodos de la red, la restauración del sistema puede ser compleja o incluso llegar a ser imposible. Losmecanismos de gestión propuestos tampoco permiten la descongestión en el caso de producirse buclessin fin en la red. Por esto es recomendable el uso de una red de gestión (TMN) específica, que podríabasarse en el protocolo CMIP o bien en técnicas de desarrollo más reciente como es CORBA.


9. Gestión de redes virtuales 105

9 Gestión de redes virtuales

El uso cada vez más frecuente de elementos de red que actúan a niveles superiores está permitiendoun auge de la gestión basada en la configuración de redes virtuales para obtener mejores rendimientossobre el tráfico circulante entre los nodos.

9.1 Introducción

Una VLAN puede entenderse como un grupo de terminales de usuario, quizás en múltiples segmentosde LAN físicos, que no están restringidos por su localización física y que pueden comunicarse como siestuvieran en una LAN en común. Una VLAN conforma un único dominio de broadcast, lo quepermite que cada miembro de esa VLAN reciba paquetes procedentes de otros miembros de esaVLAN y no paquetes de grupos del exterior. No se requiere routing dentro de una VLAN y todos loscambios, movimientos, adiciones, etc. se realizan mediante software.

9.2 Estándares de VLAN

Aparte de las múltiples soluciones propietarias implementadas, existen dos estándares propuestos porel IEEE para redes VLAN. Estos son el IEEE 902.10 y el IEEE 802.1Q. Otros estándares han sidopropuestos para emular LANs bajo ATM, como los del ATM Forum. Otros provienen del IETF,comenzando por el Spanning Tree, IEEE 802.1D que es un estándar para el control de puentes,conmutadores y el estándar IEEE 802.1p que añade importantes funcionalidades de filtrado en VLAN.

9.3 Gestión de red en VLAN

El despliegue de redes conmutadas/VLANs requiere de nuevas perspectivas para la introducción deuna gestión de red adecuada. Existen un par de estándares de gestión de red ampliamente utilizadospara VLANs: son el protocolo SNMP y el RMON. Ámbos se consideran complementarios y permitenque la escalabilidad y flexibilidad de funcionamiento que presentan las VLAN pueda resolverseadecuadamente mediante las arquitecturas jerárquicamente distribuidas que utilizan los entornosSNMP/RMON.

En entornos basados en LANs, RMON ayuda a los gestores de red a determinar cómo segmentarmejor sus redes y hacer un seguimiento de quién está comunicando con cualquier otro. A partir de la


Gestión de red106

emisión de eventos especiales, un gestor de red puede identificar los usuarios que utilizan más anchode banda. Estos usuarios pueden entonces ubicarse en sus propios segmentos de red para minimizar elimpacto 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 tratade estándares de comunicación abiertos y de tener que proporcionar seguridad distribuida.

Los estándares de seguridad se basan en los protocolos ISAKMP y Oakley que son competidores paraestablecer una gestión de claves en Internet y que son considerados por el grupo de trabajo Ipsec (IPSecurity) del IETF. Otra solución de seguridad distribuida fue presentada por Livingston Enterprises yse denomina Remote Authentication Dial-in User Service (RADIUS). Radius soluciona los problemasasociados con encontrar los requerimientos de seguridad de computación remota. La seguridaddistribuida separa la autentificación de usuario y la autorización del proceso de comunicaciones y creauna única posición central para datos de autentificación de usuario.


10. Gestión de la red B-RDSI 107

10 Gestión de la red B-RDSI

En este capítulo se procede a dar una visión general de este tipo de redes describiendo los modelos degestión establecidos en la red digital de servicios integrados de banda ancha [MIN1, SCH1].

El modelo establecido de RDSI-BA se basa en la conmutación distribuida a alta velocidad, sin utilizarun control de errores en la red. Se trata de una red de gran flexibilidad, tanto en los anchos de bandadisponibles como en las calidades de servicio ofrecidas. Todo ello repercute en una mayorcomplejidad, tanto en el diseño, como en el software que se debe utilizar, como en la gestión de la red.A pesar de todo es una red de gran eficiencia con capacidad de direccionamiento de llamadas y/oconexiones a uno o varios destinos fijos o móviles.

ATM (Asynchronous Transfer Mode) es la clave de la versatilidad de la red: se basa en el envío de unflujo continuo de celdas, tanto en la interfaz usuario-red (UNI) y en los enlaces, como en los nodos deconmutación y/o multiplexación. ATM permite además emplear una única interfaz para diferentestipos de usuarios con diferentes necesidades de servicio.

ATM es un método de comunicación orientado a conexión sin control de flujo ni recuperación deerrores, que permite agrupar canales virtuales para configurar un camino virtual. A continuación sedescriben las capas que conforman la B-RDSI.

La capa física (ITU-T I.432) es la encargada del correcto transporte de celdas ATM y de la adaptaciónal sistema de transmisión (ATM, SDH, G.703). Se descompone en dos subcapas con las siguientesfunciones asignadas: una subcapa de convergencia de transmisión (TC), que permite la daptación de latasa de celdas a la capacidad del sistema de transmisión, generación y verificación del HEC,delimitación de celdas ATM, adaptación a la trama de transmisión (ATM, SDH, G.703) ygeneración/recuperación de tramas de transmisión. Existe una segunda subcapa de medio físico (PM),que trata aspectos relativos a la correcta transmisión y recepción de los bits sobre el apropiado mediofísico, y se ocupa de la conversión electro-óptica si el medio es fibra óptica.

La capa ATM se encarga de la conmutación y multiplexación de celdas. Es una capa independientedel medio físico, común para todos los servicios y métodos de transmisión. Tiene las siguientesfunciones: controla flujo en UNI (User Network Interface) si se usa el GFC, extrae/añade cabeceraspara/desde AAL, también se encarga de cambiar los VCI y/o VPI en conmutadores y cross-connects yfinalmente multiplexa/demultiplexa celdas de distintas conexiones (VCIs/VPIs).

La capa de adaptación se ocupa de adaptar información de cada clase de servicio al flujo de celdasATM. Se descompone en las dos subcapas siguientes: una subcapa de convergencia (CS), todavía


Gestión de red108

dependiente del servicio con las clases A, B, C y D, y una subcapa de segmentación (SAR), quesegmenta 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 (I-211).

En la figura 10.1 se especifican los campos de información que conforman la estructura de una celdaATM.

Leyenda:GFC: asigna prioridades a teleservicios según la QOS.VPI/VCI: identifican conexión. Asociados a la función de encaminamiento.PTI: identificación de la carga útil.RES: no especificado.CLP: indicación de prioridad de pérdida de celdas (0/1 baja prioridad).HEC: detección y corrección de errores en cabecera.

Fig. 10.1 Estructura de celda ATM (5 + 48 bytes)

Fig. 10.2 Estructura de niveles en la red B-RDSI

GFC/VPI VPI

VP VC

VC

VC PTI RES CLP

HEC (Chequeo errores cabecera)

Tipos de celdas

Plano de control Plano de usuario

Protocolos y funcionesde capas superiores

Protocolos y funcionesde capas superiores

Capas de adaptación ATM

Capa ATM

Capa física

Plano de gestión

HL

CSSAR

TCPM

Gestióndecapas

Gestióndeplano



Fig. 10.3 Tipos de servicios en la red B-RDSI

Las clases de servicio definidas son las siguientes: vídeo de baja calidad con codificación CBR(comprimido a 2 Mbps); vídeo estándar CBR (34 Mbps) o VBR (2 a 10 Mbps); vídeo extendido VBR(10 a 34 Mbps); y, finalmente, vídeo de alta calidad: VBR (70 a 140 Mbps) y CBR (comprimido a 20Mbps).

En cuanto a las capas de adaptación, existen diferentes combinaciones de protocolos CS y SAR quedan lugar a infinidad de protocolos AAL. La ITU-T ha normalizado 4 protocolos: AAL 1 orientado alservicio A; AAL 2 orientado al servicio B; AAL ¾ orientado a servicios C, D y señalización; y,finalmente, AAL 5 con servicios C y D (más simple y eficiente que el anterior).

Fig. 10.4 Interfaces definidas en B-RDSI

La arquitectura definida en la B-RDSI contiene diversss interfaces siguiendo la misma filosofía que laRDSI de banda estrecha. Existe una interfaz en el punto de referencia R que permite tener conectadosequipos sin disponer capacidades de red de banda ancha.

UNI

B-ET1 TR2 TR1

B-TAET2óB-ET2

TR2 TR1R

SB TB UB

SB TB UB

Audio yvideoVBR

Datos X.25y señalización

A B C D CRITERIO

Relacióntemporalentre fuentey destino

Tasa de bits

Modo deconexión

Requerida(Circuitos)

No requerida(paquetes)

Constante(CBR)

Variable(VBR)

Orientada a la conexión Sinconexión

Voz 64 KbpsVideo CBR

LAN

Gestión de red110

Las interfaces en SB y TB deberan soportar todos los servicios RDSI. Las funciones en TR1 (capafísica) son de terminación de línea, de aspectos de transmisión hasta dependencias de usuario y deOA&M. Respecto a las funciones asignadas al TR2 (capa física y superiores), existen las demultiplexación/concentración de tráfico, delimitación de celdas, almacenamiento de celdas ATM,CAC/UPC, manejo de protocolos de conmutación, conmutación de conexiones internas y, finalmente,funciones de O&AM.

Respecto a las funciones de transporte de la capa ATM, se puede hablar de canal virtual (VC) y decamino virtual (VP). Es importante definir los siguientes conceptos de cara a su uso posterior: enlacede canal virtual (VCL)/enlace de camino virtual (VPL) son medios de transporte unidireccional entreun punto donde se asigna un VCI/VPI y un punto donde es conmutado (puntos de conmutación); unVCI identifica una conexión (canal virtual) incluida en un VP sobre el UNI o el NNI; un circuitovirtual (VCC) es una concatenación de VCLs entre extremos de la conexión donde se genera yprocesa la cabecera de las celdas de esa conexión; un trayecto virtual (VPC) es una concatenación deVPLs entre terminadores de VPLs (VPTs) donde se conmutan los VCLs (cambian los VCIs).

10.1 Introducción a la gestión de la red B-RDSI

Los niveles de calidad de servicio exigidos en una red de banda ancha (B-RDSI) hacen necesaria laintroducción de determinados mecanismos de gestión de red (NMC) que, de forma distribuida,interactúen con los distintos elementos de red tales como los conmutadores ATM.

Los sistemas de gestión actuales convencionales, basados preferentemente en plataformas tipo SNMP,no proporcionan las capacidades necesarias para poder controlar una red basada en ATM. Por logeneral, se requiere controlar tráfico muy sensible al retardo, jitter, o bien la infraestructura deconmutación extremo a extremo de forma muy rápida.

Para este fin, el ATM Forum creó un modelo de gestión ATM de cinco capas y unas funciones OAM(Operations, Administration and Maintenance) que distribuyen la información de gestión por la redATM. Este modelo de gestión extremo a extremo permite la interacción tanto de redes públicas comode redes privadas. El modelo también definirá las pasarelas entre los protocolos SNMP y CMIP(Common Management Information Protocol), así como entre otros sistemas propietarios.

A pesar de todo, este modelo de gestión tardará años en poder completarse. De momento, el ATMForum ha definido el ILMI (Interim Management Interface) que se incluye en la recomendación UNI(User-Network Interface). El ILMI utiliza una conexión virtual ATM preestablecida con UNI paracomunicarse conmutador a conmutador y con una aplicación de gestión vía mensajes SNMP. Sinembargo, el ILMI se limita a gestionar interfaces entre redes y no distribuye inteligencia de gestión através de la red.

En la figura 10.5 se ha detallado un escenario de red de banda ancha. Se observa que los NMC seconectan a los elementos de la red ATM a través de la interfaz Q3 normalizada por la UIT y por elETSI. Asimismo, se definen cinco interfaces de gestión (desde M1 a M5) que permiten monitorizar ycontrolar extremo a extremo los diferentes elementos de la red. En el caso de gestión más normal, deconmutadores ATM, interesarán, particularmente, las interfaces M1 y M2.

Otro organismo, el IETF (Internet Engineering Task Force) define especificaciones para las interfacesM1 y M2, basadas en el protocolo SNMP. Éstas incluyen la definición de bases de datos (tipo MIBs)



en DS-1, DS-2 y otras conexiones para SDH. Actualmente está desarrollando de forma experimentaluna base de datos para redes ATM (AToM MIB, RFC 1695). En este caso, sin embargo, la gestión noes extremo a extremo.

El ATM Forum tardará aún tiempo para la especificación del interfuncionamiento entre diversos tiposde protocolos como SNMP y CMIP y/o otros protocolos propietarios para el resto de interfaces. Apesar de ello, ya se está elaborando una base de datos MIB para la interfaz M4, que es independientedel tipo de protocolo utilizado en su acceso.

En los próximos años se completarán los protocolos de gestión de la red ATM, pero no tanto desde elpunto de vista de SNMP o CMIP sino de definición de las celdas OAM. Será necesaria unaarquitectura distribuida inteligente que gestione la red, de forma que pueda reconfigurarsedinámicamente en caso de fallos en enlaces, o negociar el ancho de banda para determinadosservicios, configurar según niveles de congestión, etc.

El forum está ahora en proceso de especificar diversos tipos de celdas OAM de 53 bytes confunciones específicas, tales como gestión de fallos, gestión de prestaciones, de tráfico y funciones deactivación/desactivación para los casos anteriores. Estas celdas permitirán realizar gestión de lasconexiones extremo a extremo así como reducir el número de bases de datos (MIB) y las cargas deseñalización en la red.

A continuación, se muestran como ejemplo algunas de las funciones de gestión de red de banda anchamás representativas. Es el caso de crear un abonado CBDS (servicio de datos de banda ancha sinconexión) donde el NMC asocia el número de abonado E.164 y el identificador de acceso físico.Entonces, el NMC de banda ancha:

- debe encontrar la ruta en la red a usar en la conexión,- asignar los recursos necesarios (p.e. ancho de banda) en cada enlace ATM,- crear las transconexiones ATM en cada elemento de red ATM,- crear el abonado en el servidor sin conexión.


Gestión de red112

Agente

Centro de gestión dered privada de BA

Agente

UME

Sistema degestión dela red portadorapública

Agente

Usuariopúblico

UMEUME

AgenteAgente

Red ATM privada Red ATM pública

Red privadalocal

Usuario

Usuario

Usuario

UNI ATMprivado

UNI ATMpúblico

ILMI(SNMP/AAL)

ILMI(SNMP/AAL)

RDSI BA

RDSI BE

M4M2 (Q3)M1(Q3)

M3 (SNMP, CMIP,...)Agente

Centro de gestión dered público de BA

Agente

UME

M4(Q3)

M5 (SNMP, CMIP,...)

UNI ATMpúblico

ILMI(SNMP/AAL)

Usuario

Usuario

Conmutador ATM

Conmutador ATM

UME

Agente

Red ATM pública

UNI ATMpúblico

ILMI(SNMP/AAL)

M4

M4

RDSI BA

Usuariopúblico

Fig. 10.5 Esquema de interfaces de gestión de red B-RDSI

Si existe algún problema como los relativos a caídas de enlace. El NMC debería:- detectar dicho enlace ATM,- encontrar todas las conexiones que estaba usando este enlace,- buscar una ruta alternativa en la red para cada conexión afectada,- asignar los recursos necesarios (p.e. ancho de banda) en cada enlace ATM,- crear las transconexiones ATM en cada elemento de red ATM.

10.2 Interfaces en la red de gestión de banda ancha.

La UIT-T (o ITU-T) define una serie de interfaces X, F, Q3, QX para la gestión de la arquitecturafísica en la red de gestión de telecomunicaciones (TMN). De entre ellas, la más importante es lainterfaz Q3. Todos los modelos de objetos específicos en Q3 se basan en información de gestióngenérica definida en las series de recomendaciones X.700 y M.3100 de UIT-T. Las áreas funcionalescubiertas por esta interfaz (Q3) están relacionadas con la gestión de abonados, gestión de tráfico ygestión de recursos del sistema.

10.2.1 Interfaces definidas por el ATM Forum

De manera simultánea, el ATM Forum define cinco interfaces de gestión denominadas de M1 a M5,que permiten monitorizar y controlar las conexiones extremo a extremo en redes ATM.



- Interfaz M1 (Q3)Define la interfaz entre el sistema de gestión de una red privada y la estación final ATM.- Interfaz M2 (Q3)Define la interfaz entre el sistema de gestión de una red privada y una red corporativa ATM.- Interfaz M3 (X)Define la interfaz entre la gestión de una red privada y el sistema de gestión de la red pública.- Interfaz M4 (Q3)Define la interfaz entre la plataforma del sistema de gestión de red y la red pública ATM.- Interfaz M5 (X)Define la interfaz entre plataformas de sistemas de gestión de redes públicas distintas.

10.3 ATM Forum

El ATM Forum es una organización internacional sin ánimo de lucro que trata de acelerar lacooperación industrial en tecnología ATM. Sus recomendaciones y especificaciones son seguidas porlos principales fabricantes de equipos ATM y constituyen un estándar de facto en esta tecnología. Lasespecificaciones propuestas por este ATM Forum se complementan en gran medida con lasrecomendaciones generadas por la UIT.

Para la gestión de la interfaz de usuario con la red, el ATM Forum define un protocolo denominadoInterim Local Management Interface (ILMI).

10.3.1 ILMI

El Interim Local Management Interface (ILMI) utiliza una conexión virtual ATM en el User NetworkInterface (UNI) para comunicar con una aplicación de gestión usando mensajes SNMP.

Cada conmutador ATM, o sistema final, y cada red ATM que desarrolle una red privada o públicaUNI debe tener una entidad de gestión UNI (UME) que soporte la MIB ILMI. La UME reside entre elconmutador y la red o entre una red privada y una red pública. Es la responsable de mantener datos degestión y responder a comandos SNMP recibidos sobre el UNI ATM a través del ILMI.

De igual forma que en una aplicación basada en SNMP, estos mensajes se envían a la red vía unprotocolo de paquetes datagrama de usuario TCP/IP. Estos paquetes se segmentan en unidades dedatos de protocolo ATM, que se incorporan en celdas ATM usando capas de adaptación AAL 3/4 oAAL 5.

Los tipos de información de gestión que están disponibles en la MIB ATM UNI son los siguientes:

- Physical Layer- ATM Layer- ATM Layer Statistics- Virtual Path (VP) Connections- Virtual Channel (VC) Connections- Address Registration Information


Gestión de red114

10.3.2 Celdas OAM

Los sistemas de gestión de redes ATM en un futuro van a utilizar celdas OAM para su gestión. Elfórum está en proceso de definir una serie de celdas OAM (de 53 bytes) con funciones específicastales como: gestión de fallos, gestión de prestaciones, de activación y desactivación (rec. UNI 3.1), yotras nuevas como, por ejemplo, para la gestión de tráfico: (Resource Management) RM (rec. UNI4.0).

Tipo de celda OAM (UNI) Tipo de función OAM

Gestión de fallos AISFERFBucle de celda OAMComprobación de continuidad

Gestión de prestaciones Monitorización directaEnvío de informes en sentido contrarioMonitorización/Reporting

Activación/desactivación Monitorización de prestacionesComprobación de continuidad

Gestión de tráfico Celdas de gestión de recursos (RM)

10.4 IETF en ATM

El grupo IETF especifica una MIB para definir y desarrollar los objetos de gestión necesarios usandoel protocolo SNMP estándar para gestionar dispositivos ATM.

10.4.1 AToM: RFC 1695

Este documento especifica un estándar para la comunidad Internet que permite su uso para gestión deredes ATM. Se define la MIB, y en particular sus objetos, para gestionar con interfaces basadas enATM, dispositivos, redes y servicios.

La MIB está limitada a un único extremo ATM del sistema o centro conmutador. Está basada enincorporaciones de la Sonet MIB, DS-1/E1 MIB, DS-3/E3 MIB y la ILMI MIB.

Existen diferencias entre los objetos gestionados definidos por ATM Forum y IETF sobre informaciónde gestión ATM. En general, la IETF MIB puede incluir la MIB II y la base de datos específica deATM, ATM MIB.

10.5 Tendencias y análisis comparativo entre estándares de gestión ATM

Actualmente las funciones de gestión que están disponibles en los equipos ATM que presentan losdistintos fabricantes distan mucho de las que debieran utilizarse para un funcionamiento óptimo en



prestaciones. Los equipos más avanzados basan su gestión en estándares del ATM Forum mediante elILMI a nivel de usuario y mediante el empleo de celdas OAM para la red de transporte.

Dado que el ATM Forum no ha definido todavía completamente las funcionalidades de gestión,existen diversas opciones según cada fabricante:

a) Uso de sistemas de gestión propietarios: pueden llegar a tener más funcionalidades que losestándares de facto abiertos definidos, como por ejemplo por ATM Forum; sin embargo, no soncompatibles con otros equipos lo que condiciona la evolución futura del sistema. Raramente sonmejores desde un punto de vista de prestaciones, rapidez de respuesta, etc.

b) Uso de sistemas basados en ATM Forum: son abiertos y avanzados en prestaciones; sin embargo,pueden adolecer de escasas facilidades de gestión si no están debidamente actualizados. Puedenofrecer funciones propietarias complementarias de gestión si es necesario y si se tiene un buen soportetécnico.

c) Uso de otros sistemas abiertos, CMIP/CORBA: actualmente no hay solución disponiblecomercialmente en redes ATM si bien están empezando a consolidarse recomendaciones para su usoen redes TMN (ITU). Se trata de sistemas complejos, con gestión distribuida y que formarán parte delos sistemas de gestión en un futuro próximo.

d) Uso de otros sistemas abiertos tales como SNMP, SNMPv2 (IETF): si bien presentan en general unbuen grado de compatibilidad con otros sistemas abiertos, tienen el inconveniente de que no sonadecuados para la gestión en redes ATM.

10.6 Control de tráfico en redes ATM

La gestión de tráfico permite a la red ofrecer una calidad de servicio en cada conexión individual,activar nuevas conexiones de acuerdo con una optimización de los recursos existentes en la red yprotegerse contra la congestión.

La calidad de servicio se obtiene a partir de una serie de procedimientos: por una parte el contratosuscrito entre el usuario y la red durante el establecimiento de la conexión, el control de policía quegarantiza el cumplimiento del contrato (UPC), también la disponibilidad de recursos para incorporaruna nueva conexión (CAC) y finalmente un comportamiento justo y equitativo de la red.

10.6.1 Calidad de servicio

La calidad de servicio se define como un conjunto de parámetros objetivos, y por tanto medibles, quecaracterizan el grado de servicio que ofrece la red al usuario del servicio. Estos parámetros han de sermedibles.

En la recomendación UNI 4.0 (Interficie usuario-red) del ATM Forum, la calidad de servicio se definepor seis parámetros: cuatro de ellos hacen referencia a la transparencia semántica (la información queentra en la red es igual a la que sale) y los dos restantes se refieren a la transparencia temporal (retardode las celdas).


Gestión de red116

- Parámetros relativos a la transparencia semántica

a) Tasa de error de celda (Cell Error Rate, CER)CER = (Celdas erróneas)/(Celdas transmitidas)

b) Tasa de celdas perdidas (Cell Loss Rate, CLR)CLR = (Celdas perdidas)/(Celdas transmitidas)

c) Tasa de celdas mal insertadas (Cell Misinsertion Rate, CMR)CMR = (Celdas mal insertadas)/(Intérvalo temporal)

d) Tasa de bloques con errores severos (Severely errored Cell Block Rate, SECBR)SECBR = (Bloques de celdas con errores severos)/(Número de bloques de celdas transmitidos).

- Parámetros relativos a la transparencia temporal

a) Retardo máximo de transferencia de celda (Maximun Cell Transfer Delay, maxCTD)Retardo máximo extremo a extremo en ausencia de tráfico.

b) Variación “pico a pico” del retardo de celda (Peak to Peak CDV)El CDV es la varianza del retardo de celda.

Otro de los aspectos importantes de la calidad de servicio que puede solicitarse o asignarse por unaconexión es la prioridad de pérdida de celdas. Un usuario puede pedir dos niveles de prioridad depérdida de celdas para una conexión ATM. La prioridad de una celda individual es indicada por elusuario mediante el bit CLP en la cabecera de la celda. Cuando se utilizan los dos niveles de prioridad,se han de especificar los parámetros de tráfico para los dos flujos de celdas. Normalmente, esto sehace especificando un conjunto de parámetros de tráfico por tráfico de alta prioridad (CLP = 0) y unconjunto de parámetros de tráfico para todo el tráfico (CLP = 0 o 1). Basándose en esta división, la redpuede asignar los recursos más eficientemente.

10.6.2 Parámetros de tráfico

Los parámetros de tráfico, junto a la calidad de servicio, se utilizan para definir una conexión ATM.Los parámetros de tráfico definen la forma que una fuente puede introducir tráfico en la red a travésde una conexión virtual. Se definen a continuación:

a) Tamaño máximo de ráfaga (Maximum Burst Size, MBS)Especifica el tamaño de la ráfaga de celdas que puede introducirse en la red. Tiene dimensiones deceldas.b) Tasa de pico de celda (Peak Cell Rate, PCR)Especifica la tasa máxima de introducción de celdas en la red. PCR = 1/T donde T es la distanciamínima entre celdas.c) Tasa sostenida de celda (Sustainable Cell Rate, SCR)Especifica la tasa promedio de introducción de celdas en la red. Para ser útil a la red, SCR ha de sermenor que PCR. SCT = 1/Ts, donde Ts es la distancia media entre celdas.d) Tasa mínima de celda (Minimum Cell Rate, MCR)Especifica la tasa mínima de introducción de celdas en la red.



10.6.3 Descriptores de tráfico

Los descriptores de tráfico de una conexión describen las características de una conexión mediante:

a) Un conjunto de parámetros de tráfico de la fuente.b) Una definición de conformidad.c) La tolerancia a la variación del retardo de la celda (Cell Delay Variation Tolerance, CDVT).

A continuación se describe la relación entre las categorías de tráfico definidas en ATM respecto de losparámetros de calidad de servicio descritos.

CBR VBR-RT VBR-NRT ABR UBR UBR+PCR SI SI SI SI NO NOSCR NO SI SI NO NO NOMCR NO NO NO SI NO SIMBS NO SI SI NO NO NOMCTD SI SI SI SI NO NOCDVT SI SI NO NO NO NOCLR SI SI SI SI NO NO

Tabla. 10.1 Parámetros de QoS aplicables a cada categoría de servicio ATM

10.6.4 Mecanismos de control de tráfico

El control de tráfico son el conjunto de acciones que adopta la red para evitar las condiciones decongestión. La gestión de tráfico en ATM se describe en las recomendaciones I.371 y en el ATMForum Traffic Management 4.0.

10.6.4.1 Control de admisión de conexiones, (Connection Admission Control, CAC)

El control de admisión de conexiones actúa cuando un usuario pide una nueva conexión y tiene queespecificar (explícitamente o implícitamente) las características de la conexión en los dos sentidos. Elusuario escoge las características del tráfico seleccionando una calidad de servicio entre las categoríasde servicio que proporciona la red.

10.6.4.2 Control de parámetros de usuario/red (Usage/Network Parameter Control, U/NPC)

Una vez se ha aceptado una conexión por le CAC, la función de control de utilización de parámetros(UPC) de la red monitoriza la conexión para determinar si el tráfico cumple el contrato de tráfico. Elpropósito principal del UPC es proteger los recursos de la red de la sobrecarga por parte de unaconexión que podría afectar negativamente la calidad de servicio en otras conexiones, detectando lasviolaciones de los parámetros asignados y adoptando las medidas apropiadas.

La localización del UPC suele realizarse a nivel de camino virtual (VPC). Los algoritmos utilizadosson variados, como el Generic Cell Rate Algorithm (GCRA) definido en la Rec. I.371 y UNI. Otrosalgoritmos son el Virtual Scheduling (VS) y continuous-state Leaky Bucket (LB) algorithm.


Gestión de red118

Otras funciones de control adicionales son el control de prioridad, ya comentado, el alisado de tráfico,los mecanismos de gestión de recursos de red, o bien los controles de realimentación.

10.7 Funciones de control de congestión

Se denomina congestión a la circunstancia en la que el rendimiento de la red (o una parte de ella) sedegrada debido a la presencia de demasiados paquetes. La congestión es un problema global, que seda en el nivel de red como consecuencia del tráfico agregado de varias fuentes sobre un enlace orouter de baja capacidad. A diferencia de la congestión, el control de flujo es una circunstancia quesólo puede darse en conexiones punto a punto (es decir, a nivel de enlace o a nivel de transporte).

Algunos de los parámetros que permiten detectar la presencia de congestión pueden ser los siguientes:

- porcentaje de paquetes descartados- longitud media de las colas en las interfaces de los routers.- número de paquetes que dan timeout y se retransmiten (no debidos a errores)- retardo medio por paquete- desviación media del retardo por paquete.

El tráfico a ráfagas es la principal causa de congestión; por eso el control de congestión sueleutilizarse sólo en caso de tráfico tipo ABR.

Entre los mecanismos de control de congestión existentes está el alisado de tráfico (traffic shaping)que permite establecer unos márgenes máximos al tráfico de ráfagas. El de vigilancia de tráfico ofunción policia (traffic policing) realiza una labor de monitorización o seguimiento del tráficointroducido por el usuario en la red para verificar que no excede el perfil pactado. El leacky bucketpermite al host enviar ráfagas, que son almacenadas en un buffer o cola de la interfaz, para serenviadas a la red posteriormente a un flujo constante.

Para llamadas de datos ABR, la fuente crea una conexión con un call setup request. Durante lallamada, se define el valor para un conjunto de parámetros ABR. La tasa a la que la fuente ABR puedetransmitir las celdas está reflejada en el ACR (Allowed Cell Rate). El ACR está inicializado al ICR(Initial Cell Rate) y siempre está entre un mínimo MCR (minimum Cell Rate) y un PCR (Peak CellRate). La transmisión de las celdas de datos está precedida por la transmsisión de celdas RMRresource Management Cell). La fuente continuará enviando celdas RM después de un cierto númerode celdas de usuario, y más frecuentemente cuando el ACR es bajo. La tasa de fuente viene controladapor el retorno de las celdas RM, que son devueltas por el destino o un destino virtual.

La fuente sitúa la tasa permitida (ACR) en el campo CCR (Current Cell Rate) de la celda RM, y latasa a la cual desearía transmitir las celdas (usualmente el PCR) en el campo ER (Explicit Rate). Lacelda RM viaja a través de la red, dando a los conmutadores la información que contiene sobre lasconexiones ABR. Los conmutadores también tienen que decidir a la vez cómo reducir el valor delcampo ER, o si poner el bit CI (Congestion Indication) a 1. Los conmutadores que sólo soportan elmecanismo basado en el bit EFCI (Explicit Forward Congestion Notification) ignorarán el contenidode la celda RM. Los conmutadores pueden generar opcionalmente un número controlado de celdasRM en el camino hacia atrás además de los generados por la fuente. Las celdas RM generadas por losconmutadores deben tener el bit BN (Backward Notification) a 1 y cada uno de los bits CI o NI (NoIncrease) a 1.



Cuando la celda llega al destino éste debe cambiar el bit de dirección en la celda RM y devolverla a lafuente. Si el destino está congestionado y no puede soportar la tasa especificada en el campo ER, eldestino debe reducir ER a la tasa que puede soportar. Si al devolver la celda RM al destino haobservado el bit EFCI activado desde que fue devuelta la última celda RM, entonces debe activar elbit CI de las celdas RM para indicar congestión.

Mientras que las celdas RM viajan a través de la red, cada conmutador debe examinar la celda ydeterminar si puede soportar la tasa ER para su conexión. Si ER es demasiado elevado, el conmutadordeberá reducir la tasa a la que pueda soportar. Los conmutadores no deben aumentar el ER ya que lainformación de los anteriores conmutadores donde ha pasado la celda RM se perdería.

Los conmutadores deben intentar modificar el ER sólo en las conexiones cuello de botella ya que estoofrece una justa asignación del ancho de banda. Los conmutadores también deben modificar elcontenido de ER cuando van hacia delante o hacia atrás, pero no en ambos.

Cuando la celda RM llega a la fuente, ésta debe reinicializar la tasa, ACR, basada en la informaciónque llevaba la celda RM. Si el indicador de congestión no estaba activado (CI = 0), entonces la fuentedebe incrementar su ACR en un incremento fijo determinado en el establecimiento de la llamada haciael valor devuelto de ER, pero nunca excediendo el PCR. Si el indicador de congestión está activado(CI = 1) entonces la fuente debe disminuir su ACR en una proporción igual o más grande que unaporción de su actual ACR. El tamaño también estará determinado en el establecimiento de la llamada.Si el ACR sigue siendo mayor que el valor devuelto de ER, la fuente debe disminuir su ACR al valorER, aunque nunca por debajo del MCR. Un bit NI = 1 indica a la fuente que debe observar los camposCI y ER de la celda RM, pero no incrementar el ACR por encima de su valor actual.

Otra vía para notificar la congestión los conmutadores ATM es poner a 1 el bit medio del campo PTI(Payload Type) de la cabecera en las celdas de datos que envían al causante de los problemas.

10.7.1 Control de flujo

El ATM Forum ha adoptado el esquema basado en tasa como estándar para control de flujo. A partirde los requerimientos de espacio se pueden dividir los agoritmos de control de flujo en dos tipos:

- algoritmo de control de flujo de espacio constante (número de variables utilizadas en el algoritmoconstante e independiente del número de sesiones que cruzan el puerto).

- algoritmo de espacio ilimitado (el espacio depende, normalmente de forma lineal, del número deconexiones).

Los algoritmos de control de flujo de espacio constante son importantes en las redes actuales, ya quesi alguien quiere tener tanto tráfico en ATM como tráfico TCP, la dependencia del número de sesionesno puede existir.

ATM Forum propone tres algoritmos para el control de flujo de espacio constante (EnhancedProportional Rate Control Algorithm, EPRCA y Adaptive Proportional Rate Control with intelligentcongestion indication APRC, Congestion Avoidance using Proportional Control, CAPC y ExplicitCongestion Indication for Congestion Avoidance, ERICA/ERICA+). Los tres algoritmos calculan para


Gestión de red120

cada puerto de salida de cada conmutador un parámetro para delimitar la cantidad de sesiones delpuerto.

10.8 Recuperación en redes ATM

En este apartado se detallan los cambios realizados en el diseño de redes ATM para que adopten unalto grado de transparencia al usuario frente a roturas de cables.

Protección de redesTrata de los principios básicos de asignación de recursos dedicados para protección y la distinciónentre protección 1+1 y 1:1. Concepto de agrupación de caminos virtuales que comparten la mismaruta física para reducir el el procesado de encabezamiento durante la protección de la conmutación.

Redes reconfigurablesCoordinación en la restauración de redes usando un control centralizado. Sólo existen solucionespropietarias.

Redes autorecuperablesSe describen tres técnicas que se basan en la asignación simultánea de rutas y capacidades. Otraopción consiste en permitir una plataforma tecnológica diferente situada usualmente en un nivel másbajo al de la jerarquía de transporte para asumir la responsabilidad de la continuidad de servicio en elcaso de fallos.

10.8.1 Mecanismos de recuperación ATM alternativos

Mecanismos que se basan en la recomendación ATM Network survivability architectures andmechanisms. Q.F/13. Nov. 1996. (*)

ProtecciónSe ocupa de la asignación de una ruta alternativa con asignación de ancho de banda dedicado. En elcaso de un evento inesperado, un protocolo de gestión distribuido permite realizar la conmutación.

RestauraciónPodría realizarse bajo los auspicios de un control centralizado (red reconfigurable) o un protocolo decontrol distribuido con procedimientos de gestión de redes autorecuperables. En ambos casos, losrecursos podrían ser semidedicados donde la ruta alternativa sea predeterminada, pero el ancho debanda asignado sea “por demanda” siguiendo la detección de fallos. También, en ambos casos, la rutay el ancho de banda podrían asignarse en tiempo real (“por demanda”).



Recursos ControlDedicados Semidedi-

cadosPor demanda Central Control

distribuidoGestióndistribuida

Protecciónde redes

X X

Redesreconfigu-rables

X X X

Redesautorecu-perables

X X X X

Tabla 10.2 Arquitecturas de recuperación ATM

Un rasgo distintivo lo constituye el hecho de que se requiere menor capacidad sobrante en métodos derestauración que en los de protección.

El control distribuido se aplica sobre procedimientos de establecimiento de conexiones con celdas deseñalización del plano de control, mientras que la gestión distribuida hace uso de mensajes en el planode gestión en forma de celdas OAM.

10.8.2 Redes de protección ATM

Las redes de protección son las que disponen de los niveles de fiabilidad más elevados; sin embargo,suelen ser las más caras, dado que recursos como el ancho de banda y los caminos/canales virtuales(VPI/VCI) son dedicados más que compartidos. Por otra parte, la preasignación de rutas y recursospermite que los protocolos de gestión distribuida sean muy simples de usar en el caso de un fallo en lared.

La protección de conexiones de red (NCP) puede aplicarse extremo a extremo o bien a un segmento(Sub-Network Connection Protection, SNCP). Para propósitos de control, los segmentos protegidos ylos no protegidos se alinearian con flujos apropiados de operaciones y mantenimiento (OAM).

El protocolo de conmutación de protección VP/VC se ha especificado para arquitecturas de protección“punto a punto” dentro de dominios NCP y SNCP (*). El protocolo podría ejecutarse de acuerdo con1+1 o en 1:n.

El uso de Virtual Path Groups (VPG) agrupa caminos virtuales formando segmentos o conexionesextremo a extremo, reduciendo la señalización en el caso de sistemas de múltiples conexiones.

10.8.3 Redes reconfigurables

Las redes reconfigurables permiten la restauración de conexiones mediante sistemas de gestión de redcentralizados (NMS). Podrían explotar rutas alternativas, preplanificadas, o mantenerlas dinámica-mente de acuerdo con la información de estado de la red actual. Además resulta una tarea simple elpriorizar el reencaminamiento de conexiones a fin de asegurar que aquellas con aplicaciones críticas


Gestión de red122

sean restauradas con mayor rapidez que los servicios que son tolerantes de pérdida de datostemporales. Sin embargo, existen tres causas de ralentización de la respuesta del sistema:

- comunicaciones ascendentes entre los nodos de la red desde nodos adyacentes al del fallo y el NMS- procesado del NMS requerido para encaminamiento y asignación del ancho de banda- comunicación descendente entre el NMS y los nodos de la red, seguidos por la reconfiguración delos elementos de red apropiados.

La restauración centralizada (generalmente propietaria) suele ser lenta e inapropiada en BISDN. Sinembargo, la gestión de fallos suele ser problemática entre equipos de diferentes fabricantes.

10.8.4 Redes ATM autorecuperables

Este tipo de redes explota la gestión distribuida o la funcionalidad de señalización del plano decontrol, e incorpora asignación de recursos “por demanda“ o bien semidedicada. Se describen acontinuación tres médodos de redes autorecuperables por demanda.

Autorecuperación con encaminamiento PNNIEl ATM Forum ha definido el protocolo (Private Network Node Interface, PNNI) para establecercircuitos virtuales conmutados (VCs) entre conmutadores ATM que utilizan un punto de acceso deservicio de red (NSAP) tipo direcciones ATM. Desde que el ATM Forum ha especificado unacodificación NSAP para direcciones E.164, el protocolo de encaminamiento PNNI puede tambiénemplearse en redes públicas.

La especificación PNNI describe cómo los nodos de la red mantienen el conocimiento acerca de laalcanzabilidad y los recursos dentro de la red gracias a un protocolo de encaminamiento según losestados topológicos en un entorno de intercambio de información periódico entre nodos.

Autorecuperación con soft PVCs/PVPsEn este caso, cuando ocurre un fallo, la conexión se corta hasta los extremos de los conmutadoresATM, seguidos de instigación automática de reencaminamiento, aunque no hay garantías de éxito. Espropio de General DataComm (APEX).

Algoritmos de restauración distribuida (DRAs)Es una descripción genérica aplicada a protocolos que dinámicamente restauran la capacidad detransporte que ha caído, y originada en redes SONET/SDH. La idea de DRAs es encaminar tráficorápidamente (< de 2 seg.) usando conmutadores digitales de alta granularidad, de manera queconexiones vocales o sesiones de transferencia de datos de usuario no se desconecten. Es decir, existeuna clara distinción entre protocolos de transporte que operan en caminos, y señalización de controlusada en circuitos individuales.

10.8.5 Autorecuperación con backup de VPs semidedicados

Las rutas de backup que son disjuntas de las rutas de trabajo son preasignadas. Sin embargo, lacapacidad sobrante podría compartirse para restauración desde el tipo más común de fallos, comosingle spans. La principal ventaja de esta aproximación es que la capacidad sobrante puede sercompartida entre otros VPs de backup, reduciendo los costes.



10.8.6 Restauración multicapa

El principal problema de la restauración a bajo nivel es que aunque la capa SDH podría utilizarse paraser usada para reconfigurarse desde roturas de cable y fallos en equipos SDH, no sería efectiva pararesolver fallos a nivel de ATM. Se plantea pues una restauración multicapa.

Mecanismo derecuperación

Aplicaciones Retardo Coste Viabilidad técnica

Proteccióndedicada

Misión crítica endatos. Telemedicina

Objetivo es 60ms

Alto (reserva decapacidad másVPI/VCIs)

La conmutaciónrápida se basa enVPG

Semi dedicada Misión casi crítica.Interruptible

< de 10 seg. Medio (capacidadcompartida másVPI/VCIs)

Se basa en VPG yasignación decapacidad

Autoredial Residencial. Misiónno crítica en datos

De 10 segs aminutos.

Bajo (sólocapacidad)

Basada enseñalizaciónestándar.

Centralizada(con NMS)

Residencial. Misiónno crítica en datos

Variosminutos

Relacionado consofisticación deNMS

Viable, perolimitado a sistemaspropietarios.

Tabla 10.3 Tabla mecanismos de recuperación en B-RDSI


11. Gestión de redes de comunicaciones móviles 125

11 Gestión en redes de comunicaciones móviles

La gestión de redes de comunicaciones móviles se beneficia de la alta sofisticación de los terminalesmóviles y de las altas prestaciones en general de todos los elementos de sus redes. Esto permiteintegrar una red de gestión de telecomunicaciones (TMN) e inteligencia de red en sus arquitecturas decomunicaciones de forma relativamente sencilla a pesar de la complejidad de todos los procesossubyacentes en los sistemas [VO1, GA1, RS2].

11.1 Introducción a las comunicaciones personales

La progresiva integración de elementos computadores en las infraestructuras de redes decomunicaciones convencionales ha permitido dar un salto adelante a éstas, proporcionando al usuarioun conjunto de nuevos servicios. Estas arquitecturas emergentes que proporcionan una capacidad decálculo y ofrecen por consiguiente nuevos servicios reciben el nombre de redes inteligentes. En elcaso de las comunicaciones móviles, estos nuevos servicios se ofrecen como facilidades ycomúnmente se conocen como comunicaciones personales. En este capítulo se da una primera visiónde 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 puntode acceso a la red o el punto de conexión del terminal a la red (Fig. 11.1). En las redes decomunicaciones móviles, los terminales no disponen de punto fijo de conexión y se comunicandinámicamente a través de canales de radio. La infraestructura celular permite la movilidad de losterminales, que establecen y reciben llamadas siempre que se encuentren en una zona de coberturaadecuada. En este caso, la asociación entre el terminal y el usuario todavía se mantiene. En el entornoUPT (Universal Personal Telecommunication), la movilidad da un paso adelante: la asociación fijaentre el usuario y el terminal, tanto en redes fijas como móviles, se rompe, el usuario únicamente seidentifica con la red mediante un número personal conocido por el número UPT. Esto se conoce comomovilidad personal. En este caso se permite al usuario aparecer en cualquier punto de acceso a la redy utilizar los servicios de telecomunicación a los que está abonado.

La evolución de este tipo de sistemas empezó en 1989, cuando en el Reino Unido se permitió eldesarrollo de una red de comunicaciones personales PCN (Personal Communication Network), basadaen estándares de ETSI GSM (Fig. 11.2). Esta nueva recomendación DCS1800 aprobada en 1991 paraEuropa era un sistema celular digital a 1800 MHz que incorporaba una serie de servicios de telefoníapersonal. En América del Norte se introdujo un sistema equivalente, más orientado a la provisión deservicios personales, denominado PCS (Personal Communication Services) que permitía el acceso porradioenlace, la movilidad del terminal y la movilidad personal.


Gestión de red126

En paralelo a la iniciativa británica, el ETSI decidió auspiciar el estándar UPT (Universal PersonalTelecommunication) en Europa. La finalidad que se perseguía con este nuevo estándar era desarrollarinicialmente los conceptos de movilidad personal y número personal de abonado. Éstos rompieron laasociación fija que había entre terminal y usuario, al permitir un alto grado de movilidad en redes fijasy móviles. También existieron iniciativas dentro del programa RACE II (1992) con el proyectoMobilise (R2003) que definía el concepto de PSCS (Personal Services Communication Space) comouna extensión de UPT. El PSCS estaba basado en el modelo conceptual de red inteligente (ITU-T,Q.1200) con extensiones obtenidas del Open Distributed Processing (ODP).

Posteriormente, en Estados Unidos se aprobaron las bandas de 1900 MHz (PCS1900) para el soportede redes móviles con servicios PCS (Personal Communication Services). En la actualidad, en Europael término PCN (Personal Communications Network) ha sido desplazado por UPT y la contraposiciónentre el sistema europeo y el americano se plantea en términos de UPT/PCS (UPT está también siendonormalizado por el ITU). En el caso de PCS, además de la funcionalidad recogida en UPT, se añadenotras de carácter físico de la red.

La evolución de estos sistemas PCS/UPT junto con su interconexión/integración con redespreexistentes es un paso intermedio hacia el concepto de sistemas de la tercera generación. La tercerageneración (UMTS/FPLMTS) surge a partir de servicios soportados por sistemas celularesincorporando diferentes estándares como sistemas telefónicos inalámbricos (p.e. DECT), incluidas suinterconexión con GSM y la ayuda de sistemas de satélites con cobertura mundial.

Identificaciónde línea

Identificaciónde terminal

Identificaciónde usuario

Redes fijas

Redes móviles

Redes fijas ymóviles

Relaciónfija

Relacióndinámica

Dinámica

Fija

Relaciónfija

Relaciónfija

Dinámica

SINMOVILIDAD

MOVILIDADDE TERMINAL

MOVILIDADPERSONAL

Fig. 11.1 La movilidad personal permite a los usuarios el libre movimiento entre terminales, tanto en redes fijascomo móviles, para establecer y/o recibir llamadas



Fig. 11.2 Esquema descriptivo de la evolución de los sistemas de comunicaciones móviles (europeo a la izquierday americano a la derecha) desde sus orígenes hasta nuestros días

11.1.1 Comparación entre la gestión en sistemas cableados y sistemas de comunicación móviles

A partir de las características de los sistemas de comunicaciones fijas descritos en capítulos anterioresse pueden estudiar los aspectos de gestión que se plantean en los nuevos sistemas de comunicacionesmóviles. Áreas funcionales como las de configuración o fallos resultan muy afectadas en estos nuevossistemas.

En la tabla 11.1 puede observarse una estimación de la evolución en la gestión que pueden seguir lossistemas de comunicaciones móviles frente a otras arquitecturas de comunicaciones fijas.

CT -1

Tecnología FM

IMTS

Tecnología analógica

AMPS

N-AMPS

Tecnología digital

TDMA

E-TDMA

CDMA

Tecnología analógica

CT-1+

TCAS, NMT, C450

Tecnología digital

CT-2

CT-3/DCT-900

GSM

DCS1800


Gestión de red128

Tema Cableado Móvil Area Funcional

Red de acceso -Bucle dedicado/usuario- Estático- Calidad bucle estable

- Canales escasos y porcontienda- Dinámico- Calidad inestable

FallosPrestaciones

Distribución deequipos

Muy centralizado Muy distribuido Configuración, fallos

Interconexiones Pocas jurisdicciones Mas jurisdicciones Contabilidad, fallos

Proveedor de servicioslocal

Fijo Depende de la posiciónen el seguimiento

ContabilidadConfiguración

Autentificaciónterminal

Ninguna Hecha para cadallamada

Configuración

Tarificación - Uso independiente delservicio local- Sin cargos parallamadas entrantes

-Distanciaindependiente delservicio local- Cargos para llamadasentrantes

Contabilidad

Diseño de red deacceso

Planif. bucle estático Herramientas deingeniería de RF

Planificación

Establecimiento delterminal inicial

Ninguno Registro del terminal PlanificaciónConfiguración

Tabla 11.1 Tabla comparativa entre la gestión en redes fijas y redes de comunicaciones móviles

11.1.2 Arquitectura de la red GSM

La arquitectura del sistema GSM consta de tres grandes subsistemas interconectados que interactúanentre ellos mismos y con los usuarios, a través de ciertas interfaces de red. Los subsistemas son elBase Station Subsystem (BSS), el Network and Switching Subsystems (NSS) y el Operation SupportSubsystem (OSS).

La estación móvil (Mobile Station, MS) se considera integrada en el subsistema BSS. La BSS,también conocida como subsistema radio proporciona y gestiona trayectos de transmisión de radioentre estaciones móviles y centros de conmutación móvil (Mobile Switching Centers, MSC). La BSStambién gestiona la interfaz de radio entre las estaciones móviles y los demás subsistemas de GSM.Cada BSS consiste de muchos controladores de estaciones base (Base Station Controllers, BSCs) queconectan las MS a la NSS vía los MSCs. Los NSS gestionan las funciones de conmutación del sistemay permiten a las MSCs comunicar con otras redes tales como la PSTN y RDSI. El OSS soporta laoperación y el mantenimiento de GSM y permite a los ingenieros de mantenimiento, monitorizar,diagnosticar y arreglar todas las alertas del sistema GSM. El OSS soporta unos o varios centros demantenimiento de operaciones (Operation Maintenance Centers, OMC). En el NSS hay tres diferentesbases de datos denominadas Home Location Register (HLR), Visitor Location Register (VLR) yAuthentication Center (AUC). El AUC contiene el registro de identidades de equipos (EquipmenteIdentity Register, EIR) que identifica terminales robados o que hacen un uso fraudulento del sistema.



Red SS7

TMNNMCX.25 Network

VLR

VLR

MSCMS BTS BSC

HLR

AUC

Subsistema de radio BSS

Radioenlace

A

MAP

MAP

CC MM RR LAPDm L1

LAPDm L1

BTSM LAPD

RR BTSM LAPD

BSSMAP SCCP MTP

BSSMAP CC, MM

SCCP MTP

MAP TCAP SCCP MTP

MAP TCAP SCCP MTP

EIR

ADC OMC

Subsistema de red NSS

Subsistema de gestión de red

Fig. 11.3 Arquitectura de la red GSM y sus protocolos de señalización

La gestión de red en GSM se basa en la constitución de una red de gestión del sistema (TMN) y siguelas pautas de diseño vistas en el correspondiente capítulo 6.

OS

OSF

Q3

Q3

MF

NE-BSC NE-BTS

NEFNEF Qx

NE-MSC/VLR

NEF

mscfunction vlrfunction

bssfunction

Fig. 11.4 Ejemplo de TMN en la arquitectura GSM


Gestión de red130

MF: función de mediaciónNEF: funciones de elementos de redOS: sistema de operacionesOSF: funciones del sistema de operaciones

Las recomendaciones de la ETSI que definen la arquitectura de gestión de red del sistema GSM son la serie12 de GSM. Esta serie define más de 100 clases de objetos gestionados con casi 500 atributos [TO1].

11.2 Arquitectura de las redes PCS

11.2.1 Características de los sistemas basados en PCS

Los sistemas PCS pueden distinguirse de otros sistemas basados en redes más convencionales por unaserie de características relacionadas con la inteligencia del sistema. Por una parte, permiten a los usuariosoperar en múltiples entornos y también preven la posibilidad de operar una conexión por persona adulta,lo que supone la infraestructura de un sistema de alta capacidad; por otra parte, PCS tiene queproporcionar acceso a determinados servicios personalizados, independientemente de la localización delusuario. Para poder alcanzar este objetivo, PCS debe integrar las redes actuales con las futuras, seancableadas o con acceso mediante radioenlace y al mismo tiempo, soportar un seguimiento de lascomunicaciones de forma global. Como consecuencia de la interconexión de multiples operadores en unentorno abierto, se requerirá la provisión de los adecuados servicios de seguridad al sistema.

En los sistemas PCS está previsto el empleo de servicios multimedia de alta calidad; de esta forma, sepretenden proporcionar determinados servicios multimedia ofrecidos en redes cableadas como RDSI,en entornos de comunicaciones móviles, proporcionando la misma calidad. Esta provisión de nuevosservicios admitirá múltiples tipos de usuario y se ofrecerán de forma personalizada, es decir, conrequerimientos y características distintas para cada uno de ellos.

El sistema admitirá un único número PTN (Personal Telecommunication Number). Este númeroconstituye la base de la movilidad personal. El usuario puede ser localizado en cualquier parte eindependientemente de los dispositivos que esté utilizando a través de este número. De esta forma,con un único y pequeño terminal se puede tener acceso a todos los servicios disponibles del sistema.

Las funciones que realiza una red PCS pueden clasificarse en los siguientes cuatro grupos: funcionesde gestión de recursos radio, funciones de gestión de movilidad, funciones de gestión de llamada yfunciones de gestión de datos (datos referidos a información interna de la red).

Las funciones de gestión de recursos radio están relacionadas con la parte del radioenlace de una redPCS, y gestionan los recursos radio (frecuencia, slots temporales, código, etc.) asignación,monitorización de las características del canal e información sobre la transmisión de la señal.

Las funciones de gestión de movilidad se realizan en las capas de transporte y de inteligencia de lared. Estas funciones son claves para proporcionar un seguimiento global y alta calidad de servicio.La gestión de movilidad consiste en el registro de localización, renovación de localización,búsqueda y traspaso del móvil.

Las funciones de gestión de llamada incluyen el establecimiento de llamada, la terminación, lamonitorización y el encaminamiento de llamadas, la autentificación, el cifrado, el descifrado y las



funciones de supervisión. Por último, la gestión de datos corresponde a la lista de funciones que seencargan de almacenar, obtener, renovar y mantener varias formas de información asociada con el usode recursos de la red, perfiles de servicio, tarificación, etc. De estas cuatro funciones, la gestión derecursos y las funciones de gestión de movilidad son las exclusivas de sistemas basados en PCS y lasque permiten un seguimiento global de los usuarios, proporcionándoles servicios de calidad.

Teniendo en cuenta estos cuatro grupos de funciones de red definidos, la red puede subdividirse entres niveles lógicos: el nivel de acceso, que proporciona el método de acceso, el nivel de transporte,que se encarga de realizar las funciones de conmutación y de transmitir la información de usuario y dela señalización, y el nivel inteligente, que realiza gestión de red y control de servicio.

Tomando como referencia esta arquitectura lógica formada por tres niveles, se han propuesto diversasarquitecturas de red. La arquitectura que actualmente se está desarrollando en Europa está basada enlos estándares GSM/DCS1800, con el soporte de la interfaz UPT. El sistema celular digital DCS1800es un estándar desarrollado por el ETSI que está basado en el GSM900 y que se diferencia de éste entres elementos fundamentales: la frecuencia de operación (1710-1785, 1805-1880 MHz con 375portadoras), las potencias de pico de 1000 mW y 250 mW, definiendo pequeños terminales portables,y, por último, la posibilidad de realizar un seguimiento a nivel nacional entre operadores quedispongan de solapes en sus coberturas.

Uno de los problemas actuales más importantes que se plantea en Estados Unidos es la compatibilidaddel estándar PCS1900, basado en GSM, y el estándar de señalización IS-41 para el desarrollo desistemas PCS. Existen diferencias importantes entre ellos, como por ejemplo la introducción dealgoritmos de privacidad y autentificaciones diferentes o la señalización necesaria para la interconexiónentre sistemas al invocar procedimientos de movilidad (p.e. protocolo MAP en el handover).

El comité del T1P1 desarrolla el estándar PCS en Estados Unidos y lo define como un conjunto decapacidades que permiten una combinación de movilidad de terminal, movilidad personal y gestión deperfil de servicio. Sin embargo, en otras ocasiones, este término se usa para cubrir varias formas deaccesos radio y servicios de movilidad personal. Se ha asignado para PCS un nuevo espectro con unafranja de 140 MHz en los 1900 MHz (FCC 47 CFR Part 15). A partir de ahí, se han definido 51 bandasMTA (Major Trading Areas), que corresponderían geográficamente aproximadamente a estados, y 492bandas BTA (Basic Trading Areas), que corresponderían a condados. Además de las licencias parasistemas terrestres se han asignado 20 MHz para aplicaciones sin licencia (10 MHz para tráfico asíncronocomo redes de paquetes no cableadas y otros 10 MHz para tráfico síncrono, como puede ser la voz).

Otros grupos de estandarización que desarrollan actualmente o que han trabajado en sistemas PCS sonel TR-46 que está bajo la supervisión de la TIA y es responsable de servicios y protocolos PCS; elT1S1, que está supervisado por ATIS (Alliance for Telecommunications Industry Solutions) y seresponsabiliza de protocolos de señalización; el T1M1, que está también supervisado por ATIS, y seocupa de operaciones, administración, mantenimiento y provisión (OAM&P); y, por último, un comitétécnico conjunto de T1P1 y TR-46 para proporcionar una interfaz común.

La FCC (Federal Communications Commission) es el organismo encargado de asignar licencias paraoperar en el espectro PCS según normativas del JTC (Joint Technical Committee). El JTC distingueentre dos categorías de sistemas: celular digital e inalámbrico digital. Recientemente, el JTC hapasado en su selección, de 16 posibles estándares a 7, cinco de los cuales son variaciones de losradioenlaces actuales: PACS, GSM, IS-54, IS-95 y DECT, mientras que los otros dos sonaproximaciones híbridas TDMA/CDMA y de banda ancha en CDMA (W-CDMA), según se ve en la


Gestión de red132

tabla 11.2. El IS-136 es otro estándar muy reciente, en fase de estudio, y que supone una mejorarespecto al IS-54 considerado en la tabla comparativa.

Los estándares anteriores pueden clasificarse en cuatro importantes grupos: GSM (PCS1900), CDMA(IS-95), TDMA y PACS. El sistema PCS1900 está siendo utilizado ya por pequeños operadores paraconseguir cuota de mercado rápidamente en los Estados Unidos. Se trata de una tecnología basada enel GSM y, por tanto, plenamente operativa. Respecto a otros sistemas como los basados en CDMApresenta mayores costes de mantenimiento ya que requiere más estaciones base y una más rigurosagestión de las frecuencias. Los sistemas basados en CDMA (p.e. IS-95) preven una entrada enfuncionamiento más a largo plazo. Se trata en principio de un sistema superior aunque en la prácticaestá teniendo muchas dificultades. Tiene la ventaja de que su plan de frecuencias es más simple y lacobertura es similar a los sistemas analógicos actuales, con 4 ó 5 veces la capacidad de éstos. Losoperadores, deseosos de expandir el espectro de radio existente, optan por soluciones TDMA, como elTDMA IS-54B, que es una extensión digital del estándar analógico anterior, o el TDMA IS-136, queestá siendo elegido por diversos operadores americanos importantes. Por último, el sistema PACS estáprevisto que funcione en bucles locales no cableados a bajo coste.

Híbrido(nuevo)

Basado enIS-95

PACS Basado enIS-54

Basado enDCS-1800

Basado enDECT

WCDMA

Método deacceso

CDMA/TDMA/FDMA

CDMA TDM/TDMA

TDM/TDMA

TDMA TDMA D-CDMA

Métododúplex

TDD FDD FDD FDD FDD TDD FDD

Bw 5 MHz 1.2MHz 300 KHz 30 KHz 200 KHz 1728Khz 5 MHzBit-rate(sin enc.)

32 Kbps 8/13.3 Kbps 32 Kbps 7 Kbps 13 Kbps 32 Kbps 32 Kbps

Gan. prc 21 dB 21 dB - - - - 21 dBGuardacanales

5 MHz 1.25 MHz 300 KHz 30 KHz 200 KHz 1728 KHz 5 MHz

Canalesvoz/port.

20 8 3 8 12 128

Refer. aAMPS

16 X 10 X 0.8 X 3 X 2-3 X 0.2 X 16 X

Modulac. Fase contsalto QM

OQPSK/QPSK

Pi/ 4d-QPSK

GMSK GFSK OQPSK/QPSK

Err.(voz) Ninguno FEC Ninguno FEC FEC Ninguno FECReuso fr. N=3 N=1 16x1 7x3 7x1y 3x3 9 1Pot. maxmedia

- 200 mW 12.5 mW 100 mW 125 mW 20.8mW 500 mW

Pot. slot 1 W - 100 mW 600 mW 1 W 250 mW -Lg.trama 625 ms - 312.5 ms 6.7 ms 577 ms 417 ms -Lg. Tslot 80 ms 50 ms 9 ms 110 ms 90 ms 28 ms 13.25 msRet. voz 80 ms 50 ms 9 ms 110 ms 90 ms 28 ms 13.25 msEcualiz. No No No Sí Sí No NoVocoder CELP

(8Kbps)ADPCM(16,24,32,40)

Tasa var.(8/4/2/1)

ADPCM32Kbps

VSELP(8Kbps)LDCELP16Kbps

RPE-LTP13 Kbps

ADPCM16-32Kbps

ADPCM32 Kbps

Tabla 11.2 Esquema resumen de los sistemas de radioenlace candidatos para soportar PCS



El ámbito de actuación del comité JTC incluye el desarrollo de documentos técnicos para la definiciónde estándares sobre las funcionalidades de la interfaz aire, proporcionando acceso a redes detelecomunicaciones para servicios de comunicaciones móviles y PCS. Los trabajos incluyen el estudiode las consideraciones electromagnéticas en las interfaces, y pueden incluir aspectos relacionados conla capa física de transmisión, el acceso al medio, y los protocolos de señalización. Las actividades delJTC también tienen impacto sobre las actividades desarrolladas por el grupo ITU-R TG 8/1, que esuna organización internacional que elabora recomendaciones para el futuro sistema FPLMTS.

De forma simultánea, se está desarrollando todo un nuevo conjunto de interfaces de aplicación sobrelos sistemas PCS; entre éstas se pueden considerar las comunicaciones inalámbricas residenciales ypúblicas, las PABX inalámbricas, las redes digitales celulares, las redes micro-celulares, las redescelulares analógicas, la radio móvil especializada, FPLMTS, UPT, el uso de satélites, etc. Todos estossistemas requieren de su integración en una red inteligente.

En el diseño de estos sistemas resulta fundamental la selección de una estructura idónea de la red quepermita la movilidad de los usuarios según unos adecuados criterios de prestaciones. Actualmente, enEstados Unidos se consideran dos modelos de referencia para redes PCS, el TR-46 y el T1P1, que a suvez son convertibles entre sí. En el modelo T1P1 los datos de usuario y los datos del terminal estánseparados, es decir, los usuarios pueden comunicarse con la red vía terminales personales de radiodiferentes. En el modelo de referencia TR-46, utilizado anteriormente por sistemas analógicoscelulares, sólo se soporta movilidad de terminal [12]. En Europa, los estándares presentan diversassoluciones que se basan, por ejemplo, en el carácter más o menos distribuido de sus nodos (caso delfuturo sistema UMTS frente al GSM). A continuación, se describen brevemente los modelos dereferencia PCS a los que se ha hecho referencia anteriormente.

1850 MHz 1910 MHz 1920 MHz 1930 MHz 1990 MHz

Licencias para banda ancha PCS

Licencias para banda ancha PCS

Asíncrono Síncrono

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 acontinuación: se define una estación personal (Personal Station, PS) como un dispositivo que puedeestar conectado o no a otros equipos (como ordenadores, fax,...) y que permite tener acceso a serviciosde la red a través de un radioenlace. El sistema de radio (Radio System, RS), a menudo llamadoestación base, se compone de una BTS (Base Transceiver System) y de un controlador, BSC (BaseStation Controller).

Se define un PCSC (Personal Communications Switching Center) que sirve de interfaz entre el tráficode usuarios procedente de las redes móviles con el de las redes cableadas. Se definen unas bases de


Gestión de red134

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 MessageHandler, DMH) usado para tarificación, un centro de autentificación (Authentication Center, AC), unregistro para equipos robados (Equipment Identity Register, EIR), un sistema para operaciones(Operations System, OS) para la gestión de la red y una función de interconexión para posibilitar lacomunicación entre otras redes (Interworking Function, IWF).

11.2.1.2 Modelo de referencia T1P1

La arquitectura del modelo T1P1, según se muestra en la figura 11.7 es similar a la anterior; sinembargo, existen algunas diferencias que se describen a continuación:

El terminal móvil o RPT (Radio Personal Terminal) es idéntico a la PS del modelo TR-46. El RP(Radio Port) es idéntico a la BTS del modelo TR-46. El RPI (Radio Port Intermediary) proporcionauna interfaz entre uno o más RPs y el controlador. El RPC (Radio Port Controller) es el controlador yes idéntico a la BSC del modelo TR-46. También se define un RASC (Radio Access SystemController) que realiza las funciones de control y conmutación en la parte específica de radio.

En la parte de la red fija se define el centro de conmutación PSC (PCS Switching Center) que essimilar al PCSC del modelo TR-46; el controlador de movilidad TMC (Terminal Mobility Controller),que proporciona el control lógico para el terminal; la base de datos TMD (Terminal Mobility DataStore), que mantiene los datos asociados al terminal de forma similar a la VLR; el controlador demovilidad personal PMC (Personal Mobility Controller), que proporciona el control lógico para elusuario. El PMD (Personal Mobility Data Store), que mantiene los datos de usuario asociados deforma similar al HLR del modelo TR-46. Se definen también un sistema OAM&P de manera idénticaal OS del TR-46 y finalmente una función para interconexión, IWF (Interworking Function).

PS BTS BSC

Sistema de radio

PCSC

OS AUX IWF

PCSC

DMH

HLR

VLR

AC

EIR

Gestores de movilidad

Redes externas

Otras VLR

Fig. 11.6 Modelo de referencia TR-46



RPT RP RPI

Sistema de radio

RPC

IWF

Redes externas

RASC

PSC

TMD TMC

PMCPMDRPT

OAM&P

Fig. 11.7 Modelo de referencia T1P1

11.2.2 Servicios PCS

Los servicios que se definen aquí están basados en el protocolo MAP, soportado por el estándar paraseñalización de interconexión IS-41. Aunque estos servicios están definidos para los sistemasnorteamericanos presentan grandes similitudes con los proporcionados por el sistema GSM. En la fasedos del T1P1 se definen una serie de servicios básicos que pueden agruparse de la siguiente forma:

Servicios básicos

Funciones de registro y desregistro de la PS (Personal Station) al sistema PCS- registro automático- autentificación de terminal y privacidad (usando clave privada)- autentificación de terminal y privacidad (usando clave pública)- autentificación de usuario y validación- registro personal automático- desconexión del registro personal automático- registro personal- desconexión del registro personal

Funciones para la comunicación interna entre la red PCS visitante y la red PCS en la que el usuarioestá abonado.Funciones de seguimiento del terminal entre diversas redes PCS.Procedimientos de establecimiento, continuación y liberación de llamada.

- origen de la llamada- distribución de la llamada- liberación de la llamada- llamadas de emergencia (E911)- handover


Gestión de red136

Servicios suplementariosLos servicios suplementarios se definen en el estándar IS-104 (Personal Communications ServiceDescriptions) para 1800 MHz. El IS-41 C define también servicios, pero sólo están disponiblescuando hay un seguimiento del móvil. Otros servicios podrían ofrecerse únicamente por determinadossistemas PCS. Estos servicios son:

Rellamada automática, llamadas a cobro revertido, mantenimiento y devolución de llamada,redirección de llamada (por defecto, ocupado, no respuesta, incondicional), transferencia de llamada,llamada en espera, presentación de la identificación del número que llama, restricción a laidentificación del número que llama, multiconferencia, no molestar, alerta flexible, notificación demensaje en espera, prioridad de acceso, prioridad multinivel, aceptación de password, preferencia delenguaje, acceso prioritario por asignación de canal, llamadas remotas, aceptación de llamadaselectiva, acceso e intercepción de PIN, llamadas con tres usuarios, mensaje de voz pregrabado,privacidad de voz y servicios de mensajes cortos.

Estos servicios tienen que poder proporcionarse estando el terminal en movimiento, para lo cual esnecesario una adecuada gestión de movilidad por parte de la red de acceso del sistema. A continuaciónse expone la solución más común adoptada actualmente.

11.2.3 Gestión de movilidad

Uno de los aspectos fundamentales en sistemas PCS es cómo se gestiona la movilidad. Esta gestión semantiene actualmente a partir de una estructura formada por dos tipos de bases de datos con dosniveles jerárquicos (basados en GSM o bien en el sistema americano de señalización IS-41). Laconfiguración más normal dispone de una única HLR (Home Location Register) que es un registro delocalizaciones en el cual se almacena la identidad del usuario móvil para propósitos de informacióndel usuario móvil (p.e. número en el directorio, información de perfil, localización actual o periodo devalidación) junto con varios VLR asociados (Visitor Location Register). El VLR es otro registro delocalizaciones temporales (de visitantes) usado para obtener información en el establecimiento dellamadas a/o desde un usuario móvil visitante.

Los sistemas más avanzados como UMTS dispondrán de una arquitectura de bases de datosdistribuida jerárquicamente que permitirá una gestión de la movilidad de los usuarios con una carga deseñalización y retardos menores. En el último punto se explica con más detalle este tipo de sistemas.Esta gestión de movilidad se apoya, pues, en unos recursos que se estructuran de manera diferentesegún los requerimientos de los usuarios y las capacidades de la red.

11.2.4 Gestión de recursos

La gestión de recursos incluye en general la asignación de recursos y el acceso tanto en la red fijacomo en la red móvil. Aquí se describirá lo que ocurre en la parte de la red móvil.

Una forma de asignar recursos es mediante esquemas de acceso múltiple. Estos tipos de esquemas seutilizan para compartir entre un grupo de usuarios un canal común de subida de forma que se mejorala capacidad del sistema y disminuye su coste. Existen tres características básicas para el diseño delacceso en un sistema PCS: flexibilidad, calidad y capacidad. La flexibilidad se refiere a la capacidadde manipular voz integrada, datos y tráfico de vídeo, tratando con la capacidad de seguimiento del



usuario. La calidad significa satisfacer requerimientos de servicio, tales como el retardo y/o laacotación de la pérdida de paquetes. La capacidad significa que el número de usuarios con serviciotendría que ser máximo para el ancho de banda dado. No siempre es fácil llegar a un buen compromisoentre estos factores.

En las redes futuras de tercera generación se exigirán redes inteligentes integradas, tanto en el accesomóvil como en la red fija. Por ejemplo, si se considera un cluster de celdas en una determinada áreageográfica, un gran operador de telefonía celular podría dar cobertura con celdas a muchas carreteras,otro a la red ferroviaria, otro operador a diversos edificios de oficinas limítrofes, etc. Para disponer deun entorno de gestión común eficaz, donde la optimización en la cobertura de las celdas, y laasignación de canales y de recursos en la red sea posible conjuntamente para las más diversasnecesidades de tráfico cambiantes se necesitaría la integración de los múltiples sistemas coexistentesen una única red inteligente.

Esta integración de subsistemas para gestionar recursos en la red requiere de la especificación de unmétodo de acceso que permita obtener la adecuada sinergia al conjunto de la red.

11.2.5 Métodos de acceso en PCS

Los esquemas de acceso múltiple pueden clasificarse en tres tipos: de acceso aleatorio, de asignaciónfija y de asignación por demanda. El acceso aleatorio en PCS puede resolverse mediante mecanismoscomo ALOHA y CSMA/CD, ya conocidos, o bien mediante técnicas de acceso CDMA, en donde secomparte todo el ancho de banda. En los sistemas de asignación fija las transmisiones son coordinadascompletamente por la estación base y ésta asigna la frecuencia con el canal correspondiente a cadaterminal. Éste es el caso de los métodos de acceso basados en FDMA o TDMA.

Cuando el acceso es por demanda de una asignación, existen distintos métodos que requierenexplícitamente de control, como D-TDMA, PRMA, DRMA o DH-TDMA. Estos métodos deasignación se basan en el hecho que las conversaciones de voz consisten en franjas temporales deactividad (talkspurts) seguidas de saltos con silencios. Durante las fases de silencios no se generainformación y los recursos de canal pueden utilizarse para otros usuarios de forma que puedeobtenerse mediante multiplexación una gran eficiencia.

Por último, pueden distinguirse una serie de métodos de asignación de canal que administran losrecursos desde una perspectiva global por parte de la red para conseguir una eficiencia óptima delespectro. Este es el caso de estrategias como la macrodiversidad, el préstamo de canales, la asignacióndinámica de canales (DCA), o bien funciones de coste que tengan en cuenta el estatus de la red, etc.

Junto al método de acceso es necesario especificar la pila de protocolos de señalización utilizados enlas distintas interfaces del modelo de referencia de la red para que ésta pueda proporcionar losservicios PCS adecuados al usuario.

11.2.6 Protocolo de señalización

El protocolo de señalización asociado a PCS está basado en el SS7 de la ITU y se recoge en lasrecomendaciones Q.1061 y Q.1062. SS7. Es un protocolo altamente fiable, que utiliza enlaces a 64Kbps en Europa y de 56 Kbps en Estados Unidos. La introducción de la nueva carga de señalización


Gestión de red138

asociada a los servicios PCS será 3 o 4 veces superior a la asociada a sistemas móviles como GSM,que ya de por sí es importante.

Los tres niveles más bajos del protocolo de señalización propuesto son el nivel físico, nivel de enlacey el nivel de gestión. El nivel físico se encarga de la transmisión de la información en cada uno de loscanales, proporcionando los canales lógicos para las capas superiores. El nivel de enlace implementalas funciones de control de errores para el entorno de radioenlaces, así como para los entornoscableados convencionales. El tercer nivel comprende tres entidades funcionales definidas como:gestión de recursos radio (RR), gestión de movilidad (MM) y gestión de conexiones (CM).

La introducción de la IN (Intelligent Network), proporciona independencia del servicio separando lasecuencia de control de éste de la gestión de los recursos de red. Para gestionar la movilidad en PCSse introduce el MAP (Mobile Application Part) situado en el nivel de aplicación de SS7. Laimplementación de un MAP requerirá el uso del concepto del Application Service Element (ASE) deIN. Éste se define como un conjunto de funciones de aplicación que proporcionan capacidad para lainterconexión de entidades de aplicaciones con un propósito específico, según se observa en la figura11.8.

El protocolo MAP es realmente un ASE basado en el TCAP (Transaction Capability ApplicationPart). Éste está formado por dos subcapas, el subnivel de componentes y el subnivel de transacciones,correspondiente al nivel de aplicación. MAP también requiere el soporte de la parte de control deconexiones de señalización SCCP (Signalling Connection Part) y del MTP (Message Transfer Part)del SS7.

En Estados Unidos se esta definiendo también el estándar T1M1 PCS OAM&P para el tratamiento deoperaciones, la administración, el mantenimiento y la disposición de costes para redes basadas enPCS. En Europa, el GSM tiene su propia normativa a partir de las 12 series de especificacionesdefinidas por ETSI.

11.2.7 Red inteligente para servicios personales en redes de comunicaciones móviles avanzadas

Para las comunicaciones móviles personales se necesitan todas las funciones de la red inteligenteusuales en las redes de cableado fijo, más otras relacionadas con la movilidad de servicio del abonadoy en la gestión de la llamada. Éstas incluyen la obtención y renovación de información delocalización, autentificación, encaminamiento de llamadas, traspaso, tarificación y mantenimiento.Estas funcionalidades de servicio adicionales causarán un dramático aumento en el tráfico deseñalización, especialmente en los entornos de microceldas con altas densidades de terminalesmóviles con frecuentes renovaciones de localización. Los sistemas de telefonía móvil actualesincorporan las funciones mencionadas anteriormente mediante dos redes inteligentes interconectadas,una para el sistema móvil y otra para la red fija a la que está conectada (p.e. RDSI).

En el caso de los procedimientos de movilidad, el estándar de red inteligente CS-2 (series Q.1200 dela ITU-T) tendrá que adaptarse a una arquitectura distribuida soportada por múltiples funciones decontrol de servicio (SCF's). Esto es un camino necesario para evitar señalización innecesaria en la redy minimizar los retardos incurridos.

Por otra parte, dadas las características de red avanzada que puede soportar PCS, se está diseñando unterminal móvil tal que sea un terminal inteligente multimodo capaz de adaptar sus subsistemas de



radio dependiendo del servicio requerido, la carga de teletráfico y el estatus del radiocanal. Esteterminal móvil dispondrá de lector de tarjetas inteligentes para la provisión de los parámetros deseguridad y los datos relativos al abonado. Esta aproximación proporciona flexibilidad a operadoresde red y a proveedores de servicio, permitiendo evolucionar según progrese la tecnología.

MAPProceso de aplicación

ASE ASE ASE ASE

TCAP

Entidad de aplicación

Subcapa de componentes

Subcapa de transacciones

SCCP

MTP

Fig. 11.8 Protocolo MAP en ITU/SS7

11.3 Funciones de gestión. Objetos gestionados

Dentro de las recomendaciones de red TMN existe un apartado para GSM. El grupo SMG6 del ETSIdefinió unas interfaces Q3 entre el sistema de operación y los elementos de red. Se especificaronaspectos de Q3 relacionados con las cinco áreas funcionales definidas por la ITU.

En las áreas de gestión de configuración y de fallos, la cobertura se limitó a la BSS. Otros elementosde red como VLR y HLR se trataron más en relación a la gestión de tarificación. La MSC no seconsideró estrictamente un elemento de red GSM y su definición se dejó para más adelante. En cuantoa gestión de seguridad, no se contemplaron especificaciones nuevas, considerando que ya se habíandefinido suficientes funcionalidades.

En general el modelo GSM puede estructurarse en tres tipos de objetos. Uno representa puramente losrecursos funcionales. El segundo tipo representa objetos que son recursos funcionales se relacionangeneralmente con el equipo. El tercer tipo son aquellos objetos que representan recursos de equipo


Gestión de red140

directamente. En total, existen más de 100 clases de objetos gestionadas, definidas con casi 500atributos.

La definición de los managed objects (M.3100 de la CCITT) se encuentra en la serie 12 de GSM-ETSI. Estos managed objects soportan la interface Q3. Las clases de objetos que son top en eldiagrama de contención son las siguientes: BssFunction, hlrFunction, vlrFunction, mscFunction,aucFunction, eirFunction, callRecordingFunction, sms_G_IWFunction. Otros objetos gestionadoscomunes son: simpleFileTransferControl, generalDataTransferControlFunction, gsmEquipment, etc.

11.4 Red inteligente y sistemas de comunicación móviles

11.4.1 Características de los servicios UPT

Dentro de los sistemas de comunicación personal que se espera tengan mayor implantación en Europa,la que está más desarrollada en especificaciones es la interfaz UPT. Además, actualmente UPT senutre también de recomendaciones generadas por la ITU. Por eso en este apartado se describirán suscaracterísticas principales.

En entornos UPT se permite a los usuarios UPT realizar y recibir llamadas en cualquier terminal, fijoo móvil conectado a cualquier red. Esto es la base de la movilidad personal. En cambio, la movilidadpersonal en PCS se incorpora como una mejora en la movilidad de terminal de una red móvil (Fig.11.9).

Una de las características fundamentales de UPT es la portabilidad de servicio. En este caso, sepermite a los usuarios invocar servicios a los que se está abonado desde cualquier terminal en la red.Sin embargo, el tipo de terminal y las capacidades de la red con las que se opera podrían limitar lascaracterísticas del servicio que se solicita.

Para poder disponer de movilidad personal se requiere de un número personal (o número personalUPT) que permita identificar de manera única y directa a un usuario independientemente del terminalutilizado. El número personal UPT se utiliza, pues, para realizar y recibir llamadas, así como para sutarificación. Este número UPT será utilizable desde cualquier terminal fijo o móvil con lasrestricciones que impongan los operadores de red, la capacidad de la red en cualquier lugar teniendoque ser conectable y enrutable desde cualquier red bajo una perspectiva global. Por tanto, se puededecir que un usuario UPT es un usuario abonado a este servicio con un único número.

En la recomendación E.168 de la ITU-T se muestran cuatro esquemas de numeración para UPT oaproximaciones basadas en la recomendación E.164 de la ITU-T. El número UPT sirve como punteropara indicar un registro o fichero donde se ubica información relativa al usuario y a los servicios a losque está abonado. Esta información tiene una parte que es fija (servicios abonados, tarificación,restricciones de movilidad, etc.) y otra parte variable (direcciones, posición, encaminamientos,...). Unusuario, según los acuerdos a que haya llegado con el proveedor de servicio y según las capacidadesde la red, tendrá la posibilidad de leer o escribir en su perfil de servicio UPT.

El uso de tarjetas inteligentes en redes móviles permite distinguir un tercer tipo de movilidad, distintade las anteriores (de terminal y personal). Un ejemplo bien conocido de tarjeta inteligente es elSubscriber Identity Module (SIM) utilizado en GSM. Este tipo de movilidad de tarjeta SIM es análoga



a la movilidad de terminal, pero proporciona una especie de servicio de movilidad personal dentro dela red GSM.

Las tarjetas inteligentes se utilizarán en las futuras redes de tercera generación como UMTS oIMT2000 permitiendo múltiples aplicaciones en entornos de red inteligente. Su uso puede servir comoun posible método de acceso para acceso a UPT o autentificación en redes de comunicaciones móvilesbasadas en la movilidad personal.

Las especificaciones UPT le permiten soportar un gran conjunto de servicios. Es previsible suimplantación progresiva en sucesivas fases, conforme avance la tecnología y aumente la demanda delmercado. En una primera fase se desarrolla el conjunto de servicios UPT 1 para ser utilizados en laparte nacional, (recomendación ANSI T1.701), o bien a nivel internacional (recomendación F.851 dela ITU-T). Esta primera fase de UPT soporta el servicio telefónico sobre redes públicas analógicasconvencionales, redes móviles y RDSI. Análogamente, el conjunto de servicios UPT 2 se sitúa en unescenario más avanzado, todavía en fase de especificación y desarrollo, tanto a nivel nacional comointernacional [10]. El desarrollo de UPT requiere de una tarificación, un encaminamiento de llamadas,diversas facilidades en torno a las bases de datos, etc. que hacen necesaria la introducción de cambiosen la red. Para facilitar este proceso se requerirá la potenciación conjunta de las redes inteligentes asícomo de una adecuada señalización, basada en el SS7.

Características de los servicios UPT 1

A continuación, se describen brevemente las facilidades proporcionadas por el conjunto de serviciosdefinidos en la fase 1 de las recomendaciones UPT.

- Autentificación de la identidad de usuario UPT: esta utilidad permite al proveedor de servicio UPTverificar la identidad de un usuario UPT.

- Registro de llamadas entrantes: esta utilidad permite al usuario UPT registrar todas las llamadasentrantes a una determinada dirección de terminal fijo o móvil.

- Llamadas UPT salientes: esta facilidad permite al usuario UPT realizar llamadas salientes desdecualquier terminal, fijo o móvil, previa autentificación de usuario.

- Seguimiento de llamadas salientes: esta facilidad permite al usuario UPT, antes de terminar unallamada saliente UPT a indicar la invocación de otro establecimiento de llamada sin necesidad deautentificación.

- Distribución de llamadas entrantes: es una facilidad de la red que permite presentar en pantalla de unterminal las llamadas UPT entrantes a un determinado usuario UPT que previamente se hayaregistrado.

Características opcionales de los servicios UPT 1

Estas facilidades tratan de complementar los servicios establecidos en la fase 1 de UPT. Todos ellosson opcionales y su implementación dependerá de las características del terminal, de la red, así comode las condiciones impuestas por el proveedor de servicio.


Gestión de red142

- Registro de llamadas salientes: el registro de llamadas salientes permite a los usuarios UPT realizarllamadas salientes desde una determinada dirección de terminal; para ello, el terminal ha sidopreviamente personalizado, autentificado y las llamadas son cargadas al correspondiente número UPT.

- Registro de todas las llamadas: esta utilidad permite al usuario UPT combinar el registro simultáneode llamadas entrantes y salientes.

- Registro de llamadas remotas entrantes, salientes y totales: esta utilidad permite registrar todo tipo dellamadas a la dirección de un terminal remoto desde otro terminal.

- Seguimiento global: esta facilidad permite a un usuario UPT, previa autentificación y uso deservicios UPT, indicar una actividad de seguimiento antes de una desconexión total.

- Registro de llamadas entrantes por defecto variable: esta utilidad permite a un usuario UPT a teneruna serie de registros por defecto para poder atender llamadas entrantes según diferentes horarios uopciones personales.

- Interrogación de perfil de servicio UPT: esta facilidad permite a un usuario UPT el consultar losdatos relativos a su propio perfil de usuario.

- Modificación de perfil de servicio UPT: esta facilidad permite a un usuario UPT el consultar y /omodificar los datos relativos a su propio perfil de usuario, como puede ser el password u otrosparamétros de servicio.

11.4.2 Seguridad en la red

Desde el punto de vista de seguridad, en UPT se tienen en cuenta dos situaciones importantes quepueden constituir amenazas para el sistema. En el primer caso, se trata de la fase en la que seproporcionan servicios de comunicación, en donde los datos relativos a un usuario UPT, tales como suidentidad, número, posición, etc. son transmitidos desde unas bases de datos a otras con lo que debeasegurarse su privacidad y protección. En el segundo caso, se trata del proceso de verificar laidentidad de un usuario UPT. Se realiza mediante la ayuda de una clave privada de autentificación (p.e. con un PIN) que es un número que permite autentificarse mutuamente el usuario UPT y elproveedor del servicio.

11.4.3 Servicios UPT de red inteligente sobre red GSM

En este apartado, como caso especial, se estudia la integración que supone una interfaz queproporciona comunicaciones personales como UPT en un sistema de comunicaciones móviles de granimplantación actual en Europa como es GSM. En este caso, la introducción de los servicios UPT en lared requiere de mayores capacidades en las bases de datos asociadas así, como una mayorfuncionalidad de inteligencia desde la infraestructura de la red PSTN que la soporte. El modelofuncional UPT está basado en el estándar de arquitectura de red inteligente a causa de su granflexibilidad en la creación de servicios. De esta forma, UPT puede integrarse en plataformas sobreGSM que dispongan de servicios de red inteligente. A continuación se analizarán los pasos que sedeben efectuar para introducir los servicios UPT en la red GSM.



En primer lugar se describirán el conjunto de modificaciones que se deben realizar en la estructurafuncional de una red inteligente, (Fig. 11.9) para soportar el conjunto de servicios UPT. Estasfunciones del sistema pueden dividirse desde un punto de vista geográfico en elementos originantes,de abonado y elementos terminantes. Desde un punto de vista lógico se dividen en un control dellamada, control de servicio y funciones de gestión.

En la figura 11.10 se muestra la arquitectura funcional en la interfaz UPT. Para una adecuadaintegración de las redes, se requieren una serie de cambios en las funcionalidades relativas alestablecimiento de llamada. Concretamente, la función del agente de control de llamada UPT (CCAF)requiere de una combinación específica por parte del terminal usado, el dispositivo UPT y lafuncionalidad de red para proporcionar acceso al servicio UPT. Desde el punto de vista de losterminales existentes, incluyendo GSM, sólo pueden hacerse cambios mínimos en CCAF. Desde unpunto de vista ideal, UPT no impone requerimientos especiales en la función de control de llamada(CCF). Esto se debe a que la señalización a partir de pulsos decádicos puede convertirse en señalesDTMF e información relacionada con el protocolo de señalización SS7, tal como de línea llamante ode identidad de línea llamada, debe ser soportada por todas las redes. Esto es posible en GSM.

Siguiendo con los elementos descritos en la figura 11.10, dentro de las funcionalidades relacionadascon la operación de servicios, la función de conmutación de servicio (SSF) permite interrogar a lafunción SCF y así recibir una respuesta, que permite el intercambio de servicio de forma correcta.Algunos servicios UPT (p. e. registro para llamadas salientes), podrían requerir que la funcionalidadSSF sea soportada tanto a nivel de central local como a nivel de tránsito. En el Mobile SwitchingCentre (MSC) de GSM, actuando como central local, es posible registrar llamadas salientes para uncierto periodo de tiempo siempre que éste conozca el estatus de línea. Los mismos resultados sepodrían obtener si se consiguiera integrar la SSF, función de conmutación de servicio en la MSC.

La función de control de servicio (SCF) contiene el servicio lógico para UPT y es capaz de realizartodo tipo de consultas a la base de datos desde otras redes. La función de datos de servicio (SDF)contiene información relacionada con el servicio y el abonado UPT. Esta entidad necesita un estudiomás profundo que permita diseñar una estructura estándar fácilmente utilizable en los procesos deautentificación, perfil de servicio, información de localización, etc. En esta reflexión parece muyrecomendable estudiar las especificaciones diseñadas para GSM que pueden ser de utilidad en elproceso de integración y seguramente evitarán esfuerzos redundantes en el diseño.

Existen otras funciones también necesarias como son la función de recursos especiales (SRF), quetraduce las señales DTMF para el SCF, y las peticiones SCF en anuncios vocales para el usuario. Otrafunción de interés es la que permite la creación de servicios (SCEF): su principal misión es ladefinición, creación, y comprobación del servicio UPT.

Los procedimientos UPT no relacionados con la llamada en la red inteligente pueden manipularse dedos formas diferentes:

- El usuario interactúa con el mismo terminal que utiliza para realizar o recibir llamadas, y lainformación pasa a través de las funciones CCAF, CCF, SSF, SCF y SMF (función de gestión deservicios).

- El usuario interactúa con un terminal dedicado a la gestión de servicio, y la información pasa através de la función de acceso de gestión de servicio (SMAF), SMF, SCF, y SSF.


Gestión de red144

Desde un acceso PSTN, el primer método se usa para procedimientos simples, que se realizanfrecuentemente desde distintas situaciones, tales como procedimientos de movilidad personal. Elsegundo método se usa en procedimientos más complejos (p.e. gestión de servicios), que se justificanen pocas situaciones. El objetivo a largo plazo es que el acceso a RDSI pueda utilizarse para todos losprocedimientos de gestión. Al principio, en GSM se prevee, por su simplicidad, el primer método.Esto implica que la SMF sería flexible para permitir el uso de varios procedimientos de gestión deservicios como pueden ser la modificación de perfil de servicio, el chequeo de los límites de crédito,la tarificación, las estadísticas, etc.

Es imprescindible definir la interfaz entre un usuario UPT y el sistema GSM, puesto que en general unabonado UPT requiere disponer de un acceso para operar en la red, es decir, registrar y realizarllamadas entrantes / salientes, o bien modificar el perfil de servicio, incluyendo el encaminamientosegún hora del día, lista de preferencia de usuarios llamantes, opción de no molestar o de correo vocalsi está ocupado.

En la primera fase, está prevista la utilización de teléfonos con teclado DTMF, y realimentación vocal.Dado que no es deseable el tecleado de largas secuencias de números, para simplificar elprocedimiento de acceso podría usarse la información de la dirección de la línea llamante. Ensucesivas fases de desarrollo e implantación de estos servicios se usará una única tarjeta inteligenteque permite proporcionar acceso a través de teléfonos públicos así como privados equipados conlectores de tarjetas. Entre estos se pueden incluir los sistemas de comunicaciones móviles tales comoGSM, DECT, y avanzados o de tercera generación como UMTS/FPLMTS.

El acceso de GSM al servicio UPT se puede efectuar mediante el tecleado de una secuencia de dígitos(incluyendo un código de acceso UPT, un número UPT y un número de identificación personal) yseleccionando el servicio usando un sistema de voz interactivo.

Cuando un abonado UPT se registra en un terminal GSM usando un dispositivo DTMF, se enfrenta aun problema, ya que las señales DTMF no pueden soportarse actualmente de forma fiable por loscodificadores de voz GSM. Sin embargo, el uso de un dispositivo DTMF permitiría a los abonadosUPT y GSM tener sus servicios activos al mismo tiempo. En otras situaciones, es posible que unabonado UPT se registre en un terminal que contenga una tarjeta SIM de otra persona. Si el usuarioextrae la tarjeta y realiza un nuevo registro de posición, los registros UPT le siguen a la nuevaposición y terminal. Este problema podría evitarse con una desconexión del registro UPT automático.Se pueden realizar ciertas consideraciones de cierto interés y que surgen por la incorporación defuncionalidades UPT en terminales GSM. En las últimas fases de diseño de UPT, el dispositivo queproporciona servicios podría ser del tamaño de una tarjeta SIM. Sin embargo, en este caso seríaimposible para el abonado GSM original tener sus servicios simultáneamente activos en el terminalcuando un abonado UPT se registre en éste. Si un abonado GSM y uno UPT se registraran en elmismo terminal, la red sería incapaz de encontrar si una llamada entrante va al abonado GSM o alUPT. Para solucionarlo se requerirían algunos pequeños cambios en las especificaciones deseñalización existentes (p.e. un bit para indicar una llamada UPT).

Otras cuestiones de relativo interés se refieren a la actuación que deben tener los propietarios determinales para poder protegerse de los mismos usuarios UPT. Es necesario habilitar una serie deprocedimientos que permitan la desconexión del registro de usuarios UPT de una dirección determinal, así como la protección de la información de perfil de servicio, la tarificación etc. de las basesde datos. Por eso, sería necesaria la verificación de la autorización de entrada al servicio UPT en cadapetición.



La provisión de autentificación prevista por medio de la utilización de un PIN parece no muyrecomendable. En este caso, una tercera persona podría encontrar el código y usar el servicio a cuentade los abonados. El problema podría reducirse notablemente si se dispusiera de una tarjeta inteligenteUPT/GSM.

Una vez se ha analizado la interfaz entre UPT y GSM para tener acceso a diversos servicios UPT seprocede a la especificación de los procedimientos para poder soportarlos.

Un usuario UPT puede controlar el servicio usando procedimientos UPT estandarizados. En unaprimera fase, estos procedimientos se efectúan manualmente, por ejemplo, usando el dispositivo desuscripción y mediante apuntes vocales. Todos los procedimientos que se pueden sugerir requieren eluso de ciertos elementos básicos, tales como acceso, autentificación, e identificación del abonado.Como se ha dicho anteriormente, los procedimientos UPT pueden clasificarse en cuatro grandescategorías: procedimientos de movilidad personal, procedimientos de establecimiento de llamadaUPT, procedimientos de gestión de perfil de servicio UPT y determinados procedimientos especialesde gestión de red.

En el establecimiento de la llamada, el terminal GSM indicaría que un determinado servicio UPT estáactivo informando al usuario (GSM o UPT). Por ejemplo, una llamada UPT entrante se distinguiría deuna llamada GSM ordinaria por un tono de alerta, un apunte vocal con autentificación, o un displayespecial. En el caso de apuntes vocales, los terminales existentes no requieren modificaciones.

Entre los procedimientos especiales de gestión de la red existe el de la facturación de cargos otarificación del abonado. En el caso de la tarificación de un abonado UPT, ésta se basa en el númeroUPT. El abonado recibe una sóla factura a pesar de las redes o servicios usados. El operador es librede ofrecer a sus abonados paquetes de servicios UPT adaptados al cliente. De acuerdo a laspreferencias de los usuarios, la tarificación puede basarse en la localización del usuario llamado yllamante, hora del día, duración de la comunicación, etc. La información de contabilidad UPT sereúne en la red usada, que es transferida y manipulada de acuerdo a los principios de tarificacióninternacional. Si se usan recursos de red inteligente locales como plataformas UPT, se requierenacuerdos entre operadores UPT para asegurar que cada abonado UPT trata únicamente con unoperador. Los cargos se pueden basar en los siguientes componentes: suscripción (pago inicial y tarifamensual), gestión de la suscripción (p.e. servicios disponibles, cambios,..), uso de servicios (p.e.llamadas), cargos relacionados con la posición. Los cargos al abonado UPT se realizan de formasimilar a GSM. Si un abonado UPT se registra y realiza llamadas desde un terminal GSM, lasllamadas se cargan al abonado UPT hasta el punto de la red a la que está abonado el usuario llamado.

Una situación especial se produce al tratar determinados conjuntos de servicios. En este caso, ETSI(European Telecomunications Standard Institute) ha especificado un conjunto de serviciossuplementarios para UPT. Por otra parte, la red GSM se ha diseñado de acuerdo con los principios deRDSI, de forma que todos los servicios suplementarios GSM tienen sus contrapartidas en RDSI.Podrían producirse condiciones de colisión entre los servicios suplementarios al ocurrir solapamientosen las coberturas de ambos sistemas. Para evitar esto, se podría denegar el registro UPT si hubiera unservicio activo GSM que pudiera provocar una colisión. Sin embargo, la mejor solución pasa pordistinguir entre llamadas GSM y UPT.

La gestión en UPT requiere de un protocolo de aplicación especial. Debido a que se ha adoptado laarquitectura de red inteligente en una primera fase, UPT utilizará INAP (Intelligent Network


Gestión de red146

Application Part) como su protocolo de aplicación. Además usará el modelo conceptual y de gestiónde la red inteligente para propósitos de diseño y control.

La gestión UPT se divide en cinco areas funcionales de gestión (MFAs): gestión de perfil de servicio,gestión de abonado (administración de abonados y usuarios), gestión de tarificación, gestión deseguridad y gestión de interconexión de redes. Más adelante, la gestión UPT será adaptada a la red degestión de telecomunicaciones (TMN) definida por la ITU.

Si las redes GSM y la UPT se integran, los principios de gestión deben ser consistentes. Un abonadoUPT debe ser capaz de modificar una porción de su perfil de servicio y desconectar el registro dellamadas entrantes y salientes usando un terminal GSM. En un principio, sólo podrán utilizarsemodificaciones basadas en una señal DTMF o bien apuntes vocales. En el futuro, las facilidades delGSM relativas a la posibilidad de envío de mensajes cortos podrían utilizarse para el registro y lageneración de un menú basado en una plataforma de selección interactiva que permita la modificaciónde servicios. Sin embargo, esto requerirá de una interconexión con un centro de servicios y con lasbases de datos (SDF o HLR) que no se ha especificado todavía.

La arquitectura de interconexión actual entre red inteligente y GSM no contiene señalización directa,de forma que si se requiere un intercambio de información entre ambas redes tiene que establecerseuna llamada. Esta arquitectura debe adaptarse convenientemente para introducir los servicios UPT.

Para posibilitar una conexión directa entre entidades, algunas funcionalidades como las provistas porel SSF y SRF tendrán que instalarse en la MSC. Cuando se usan servicios UPT desde GSM, unaconexión de señalización es suficiente ya que la MSC tiene funcionalidades en la SSF para un accesodirecto a la SCF, tal como puede verse en la figura 11.11 En la figura 11.12 pueden observarse losdatos de abonado GSM y cómo deberían integrarse en la base de datos de la red inteligente a la que seestá abonado. Eso facilitaría la obtención de información relacionada con GSM hacia la SCF.También las bases de datos con los perfiles de servicio del operador GSM o UPT a los que se estáabonado podrían integrarse. Las autentificaciones podrían unificarse. En general, la integraciónflexible de bases de datos proporciona información relacionada con la movilidad a los servicios de redinteligente reduciendo la carga de señalización en la red. El operador de red inteligente y el decomunicaciones móviles podrían ser el mismo, posibilitando una conexión de bajo coste.

Grupo llamante

Grupo UPT llamado

Grupo UPT llamado Base de

datos UPT

País BPaís A

País C

Llamada actual

Obtención de localización

Seguimiento

Fig. 11.9. La red inteligente permite a una llamada actual ser enrutada directamente desde el país A al país C



SSF

SCF

SDF

SMF

SMAF

SCEF

CCFSSF

SCF

SDF

SMF

SMAF

SCEF

CCF CCFCCAF CCAF

SRF SRF

Red originante

Red terminal

SCF

SDF

SMF

SMAF

SCEFRed de abonado

Fig. 11.10 Arquitectura funcional en UPT

SDF

SCF

INAP INAP

TUP/ISUP

SSP

CCFSSF

HLR

MAP

VLRSSFSSF

MSC

Fig. 11.11 Integración de facilidades de red inteligente en la MSC para el soporte de movilidad personal


Gestión de red148

SDF

SCF

INAP INAP

TUP/ISUP

SSP

CCFSSF

MAP

VLRSSFSSF

MSC

HLR

Fig. 11.12 Integración de facilidades de red inteligente en las bases de datos VLR/HLR para el soporte demovilidad personal

MSF

MCF

MCCF

MRRC

MRTR RFTR

RRCRBC

BC

ACCF

SCF(M)o

SDF(M)o

SMF

SMAF

SCEF

Relaciones de gestión de servicios

Relaciones de control de conexiones de llamada

Relaciones de control de conexiones portadoras

Relaciones de control de servicio

Inteligencia

Acceso y Transporte

Parte móvil Parte de la red

Fig. 11.13 Modelo funcional en UMTS - FPLMTS



11.4.4 Red inteligente en GSM: CAMEL

La red inteligente en GSM se ha denominado CAMEL (Customized Applications for Mobile NetworkEnhaced Logic). Sus principales características son:

- Como una plataforma, CAMEL permite a los operadores móviles definir y desarrollar nuevosservicios de valor añadido sin necesidad de estandarizarlos.- Los operadores se pueden diferenciar de los otros operadores de red mediante la introducción deestos nuevos servicios de valor añadido.- Estos servicios pueden usarse cuando el roaming sea internacional.- CAMEL está diseñado para trabajar como un entorno multifabricante para la infraestructura, comolas estaciones móviles.

El potencial a largo plazo del desarrollo de CAMEL es tan grande que el concepto de Virtual HomeEnvironment (VHE) planificado para el sistema UMTS está adoptando una gran importancia.

La tercera fase de implantación de servicios de CAMEL está prevista para el año 1999. Se esperasoporte una interconexión con la gestión de movilidad y con los servicios de GSM, posibilite lagestión de llamadas a más de dos terminales y el soporte de un nuevo VHE para facilitar el paso aUMTS.

11.5 Evolución de PCS hacia sistemas de tercera generación

Los recientes avances tecnológicos están permitiendo cada vez más un flujo interrelacionado depersonas a escala mundial. En esta nueva era de globalización económica cada vez se hace másnecesario el soporte de una red de comunicaciones móviles de cobertura mundial. El sistemaUMTS/IMT2000 de la ITU surge como un intento de cubrir estas necesidades de comunicación. Paraello, se requiere de una nueva arquitectura de red inteligente (IN CS-3) que se integre en el sistemadefinido y que posibilite la gestión correcta de la información transmitida entre los nodos del sistema.

Los sistemas de tercera generación como por ejemplo IMT2000/UMTS, permitirán dar soporte a losabonados para realizar cualquier tipo de comunicacion sin restricciones en el área de servicio, en laforma, ni en el instante de tiempo elegido. El sistema tendrá que ser capaz de poder transportarmuchos tipos de información diferente y servir en muchos entornos de población diferentes. Entreellos se pueden destacar el entorno urbano, con alta densidad de tráfico, entornos rurales dispersos,interiores de edificios y vehículos que pueden estar moviéndose a gran velocidad (p.e. coches,trenes,...).

En principio, está previsto que el sistema IMT2000/UMTS tenga su propio servicio de movilidadpersonal disponible sólo en esa red, siendo la interfaz UPT necesaria para el caso de requerirmovilidad a otras redes.

Dado que IMT2000/UMTS dará acceso a servicios de información avanzados a una mayor población(millones de abonados) que los sistemas anteriores y a multitud de entornos, requerirá que latecnología de los sistemas terminales, así como de la red, sean notablemente mejoradas.

El sistema que se espera que se desarrollará, estará totalmente integrado por operadores de red de losdiversos países proporcionando cobertura mundial y con tasas de velocidad de información de hasta 2


Gestión de red150

Mbps, proporcionado gran capacidad y calidad a los más variados servicios. Las bandas de frecuenciaasignada para FPLMTS/UMTS por la WARC (World Administrative Radio Conference) son de 230MHz de espectro no contiguo entre los 1885 y 2200 MHz.

En este punto se introduce al lector en esos futuros sistemas de comunicaciones móviles. En primerlugar, se define la arquitectura de red en UMTS, tanto en la red de acceso como en la estructura dedirectorios de la red fija. Posteriormente, una vez se ha definido préviamente la arquitectura en la cualse va a operar, se desarrolla con más detalle la estructura de bases de datos distribuida del sistema.Este tipo de arquitectura es esencial para el buen funcionamiento de las futuras redes inteligentes, yaque actualmente son de tipo centralizado (p.e. CS1).

11.5.1 Arquitectura de la red UMTS

En este apartado se presenta una visión de la red UMTS según el proyecto MONET del RACE.Todavía no se ha desarrollado completamente un arquitectura definitiva para este estándar. Es en elentorno de la red UMTS donde van a integrarse los servicios para el usuario, a través de diferentesoperadores de red y de servicio. Esta red está compuesta por una red de acceso y una red fija, cada unade las cuales contiene sus propias bases de datos. La red de acceso comprende diversas entidades queproporcionarán funcionalidades que soportarán la cobertura de los radioenlaces. Es decir, ejerceránfunciones de soporte en las interfaces de radio, en la gestión de sus recursos y en el mantenimiento yoperación del traspaso.

La red fija UMTS comprenderá entidades que proporcionarán funcionalidades para soportar gestiónde movilidad, operaciones con bases de datos, e interconexión con otras redes. Todas las interfacescon la parte fija de la red están previamente establecidas y no existe distinción entre entidades de lared fija UMTS y entidades de otras arquitecturas (p.e. B-ISDN, UPT). Éstas podrían ser(parcialmente) coincidentes o (totalmente) distintas, dependerá de su nivel de integración. En la figura11.14 se representa la arquitectura de la red UMTS. A continuación, se describen brevemente losdiferentes componentes que forman la red UMTS:

La estación base (Base Transceiver Station, BTS) proporciona la gestión del radioenlace,representando la funcionalidad necesaria para el establecimiento, el mantenimiento y la liberación delradioenlace. La CSS (centro de conmutación de celda o Cell Site Switch) representa la funcionalidadde conmutación básica en la red de acceso. En el caso de las BCPNs, la CSS podría representar unaPBX fija o bien una NT2 dentro de un entorno ISDN.

La central de interconexión local (Local Exchange, LE) e interconexión de tránsito (Transit Exchange,TX) representan la red fija existente, es decir, la infraestructura de conmutación sobre la cual sesoportarán los servicios y procedimientos UMTS.

El punto de control del servicio y movilidad (Mobility and Service Control Point, MSCP) comprendela funcionalidad necesaria para el control de los procedimientos de movilidad y operación de serviciosen una cierta área; puede acceder, modificar y borrar información en las bases de datos (Mobility andService Data Point, MSDP). Las MSCPs estarían asociadas con la red fija (MSCP(LE/TX)) y con lared 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 SiteSwitch) al tener los entornos públicos (P) diferente funcionalidad de los de negocios privados



(Business, B). Además, la MSCP está preparada para soportar servicios y control de servicios de lared inteligente.

El punto de datos de servicio y movilidad (Mobility and Service Data Point, MSDP) puedeidentificarse como una entidad que forma la base de datos distribuida UMTS. Esta entidad almacenainformación concerniente a datos del terminal, perfil de abonado y de servicio, datos de red, datos delocalización, etc. Contiene también la funcionalidad de los datos que comprende el control y lacomunicación en las bases de datos.

El MT o terminal móvil (Mobile Terminal, MT) comprende las funciones ubicadas en la parte delradioenlace correspondiente al terminal móvil. El MT será un "terminal multimodo inteligente" consubsistemas programables. Éstos permitirán seleccionar el tipo de control de frecuencias, el método deentrelazado usado por el canal, el codificador, el procedimiento de acceso múltiple, el tipo demodulación, el control de ráfaga, la secuencia de spreading, las frecuencias portadoras, etc. Lageneración de las claves de cifrado para confidencialidad e integridad es realizada por una tarjetainteligente (Subscriber Identity Device, SID).

Las redes privadas o CPN (Customer Premises Network) pueden verse externamente como subredesUMTS. Existen CPNs según los diversos entornos posibles en UMTS: doméstico, de oficinas oempresas, o bien móviles. A diferencia de GSM u otros sistemas anteriores, en UMTS está permitidorealizar handovers entre redes distintas; eso comporta la adopción de servicios de seguridad talescomo autentificaciones, controles de acceso, cambio de claves, etc., que dependerán en últimainstancia de la política de seguridad del sistema.

Se pueden clasificar las CPNs según diversos criterios: uno de ellos, por ejemplo, según el tipo deinterfaz entre la CPN y la red adyacente UMTS (pública). Esta interfaz determina las funciones queson soportadas por la CPN en sí misma y las funciones que realiza la red pública. Atendiendo a estecriterio, se distinguen los siguientes:

- CPN simple con acceso transparente- CPN compleja con acceso UNI usuario-red (User-Network Interface, UNI)- CPN con acceso UNI mejorado para MCPN (CPN móviles).

11.5.2 Estructura de directorios en la red fija. Bases de datos distribuidas

En la estructura de red fija se dispone de una serie de bases de datos distribuidas que forman unaestructura jerárquica que permite almacenar tanto la información de perfiles de abonados como de lapropia red. Las bases de datos distribuidas están compuestas de nodos de almacenamiento deinformación (Information Storage Nodes, ISN), de los cuales pueden identificarse varios tipos (Fig.11.15).

Los ISNs son nodos que contienen datos UMTS, información de directorios y funciones de controlinternas. Pueden dividirse en nodos de almacenamiento de datos residentes y nodos dealmacenamiento de datos visitados. Ambos tipos no son mutuamente excluyentes y podrían coexistiren la misma ISNs. No configuran ninguna jerarquía.


Gestión de red152

Los ISNDn son nodos que contienen información de directorios y funciones de control, pero no datosUMTS. Están organizados jerárquicamente y pueden ser de los siguientes tipos: ISNDN, que sonnodos que están en la parte superior de la jerarquía y son responsables de las relaciones entre redes, eISNDn, 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 redespertenecientes a distintos operadores a través de una interfaz común UMTS. Estos nodos recibenpeticiones de las entidades UMTS que están fuera de las bases de datos y las transforman encomandos internos y peticiones, que envían a las ISNs apropiadas. Estos nodos son tambiénresponsables de recoger los resultados y devolverlos a la entidad originante.

11.5.3 Distribución de información en las bases de datos

En este apartado, a modo de introducción, se describen brevemente los mecanismos sobre los cualesfunciona el intercambio de los distintos tipos de información (p.e. de servicio o personal) entre lasbases de datos de la red fija y el terminal móvil del usuario.

Durante el funcionamiento normal de la red, el usuario con el terminal móvil va desplazándose sobrelas distintas celdas en las que tiene cobertura el sistema. En la ejecución de los procedimientos demovilidad, ciertos datos son transferidos, o bien obtenidos, modificados o renovados entre las bases dedatos del resto de la red. Cuando se considera el modelo funcional UMTS, puede entenderse elservicio de bases de datos como proporcionado por las entidades funcionales SDF (que representan labase de datos ISN) en respuesta a peticiones de servicio desde las entidades funcionales SCF (querepresentan los elementos de control de la red).

Los datos son estructurados en dominios bajo áreas administrativas con la supervisión de un operadorUMTS. Los proveedores de servicio son la autoridad que tiene la completa responsabilidad para laprovisión de un servicio o un conjunto de servicios (p. e. de tipo personal) a los usuarios finales.Como se verá, eso puede afectar a las disciplinas de control de acceso a determinados servicios. Losproveedores de servicios, a su vez, pueden dividirse en dos categorías, los públicos y los privados, conpolíticas de seguridad no siempre coincidentes.

El área de cobertura de un servicio personal es el área donde un proveedor de servicio dado esresponsable de la provisión de uno o más de estos servicios. Para realizar esa tarea, un proveedor deservicios personales tiene acceso a una base de datos o a un conjunto de bases de datosinterconectadas. Es importante también hacer una distinción entre las distintas clases de datos: losdatos usables directamente, que pueden ser procesados para responder a una petición de base de datos,y los punteros, que dan indicaciones de la posición de los datos usables pedidos en los dominios debases de datos y necesarios para soportar la provisión de un servicio.

En el caso del establecimiento de una comunicación personal, los datos concernientes a los gruposllamante y llamado se intercambian entre los proveedores del servicio, formando parte de distintosdominios. Se define el dominio UMTS visitado como aquel dominio en el que el terminal móvil(usuario) se está moviendo. En contraposición se encuentra el dominio UMTS de abonado (home) enel cual el terminal móvil (usuario) tiene una suscripción válida. Durante la ejecución de losprocedimientos de movilidad ciertos datos podrían ser transferidos (o modificados, obtenidos, etc.)



entre diferentes dominios UMTS. Se llama dominio UMTS originante a aquel dominio en el cual segenera una petición. Cabe notar que el dominio UMTS originante podría ser idéntico al dominio deabonado o visitado.

11.5.4 Conclusiones

A medida que se liberalizan los servicios de telecomunicaciones en todo el mundo y existen unasmayores necesidades de movilidad por parte de los usuarios, surgen una serie de problemas que tratande resolver estos nuevos sistemas de comunicaciones personales. Para el soporte de esta movilidadpersonal se requiere de una red inteligente que se integre en un principio en las redes existentesconvencionales para evolucionar, en un futuro, hacia sistemas más avanzados de tercera generación.El reto actual consiste en superar la problemática integración por la existencia de un considerablenúmero de operadores de redes y proveedores de servicios, tanto públicos como privados, que ofrecenun soporte para los servicios de movilidad personal PCS/UPT. En este caso, el mayor orden reinanteen Europa, en cuanto a operadores se refiere, permite ser optimistas en cuanto a su implantación final;sin embargo, se requerirán profundos cambios en las infraestructuras de comunicaciones así como enla misma sociedad, que de esta forma entraría de lleno en una nueva era de la información. En estecapítulo se ha tratado de dar una visión lo más amplia posible del panorama actual de lascomunicaciones personales; sin embargo, hay que decir que los estándares sobre el tema siguenestando abiertos y que existe una mejora continua en los sistemas.

CONTROL DESERVICIO YMOVILIDAD

RED DE SEÑALIZACIÓN

MSDP(B) MSDP(LE) MSDP(TX)

MSCP(P/B) MSCP(LE) MSCP (TX)

MT BTS CSS(P/B) LE TX

RED DE ACCESO

RED FIJA

INFRAESTRUCTURADE CONMUTACIÓNBÁSICA

DATOS

P/B: Public/Business

MT: Mobile TerminalBTS: Base Transceiver StationCSS Cell Site SwitchLE: Local ExchangeTX: Transit ExchangeMSCP: Mobile and Service Control PointMSDP: Mobility and Service Data Point

MCPN(MT, BTS, CSS, MSCP,MSDP)

Fig. 11.14 Arquitectura de la red UMTS (según el proyecto MONET del programa RACE, UE)


Gestión de red154

ISNDN

ISNDn

ISNDn ISNDnISNDn

ISNDn

ISNDn

ISNsISNs ISNs ISNsISNs ISNs ISNs ISNsISNs

ISNI

Fig. 11.15 Estructura jerárquica y distribuida de bases de datos (MSDP) en la red fija UMTS (según el proyectoMONET del RACE)


12. Gestión en Internet 155

12 Gestión en Internet

En este capítulo se aborda la gestión con la familia de protocolos SNMP, actualmente laconfiguración de gestión más extendida y propia de las redes con pilas de protocolos TCP/IP. No sepretenden estudiar las problematicas de la gestión global de Internet como red de redes [STA1,ROS1,2..].

12.1 Introducción

La red de redes Internet es actualmente una de las redes gestionadas de peor forma. Ello se debeprincipalmente a que no hay una calidad de servicio que se deba cumplir estrictamente entre losproveedores de servicio y los usuarios. Únicamente determinados operadores de red y proveedoresde servicio cobran unas cuotas a sus abonados y éstos pueden exigir un determinado servicio; sinembargo, esa condición no se puede cumplir para todos los servicios y redes. Un problema añadidoes que los protocolos actuales de Internet no permiten la flexibilidad de servicios ni la calidad deservicio que proporcionan redes más avanzadas como la RDSI de banda ancha, basada entecnología ATM. Recientemente han aparecido especificaciones del IETF para el desarrollo de laInternet 2 que si, bien mejoran determinados aspectos de servicio, tampoco acaban de ofrecer unasolución global satisfactoria a los abonados, sobre todo en cuanto se refiere a servicios interactivosen tiempo real.

A pesar de todo lo anterior, los protocolo TCP/IP y la red Internet están ampliamente extendidospor la mayoría de países desarrollados y constituyen la red por antonomasia en la mayor parte deéstos. Por otra parte, las empresas están introduciendo recientemente este tipo de tecnología deforma masiva en sus redes, de forma que cada vez dependen más de su buen funcionamiento. Deahí se deduce que si se considera la gestión de red como esencial, entonces deba de implantarse entodos los recursos de una red. Esto trae consigo una serie de consecuencias y es que el impacto deañadir gestión de red en los nodos debe ser el mínimo posible, de forma que la complejidadalgorítmica y de comunicaciones debe recaer en los procesos gestores (con el uso de plataformas degestión de elevadas prestaciones). Esto último no siempre se cumple en realidad: baste decir queentornos de gestión como el basado en el protocolo CMIP que permitiría obtener mejoresrendimientos en estos tipos de redes son suplantados generalmente por entornos más simples ybaratos como el basado en SNMP (Simple Network Management Protocol) que generan a menudoun tráfico de señalización excesivo.


Gestión de red156

12.2 Evolución

Las primeras aproximaciones a la gestión de red en Internet aparecieron en marzo de 1987 con unaserie de protocolos como el SGMP (Simple Gateway Monitoring Protocol), el HEMS (High-LevelEntity Management System) y el CMOT (versión de CMIP sobre TCP). Estos protocolos de gestión seocupaban básicamente del buen funcionamiento de los nodos de encaminamiento centrales delconjunto de redes Internet.

Posteriormente, en febrero de 1988, se produjeron una serie de revisiones para actualizar el protocoloSGMP, que dieron lugar a un incipiente SNMP. Más a largo plazo, existía la versión del CMOT comoalternativa. No fue hasta el agosto de 1988 cuando aparecieron realmente las primerasrecomendaciones del SNMP, así como de la SMI y MIB correspondientes. Desde el principio elprotocolo SNMP tuvo mucho éxito, si bien no dejaba de ser un protocolo de monitorizaciónesencialmente simple. Hubo en marzo de 1991 nuevas revisiones del entorno, que dieron lugar a unanueva especificación de base de datos denominada MIB II. Fue a partir de ahí que diversos fabricantesse dedicaron a la obtención de MIBs particulares que permitían la compatibilidad entre plataformas degestión en entornos de red heterogéneos, dado que SNMP era esencialmente un protocolo abierto.Posteriormente, en mayo de 1993, el grupo IETF sacó una nueva versión más completa del protocolo,denominada SNMPv2, con diversas versiones y con relativamente escaso éxito. Finalmente, en elverano de 1998, se anunciaban los primeros documentos relacionados con una nueva versión SNMP3más avanzada.

Puede decirse que, actualmente, el marco de trabajo del protocolo SNMP se basa esencialmente entres documentos:- Structure of Management Information (SMI): RFC1155.- Management Information Base (MIB): RFC 1156, RFC 1213.- Simple Network Management Protocol (SNMP): RFC 1157.

Cabe destacar otros documentos adicionales como el Concise MIB definitions: RFC 1212.

12.3 Estructura de la información de gestión

El objetivo de especificar una estructura de la información de gestión consiste en poder referenciar unrecurso en un sistema remoto. Pero para ello se requieren una serie de elementos, como un protocoloIP que nos permite llegar al sistema remoto, o el protocolo SNMP que permite llegar al proceso degestión de red del sistema remoto. Sin embargo, existe un problema: ¿cómo llegar a los recursos delsistema remoto?, para ello se va a utilizar un método común para nombrar a los objetos. Este métodousa los identificadores de objetos (Object Identifiers, OID).

Los OID no son más que una secuencia de enteros no negativos separados por un punto que forman unárbol. Este árbol, denominado de registro, está estandarizado a nivel mundial. Por ejemplo, el OID:1.3.6.1.1 identifica el objeto que se encontraría si, comenzando en el root, pasamos a la rama 3,después a la 6, a la 1 y finalmente a la rama 1.

El árbol está formado por ramas y nodos. En cada nodo existe una etiqueta consistente en un númeroentero y quizás un texto breve. Cada nodo puede tener nodos hijos (subordinados o sub-identifiers),



conectados a éste mediante líneas (ramas). El árbol comienza con un nodo inicial denominado rootque se puede extender hasta cualquier nivel de profundidad.

Estos OIDs son los que permiten alcanzar (nombrar) objetos mediante SNMP. Pero, ¿cómodevolvemos los valores de los objetos (respuesta a un get)?. Para que ello sea posible es necesarioconocer la estructura de los valores que nos pueden llegar desde los objetos, es decir la MacroOBJECT-TYPE, así como conocer el uso de una codificación por línea conocida de estos valores(sintaxis de referencia ASN1).

Fig. 12.1 Árbol de registro

12.4 Sintaxis ASN.1

La sintaxis ASN.1, que se representa mediante el término Syntax en la macro de tipo de objetos,define el tipo de datos que modela el objeto. La sintaxis abstracta se utiliza para describir tanto lasestructuras de datos que se intercambian las entidades del protocolo SNMP como la información degestión que contienen estas estructuras de datos [STE1].

Junto con el concepto de sintaxis abstracta, existe el concepto de sintaxis de transferencia. Ésta últimapermite, a partir de la definición de las estructuras de datos, utilizar una forma determinada detransmitir los datos a través de la red. La sintaxis de transferencia que se utiliza junto con la ASN.1son las reglas de codificación básicas (Basic Encoding Rules, BER).

Si bien se usa ASN.1 para la sintaxis abstracta, dado que esta notación es muy extensa, se restringe suuso para mantener la simplicidad en los agentes.

Una colección de descripciones ASN.1 relacionadas con un mismo tema se conoce como módulo. Sedefinen tres tipos de objetos con ASN.1:

iso (1) ccitt (2)

org (3)

internet (1)

dod (6)

directory (1) mgmt (2)

mib (1)

experimental (3)private (4)

enterprises (1)


Gestión de red158

- Tipos (types), que definen nuevas estructuras de datos.- Valores (values), que son realizaciones (variables) de un tipo.- Macros, que se utilizan para cambiar la gramática ASN.1.

Para saber en cada momento de qué tipo de objeto se trata, se utiliza la siguiente regla: losidentificadores de tipo comienzan en mayúscula, los identificadores de valor se escriben en minúsculay los identificadores de macros se escriben completamente en mayúsculas.

El tipo se representa con la siguiente sintaxis:

NombreDeTipo ::= TIPO

Un valor (una variable) lo hace de forma similar:

NombreDeValor NombreDeTipo ::= VALOR

Existen una serie de tipos permitidos para los objetos como los siguientes:

Tipos simples (Integer, Octet String, Object Identifier)

Tipos de aplicación

Tipos estructurados (Sequence, Sequence Of)

Subtipos (IpAddress, Counter, Gauge,...)

12.4.1 Tipos simples

Los tipos simples de ASN.1 que utiliza el protocolo de gestión son:

- INTEGER: tipo de dato que toma como valor un número entero.

Ejemplo:Estatus ::= INTEGER {up(1), down(2), testing(3)}que es lo mismo que decir que up = 1, down = 2 y testing = 3.

- OCTET STRING: tipo de dato que toma como valor 0 o más octetos. Cada byte puede tomar valoresentre 0 y 255. (código ASCII).

- OBJECT IDENTIFIER: tipo de dato que permite la identificación de objetos de gestión.

- NULL: tipo nulo. No se usa en el marco de gestión.

12.4.2 Tipos estructurados

Los tipos constructed (estructurados) que utiliza el protocolo de gestión son:

- SEQUENCE: tipo de dato para hacer listas.



<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 lossiguientes tipos de etiquetas:

UNIVERSALAPPLICATIONCONTEXT-SPECIFICPRIVATE

Los tipos etiquetados se construyen con la etiqueta y un número entero, por ejemplo:Opaque ::= [APPLICATION 4]

IMPLICIT OCTET STRING

Opaque es un tipo de dato que representa una codificación arbitraria.

12.4.4 Subtipos ASN.1

Los subtipos ASN1 refinan la semántica de un tipo ya existente, como:

- IpAddress: tipo que sirve para representar direcciones IP.IpAddress ::= [APPLICATION 0]

IMPLICIT OCTET STRING (SIZE (4))

- Network Address: representa direcciones de distintos protocolos.NetworkAddress ::= CHOICE {

internet IpAddress}

- Counter: entero no negativo, que se incrementa monotónicamente.Counter ::= [APPLICATION 1]

IMPLICIT INTEGER (0 .. 4.294.967.295)

- Gauge: entero no negativo, que se puede incrementar o decrementar con valor máximo.Gauge ::= [APPLICATION 2]



Gestión de red160

- TimeTicks: entero no negativo, que permite contar tiempo en centésimas de segundo desde algúninicio.TimeTicks ::= [APPLICATION 3]


Junto a estos tipos, es preciso definir también en las macro de los objetos gestionados un acceso y unestatus para así poder especificar las operaciones permitidas en éstos. El acceso (Access) define elnivel de acceso al objeto y puede especificarse uno de los siguientes: read-only, read-write, write-onlyy not-accesible. Como ejemplo, para tipos estructurados, no puede accederse a una tabla sino sólo aun campo concreto de la misma.

El status permite definir los requisitos de implementación del objeto distinguiéndose 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 paranombrar a los objetos gestionados. Este identificador puede estar en tres tipos de MIBs. Éstas sonactualmente las siguientes:

MIB estándar de Internetmib OBJECT IDENTIFIER

::= { internet mgmt(2) 1 }MIB experimental

experimental OBJECT IDENTIFIER::= { internet 3}

MIB privadasenterprises OBJECT IDENTIFIER

::= { internet private (4) 1 }

12.5 Bases de información de gestión (MIB)

Las bases de información de gestión (MIB) son un conjunto de objetos gestionados de un recurso quese publican para ofrecer interoperabilidad de gestión. Estos objetos se organizan en grupos, según seasu temática. La red se estructura de forma que los nodos deben soportar grupos enteros.

Actualmente existen los siguientes tipos de MIBs: las estándares, que son la MIB-I y MIB-II; lasexperimentales, con grupos en fase de desarrollo; y, finalmente, las privadas, que incorporan lainformación de los diversos fabricantes de equipos.

A continuación, se presenta la plantilla de la macro de tipo de objeto utilizada en la MIB y la plantillade la estructura de información de gestión (SMI).

IMPORTS ObjectName FROM RFC1155-SMI DisplayString FROM RFC1158-MIB;

OBJECT-TYPE MACRO ::=



BEGIN TYPE NOTATION ::= -- must conform to -- RFC1155's ObjectSyntax "SYNTAX" type(ObjectSyntax) "ACCESS" Access "ESTATUS" Estatus DescrPart ReferPart IndexPart DefValPart VALUE NOTATION ::= value (VALUE ObjectName)

Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Estatus ::= "mandatory" | "optional" | "obsolete" | "deprecated"

DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty

ReferPart ::= "REFERENCE" value (reference DisplayString) | empty

IndexPart ::= "INDEX" "{" IndexTypes "}"| empty

IndexTypes ::= IndexType | IndexTypes "," IndexType

IndexType ::= -- if indexobject, use the SYNTAX -- value of the correspondent -- OBJECT-TYPE invocation value (indexobject ObjectName) -- otherwise use named SMI type -- must conform to IndexSyntax below | type (indextype)

DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}" | empty

END

IndexSyntax ::= CHOICE { number INTEGER (0..MAX), string OCTET STRING, object OBJECT IDENTIFIER, address NetworkAddress, ipAddress IpAddress }

Fig. 12.2 Macro de Object-Type del RFC 1212


Gestión de red162

RFC1155-SMI DEFINITIONS ::= BEGIN

EXPORTS -- EVERYTHING internet, directory, mgmt, experimental, private, enterprises, OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax, ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque;

-- the path to the root

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 }

-- definition of object types

OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax) "ACCESS" Access "ESTATUS" Estatus VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Estatus ::= "mandatory" | "optional" | "obsolete" END

-- names of objects in the MIB

ObjectName ::= OBJECT IDENTIFIER

-- syntax of objects in the MIB

ObjectSyntax ::= CHOICE { simple SimpleSyntax,

-- note that simple SEQUENCEs are not directly -- mentioned here to keep things simple (i.e., -- prevent mis-use). However, application-wide -- types which are IMPLICITly encoded simple -- SEQUENCEs may appear in the following CHOICE

application-wide ApplicationSyntax}

SimpleSyntax ::= CHOICE { number INTEGER,



string OCTET STRING, object OBJECT IDENTIFIER, empty NULL }

ApplicationSyntax ::= CHOICE { address NetworkAddress, counter Counter,

gauge Gauge,

ticks TimeTicks, arbitrary Opaque

-- other application-wide types, as they are -- defined, will be added here }

-- application-wide types

NetworkAddress ::= CHOICE { internet IpAddress }

IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4))

Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)

Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)

TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value,IMPLICIT OCTET STRING -- "double-wrapped"

END

Fig. 12.3 Estructura de la información de gestión (SMI, RFC 1155)

Cada objeto se describe utilizando la macro OBJECT-TYPE. Cada objeto se descompone en una seriede campos. A continuación se describen brevemente los campos obligatorios:

- Descriptor: nombre del objeto- Value: nombre del objeto en forma de OBJECT IDENTIFIER- Syntax: especifica el tipo de dato del que se trata- Access: indica el nivel máximo de acceso (lectura, escritura,.)- Status: muestra la vigencia de la definición del objeto- Description: se trata de un texto que describe el significado del objeto.

Existen también estos campos opcionales:

- Units: unidades asociadas con el tipo de dato (p.e. segundos)


Gestión de red164

- Reference: se nombra en caso de haber algún objeto asociado- Index/Augments: ofrecen medios para identificar variables- Defval: recomendación sobre la creación de variables.

12.5.1 MIB-I

La MIB-I constituye la primera MIB normalizada. Está formada con objetos de la torre de protocolosde TCP/IP. En la tabla se especifican los grupos que la forman, con el número de objetos que formacada grupo y una breve descripción de éstos.

Grupo Número Propósitosystem 3 El propio sistemainterfaces 22 Interfaces de redat (adress translation) 3 Correspondencia de dirección IPip 33 Protocolo interneticmp 26 P. de mensaje de control internettcp 17 P. de control de transmisiónudp 4 P. de datagrama de usuarioegp 6 P. de pasarela exterior

114

Tabla 12.1 Esquema de grupos de la MIB-I

12.5.2 MIB-II

En la MIB-II se realizaron una serie de modificaciones sobre la primera versión. Entre éstas se halla lade la tabla address translation que se desestimó. También se define un nuevo grupo para cada tipoespecífico de interfaz, así como un nuevo grupo con objetos de SNMP.

Grupo Número Comentariossystem 7 eran 3interfaces 23 eran 22at 3 serán 0ip 38 eran 33icmp 26 sin cambiotcp 19 eran 17udp 7 nueva tablaegp 18 expansión de tablatransmission 0 nuevosnmp 30 nuevo

171

Tabla 12.2 Esquema de grupos de la MIB-II



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 errorsin their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc."


Gestión de red166

::= { 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 theIP 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., ClassE). For entities that are not IP Gateways and therefore do not forward datagrams, this counterincludes 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 finalIP destination, as a result of which an attempt was made to find a route to forward them to that finaldestination. In entities that do not act as IP Gateways, this rate will include only those packets thatwere 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 datagramsreceived 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 problemswere encountered to prevent their continued processing, but which were discarded (e.g., for lack ofbuffer space). This counter does not include any datagrams discarded while awaiting re-assembly." ::= { iP 7 }

ipDatagramsReceivedDeliveredPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION



"Datagrams Received Delivered/sec is the rate that input datagrams are successfully deliveredto 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 localIP user-protocols (including ICMP). That this counter does not include any datagrams counted inDatagrams 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 problemswere encountered to prevent their transmission to their destination, but which were discarded (e.g., forlack of buffer space.) This counter would include datagrams counted in Datagrams Forwarded if anysuch 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 routecould be found to transmit them to their destination. This counter includes any packets counted inDatagrams 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 thisentity are received." ::= { iP 12 }

ipFragmentsRe-assembledPerSec OBJECT-TYPE SYNTAX Counter ACCESS read-only ESTATUS mandatory DESCRIPTION


Gestión de red168

"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-assemblyalgorithm (for whatever reason: timed out, errors, etc.) This is not necessarily a count of discarded IPfragments since some algorithms (notably RFC 815) can lose track of the number of fragments bycombining 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 thisentity." ::= { 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 theyneeded to be fragmented at this entity but could not be, e.g., because their `Don't Fragment' flag wasset." ::= { 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 resultof 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 deInternet. Actualmente existen MIBs para:



IEEE 802.4 Token Bus (RFC 1230)IEEE 802.5 Token Ring (RFC 1231)IEEE 802.3 Repeater Devices (RFC 1368)Ethernet (RFC 1398)FDDI (RFC 1285)RMON (RFC 1271)Bridges (RFC 1286)...Actualmente el RFC 1398 correspondiente a la MIB de Ethernet ya es estándar, con lo que pasará adepender de la MIB de transmisión. Posteriormente todas estas MIB se irán estandarizando,complementando a la MIB-II.

12.5.4 MIBs privadas

Las MIB privadas corresponden a las MIBs de productos específicos, generadas por los distintosfabricantes, y añaden funcionalidad a las MIB estándar. Generalmente, los fabricantes las hacenpúblicas, poniéndolas accesibles por Internet (deposito común en venera.isi.edu). Por ejemplo, sepueden encontrar MIBs para productos, de Cabletron, Synoptics, Proteon, ATT, Cisco, etc.

12.6 Simple Network Management Protocol (SNMP)

El protocolo SNMP (RFC 1157) surge a partir del protocolo SGMP para gestión de routers IP. ElSimple Network Management Protocol (SNMP) es un protocolo de aplicación que ofrece servicios degestión de red al conjunto de protocolos Internet. SNMP define una arquitectura basada en cliente-servidor. El programa cliente (llamado el gestor de red) realiza conexiones virtuales a un programaservidor (llamado el agente SNMP) ejecutando en un dispositivo de red remoto. La base de datoscontrolada por el agente SNMP se denomina Management Information Base (MIB), y es un conjuntoestándar de valores estadísticos y de control de status. SNMP permite también extensiones de estaMIB a agentes particulares para el uso de MIB privadas.

Los mensajes enviados por el cliente (gestor de red) a los agentes SNMP están formados deidentificadores de objetos MIB, junto con instrucciones a fin de cambiar u obtener un valor.

Estación degestión de red

Conjuntode MIBs

Conjuntode MIBsConjunto

de MIBs

Ordenador Router Servidor determinales

Conjunto de recursos

SNMPSNMP

SNMP

Agente AgenteAgente

Fig. 12.4 Arquitectura de un sistema de gestión SNMP


Gestión de red170

La torre de comunicaciones SNMP se apoya en la estructura de protocolos TCP/IP de Internet y quese muestra en la figura siguiente.

SNMP RFC 1157

UDP RFC 768

IP RFC 791 ICMP RFC 782

Token Ring Ethernet, FDDI

Nivel 7

Nivel 4

Nivel 3

Nivel 1 y 2

Fig. 12.5 Torre de protocolos en Internet

A pesar de la fácil integración de SNMP en los protocolos UDP/IP, es posible montar SNMP sobreotras torres de comunicación (Ethernet, IPX, OSI, CLNS). Sin embargo, a la hora de elegir unainfraestructura de comunicaciones, hay que tener en cuenta la interoperabilidad, el nivel de transportey el uso de un servicio orientado o no a conexión.

Entre las características principales del protocolo SNMP se puede destacar el hecho de que es unprotocolo de gran flexibilidad y que permite una gran extensibilidad a todo tipo de redes. A pesar dedefinirse como un protocolo simple resulta ser un protocolo difícil de implementar para el diseño deaplicaciones, dada la complejidad intrínseca de las aplicaciones que debe diseñar. Por otra parte, encuanto a rendimiento, la eficiencia del protocolo para la transmisión de información es baja, ya que setrata de una arquitectura basada en polling de acuerdo con una estructura de funcionamientocentralizada. El hecho de que se trate de una gestión conducida por polling determina que el gestorpregunte periódicamente a la información del agente sobre los recursos gestionados, de forma que esel gestor el responsable de monitorizar los recursos. Ello presenta la ventaja de que el gestor puede sersimple, pero presenta la desventaja de que la gestión de tráfico puede ser importante.

SNMP, si bien es un protocolo abierto, también puede utilizar un agente proxy para gestionar sistemaspropietarios. Cabe destacar también que en SNMP la comunicación con los agentes no está orientada aconexión y que al ser un protocolo basado en UDP/IP no garantiza la llegada de los mensajes TRAP adestino, con lo que tienen que integrarse mecanismos especiales en capas superiores para evitar estasdeficiencias.



12.6.1 Operaciones de SNMP

El protocolo SNMP es eminentemente un protocolo simple y de monitorización. A continuación, sedefinen los tipos de operaciones permisibles con sus objetos:

- GetRequest: petición de valores específicos de la MIB.- GetNextRequest: proporciona un medio para moverse por la MIB. Petición del objeto siguiente a unodado de la MIB (orden lexicográfico).- GetResponse: devuelve los valores solicitados por las operaciones anteriores.- SetRequest: permite asignar un valor a una variable. Debido a posibles problemas de seguridad estafunción suele estar desactivada.- Traps: permite a los agentes informar de sucesos inusuales. (p.e. ColdStart, WarmStart, LinkDown,LinkUp, AuthenticationFailure, EGPNeighborLoss, EnterpriseSpecific).

En la figura 12.6 se muestran las relaciones que existen entre los diversos tipos de primitivas y losnodos de comunicaciones, es decir, los papeles de gestor (lado de la izquierda) y agentes (ladoderecho). Junto a los mensajes anteriores destacan las Traps como mensajes especiales queespecifican alarmas o sucesos inusuales. Estas Traps suelen variar mucho en cada entorno,dependiendo de la implementación que realice el fabricante.

El uso de MIBs privadas junto con mensajes tipo Trap permite la respuesta del sistema a alarmasespecíficas de los equipos de cada fabricante. Además, se posibilita la integración de agentes enmultitud de dispositivos para su gestión, tales como puentes, encaminamientores, pasarelas, etc. Lasdefiniciones de las variables MIB soportadas por un agente en particular se incorporan en ficherosdescritos en una notación especial denominada Abstract Syntax Notation (ASN.1) a fin de que puedanser utilizables por programas cliente de gestión de red de otros fabricantes.

A continuación se describe la secuencia de eventos que se produce en la emisión y recepción de unmensaje SNMP por parte de una entidad de gestión:

Secuencia de transmisión de un mensaje SNMP

1. Construcción de la PDU, usando estructuras ASN.1.2. La PDU se procesa por el servicio de autenticación junto a las direcciones correspondientes.3. La entidad de protocolo construye el mensaje, consistiendo de una vesión de campo, el nombre dela comunidad y el resultado del paso dos.4. Este nuevo objeto ASN.1 es entonces codificado, usando las reglas de codificación básicas y pasadoal servicio de transporte.En la práctica, las autentificaciones no se invocan.

Secuencia de recepción de un mensaje SNMP

1. Chequeo básico de la sintaxis del mensaje, descartándolo si es erróneo.2. Verificación del número de versión. Se descarta el mensaje si no es coherente.3. La entidad de protocolo pasa al usuario la porción PDU del mensaje y las direcciones de transportede emisor y receptor al servicio de autenticación.

3.1 Si la autenticación falla, el servicio de autenticación señaliza a la entidad de protocolosSNMP, para que genere una Trap y descarte el mensaje.


Gestión de red172

3.2 Si la autenticación tiene exito, el servicio de autenticación devuelve la PDU en la forma deobjeto ASN.1 definido en RFC 1157.

4. La entidad de protocolo hace un chequeo básico de la sintaxis del mensaje, descartándolo si eserróneo. En cualquier caso, la comunidad nombrada con la adecuada política de acceso SNMPseleccionada finalmente procesa la PDU.

Obtener valores(Get values)

Obtener próximosvalores(Get-next values)

Asignar valores(Set values)

Enviar Trap(Send Trap)

Trap PDU

SetRequest PDU

GetResponse PDU

GetNextRequest PDU

GetResponse PDU

GetRequest PDU

GetResponse PDU

Fig. 12.6 Secuencias de PDUs en el protocolo SNMP

Versión Comunidad SNMP PDU

Tipo PDU Petición id 0 0 Campos variables

error-estatus error-índiceTipo PDU Petición id Campos variables

Tipo PDU empresa direcciónagente

Trapgenérico

Trapespecífico

Time-stamp Campos variables

Nombre 1 Valor1 Nombre2 Valor2 Nombre n Valor n...

Mensajes SNMP

GetRequest PDU, GetNextRequest PDU, y SetRequest PDU

GetResponse PDU

Trap PDU

Campos variables

Fig. 12.7 Formatos SNMP



12.6.2 Codificación para la transferencia de la información de gestión: BER

Según se ha explicado en la sección 12.4, la información de gestión se define a partir de la ASN.1.Ésta establece que para la codificación se utilizarán las BER (Basic Encoding Rules). Las BERpermiten traducir una estructura de datos cualquiera en una secuencia de bytes y viceversa. Las BERno son más que un algoritmo recursivo que puede producir una secuencia de bytes a partir decualquier valor ASN.1. El protocolo SNMP sólo utiliza un subconjunto de estas reglas.

Las BER codifican los tipos utilizando los siguientes tres campos de longitud arbitraria:

- Tag: indica el tipo de ASN.1- Length: indica el tamaño de la codificación del valor que sigue- Value: indica propiamente la codificación del valor.

12.7 Configuración y rendimiento de una red gestionada por el protocolo SNMP

La gestión de redes se basa en la gestión de nodos, entendiendo como tales abstracciones de unaentidad de red física como routers, hubs, ordenadores personales, impresoras, etc. Sin embargo, paraanalizar más en detalle la configuración y el rendimiento en la gestión, se tienen que determinar lasdimensiones de los correspondientes parámetros:

- número de estaciones- número de redes- número de segmentos- número de nodos- número de interfaces- número de gateways- número de nodos gestionados.

De hecho, cada nodo tiene una o más interfaces que se registran en la base de datos. La carga degestión puede determinarse a partir del número de nodos gestionados más el número de interfacesgestionadas para cada nodo. A partir de ahí, considerando el número de redes y de segmentos sedetermina finalmente el número de objetos que se deben gestionar.

Para calcular el número de objetos que se deben gestionar, se tiene en cuenta que el número deinterfaces por nodo suele ser único, y que experimentalmente puede considerarse un promedio de 2.4objetos por nodo.

Los requerimientos de recursos del sistema de gestión pasan por cubrir las funcionalidades demonitorización y de descubrimiento básicas (Discover); las funcionalidades de presentación (display);las funcionalidades de eventos de acción y de colección de datos; finalmente, funcionalidades relativasa gestión distribuida y de bases de datos específicas. Todas estas funciones requieren de espacio dememoria estándar, memoria swap, espacio de disco y potencia de cálculo. Se suele estimar a menudoque el espacio de memoria swap sea como dos veces el de la memoria estándar.

El uso del protocolo SNMPv2 permite diversas configuraciones de gestión, y puede integrarestaciones de gestión con estaciones de sondeo de datos y con cónsolas de gestión (sesiones delprograma de gestión). El proceso de sincronización de la información puede ser por ejemplo, de unos


Gestión de red174

3 min. para configuraciones de una estación de gestión, hasta unos 15 min. para configuraciones de 5estaciones.

El uso de filtros para los procesos de obtención de información, de descubrimiento de los nodos(Discovery), la topología y los mapas, permite reducir mucho las necesidades de memoria y la cargadel sistema de gestión, cosa que repercute en una mayor concentración de recursos para los objetosque realmente interesa gestionar.

12.7.1 Interrogación (polling) de estatus de dispositivos.

Cada interrogación de estatus IP genera alrededor de 4 a 5 pequeños paquetes en una LAN local(debido a los ARPs) y 2 paquetes en las LAN remotas. El intervalo de interrogación de estatus sueleestar por defecto en torno a los 5 min. (300 s). Este tiempo viene acotado por el tiempo que tarda unpaquete en recorrer la red (ICMP echo request) a la interfaz más lejana.

12.7.2 Interrogación (polling) de descubrimiento (Discovery)

La interrogación de descubrimiento IP requiere de 10 a 100 paquetes por nodo, dependiendo del tipode nodo. Los routers que soportan SNMP pueden requerir 100 paquetes, mientras que routers degrandes redes pueden requerir centenares de paquetes. Los dispositivos que no soportan SNMPrequieren de unos 3 paquetes. Las frecuencias de chequeo de los nodos dependen a menudo de lainformación previa disponible.

12.7.3 Interrogación (polling) de configuración de topología

El número de paquetes generados por esta interrogación depende en gran manera de cuántas interfacesen la red comunican a través de dispositivos que soportan la MIB Bridge (RFC 1493). En un entornocon gran cantidad de encaminamientos o conmutado se puede esperar la generación de 10 a 20paquetes por interfaz en la red. Por defecto, la interrogación de la red se completa cada 4 horas.

12.7.4 Interrogación (polling) de chequeo de configuración de dispositivo

Durante la interrogación de chequeo de configuración se generan entre 20 y 100 paquetes por nodo,dependiendo del tamaño de la información que se solicita. Este chequeo se completa por defecto unavez por nodo y se realiza para cada día.

12.7.5 Interrogación (polling) de estatus de estación de sondeo

Requiere de aproximadamente 20 paquetes por estación de sondeo. La frecuencia de este tipo deinterrogación se configura a partir de cada estación de sondeo, siendo la frecuencia por defecto de unacada 5 minutos.

12.7.6 Otras aplicaciones

Si se utilizan otras estaciones para la recolección de datos, monitorizar variables MIB, chequearniveles de disparo, crear gráficos, conectar a sistemas remotos, etc. consecuentemente se generatráfico extra en la red.



12.8 Marco administrativo

Para una gestión con SNMP adecuada se define un nombre de comunidad (community) que afectatanto al agente como al conjunto de gestores que lo administran, y un perfil de comunidad quedelimita las propiedades así como el modo de acceso al sistema. De esta forma, la comunidad puedeser pública (public), es decir, de libre acceso. Esta información se almacena en cada MIB (Fig. 12.8).De esta forma, una comunidad es una relación entre un agente y gestores y el nombre de comunidades una cadena de octetos transmitida en los mensajes SNMP.

Para la determinación de políticas de autentificación y autorización se trabaja con autentificaciónsimple, en la que el nombre de comunidad se transmite en claro; de ahí la necesidad de ampliar laseguridad del entorno de gestión mediante otros servicios de seguridad. En cuanto a la autorización,cada comunidad tiene asociado una vista (conjunto de objetos), de forma que para cada objeto sedefine un modo de acceso: read-only, read-write. Finalmente, el nombre de comunidad junto al perfilde comunidad marca la política de acceso al sistema.

Agente SNMP

Conjunto de gestores SNMP

Comunidad SNMP (nombre comunidad)

Política de acceso SNMP

MIB SNMP

Modo de acceso SNMP

Perfil de comunidad SNMP

Fig. 12.8 Conceptos administrativos

12.9 Configuraciones para el uso del protocolo SNMP en entornos heterogéneos

Las diversas configuraciones entre sistemas de gestión distintos y/o de diferentes fabricantes en unared limitan el acceso a la información de las bases de datos de gestión (MIBs). A continuación sedescriben algunas de las configuraciones de redes formadas con nodos heterogéneos más utilizadas.

12.9.1 Sistemas de gestión de red basados en SNMP emergentes

Las aplicaciones de gestión SNMP de distintos fabricantes pueden actuar sobre la información degestión de tipo público (MIB2) común de todos los nodos de la red; sin embargo, cada una de ellassólo puede entender la información de gestión de los nodos que pertenezcan a la misma marca. Esto sedebe a que son MIBs propietarias. Por otra parte, la base de información definida por RMON sueletambién ser visible por las aplicaciones basadas en SNMP, complementando la gestión de la red.


Gestión de red176

SNMP SNMP

SNMP SNMP

SNMP SNMP

MIBpropietario

StandardMIB

RMON

MIBpropietario

EstándarMIB

RMON

Sistemasgestionados



Aplicaciones deplataforma ygestión

Aplicaciones deplataforma ygestión

Sistemas degestiónde red

Fig. 12.9 Esquemas de actuación en redes con sistemas de gestión homogéneos

12.9.2 Sistemas de gestión de LANs heterogéneas

En el caso de disponer de sistemas de gestión diferentes en la misma red, en principio tanto lainformación de gestión como los protocolos de gestión funcionan independientemente. Actualmente,las plataformas de gestión más evolucionadas permiten compatibilidad entre agentes de distintosestándares como SNMP y CMIP.

Tal como se observa en la figura 12.10, el protocolo CMIP pasa a denominarse CMOT en entornos deredes TCP/IP, y CMOL en versión simplificada para la gestión de redes de área local.

Gestor CMISEGestor SNMP

SNMP

Pila de protocolos OSIcon CMIP o CMOL

SNMP/OSICMOT

Agentes de objetosgestionados TCP/IP

Agentes de objetosgestionados OSI

SNMP: protocolo de gestión de red simpleOSI: interconexión de sistemas abiertos

CMIP: protocolo de información de gestión comúnCMISE: elemento de servicio de información de gestión común

CMOT: protocolo de información de gestión común sobre TCP/IPCMOL: protocolo de información de gestión común sobre LLC

Fig. 12.10 Esquemas de actuación en redes con sistemas de gestión heterogéneos



12.9.3 Valoración crítica de las MIB en SNMP

A pesar de ser las MIBs unas bases de datos para gestión de red muy utilizadas y de fácil uso,presentan diversos problemas respecto a otros entornos de gestión más evolucionados. Entre losaspectos negativos considerados figuran los siguientes:

- Las comunicaciones datagrama son ineficientes para la obtención de grandes cantidades deinformación de las bases de datos.- No existen mecanismos para la obtención agregada de datos de las MIB.- No existen mecanismos de compresión de la información en la fuente.- No existen mecanismos de correlación de la información en la fuente (p.e. la unión de tablas SNMP).- No existe control de acceso a MIB.- La estructura estática de la información en las MIB limita la manipulación y la reconfiguracióndinámica, aunque se puede hacer uso de MIBs con información aportada por fabricantes,...- Existe gran heterogeneidad en el modelo sintáctico/semántico.- No hay modelo explícito de control (p. e. en invocaciones remotas).- No hay mecanismos para representar y manipular relaciones.- El modelado de sistemas jerárquicos puede ser complicado.

12.10 Conclusiones sobre SNMP

Entre las ventajas del protocolo SNMP se pueden considerar las siguientes:

- Es un estándar de mercado.- Es simple, fácil de usar.- Modelo útil para el acceso a datos de gestión de la red.- Acceso y organización eficientes de los datos gestionados.- Independencia del entorno de comunicaciones.- Capacidades generales de monitorización y control.

Respecto a los inconvenientes más importantes se pueden enumerar los siguientes:

- Limitaciones en el mecanismo de obtención de información:Falta de obtención selectiva de información.

- No dispone de controles de gestión.- Limitaciones de las capacidades de modelado de datos:

MIB estáticaCorrelación de datos difícilModelados de sistemas complejos.

12.11 Comparación entre los protocolos CMIP y SNMP

Finalmente, a título comparativo, se presenta una relación de temas donde se muestran similitudes ydiferencias entre los protocolos CMIP y SNMP.


Gestión de red178

En cuanto a modelo de datos de instrumentación, el protocolo SNMP se representa a través devariables, tablas, Traps etc. mientras que CMIP utiliza un modelo de objetos extendido. Respecto aidentificación de nombres de datos gestionados, SNMP hace uso de un árbol de directorios estático yCMIP hace uso de un árbol de directorios dinámico.

En relación a la representación de datos uniforme, SNMP utiliza un número mínimo de tipos de datosASN.1, mientras que CMIP hace uso de un rango extendido de tipos ASN.1. También, respecto alsoporte de transporte de primitivas query/responses de gestión, SNMP utiliza datagrama, con lamáxima independencia de la elección de transporte, mientras que CMIP utiliza conexiones con fuertedependencia del estándar OSI.

A nivel funcional, el protocolo CMIP obtiene un mayor rendimiento de los mensajes enviados ya quese reduce la señalización respecto al protocolo SNMP. CMIP también es más seguro que el SNMP.

A nivel operacional, el protocolo CMIP se basa en una arquitectura jerárquicamente distribuida, lo quepermite que el número de objetos supervisados sea mayor que en el protocolo SNMP que, al ser detipo centralizado, viene limitado por la capacidad tecnológica de las plataformas de gestión. De todasformas, hay que decir a favor del protocolo SNMP que es más simple y que el personal requerido parasu mantenimiento se reduce.

A nivel de implementación, hay que decir que un agente CMIP ocupa unos 400 Kbytes o másmientras que un agente SNMP ocupa de 20 Kbytes a 60 Kbytes. También, el coste de procesado y dela misma aplicación es más elevado en una plataforma CMIP.

En cuanto al soporte por parte de fabricantes, el protocolo SNMP es el utilizado por la gran mayoríade fabricantes y clientes, y existe una multitud de productos comerciales. Los gastos demantenimiento también suelen ser menores en SNMP al ser más simple y tener una mayor basecomercial.

Finalmente, el protocolo CMIP permite más extensiones, es más escalable, permite la herencia deatributos y es más flexible que el protocolo SNMP.

12.12 SNMPv2

Este protocolo de gestión que se definió en 1993, es una versión más avanzada del SNMP. SNMPv2aporta una serie de ventajas respecto a la primera versión, entre las cuales pueden destacarse:

- Permite una mayor eficiencia en la transferencia de información.- Admite mecanismos de seguridad como la autentificación y el cifrado frente al SNMP (noimplementados).- Permite la comunicación entre estaciones de gestión.- Parte de un modelo de comunicaciones extendido considerablemente.- Permite una señalización extendida de errores.- Permite el uso de varios servicios de transporte.

El sistema basado en SNMPv2 soluciona muchos de los problemas de su anterior versión, SNMP; sinembargo, su mayor complejidad está coartando su desarrollo.



Los mensajes enviados por la plataforma de gestión de red a los agentes SNMP están formados poridentificadores de objetos MIB junto con instrucciones, a fin de cambiar u obtener un valor.

12.12.1 Operaciones de SNMPv2

El protocolo SNMPv2, que incluye los mensajes de la primera versión SNMP, dispone de lossiguientes tipos de mensajes:

- GetRequest: petición de valores específicos de la MIB.- GetNextRequest: proporciona un medio para moverse por la MIB. Petición del objeto siguiente a unodado de la MIB (orden lexicográfico).- GetBulkRequest: petición de múltiples valores.- Response: devuelve los valores solicitados por las operaciones anteriores gestor a gestor o agente agestor).- SetRequest: permite asignar un valor a una variable. Debido a posibles problemas de seguridad estafunción suele estar desactivada.- InformRequest: transmite información no solicitada (gestor a gestor).- SNMPv2-Traps: permite a los agentes informar de sucesos inusuales (p.e. ColdStart, WarmStart,LinkDown, LinkUp, AuthenticationFailure, EGPNeighborLoss, EnterpriseSpecific).

Tipo PDU Petición id 0 0 Campos variables

error-status error-indiceTipo PDU Petición id Campos variables

Tipo PDU Campos variables

Nombre 1 Valor1 Nombre2 Valor2 Nombre n Valor n...

GetRequest PDU, GetNextRequest PDU, SetRequest PDU, SNMPv2 Trap PDU, InformRequest PDU

GetResponse PDU

GetBulkRequest PDU

Campos variables

Petición id No repet. Max. repet.

Fig. 12.11 Formatos de PDU para SNMPv2

Sin embargo, el hecho de su incompatibilidad con la versión SNMP y la mayor complejidad añadida alas plataformas están desestimando su futura implementación.

El desacuerdo en el consorcio sobre las recomendaciones acerca de seguridad propuestas en SNMPv2ha propiciado finalmente su incorporación en una nueva versión SNMPv3.


Gestión de red180

SNMP PDU

dstTime-stamp

..

.

Mensajes SNMP generales

Mensajes no seguros

Autenticados pero no privados

Privados pero no autenticados

Privados y autenticados

srcTime-stamp

PrivDst

PrivDst

PrivDst

PrivDst

PrivDst

AutInfo GrupoDst GrupoSrc

GrupoSrc SNMP PDUGrupoDst



GrupoSrc SNMP PDUGrupoDstFirma

Firma

Longitud 0 OCTET STRING

Longitud 0 OCTET STRING

Encriptado

Encriptado

Contexto

Contexto

Contexto

Contexto

ContextodstTime-stamp

srcTime-stamp

Fig. 12.12 Formatos de mensajes de SNMPv2

12.13 SNMPv3

El protocolo SNMPv3 es una evolución de la serie de modelos de gestión vistos anteriormente.SNMPv3 está aún en fase de especificación; sin embargo, se pueden describir algunas de lascaracterísticas en las que se está trabajando. Las áreas a las que SNMPv3 va enfocado son,primordialmente, mejorar la seguridad y la administración respecto a SNMPv2.

Respecto a la estructura de la información de gestión, la SMI está dividida en tres partes: definicionesde módulos, definiciones de objetos y definiciones de notificaciones. Las definiciones de módulos(macros ASN.1: MODULE-IDENTITY) se utilizan para describir semánticamente los módulos deinformación. Para las definiciones sintácticas y semánticas de objetos se usan macros ASN.1:OBJECT-TYPE. Las definiciones de notificaciones usan macros NOTIFICATION-TYPE y describentransmisiones no solicitadas de información de gestión.

Entre los tipos de datos que se incorporan a la SMI (RFC 1902) están:

- IMPORTS para permitir la especificación de items que se usan en un módulo MIB, pero definidos enotro módulo MIB.- MODULE-IDENTITY especifica una descripción e información administrativa para un móduloMIB.- OBJECT-IDENTITY y los OID se asignan para especificar un valor OID.- OBJECT-TYPE especifica el tipo de dato, estatus y la semántica de los objetos gestionados.- SEQUENCE es un tipo que permite asignar los objetos de una lista en una tabla.- NOTIFICATION-TYPE se especifica para construir una notificación de eventos.



En SNMPv3 se prevé también aumentar el mapeo de mensajes tipo SNMP a otros tipos de protocolosde transporte. Desde el punto de vista de arquitectura de gestión se extiende el nombrado de:

- Motores y aplicaciones.- Entidades (proveedores de servicio tales como motores en agentes y gestores).- Identidades (usuarios de servicio).- Información de gestión, incluido soporte para múltiples contextos lógicos.

Los cinco tipos de aplicaciones que se prevé asociar con un motor SNMP son: generadores decomandos, receptores de comandos (generadores de respuestas), originadores de notificaciones,receptores de notificaciones y envío de proxies.

Respecto a las mejoras en seguridad, SNMPv3 utilizará MD5 y algoritmos de Hash para firma digitaly proteger contra la modificación de la información proporcionando integridad de datos,autentificación de origen y de usuario.

12.14 Remote Network-Monitoring (RMON)

El Remote Network-Monitoring (RMON), especificado en 1994, define una MIB (que suplementa laMIB II) para permitir la monitorización remota, y proporciona al gestor de red información vitalacerca de la interconexión con otras redes.

Mientras que el protocolo SNMP se diseñó en función de una arquitectura de polling pasivo, elRMON permite al usuario el uso de agentes “inteligentes” que responden de acuerdo conacontecimientos excepcionales. Esto reduce el tráfico asociado con la red de gestión, mientras quepermite al equipo remoto alertar a la plataforma de gestión SNMP cuando ocurre algún problema.

Entre las características principales cabe destacar:- Operación off-line: pueden interrumpirse procesos de polling mientras el monitor sigue funcionandosiempre.- Monitorización preventiva: en caso de sistemas bien dimensionados, se puede enviar periódicamenteinformación de estatus de la red a fin de prevenir posibles problemas.- Detección de problemas y generación de informes: disposición de sondas activas.- Datos de valor añadido: el monitor de redes puede realizar análisis específicos de la información desu red que no son accesibles con métodos directos (sólo hasta nivel MAC).- Multiples gestores: RMON permite la estructura de plataformas gestoras dispuestas de formadistribuida y jerárquica.

El estándar RMON es un sistema de monitorización remota que está creciendo muy deprisa comosolución a problemas de gestión de red centralizada. Uno de sus principales alicientes es el deproporcionar una arquitectura distribuida, frente al carácter centralizado del protocolo SNMP.

Las funciones MIB asociadas a RMON1 entran dentro los siguientes grupos:

- Actividades a nivel de aplicación- Filter: mecanismo de selección de paquetes de acuerdo a un determinado criterio.- Packet capture: colección de paquetes y mecanismos de carga a través de criterios de filtrado.


Gestión de red182

- Events: mecanismo de control para acciones disparadas por una alarma.

- Estadísticas de host- Host: descubrimiento y estadísticas de hosts por direcciones MAC.- Host Top N: estadísticas ordenadas por dirección MAC.- Matrix: seguimiento de la conversación entre dos hosts.

- Otros grupos- Statistics: tráfico LAN acumulado y estadísticas de errores.- History: estadísticas de muestreo de intervalo para análisis de tendencias.- Alarms: niveles de disparo.- Token Ring: 4 parámetros de las redes token-ring.

En las figuras siguientes se realiza una comparación de los entornos de una red, gestionada con y sinsonda RMON.

• Red con sonda RMON (agente RMON): reduce el tráfico de gestión ya que analiza el tráfico, lasalarmas, etc. y procesa toda la información de la red, mandando únicamente los datossignificativos a la estación de gestión (p.e. estadísticas).

SondaRMON

Interconexión

Interconexión

Interconexión

SondaRMON

SondaRMON

Estación de gestión

Fig. 12.13 Esquema de redes con sonda RMON

• Red sin sonda RMON: se caracteriza por realizarse un polling continuo de la estación de gestiónal monitor. La estación de gestión ha de procesar toda la información lo que provoca un mayortráfico de gestión.



Interconexión

Interconexión

Interconexión

Analizadorde redes

Estación de gestión

Fig. 12.14 Esquema de redes sin sonda RMON

12.15 RMON 2

RMON2 aparece como especificación RFC en 1996 como una extensión de RMON. RMON2 añaderespecto a la versión uno, la decodificación de paquetes entre los niveles 3 y 7 del modelo OSI. Ellotrae consigo las siguientes consecuencias:

a) Una sonda RMON2 puede monitorizar tráfico de acuerdo con protocolos de nivel de red ydirecciones, incluido el Internet Protocol (IP). Esto permite a la sonda observar más allá de lossegmentos LAN, a los cuales está conectado, y ver el tráfico entrante/saliente a la LAN vía routers(nodos específicos). Aplicable a la gestión de interconexión de redes.

b) A causa de que la sonda RMON2 puede decodificar y monitorizar tráfico a nivel de aplicación, talcomo email, transferencia de ficheros, y protocolos WWW, la sonda puede grabar tráfico a y desdehosts para determinadas aplicaciones.

RMON2 introduce, además, dos nuevas funcionalidades que mejoran el protocolo RMON: el uso deobjetos indexados que no son parte de la tabla que éstos indexan, y el uso de indexado de filtrotemporal.

Los grupos MIB que incorpora RMON2, respecto a la versión anterior, son los siguientes:

- Protocol Discovery- Protocol Distribution- Adress Mapping- Network Layer Host- Network Layer Matrix- Application Layer Host- Application Layer Matrix- User History- Probe Configuration- RMON Conformance


Gestión de red184

12.16 RMON 3

RMON 3 prevé extender el entorno RMON a las redes de área extendida (WAN). Todavía está en fasede especificación.


13. Gestión distribuida 185

13 Gestión distribuida

Las arquitecturas de red basadas en gestión distribuida son las que permiten la obtención de mejoresrendimientos en grandes redes. La gestión de un gran número de nodos no puede solucionarsecorrectamente 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 paradistribuir recursos a través de redes heterogéneas. Está organizada en función de la relación cliente-servidor [KNO1].

Existen tres grupos principales de funcionalidad DCE:

1. Remote Procedure Calls a servidores (DCE-RPC), utilizado también en DCOM.

2. Servicios de seguridad entre servidores y clientes

3. Localización de servidores y clientes dentro de una red.

La unidad de organización principal de la DCE es la celda, que consta de recursos, sistemas y usuariosque tienen un propósito común y comparten actividades DCE comunes. Típicamente una celdacontiene hosts y servidores conectados a una red de área local (LAN).

13.1.1 Componentes principales de DCE

El modelo de distribución está basado en su software RPC (Remote Procedure Call) y utiliza unmodelo de distribución orientado a procedimiento. Permite a clientes/servidores comunicarse a travésde diálogos de peticiones/respuestas (una petición iniciada por un cliente). El cliente no tieneconstancia de la posición del servidor. Es el concepto clave de procesamiento distribuido.

Existen una serie de componentes principales que conforman la arquitectura DCE: entre ellos se puedecitar los threads (enlaces). Los enlaces comparten recursos más que copiarlos (excepto para pilas yregistros que están separados para cada enlace). Se utilizan también los servicios de directorio, que


Gestión de red186

sirven para localizar recursos en una red de redes. Para ello usa el nombrado de la notación de X.500 yespecíficas de DCE. Así, se tienen:

- Cell Directory Service (CDS): controla los servicios de directorio dentro de una celda.- Global Directory Service (GDS): controla los servicios de directorio fuera de una celda.

Otros componentes de la arquitectura DCE son los siguientes:

- Distributed Security Service (DSS): proporciona servicios de seguridad de una manera centralizadaen lugar de realizar procedimientos de autentificación entre cada host. Proporciona autentificación,autorización, integridad de datos y privacidad de datos.

- Distributed Time Service (DTS): proporciona un medio de sincronización de actividades entre hostsy red.

- Distributed File Server (DFS): permite acceder ficheros en hosts entre una red o redes. Proporcionaficheros de back-up y servidores de back-up (si un servidor se pierde, otro puede realizar susactividades). También organiza servidores en grupos lógicos, llamados dominios administrativos,facilitando el trabajo con grandes redes. Así como el uso de herramientas de administración.

13.1.2 Restricciones en el uso de DCE

Entre las restricciones a la hora de acometer una gestión con DCE hay que decir que la librería deejecución de DCE debe ejecutarse en cada host (no importa si es servidor o cliente). La configuraciónmínima de una celda es de RPC, enlaces, CDS, DSS y DTS. Además, a los recursos puede accedersesólo después de una autentificación correcta.

13.1.3 Razones para escoger DCE

Entre las razones para la elección de DCE como arquitectura de gestión, se puede citar el hecho quepermite el desarrollo de aplicaciones independientemente de la red, sin tener que desarrollar funcionesgenéricas como RPC, enlaces, etc. Se trata, además, de un entorno coherente, basado en estándares: esun entorno de computación abierto y que permite la compartición transparente de ficheros. El hechode ser un entorno distribuido proporciona información independientemente de donde está almacenada,escondida la complejidad de la red, y se obtiene un conjunto integrado de servicios.

Además, DCE previene el acceso no autorizado a recursos, y para su implantación no se necesitan lascapacidades de un sistema orientado a objetos. Finalmente, DCE soporta comunicaciones síncronasentre servidores y clientes.

13.2 Distributed Management Environment (DME)

La Open Software Foundation (OSF) seleccionó un conjunto de tecnologías para integrar dentro de suDistributed Management Environment (DME). Esta tecnología, propugnada inicialmente por HP, escapaz de trabajar con cualquier sistema operativo y simplifica la gestión de sistemas distribuidos ystand-alone, reduciendo los costes para administración de sistemas.



Herramientasde desarrollo

Aplicaciones de gestión

Servicios de gestión Opción degestión dered(NMO)Servicios Objeto

Marco de actuación DCE con extensiones

Fig. 13.1 Estructura del marco de actuación DME

Aplicación cliente

CORBA IDL StubDCE IDL Stub

DCE IDL RuntimeDCE 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 actuación y unaserie de servicios distribuidos. Dentro del marco de actuación, presenta una infraestructura orientada aobjetos para aplicaciones de gestión distribuida, la Object Management Framework (OMF) con unaDistributed User Interface (DUI) que permite el soporte para el Simple Network ManagementInformation Protocol (SNMP) y el CMIP, la Network Management Option (NMO). También disponede Distributed Notificacion Services. En cuanto a los servicios distribuidos, permiten la instalación ydistribución de software, licencia de software, integración de ordenadores personales o bien la gestiónde hosts.


Gestión de red188

Cliente

IDLStub

DCE Runtime

RPC

Repositoriode interfaces

Interfaz deinvocacióndinámica

(DII)

Servicio

Esqueleto IDL

DCE Runtime

activar/registrar

DCEdaemon

Fig. 13.3 Componentes en el marco de trabajo DME

13.3 CORBA. Gestión según OMG

CORBA es una especificación para una arquitectura orientada a objetos estándar para aplicaciones(Object Management Architecture, OMA). CORBA se definió primero por el Object ManagementGroup (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 costesactuales y futuros de las empresas. CORBA proporciona la posibilidad de dar acceso a informacióndistribuida y a recursos desde dentro de aplicaciones de sobremesa populares; proporcionar datos ysistemas disponibles como recursos de red; aumentar las herramientas, aplicaciones con funciones decliente y capacidades para un entorno particular. Además, CORBA permite el cambio y evolución delos sistemas basados en red para reflejar nuevas topologías o nuevos recursos.

CORBA permite la computación distribuida de objetos, es decir, dos o más partes de softwarecomparten información con cada otra. Para ello, sin embargo, hay aspectos que se deben tener encuenta, como la unión de computación distribuida con un modelo de objetos o el uso de un broker.

Un modelo de objetos es un concepto de computación orientado a objetos. Se basa en los conceptos deabstracción, encapsulación, herencia y polimorfismo. Abstracción es la capacidad para agrupar objetosy enfocar las características comunes del grupo. La encapsulación esconde los detalles deimplementación de un objeto en función de los servicios que puede proporcionar. La herencia permitepasar junto a las capacidades y comportamientos de un objeto a otro. Finalmente, el polimorfismo es lacapacidad para sustituir objetos con la identificación de interfaces en el tiempo de ejecución.

Existen diversas justificaciones para utilizar CORBA frente a otros mecanismos. Por ejemplo, elmodelo de distribución CORBA está basado en el uso de objetos y utiliza un modelo de distribuciónorientado a objetos. De esta forma permite cubrir una necesidad de modificar o extender el sistema de



computación distribuido lo que permite obtener los beneficios que comporta el análisis y el diseñoorientado a objetos. Esta flexibilidad resulta de gran utilidad en el diseño de los atributos de losobjetos a gestionar, así como en el rendimiento de los protocolos de gestión. CORBA, además,soporta comunicaciones síncronas entre servidores y clientes y también cubre la necesidad decomunicaciones asíncronas sin usar una trayectoria predefinida.

13.3.1 Arquitectura CORBA

OMG a través de CORBA (Common Object request Broker Architecture) estandariza los mecanismosmediante los cuales los objetos envían mensajes y reciben respuestas, los servicios necesarios queincluye y ofrece interoperatividad entre aplicaciones. OMG proporciona un modelo, una arquitectura yun lenguaje (IDL, Interface Definition Language) para la definición de la interfaz de los objetos.CORBA propone una aproximación consistente en el desarrollo de una interfaz independiente de todolenguaje, que permita invocar las operaciones sobre objetos, sin saber dónde éstas van a serejecutadas.

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.

ORB (mecanismos)

Solicitudes

Respuestas

Fig. 13.4 Esquema de flujos de información en un ORB

Objetosclientes

Herramientascomunes

Broker de petición de objetos(ORB)

Objetosservidores

Descripción de los serviciosofrecidos a través de IDL

Fig. 13.5 Esquema de servicios ofrecidos a través de IDL al ORB


Gestión de red190

La función principal del agente ORB es la de asegurar la independencia de localización eimplementación de los objetos, y responder de la interoperatividad entre máquinas diferentes.

Para ello, debe conseguir que el cliente sea capaz de ver la interfaz del objeto de maneraindependiente de su ubicación, del lenguaje de programación que lo implemente, y de cualquieraspecto que la interfaz no refleje expresamente.

El funcionamiento de CORBA se sustenta en 5 componentes principales: el núcleo de ORB (ORBcore), el lenguaje de definición del interfaz (IDL), el interfaz de invocación dinámica (DII), elalmacén de interfaces (IR) y los adaptadores de objeto (OA).

El nucleo de CORBA es responsable de la recepción desde el cliente y entrega posterior de laspeticiones a los servidores correspondientes. Los clientes no tienen por qué conocer dónde residen losobjetos de red, cómo se comunican, cómo están implementados, cómo están almacenados, ni tampococómo se ejecutan o procesan. Para que un cliente pueda efectuar una petición sobre un objeto, debeconocer una referencia de objeto de él. CORBA especifica dos alternativas mediante las cuales losclientes pueden efectuar sus solicitudes sobre objetos: invocaciones estáticas vía una interfazespecífica, o invocaciones dinámicas vía la interfaz de invocación dinámica (DII) del ORB.

El lenguaje de definición del interfaz permite la especificación de las interfaces a objeto. Es unlenguaje declarativo, cuya sintaxis es similar a la de C++, que proporciona tipos de datos básicos(enteros, reales, etc.) estructurados (estructuras y uniones) y plantillas (templates). Se emplea en ladeclaración de operaciones para definir los tipos de argumentos y los valores de retorno.

La interfaz de invocación dinámica permite que aquellas declaraciones de interfaces en IDL de las quelos clientes no tenían conocimiento en tiempo de compilación, y que han sido compiladas en C++ o C,puedan ser invocadas por los clientes para operar sobre objetos conocidos. Por ejemplo, un constructorde una interfaz gráfica de usuario GUI puede, dada una lista de referencias a objeto, permitir a losusuarios hojear el almacén de interfaces, aprender sobre las operaciones soportadas por cada objeto y,entonces, invocar operaciones sobre ellos para ver cómo se presentan en pantalla. En suma, el DII esuna matriz genérica del cliente capaz de avanzar cualquier petición sobre un objeto.

El almacén de interfaces guarda de forma persistente la definición de las interfaces (InterfaceDef) detodos los objetos declarados IDL, y pueden ser consultados por medio de la operación get_interface(),la cual devuelve una referencia de objeto a un Interfacedef describiendo la interfaz del objetosolicitado.

Los adaptadores de objeto proporcionan los medios por los cuales varios tipos de implementacionesutilizan los servicios de ORB, tales como la generación de referencias a objeto, la invocación demétodo de objeto, la seguridad o la activación y desactivación de objetos e implementaciones. Elhecho de que CORBA admita varios tipos de implementaciones (por ejemplo, aplicacionestradicionales o nuevos desarrollos O-O) le adjudica flexibilidad suficiente para permitir la integraciónde aplicaciones heredadas sin perjudicar a nuevos objetos definidos, restringiéndolos a un conjuntolimitado de criterios de implementación. Los servicios que los OA deban proporcionar podrán serproporcionados delegándolos al propio ORB o bien efectuándolos él mismo.



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 pasarelaCORBA/CMIP UHC, que permite que en una aplicación basada en CORBA se pueda controlar o sepuedan visualizar objetos basados en los agentes Q3 de CMIP, y permita recibir los eventos emitidospor los agentes de CMIP. La pasarela CORBA/CMIP UHC trabaja según los principios definidos en elOpen Group/NMF Join Inter-Domain Management Force (JIDM).

Los objetivos básicos del diseño de la pasarela CORBA/CMIP UHC son:

- Proporcionar una implementación escalable que permita el acceso a un número configurable deagentes OSI.- Incluir los principios de traducción definidos por el JIDM.- Permitir una configuración completamente dinámica en tiempo de ejecución de la información deldiccionario.- Que las prestaciones de la pasarela sea independiente del número y tamaño de los agentes de la red.

La pasarela incluye un compilador GDMO a IDL, que traduce de GDMO a IDL de CORBA yproporciona la información de mapeado que necesita el kernel de la pasarela. Una de lasfuncionalidades de la pasarela permite una actualización dinámica de la información del diccionario,incluir nuevas clases de objetos y agentes OSI en tiempo de ejecución. Esto se realiza implementandola información del diccionario como un MIB local accesible mediante un protocolo Q3, la interfaz deCORBA o la interfaz de gestión local de la pasarela.

A partir de las funcionalidades básicas de traducción CORBA/CMIP, la pasarela añade las siguientesfuncionalidades adicionales:

Implementación deobjetosCliente

Repositoriointerfaces

ImplementaciónRepositorio

Invocacióndinámica

StubsIDLCliente

InterfacesORB

Esqueletosestáticos

Invocación deesqueletosdinámica

Adaptadordeobjetos

Núcleo del broker de petición de objetos (IIOP)


Gestión de red192

- Gestor de eventos genéricos: cumple las normativas X.734 y X.735, se encarga de la recepción,redirección y memorización de los eventos.- Q3IM: gestión interna de Q3ADE, que es un paquete de aplicaciones para el desarrollo TMN, yprotocolo de gestión de MIB.- Pasarela de SNMP: accede a los agentes SNMP según las especificaciones NMF IIMC.- ADK: monitoriza la calidad de servicio y realiza estadísticas.

La pasarela CMIP/CORBA UHC es una pasarela general con diversos campos de aplicación:- El producto se puede utilizar como una pasarela independiente entre dominios CORBA y CMIP.- El producto se puede utilizar para disponer de aplicaciones estandarizadas de gestión, que permitemapear a un número elevado de lenguajes de programación y mediante el cual se pueden gestionar losagentes CORBA, CMIP y SNMP.- El producto se puede utilizar para implementar agentes heterogéneos capaces de ser gestionados poraplicaciones de gestión CORBA y CMIP.

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. Existeuna amplia gama de productos basados en CORBA. Además, su interoperabilidad se garantizamediante la versión 2 del ORB, que incluye una notación IDL normalizada por la ITU. Esa mismainteroperabilidad de ORBs permite utilizar CORBA como soporte de la interfaz X o Q en TMN.

De todas formas hay que decir que la notación GDMO/ASN1 sigue siendo mejor alternativa comoespecificación de modelos de información.

13.4 Distributed Component Object Model (DCOM)

DCOM (Distributed Component Object Model) es un protocolo que permite a los componentessoftware comunicarse directamente a través de una red de manera fiable, segura y eficiente. Al

Sistema gestor

PROXY(ClienteCORBA)

Browserweb

Browserweb

Browserweb

Interfaz de usuario

Operador o abonado

HTTP

CORBA

PasarelaCORBA/CMIP

PasarelaCORBA/SNMP

Servidores CORBA

CMIP

SNMP

Recursosgestionados

Recursosgestionados

AgenteOSI

AgenteSNMP

Sistema gestionado



principio adoptaba el nombre de Network OLE. Actualmente DCOM está diseñada para utilizarse através de múltiples protocolos de transporte de red, incluyendo los de Internet como HTTP. DCOM sebasa en la especificación DCE-RPC de la Open Software Foundation y funciona tanto con appletsjava como con componentes ActiveX a través del uso del Component Object Model (COM) [CHA1].

DCOM fue desarrollado por Microsoft Corporation como respuesta a CORBA como arquitecturaabierta. DCOM está disponible actualmente en la mayoría de sistemas operativos, si bien CORBA esmás utilizado.

DCOM especifica cómo se hacen las peticiones a un objeto y cómo se representan, comunican ymantienen las referencias a objetos. Tiene su aplicación en el diseño de las comunicaciones enentornos de red distribuidos.

13.4.1 OLE y el modelo de objeto COM

OLE es el acrónimo de Object Linking and Embedding que se refiere a enlazar e integrar objetos. Latabla 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 ya la programación de aplicaciones clientes, similares a las del ORB de CORBA. Estos serviciosconstituyen el OLE Automation.

Por otra parte están los OLE Controls, redenominados ActiveX por Microsoft en 1996, para avanzarsu posición en el contexto del World Wide Web y de Internet. La distribución de objetos en el sistemaOLE es lo que ha dado lugar a la definición de DCOM.

13.5 Gestión basada en agentes inteligentes móviles

Actualmente se está planteando el uso de agentes inteligentes en todo tipo de redes avanzadas. Sepueden entender éstas como redes donde la información está disponible en cualquier momento,cualquier hora y desde cualquier terminal. Para que ello sea posible hay que plantearse los avancesque en los últimos tiempos se han mantenido en entornos de comunicaciones móviles y personales.

13.5.1 Introducción a los agentes inteligentes

Un agente inteligente (AI) es un término que define desde interfaces de usuario adaptativos hastacomunidades de procesos inteligentes que cooperan unos con otros para conseguir realizar una tareacomún. Como agentes moviles representan objetos activos o transportables que se mueven desde unsistema a otro para acceder a recursos remotos o incluso encontrar otros agentes y cooperar con ellos.Una última categoría de AI son los de programación remota y se consideran una alternativa a laprogramación remota, considerada alternativa a la basada en la estructura Remote Procedure Call(RPC).

También pueden definirse los agentes inteligentes como entidades de software autónomas que secomportan de acuerdo a una inteligencia autocontenida. Entre los atributos de un agente se puedenconsiderar:


Gestión de red194

- Inteligencia: indica el método que se utiliza para desarrollar la lógica del agente o “inteligencia”.- Operaciones asíncronas: un agente podría ejecutar su(s) tarea(s) totalmente desacoplada de suusuario u otros agentes.

- Comunicación de agentes: durante sus operaciones, los agentes podrían comunicar con variosrecursos de sistemas y usuarios.

- Cooperación de agentes: este atributo indica que el sistema de agentes permite la cooperación entreentidades de agentes. Esta cooperación abarca desde la clásica interacción cliente/servidor anegociaciones basadas en métodos de inteligencia artificial.

- Movilidad de agentes: con el objetivo de realizar tareas específicas, los agentes podrían transportarsea través de la red hasta entornos remotos donde admitan su soporte. Existen diversos niveles demovilidad: ejecución remota y migración.

13.5.2 Clases de agentes inteligentes

Dentro del contexto de sistemas con un único agente se puede hablar de agentes locales en relación aagentes de red. En el contexto de sistemas multiagente, los agentes pueden estar basados eninteligencia artificial distribuida o bien ser agentes móviles.

Agentes localesLos agentes locales tienen como objetivo principal las interacciones típicas entre el usuario y elagente. También se denominan interfaces inteligentes. Por ejemplo: obtención y filtrado deinformación local, gestión de correo local, ordenación de reuniones, etc.

Agentes de redLos agentes de red, en contraste con los agentes locales, pueden acceder no sólo localmente sinotambién a recursos remotos. Esto exige tener un conocimiento más o menos detallado de lainfraestructura de la red y de los servicios que hay disponibles. Los agentes de red no cooperan entreellos. Por ejemplo: asistentes personales: correos inteligentes (filtros basados en preferencias),motores de búsqueda (WWW).

Agentes basados en inteligencia artificial distribuidaEl principal objetivo de estos sistemas multiagente es la coordinación de comportamiento inteligenteentre una colección de agentes inteligentes autónomos. Cómo coordinan ellos sus conocimientos,objetivos y utilidades para planear y desarrollar conjuntamente acciones o solucionar problemas. Porejemplo: monitorización de vehículos distribuida, CIM, gestión de telecomunicaciones. Estos agentesse desarrollan mediante técnicas de inteligencia artificial y podrían comunicarse y cooperar entreellos. Son usualmente estáticos.

Agentes móvilesLos agentes móviles se sitúan principalmente en grandes ordenadores, ofreciendo un conjunto deservicios sofisticados. Por ejemplo: filtrado de Internet avanzado, agentes de búsqueda, mensajesinteligentes, comunicación inteligente y gestión. En cuanto a lenguajes, los más utilizados actualmenteson el Safe-TCL y Java, que permiten ejecución remota de agentes. Los agentes basados en Telescriptpermiten la migración mientras están activos.



Atributos/Clase

Agente local Agente de red Agente DAI Agente móvil

Inteligencia deagente

X X X X

Operaciónasíncrona

X X X X

Comunicaciónentre agentes

X X X

Cooperaciónentre agentes

X X

Movilidad entreagentes

X

Tabla 13.1 Clases de agentes inteligentes y sus características

13.5.3 Agentes móviles

La movilidad es quizás la característica más apreciada de los agentes a la hora de influir en la formatradicional en que se realizan servicios y comunicaciones. Como contrapartida, la ejecución deprogramas (agentes) debe realizarse en entornos considerados seguros. Se pueden considerar lassiguientes situaciones:

- Procesado de tareas asíncrona y cooperativamente.- Personalización y configuración de servicios.- Uso de servicio instantáneo (NCs) y comercio activo. Se pueden distinguir los siguientes tipos:

Clase de agente simple: ejecución remota o migración.Clase de agente cliente/servidor (p.e. CORBA).Clase de agente multimedia (p.e. MHEG).

- Descentralización de gestión.- Comunicaciones inteligentes.- Obtención de información y soporte de tipos de información dinámica.

13.5.4 Arquitecturas de comunicaciones basadas en agentes

Los entornos de telecomunicaciones actuales están basados en dos tipos de redes: las redesinteligentes con el protocolo INAP, o bien la red de gestión de las telecomunicaciones (TMN), con elprotocolo CMIP. Estos entornos representan los fundamentos para una creación eficiente y uniforme,y la provisión y gestión de servicios de telecomunicación avanzados.

Ambos tipos de redes presentan arquitecturas altamente centralizadas en sus SCP, lo que las limita ensu escalabilidad y flexibilidad para su crecimiento. Esto no ocurriría con el uso de agentesinteligentes. Se pueden hacer las siguientes aproximaciones a arquitecturas de servicio basadas enagentes:

- Red inteligente: los agentes son entidades estacionarias en la red, que proporcionan la inteligencianecesaria y son capaces de realizar tareas predefinidas específicas autónomamente (en nombre de un


Gestión de red196

usuario o aplicación). Este tipo de agentes estáticos, tales como agentes de usuario o de gestión,podrían considerarse más como entornos de ejecución de agentes especializados, que ejecutan scripts(p.e. agentes de tipo de ejecución remota).

- Mensaje inteligente: los agentes son entidades móviles, que viajan entre diferentesordenadores/sistemas y realizan tareas específicas en posiciones remotas (tanto ejecuciones remotasde agentes como migraciones).

Actualmente existe ya una arquitectura de comunicaciones basada en agentes. Se trata del entornodenominado Mobile IP. Ésta es una estructura basada en agentes estáticos (Home Agent, ForeignAgent). En este caso, el home agent de un nodo móvil es un router que al menos tiene una interfaz conel home link del nodo móvil. A un nodo móvil se le asigna una nueva dirección IP cuando visita unforeign link. Un foreign agent de un nodo móvil es un router que al menos tiene una interfaz con elforeign link del nodo móvil.

En el caso anterior de la aproximación de sistema inteligente, ésta se basará en el despliegue deagentes estáticos en la red o sistema. En este caso, la red inteligente está previsto que evolucione haciaTINA.

Adoptando la aproximación de mensajes inteligentes basada en agentes móviles, se podría utilizar endos tipos de dominios, los llamados de intercambio de información asíncrona, tales como servicios decorreo, y para el preestablecimiento de información en tiempo real, tales como servicios decomunicación multimedia.

Usuario A

Usuario B

Sistema final

Sistema final

Recursos de red

Establecimiento de conexión

Gestión de conexión

Agente terminal

Agente terminal

Agente usuario

Agente usuario

Negociación

Entorno de red

Fig. 13.8 Telecomunicaciones basadas en agentes estáticos



Usuario A

Usuario B

Sistema Final

Sistema FinalEntorno de red

1 1

2 2

Fig. 13.9 Señalización basada en agentes móviles

13.5.5 Gestión basada en agentes

La distribución de tareas de gestión en la gestión de red se conoce como gestión por delegación, yadopta un paradigma de gestión descentralizada que tiene la ventaja del incremento de potenciacomputacional en nodos de la red y decrecimiento de la presión en sistemas de gestión de redescentralizados y en anchos de banda de red. La gestión por delegación habilita tanto la distribucióntemporal (p.e. distribución sobre tiempo) como la distribución espacial (p.e. distribución sobre nodosde red diferentes).

El objetivo básico consiste en traer la inteligencia de gestión (p.e. los servicios de gestión), tan cercacomo sea posible a los recursos gestionados, y a su representación lógica en forma de objetosgestionados. Esto es, mediante la delegación.

Agente gestionado Agente gestionado Agente gestionado

Descarga de scriptsde gestión

Gestor

Fig. 13.10 Delegación de inteligencia de gestión

El agente de gestión (nodo gestionado) tiene que verse como un entorno de agente de ejecuciónespecífico, que soporta la ejecución remota de scripts de gestión. Estos scripts podrían activarse segúnel tiempo, las actividades de gestión o la aparición de eventos específicos en el agente gestionado.


Gestión de red198

Las aplicaciones de gestión móviles representan una extensión del escenario anterior, donde lasaplicaciones de gestión serán realizadas por medio de agentes móviles que también soportanmigración.


Gestor

1

2 3

4

Fig. 13.11 Servicios de gestión basados en agentes moviles

Sea rT Tiempo de respuesta completo.

mt representa el tiempo de cálculo local del proceso del gestor en el gestor.

at describe el tiempo pasado por los agentes (SNMP o agente móvil).

dt representa el retardo de la red.

Tr = tm + ta + td

nAAA ,...,, 21 representan los agentes distribuidos.

1mt representa el retardo temporal desde el gestor al agente 1A .

mt1 representa el retardo temporal entre el agente 1A y el gestor.

Para el caso cliente/servidor tradicional, el gestor necesitará construir un mensaje de petición tantasveces como n, donde n es el número de nodos agentes. Además, un agente móvil sólo necesitaprocesar una vez. El tiempo de cálculo local del proceso gestor en cada caso será:

tmSNMP = ntm

tmMOVIL = tm



��


Gestor

A1 A2 A3 An

t1m

tm1

tmn

tnm

Fig. 13.12 Tiempo de respuesta de agentes SNMP

��


Gestor

A1 A2 A3 An

tm1tnm

t12 t23

Fig. 13.13 Tiempo de respuesta de un agente móvil

El retardo de la red total dt es 2nt para SNMP y (n+1)t para el caso móvil. Se asume que los retardos

temporales entre todos los nodos distribuidos son los mismos. Si se asume también que am tt , son

constantes, el tiempo rT será:

Tr SNMP = 2nt + nα + βTr MOVIL = (n +1)t + α + β

con

α = tm

β = ta


Gestión de red200

13.5.6 Procesos elásticos

Un proceso elástico es un proceso con múltiples enlaces que soporta la invocación remota de unconjunto de transformaciones elásticas. Estas transformaciones permiten procesos remotos para:

- Extender la funcionalidad de un proceso elástico mediante la delegación de agentes a éste.- Controlar la ejecución de agentes.- Comunicarse con los agentes

Un proceso P = < C, S > consiste en un programa código C y un estado S.C se define por una colección de fragmentos de código de programa que P puede ejecutar,C = {c1, c2, …,cn}.S es el estado de todos sus enlaces, S = {s1, s2, …,sn}.ci incluye todo el código en el programa principal ejecutable, y todo las rutinas de librería importadasque fueron explícita o implícitamente cargadas en su espacio de direcciones.si = < ci, xi > donde xi indica el estado de ejecución del enlace.

Fig. 13.14 Agentes móviles delegando a un servidor elástico

- Transformaciones de extensibilidad de código: permiten a un proceso remoto extender o contraerel código de programa C de un proceso elástico.

- Una transformación suma incorpora un nuevo fragmento de código, c en un proceso en ejecución, P= < C, S >.Suma: {< C, S >, c} -> < {C U c}, S >

- Una transformación borrado, borra un fragmento de código c, de un proceso P, y podríaimplícitamente borrar cualquier enlace cuyo estado esté asociado con el fragmento de código borrado.Borrado: {< C, S >, c} -> <{ C - c }, {S - {si: si = < c, xi > }} >

- Transformaciones de control de estado: permiten a un proceso remoto modificar el estado de unproceso elástico.

- Una instanciación incorpora un nuevo enlace al estado de un proceso existente.Instanciación: {< C, S >, c} -> <C, {{s1,..,sk} U {sk+1 = <c, Run >}} >

Clientes Agente delegado

RPCRuntimeelástico

Servidorelástico

Procesoelástico

Proceso

Proceso


- Una terminación borra un enlace de un proceso existente.Terminación: {< C, S >, sj} -> <C, S - sj >.

- Una suspensión cambia el estado de un enlace que se está ejecutando a suspendido.Suspensión: { sj = < c, - >} -> { sj = < c, Sus >}

- Un reenganche cambia el estado de un enlace suspendido a ejecución.Reenganche: { sj = < c, Sus >} -> { sj = < c, Run >}

Un proceso elástico Pe, soporta la invocación remota de las seis transformaciones elásticas definidasanteriormente. Esto es, el código y el estado de un Pe pueden modificarse remotamente durante suejecución, como el resultado de una interacción externa explícita. Un proceso elástico es unageneralización de un entorno de múltiples enlaces dinámicos a uno de distribuido.

Un server elástico es un proceso elástico cuyas interfaces de servicio pueden modificarseremotamente. Esto es, la interfaz del servidor es una colección de procedimientos de servicio { p1,p2,…,pn } que cambia dinámicamente y que puede invocarse remotamente por sus clientes.


14. Gestión basada en Webs 203

14 Gestión basada en Webs

La aplicación de las nuevas tecnologías de Internet a la gestión de redes intranet, sistemas yaplicaciones es lo que se denomina comunmente como gestión basada en web. La gestión basada enweb puede acomodar los sistemas actuales de gestión, basados en SNMP, CMIP, DMI u otrossistemas propietarios. Existen recientemente sin embargo nuevas iniciativas como Web-basedEnterprise 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 degestión de servicios para redes heterogéneas. Este núcleo de APIs puede usarse en un array diverso deentornos de computación que incluye numerosos sistemas operativos, arquitecturas y protocolos dered, lo que permite el desarrollo del bajo mantenimiento y un software heterogéneo desde una fuenteúnica.

JMAPI está orientado a resolver problemas de gestión de sistemas distribuidos. El componente quepermite a una máquina ser gestionada es pequeño (p.e. applets/java beans), y los objetos agente paraoperaciones de gestión se descargan y ejecutan de forma segura. Esto minimiza la distribución y elproblemas de las versiones para las operaciones de gestión, y fácilmente permite la modificación yextensión de las operaciones de gestión. Por otro lado, la máquina virtual java ha de residir en lasplataformas que deben ser gestionadas.

En el nivel superior, la arquitectura consiste de un browser user interface, admin runtime module, yappliances.

- El browser user interface es el mecanismo por el cual una administrador envía operaciones degestión. Estas operaciones podrían invocarse interactivamente a través de un navegador de web o bienuna aplicación independiente.- El admin runtime module es el mecanismo que proporciona objetos de gestión instanciados activos aaplicaciones.- Las appliances son los dispositivos de red que deben ser gestionados.

El JMAPI está provisto de guías para interfaz de usuario, clases java y especificaciones para eldesarrollo de aplicaciones para la gestión integrada de redes de sistemas y servicios. Esto incluye:


Gestión de red204

- Java Management API User Interface Style Guide- Admin View Module (AVM)- Base Object Interfaces- Managed Container Interfaces- Managed Notification Interfaces- Managed Data Interfaces- Managed Protocol Interfaces- SNMP Interfaces- Applet Integration Interfaces

Para la creación de los agentes que se sitúan en los dispositivos que se deben gestionar (appliances),SUN proporciona el Java Dynamic Management Kit (JDMK), que se trata de un toolkit para dotar defuncionalidad a los agentes.

Fig. 14.1 Esquema de gestión con JMAPI

14.2 Web-based Enterprise Management (WBEM)

El WBEM trata de ser un estándar de facto para integrar aplicaciones de gestión de red en webs. Estádefinido por más de 50 fabricantes (julio 1996) entre los que destacan: Microsoft, Intel, Compaq,BMC y Cisco.

HTTP ServidorHTTP

Applet JMAPI

AVM base

AVM Help

AVM Integration

Managed object interfaces

Navegador de web para java

Admin runtime module

Fábrica de objetos gestionados

Instancias de objetos gestionados

Interfaces de agentesSNMP

Agente objeto

Interfaces de datosgestionados

JDBC

Base de datos

RMI

SNMP

RMI

Agente SNMP

Appliance

Fábrica de objetos agente

Instancia de objetos agente

Código JAVA Métodos nativos


14. Gestión basada en Webs 205

WBEM proporciona una arquitectura que permite soluciones de gestión para ser construidascubriendo las áreas tradicionales de gestión de configuración, gestión de fallos, gestión de tarificación,prestaciones, seguridad, gestión de operaciones y planificación. Está construido para las necesidadesde los estándares de Internet, tanto actuales como futuros, en las áreas de transporte, seguridad yprotocolos de configuración. WBEM proporciona un modelo de datos que permite un modeladouniforme, así como la gestión del sistema, la red, y los elementos de aplicación. También direccionalas necesidades de un conjunto grande y distribuido de elementos de gestión, proporcionando unasolución escalable.

Componentes definidos por el modelo WBEM:

- HyperMedia Management Schema (HMMS): descripción de datos extensiva para representar elentorno gestionado que será definido por el Desktop Management Task Force (DMTF).Implementación independiente de los datos comunes, permitiendo datos de una variedad de fuentespara 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 delnúcleo) que consiste de las clases a nivel superior, sus propiedades y asociaciones. El segundo nivel esuna serie de esquemas específicos de dominio, que incluye el Windows NT, UNIX, red y esquemas deaplicaciones. El core schema establece una clasificación básica de los elementos del entornogestionado, en elementos de sistema gestionado, componentes de aplicación, componentes de recursosy componentes de red. Las clases de componentes son agrupaciones de las clases de elementos desistema gestionados.

- HyperMedia Object Manager (HMOM): un modelo de datos que consolida los datos de gestiónprovenientes de diferentes fuentes. Definición genérica para gestión de aplicaciones que agregagestión de datos y usa uno o más protocolos para presentar una representación uniforme del browser(navegador) usando, HTML. Implementación de referencia C++.

Un servidor HMMP que implementa un gran subconjunto del protocolo y del rol de losconmutadores para actuar como proxy en nombre de las peticiones de un cliente HMMP sedenomina gestor de objetos hipermedia (HMOM). Los servidores HMMP que implementan unsubconjunto pequeño de los protocolos y no tienen roles de conmutación se denominan típicamenteproveedores (providers).

- HyperMedia Management Protocol (HMMP): un protocolo de comunicación sobre el cual lagestión de datos puede ser accedida y visualizada, y permite soluciones de gestión que sonindependientes de la plataforma y físicamente distribuidas entre los elementos de la empresa. Permiteintegrar HMMS, corriendo sobre HTTP y con interfaces planeadas a SNMP y DMI.

El HMMP se utiliza para intercambiar mensajes que lleven información de gestión entre entidadesHMMP. Las operaciones básicas en HMMP son OPEN, CLOSE, GET, PUT, DELETE; CANCEL,METHOD_EXEC, y METHOD_RETURN


Gestión de red206

Fig. 14.2 Esquema de la arquitectura WBEM

Navegador InternetApplet

Otros

Programas yaplicaciones

Dir. servicios Acceso a datos

Gestión de servicios(HMOM)

SNMP, DMI, otros

Esquema degestiónhipermedia

Acceso basado en HTTP(incluyendo HMMP)

Protocolo degestiónhipermedia

Dispositivos oaplicaciones




15. Desktop Managment Interface (DMI) 207

15 Desktop Management Interface (DMI)

El DMI (Desktop Management Interface) ha sido definido por el DMTF (Desktop Management TaskForce) que es un consorcio internacional, fundado en 1992. Se han definido las siguientesespecificaciones DMI1.0 (Abril 1994) y DMI2.0 (Marzo 1996).

El DMI consta de tres capas. La capa del núcleo es la capa de servicios (Service Layer,SL), que es laaplicación local que gestiona las peticiones para información de gestión y las almacena en una base dedatos. La capa de servicio soporta dos interfaces de programación de aplicaciones: la interfaz decomponentes (Component Interface, CI) y la interfaz de gestión (Management Interface, MI). El CI seimplementa en los componentes de hardware o de software, tales como procesadores, impresoras,sistemas operativos, etc. Esta interfaz permite el acceso a información específica de componentes quese requiere para gestionar esos mismos componentes. El MI es la interfaz vista por las aplicaciones degestión, que puede ser local o remoto. Los sistemas de gestión construidos en el esquema gestor-agente pueden acceder a componentes desktop vía agentes proxy (SNMP, CMIP). La información degestión se describe mediante un lenguaje especial llamado Management Information Format (MIF)que se utiliza en los ficheros MIF que se almacenan en bases de datos MIF.

Las especificaciones DMI se refieren a los interfaces MI y CI, funciones soportadas por esasinterfaces, y llamadas y procedimientos usados para acceder a esas funciones. Estas llamadas songestionadas por la capa de servicio DMI. El conjunto de operaciones disponibles por las aplicacionesde gestión son las siguientes:

- GET (valores de atributos de componentes gestionados).- SET (atributos y valores de atributos).- LIST (atributos actuales como almacenados en la base de datos MIF).- INDICATION (enviados por la SL a la aplicación como un suceso asíncrono).

La lista de operaciones implementadas en la SL y disponibles a nivel de CI son:

- INSTALL (usado en la instalación de los componentes gestionados).- REGISTER (registro dinámico de un punto de servicio en SL para ser gestionado).- INDICATE (evento asíncrono enviado a una aplicación registrada).

La CI permite la creación de un punto de servicio que se usa para cargar los ficheros MIF asociadoscon nuevos componentes registrados.


Gestión de red208

Actualmente sólo existen especificaciones para la traducción de DMTF MIF a SNMP MIB y no ensentido contrario.

15.1 Common Information Model (CIM)

Actualmente se está especificando la versión 2 de CIM por el IETF, lo que significa que lainformación de gestión de redes y sistemas podrá recogerse y almacenarse de un mismo modo. Si aCIM se añade Extensible Markup Language (XML), la gestión de datos podría representarse sobreuna interfaz web de forma estándar o a través de WBEM.


16. Plataformas de gestión de red 209

16 Plataformas de gestión de red

Las plataformas de gestión son el elemento más visible de la gestión de una red y la clave del correctofuncionamiento de los sistemas de comunicaciones. Su ubicación física, el personal, el mantenimiento,la configuración de elementos, etc., son básicos para que no haya mayores problemas.

16.1 Plataformas de gestión

Las plataformas de gestión son la última etapa en la evolución de los sistemas de gestión, desdesistemas de monitorización pasivos a sistemas de gestión standalone, y finalmente a plataformas degestión. Las plataformas de gestión se distinguen por los siguientes atributos únicos [GHE1]:

- Separación de aplicaciones de gestión de los servicios de la plataforma por medio de APIs.- Entornos de desarrollo de aplicaciones de gestión independientes del software de fabricante.- Separación/modularidad de los servicios/componentes de la plataforma de gestión.- Soporte para la integración de aplicaciones de gestión.- Fundamento para la integración de tecnologías multifabricante, heterogéneas, distribuidas y abiertas.- Interfaz de usuario gráfica común.- Servicios de aplicaciones comunes (tiempo, directorio, seguridad).- Repositorio de datos de gestión comunes.- Sistemas de distribución de software y servicios de licencia software.- Reusabilidad de software y entornos de desarrollo de software de bajo coste.

Dependiendo del nivel de sofisticación, las plataformas de gestión pueden proporcionar también:

- Un entorno para paradigmas orientados a objetos (definiciones de interfaces, modelos, librerías,...).- Un entorno para invocar métodos de objetos e instrumentación.- Un entorno para soportar selectivamente sistemas propietarios.

A continuación se describen brevemente algunas de las plataformas de gestión más importantes:

HP OpenView.Sun Solstice.IBM System View.SPECTRUM de Cabletron.TME10 (Tivoli Management Environment)


Gestión de red210

16.2 Plataforma de gestión de red OpenView

El OpenView de HP ofrece una solución de gestión de red para gestión local y redes multifabricantede área extendida. Incorpora herramientas para el desarrollo de aplicaciones de gestión OSI. Utilizauna amplia variedad de protocolos (SNMP, CMIP, CMOT...). En el caso de gestión distribuida, hayque decir que HP fue el principal promotor del estándar DME (OSF).

Otras características de OpenView:

- Incorpora la aplicación Network Node Manager para redes TCP/IP.- Usa la base de datos INGRES (relacional).- Servidor del gestor de red OpenView.- Soporta los interfaces XOM/XMP.- Compilador GDMO/ASN1.- API SQL y permite exportar datos a RDBMS externas.

X.11

OSF/MOTIF

HP Open View Windows

Infraestructura

Protocolos de comunicaciones

SNMP CMIP CMIP

OSIUDP TCP

IP IP

Gestorobjetos

Gestorobjetos

Gestorobjetos

Gestorobjetos

Aplicación

HP Open View Windows

Base dedatosSistema

de gestióndebases dedatos

Co-muni-caci-ones

Servicios

de gestión

de datos

Serviciosde gestiónde eventos

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 cálculodistribuido. Los agentes que actúan con SunNet Manager son del tipo:


16. Plataformas de gestión de red 211

- Niveles de protocolo de comunicaciones e interfaces tales como Internet MIB (RFC1066) a través deSNMP, RPC, Ethernet, FDDI y X.25.- Dispositivos de red tales como routers IP.- Estadísticas de recursos y sistema:

a) Mecanismos del sistema tales como el uso de CPU y buffers de memoria libres.b) Disco y sistema de ficheros.c) Aplicación, bases de datos y estadísticas de servicios de red tales como NFS o RPC.

Servicios de comunicaciones (RPC)

serviciosagentes

serviciosagentes

serviciosagentes

Agente proxy Agente Agente

Agente

Objetos gestionados

Cónsola(open windows)

Run-timeMDB

ASCIIMDB

Discover

Resultadosnavegador

ResultadosGráfico

EventosLog

DatosLog

Fig. 16.2 Esquema funcional de la plataforma SunNet Manager

16.4 IBM System View para AIX

El origen de la plataforma de gestión IBM System View es la plataforma IBM Netview/6000 que a suvez partió de una licencia de HP Openview v.3 con algunas mejoras.

El diseño de IBM Netview/6000 para AIX añadió una nueva componente al entorno tradicional degestión IBM, que consiste de las siguientes entidades Focal Point (host basado en Netview), EntryPoint (para dispositivos SNA), y Service Point (para dispositivos no SNA). Esta nueva componente sedenomina Collection Point. El Collection Point actúa como un sistema de gestión de elementosindependiente que recibe datos usando otros protocolos nativos aparte de SNA.


Gestión de red212

Otro aspecto destacable de la plataforma de gestión IBM System View es que no soporta el protocoloCMIP ni soporta actualmente ORB (Object Request Broker).

16.5 SPECTRUM de Cabletron

La primera versión de Spectrum de Cabletron data de 1992. Los componentes que forman el núcleo dela plataforma son el módulo SpectroSERVER y los clientes SpectroGRAPH. El SpectroSERVERconsta de tres componentes el Virtual Network Machine (VNM), una bases de datos y un gestor dedispositivos de comunicaciones. El cliente SpectroGRAPH proporciona las capacidades de la interfazgráfica de usuario.

Las primeras versiones potentes de Spectrum no salieron hasta 1994. Actualmente no soporta elprotocolo CMIP ni implementa el entorno de operación ORB.

16.6 TME10 (Tivoli Management Environment)

La arquitectura TME está formada por unos servicios desktop y el marco de la plataforma de gestión,que en principio pueden distribuirse separadamente. El modelo de información de objetos soportaherencia y relaciones de contención; sin embargo, no está basado en el modelo y las plantillas OSIMIM/GDMO. La comunicación entre gestor y agentes se realiza con mecanismos RPC de la pila deprotocolos TCP/IP. Una plataforma que funciona como pasarela realiza una conversión de llamadasRPC y comandos SNMP a métodos IDL para ordenar acciones en objetos. El ORB disponible nosoporta la versión CORBA 2.0 dado que ésta no soporta seguridad en el protocolo IIOP (OMG).TME10 incorpora su propia seguridad de forma integrada.

Tivoli Systems se fundó en 1989 y fue adquirida en 1996 por IBM.


Conclusiones 213

Conclusiones

Actualmente todavía no existe una solución en el marco de la gestión de red que pueda proporcionarresultados satisfactorios a todo tipo de redes de comunicaciones.

La TMN, o red de gestión de telecomunicaciones, es el camino más válido para enfocar la gestión engrandes redes. El protocolo CMIP y/o la arquitectura CORBA permiten utilizar las funcionalidadesrequeridas normalmente para gestionar redes con gran número de nodos. Sin embargo, desde un puntode 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 deprotocolos como SNMP y RMON/RMON2, sobre todo si se trata de redes que utilizan comoprotocolo de transporte el TCP/IP. Sin embargo, hay que considerar que la gestión quedará reducida ala simple monitorización de las funciones esenciales del sistema.

Si la red que se quiere gestionar está constituida básicamente de nodos tipo PCs que soporten elestándar de gestión DMI, ésta será la solución más cómoda y completa.

Para la gestión remota por Internet, están definiéndose una serie de soluciones como JMAPI, WBEM,CIM que, si bien son realmente potentes, actualmente están aún en una fase temprana de desarrollo.


Bibliografía 215

Bibliografía

SNMP y gestión 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, ISBN0070203598.

[HAR1] Harnedy, Sean J. Total SNMP: Exploring the Simple Network Management Protocol,segunda edición, CBM Books, 1997, ISBN 0136469949.

[HEI1] Hein, Mathis, Griffiths, David. SNMP Version 1 & 2: Simple Network Management Protocol:Theory and Practice, International Thomson Computer Press, 1995, ISBN 1850321396.

[LEI1] Leinwand, Allan, Fang-Conroy, Karen. Network Management: A Practical Perspective,segunda edición, Addison-Wesley, 1995, ISBN 0-201-60999-1.

[MIL1] Miller, Mark A. Managing Internetworks With Snmp (Network Troubleshooting Library),segunda edición, M&T Books, 1993, ISBN 1558515615.

[PER1] Perkins, David, McGinnis, Evan. Understanding SNMP MIBs, Prentice Hall, 1997, ISBN0134377087.

[ROS1] Rose, Marshall T. The Simple Book: An Introduction to Network Management, segundaedición revisada, Prentice Hall Series in Innovative Technology, 1996, ISBN 0134516591.

[ROS2] Rose, Marshall T., McCloghrie Keith, How to Manage Your Network Using SNMP: TheNetwork Management Practicum, Prentice Hall, 1995, ISBN 0131415174.

[STA1] Stallings, William. SNMP, SNMPv2, and RMON: Practical Network Management, segundaedición, 1996, ISBN 0201634791.

TCP/IP

[BLA3] Black, Uyless D. TCP/IP and Related Protocols, segunda edición, McGraw-Hill Series onComputer Communications, 1992, ISBN 0070055602.


Gestión de red216

[BON1] Bonner, Patrick. Networking Programming With Windows Sockets, Prentice Hall ComputerBooks, 1995, ISBN 0132301520.

[COM1] Comer, Douglas E. Internetworking with TCP/IP - Volume I: Principles, Protocols, andArchitecture, tercera edición, Prentice-Hall, 1995, ISBN 0132169878.

[COM2] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume II: Design,Implementation, and Internals, segunda edición, Prentice-Hall, 1994, ISBN 0131255274.

[COM3] Comer, Douglas E., Stevens, David L. Internetworking with TCP/IP - Volume III: Client-Server Programming and Applications, Versión Windows Sockets. Prentice-Hall, 1997. ISBN0138487146.

[FEI2] Feit, Sidnie. TCP/IP: Architecture, Protocols, and Implementation with Ipv6 and IP Security,segunda edición, McGraw-Hill, 1996, ISBN 0070213895.

[HUN1] Hunt, Craig. Networking Personal Computers with TCP/IP, O'Reilly & Associates, 1995.ISBN 1565921232.

[HUN2] Hunt, Craig. TCP/IP Network Administration, O'Reilly & Associates, 1992, ISBN093717582X.

[QUI1] Quinn, Bob, Shute Dave. Windows Sockets Network Programming, Addison Wesley, 1996,ISBN 0201633728.

ASN.1 y BER

[STE1] Steedman, Douglas. Abstract Syntax Notation One (ASN.1): The Tutorial and Reference,Technology Appraisals, Isleworth, Middlesex United Kingdom, 1993, ISBN 1871802067.

Programación con Win32. Windows NT

[APP1] Appleman, Daniel. Visual Basic Programmer's Guide to the Win32 API, Ziff-Davis Press,1996, ISBN 1562762877.

[BEV1] Beveridge, Jim, Wiener Robert. Multithreading Applications in Win32. The Complete Guideto Threads, Addison-Wesley, 1996, ISBN 0201442345.

[BRA1] Brain, Marshall, Win32 System Services: The Heart of Windows 95 and Windows NT,segunda edición, Prentice Hall, 1996, ISBN 0133247325.

[HAM1] Hamilton, Dave, Williams Mickey. Programming Windows NT 4 Unleashed, SamsPublishing, Indianapolis, IN, 1996, ISBN 067230905

[LEW1] Lewis, Bil, Berg, Daniel J. Threads Primer, Prentice Hall, 1995, ISBN 0134436989

[MUR1] Murray, James D. Windows NT SNMP, O’Reilly, 1998.


Bibliografía 217

[PEA1] Pearce, Eric, Windows NT in a Nutshell, O’Reilly & Associates, 1997, ISBN 1565922514.

[PET1] Petrusha, Ron, Inside the Windows 95 Registry, O'Reilly & Associates, 1996, ISBN1565921704.

[PHA1] Phan, Thuan Q., Garg Pankaj K. Multithreaded Programming with Windows NT, PrenticeHall, 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 APIBible, The Waite Group, 1996, ISBN 1571690093.

Sistema de señalización nº 7 y redes inteligentes

[ATS1] Nakamura Atsushi et al. SCP Architecture with Performance Flexibility, p. 1680-1684,Globecom 91.

[BLA1] Black Uyless. The Intelligent Network. Customizing Telecommunication Networks andServices, Prentice Hall, 1998.

[BLA2] Black Uyless. ISDN and SS7. Architectures for Digital Signalling Networks, Prentice Hall,1997.

[FAY1] Faynberg Igor et al. The Intelligent Network Standards, Mc Graw Hill, 1997.

[INO1] Inoue Yuji et al. The TINA book, Prentice Hall 1999.

[RUS1] Russell Travis. Signaling System #7, Segunda edición, Mc Graw Hill, 1998.

Gestión según OSI

[BLA4] Black, Uyless. Network Management Standards: Snmp, Cmip, Tmn, Mibs, and ObjectLibraries, 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-ManagementStandards, Addison Wesley, 1993.

Gestión de la red B-RDSI

[MIN1] Daniel Minoli, Golway Thomas. Planning & Managing ATM Networks, Prentice Hall, 1997.


Gestión de red218

[NAT1] Giroux Natalie, Ganti Sudhakar. Quality of Service in ATM networks, Prentice Hall, 1999.

[SCH1] Schwartz Mischa. Broadband Integrated Networks, Prentice Hall, 1996.

[VEN1] Venieris Iakovos, Hussmann Heinrich. Intelligent Broadband Networks, John Wiley, 1998.

Gestión en redes de comunicaciones móviles

[AB1] Barba A., Cruselles E., Melús J. L. The CPNs in UMTS. Security aspects. Fourth WINLABWorkshop on Third Generation Wireless Information Networks. p 317-328, New Jersey, 1993.

[AB2] Barba A., Pulido J. M., Melús J. L. Diseño de protocolos de gestión de movilidad entre redesprivadas 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 oncommunications, agosto 1990.

[DG2] Goodman David J. Trends in Cellular and Cordless Communications, IEEE CommunicationsMagazine, vol. 29, N 6, p 31-40, junio 1991.

[GA1] Garg Vijay K., Wilkes Joseph E. Wireless and Personal Communications Systems, Ed. PrenticeHall, 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, p1517-1522. 1991.

[HM1] Maab Henning, Schreyer Oliver, Stahl Martin. Directory Services for Mobility Management inPrivate Telecommunication Networks, p 1252-1256, ICC 1993.

[JB1] Bursztejn J. Interoperability and/or convergence of mobile systems. p 9-12. RACE MobileTelecommunications 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. 41stVTC 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 PersonalCommunications, p 18-22. 4 trimestre 1994.


Bibliografía 219

[MH1] Hakan Mitts. Universal wireless accesss to ATM, p 329-333, RACE MobileTelecommunications Workshop, Portugal, 1995

[ML1] Laitinen Mikko, Rantala Jari. Integration of intelligent network services into future GSMnetworks. IEEE Communications Magazine, p 76-86, junio 1995.

[MM1] Mouly Michel, Pautet Marie-Bernadette. Current evolution of the GSM systems, IEEEPersonal Communications, p 9-19, octubre 1995.

[MM2] M. B. Pautet and M. Mouly. GSM protocol architecture: Radio sub-system signalling, 41stIEEE 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 theIEEE, p 1210-1243, septiembre 1995.

[TO1] Towle Thomas T. TMN as Applied to the GSM Network, IEEE Communications Magazine, p68-73, marzo 1995.

Gestión distribuida

[BA1] Bapat Subodh. Object-Oriented Networks, models for architecture, operations, andmanagement, Prentice Hall 1994.

[CHA1] Chauvet Jean Marie. Corba, Active X y Java Beans, Ed. Gestión 2000.

[KNO1] Knouse Charles. Practical DCE Programming, Prentice Hall, 1996.

[LE1] Lewis Geoffrey, Barber Steven, Siegel Ellen. Programming with Java IDL, John Wiley, OMG,1998.

[OR1] Orfali Robert, Harkey Dan. Client/Server Programming with Java and Corba, John Wiley,1997.

[WAT1] Watson Mark. Intelligent Java Applications for the internet and intranets, MorganKaufmann, 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. Introducción a la recomendación TMN.M.3010. Principios para una red de gestión de telecomunicaciones.M.3020. Metodología para la especificación de la interfaz TMN.M.3100. Modelo de información de elementos de red genéricos.M.mocs (=M.3101). Requerimientos para conformar objetos gestionados en TMN M.3100.M.3180. Catálogo de información de gestión TMN.M.3200. Introducción a los servicios de gestión TMN.M.3300. Capacidades de gestión TMN presentadas en la interfaz F.M.3400. Funciones de gestión TMN.M.xfunc. Servicios de gestión TMN y funciones para la interfaz X.M.xinfo. Identificación de la información que debe ser intercambiada vía la interfaz X para diferentescasos de acceso.

X.282. ISO/IEC 10742. Elementos de información de gestión relacionados con el nivel de enlace dedatos OSI.X.283. ISO/IEC 10733. Elementos de información de gestión relacionados con el nivel de red OSI.X.284. Elementos de información de gestión relacionados con el nivel de transporte OSI.

Serie X.700

X.700. Marco de gestión para OSI.X.701. Visión de la gestión de sistemas.X.702. ISO/IEC 11587. Contexto de aplicación para sistemas de gestión con procesado detransacciones OSI.X.710. Definición de CMIS.X.711. Especificación de CMIP.X.712. Definición de CMIP. Proforma del protocolo PICS.X.720. Estructura de la información de gestión: modelo de información de gestión.X.721. ISO/IEC 101652. Estructura de la información de gestión: definición de la información degestión.X.722. Estructura de la información de gestión: GDMO.X.723. ISO/IEC 101645. Gestión de sistemas: información de gestión genérica.


Gestión de red222

X.725. ISO/IEC 10156-7. Modelo de relación general.X.730. ISO/IEC 101641. Modelo de información de red genérica.X.731. ISO/IEC 101642. Gestión de sistemas: función de gestión de estado.X.732. ISO/IEC 101643. Gestión de sistemas: atributos para representación de relaciones.X.733. ISO/IEC 101644. Gestión de sistemas: función de recopilación de alarmas.X.734. ISO/IEC 101645. Gestión de sistemas: función de gestión de recopilación de eventos.X.735. ISO/IEC 101646. Gestión de sistemas: función de control de registro.X.736. ISO/IEC 101647. Gestión de sistemas: función de recopilación de alarmas de seguridad.X.737. ISO/IEC 10164-14. Gestión de sistemas: clases de test de diagnóstico y confianza.X.738. ISO/IEC 1016413. Gestión de sistemas. Función de sumario.X.739. ISO/IEC 1016411. Gestión de sistemas. Métrica de objetos y atributos.X.740. ISO/IEC 101648. Gestión de sistemas. Función de pruebas de auditabilidad y seguridad.X.741. ISO/IEC 10164-9. Gestión de sistemas. Objetos y atributos para control de acceso.X.742. ISO/IEC 10164-10. Gestión de sistemas. Función de métrica de contabilidad.X.744. ISO/IEC 1016418. Gestión de sistemas. Función de gestión del software.X.745. ISO/IEC 10164-12. Gestión de sistemas. Función de gestión de test.X.746. ISO/IEC 10164-15. Gestión de sistemas. Función de inventario.X.750. ISO/IEC 10164. Conocimiento de gestión, función de gestión.

Otras normas de ITU-T relacionadas con gestión según TMN.

Q.811. Protocolos de capa baja para la interfaz Q3.Q.812. Perfiles de protocolo de capa alta para la interfaz Q3.Q.821. Etapas 2 y 3 de descripción de la interfaz Q3. Vigilancia de alarmas.Q.822. Descripción de las etapas 1, 2 y 3 para la interfaz Q3. Gestión de prestaciones.Q.823. Gestión de tráfico y encaminamiento.Q.824.0 - Q.824.6. Etapas 2 y 3 de descripción de la interfaz Q3. Administración de clientes.G.774. Modelo de información de gestión de SDH para los elemetos de red.G.774.01 Monitorización de prestaciones SDH para el elemento de red.G.774.02 Configuración SDH de la estructura de carga para el elemento de red.G.774.03 Gestión SDH de la protección de la sección multiplex para el elemento de red.G.774.04 Gestión SDH de la protección de la conexión de subred desde el elemento de red.G.784. Gestión SDH.G.atmn. Gestión ATM.G.mtn1 Gestión de redes de transmisión.

Recomendaciones para control y gestión de B-RDSI (ITU-T)

I.371. Control de tráfico y control de congestión.I.35B. Prestaciones en la red B-ISDN.I.610. Principios OAM.

RFCs de IETF

RFC Título Autor(es) Fecha Comentarios

1089 SNMP over Ethernet. M.L. Schoffstall, C. Davin, M. Fedor, J.D. Case. Feb 1989. none


Anexos 223

1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C.Davin. Apr 1989. OBSOLETES: RFC1067, OBSOLETED-BY: RFC1157

1155 Structure and Identification of Management Information for TCP/IP-based Internets. M. T.Rose, K. Z. McCloghrie. May 1990. OBSOLETES: RFC1065

1156 Management Information Base for Network Management of TCP/IP-based Internets. K. Z.McCloghrie, M. T. Rose. May 1990. OBSOLETES: RFC1066

1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C.Davin. May 1990. OBSOLETES: RFC1098

1158 Management Information Base for Network Management of TCP/IP- based Internets: MIB-II M. T. Rose. May 1990. OBSOLETED-BY: RFC1213

1161 SNMP over OSI. M.T. Rose. Jun 1990. OBSOLETED-BY: RFC14181187 Bulk table retrieval with the SNMP. M.T. Rose, K. McCloghrie, J.R. Davin. Oct 1990. none1213 Management Information Base for Network Management of TCP/IP- based Internets: MIB-

IIK. Z. McCloghrie, M. T. Rose. Mar 1991. OBSOLETES: RFC11581215 Convention for defining traps for use with the SNMP. M.T. Rose. Mar 1991. none1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. none1270 SNMP communications services. F. Kastenholz. Oct 1991. None1283 SNMP over OSI. M. Rose. Dec 1991. OBSOLETED-BY: RFC14181284 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Cook. Dec 1991.

none1285 FDDI Management Information Base. J. Case. Jan 1992. none1286 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K.

McCloghrie. Dec 1991. none1289 DECnet Phase IV MIB Extensions. J. Saperia. Dec 1991. none1298 SNMP over IPX. R. Wormley, S. Bostock. Feb 1992. OBSOLETED-BY: RFC14201303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. Feb 1992.

SEE-ALSO: RFC1155, RFC1212, RFC1213, RFC11571351 SNMP Administrative Model. J. Davin,J. Galvin,K. McCloghrie. Jul 1992. none1352 SNMP Security Protocols J. Galvin,K. McCloghrie,J. Davin. Jul 1992. none1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. Nov 1992. none1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop. Nov 1992. none1407 Definitions of Managed Objects for the DS3/E3 Interface Type. Tracy A. Cox, Kaj Tesink.

Jan 1993. OBSOLETES: RFC12331414 Identification MIB. M. StJohns & M. Rose. Jan 1993. none1418 SNMP over OSI. M. Rose. Feb 1993. OBSOLETES: RFC1161, RFC12831419 SNMP over AppleTalk. G. Minshall & M. Ritter. Feb 1993. none1420 SNMP over IPX. S. Bostock. Feb 1993. OBSOLETES: RFC12981441 Introduction to version 2 of the Internet-standard Network Management Framework. J. Case,

K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none1442 Structure of Management Information for version 2 of the Simple Network Management

Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).

J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none1444 Conformance Statements for version 2 of the Simple Network Management Protocol

(SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none1445 Administrative Model for version 2 of the Simple Network Management Protocol

(SNMPv2). J. Galvin & K. McCloghrie. Apr 1993. none1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J.

Galvin & K. McCloghrie. Apr 1993. none


Gestión de red224

1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K.McCloghrie & J. Galvin. Apr 1993. none

1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2).J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none

1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2).J. Case, K. McCloghrie, M. Rose, & S. Waldbusser Apr 1993. none

1450 Management Information Base for version 2 of the Simple Network Management Protocol(SNMPv2). J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none

1451 Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, & S.Waldbusser. Apr 1993. none

1452 Coexistence between version 1 and version 2 of the Internet-standard Network ManagementFramework. J. Case, K. McCloghrie, M. Rose, & S. Waldbusser. Apr 1993. none


Anexos 225

Anexo II: direcciones en Internet

Revistas

Publicaciones relacionadas con programación y gestión en Windows.

http://www.entmag.com/Maintech: el periódico independiente para Windows NT.

http://www.ntsystems.comWindows NT System Magazine

http://www.winntmag.comWindows NT Magazine

http://www.backoffice.comBackOffice Magazine

Página web de Open System Resources:http://www.osr.com/

Recursos de Internet

Desarrollos en Windows

http://www.microsoft.com/support/ftp://ftp.microsoft.com/

Grupos de News

comp.protocols.snmpinfo.snmptnn.protocols.snmpcomp.dcom.net-managementvmsnet.networks.management.misccomp.protocols.tcp-ipmicrosoft.public.management.comp.protocols.tcp-ip.ibmpccomp.os.ms-windows.networking.tcp-ipmicrosoft.public.windowsnt.protocol.miscmicrosoft.public.windowsnt.protocol.tcpipcomp.dcom.lans.ethernetcomp.os.ms-windows.programmer.win32


Gestión de red226

Páginas Web

SNMP

http://www.concentric.net/~tkvallil/snmp.htmlhttp://www.cisco.com/univercd/data/doc/cintrnet/ito/55029.htmhttp://www.snmpinfo.com/http://snmp.net.cmu.edu/bin/snmpv2/http://www.ibr.cs.tu-bs.de/cgi-bin/sbrowser.cgihttp://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.htmlhttp://www.int.snmp.com/v2star.htmlhttp://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.htmlhttp://www.itu.int/itudoc/itu-t/rec/x/x200-499/x209_24177.htmlhttp://www.inria.fr/rodeo/personnel/hoschka/asn1.htmlhttp://www.csc.vill.edu/~cassel/netbook/asn1only/node4.html

Estándares de organizaciones

http://www.cis.ohio-state.edu/htbin/rfc/rfc1871.htmlhttp://www.cis.ohio-state.edu/htbin/rfc/rfc2200.htmlftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/std-faqcomp.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.htmlInternet 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)

Asignación de números a empresas

Assigned Numbers Authority (IANA):http://www.isi.edu/div7/iana/forms.html

Lista actual de asignación de numeración:ftp://ftp.isi.edu/in-notes/iana/assignments/ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

Gestión de red

http://netman.cit.buffalo.edu/Gestión de red, University of New York, Buffalo

http://snmp.cs.utwente.nl/The SimpleWeb

http://www.cforc.com/cwk/net-manage.cgiBase de datos de recursos de gestión de red.

http://www.cit.ac.nz/smac/nm210/Redes y gestión de redes.

http://www.ldv.e-technik.tu-muenchen.de/forsch/netmanage/netmanage_e.htmlRedes y gestión de sistemas, Technical University of Munich, Germany

http://www.microsoft.com/products/backoffice/management/Página deMicrosoft System y gestión de red

http://www.mindspring.com/~jlindsay/webbased.htmlPágina de gestión basada en web

http://www.microsoft.com/management/Productos de gestión Microsoft

http://wwwsnmp.cs.utwente.nl/~schoenw/ietf-nm/RFCs de gestión de red. IETF


Gestión de red228

http://www.elec.uow.edu.au/anmf/index.htmlForum de gestión de red australiano

http://www.javasoft.com/products/JavaManagement/document.htmlDocumentos de gestión de Java

http://www.aetc.af.mil/AETC-NetMgmt/nms-menu.htmlEvaluación de sistemas de gestión de red.

http://www.phoaks.com/phoaks/comp/dcom/net-management/resources3.htmlPágina de gestión de PHOAKS: comp.dcom.net-management

WinSNMP

http://www.winsnmp.com/Tutoriales WinSNMP, freeware, e información.

http://www.acec.com/snmp.htmAce*Comm WinSNMP

http://www.mg-soft.si/MG-WinSNMP SDK, MG-WinMIB SDK, WinSNMP. Ejemplos de código fuente.

http://www.ftp.com/pr/wsnmp.htmWinSNMP Software Development Kit

ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsnmp/http://www.fastin.com/cdrom2/winsnmp/Sunsite.UNC.EDU WinSNMP archivo

WinSock

http://www.winsock.com/Stardust WinSock Labs

http://www.sockets.com/Página de desarrollo de WinSock de Bob Quinn's

http://www.goodnet.com/~esnible/winsock.htmlWindows Sockets Programming

http://www.intel.com/IAL/winsock2/index.htmIntel WinSock 2

http://www.data.com/Tutorials/Winsock_2.htmlTutorial WinSock 2

http://webcom.com/~llarrow/winsock.htmlArchivos 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.htmlColección 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.htmlArchivo Krakow,

http://www.phoaks.com/phoaks/alt/winsock/Páginas PHOAKS alt.winsock.

Ethernet

http://wwwhost.ots.utexas.edu/ethernet/Página Ethernet de Charles Spurgeon.

http://www.lantronix.com/htmfiles/mrktg/catalog/et.htmTutorial Ethernet

http://netlab1.usu.edu/novell.faq/nvfaq-l.htmEthernet

http://pclt.cis.yale.edu/pclt/comm/ether.htmRedes Ethernet

http://www.cavebear.com/CaveBear/Ethernet/Códigos Ethernet

http://www.phoaks.com/phoaks/comp/dcom/lans/ethernet/resources0.htmlEthernet PHOAKS comp.dcom.lans.

http://www.yahoo.com/Computers_and_Internet/Communications_and_Networking/LANs/Ethernet/Página Ethernet Yahoo!'s

TCP/IP

http://www.ftp.com/FTP Software


Gestión de red230

http://www.dart.com/Power TCP Internet Toolkit

http://www.distinct.com/home.htmDistinct TCP/IP

http://www.kaon.co.nz/netmanage/cham.htmlChameleon y Chameleon NFS

http://www.netinst.com/html/wscomp.htmlWinSock 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.htmlGuía del comprador TCP/IP

http://www.phoaks.com/phoaks/comp/protocols/tcp-ip/resources0.htmlPágina PHOAKS comp.protocols.tcp-ip

http://www.microsoft.com/win32dev/netwrk/tcpiphom.htmRedes: Microsoft TCP/IP y Windows 95

http://pclt.cis.yale.edu/pclt/comm/tcpip.htmIntroduction to TCP/IP

Telecomunications Management Network (TMN)

http://www.delta.dk/se/icm/ni.htmhttp://www.broadcom.ie/p812/reference/probehttp://www.ics.forth.gr.http://www.isrglobal.com/snmpwp.htm.http://www.itu.int/itunews/199602/standard.htm.http://www.webproforum.com/vertel.

Gestión en comunicaciones móviles

http://www.ee.surrey.ac.ukhttp://www.cdg.orghttp://www.gsmdata.comhttp://www.itu.chhttp://www.etsi.frhttp://www.gsmworld.comhttp://www.pcsdata.com


Anexos 231

Archivos de módulos 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

Obtención de RFCs para gestión 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 vía 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.


Documents

Gestión_De_Red_-_Antoni_Barba_Martí_-_UPC