En el pasado post vimos las diferencias entre TDMoIP y VoIP así como las diferencias entres las redes de conmutación de circuitos y las de conmutación de paquetes.
Al final vimos que para transmitir un flujo síncrono a través de redes de conmutación de paquetes (PSN) a través de TDMoIP debemos segmentar, añadir información de control, encapsular, desencapsular, extraer información de control y reconstruir la información. Hoy veremos cómo realizar estas tareas los diferentes protocolos existentes.
Bundle o pseudowire (PW)
En TDMoIP introducimos el concepto de bundle o PW. Un PW es un 'canuto' o un grupo de paquetes encapsulados que incluyen la información de un flujo síncrono TDM. Para cada PW definimos una etiqueta o Bundle ID que nos permite:
- identificar los flujos individualmente facilitando las tareas de extracción del flujo síncrono
- multiplexar varios flujos sobre un mismo túnel a nivel superior (PSN)
Si el transporte es IP la etiqueta se asocia al puerto UDP sobre el que se encapsulan los paquetes (TCP no nos sirve porque necesita ACK y retransmisiones)
Si el transporte es MPLS la etiqueta se asocia a la inner label y en servicios L2TPv3 podemos usar la multiplexación L2TP para combinar los diferentes PW.
Estructura jerárquica de los paquetes TDMoIP
Para poder transmitir una información síncrona a través de paquetes necesitamos añadir una serie de información a los datos síncronos de usuario de acuerdo con el modelo inferior.
La cabecera PSN hace referencia a cabeceras IP o MPLS que permiten encaminar el tráfico entre origen y destino a través de la red PSN.La cabecera RTP (opcional) contiene marcas de tiempo que pueden ayudar a la recuperación del sincronismo en recepción
La palabra de control TDMoIP incluye contadores y números de secuencia que permiten detectar pérdidas de paquetes o alteraciones de la secuencia. También incluye alarmas locales y remotas
El flujo TDM original tiene que ser adaptado, es decir, ajustado de forma que permita:
- la transmisión de la señalización TDM
- facilitar la recuperación del sincronismo y la recuperación de paquetes perdidos
- conseguir un compromiso entre eficiencia (ancho de banda necesitado sobre PSN) y latencia (retardo en la transmisión)
Palabra de control TDMoIP
La palabra de control incluye los siguientes campos:
- PID (4b) para usos especiales
- flags (4 b)
- L bit (Local failure)
- R bit (Remote failure)
- FRG (2 bits) indica si hay o no fragmentación
- Length (6 b) se usa para añadir relleno cuando la cadencia de transmisión de la información paquetizada es superior al flujo TDM de entrada
- Sequence Number (16 b): número de secuencia que permite detectar pérdidas o desorden en los paquetes
TDM payload
En este campo debemos incluir el flujo de datos TDM a transmitir junto con el sincronismo asociado al mismo. En función de cómo adaptamos el flujo TDM a los paquetes encapsulados tenemos diferentes protocolos
Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
Se recoge en la norma RFC4553. El payload tiene un número fijo de bytes y siempre se encapsulará un trama completa o un múltiplo de tramas. Por tanto tendremos un payload de 256 bytes para E1 (32 TS), 192 bytes para T1 (24 TS) y 1024 bytes para E3 o T3.
Este protocolo es el más simple de encapsular y desencapsular y suele usarse en aquellas redes de paquetes bien caracterizadas donde tenemos un retardo constante (baja latencia) y un ancho de banda estable y garantizado. Por contra, no es posible encapsular únicamente algunos timeslots de la trama (E1 fraccional).
Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
Se recoge en la norma RFC5086. En este caso el payload también tiene una longitud fija pero múltiplo de 1 bytes (9 bits) y por tanto esto payload es capaz de encapsular timeslots de forma individual (E1 fraccional). La seañalización por canal asociado CAS, se obtiene añadiendo unos punteros al primer timeslot de la siguiente multitrama.
AAL1 y AAL2
En TDMoIP se utilizan técnicas idénticas para la encapsulación de flujos constantes a través de redes asíncronas ATM. En concreto tenemos los encapsulamientos AAL1 que se usa para flujos TDM constantes (circuit emulation) o AAL2 para flujos TDM de velocidad variable (Loop emulation). Estos últimos circuitos podrían representar, por ejemplo, el flujo primario de una centralita RDSI donde el flujo útil de datos transmitido varía en función del número de llamadas concurrentes. Otro ejemplo es detectar silencio en los canales de audio y no encapsular el tráfico TDM durante estos silencios requiriendo un menor ancho de banda.
En ambos casos el payload se estructura como un múltiplo de celdas o PDU AAL1/AAL2 de tamaño fijo de 48 bytes. En estas PDUs encapsulamos los datos del flujo, relleno (padding), sincronismo,... Si aumentamos el número de PDUs por paquete TDMoIP tendremos una mayor eficiencia y también un mayor retardo.Eficiencia vs retardo/latencia
En toda tecnología TDMoIP tendremos siempre un compromiso entre eficiencia y retardo/latencia.
Si tenemos un payload TDM grande, estaremos añadiendo poco overhead y por tanto reduciremos al caudal necesario. Por contra, tendremos que esperar un tiempo mayor antes de completar y encapsular el paquete y por tanto tendremos un retardo mayor en la recepción del flujo síncrono en el extremo remoto.
Si por el contrario tenemos un payload TDM pequeño (por ejemplo, 1 byte para 1 TS), estaremos añadiendo un overhead superior al propio flujo de datos pero tendremos un retardo muy pequeño.
En función del tipo de tráfico TDM y del ancho de banda disponible en nuestra red PSN debemos configurar los parámetros de nuestro payload.
Latencia
Uno de los principales problemas de las redes PSN de conmutación de paquetes es que usan medios de transmisión compartidos lo que provoca con frecuencia problemas de congestión. Estos problemas de congestión se traducen en la incapacidad de poder entregar un flujo de paquetes a un ritmo constante, es decir, paquetes consecutivos de un mismo flujo pueden padecer retardos diferentes. Este fenómeno se traduce directamente en lo que llamamos latencia o variación en el retardo. Este fenómeno puede ser incluso más molesto que el retardo en las comunicaciones por voz. Para compensar estas diferencias de retardo, los sistemas TDMoIP disponen de unos buffers internos que permiten compensar estas diferencias entre el ritmo de entrada al buffer (paquetes TDMoIP recibidos) y el ritmo de salida (flujo TDM reconstruido). Estos buffers se miden en ms. Por ejemplo, un buffer de 32 bytes (una trama E1 completa) nos compensaría un retardo de 125ms (lo que tarda en llenarse el buffer a ritmo de 2048Kbps).
No hay comentarios:
Publicar un comentario