TDM sobre IP

Este artículo incluye una lista de referencias , lecturas relacionadas o enlaces externos , pero sus fuentes no están claras porque carece de citas en línea . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( Octubre de 2014 ) ( Aprenda cómo y cuándo eliminar este mensaje )

En redes informáticas y telecomunicaciones , TDM sobre IP (TDMoIP) es la emulación de multiplexación por división de tiempo (TDM) sobre una red de conmutación de paquetes (PSN). TDM se refiere a una señal T1 , E1 , T3 o E3 , mientras que la PSN se basa en IP o MPLS o en Ethernet sin formato . Una tecnología relacionada es la emulación de circuitos , que permite el transporte de tráfico TDM sobre redes basadas en celdas ( ATM ).

TDMoIP es un tipo de pseudowire (PW). Sin embargo, a diferencia de otros tipos de tráfico que pueden transportarse a través de pseudowires (por ejemplo, ATM, Frame Relay y Ethernet ), TDM es un flujo de bits en tiempo real, lo que hace que TDMoIP tenga características únicas. Además, las redes TDM convencionales tienen numerosas características especiales, en particular las necesarias para transportar canales de telefonía de grado de voz. Estas características implican sistemas de señalización que admiten una amplia gama de funciones de telefonía, una rica literatura de estandarización y mecanismos de operaciones y gestión (OAM) bien desarrollados. Todos estos factores deben tenerse en cuenta al emular TDM sobre PSN.

Un problema crítico en la implementación de las PW TDM es la recuperación del reloj . En las redes TDM nativas, la capa física transporta información de sincronización de alta precisión junto con los datos TDM, pero cuando se emula TDM sobre PSN, esta sincronización no existe. Los estándares de sincronización TDM pueden ser exigentes y su cumplimiento puede requerir mecanismos innovadores para reproducir de forma adaptativa la sincronización TDM.

Otro problema que debe abordarse es la ocultación de pérdida de paquetes (PLC) de TDMoIP. Dado que los datos TDM se entregan a una velocidad constante a través de un canal dedicado, el servicio nativo puede tener errores de bits, pero los datos nunca se pierden en tránsito. Todas las PSN sufren en algún grado la pérdida de paquetes y esto debe compensarse al entregar TDM a través de una PSN.

En diciembre de 2007, TDMoIP fue aprobado como IETF RFC 5087 escrito por el Dr. Yaakov Stein, Ronen Shashua, Ron Insler y Motti Anavi de RAD Data Communications .

Los proveedores de servicios de comunicaciones y los clientes empresariales están interesados ​​en la implementación de servicios de voz y líneas arrendadas sobre infraestructuras eficientes de Ethernet, IP y MPLS. Si bien la voz sobre IP (VoIP) está madurando, su implementación requiere una inversión en nueva infraestructura de red y equipos en las instalaciones del cliente (CPE). TDMoIP presenta una vía de migración mediante la cual se pueden utilizar redes modernas conmutadas por paquetes para el transporte, sin necesidad de reemplazar de inmediato el equipo del usuario final.

TDMoIP fue desarrollado por primera vez en 1998 por RAD Data Communications (ver número de patente estadounidense 6.731.649) y desplegado por primera vez en Suecia en 1999 por Utfors (posteriormente adquirida por Telenor ). Utfors empleó el producto TDMoIP de primera generación (conocido como IPmux-4) para proporcionar servicios agrupados que incluían líneas privadas TDM, líneas alquiladas TDM y una variedad de servicios IP y Ethernet. En 2001, el IETF creó el grupo de trabajo PWE3 , que fue creado para desarrollar una arquitectura para pseudowires de borde a borde y para producir especificaciones para varios servicios, incluido TDM. Otros foros de normalización, incluidos la UIT y la MPLS - Frame Relay Alliance, también están activos en la producción de estándares y acuerdos de implementación para pseudowires.

Aunque TDM puede utilizarse para transportar secuencias de bits arbitrarias a las velocidades definidas en G.702, existen métodos estandarizados para transportar secuencias de bits en unidades mayores, cada una de las cuales contiene la misma cantidad de bits, llamadas tramas . La trama TDM bloquea la velocidad de trama a la frecuencia de muestreo del tráfico de voz, de modo que siempre hay 8000 tramas por segundo; una trama T1 consta de 193 bits y una trama E1 de 256 bits.

A diferencia de la TDM sin trama, en la que todos los bits están disponibles para la carga útil, la TDM con trama requiere dedicar una cierta cantidad de bits por trama para la sincronización y quizás para varias otras funciones (por ejemplo, 1 bit por trama T1, 8 bits por trama E1). La TDM con trama se utiliza a menudo para multiplexar varios canales de voz, cada uno de los cuales consta de 8000 muestras de 8 bits por segundo en una secuencia de intervalos de tiempo que se repiten en cada trama. Cuando se hace esto, tenemos "TDM canalizado" y se debe introducir una estructura adicional.

Para transportar de manera eficiente bits de señalización asociados a canales que varían lentamente, se definen estructuras de segundo orden conocidas como multitramas o supertramas. Por ejemplo, para los troncales E1, los bits de señalización CAS se actualizan una vez por cada multitrama de 16 tramas (cada 2 milisegundos), mientras que para los troncales ESF T1, la supertrama es de 24 tramas (3 milisegundos). También se utilizan comúnmente otros tipos de estructuras de segundo orden. En las redes celulares GSM , el canal Abis que conecta la estación transceptora base (BTS) y el controlador de la estación base (BSC) es un enlace E1 con varias alternativas de tramado, todas las cuales tienen una duración básica de supertrama de 20 milisegundos.

El término "TDM estructurado" se utiliza para referirse a TDM con cualquier nivel de estructura, incluido "TDM enmarcado" y "TDM canalizado".

El transporte TDMoIP se denomina "agnóstico de estructura" cuando el TDM no está enmarcado, o cuando está enmarcado o incluso canalizado, pero los mecanismos de transporte ignoran por completo la estructura de enmarcado y canalización. En tales casos, toda la sobrecarga estructural debe transportarse de manera transparente junto con los datos de carga útil, y el método de encapsulación empleado no proporciona mecanismos para su ubicación o utilización. El transporte TDM consciente de la estructura puede proteger explícitamente la estructura del TDM, de tres maneras conceptualmente distintas, que llamaremos bloqueo de estructura, indicación de estructura y reensamblaje de estructura.

El bloqueo de estructura garantiza que los paquetes consten de estructuras TDM completas o múltiplos o fracciones de las mismas. La indicación de estructura permite que los paquetes contengan fragmentos arbitrarios de estructuras básicas, pero emplea punteros para indicar dónde comienza la siguiente estructura. En el reensamblaje de estructura, los componentes de las estructuras TDM se pueden extraer y reorganizar en el ingreso, y la estructura original se puede reensamblar a partir de los constituyentes recibidos en el egreso.

TDMoIP funciona segmentando, adaptando y encapsulando el tráfico TDM en el ingreso de PSN y realizando las operaciones inversas en el egreso de PSN. La adaptación denota mecanismos que modifican la carga útil para permitir su correcta restauración en el egreso de PSN. Al utilizar la adaptación adecuada, se puede recuperar la señalización y la temporización de TDM, y se puede acomodar una cierta cantidad de pérdida de paquetes. La encapsulación significa colocar la carga útil adaptada en paquetes del formato requerido por la tecnología PSN subyacente. Para el caso de MPLS, la Recomendación UIT-T Y.1413 contiene una descripción completa del formato de paquete.

En todos los casos, un paquete TDMoIP comienza con encabezados PSN. Estos son los encabezados estándar utilizados por la tecnología PSN, por ejemplo, el encabezado de 20 bytes de UDP/IP o la pila de etiquetas de MPLS. Después de estos encabezados viene la "etiqueta PW", una etiqueta similar a MPLS de cuatro bytes que sirve para demultiplexar diferentes PW TDM. Después del encabezado PSN viene la "palabra de control" TDMoIP de cuatro bytes. La palabra de control contiene un número de secuencia de paquete de 16 bits (necesario para detectar la reordenación y la pérdida de paquetes), la longitud de la carga útil y los indicadores que indican las condiciones de defecto.

Después de la palabra de control viene la carga útil TDMoIP. Para el transporte independiente de la estructura (SAToP), esto es simplemente un número predeterminado de octetos TDM, mientras que para el formato bloqueado por la estructura, la carga útil es un número entero de tramas TDM. Para la indicación de la estructura y el reensamblaje de la estructura, TDMoIP se basa en mecanismos de adaptación probados desarrollados originalmente para ATM. Un beneficio adicional de esta elección de tipos de carga útil es la interoperabilidad simplificada con los servicios de emulación de circuitos transportados por redes ATM. Para los enlaces TDM de velocidad de bits constante (CBR) asignados estáticamente, TDMoIP emplea la capa de adaptación ATM 1 (AAL1). Este mecanismo, definido en la norma ITU-T I.363.1 y la especificación atm-vtoa-0078 del Foro ATM, se desarrolló para transportar servicios CBR por ATM. AAL1 funciona segmentando el flujo continuo de datos TDM en pequeñas celdas de 48 bytes e insertando información de secuenciación, temporización, recuperación de errores y sincronización en ellas. TDMoIP permite la concatenación de cualquier número de celdas AAL1 en un paquete (nótese que se trata de celdas AAL1 y no de celdas ATM, es decir, no incluyen el "impuesto de celda" de cinco bytes). Al permitir múltiples celdas por paquete, TDMoIP facilita compensaciones flexibles de retardo de almacenamiento en búfer (que disminuye con menos celdas por paquete) por eficiencia de ancho de banda (que aumenta con más celdas por paquete, debido a la sobrecarga por paquete). Para enlaces TDM asignados dinámicamente, ya sea que la tasa de información varíe debido a la activación de intervalos de tiempo o debido a la detección de actividad de voz, TDMoIP emplea la capa de adaptación ATM 2 (AAL2). Este mecanismo, definido en la norma ITU-T I.363.2, fue desarrollado para transportar servicios de velocidad de bits variable (VBR) sobre ATM. AAL2 funciona almacenando en búfer cada intervalo de tiempo TDM en miniceldas cortas, insertando el identificador del intervalo de tiempo y la indicación de longitud, secuenciando y luego enviando esta minicelda solo si lleva información válida. TDMoIP concatena las miniceldas de todos los intervalos de tiempo activos en un solo paquete. Para los intervalos de tiempo que transportan datos de control de enlace de datos de alto nivel (HDLC), como datos para señalización de canal común (CCS), TDMoIP tiene una adaptación especial que encapsula tramos de datos no inactivos.

La red de telefonía limita severamente los retardos de extremo a extremo. La norma UIT-T G.114/G.131 establece que los tiempos de transmisión unidireccional de hasta 150 ms son universalmente aceptables, suponiendo que se proporcione un control de eco adecuado. Estas restricciones no son problemáticas para las redes TDM, donde el componente principal del retardo de extremo a extremo es el tiempo de propagación eléctrica ("retardo de velocidad de la luz"). Por el contrario, los sistemas basados ​​en IP suelen añadir varias formas de retardo, una de las cuales se basa en el tiempo que lleva formar los paquetes (retardo de paquetización), que es proporcional al tamaño del paquete dividido por la velocidad de datos. Los tamaños de los paquetes no se pueden hacer demasiado pequeños o la sobrecarga del encabezado del paquete se volverá abrumadora. La otra forma de retardo introducida por los sistemas IP es el retardo de reproducción, que debe añadirse en el receptor para amortiguar la variación del retardo de los paquetes y garantizar una reproducción fluida. Los sistemas VoIP que intentan ser muy eficientes en cuanto al ancho de banda también pueden añadir decenas de milisegundos de retardo algorítmico en el códec de voz. Históricamente, las malas implementaciones han agregado retrasos adicionales inducidos por el sistema operativo, que junto con otros retrasos en la práctica a veces se acercan a los 100 ms incluso antes de tener en cuenta los retrasos de propagación.

Por el contrario, TDMoIP asigna octetos TDM directamente a la carga útil sin algoritmos de compresión de voz y sin demora algorítmica resultante. La latencia de paquetización agregada por TDMoIP depende de la cantidad de celdas por paquete, pero generalmente está en el rango de un solo milisegundo debido a la mayor velocidad de datos de un multiplexor completo en comparación con un flujo de VoIP único. Sin embargo, las consideraciones de demora de reproducción no difieren materialmente entre TDMoIP y VoIP, por lo que ambos funcionan mejor en rutas con variación controlada de demora de paquetes (fuerte sobreaprovisionamiento o "QoS").

Las redes TDM nativas se basan en una distribución jerárquica de la sincronización. En algún lugar de la red hay al menos un reloj de referencia primario extremadamente preciso con una precisión a largo plazo de 1 x 10^-11. Este nodo, que ofrece una precisión de Stratum 1, proporciona el reloj de referencia a los nodos secundarios con una precisión de Stratum 2. Los nodos secundarios proporcionan una referencia de tiempo a los nodos de Stratum 3. Esta jerarquía de sincronización de tiempo es esencial para el correcto funcionamiento de la red en su conjunto.

Los paquetes en la PSN llegan a su destino con un retraso que tiene un componente aleatorio, conocido como variación del retraso de los paquetes (PDV). Al emular el transporte TDM en una red de este tipo, esta aleatoriedad se puede superar colocando los paquetes TDM en un búfer de fluctuación desde el cual se pueden leer los datos a una velocidad constante para su entrega al equipo del usuario final TDM. El problema es que la referencia de tiempo de la fuente TDM ya no está disponible y se desconoce la velocidad precisa a la que se deben "extraer" los datos del búfer de fluctuación.

En ciertos casos, la sincronización puede derivarse del equipo TDM en ambos extremos del PW. Dado que cada uno de estos relojes es muy preciso, necesariamente coinciden en un orden superior. El problema surge cuando, como máximo, un lado del túnel TDMoIP tiene un estándar de tiempo muy preciso. Para las redes ATM, que definen una capa física que transporta la sincronización, se puede utilizar el método de marca de tiempo residual sincrónica (SRTS); sin embargo, las redes IP/MPLS no definen la capa física y, por lo tanto, no pueden especificar la precisión de su reloj.

Por lo tanto, en muchos casos la única alternativa es intentar recuperar el reloj basándose exclusivamente en el tráfico TDMoIP, una tecnología conocida como "recuperación de reloj adaptativa". Esto es posible porque el dispositivo TDM de origen está produciendo bits a una tasa constante determinada por su reloj, aunque esta tasa está oculta por el PDV. La tarea de recuperación del reloj es, por tanto, un proceso de "promedio" que anula el efecto del PDV aleatorio y captura la tasa media de transmisión del flujo de bits original.

Si bien se espera que la aplicación adecuada de la ingeniería de tráfico y la calidad de servicio (QoS) minimicen la pérdida de paquetes, a veces los paquetes llegarán a la salida fuera de orden. También es posible que se hayan descartado por completo dentro de la PSN. La palabra de control TDMoIP descrita anteriormente incluye un número de secuencia de 16 bits para detectar y gestionar los paquetes perdidos y mal ordenados. En el caso de paquetes perdidos, TDMoIP requiere la inserción de paquetes de interpolación para mantener la sincronización TDM. Los paquetes mal ordenados pueden reordenarse o descartarse e interpolarse.

Aunque la inserción de paquetes arbitrarios puede ser suficiente para mantener la sincronización TDM, en aplicaciones de voz la pérdida de paquetes puede causar lagunas o errores que resulten en un habla entrecortada, molesta o incluso ininteligible. El efecto preciso de la pérdida de paquetes en la calidad de la voz y el desarrollo de algoritmos de ocultación de la pérdida de paquetes han sido objeto de un estudio detallado en la comunidad de VoIP, pero sus resultados no son directamente aplicables al caso de TDMoIP. Esto se debe a que los paquetes de VoIP suelen contener entre 80 muestras (10 ms) y 240 muestras (30 ms) de la señal de voz, mientras que los paquetes de TDMoIP pueden contener solo una pequeña cantidad de muestras. Dado que los paquetes de TDMoIP son tan pequeños, es aceptable simplemente insertar un valor constante en lugar de cualquier muestra de voz perdida. Suponiendo que la señal de entrada es de media cero (es decir, no contiene ningún componente de CC ), se obtiene una distorsión mínima cuando esta constante se establece en cero. Alternativamente, los enfoques más sofisticados requieren predecir de manera óptima los valores de las muestras faltantes.

• TDMoIP
• Emulación de pseudo-cable de borde a borde (pwe3) en Wayback Machine (archivado el 4 de diciembre de 2004)