RIELAC, Vol. XXXVII 2/2016 p.

39-53 Mayo - Agosto ISSN: 1815-5928

Sistema para la gestión en redes no

comerciales de los SLA en la etapa de
ejecución
Guillermo Gafas Cabrera, Caridad Anías Calderón

RESUMEN / ABSTRACT
Actualmente las empresas que proveen servicios de telecomunicaciones deberían establecer acuerdos de nivel de servicio
con sus clientes para acordar y fijar la calidad de los servicios a ofrecer. Establecer estos acuerdos permite obtener múltiples
beneficios tanto a los clientes como a los proveedores de los servicios. Existen varias iniciativas para la estandarización de
los mencionados acuerdos pero estas presentan una complejidad elevada, por ello, aplicarlas en redes de entidades que
ofrecen servicios de telecomunicaciones de manera no comercial resultaría complejo, además, las herramientas que
permiten gestionar estos acuerdos son generalmente software propietario. En este artículo se presenta una propuesta
desarrollada para ser aplicada en redes de telecomunicaciones no comerciales que permite la gestión de los acuerdos de
nivel de servicio en la etapa de ejecución. Para comprobar el funcionamiento de la propuesta realizada se desarrolló un
software que también se presenta.
Palabras claves: acuerdos de nivel de servicio, redes de telecomunicaciones no comerciales
At present the companies that provide telecommunications services need to establish service level agreements with
customers to agree and set the quality of services to offer. To establish service level agreements allow for multiple
benefits to customers and service providers. There are a lot of existing initiatives for standardization of those agreements
in various scenarios, but these have a high complexity and apply them to networks of entities that provide
telecommunications services in non-commercial way would be complex and the tools to manage such agreements are
generally proprietary software. In this article it is established a proposal to be applied to non-commercial networks that
allows to manage service level agreements at the execution stage. To check out the operation of the proposal a software
was developed, that is also showed up in this article.
Key words: service level agreements, non-commercial telecommunications networks
SLA Management at the execution stage in non-commercial networks

1.- INTRODUCCIÓN
En los últimos años la variedad de servicios ofrecidos por las empresas de telecomunicaciones se ha incrementado
drásticamente, haciéndose necesario una correcta gestión de los mismos para lograr, entre otros, mejorar la disponibilidad y
calidad de los servicios, aumentar la satisfacción de los usuarios y disminuir los costos. El establecimiento de acuerdos de
nivel de servicio (SLA, Service Level Agreement) entre el proveedor de servicios y el cliente permite, entre otros aspectos,
acordar y gestionar la calidad de los servicios ofrecidos y las penalidades que se aplicarán por incumplimiento de los
términos del acuerdo [1].
Existen multitud de iniciativas para la estandarización de los SLA en diversos escenarios. Estas iniciativas presentan
generalmente un nivel de complejidad elevado, por lo que aplicarlas en redes de entidades que ofrecen servicios de
telecomunicaciones de manera no comercial (para los efectos de este trabajo redes no comerciales) resulta complejo.

39
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
Por otra parte, se debe contar con herramientas software que permitan gestionar los SLA que se establecen con los clientes.
La mayoría del software que es empleado para la gestión de SLA es propietario, por lo que resulta difícil encontrar
aplicaciones que se puedan utilizar con este propósito en redes no comerciales.
Lo antes planteado llevó a los autores a diseñar un sistema que permitiera la gestión de los SLA de manera eficiente en
redes no comerciales. Para su diseño se tuvo en cuenta el ciclo de vida de un SLA según la UIT-T, haciendo énfasis en la
etapa de ejecución, ya que resulta ser la más crítica para la gestión de los SLA producto a los mecanismos de supervisión y
control que involucra [2]. El sistema que se diseñó posee varios bloques y para comprobar su funcionamiento se desarrolló
un software que permite la gestión de los SLA en la etapa de ejecución, en el tipo de redes analizado.

2.- INICIATIVAS EXISTENTES PARA LA GESTIÓN DE LOS SLA

Dada la importancia y la gran cantidad de datos involucrados en los SLA se requiere contar con sistemas automatizados
para su gestión. Para la estructuración del sistema que se propone resultó necesario profundizar en los procesos
involucrados en la gestión de los SLA en la etapa de ejecución, de las iniciativas propuestas por organismos rectores para su
normalización y estandarización. En la actualidad existe una multitud de iniciativas para la estandarización de los SLA en
diversos escenarios. En la tabla 1 se recopilan 45 organismos e iniciativas que proponen mecanismos para dicha
estandarización [3].
Tabla 1
Iniciativas para la estandarización de los SLA [Fuente: [3]]
ATIS CSF CSA IEEE-SA NIST CCP OSCA
CCF CSCC IETF OAGi OSGi
CCIF DMTF CMWG ISO/IEC JTC 1/SC 7 OASIS SNIA
CCPPF ENISA ISO/IEC JTC 1/SC 27 OCC TIA
CCSWG ETSI TC CLOUD ISO/IEC JTC 1/SC 38 ODCA TMForum
CCUCDG EuroCloud ITU-T FG Cloud ODL TOG
CENELEC ETSI CSC ITU-T JCA Cloud OGF W3C
CESI FIRST CVSS SIG JCC OMG W3C HTML WG
CIF GICTF KCSA OpenStack ITIL

Luego de un análisis de varias iniciativas, entre las que destacan las propuestas por el TMForum, UIT-T e ITIL se llegó a la
conclusión de que presentan un nivel de complejidad elevado, por lo que aplicarlas a los servicios brindados en redes no
comerciales resulta complejo. Entre las iniciativas antes mencionadas se encuentra el Mapa de Operaciones de las
Telecomunicaciones mejorado (eTOM, enhanced Telecomunication Operations Map), desarrollado por el TMForum, que
brinda todo un marco de procesos en el que se especifican, entre otros, los procesos involucrados en la gestión de los SLA
en la etapa de ejecución [4]. Aunque este marco resulta muy complejo para ser aplicado en redes no comerciales e involucra
la facturación por los servicios brindados, algo de menor interés en este tipo de redes, por su profundidad fue el
seleccionado como base para desarrollar la propuesta del sistema para la gestión en redes no comerciales de los SLA en su
etapa de ejecución.
Para el desarrollo del sistema, así como la conformación del software, fue necesario el análisis de algunas de las
herramientas existentes para la gestión de los SLA. Entre las herramientas analizadas se destacan ServiceDesk Plus, IT SLA
Monitoring and Reporting, Gestar ITIL y FrontRange ITSM. Cada herramienta posee diversos módulos y funcionalidades e
involucran la gestión de SLA de uno o más servicios.
Estas herramientas están basadas en algunas de las iniciativas mencionadas con anterioridad e implican elementos de
facturación de los servicios. Por otra parte las herramientas analizadas están sujetas al uso de licencias para su operación,
por lo que se hace difícil encontrar aplicaciones que se puedan utilizar para la gestión de los SLA en la etapa de ejecución
en redes no comerciales.

3.- SISTEMA PARA LA GESTIÓN DE LOS SLA EN LA ETAPA DE

EJECUCIÓN
En el diseño del sistema de gestión de los SLA en su etapa de ejecución se consideró una base de datos (UISLA, Unidad de
Información de SLA) centralizada y accesible para todos los bloques del sistema. En UISLA deben estar almacenados los
detalles de cada uno de los SLA contratados y los recursos que se encuentran asociados a cada uno de los servicios que se
40
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
brindan a los clientes. Además el sistema está compuesto por cuatro bloques funcionales:
• Bloque “Recolección de datos”
• Bloque “Gestión del desempeño de los recursos y servicios”
• Bloque “Gestión de incidencias”
• Bloque “Gestión del SLA”
En la figura 1 se observa el diagrama general del sistema diseñado para la gestión de los SLA. Vale aclarar que por ser un
sistema diseñado para redes no comerciales, no se tomó en cuenta la dependencia de la facturación con el cumplimiento de
los SLA. Los bloques que componen el sistema interactúan con la base de datos obteniendo e insertando diversos tipos de
información.
La interfaz con el cliente del servicio (SC, Service Customer) representa la vía de comunicación que existe entre el SP y el
SC y permite que este último pueda informar al SP los problemas que detecte en el servicio. Esta interfaz también es
empleada por el SP para hacer llegar los reportes de calidad de servicio (QoS, Quality of Service) al SC.
Los bloques del sistema propuesto pueden interactuar entre sí y con la base de datos UISLA y están compuestos por
diversos sub-bloques que les proporcionan sus funcionalidades.. A continuación se analizan los bloques que conforman el
sistema que se propone para la gestión de los SLA en la etapa de ejecución.

3.1.- BLOQUE RECOLECCIÓN DE DATOS

Este bloque lleva a cabo la primera fase del sistema. El mismo permite recolectar, procesar y almacenar información
proveniente del monitoreo constante de las instancias de los recursos y servicios involucrados en los SLA. La información
recopilada puede ser:
• Datos de desempeño de los recursos y servicios.
• Información de uso de los recursos y servicios.
• Otros eventos, como alarmas de fallos.
Este bloque puede emplear diversas políticas o mecanismos de monitorización entre los que se encuentran el sondeo o
polling, informe de eventos o notificaciones, proxys y sondas.

Figura 1
Diagrama general del sistema propuesto [Fuente: Propia]
41
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
En esta fase es muy importante la interacción con la base de datos centralizada UISLA para obtener información como:
• Detalles de los recursos/servicios a monitorear (enrutadores, conmutadores, PCs y aplicaciones, entre otros).
• Parámetros a monitorear para cada recurso/servicio.
• Frecuencia de monitorización para cada elemento.
• Mecanismos de monitorización a emplear.
Existen eventos que desencadenan la acción de monitorización sobre los recursos y servicios, estos pueden ser:
• Eventos automáticos del propio bloque de recolección de datos, regidos por la frecuencia de monitorización
establecida para cada recurso/servicio en particular.
• Solicitud de otro bloque (evento desencadenado cuando el bloque “Gestión de incidencias” necesita contar con
información actualizada).
Las responsabilidades de este bloque también abarcan:
• Procesamiento de los datos a través de mecanismos de filtrado (según criterios pre-establecidos) y formateado de la
información (agregación y transformación).
• Almacenamiento de la información en la base de datos centralizada UISLA para que pueda ser empleada por los
restantes bloques que conforman el sistema.
Para llevar a cabo su propósito, en el bloque Recolección de Datos está conformado por los siguientes sub-bloques:
“Control de Monitorización”, “Encuesta”, “Gestor”, “Filtrado” y “Normalización” (ver figura 2).
El sub-bloque que controla la monitorización obtiene de la base de datos los recursos/servicios y los parámetros a
monitorear, así como los mecanismos de monitoreo que se deben emplear para dichos recursos/servicios, el período de
monitorización y otros detalles necesarios para el proceso de supervisión. Este sub-bloque, además, es capaz de recibir una
indicación del bloque “Gestión de incidencias” para activar el monitoreo de un recurso/servicio específico. Una vez
obtenidos los detalles de los recursos/servicios a monitorear, este sub-bloque ejecuta el mecanismo de monitoreo que se va a
emplear.
En el diseño del sistema que se propone se consideraron como mecanismos posibles de monitorización la encuesta al
recurso/servicio o la existencia de un agente del lado del mismo que recopila la información necesaria y la notifica. En caso
de que el mecanismo empleado sea el de encuesta, se conforma la solicitud que se emite al recurso/servicio con el objetivo
de recibir respuesta por parte del mismo (esto se realiza en el sub-bloque “Encuesta”) y se interactúa con el recurso/servicio
mediante el envío de la misma. En caso de que el recurso emplee un agente se le cede el proceso de interacción con el
mismo al sub-bloque “Gestor”.

Figura 2
Bloque Recolección de datos [Fuente: Propia]

42
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
Una vez obtenidos los datos de desempeño, por cualquiera de los mecanismos antes mencionados, estos se pasan a los sub-
bloques “Filtrado” y “Normalización”. En el primero se filtra la información recibida según criterios previamente
establecidos, lo que permite desechar la que no sea necesaria. En el segundo sub-bloque se lleva a cabo la normalización de
la información lo que incluye el formateado de la misma (agregación y transformación) para su correcta inserción en la base
de datos.

3.2.- BLOQUE GESTIÓN DEL DESEMPEÑO DE LOS RECURSOS Y

SERVICIOS
Este bloque vigila el nivel de servicio que los recursos y servicios ofrecen, verificando su correcta operación en todo
momento. Abarca la supervisión, análisis, control y notificación de su desempeño. Trabaja con información básica
almacenada previamente en la base de datos del sistema por el bloque de “Recolección de datos”, procesándola de diversas
formas para, por ejemplo, obtener estadísticas y conformar los indicadores clave de desempeño (KPI, Key Performance
Indicators), que no deben superar los valores umbrales establecidos (que se obtienen de UISLA) para que el servicio
funcione de manera correcta.
En sentido general las responsabilidades de este bloque incluyen:
• Obtener la información, almacenada en la base de datos, para el procesado de los parámetros de desempeño con
vistas a la conformación de los KPI.
• Adquirir, en la base de datos, los valores umbrales establecidos para los KPI, los que se requieren para verificar el
correcto funcionamiento del recurso/servicio.
• Comparar los valores umbrales de los KPI con los obtenidos.
• Detectar violaciones en los umbrales establecidos, lo que representa una degradación en la calidad del servicio
ofrecido, debido a un posible fallo en los recursos que soportan a los servicios o a un cuello de botella creado por
un uso elevado de los mismos. La detección temprana de la degradación del desempeño de recursos y servicios
también posibilita actuar de manera proactiva, evitando fallos de gran magnitud.
• Informar al bloque de “Gestión de incidencias” los elementos afectados debido a violaciones de umbrales de los
KPI, lo que desencadena la actividad de restauración necesaria.
Para realizar sus funciones, el bloque Gestión del desempeño de los recursos y servicios se ha considerado formado por tres
sub-bloques: “Obtención de información de desempeño”, “Procesado de las estadísticas” y “Analizador”. La figura 3
recoge los detalles de las funcionalidades de este bloque.

Figura 3
Bloque Gestión del desempeño de los recursos y servicios [Fuente: Propia]
43
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
El sub-bloque “Obtención de información de desempeño” es el encargado de interactuar con la base de datos UISLA para
obtener la información de desempeño, los valores umbrales de los KPI y los valores de alerta. Además, recibe solicitudes
del bloque “Gestión de incidencias” que le indica evaluar los parámetros de un determinado recurso/servicio e interactúa
con el sub-bloque “Procesado de las estadísticas” para entregarle los datos de desempeño que le permiten conformar los
KPI. También se comunica con sub-bloque “Analizador” para indicarle los distintos rangos posibles de los parámetros de
desempeño.
El sub-bloque “Procesado de las estadísticas” realiza diversas funciones en dependencia del parámetro de nivel de servicio
que esté evaluando. El procesado de los parámetros puede variar notablemente de uno a otro según la naturaleza del mismo.
El sub-bloque “Analizador” se encarga de comparar las estadísticas procesadas (los KPI conformados) con los rangos
establecidos en los SLA. Esto le permite detectar si los parámetros procesados se encuentran en un rango normal, en el
rango de alerta o si se ha producido una alarma (por ejemplo, cuando el servicio no se encuentra activo). Acorde con los
resultados obtenidos del análisis, emite al bloque de “Gestión de incidencias” un informe de estado de los KPI, si estos se
encuentran en el rango normal, o una alerta o alarma, si existe algún problema indicando, en este caso los detalles del
incidente.

3.3.- BLOQUE GESTIÓN DE INCIDENCIAS

El bloque “Gestión de incidencias” cubre todo tipo de incidencias, ya sean fallos, consultas realizadas por el personal
técnico o por los usuarios (generalmente mediante una llamada al centro de asistencia), o problemas detectados de forma
automática por las herramientas de monitoreo. El objetivo principal de este bloque es restaurar lo antes posible el servicio a
su funcionamiento normal, garantizando niveles de calidad y disponibilidad elevados.
Hay algunos conceptos básicos a tener en cuenta en la gestión de incidencias:
• Límites de tiempo: Se deben definir límites de tiempo para cada uno de los niveles de gestión.
• Modelos de incidencias: Permite determinar rápidamente el procedimiento adecuado para atender las incidencias,
lo que facilita que las que son estándar se gestionen de forma correcta y en el tiempo establecido.
• Incidencias graves: Requieren un procedimiento distinto al estándar, con plazos más cortos, debido a su urgencia.
Se debe definir lo que es una incidencia grave, así como precisar las prioridades para la atención a estas
incidencias.
• Escalado funcional: Consiste en involucrar o transferir un fallo o problema a un equipo técnico con mayor
experiencia para que ayude en su solución.
• Escalado jerárquico: Involucrar o transferir un fallo o problema no resuelto a niveles de gestión más elevados para
su solución.
La capacidad para resolver las incidencias en un tiempo determinado es fundamental al ofrecer servicios. Para ello, entre
otros elementos, la gestión de incidencias debe tener acceso a los SLA almacenados en la base de datos ya que es esencial
que se disponga de información puntual sobre los recursos asociados a los servicios brindados.
Una herramienta que posibilite la gestión de incidencias debe gestionar las averías técnicas de los servicios ofrecidos y
almacenar toda la información relevante, en referencia a la incidencia, siguiendo un flujo de trabajo que defina los estados
por los que pasa la misma, los grupos técnicos que deben tratarla, y las notificaciones o acciones automáticas a realizar. De
acuerdo con lo antes planteado, el empleo de una herramienta de gestión de incidencias tiene tres objetivos básicos:
• Minimizar los periodos “fuera de servicio”.
• Registrar la información relevante de todas las incidencias.
• Incorporar, de forma sistemática, las mejores prácticas de solución de incidencias.
En la figura 4 se muestra el diagrama detallado del bloque “Gestión de incidencias”, el cual se encuentra compuesto por
diversos sub-bloques que realizan variadas funciones. Para poder explicar el funcionamiento de este bloque se analizarán
dos situaciones: a la interfaz de entrada le llega un incidente que representa una alerta o alarma y, a la interfaz de entrada
llega un reporte de problemas emitido por el cliente del servicio. Si a la interfaz de entrada llega un reporte de estado lo que
ocurre se explica en las dos situaciones planteadas.
Situación 1: Alerta o Alarma en la interfaz de entrada
• La alerta o alarma que se recibe es emitida por el bloque de “Gestión del desempeño de los recursos y servicios”, la
44
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
cual indica los detalles de la incidencia ocurrida por ejemplo: Fecha, id_recurso(s), id_servicio(s), KPI afectados y
valores de los KPI.
• Se correlaciona la incidencia que se recibe con las incidencias pendientes de solución existentes en UISLA, con el
objetivo de determinar si existen incidencias por la misma causa aún no solucionadas.
• Si existe alguna incidencia pendiente registrada por la misma causa aún no solucionada, se actualiza el estado de la
misma en la base de datos. Si este no es el caso, se agrega (registra) la nueva incidencia a la lista de incidencias
pendientes y se emite una alerta o alarma al operador.
• Se correlaciona la incidencia actual con incidencias ya solucionadas, ocurridas con anterioridad por la misma
causa. Esto le brinda al operador un historial de posibles soluciones, lo que le ayuda a resolver más rápidamente el
problema reportado en la incidencia.

Figura 4
Bloque Gestión de incidencias [Fuente: Propia]
45
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
• Se ejecutan las acciones correspondientes para la solución, lo que requiere interactuar con una base de datos que
contenga la configuración de todos los recursos y servicios. Esta interacción consiste en la solicitud de datos de
configuración y, luego de ejecutar las acciones necesarias para la solución, la actualización del estado de la
configuración de los recursos y servicios que hayan sido modificados.
• A continuación, es necesario verificar que los cambios efectuados hayan tenido la repercusión esperada. Para esto
se le indica a los bloques de “Recolección de datos” y “Gestión del desempeño de los recursos y servicios” que
lleven a cabo un análisis del estado actual de los recursos y servicios especificados y se espera por el reporte de
estado emitido por el último bloque.
• Cuando llega el reporte de estado se lleva a cabo un análisis de incidencias para determinar si corresponde a la
solicitud de un reporte de problemas emitido por el SC o a la verificación de que la incidencia ha sido solucionada.
• En caso que la incidencia haya sido solucionada se procede al cierre de la misma, registrando en la base de datos de
UISLA las acciones llevadas a cabo para dar solución al problema, lo que es útil para futuras consultas.
• Si el problema aún no ha sido solucionado se actualiza el estado de la incidencia en la base de datos. Una
característica importante de este bloque es que tiene en cuenta que si el tiempo para el tratamiento de una
incidencia en un nivel ha vencido, esta debe ser escalada al nivel inmediato superior. En caso de que dicho tiempo
aún no haya vencido se vuelve a empezar el ciclo trabajando en otra posible solución.
Situación 2: Reporte de problemas por el SC en la interfaz de entrada
• A la interfaz de entrada le llega el reporte de un posible problema detectado por el SC.
• El proceso continúa con la correlación con las incidencias pendientes. Si no existen incidencias pendientes por la
misma causa se procede a su registro y se emite una alarma al operador.
• Se procede a analizar el estado de los recursos y servicios implicados en el reporte del problema. Para esto se
activan los bloques de “Recolección de datos” y “Gestión de desempeño de los recursos y servicios” indicando los
recursos y servicios a monitorear, siendo necesario obtener de la base de datos correspondiente los detalles de los
recursos y servicios implicados.
• Se espera por el reporte de estado para determinar si existe o no un problema. Si el problema no existe se procede a
dar cierre a la incidencia y a reportarle al SC que realmente no existen problemas en el servicio que está
recibiendo.
• Si realmente existe un problema se procede al ciclo de solución de la incidencia mencionado en la primera
situación.

3.4.- BLOQUE GESTIÓN DEL SLA

El bloque “Gestión del SLA” es el encargado de llevar el registro y control de las violaciones incurridas en los SLA y de
emitir los informes de QoS a los clientes. Las responsabilidades de este bloque incluyen:
• Obtención, desde la base de datos, de los detalles de los recursos asociados a cada instancia de servicio.
• Adquisición y procesado (de manera parcial y global) de los parámetros de desempeño almacenados en la base de
datos para conformar los KPI que se incluyen en el SLA.
• Obtención en la base de datos de los valores “objetivo” acordados para los parámetros de nivel de servicio.
• Comparación de los valores “objetivo” con los valores de los parámetros procesados.
• Clasificación de las violaciones incurridas a los SLA.
• Conformación de los informes de QoS emitidos al cliente.
En la figura 5 se pueden observar los detalles de la estructura del bloque “Gestión del SLA” el cual está compuesto, a su
vez, por los sub-bloques:
• “Procesado de las estadísticas”.
• “Análisis de las violaciones”.
• “Conformación del informe de QoS”.
El sub-bloque “Procesado de las estadísticas” es el encargado de realizar el análisis de todos los parámetros que se
establecieron en el SLA. Realiza el análisis de las estadísticas recopiladas por el bloque “Recolección de datos” de manera
46
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
parcial y global. El análisis parcial generalmente se lleva a cabo para conocer el desempeño del servicio en un período
determinado y usualmente se utiliza para la elaboración de los informes periódicos de QoS. El análisis global abarca a todas
las estadísticas en un período mayor (generalmente mensual) y se efectúa para verificar las violaciones ocurridas a los SLA
y para la emisión del reporte mensual de QoS.
El procesado de las estadísticas varía en dependencia del parámetro de nivel de servicio que se desea comprobar.
Determinados parámetros, como la latencia promedio y el jitter promedio, involucran el promediado de las estadísticas
obtenidas a lo largo del período establecido. Por otra parte existen parámetros, como la disponibilidad y el tiempo medio
entre fallos, que dependen de expresiones para su cálculo, por lo que primeramente es necesario procesar las variables de las
que dependen estos parámetros para luego calcular los mismos.

Figura 5
Bloque Gestión del SLA [Fuente: Propia]

El sub-bloque “Procesado de las estadísticas” interactúa con la base de datos UISLA para obtener los parámetros de nivel de
servicio que debe evaluar para cada instancia del servicio, así como las estadísticas acumuladas. También interactúa con los
sub-bloques “Conformación del informe de QoS”, al que le envía los parámetros evaluados, y “Análisis de las violaciones”,
al que le hace llegar el análisis global de los parámetros de nivel de servicio.
El sub-bloque “Análisis de las violaciones” recibe, como se mencionó anteriormente, los parámetros de nivel de servicio ya
evaluados, además de los valores “objetivo” para cada uno de estos parámetros y los rangos para las distintas magnitudes de
violación establecidas en el SLA. Con esta información, se encarga de comparar los valores de los parámetros de nivel de
servicio con los valores acordados y determinar si ha ocurrido o no una violación. En caso de ocurrir una violación, la
clasifica teniendo en cuenta los rangos establecidos para las distintas magnitudes de violación en el SLA. La información
resultante se envía al sub-bloque “Conformación del informe de QoS” para emitir el informe mensual de QoS al cliente.
El sub-bloque “Conformación del informe de QoS” se encarga de la elaboración del informe que se envía al cliente para que
este conozca la calidad del servicio que recibe. Este bloque obtiene de la base de datos la frecuencia de envío del informe, el
o los mecanismos para su presentación al cliente y la información que debe estar reflejada en el mismo. Además, recibe del
sub-bloque “Procesado de las estadísticas” el análisis de los parámetros procesados de manera parcial o global, en
dependencia de si el informe es el emitido periódicamente o el que se emite una vez al mes. En caso de que el informe sea
emitido mensualmente, se recibe desde el sub-bloque “Análisis de las violaciones” las violaciones incurridas durante el
período. Finalmente, el informe se conforma y se envía al cliente mediante la(s) vía(s) acordada(s) en los mecanismos de
presentación y con la frecuencia establecida en el SLA.

4.- SOFTWARE DESARROLLADO PARA GESTIONAR EN REDES NO

COMERCIALES LOS SLA EN LA ETAPA DE EJECUCIÓN
El software desarrollado tiene como objetivo validar el diseño del sistema de gestión de los SLA en la etapa de ejecución.
Para su elaboración se utilizó como lenguaje de programación C# y se empleó Microsoft Visual Studio 2012, por sus
posibilidades de personalizar y conformar la interfaz gráfica.
47
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
Con el propósito de que el código empleado fuera totalmente compatible con un sistema operativo GNU/Linux, se
programaron las funcionalidades del software utilizando MonoDevelop ejecutándose sobre Ubuntu 12.04. El sistema gestor
de base de datos empleado fue SQLite, escogido por su simplicidad y eficiencia.
La interfaz gráfica se realizó utilizando los formularios de Windows, ya que los brindados por MonoDevelop para crear
interfaces gráficas pertenecen a GTK (Kit de herramientas de programas para manipulación de imágenes de GNU, GNU
Image Manipulation Program Tool Kit) y el trabajo con los mismos resulta difícil.
El software realizado está compuesto por dos módulos principales: el módulo “Monitor” y el módulo “Ejecución del SLA”.
El módulo “Monitor” es un programa de consola que rige su funcionamiento mediante un script, que se explicará
posteriormente, y es el encargado del bloque “Recolección de datos”. El módulo “Ejecución del SLA” es un programa que
cuenta con una interfaz gráfica con el usuario y que contiene a los restantes bloques del sistema de gestión de los SLA en la
etapa de ejecución.
Para el correcto funcionamiento del software desarrollado se deben tener en cuenta los requerimientos siguientes:
• Ejecutarlo en un sistema operativo basado en GNU/Linux y no en sistemas operativos basados en Windows o Mac.
• Contar con una instalación de Mono que permita ejecutar programas basados en .NET versión 4.0 (en los
repositorios de Ubuntu 12.04 se encuentra la instalación necesaria de Mono). Además, se debe poseer permisos
administrativos y ejecutar, en la línea de comandos, la sentencia: sudo apt-get install mono, la que permite
instalar el lenguaje común de infraestructura que es utilizado para correr aplicaciones compiladas en .NET.
• Instalar el paquete apache_utils que contiene la aplicación apache_bench. Este paquete se encuentra disponible en
la mayoría de los repositorios. Para la instalación del mismo se debe ejecutar en la línea de comandos la sentencia:
sudo apt-get install apache_utils.
• Poseer, en la localización donde se va a ejecutar la aplicación, permisos administrativos que permitan la ejecución,
creación y modificación de archivos, ya que el software desarrollado durante su ejecución hace uso de archivos
temporales.
• Tener instalado SQLite para lo cual se emplea la sentencia: sudo apt-get install sqlite.

4.1.- MÓDULO “MONITOR”

El módulo “Monitor”, como ya se mencionó previamente, es el encargado de ejecutar el bloque “Recolección de datos”.
Este módulo no posee interfaz gráfica ni brinda la posibilidad de interacción con el usuario, su trabajo consiste en la
recopilación, filtrado, formateo y almacenamiento de las estadísticas de desempeño.
Aunque los sistemas empleados para gestionar niveles de servicio deben permitir el monitoreo de diversos elementos, en la
realización de este software, cuyo objetivo era solamente validar el funcionamiento de la propuesta realizada, se consideró
que existe un solo recurso/servicio a monitorear. Esto evita invertir esfuerzos en la conformación de este módulo para
dedicarlos al módulo “Ejecución del SLA”, lo que es admisible dado que este no varía sustancialmente con el
recurso/servicio que se desea monitorear. Se consideró que se brinda un único servicio Web a múltiples usuarios.
El módulo “Monitor” se encuentra formado por un script y por la aplicación [Link]. El script se encarga de recopilar
las estadísticas de desempeño antes de la ejecución del programa [Link]. Para ello emplea dos aplicaciones: la
aplicación apache_bench (ab) y la aplicación wget, que interactúan con el servicio Web para obtener los parámetros de
desempeño. Los parámetros de desempeño a monitorizar fueron la disponibilidad y el tiempo medio por solicitud [5].
La aplicación ab se utiliza para emitir un número determinado de solicitudes a un servidor Web, con el objetivo de obtener
diversos parámetros que permitan conocer el desempeño del servicio. Por su parte la aplicación wget se utiliza para conocer
el estado del servicio Web permitiendo saber si el servicio se encuentra o no activo, sin necesidad de descargar contenido
del sitio.
Una vez obtenidas las estadísticas de desempeño mediante las aplicaciones ab y wget se procede a la ejecución del
programa [Link]. Este programa es una aplicación de consola que se abastece de los archivos temporales creados por
las aplicaciones ab y wget para realizar el filtrado de la información que contienen. Este filtrado elimina toda la información
que no es necesaria o que es redundante, por ejemplo, a partir del tamaño de los documentos que fueron descargados, del
número de solicitudes completadas y del tiempo que tomó la descarga se pueden obtener indicadores como son: el tiempo y
la velocidad de transferencia promedio por solicitud y el tráfico total cursado. Luego del filtrado de la información, el
programa [Link] formatea y almacena la información en la base de datos.

48
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928

4.2.- MÓDULO “EJECUCIÓN DEL SLA”

Como ya se mencionó, este módulo es el encargado de implementar las funcionalidades de los restantes bloques del sistema
propuesto para la gestión de los SLA en la etapa de ejecución. Posee una interfaz gráfica, que fue realizada utilizando los
formularios de Windows, cuatro formularios principales y varios formularios secundarios, estos son:
1. Formulario “Gestión de ejecución de SLA”
2. Formulario “Gestión de desempeño”
o Formulario “Detalles de indisponibilidad”
3. Formulario “Gestión de incidentes”
o Formulario “Modificar incidente”
o Formulario “Base del conocimiento”
4. Formulario “Gestión del SLA”
o “Detalles SLA”
El primer formulario que se presenta al ejecutar el programa desarrollado es el de “Gestión de ejecución de SLA”, el cual
representa la vía de acceso a los restantes formularios que componen el software. El mismo brinda información general
sobre el estado del servicio, indicando si el servicio se encuentra activo y el número de incidencias pendientes (incidencias
que no han sido solucionadas y que por lo tanto permanecen activas). Además indica, en incidencias no revisadas, las
incidencias que han ocurrido y que se han solucionado sin reportarle al sistema los detalles de su solución.
El formulario “Gestión de desempeño” recoge las funcionalidades más importantes del bloque “Gestión del desempeño de
los recursos y servicios”. Este formulario, además, posee un formulario secundario, el de “Detalles de indisponibilidad”.
Ambos formularios se pueden apreciar en la figura 6.

Figura 6
Formularios “Gestión de desempeño” y “Detalles de indisponibilidad” [Fuente: Propia]
Adicionalmente, el formulario “Gestión de desempeño” brinda el resultado del procesado de los parámetros de desempeño,
los que deben ser actualizados periódicamente para que sea posible velar por el estado de los mismos. También este
formulario permite cargar una tabla con más información (sin procesar) relacionada con los datos de desempeño, lo que
posibilita analizar en qué momento ocurrió una degradación el servicio o en qué momento el servicio se encontraba
trabajando con más holgura.
Además, a través del formulario “Gestión de desempeño” se puede conocer el tiempo total en el que el servicio ha estado
49
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
indisponible, por cualquier razón, así como el número de veces en que esto ha ocurrido. Para obtener información más
detallada sobre las indisponibilidades se puede desplegar el formulario “Detalles de indisponibilidad” que desglosa, por
fecha, las interrupciones al servicio indicando el tiempo que el mismo estuvo inactivo.
El formulario “Gestión de incidentes” implementa las principales funcionalidades del bloque “Gestión de incidencias”.
Cuenta con dos formularios secundarios: “Modificar incidente” y “Base del conocimiento”. Este formulario permite conocer
los incidentes que están ocurriendo en ese momento (incidentes pendientes) y los que no se han cerrado de manera correcta
(incidentes no revisados), pues aún no se han descrito en el sistema las acciones de solución llevadas a cabo.
El formulario secundario “Base del conocimiento” permite visualizar todos los incidentes ocurridos que han sido resueltos,
lo que es útil para encontrar posibles soluciones a nuevos incidentes. Por su parte el formulario secundario “Modificar
Incidente” permite cerrar un incidente, una vez que ha sido solucionado de manera correcta. El cierre del incidente requiere
una descripción detallada de la solución dada al problema que dio origen al mismo lo que, automáticamente, pasa a formar
parte de la “Base del Conocimiento” para futuras consultas. Cerrar un incidente disminuye el indicador de incidentes no
revisados.
Por último, el formulario “Gestión del SLA” permite conocer el estado de los SLA que se encuentran registrados en la base
de datos. Brinda, mediante la ventana “SLA Activos”, la posibilidad de conocer los acuerdos que se encuentran activos y,
además, permite generar un reporte de QoS señalando el estado actual de los KPI. También, a través del formulario
“Detalles SLA”, ofrece los detalles básicos y avanzados del cumplimiento del SLA. Los detalles avanzados brindan los KPI
acordados y los valores actuales de los mismos, permitiendo, para los diferentes parámetros, la clasificación de las
violaciones según los rangos establecidos en el SLA. Estos formularios se pueden observar en la figura 7.

Figura 7
Formularios “Gestión del SLA”, “Detalles SLA” y reporte de QoS [Fuente: Propia]

4.3.- ESCENARIO DE PRUEBA DEL SOFTWARE DESAROLLADO

En el escenario de prueba fueron empleadas tres PC (dos laptops y una computadora de escritorio). Para ejecutar el software
de gestión de los SLA y el servicio Web se utilizaron en dos PC, el sistema de virtualización por software VMware
Workstation 10.0.0 sobre el cual se encontraba corriendo Ubuntu 12.04. Esto se puede apreciar en la figura 8.
Una laptop se encargó de ejecutar el software de gestión de los SLA y en la computadora de escritorio se ejecutó el servicio
Web. Ambas computadoras se comunicaron mediante una laptop que funcionó como puente entre una red inalámbrica y una
red cableada. La red inalámbrica se empleó con el objetivo de proporcionar una mayor latencia a los paquetes que se
transmiten entre el software de gestión de los SLA y el servicio Web, que hicieran más reales las condiciones de prueba. La
plataforma de virtualización brindó la flexibilidad necesaria para simular una degradación en el desempeño del servicio
brindado, ya que permite limitar el ancho de banda de las interfaces de red así como la pérdida de paquetes.
Para realizar la prueba se simuló un fallo en el servicio Web. Esto permitió comprobar el funcionamiento de los distintos
formularios que conforman el programa.
50
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
Se parte de que el servicio Web se encuentra activo y no se están ejecutando ninguno de los módulos que conforman el
software desarrollado. Para ejecutar los dos módulos que conforman dicho software hay que situarse en la consola y sobre la
localización del software, escribir las sentencias: ./script y mono [Link]. Una vez ejecutadas ambas sentencias, el
software, ya ejecutándose, muestra en el formulario “Gestión de ejecución de SLA” que no existen incidentes pendientes ni
incidentes no revisados.

Figura 8
Diagrama general del escenario de prueba [Fuente: Propia]

A continuación se simula un fallo en el servicio desactivando el servidor Web. El fallo del servicio es automáticamente
detectado por el software una vez completado el ciclo de monitorización, indicando en el formulario “Gestión de ejecución
de SLA” que existe un incidente pendiente y un incidente no revisado, como se observa en la figura 9.
En el formulario “Gestión de desempeño” aparece que ha ocurrido una interrupción y comienza a incrementar el tiempo
total en el que el servicio ha estado indisponible. En la figura 9 se muestra dicho formulario donde se aprecian los valores de
los indicadores de desempeño procesados y los detalles de indisponibilidad brindados por el formulario con este nombre.

Figura 9
Formularios “Gestión de ejecución de SLA”, “Gestión de desempeño” y “Detalles de indisponibilidad” durante el fallo del
servicio [Fuente: Propia]

51
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
Para obtener los detalles del problema se recurre al formulario “Gestión de incidentes” (ver figura 10) en el que se pueden
comprobar los incidentes pendientes así como la base de datos con todos los incidentes previos, donde se pueden buscar
posibles soluciones.
Una vez restaurado el funcionamiento del servicio, el indicador de incidentes pendientes disminuye su valor, pero el
indicador de incidentes no revisados se mantiene, indicando que no se han descrito las acciones llevadas a cabo para dar
solución al problema. Para hacerlo, en el formulario “Gestión de Incidentes”, se selecciona el incidente no revisado para
actualizar su estado en el formulario “Modificar incidente”. Una vez hecho esto se puede observar en el formulario “Base
del conocimiento” de la figura 10 que el incidente con su solución se encuentra registrado.

Figura 10
Formularios “Gestión de incidentes”, “Modificar incidente” y “Base del conocimiento” una vez corregido el fallo del servicio
[Fuente: Propia]

En la figura 11 se encuentra el formulario “Gestión del SLA” con los detalles de los dos SLA que se encuentran registrados.
Como se puede observar, en uno de los SLA el tiempo total de indisponibilidad de servicio permitido fue superado y se
incurrió en una violación menor de disponibilidad, sin embargo en el otro acuerdo (que es más flexible) no se incurrió en
ninguna violación de este tipo. El tiempo medio por solicitud en un SLA alcanzó el valor necesario para considerarse una
violación media mientras que en el otro una violación menor.

Figura 11
Formulario “Gestión del SLA” y detalles de dos SLA [Fuente: Propia]

Como prueba adicional se simuló una degradación del desempeño de la red, limitando el ancho de banda de la interfaz de
red del servidor a 10 Mbps e insertando una pérdida de paquetes de un 2%. Esto posibilitó verificar que el software
reacciona de manera proactiva indicando que existe una degradación del desempeño de la red, lo que permite llevar a cabo
oportunamente las acciones para dar solución al problema que se presenta.

5.- CONCLUSIONES
La propuesta de sistema para la gestión de los SLA en la etapa de ejecución es de gran utilidad para redes no comerciales,
en las que no es importante considerar la dependencia de la facturación con el cumplimiento de los SLA. El mismo posee
cuatro bloques funcionales, que interactúan entre ellos y con una base de datos centralizada. Cada bloque está compuesto
52
 Guillermo Gafas Cabrera, Caridad Anías Calderón
RIELAC, Vol. XXXVII 2/2016 p. 39-53 Mayo - Agosto ISSN: 1815-5928
por diversos sub-bloques que les proporcionan sus funcionalidades.
El software desarrollado para validar el diseño del sistema de gestión de los SLA en la etapa de ejecución, considera todos
los bloques propuestos en este sistema. En su programación se empleó como lenguaje C# y como sistema gestor de base de
datos SQLite. El software realizado es compatible con sistemas operativos basados en GNU/Linux y se encuentra
compuesto por dos módulos principales: el módulo “Monitor” y el módulo “Ejecución del SLA”.
En las pruebas del software se simularon diversas situaciones que se presentan en la práctica. Se comprobó su
funcionamiento con el servicio trabajando sin problemas y con incidentes como el fallo en el servicio Web y la degradación
del desempeño del mismo mediante una sobrecarga de la red. Una vez finalizada las pruebas se pudo corroborar que el
software funciona de manera correcta ante diversas situaciones.

REFERENCIAS
1. Ding J. Advances in Network Management. 6000 Broken Sound Parkway NW: Auerbach Publications; 2010.
375p.
2. Requisitos de gestión de calidad de servicio/acuerdo de nivel de servicio a través de la interfaz X de la RGT para
servicios del protocolo Internet. M.3341, (2003).
3. Kennedy J. Towards Standardized SLAs. Euro-Par 2013: Parallel Processing Workshops; Aachen, Alemania:
Springer; 2013.
4. Enhanced Telecom Operations Map (eTOM) – The business process framework. M.3050.1, (2007).
5. TMForum. SLA Management Handbook. Enterprise Perspective Berkshire, United Kingdom: The Open Group;
2004. 137p.

AUTORES
Guillermo Gafas Cabrera, ingeniero en Telecomunicaciones y Electrónica, graduado con título de oro en el Instituto
Superior Politécnico José Antonio Echeverría, La Habana, Cuba. Actualmente trabaja en CubaTel s.a., La Habana, Cuba, e-
mail; guillermo@[Link]
Caridad Anías Calderón, doctora en Ciencias Técnicas, máster en Telemática y profesora titular del Dpto de
Telecomunicaciones y Telemática, Facultad de Eléctrica, Instituto Superior Politécnico José Antonio Echeverría, La
Habana, Cuba, e-mail; cacha@[Link]

53
Copyright of Ingenieria Electronica, Automatica y Comunicaciones is the property of
Facultad de Ingenieria Electrica and its content may not be copied or emailed to multiple sites
or posted to a listserv without the copyright holder's express written permission. However,
users may print, download, or email articles for individual use.