Inicio Tecnología 2017 Articulos 2017 Manual de mejores prácticas para garantizar que su red se encuentra lista...

Manual de mejores prácticas para garantizar que su red se encuentra lista para aplicaciones de voz y video sobre IP. 2ª. de 3 partes

Revista Mundo-Contact

     

 

El descubrimiento y la clasificación del tráfico revelan qué es lo que se encuentra en la red y cuán importantes son para la organización cada una de las aplicaciones que corren en la red. El análisis del ancho de banda le brinda al administrador de la red información crucial necesaria para la elaboración de estrategias tendientes a administrar el ancho de banda, mejorar las topologías de la red y planificar la capacidad futura. Dos de los principales tipos de análisis son el análisis de utilización y el análisis de desempeño.

Existen varias medidas basadas en el control para proveer un nivel adecuado de calidad de servicio. Un elemento clave en toda estrategia de control consiste en definir un concepto general de operaciones de red a fin de contar con un cimiento sobre el cual el administrador pueda erigir definiciones precisas de la funcionalidad y el desempeño que se pretende tener en la red. Cuando no se desarrolla un concepto operativo para la administración de la red, la consecuencia puede ser inestabilidad en la red o una administración a base de excepciones, debido a las cambiantes exigencias de los usuarios finales. Muchas veces los administradores necesitan unificar las expectativas de desempeño (a menudo divergentes) de los diferentes usuarios de las aplicaciones.

 
    Manual de mejores prácticas para garantizar que su red se encuentra lista para aplicaciones de voz y video sobre IP. 2ª. de 3 partes

Análisis y planificación del ancho de banda

El descubrimiento y la clasificación del tráfico revelan qué es lo que se encuentra en la red y cuán importantes son para la organización cada una de las aplicaciones que corren en la red. El análisis del ancho de banda le brinda al administrador de la red información crucial necesaria para la elaboración de estrategias tendientes a administrar el ancho de banda, mejorar las topologías de la red y planificar la capacidad futura. Dos de los principales tipos de análisis son el análisis de utilización y el análisis de desempeño:

Análisis de utilización del ancho de banda

El análisis de utilización identifica qué aplicaciones y usuarios o hosts están haciendo uso del ancho de banda. Un análisis de utilización revela:

Si las aplicaciones indicadas están teniendo acceso suficiente al ancho de banda y si las aplicaciones equivocadas están teniendo demasiado acceso, Si la organización está recibiendo todo el ancho de banda que tiene contratado con su proveedor de servicio, y Si la organización cuenta con ancho de banda suficiente para las aplicaciones que necesitan hacer uso de la red, y cuánto ancho de banda realmente se necesitaría para las aplicaciones críticas si la red se administrase de manera más eficaz.

Un parámetro clave es cuáles son los mayores usuarios de ancho de banda por tipo de clasificación. Estos datos sirven para determinar si se está otorgando a las aplicaciones indicadas una cantidad adecuada de ancho de banda y si las aplicaciones equivocadas están consumiendo demasiado. Por ejemplo, un administrador de red podría determinar que la categoría de tráfico de Web consume 75% del ancho de banda de la red, por lo que tal vez querría dividir el tráfico de web en dos clases – crítico y casual – a fin de dar a cada una la prioridad que le corresponde. Del mismo modo, el administrador no querrá que el tráfico de voz y video crezca fuera de control, consumiendo todo el ancho de banda de la red en detrimento del desempeño de las aplicaciones críticas para la empresa. En este caso, el administrador consideraría imponer límites al ancho de banda consumido por las aplicaciones de VoIP y video, de manera que todas las aplicaciones críticas tengan un desempeño satisfactorio. Otro parámetro útil consiste en determinar cuáles aplicaciones transmiten la mayor cantidad de información (hablantes) y cuáles reciben la mayor cantidad de datos (escuchas). Si uno de los principales hablantes es una página web en el sitio web de la empresa, es posible adoptar las medidas pertinentes; si uno de los principales escuchas está direccionado a descargas de música o video, se pueden tomar las medidas necesarias para limitar su acceso a ancho de banda.

Cómo usar los datos de utilización del ancho de banda

Si usted observa… Entonces considere…
Índices de utilización pico muy altos con índices promedio muy bajos Funciones de control para suavizar los picos e incrementar la capacidad de procesamiento
Índices de utilización bajos que rara vez o nunca se acercan a la capacidad y aplicaciones que funcionan satisfactoriamente Que quizá está pagando más ancho de banda del que necesita. Tal vez pueda reducir sus gastos por concepto de ancho de banda.
Picos frecuentes a niveles consistentes, pero menores que su capacidad supuesta Verificar si está obteniendo todo por lo que está pagando. Considere usar funciones de control para aprovechar de manera más eficiente el ancho de banda que tiene a su disposición.
Índices de utilización consistentemente altos que se mantienen muy cerca de su capacidad máxima Primero, incorporar equipos con funciones de control y/o compresión para maximizar la eficiencia de utilización del ancho de banda (por ejemplo Packeteer PacketShaper Xpress). Después, si el problema persiste, considere adquirir más ancho de banda.

Tabla 1: Lineamientos para el uso de los datos de utilización del ancho de banda en la toma de decisiones sobre el control y la capacidad de la red.

El monitoreo de los índices máximos y promedio de utilización de ancho de banda arroja información muy valiosa sobre el comportamiento de todas las clases de tráfico. Una clave consiste en garantizar que el tiempo de medición sea suficientemente breve para capturar realmente el comportamiento de las aplicaciones, pero detectando la utilización máxima. Los ruteadores y otros equipos de red pueden dar una sensación artificial de seguridad cuando proporcionan mediciones de uso promedio de la red durante períodos prolongados. Los equipos que detectan la utilización pico y los que utilizan intervalos de medición más frecuentes pueden dejar al descubierto un problema de capacidad oculto. Por ejemplo, un índice de utilización promedio podría llevar a un administrador a pensar, erróneamente, que la utilización nunca se aproxima a la capacidad total de la red, mientras que una línea de índices máximos puede revelar la presencia de picos frecuentes en ese mismo lapso de tiempo. También puede ser que una línea de índices pico llegue a revelar lo contrario – tal vez la organización utiliza menos ancho de banda del que está comprando.

Análisis del desempeño de las aplicaciones

El análisis del desempeño de las aplicaciones cuantifica lo que a menudo ha sido información subjetiva y anecdótica sobre la medición de la percepción que un usuario tiene respecto al desempeño – tiempo de respuesta – una vez que oprimió la tecla “Enter” o que hizo clic con el ratón. Este tipo de análisis le brinda al administrador de la red un mecanismo para comparar el desempeño real y el desempeño esperado de las aplicaciones, y una manera de verificar el cumplimiento de los compromisos de nivel servicio. También le permite cuantificar y validar las reclamaciones asociadas al desempeño, que pueden contribuir a justificar la compra de equipo nuevo y garantizar que las aplicaciones de voz y video funcionen dentro de los valores meta de calidad de servicio.

Parámetros utilizados en el análisis de desempeño de aplicaciones

Parámetro Descripción Usos
Demora total Número de milisegundos que una transacción requiere, desde la petición del cliente hasta la recepción de la respuesta. Es a lo que la mayoría de la gente se refiere cuando habla de “tiempo de respuesta”, y corresponde a la percepción por parte del usuario del tiempo necesario para llevar a cabo una transacción. Verificar las percepciones de desempeño lento que manifiestan los usuarios. Detectar tendencias positivas o negativas dando seguimiento a los promedios históricos a lo largo del tiempo.
Demora de la red

Número de milisegundos transcurridos en tránsito cuando dos equipos intercambian datos. Si una transacción requiere la transferencia de una gran cantidad de datos, estos se dividen y se envían en varios paquetes.

La demora del servidor es el tiempo transcurrido entre el momento en que el servidor recibe el último paquete de una petición y el momento en que envía el primer paquete de la respuesta (no acuse de recibo, sino el contenido de la respuesta en sí). Es el tiempo que el servidor se lleva en procesar la petición del cliente.

Determinar si un deterioro en la velocidad de la red se debe a un problema en tránsito (y no a un servidor sobrecargado, por ejemplo). Este parámetro es crucial en el caso de aplicaciones de voz y video sobre IP.

Determinar si el uso de funciones de control de conformación de paquetes puede resolver un problema determinado de desempeño o evitar que se presenten en un futuro.

Demora del servidor

Número de milisegundos que el servidor invierte en procesar la petición de un cliente una vez que ha recibido todos los datos necesarios.

La demora del servidor es el tiempo transcurrido entre el momento en que el servidor recibe el último paquete de una petición y el momento en que envía el primer paquete de la respuesta (no acuse de recibo, sino el contenido de la respuesta en sí). Es el tiempo que el servidor se lleva en procesar la petición del cliente.

Determinar si los servidores son culpables del deterioro en el desempeño de las aplicaciones. Para aplicaciones de voz y video, esto incluiría unidades de control multipunto y gatekeepers.
Tiempo de viaje redondo (Round Trip Time o RTT) Número de milisegundos transcurridos en tránsito cuando un cliente y servidor intercambian un paquete pequeño. Aun si los datos de la transacción están divididos en varios paquetes, el RTT sólo incluye un viaje redondo de un solo paquete entre el cliente y el servidor. Determinar si una demora importante en la red se debe a transacciones muy grandes o a que la red está muy lenta. Por ejemplo, si los usuarios de pronto empiezan a usar la funcionalidad de file sharing con archivos enormes, el deterioro en el desempeño de la red podría deberse a la cantidad de información que se está transmitiendo, más que a un cambio en el estatus de la red. En este caso se incrementaría la demora de la red, no así el RTT.

Tabla 2: Parámetros empleados en el análisis de desempeño de aplicaciones y cómo utilizarlos para detectar problemas de desempeño en la red.

El análisis de desempeño de las aplicaciones consiste en medir las demoras que se presentan tanto en la red como en los servidores, puntos terminales, hosts y otros equipos que utiliza una aplicación. Los mejores analizadores de desempeño pueden rastrear y asociar la demora con una aplicación determinada o un subproceso dentro de una aplicación (aplicaciones de Citrix, VoIP o video). En la siguiente tabla se presentan los parámetros que es necesario evaluar:

Planeación del ancho de banda para aplicaciones de video y voz

A la hora de planificar el ancho de banda para aplicaciones de VoIP o video, es importante entender cuánto ancho de banda realmente se necesita. Por lo general estas aplicaciones constan de varios componentes: audio, video, control y protocolo. El ancho de banda especificado al configurar la aplicación puede o no tomar en cuenta todos los datos que está utilizando la aplicación. El ancho de banda que realmente se consume a menudo es mayor una vez que se toman en cuenta todos los demás componentes. El único método confiable para determinar con exactitud los requerimientos de capacidad de las aplicaciones consiste en medirlos usando equipos de prueba. El ancho de banda para VoIP depende del algoritmo de compresión utilizado. La siguiente tabla muestra el consumo de ancho de banda para varios de los codecs más comúnmente usados en VoIP. Tenga en cuenta que estos val ores incluyen la carga del protocolo para el encabezado de los paquetes, pero para atravesar la WAN usando ATM o frame relay puede llegar a necesitarse un 10% más.

Requerimientos de ancho de banda para varios de los algoritmos de compresión más utilizados en VoIP*

Codec Bit Rate (Kbps) Ancho de banda nominal Ethernet (Kbps)
G.711 64 87.2
G.729

8

31.2

G.723.1

6.3

21.9
G.723.1 5.3 20.8
G.726 32 55.2
G.726 24 47.2
G.728 16 31.5

Tabla 3: Cada algoritmo de compresión para VoIP tiene un consumo distinto de ancho de banda.

*Fuente: Cisco Systems. Ver: http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml#topic1.

Para video sobre IP, una regla básica conservadora es asumir el valor nominal más 10% para la carga en una LAN y un 10% para la carga en una WAN (es decir, el llamado “cell tax”). Por ejemplo, para manejar una llamada de video a 384 Kbps que viaja en la WAN, es necesario proveer por lo menos 460 Kbps de ancho de banda; para una videoconferencia de 512 Kbps hay que suministrar un ancho de banda de al menos 615Kbps.

También hay que tomar en consideración el hecho de que cada tipo de llamada VoIP puede usar un ancho de banda distinto. Por ejemplo, si se tiene un PBX IP, quizá resulte deseable configurar el sistema para un protocolo económico en el uso de ancho de banda, por ejemplo G.723, al marcar a teléfonos IP en la red. Sin embargo, una llamada que entre a la red proveniente de la red de telefonía pública a través del gateway podría usar el protocolo G.711 de 64 Kbps. El responsable de la red tiene que tomar en cuenta la diferencia en el posible ancho de banda para protocolo al planear la implantación de aplicaciones de VoIP

En un ambiente “sin carga” (es decir, donde la aplicación de voz o video no compite con otras aplicaciones de datos), dimensionar la red es sencillo: considere 10% para el protocolo más otro 10% para las ineficiencias de la WAN. Sin embargo, si la WAN se comparte con otras aplicaciones, entonces hay que dar un margen adicional para la carga que implica operar en un ambiente compartido. Se recomienda que el tráfico de voz y video no consuma más de 50% a 70% de la capacidad de la red en un ambiente con distintos tipos de aplicaciones. Esto significa que se debe reservar por lo menos 30% de la capacidad de la red para las aplicaciones de datos. Aun si el ancho de banda esperado de las aplicaciones de datos es menor al 30%, se recomienda aplicar este nivel de asignación con el fin de minimizar posibles demoras debidas a encolamiento y el consiguiente deterioro en la calidad del audio o el video.

Los administradores de TI pueden solazarse al agregar ancho de banda para aplicaciones de video porque la capacidad nueva de hecho crea más ancho de banda para todas las aplicaciones que se ejecutan en la red. En una aplicación de video, el sistema de compresión de video envía tres tipos de cuadros: los cuadros llave, que contienen toda la información en una imagen determinada; los cuadros tipo p, que contienen únicamente lo que cambió en la señal de video de un cuadro a otro; y los cuadros tipo b, que son como los tipo p pero se construyen a partir de los cuadros llave y los cuadros p. Dado que el ancho de banda necesario se dimensiona en función del envío de la gran cantidad de datos que contiene un cuadro llave, y debido a que la mayor parte del tiempo se envían cuadros p y b más pequeños, en realidad hay más ancho de banda disponible para todas las demás aplicaciones, salvo cuando se manda un cuadro llave.

Figura 2: Los índices de utilización para el establecimiento de una llamada de voz o video sobre IP pueden ser varias veces mayores que los índices observados una vez que la llamada se ha estabilizado.

Implantación de procedimientos de control

Existen varias medidas basadas en el control para proveer un nivel adecuado de calidad de servicio. Un elemento clave en toda estrategia de control consiste en definir un concepto general de operaciones de red a fin de contar con un cimiento sobre el cual el administrador pueda erigir definiciones precisas de la funcionalidad y el desempeño que se pretende tener en la red. Cuando no se desarrolla un concepto operativo para la administración de la red, la consecuencia puede ser inestabilidad en la red o una administración a base de excepciones, debido a las cambiantes exigencias de los usuarios finales. Muchas veces los administradores necesitan unificar las expectativas de desempeño (a menudo divergentes) de los diferentes usuarios de las aplicaciones.

Marcaje y encolamiento de paquetes

En las redes que transportan datos además de voz y video, hay quienes instrumentan mecanismos de calidad de servicio a nivel IP para garantizar un manejo adecuado a los paquetes de voz y datos y salvaguardar su carácter de tiempo real. Los mecanismos a este nivel permiten identificar y dar un trato preferente en los mecanismos de transporte de la red a los paquetes individuales de las aplicaciones de alto nivel, usando para ello marcaje y encolamiento de paquetes. Los esquemas de precedencia de IP y precedencia de servicio diferenciado IP (DiffServ) se valen de mecanismos similares para marcar los paquetes y lograr una alta calidad de servicio. Ambos esquemas de marcaje de tráfico modifican ciertos bits en el encabezado del paquete de datos. Al llegar a un ruteador o switch habilitado para Precedencia de IP o DiffServ, a los paquetes que tengan los bits configurados correctamente se les da prioridad de encolamiento y transmisión.

Figura 3: Esquemas de clasificación de paquetes Precedencia de IP y y DiffServ.

En el encabezado de los paquetes IP, los bits 9 a 11 están reservados como bits de precedencia IP. Estos tres bits sirven para ocho clasificaciones distintas que van desde 7, correspondiente a la máxima prioridad, hasta 0 (cero), para la prioridad más baja*. No todos los proveedores de equipo implementan el esquema de clasificación de Precedencia de IP de la misma manera; por lo tanto, hay que estar atentos y cerciorarse que las redes mixtas (es decir, que incorporen equipos de varios proveedores) funcionen correctamente.

DiffServ utiliza los bits 9 a 16 del encabezado de los paquetes IP para ayudar a los ruteadores a priorizar cuáles paquetes deben enviar más rápidamente y cuáles pueden “soltar” en caso de presentarse un congestionamiento. DiffServ ha sido diseñado para ofrecer una mayor flexibilidad de clasificación que Precedencia IP, y ofrece 64 posibles clasificaciones**. Tanto con Precedencia de IP como con DiffServ, la red tiene que estar diseñada de manera que el esquema se implemente en forma consistente en toda la red. Algunos proveedores de servicio están comenzando a ofrecer clases de servicio con distintos niveles de calidad de servicio en función de la clasificación de DiffServ. En una red controlada mediante marcaje de paquetes, se debe dar a los paquetes de voz la mayor prioridad, pues son especialmente susceptibles a las demoras y el jitter, aun cuando la voz no es especialmente ávida en lo concerniente a consumo de ancho de banda. A los paquetes de video se les otorga una prioridad ligeramente menor, mientras que a los paquetes de correo electrónico y navegación en Web, por ejemplo, se les confiere la prioridad más baja.

*Las organizaciones que utilizan equipos Cisco exclusivamente deben configurar sus bits de precedencia de la siguiente manera: para voz sobre IP, el valor del bit del encabezado debe ser 5; para videoconferencia IP, 4; para todas las demás aplicaciones de datos, elija valores entre 3 y 0, según se requiera. Las prioridades 7 y 6 deben reservarse para los paquetes de protocolo de enrutamiento.

**Aunque DiffServ utiliza el octeto “ToS” en el encabezado de paquete IP que consta de los bits 9 – 16, los últimos dos bits (15 y 16) no se utilizan actualmente; por lo tanto, en realidad sólo se usan 6 bits, lo que permite 64 diferentes clasificaciones. Para más información, favor de consultar http://www.qosforum.com/docs/faq/.

Encolamiento

El encolamiento tiene lugar en los ruteadores y switches. Para cada esquema de marcaje de paquetes se establecen distintas filas o buffers. Una de las colas, por ejemplo, podría establecerse para información sensible a demoras y pérdidas de datos, tales como la voz y el video. Los paquetes de voz y video marcados con determinados valores de Precedencia IP o DiffServ se envían a estas filas de alta prioridad. Los paquetes en la fila prioritaria siempre se transmiten primero, seguidos de los paquetes que pudieran estar aguardando en las filas de menor prioridad. El administrador establece las filas y prioridades para su red, y los proveedores de infraestructura de redes, como Cisco, ofrecen recomendaciones sobre cómo hacerlo.

Conformación del tráfico

Las soluciones basadas en encolamiento tienen varias desventajas. De ellas, una de las más significativas es la falta de mecanismos de retroalimentación para determinar de qué manera las aplicaciones están compitiendo por ancho de banda. Por consiguiente, el tráfico de datos para las aplicaciones en las redes que usan mecanismos de encolamiento incrementa y disminuye las velocidades de transmisión en forma cíclica dependiendo de qué paquetes estén siendo descartados. Esto ocasiona fragmentos de datos que se van acumulando en la interfaz LAN/WAN, donde ocurre esa conversión en la velocidad.

Una manera de eliminar estos fragmentos de datos es usar una tecnología especial llamada control de velocidad TCP (TCP Rate Control). Desarrollada por Packeteer, TCP Rate Control regula o uniformiza los flujos de datos en la red, detectando la velocidad de acceso de un usuario remoto, tomando en cuenta la latencia de la red, y correlacionando esta información con otras políticas de velocidad y prioridad para las diversas aplicaciones. En vez de encolar los datos en un switch o ruteador y enviarlos a la velocidad adecuada, TCP Rate Control hace que las aplicaciones remitentes se frenen o se aceleren, enviando así los datos justo a tiempo. Al conformar el tráfico en paquetes de tamaño óptimo y enviarlos en el momento idóneo, TCP Rate Control permite mejorar la eficiencia de la red, aumentar la capacidad de procesamiento y lograr tiempos de respuesta más oportunos, consistentes y predecibles.

TCP Rate Control emplea tres métodos para regular la velocidad de transmisión de la aplicación:

Detección de velocidad de flujo en tiempo real. Medición de acuses TCP enviados al remitente. Modificación de los tamaños de ventana anunciados por TCP enviados al remitente.

Funciona detectando y monitoreando continuamente la velocidad de conexión de los servidores y clientes involucrados en una transacción de red, ajustando las estrategias de gestión del ancho de banda en tiempo real a medida que cambian las condiciones en la red. Un mecanismo de control de flujo tipo ventana corrediza controla la capacidad de transporte de los paquetes TCP sobre la red. Cuando el equipo destinatario da acuse por primera vez de que ha recibido los datos, anuncia cuántos datos puede recibir; a este dato se le denomina tamaño de ventana. El equipo remitente puede transmitir varios paquetes, hasta el tamaño de ventana, antes de detenerse a esperar un acuse. El remitente llena la “tubería”, espera el acuse, y la llena nuevamente. TCP Rate Control monitorea los acuses que manda el receptor, así como los tamaños de ventana, y los modifica en tiempo real para atenuar las ráfagas de datos y controlar cuándo la aplicación transmisora manda información, y cuánta.

La mayoría de las aplicaciones de voz y video utiliza UDP, en lugar de TCP, para transmitir datos en comunicaciones en tiempo real. A diferencia de TCP, UDP manda los datos al destinatario sin establecer una conexión, y UDP no intenta verificar que los datos hayan llegado intactos. Por lo tanto, se dice que UDP es un protocolo no confiable sin conexión de por medio. Los servicios que proporciona UDP son mínimos – multiplexación de números de puerto y un proceso opcional de verificación de errores con dígito verificador – por lo que requiere mínimo tiempo de procesamiento y menos ancho de banda que TCP. Esto permite que los paquetes UDP recorran la red más rápido, característica deseable cuando se trata de aplicaciones de voz y video.

Sin embargo, dado que UDP no administra la conexión de principio a fin, no recibe retroalimentación sobre las condiciones de transmisión y, por consiguiente, las aplicaciones que transmiten paquetes UDP no pueden prevenir ni adaptarse a situaciones de congestionamiento. Por lo tanto, UDP puede acabar por contribuir en forma significativa a un exceso de tráfico, en detrimento de todo el tráfico que circula por la red. Esto puede provocar que los flujos sensibles a problemas de latencia, como es el caso de voz y video sobre IP, se demoren a tal grado que resultan inútiles. En estos casos, la aplicación de voz o video puede seguir transmitiendo datos, completamente ajena al hecho de que está contribuyendo al problema de demora.

Repartición (Partitioning)

La velocidad de las transmisiones de UDP sobre la WAN puede controlarse mediante un proceso llamado repartición. Se trata de un caso especial de control de velocidad en el cual se reservan cantidades específicas de ancho de banda para las clases de tráfico más importantes. La reparticiónto también puede colocarse por encima (“overlay”) del control de velocidad TCP para aplicaciones basadas en TCP.

La repartición se administra mediante un dispositivo de conformación de paquetes que examina todos los paquetes que recorren la red. Al identificar que una aplicación determinada pertenece a una clase de partición dada, el “conformador de paquetes” puede controlar cuánto ancho de banda utiliza cada aplicación o clase de aplicaciones, y puede garantizar que una partición determinada siempre disponga de suficiente ancho de banda. Cuando el ancho de banda dentro de un reparto determinado no esté siendo completamente utilizado, el exceso puede ser reasignado a particiones dedicadas a otras aplicaciones importantes. El administrador también puede especificar valores máximos de flujo UDP, de modo que un flujo grande – videoconferencia o streaming video, por ejemplo—no consuma todo el ancho de banda de la red. En ambientes donde existan muchos equipos de video, las organizaciones querrán usar el particionamiento en conjunción con controles de ancho de banda de llamada, ya sea de un Proxy SIP o de un gatekeeper H.323, a fin de administrar en forma simultánea tantas videoconferencias como puedan hacerse en el sistema. Con el uso de un gatekeeper se evitará sobrecargar una partición de video determinada, lo cual provocar que fallasen todas las aplicaciones de video que se están ejecutando en ese reparto.

 
    Continuará…    
Opinión