DQoS routing

Enrutamiento Dinámico de la QoS (Calidad de Servicio)

2ª Parte

(CT´s Pipeline (01/04/2008) entrevista a Craig Lien)

Indaga, traduce y presenta: Ing. Martín Antonio Huerta C.

En su reciente artículo CT sobre DQoS routing, usted discute pérdidas en asociaciones MTA (multimedia terminal adapter)/CMTS (cable módem termination system), en divisiones de nodos. ¿Qué tan grande es este problema ahora? O es algo que usted espera será mayor en años venideros?

CableLabs tiene un documento (Disponibilidad de VoIP) que establece “99.94 por ciento se fijó para la red PacketCable de punta-a-punta.” Una disponibilidad de 99.94 por ciento es igual a casi 5 horas y 15 minutos de inactividad al año. La red de punta-a-punta consiste en un gran número de componentes y cualquiera de dichos componentes puede impactar el servicio en un número de maneras diferentes. El total de dichos impactos puede acumularse muy rápidamente.

El colocar un Servidor de Políticas en una red PacketCable es una forma de minimizar el impacto del trabajo en el nodo para ayudar a conseguir 99.94 % de disponibilidad. Cuando se incorpora un CMTS nuevo y se mueven los MTAs, podría haber miles de actualizaciones de la asociación MTA/CMTS que necesitan hacerse. Dependiendo de qué tan rápido pueden hacerse las actualizaciones, ello presenta una situación posible donde el MTA podría ser cargado y registrado con el CMS (servidor de administración de la llamada), se inicia una llamada en cualquier dirección y, ya que la asociación MTA/CMTS no es actualizada, el CMTS equivocado es contactado para alcanzar DQoS. A menudo una llamada como ésta tiene algún resultado extraño o, simplemente, se desploma.

Existen CMTSs que tienen alta capacidad, soportando miles de MTAs. En el futuro habrá, seguramente, CMTSs de mayor capacidad. Con CMTSs más grandes, el problema de mantener la asociación MTA/CMTS se hace menor – habría pocas veces que mover MTAs.

Sin embargo, hay nuevos dispositivos que están llegando sobre los CMTSs, tales como las DOCSIS Set-top Gateways (Compuertas encima del televisor). Las demandas futuras pueden incluir inclusive más CMTSs. Si hay más CMTSs, permanece el problema de asociación.

En el artículo, usted recomienda colocar un Policy Server entre el CMS y el CMTS. ¿Cuántos Policy Servers se necesitarían en un sistema?

Por cada llamada, sólo unos cuantos pequeños mensajes necesitan procesarse, lo cual permite que pequeños sistemas tengan buena capacidad. Hay maneras de de construir la base de datos de la subred que permita muy rápidas y eficientes “lookups” (búsquedas o revisiones). Ambas características permiten que un sistema Policy Server maneje muchos CMTSs y miles de MTAs. Una estrategia posible es igualar un sistema Policy Server con un CMS o, posiblemente, un Policy Server por región.

El artículo también menciona usos posibles para los datos históricos DQoS. ¿Podría extenderse en este tema?

Podría ser valioso juntar la historia DQoS con la métrica de las llamadas y el puerto torrente arriba, si el Policy Server (que bien podría llamarse Servidor de Políticas) pudiera adicionarla. Con esa información, usted podría hacer o construir un reporte donde podrían buscarse las llamadas o problemas específicos. El reporte podría mostrar problemas o tendencias del MTA o, por comparación con otros de la misma área, mostraran un problema mayor.

En la solución de problemas de calidad de la voz con un MTA, una de las primeras cosas que deben verificarse es que DQoS esté construido correctamente. Con esta clase de reporte histórico, sería posible verificar eso.

Los datos históricos DQoS podrían también proveer información para ayudar en la planeación de la capacidad. Con el puerto torrente arriba, los datos podrían usarse para calcular Erlangs sobre una base “por torrente arriba”. Ya que la información DQoS realmente contiene las direcciones IP de los puntos finales, usted podría hacer también cálculos por tipos de llamadas.

Esta información podría también usarse para mostrar disponibilidad y performance de la red PacketCable. Dados grandes CMTSs ahora y en el futuro, debe haber, casi siempre, una llamada (o evocación). Tomando el patrón de tiempo de las llamadas y construyendo un mayor marco de tiempo para un CMTS, o un torrente abajo, usted podría mostrar la disponibilidad de la red PacketCable, así como su calidad de llamada.

¿Cuáles son los requerimientos de respaldo/redundancia para el Policy Server?

Hay cierto número de formas de construir un sistema computacional de alta disponibilidad. Dependería del diseño del Policy Server. Con servidores de políticas Multimedia PacketCable, yo creo que esto ya ha sido tratado.

Un pensamiento sobre ello: Un Servidor de Políticas es tan vital para la apropiada función de una aplicación que, tal vez, cada sistema de reconocimiento tendría su propio Servidor de Políticas. Esto podría evitar la posible catástrofe donde múltiples aplicaciones estuvieran fuera de línea al mismo tiempo.

Usted también mencionó equipo para prueba de voz, específico para cable. ¿Qué características y atributos debe tener tal equipo?

El equipo de prueba debe ser pequeño y portátil, asimismo debe ser un MTA en funcionamiento total, que opere en cualquier parte de la red. Durante una llamada PacketCable, periódicamente hay packetes de control enviados entre los MTAs; la unidad debe participar en los packetes de control y reportar sobre aquellos recibidos. El equipo de prueba debiera (vía una llamada) conectar consistentemente al mismo punto de prueba en la red. Sería conveniente, para el mismo, correr pruebas continuas y automatizadas contra ese punto. Durante esta prueba automatizada, el punto interesante, en el tiempo, es siempre que los packetes de control comiencen a mostrar un problema.

Para que este equipo de prueba sea comisionado en una área con más de un CMTS, debe ser aprovisionado para operar sobre todos los CMTSs en el área. Para probar verdaderamente la red, el equipo de prueba debe participar en DQoS justo como un MTA. Para ser una prueba honesta, sin la posibilidad de falsos positivos, la red necesita un Policy Server haciendo enrutamiento DQoS. Por ejemplo, un falso positivo puede ocurrir cuando DQoS no esté correctamente construido sobre un ocupado torrente-arriba, donde la prueba puede mostrar erróneamente un problema cuando realmente no exista.

Tal equipo sería ideal para la localización y corrección de fallas en un problema de calidad de la llamada, caso en que podría conectarse en diferentes puntos en la red. Si la misma prueba se realizó en cada punto, la calidad de la llamada podría compararse y ayudar a aislar el problema.

Indiscutiblemente debemos seguir al pie del cañón.

                                                                                                                 Folio 804030.