Protocolo de transmisión de Licklider

This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (March 2019) (Learn how and when to remove this message)

El protocolo de transmisión Licklider es un protocolo punto a punto para su uso en enlaces de espacio profundo. El protocolo LTP se considera comúnmente como el protocolo de capa de convergencia subyacente estándar para los protocolos Bundle (RFC 5050), que admite una amplia selección de redes.

LTP recibe su nombre en honor al científico informático estadounidense Joseph Carl Robnett Licklider .

LTP está diseñado para ejecutarse directamente sobre una capa de enlace de datos (por ejemplo, el Protocolo de Enlace de Datos Espaciales de Sistemas Orbitales Avanzados (AOS) ^[1] ). También puede ejecutarse sobre el Protocolo de Datagramas de Usuario (UDP), por ejemplo, si se utiliza en una red de sensores, en una red privada (donde la disputa por el ancho de banda no es un problema) o para fines de depuración de software. Por lo tanto, no aborda cuestiones como el enrutamiento o el control de la congestión. Originalmente fue diseñado para soportar la transmisión de "larga distancia" en una red interplanetaria; su diseño se basa en experiencias con el Protocolo de Entrega de Archivos CCSDS (CFDP).

Desarrollado para la comunicación espacial, sus características son:

• Transporte de datos confiable para datos importantes (como el encabezado de un archivo)
• Transporte de datos poco confiable para datos menos importantes (como píxeles de imagen: un píxel dañado puede ser superado)
• No se intercambian mensajes para realizar la negociación. El protocolo evita este proceso para evitar demoras por tiempos de ida y vuelta elevados . También evita la subutilización del enlace.
• Eficiencia energética, ya que sólo transmite si hay un enlace disponible y distingue entre datos importantes y no importantes.
• Sus temporizadores funcionan junto con los programas de comunicación y pueden suspenderse cuando ocurre una interrupción programada del enlace.
• Es necesario que se le informe sobre la disponibilidad de la capa de enlace, el tiempo de ida y vuelta y los cronogramas de comunicación, lo que básicamente requiere una base de información de gestión (MIB). LTP es altamente dinámico.
• Sesiones de transmisión unidireccional, evitan los tiempos de ida y vuelta elevados o la incapacidad de un nodo de comunicación de pares para transmitir

La aplicación divide sus datos a enviar en dos partes (cualquiera de las partes puede tener un tamaño de 0):

• una parte roja : contiene datos que deben transportarse de forma fiable, que el receptor debe reconocer y que deben mantenerse disponibles hasta que se reconozca. Podría ser, por ejemplo, un encabezado que contiene información importante para decodificar los datos siguientes y cuya corrupción haría que todos los datos siguientes fueran inútiles.
• Parte verde . Contiene datos que no requieren un transporte fiable. Como no se acusa recibo de estos datos, se pueden descartar después de la transmisión .

El motor LTP almacena los datos en una cola, comprueba si el enlace hacia el destino está disponible y, en caso afirmativo, inicia la transmisión. Si el enlace no está disponible, los datos permanecen en la cola y la transmisión comienza tan pronto como llega una llamada "señal de estado del enlace", ya sea desde una capa de enlace subyacente o desde una base de información de gestión . Dados los datos rojos para enviar, el último segmento de los datos rojos se marca con una bandera de "fin de datos rojos" y se inicia un temporizador para ese segmento. Si no hay datos verdes para enviar, se establece la bandera de "fin de bloque", de lo contrario, se transmiten los datos verdes y el último segmento de esta parte se marca con la bandera de "fin de bloque". El receptor emite un segmento de informe para el remitente una vez que recibe el segmento de "fin de datos rojos" y todos los datos están completos. Una vez que se ha transmitido el segmento de informe, se inicia un temporizador. Al llegar el segmento de informe, el remitente cancela su temporizador, pone en cola un acuse de recibo de informe para el receptor e informa a la aplicación que todos los datos rojos se han transmitido correctamente. Una vez que el receptor recibe el acuse de recibo del informe, cancela su temporizador y se completa la transmisión de los datos en rojo. La transmisión se completa si ha llegado el segmento de “fin de bloque”.

Las dos implementaciones de referencia para LTP son:

• ION, escrito en C por el Laboratorio de Propulsión a Chorro y mantenido en la Universidad de Ohio .
• LTPlib, escrito en C por Trinity College, Dublín .

• Scapy tiene un módulo de contribución LTP, ^[2] aportado por MITRE Corporation. ^[3]

• RFC 5325: Protocolo de transmisión Licklider: motivación
• RFC 5326: Protocolo de transmisión Licklider: especificación
• RFC 5327: Protocolo de transmisión Licklider: extensiones de seguridad
• ION, Universidad de Ohio
• LTPlib Colegio de la Trinidad