El formato Type Length Value (TLV) (Tipo-longitud-valor, en español) es una solución ampliamente utilizada para el problema del marshalling de datos. La figura 1 muestra un ejemplo del protocolo de enrutamiento de sistema intermedio a sistema intermedio IS-IS.
En la Figura 1, el paquete consiste en un encabezado, que generalmente tiene una longitud fija, y luego un conjunto de TLV. Cada TLV se formatea según su código de tipo. En este caso, se muestran dos tipos de TLV (en IS-IS hay muchos otros tipos; se utilizan dos aquí para ilustrar).
El primer tipo es 135, que lleva información sobre la versión 4 del protocolo IP (IPv4). Este tipo tiene varios campos, algunos de los cuales tienen una longitud fija, como la métrica. Otros, sin embargo, como el prefijo, tienen una longitud variable; la longitud del campo depende del valor colocado en algún otro campo en el TLV. En este caso, el campo de longitud del prefijo determina la longitud del campo de prefijo. También existen sub-TLV, que tienen un formato similar y llevan información relacionada con esta información IPv4. El tipo 236 es similar al 135, pero lleva información sobre IPv6, no IPv4.
Esencialmente, un TLV puede considerarse como un conjunto completo de información autónoma transportada en un paquete más grande. Un TLV consta de tres partes:
- Tipo de código: que describe el formato de los datos.
- Longitud: que describe la longitud total de los datos.
- Valor o datos: los datos en sí.
Los formatos basados en TLV son menos compactos que los formatos de longitud fija, ya que contienen más metadatos en el propio paquete. La información de tipo y longitud contenida en los datos proporciona información sobre dónde buscar en un diccionario la información de formato, así como información sobre la gramática a utilizar (cómo está formateado cada campo, etc.). Los formatos TLV compensan la posibilidad de cambiar el formato de la información transmitida por el protocolo sin necesidad de actualizar cada dispositivo o permitiendo que algunas implementaciones opten por no soportar todos los TLV posibles en comparación con los metadatos adicionales que se transmiten por cable.
Los TLV generalmente se consideran una forma muy flexible de marshalling de datos en protocolos.
Diccionarios de objetos comunes
Uno de los principales problemas con los campos de longitud fija es la fijación de las definiciones de los campos; si deseas modificar un protocolo de campo de longitud fija, debes aumentar el número de versión y modificar el paquete, o debes crear un nuevo tipo de paquete con diferentes codificaciones para los campos. El formateo TLV resuelve este problema mediante la inclusión de metadatos integrados con los datos transmitidos, a costa de transmitir más información y reducir la compacidad. Los diccionarios compilados comunes intentan resolver este problema colocando el diccionario en un archivo común (o biblioteca), en lugar de en la especificación. La Figura 2 ilustra el proceso.
En la Figura 2, este proceso comienza con el desarrollador creando una estructura de datos para organizar un conjunto específico de datos que se transmitirán a través de la red. Una vez construida la estructura de datos, se compila en una función o, posiblemente, se copia en una biblioteca de funciones (1) y se copia en el receptor (2). Luego, el receptor utiliza esta biblioteca para escribir una aplicación para procesar estos datos (3). En el lado del transmisor, los datos sin procesar se codifican en un formato (4) y luego se transmiten a través del protocolo a través de la red al receptor (5). El receptor utiliza su copia común del formato de datos (6) para decodificar los datos y transmitir la información decodificada a la aplicación receptora (7).
Este tipo de sistema combina la flexibilidad del modelo basado en TLV con la compacidad del protocolo de campo fijo. Aunque los campos tienen una longitud fija, las definiciones de los campos se establecen de manera que permitan una actualización rápida y flexible si es necesario cambiar el formato de marshalling. Mientras la biblioteca común esté separada de la aplicación que utiliza los datos, el diccionario y la gramática pueden modificarse mediante la distribución de una nueva versión de la estructura de datos original.
¿Se necesitará un “Flag Day” si se distribuye una nueva versión de la estructura de datos? No necesariamente. Si se incluye un número de versión en la estructura de datos para que el receptor pueda hacer coincidir los datos recibidos con la estructura de datos correcta, entonces varias versiones de la estructura de datos pueden coexistir en el sistema simultáneamente. Una vez que no se encuentra un remitente utilizando un formato de datos más antiguo, la estructura antigua puede descartarse de forma segura en todo el sistema.
En redes, un “Día de la Bandera” (Flag Day) ocurre cuando todos los dispositivos deben actualizarse simultáneamente a una nueva versión de un protocolo para evitar incompatibilidades.
Es importante destacar que, mientras que los sistemas de formato fijo y TLV confían en que los desarrolladores lean las especificaciones y escriban código como una forma de compartir gramática y diccionario, los sistemas de estructura de datos común descritos en estas diapositivas confían en que el diccionario común se distribuya de alguna otra manera.
Hay muchas formas diferentes de hacerlo, por ejemplo, se puede distribuir una nueva versión del software entre todos los remitentes y receptores, o se puede utilizar alguna forma de base de datos distribuida para asegurar que todos los remitentes y receptores reciban los diccionarios de datos actualizados, o alguna parte de la aplicación que gestiona específicamente el marshalling de datos puede distribuirse y acoplarse a la aplicación que genera y consume los datos. Algunos sistemas de este tipo transmiten el diccionario común como parte de la configuración inicial de la sesión.
Resumen
En resumen, el formato TLV ofrece una solución eficiente y flexible para el marshalling de datos en protocolos de red, permitiendo adaptaciones y actualizaciones sin la necesidad de cambios en todos los sistemas. Aunque menos compacto que los formatos de longitud fija, su flexibilidad compensa la sobrecarga de metadatos, convirtiéndolo en una opción ideal para protocolos que requieren adaptabilidad y evolución. La utilización de diccionarios de objetos comunes complementa esta flexibilidad, optimizando la eficiencia y la gestión de versiones.
