29 de diciembre de 2006

¿Qué es el protocolo SS7?

El Sistema de Señalización de Canal Común número 7 (Common Channel Signaling System No 7, SS7 o C7) es un estándar global empleado en la industria de las telecomunicaciones definido por la el Sector de Estandarización de Telecomunicaciones del Internacional Telecommunications Union (ITU-T). En el que se declaran los procedimientos y protocolos por los cuales los elementos de red en una red pública de teléfonos (PSTN o Public Switched Telephone Network), intercambian información sobre una red de señalización digital a fin de afectar el modo en el que se llevan a cabo llamadas telefónicas, ya sea en los esquemas celulares o en los comunes.

Dentro de sus aplicaciones más comunes están:

- Establecimiento básico, gestión y finalización de llamadas

- Servicios celulares tales como los de comunicaciones personales (PCS), roaming y autenticación de suscriptores

- Portabilidad de números locales (LNP)

- Servicios 800 y 900

- Características ampliadas tales como reenvío de llamadas, identificación de llamadas y conferencias entre varios participantes

- Telecomunicaciones seguras a nivel mundial

Los mensajes SS7 se intercambian entre los elementos de red brindando:
-
Mejores tiempos en el establecimiento de las llamadas

- Uso más eficiente de los circuitos de voz

- Soporte para los servicios de redes inteligentes (IN), que requieren la señalización a los elementos de red sin necesidad de emplear los canales de voz.

- Control sobre el uso fraudulento de la red.

Cada punto de señalización (signaling point), en la red SS7 (elemento de la red), se identifica mediante un código numérico único llamado point code (código del punto). Los point codes son llevados y traídos en los mensajes intercambiados entre los puntos de señalización a fin de identificar la fuente y el destino de cada mensaje. Cada punto de señalización utiliza una tabla de ruteo para seleccionar la ruta apropiada para que un mensaje pueda alcanzar su destino. Más o menos de la manera en la que un ruteador funciona en una red de cómputo.

Hay tres clases de puntos de señalización en una red SS7:

- SSP (Service Switching Point. Punto de Intercambio de Servicio)

- STP (Signal Transfer Point. Punto de Transferencia de Señal)

- SCP (Service Control Point. Punto de Control de Servicio)

Los SSP’s son switches en los que se originan, terminan o se reenvían las llamadas. Un SSP envía mensajes de señalización a otros SSPs a fin de establecer, gestionar y liberar los circuitos de voz que se requieren para completar una llamada. Por otro lado, también pudieran enviar peticiones a alguna base de datos centralizada (un SCP), a fin de determinar cómo reenviar una llamada, un ejemplo de esto son los números 800 y 900. Un SCP responde con el número telefónico real, asociado con el número 800/900 marcado. Así mismo, es común que se use un número alternativo si es que el primario se encuentra ocupado o si la llamada no se responde en un tiempo establecido.

El tráfico de la red entre los puntos de señalización puede enrutarse por medio de un switch de paquetes conocido como STP, cuya tarea es la de tomar cada paquete entrante y enviarlo hacia uno de los tantos enlaces de señalización (signaling link), basándose en la información de ruteo contenida en el mensaje SS7. En virtud de que actúa como un concentrador, el STP brinda un uso mejorado de la red SS7 al eliminar la necesidad de tener enlaces directos entre los diversos puntos de señalización. Así mismo, un STP puede llevar a cabo global title translation, que es un procedimiento por el cual el elemento de red destino se determina por medio de los dígitos presentes en el mensaje. También un STP puede hacer las veces de un firewall para controlar los mensajes SS7 que se intercambian con otras redes.

Debido a que la red SS7 es crítica para el procesamiento de las lamadas, tanto los SCPs como los STPs se despliegan en pares, separados físicamente para asegurar que la red permanezca en funcionamiento aunque alguno de estos elementos falle. Los enlaces entre los puntos de señalización también se instalan en pares por lo que el tráfico se comparte sobre todos los enlaces. Si uno de los enlaces falla es reenviado por otro enlace. El protocolo SS7 brinda capacidades de retransmisión y corrección de errores.

Finalmente, hablemos un poco sobre los tipos de enlaces, estos se organizan por el tipo, de acuerdo a su uso en la red de señalización SS7.

Enlace A: Un enlace A (Access), conecta un punto de señalización final (Signaling End Point), como un SCP o un SSP a un STP. Sólo se transmiten los mensajes originados por o destinados al Signaling End Point.

Enlace B: Un enlace B (Bridge o puente), conecta un STP a otro STP.

Enlace C: Un enlace C (Cross o cruzado), conecta a un STP con su pareja. Se usa típicamente cunado un STP no tiene otra ruta disponible para llegar a otro elemento debido a un error en los enlaces. Notemos que aunque los SCPs también se instalan en pares, estos no se interconectan entre sí.

Enlace D: Un enlace D (Diagonal), conecta a algún par secundario de STPs hacia un primario. Los STPs secundarios dentro de la misma red se conectan vía enlaces tipo D.

Enlace E: Un enlace E (Extended o extendido), conecta un SSP con un STP alternativo. Los enlaces E proveen una ruta alternativa para conectar con un STP.

Enlace F: Un enlace F (Fully associated o completamente asociado), conecta a dos Singnaling End Points (SSPs y SCPs). Los enlaces F no se usan regularmente en las redes con STPs, ya que se pensaron para conectar directamente dos puntos de señalización.

28 de diciembre de 2006

Algunas ideas sobre la calidad en el desarrollo de software

Hace unos momentos leía una presentación sobre calidad sobre las normas ISO, para ser más específicos. Debo admitir que tiene conceptos interesantes ya que menciona que son una referencia internacional para exigencias de dirección de calidad entre empresas y que se aplica a toda empresa que busca tanto aumentar la satisfacción del cliente como una mejora continua. Suena muy bien, al menos hasta ahora.

Dice también que dos razones por las que se busca la certificación en la calidad de los procesos son dos por requerimientos del cliente y por presión de la competencia. Vamos al día con día.

La aplicación de normas rigurosas en las etapas tempranas del desarrollo de software necesariamente conlleva un aumento en el tiempo que se toman las fases de análisis y validación de requerimientos. Lamentablemente esto no siempre se comprende y se toma muy poco tiempo para estas fases, perdiendo de vista (ambos lados) el objetivo de la satisfacción del cliente.

Esto pasa, pienso yo, cuando tanto el proveedor, como el cliente no concuerdan en la prioridad de los procesos de calidad, de entrada, cuando el cliente no se involucra adecuadamente en el desarrollo de su software al no asignar tiempo para que el proveedor entreviste al personal operativo que seguramente conoce los intríngulis de los procesos. O bien cuando el cliente propone a alguien que no conoce del todo el proceso como interfaz con el cliente, siempre es bueno hablar directamente con quienes “hacen las cosas”.

Bajo estas condiciones, el análisis de requerimientos saldrá mal o no contemplará todos los aspectos de un proceso.

Posteriormente, durante la fase de validación de requisitos es posible que el cliente detecte omisiones y las haga patentes, en cuyo caso habrá que regresar a revisar los faltantes y a corregir los errores potenciales. Si no se detectan, aún hay posibilidad de que salgan a la luz posteriormente. De cualquier modo, ya se tuvo que invertir un poco de tiempo que quizás no estaba contemplado de inicio, ¿quién planea que las cosas pueden salir mal?

Otro problema común es cuando el cliente quiere las cosas “para ayer”. Es obvio que esta práctica elimina la posibilidad de hacer un buen análisis del impacto de los requisitos de adecuación y tiene como resultado común un código parchado que se vuelve inestable con el paso del tiempo y que será complicado de mantener y que seguramente no estará debidamente documentado.

Durante la fase de diseño del software, el cliente debe estar informado y ser consultado hasta el cansancio a fin de hallar, en la medida de lo posible, cualquier defecto de análisis y con ello garantizar que el proyecto quede bien delimitado.

Al principio al cliente, puede parecerle un poco engorroso pero a la larga redundará en la satisfacción por el producto final. Esto es lo que hace la diferencia entre una empresa comprometida con la calidad y aquella que no cuenta al menos con una política interna de desarrollo.

Estos son algunos beneficios que una certificación de calidad otorga.

Internos:

- Mayor sistematización y documentación de los procesos

- Aumento de la productividad

- Mejoramiento de la organización interna

- Incremento en la rentabilidad

- Orientación a la mejora continua

- Mayor capacidad de respuesta

- Mejoramiento en la gestión de costos y riesgos.

Externos:

- Mejoramiento de la imagen empresarial

- Refuerzo de la confianza entre los clientes actuales y potenciales

- Apertura de nuevos mercados

- Mejoramiento de la posición competitiva

- Aumento de la fidelidad de los clientes

Finalmente, pongo a su consideración tres ideas que podrían mejorar las prácticas en la industria del desarrollo de software:

1) La calidad es necesaria tanto para el cliente como para el proveedor.

2) No es necesario comenzar con normas ISO, CMM, RUP o cosas así, vale más, adoptar de entrada algo cómodo y adecuado al tamaño de la empresa, sin dejar de buscar la mejora continua.

3) A veces es necesario enrolar al cliente en la cultura de la calidad y hacerle comprender la importancia de los procesos.

¿Qué son los sistemas de gestión de red?

En una red (no solamente de cómputo), existen diversas entidades que la forman, tanto físicos (hardware) como lógicos (software).

Entre los más comunes tenemos a los switches, los ruteadores, los firewalls, los concentradores y por supuesto las computadoras, ya sea como estaciones de trabajo o servidores. Todos estos se conocen como elementos de una red, elementos gestionados u objetos gestionados.

Cuando sobreviene un problema en alguno de estos elementos, depende sobre todo del tamaño de la misma el qué tan pronto puede detectarse, diagnosticarse y por supuesto resolverse. Para las redes pequeñas, la tarea es sencilla ya que incluso una revisión ocular de los elementos puede revelar al menos en qué dispositivo o sistema se presenta la falla, más no nos dirá con exactitud en dónde se localizan los problemas.

En cuanto a las redes más grandes, el problema se complica sobre todo si el elemento que falla se encuentra lejos de las instalaciones de mantenimiento o que está en un sitio de difícil acceso. Para este caso, es indispensable saber a detalle cual es el motivo de la falla para que la gente de campo pueda solucionar el problema.

Así mismo, es deseable contar con estadísticas de velocidad, datos sobre paquetes enviados/recibidos o aquellos que se pierden; así mismo, es indispensable saber en dónde hay demasiado tráfico (carga) y a qué hora se presenta, lo mismo para los fallos frecuentes.

Del mismo modo pudiéramos saber con diferencia de fracciones de segundo si existen intentos de penetración ilegales a algún elemento o a toda la red, de modo que como administradores de red seamos capaces de responder ante posibles compromisos a la seguridad que potencialmente pongan en riesgo el capital intelectual y financiero de la empresa.

Ahora, a los sistemas capaces de interactuar con los objetos gestionados se les da el nombre de Sistemas de Gestión de Elementos o EMS (Element Management Systems). Éstos gestionan una porción de la red. Por ejemplo, existen EMS específicos para entender SNMP, ya sea en versión uno, dos o tres. Otros que pueden trabajar con otros protocolos como Q3 o bien protocolos propietarios. Hasta el medio de conexión cambia, ya que los medios pueden ir desde un sencillo cable ethernet o por medio de puertos seriales.

En virtud de que una red generalmente es heterogénea per se, es necesaria la existencia de otros dispositivos que integren la información enviada por los diferentes EMS, a estos sistemas se les conoce como Sistemas Gestores de Gestores (Managers of Managers Systems o Mom). Desde aquí se puede enviar la información de la red hacia la interfaz de usuario que es la que finalmente se encargará de mostrarla de una forma ordenada a fin de que los usuarios puedan tomar decisiones respecto a ella.

En base a lo anterior se recomienda que la información se divida en lo que se conoce como las Áreas Funcionales de la Gestion (Management Functional Areas o MFA), las cuales son: Gestión de Fallas (Fault Management), Gestión de Configuración (Configuration Management), Accounting, Gestión del Rendimiento (Performance Management) y Seguridad (Security). Estas se conocen como el modelo FCAPS del MFA.

La gestión de fallas se puede definir como la detección de un problema, el aislamiento del error y su posterior corrección. La detección del problema se puede realizar de dos maneras diferentes, ya sea pasiva o activamente, dependiendo de cómo reciba el EMS los mensajes de error. Si éstos provienen de los dispositivos y el EMS solamente los recibe a manera de mensajes informativos no solicitados (UIM), o mensajes de alarma no solicitados (UAM), se considera que la detección es pasiva. En cambio, si es el EMS el que cada determinado tiempo pregunta al dispositivo por su estado, entonces se considera que es una detección de alarmas activa.

La gestión de la configuración de la red podría ser la parte más importante de la gestión de una red ya que no se puede manejar adecuadamente si no se puede configurar. Siempre es buena práctica coordinar esfuerzos con el personal de gestión de red a fin de que lo que reflejen dichos sistemas sea lo que realmente está funcionando en la red.

El accounting es generalmente relegado a los administradores de sistemas puesto que no se considera una tarea realmente de la red. Un enfoque interesante es el considerar cuentas de usuario para toda la red y no solamente en sistemas determinados.

Mediante la gestión de rendimiento se busca conocer el desempeño de los enlaces o circuitos de información y el uso que se le da a determinados elementos de red a fin de optimizar recursos.

Sobre la seguridad podemos decir que la mayoría de las aplicaciones de gestión sólo se refieren a la seguridad del hardware, es decir, monitorean accesos, sobrecalentamientos, etc. Esta tarea se deja en manos de los administradores de sistemas.

Ahora que conoce todo lo que involucra la gestión de una red cabe preguntarnos si nuestras redes están gestionadas, es decir, ¿sabemos qué cosa sucede realmente en ella, o simplemente hacemos pronósticos optimistas?