Resumen
- BTPU admite copias exactas de mensajes para operar sobre un enlace unidireccional que no puede pedir retransmisiones.
- Transfer End revela el último índice esperado; la terminación solo existe localmente cuando el receptor reúne todos los segmentos de
0aN.
La escena parece tranquilizadora: el transmisor envía el mismo fragmento una y otra vez. Sin embargo, ninguna copia regresa con noticias. draft-ietf-dtn-btpu-04, publicado el 7 de septiembre, define un mecanismo para transportar grandes objetos binarios—habitualmente bundles BPv7—sobre una capa de enlace en tramas, no fiable y de una sola dirección.
Los segmentos de un objeto comparten un Transfer number de 32 bits y usan índices crecientes. Transfer End transporta el segmento final y el índice N. El receptor considera completo el traslado cuando posee 0..N, concatena los datos y entrega el bundle reconstruido a una capa superior.
Ese criterio no es un acuse enviado al origen. Que el emisor haya transmitido Transfer End no demuestra que el mensaje cruzó el enlace. Que el receptor lo vea no recupera segmentos anteriores. La reconstrucción completa tampoco demuestra que BPv7 aceptó el objeto, que CRC o BPSec fueron válidos, que otro nodo lo custodió o reenvió, ni que una aplicación lo procesó.
BTPU responde a la pérdida con redundancia abierta. Cualquier mensaje puede repetirse en otra PDU, siempre como copia exacta. La cantidad puede depender de un análisis del entorno, una prioridad local o señales fuera de banda. El borrador no convierte un número de repeticiones en una garantía universal.
La Transfer Window limita el conjunto de traslados simultáneos y ayuda a tratar números antiguos tras la vuelta del contador. El tamaño se acuerda fuera de banda. La cifra 16 aparece como recomendación provisional y todavía está marcada para discusión. Una ventana coherente protege estado y memoria; no certifica una entrega.
Tampoco deben sumarse sin contexto la repetición BTPU, la redundancia de la capa inferior y la codificación de borrado. Son mecanismos diferentes. El Bundle Length Hint solo anuncia memoria necesaria. La protección criptográfica pertenece a otras capas: integridad no equivale a llegada y confidencialidad no equivale a aceptación.
La sección de despliegue fija el límite: BTPU es no fiable y carece de retorno integrado para confirmar éxito. Todo acuse exige un camino lógicamente separado. Además, sin control de congestión propio, no debe usarse en una ruta disputada como Internet público salvo que la capa inferior aporte ese control.
Fuentes
- Registro Datatracker de BTPU
- Texto de BTPU revisión 04
- Historial de BTPU
- Repositorio del autor
- RFC 9171: Bundle Protocol Version 7
- RFC 9172: Bundle Protocol Security
- RFC 9174: TCP Convergence-Layer Protocol v4
- RFC 4838: arquitectura DTN
- RFC 5050: Bundle Protocol
- Registros IANA de Bundle Protocol
- Heng Lu: realidad, no promoción
- Heng Lu: especificación inicial mínima
- Heng Lu: primacía del código en funcionamiento
Informe para miembros
Leer el informe de tendencia completo
Los miembros leen el informe completo, con las notas de fuente detrás de cada hallazgo.
Círculo Estratégico
Un resumen diario en tu idioma, elaborado a partir de cambios que hemos verificado.
Únete por USD 20 al mesCancela cuando quieras.
Solicita tu admisión a Leadership Alliance
¿Ya eres miembro? Inicia sesión
Los miembros también obtienen toda la biblioteca de investigación, un resumen diario sobre las redes que siguen y el foro privado.






