DQoS Routing

Adding a Policy Server to a PacketCable Network

Autor: Craig Lien Network Engineer for Midcontinent Communications.

Gestiona, traduce y presenta: Ing. Martín Antonio Huerta Carbajal.

                                                                                              Muchas gracias Craig Lien.

 

Los componentes básicos de una red HFC (Híbrida de Fibra y Coaxial) son los nodos; pueden agregarse o dividirse, según lo que requiera el diseño. La capacidad es realmente el factor dominante para esta clase de operación del nodo. Los operadores de cable están siempre añadiendo nuevos servicios y nuevos usuarios, consumiendo capacidad, lo cual conduce a más trabajo del nodo. A través de unos cuantos años, PacketCable es uno de tales servicios que se han añadido. Dicho servicio suministra llamadas telefónicas de alta calidad a través de la red HFC.

 

En la cabeza, los nodos se conectan a un sistema terminal de cable módems (CMTS). A medida que la capacidad da lugar a la adición de nodos, dicha capacidad puede también dar lugar a la adición de otro CMTS. Cuando se añade un CMTS, típicamente los nodos existentes se mueven al nuevo CMTS para ayudar a balancear el futuro crecimiento. Cuando se mueven los nodos, se puede romper una asociación vital en PacketCable!

 

Cuando por primera vez se aprovisiona, un adaptador terminal multimedia (MTA) se asocia al CMTS al cual está conectado. Esta asociación se hace en el servidor de administración de la llamada (CMS). Durante el crecimiento de la red HFC, cuando un nodo se mueve a un CMTS diferente, esa asociación necesita ser actualizada. Para actualizarla, usted puede mirar al sistema de aprovisionamiento, o al CMTS, para decir exactamente cuáles MTAs se están moviendo. Pero la actualización presenta un problema. Muy importantemente, el período de tiempo en que el MTA no puede correctamente hacer o recibir una llamada, debe ser minimizado. Nótese que, cuando un MTA viene en línea y entra en servicio, ello puede tomar justos unos pocos segundos. Si se mueve un nodo que contenía 100 MTAs, usted necesitaría hacer las actualizaciones de 100 CMS en tan solo unos cuantos segundos. Inclusive más difícil, usted necesitaría sincronizar el movimiento del nodo y las actualizaciones de CMS, al mismo tiempo.

 

En una red PacketCable, cuando un CMTS se instala primero, se ajusta de modo de igualarse con el CMS; asimismo, el CMS se ajusta para igualar con el CMTS.  Esta sesión de “igualamiento” (peering) se hace específicamente para lograr la calidad dinámica de servicio (DQoS) PacketCable. Todo el tráfico, en lo que concierne a la QoS de MTA corre sobre este enlace de igualamiento.

 

PacketCable usa Docsis 1.1, el cual suministra flujos de servicio; estos flujos tienen en cuenta QoS a través de la red HFC. El tráfico DOCSIS típico es “best effort” (el mejor esfuerzo), en el cual no puede confiarse para entregar llamadas de alta calidad. Cuando PacketCable DQoS es “construido alto” (en una zona muy urbanizada o con altura adicional), es único en detalles de esa llamada particular.

 

“Hacer subir, o elevar una llamada” involucra múltiples elementos de red PacketCable. DQoS es, realmente, un subconjunto de negociación de la llamada. Para hacer subir DQoS de PacketCable, el CMS, CMTS y MTA, todos trabajan juntos. (Véase Figura 1). Inicialmente, el CMS y el MTA negocian que hay un comienzo de llamada. El CMS contacta al CMTS solicitándole el ancho de banda requerido y QoS para la llamada. El CMTS responde con un identificador (ID) asociado con la QoS. El CMS envía el ID al MTA y el MTA usa el ID para solicitar, pedir o requerir, QoS del (o desde el) CMTS. El

CMTS envía un reporte al CMS acerca de la QoS que está siendo activa. Finalmente, la llamada está lista y la voz (datos) comienza a fluir.

 

 

Cambio

Las llamadas PacketCable sin QoS están sujetas a cuestiones crónicas e intermitentes en la calidad de la voz, debido a paquetes caídos, retardo en la red y jitter.  Puede, inclusive, haber caída de audio en una o ambas direcciones. Algunas veces, si las condiciones son correctas sin QoS, una llamada puede parecer perfecta al cliente.

 

DQoS de PacketCable asegura que a los datos de voz les es dada QoS de DOCSIS de alta prioridad. Esta alta prioridad ayuda a minimizar, o disminuir, pérdidas y maneja el jitter o retardo causado por diferentes situaciones. El CMS actúa como agente de control, autorizando QoS solamente para legítimas sesiones de voz. El igualamiento (peering) del CMTS con el CMS evita cualesquiera peticiones o solicitudes no autorizadas de QoS. Cuando está correctamente configurado, DQoS de PacketCable es transparente y habilitador clave de un servicio de voz de alta calidad.

 

Podemos cambiar ese paso de aprovisionamiento, o suministro, para tratar el problema de actualización del CMS una vez que ha ocurrido una división de un nodo. Es posible usar el concepto de dar como ruteador al DQoS para ayudar a mantener la asociación de CMTS y MTA.  El ruteo de DQoS requiere que agreguemos un elemento de red llamado Policy Server (Servidor de Políticas). Con esta adición cambiamos un poco el igualamiento o peering. A su vez, cada CMTS “iguala” directamente con el Servidor de Política. Ahora, cuando el MTA se aprovisione “sobre” el CMS, es asociado con el Policy Server. Desde la perspectiva del CMS, no importa a cual CMTS se conecta el MTA, ya que el CMS nunca se comunica con el CMTS, sino sólo con el Policy Server.

 

El Policy Server mantendrá una base-de-datos acerca de cuáles subredes están en cuáles CMTS. Cuando el CMS contacta al CMTS solicitando los requeridos anchos-de-banda y QoS para la llamada, ese mensaje realmente contiene la dirección IP del MTA.

El Servidor de Políticas podría borrar las direcciones IP y consultar la base de datos de la subred y enviar el mensaje QoS al CMTS apropiado. El Servidor de Políticas podría también enviar cualesquiera respuestas viniendo de regreso del CMTS al CMS.

 

La Figura 2 muestra el montaje DQoS con el Servidor de Políticas PS insertado. De nuevo, inicialmente el CMS y MTA negocian que hay el comienzo de una llamada. El CMS envía un mensaje al Servidor de Políticas solicitando el ancho de banda requerido y el QoS para la llamada. El Servidor de Políticas consulta la base de datos de la subred y envía la solicitud al CMTS apropiado. El CMTS responde con una ID asociada con la QoS y el Servidor de Políticas envía la respuesta de regreso al CMS. Justo como antes, el CMS envía la ID al MTA y el MTA usa la ID para solicitar QoS del CMTS. El CMTS envía un reporte de la QoS estando activo, mismo que el Servidor de Políticas, envía al CMS. Finalmente, la llamada se hace y los datos de voz comienzan a fluir.

 

 

 

Figura 2: Arreglo DQoS con el Servidor de Políticas insertado.

 

Hay un cierto número de diferentes mensajes que fluirán entre el CMS y CMTS, en forma transparente, a través del Servidor de Políticas; todos se enviarán inalterados. Algunos de ellos son solicitudes, acuses de recibo, aperturas y cierres. Por cada llamada, hay casi un par de mensajes al comienzo y final de una llamada. Un Servidor de Políticas debiera fácilmente mantenerse al nivel del tráfico inclusive durante momentos pico de llamadas.

 

Actualizaciones

 

La base de datos de la subred del Servidor de Políticas es ahora crucial en los mensajes entre CMS y CMTS. Debe mantenerse actualizada y ello podría hacerse en varias formas. La base de datos del Servidor de Políticas podría mantenerse manualmente, pero ello no funcionará bien con un gran número de CMTSs y muchas divisiones de nodo. Sería mejor automatizar las actualizaciones de la base de datos.

 

Hay varias opciones. Una solución sería tenerla que escuche a un “routing protocol”, tal como “open shortest path first” (OSPF) (abre primero la trayectoria más corta). O podría usar simple network management protocol (SNMP) para cuestionar a las subredes de cada CMTS. La lista de CMTS en un Policy Server podría mantenerse manualmente o, posiblemente, en forma automática, con un auto-discovery sobre una pequeña sub-red.

 

Sin embargo, si se mantiene, debe ser simple actualizarla. Definitivamente debería haber un sistema de errores para captar (o cachar) una petición con una dirección IP que no pueda encontrarse en la base de datos. Cualquier error, o información faltante en la base de datos resultará seguramente en problemas de llamada.

 

El Servidor de Políticas es un elemento crítico de red, precisamente de la red PacketCable, en donde la falla de dicho Servidor daría lugar a muy extendidas faltas de servicio. Por lo tanto, el Servidor de Políticas debiera ser desplegado en una configuración de alta disponibilidad, proporcionando “fail-over” de baja latencia.

 

Incorporación de un Servidor de Políticas

 

Esta adición a una red PacketCable puede hacerse con unos cuantos pasos. Primero, instale el Servidor de Políticas y establezca la sesión peering (igualamiento), igual que usted lo haría para un CMTS. Luego dirija el igualamiento del CMTS al Servidor de Políticas; usualmente hay una lista de “peers” en el CMTS, así que simplemente adicione el Servidor de Políticas a esa lista. Asegúrese de que la base de datos del Servidor de Políticas está ajustada con las subredes sobre el CMTS. Y por último, en el CMS cambie la asociación de MTA, del CMTS al Servidor de Políticas. Ahora, cuando se coloque una llamada, la mensajería DQoS será enviada al Servidor de Políticas.

 

En www.packetcable.com, bajo Multimedia, hay una descripción para un Policy Server que es similar a lo que aquí se describe. PacketCable Multimedia (PCMM) está asociado con gaming  y, tal vez, con voz session initiation protocol  (SIP). Los operadores de cable están actualmente mercadeando servicios empaquetados que muy probablemente incluyen la tradicional voz PacketCable. Una solución de elección de rutas y calidad dinámica de servicio debe ser un simple acomodo dentro de una red tradicional PacketCable.

 

Prueba y garantía de servicio

 

Hay disponible equipo de prueba, específico para cable, que puede hacer pruebas de voz. Instrumentos como estos son ideales para corrección de fallas e, inclusive, para comparar la calidad de la llamada en diferentes partes de la planta HFC.

 

Este tipo de equipo de prueba se requiere a menudo para trabajar a través de un extenso territorio, posiblemente abarcando muchos CMTSs. Cuando estos instrumentos se mueven de CMTS a CMTS, ellos sufren del mismo problema de la asociación MTA y CMTS. Sin DQoS operando correctamente, el instrumento puede mostrar un falso positivo de un problema de voz que no existe cuando se establece DQoS. Con ruteo DQoS, las llamadas de prueba del instrumento tendrían establecido DQoS sin importar a cuál CMTS está conectado.

 

Un Servidor de Políticas suministra un punto de garantía de servicio PacketCable. La historia DQoS podría ser registrada y puesta en una base de datos. Esta base de datos podría usarse para resolver quejas pasadas de los clientes, o para verificar si una llamada tenía DQoS. Estos datos también podrían usarse en graficado histórico y planeación de capacidad. Ya que los datos tienen el comienzo y final de cada llamada, podría también ser posible generar gráficas Erlang para cada puerto. Otro uso podría ser comparar estos datos con los de calidad de las llamadas. Podría ser posible generar reportes demostrando la calidad de las llamadas, lo cual suministraría datos útiles para procesos de resolución de disputas, mercadotecnia y presupuestos.

 

Conclusión

 

Con ruteo DQoS, hay una forma de eliminar la asociación MTA y CMTS en el CMS. Esta asociación se torna en otra asociación, ahora de MTA y Servidor de Políticas, donde el CMS ve solamente un elemento de red Servidor de Políticas. Con ruteo DQoS, podemos minimizar el tiempo en que un MTA no puede hacer llamadas debido a operación en curso del nodo; ese tiempo, o momento, es el movimiento físico mismo del nodo y el MTA viniendo en línea e iniciando el servicio. DQoS puede recapturar este tiempo potencialmente perdido.

 

Hoy como siempre: Ratifiquemos nuestro deseo de seguir siempre al pie del cañón.

 

                                                                                                          Folio 803052.