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

Resumen ejecutivo

Prepararse para usar voz y video sobre IP exige entender a cabalidad el tráfico actual de la red, determinar las políticas de la red para cada tipo de tráfico y aplicar controles de Calidad de Servicio (QoS) en la red de área amplia (WAN). Muchas organizaciones sencillamente sobredimensionan el ancho de banda de la WAN con la esperanza de obtener una QoS adecuada. Algunas actualizan a una VPN MPLS bajo la creencia de que las clases de servicio en MPLS van a resolver los problemas de calidad del servicio.

Adoptar un enfoque holístico para habilitar voz y video sobre la red IP incluye llevar a cabo una evaluación de la red, hacer un análisis y planificación del ancho de banda, implantar procedimientos de control y realizar actividades de monitoreo y reporteo. La correcta aplicación de estas cuatro prácticas puede permitir a las organizaciones brindar la calidad de servicio que se requiere para voz y video sobre IP.

Introducción

El mayor desafío técnico en la transición de los sistemas tradicionales de voz y video a base de conmutación de circuitos a las nuevas y más económicas tecnologías de conmutación de paquetes de voz y video sobre IP consiste en lograr una adecuada calidad del servicio (QoS) en la red de área amplia. La calidad del servicio es la capacidad integrada en la red que garantiza que la información ha de atravesar la red de manera oportuna. La mayor parte de las redes de datos existentes fueron diseñadas para aplicaciones que, por un lado, envían la información en forma de ráfagas y, por otro, son insensibles a las demoras, lo que significa que si un paquete de datos llega dentro de un tiempo razonable, tanto la aplicación como el usuario quedan satisfechos. Los datos de voz y video, en cambio, son muy sensibles a los retrasos. Si un paquete llega más de unos 200 milisegundos (ms) después de que fue transmitido, el paquete es totalmente inútil como portador de comunicación en tiempo real, pues se recibirá demasiado tarde para ser utilizado en la conversación o imagen de video. Por lo tanto, las redes que transportan voz y video sobre IP deben estar diseñadas y configuradas correctamente para garantizar que los paquetes de datos en tiempo real puedan transitar por la red en forma eficiente.

Figura 1: Cuando varias aplicaciones intensivas en uso de datos compiten sin control por el escaso ancho de banda en una WAN, las aplicaciones de misión crítica y/o las aplicaciones en tiempo real, como por ejemplo voz y video, pueden acusar un desempeño deficiente.

La dificultad de lograr una adecuada calidad del servicio se ve exacerbada cuando un paquete de datos necesita atravesar la WAN. Las redes de área local (LAN) típicas funcionan a 10 Mbps, 100 Mbps y algunas incluso tienen un hecho de banda de 1 Gbps (1000 Mbps) o incluso más. Sin embargo, debido a que el ancho de banda sobre la WAN es considerablemente más costoso que sobre la LAN, muchas redes de área amplia operan a velocidades de T1 (1.45 Mbps) o menos, dando lugar a un enorme cuello de botella en la interfaz entre la LAN y la WAN. Para paquetes de datos normales, como por ejemplo correo electrónico, navegación en Web, programas cliente-servidor y muchas otras aplicaciones, este cuello de botella representa una molestia pero no es necesariamente devastador para las aplicaciones, pues estas pueden soportar demoras y aún así funcionar satisfactoriamente. Sin embargo, cuando paquetes de voz y video necesitan competir con los paquetes datos convencionales por capacidad de transmisión sobre una WAN con ancho de banda limitado, las aplicaciones de voz y video pueden llegar a resultar inoperantes, a menos que se tomen medidas para garantizar la calidad del servicio en esas aplicaciones.

Parámetros importantes para la QoS

Para las redes IP que transportan voz, video y aplicaciones de datos, el objetivo en términos de calidad del servicio consiste en un conservar tanto los datos de misión crítica en presencia de voz y video como la calidad de voz y video en presencia de tráfico de datos errático. La calidad del servicio en la red se evalúa midiendo cuatro parámetros fundamentales: ancho de banda, demora total, jitter y pérdida de paquetes.

Para que los sistemas de comunicaciones de voz y video sobre IP funcionen satisfactoriamente, el ancho de banda deben ser tan grande como sea económicamente posible y, al mismo tiempo, deben minimizarse la demora total, el jitter y la pérdida de paquetes. Una menor demora total se traduce en una comunicación más natural y satisfactoria, ya que las demoras largas dan pie a conversaciones poco naturales, con largas pausas entre las frases u oraciones. Los valores meta para la demora, el jitter y la pérdida de paquetes son < 200 ms, <50 ms, y < 1% respectivamente.

Aquellas organizaciones que deseen conservar el control administrativo de sus redes al incorporar nuevas aplicaciones, incluyendo voz sobre IP (VoIP) y video sobre IP, por lo general siguen alguna variante de un proceso básico de cuatro pasos que consiste en: 1) llevar a cabo una evaluación de la red existente; 2) determinar las características de ancho de banda y desempeño necesarias para las nuevas aplicaciones; 3) implantar procedimientos de control; y 4) monitorear y reportar el comportamiento de la red.

Evaluación de la red existente

Desde un punto de vista conceptual, hacer una evaluación de la red es muy sencillo. El administrador de la red necesita desarrollar una línea de base para la red identificando qué aplicaciones están corriendo actualmente, cuándo corren, cuánto ancho de banda utilizan y si su desempeño es satisfactorio. Para comenzar la evaluación se pueden utilizar diversas herramientas, incluyendo “sniffers” de paquetes y sondeos de la red. Los sniffers y las sondas vienen con un una gran variedad de funciones y pueden ser a base de hardware o software. La mayoría de estos equipos utiliza una especificación estandarizada de monitoreo conocida como Monitoreo Remoto, o RMON, que permite que varios monitores y sistemas de consolas intercambien información de monitoreo de la red. Con RMON, el administrador de la red puede monitorear un gran número de parámetros, tales como el número de paquetes perdidos, paquetes enviados y paquetes recibidos por un equipo determinado, colisiones de paquetes, qué dispositivos envían la mayor cantidad de datos, qué dispositivos reciben la mayor cantidad de información, contadores para tamaño de paquetes, y mucho más. Además de estas herramientas, muchos ruteadores permiten medir la demora y el jitter en determinados segmentos de la red entre un ruteador y otro.

Sin embargo, valerse exclusivamente de analizadores para la capa de protocolo de bajo nivel, como los que analizan los encabezados de los paquetes IP para clasificar el tráfico, no proporciona ningún indicio sobre qué aplicaciones están enviando tráfico a la red y podría inhibir el descubrimiento de algunas tendencias de tráfico más significativas. Subir un peldaño al nivel de aplicaciones para diferenciar el tráfico de una aplicación del de otra permite distinguir el comportamiento de cada aplicación en forma individual. Por ejemplo Skype*, Ares*, BitTorrent*, virus, worms, y muchas otras aplicaciones no basadas en HTTP que corren sobre la red consumen un ancho de banda significativo mientras se ocultan en un túnel HTTP utilizando el puerto 80 para atravesar el firewall. Un administrador de sistemas que se enfrente a problemas de capacidad en la red tendría dificultades para distinguir el tráfico de navegación de Web legítimo del tráfico peer-to-peer (P2P) no autorizado si no cuenta con herramientas de monitoreo más sofisticadas que analicen el comportamiento de la red a nivel aplicación. Esto es especialmente cierto en el caso de videoconferencias y VoIP, que comienzan a utilizar puertos bien definidos para establecer una comunicación pero después emplean varios puertos definidos dinámicamente (hasta ocho o más, dependiendo del punto terminal de video utilizado) para intercambiar información. Saber qué aplicaciones están ejecutándose, qué recursos de red de bajo nivel utilizan y cómo se comportan resulta esencial para establecer una línea de base y mantener el control sobre la red.

*Skype es una tecnología de telefonía gratuita P2P vía Internet. Ares es un programa gratuito para compartir archivos peer to peer que permite a los usuarios intercambiar cualquier archivo digital, incluyendo imágenes, audio, video, software, documentos, etc. BitTorrent es un programa para compartir archivos P2P capaz de acelerar considerablemente la descarga de información a través de redes no confiables (como lo es Internet). Consiste en intercambiar “fragmentos” de un archivo que el usuario posee por fragmentos que otros usuarios poseen.

VoIP vs. VoIP

A medida que las empresas adoptan la telefonía IP instalando PBXs IP, comienzan a apreciar la necesidad de proteger las aplicaciones de voz autorizadas y críticas para la empresa, no sólo contra el tráfico de datos sino también contra otras aplicaciones no autorizadas que se desprenden de programas de mensajería instantánea tales como AOL IM, Yahoo!, y MSN Messenger. Más aún, existe la posibilidad de que las futuras aplicaciones P2P puedan hacerse pasar por tráfico VoIP a fin de poder penetrar NATs y firewalls y recibir trato prioritario al transitar por la WAN.

Existen dos tipos principales de aplicaciones VoIP para mensajes instantáneos:

1. Aquellas que utilizan protocolos VoIP estándar tales como SIP y RTP. El problema aquí es que el ruteador puede estar programado para dar prioridad de tránsito por la WAN a cualquier paquete de voz que utilice estos protocolos; en consecuencia, el sistema de voz de la empresa podría sufrir problemas de calidad intermitentes debido a que necesita competir por ancho de banda con las personas que utilizan aplicaciones no autorizadas de VoIP –tales como AOL o MSN Messenger– y que, deliberada o inconscientemente, pueden estar utilizando ancho de banda prioritario de la empresa para comunicarse con sus familiares y amigos.

2. Aquellas que utilizan protocolos de VoIP propietarios. La dificultad con estas aplicaciones es que, por lo general, resultan más difíciles de distinguir de las aplicaciones de datos convencionales; por lo tanto, un esquema de priorización de paquetes basado en el marcaje e identificación de ciertos tipos de tráfico no funcionaría. Esto puede resultar aceptable, salvo en el caso de que la aplicación VoIP propietaria esté autorizada y se le considere una aplicación crítica.